Observability.

When I started working with the microservices at my job about 4 months ago, there were numerous ways to know a bug made it to production.

Slack alerts. Cloudwatch logs. Production support.

There was no aggregation of errors and alerting.

I had never used Sentry, but heard a lot about it over the last couple of years. It seemed like a reasonable solution to this problem.

Other folks at my job agreed we should try it. Here's what it took to integrate.

Requirements

To understand fully what's going on in each of the services, it made sense to capture EVERYTHING, at least at first. This meant uncaught and caught exceptions, including the ones already caught by any @ExceptionHandlers.

We also wanted to keep any secrets out of our code and in AWS Secrets Manager.

Follow The Instructions

I found vast documentation on Sentry's Spring Boot docs pages. However, there wasn't a solution that let us store the DSN securely, outside the source.

My Solution

To store the DSN elsewhere and pull it in at runtime, I used the AWS Secrets Manager SDK. Here's a decent tutorial from AWS on how to get that setup. Now let's focus on the Sentry part.

Code

Combining the documentation from Sentry and the slightly different requirements we had, I created a Spring configuration that provides a Sentry OptionsConfiguration bean:

@Bean
@Primary
Sentry.OptionsConfiguration<SentryOptions> sentryOptionsConfiguration() {
    return options -> {
        SentryProperties properties = (SentryProperties) options;
        properties.setDsn(secretService.getSentrySecret().getDsn());
        properties.setEnvironment(activeProfile);
        properties.setDebug(true);
        properties.setExceptionResolverOrder(Ordered.HIGHEST_PRECEDENCE);
    };
}

Because Sentry provides an OptionsConfiguration themselves, I used @Primary to ensure mine took precedence.

I used the Spring profile name to set the environment; for example, QA.

To make sure we see all handled errors, I set the exception resolver order to Ordered.HIGHEST_PRECEDENCE.

Properties

I thought the code changes would be enough. I was wrong.

Turns out Sentry requires the property sentry.dsn to be set to something or the Sentry bootstrap fails when the Spring application context is built.

The solution:

sentry.dsn=dummy in my application.properties file

Summary

Sentry is an extremely useful tool that has a friendly and clear interface. We use it to see production issues and have more context of issues reported by our QA team.

With these small tweaks, we are able to get the data we need to resolve errors fast.