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.
- You'll see a scary looking message about Sentry being disabled on boot up.
- Errors / Warnings that happen at bootup will not be captured by Sentry.
Just show me how to make it work.
sentry.properties: Put at the root of the Spring classpath
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
<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>
- 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,
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:
- Logback boots up.
- The Sentry Logback appender boots up.
- Sentry finds no configuration, in either properties or the runtime environment.
- It logs a missing DSN warning.
- Spring Boot boots.
- The Sentry Spring Boot starter configures Sentry.
- 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.
So the choices for using Sentry with Spring Boot are the following:
- Use the logback dependency and capture errors both on startup and runtime but use environmental / properties for configuration.
- 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.
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...
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...
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
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 [...]
01.28.2021 | Backend | Parker Drake
Recently I found myself needing to validate fields in a Spring Boot controller written in Kotlin...
01.22.2021 | Tutorial | Luke Mueller
⌘+⇧+g is the way to go
01.21.2021 | Devops | Katy G
Kube jobs running wild? To delete successful jobs...