What additional benefits can Sentry.IO provide over Application Insights for ASP.NET Core?
Our company is considering implementing Sentry.IO for our ASP.NET Core application, and I'm trying to understand the additional benefits it can offer over our current setup with Application Insights.
Here is what their arguments are:
Filtering Out 401 Errors: We encounter a lot of 401 errors in Application Insights, primarily due to JWT tokens expiring in the mornings. They said this was making it harder to track down real issues, and I've told them that they could filter these out by excluding Request Response Code != 401, but I'm curious if Sentry.IO offers a more efficient or automated way to handle this?
Exception Types by Count: They said they need to see exception types by count. For example, if our app suddenly produces a new 400 error that we haven't seen before, we need to detect and get alerted about it. This is still doable in Application Insights, and I've told them about it.
I wonder if there is an actual argument that would make Sentry.IO something more than Application Insights in some aspect.
An important distinction is that Sentry isn't a logging tool. It aggregates events with fingerprint (by default based on stack trace) into 'issues' and alerts you on new issues. You can configure alerts of course for other conditions beyond new issues.
It's focused on capturing the most amount of types of errors your app can have, and report them with extensive context that can help you debug what's going on. Including lines of code but also surrounding source code, even if PDBs are not shipped with the final app (Sentry's SDK has an msbuild task that can upload PDBs to Sentry for server-side symbolication). As well as possible commit that caused that error.
Filtering Out 401 Errors
Sentry will not capture events for requests served that resulted in status 401. It will capture any error in your code, resulting in a 500. For example if it was an unhandled exception thrown in a Middleware. Or an error that happened to be handled by an ExceptionHandler. Or also errors in Task's that were not captured by your code UnobservedTaskException. And other such errors.
In addition it can capture errors if you're using blocking calls on async endpoints.
And HTTP Client errors (if you're using HttpClient or HttpClientFactory): https://docs.sentry.io/platforms/dotnet/guides/aspnetcore/configuration/http-client-errors/
On ASP.NET Core, you just need to opt-in with options.CaptureFailedRequests = true; since the handler is added automatically.
And you can configure what status codes you want to add (for example if you want to opt-in to 400 range: options.FailedRequestStatusCodes.Add((400, 499));. But I realize this is exactly what you don't want, and the default behavior is NOT to capture ~400.
It also runs on Native AOT compiled apps, including ASP.NET Core. See: https://sentry.engineering/blog/should-you-could-you-aot