AfterSendCallback hook to capture SDK Issues

[nodshams]

Problem Statement

Hey team,

We experienced a problem with our Spring Boot application and egress proxy configuration. Due to a bug, the proxy settings were omitted in the shell entrypoint, causing our HTTP clients to fail. As a result, Sentry could not send events, and network issues went unnoticed until they had a production impact (the issue was identified when a Datadog monitor was triggered by a drop in business metrics).

Would it be possible to add a hook on application startup to healthcheck if Sentry has a successful server connection, or after the event send process to capture issues (in this case, network issues) that the Sentry SDK is experiencing? This would allow us to report these issues to Datadog and set up appropriate monitors.

Thanks!

Solution Brainstorm

No response

[adinauer]

Hey @nodshams thanks for opening this issue. We'll talk about this internally and come back.

[adinauer]

Can you please clarify how this should work @nodshams. If there's network issues, notifying other services also wouldn't work I presume.

[nodshams]

Hey @adinauer,

Thank you for getting back to me. What you mentioned makes complete sense for request serving. However, the issue we encountered was specifically related to the egress configuration for https.proxyHost and https.proxyPort; they were not set properly. This meant that we were blind to problems in scheduled tasks or background processes that threw exceptions. We only noticed the issue when Datadog scraped the metrics from the endpoint.

After fixing the egress configuration, we started receiving some errors. However, the problem now is that when Sentry is quiet for a long time, we can't distinguish whether it's due to network issues or if everything is running smoothly.

Thanks again!

[adinauer]

Thanks for the info @nodshams , our suggestion would be to have a hook in Sentry that allows you to detect failed Sentry requests. So a callback that'd be invoked whenever our transport fails to send an event. We're not quite sure how that'd be set. We'll update here once we take a more detailed looks. Can't state any ETA at the moment.

To perform a check at startup, you'd then have to capture a Sentry event (e.g. a message) and wait for the hook to fire (in case there's a problem).

Does this sound like it would solve your problem?