Blog

Sentry with Spring Boot (The Better Way)

08.24.2020 | Tutorial Devops Backend | James McMahon

hero

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")

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

stacktrace.app.packages=com.mypackage

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>

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>

Environment Variables

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

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,

icon

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.
  8. 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](https://dev.to/focusedlabs/sentry-with-spring-boot-1jko). 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.

Share

Read More

Related Posts

related_image

06.30.2021 | Culture | Katy Scott

At Focused Labs, collaboration is key to how we work together; it helps our teams learn from each other, brings us closer and helps us become more efficient...

related_image

06.23.2021 | Culture | Austyn

Late-night feedings and diaper changes, the 3-4 month sleep regression, teething, and a growth spurt all mean I'm getting less sleep than...

related_image

05.12.2021 | Culture Backend Frontend | Ryan Taylor

Temporarily disrupts "normal" business operations and allow self-organized teams to rapid prototype around their interest areas

related_image

04.27.2021 | Culture | Erin Hochstatter

Several years ago, I'd been trying to find an approach to software consulting that made sense for me [...]

related_image

01.28.2021 | Backend | Parker Drake

Recently I found myself needing to validate fields in a Spring Boot controller written in Kotlin...

related_image

01.22.2021 | Tutorial | Luke Mueller

⌘+⇧+g is the way to go

related_image

01.21.2021 | Devops | Katy G

Kube jobs running wild? To delete successful jobs...

additional accent
accent
FocusedLabs

171 N Aberdeen St
Suite 400
Chicago, IL 60607
(708) 303-8088

[email protected]

© 2021 FocusedLabs, All Rights Reserved.

  • facebook icon
  • twitter icon
  • linkedin icon
  • github icon