I wrote previously about our initial Sentry setup with Spring Boot, and let’s just say mistakes were made.

Oh well, okay, it’s not all bad, there is still some useful info there, which is why I am leaving it up, but there are some caveats.

1. You’ll see a scary looking message about Sentry being disabled on boot up.
2. Errors / Warnings that happen at bootup will not be captured by Sentry.

TLDR

Just show me how to make it work.

build.gradle.kts:

implementation("io.sentry:sentry-logback:1.7.30")

Enter fullscreen mode Exit fullscreen mode

sentry.properties: Put at the root of the Spring classpath

stacktrace.app.packages=com.mypackage

Enter fullscreen mode Exit fullscreen mode

logback-spring.xml: Also put at root of the Spring classpath

<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    <appender name="SENTRY" class="io.sentry.logback.SentryAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>WARN</level>
        </filter>
    </appender>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE"/>
        <appender-ref ref="SENTRY"/>
    </root>
</configuration>

Enter fullscreen mode Exit fullscreen mode

EDIT: The configuration has changed in later versions of the Sentry library, this is the same config updated for 3.2.0.

<configuration>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
    <appender name="SENTRY" class="io.sentry.logback.SentryAppender">
        <minimumEventLevel>WARN</minimumEventLevel>
    </appender>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
        <appender-ref ref="FILE"/>
        <appender-ref ref="SENTRY"/>
    </root>
</configuration>

Enter fullscreen mode Exit fullscreen mode

Environment Variables

- name: SENTRY_ENVIRONMENT
value: <enviroment>
- name: SENTRY_DSN
value: "<my-dsn>"

Enter fullscreen mode Exit fullscreen mode

Set the environment variables on a per deployment basis, which is going vary depending on your infrastructure. (We have ours as a Helm deployment value).

To disable Sentry, omit the SENTRY_DSN environment variable.

The longer explanation

So when I initially setup Sentry, I very much wanted to store my Sentry configuration alongside my Spring Boot project configuration. As you may have noticed above, I’ve entirely abandoned that approach, which I am slightly sad about since I like having configuration in one place.

So what went wrong, well let’s look at the two issues we had:

You’ll see a scary looking message about Sentry being disabled on boot up.

Specifically this error,

*** Couldn’t find a suitable DSN, Sentry operations will do nothing! See documentation: https://docs.sentry.io/clients/java/ ***

But then you’ll start seeing errors going to Sentry just fine. What the heck? This is connected to the next issue.

Errors / Warnings that happen at bootup will not be captured by Sentry.

While you will see errors go to Sentry, it will omit errors at bootup. Why? Because the Spring configuration isn’t loaded until the Spring Application Context is created, which means that Sentry misses the boat.

I won’t keep you in suspense, here is what is happening:

1. Logback boots up.
2. The Sentry Logback appender boots up.
3. Sentry finds no configuration, in either properties or the runtime environment.
4. It logs a missing DSN warning.
5. Spring Boot boots.
6. The Sentry Spring Boot starter configures Sentry.
7. Sentry will now be able to capture errors.

So if you care about capturing errors on bootup, sentry-spring-boot-starter isn’t really doing anything for you. In fact, with the configuration above, all you need is sentry-logback as a dependency.

Wrap Up

So the choices for using Sentry with Spring Boot are the following:

1. Use the logback dependency and capture errors both on startup and runtime but use environmental / properties for configuration.
2. Use the Spring Boot starter and capture errors only at runtime but be able to use application.yaml for configuration. If you want to capture logs, you’ll need to put off with a scary-looking warning at startup.

If the latter sounds preferable, check out my first article. But the method I’d recommend is above, even if the configuration options are worse.

Once again, I hope this was helpful. I’ve been staring Sentry for a bit now, so if you have any questions, feel free to ask below.

原文链接：Sentry with Spring Boot (The Better Way)