Sentry.Extensions.Logging Ignores Global Log Filters

[mattico]

Problem Statement

In my app I have global filters configured for certain libraries namespaces whose debug-level logs are spammy and not-actionable. The reason I configured them as global filters is because I want them to apply to all loggers, including Sentry's loggers. I spent quite some time confused about why Sentry was logging them anyway, before discovering sentry ignores such filtering intentionally.

I disagree quite strongly with this choice of defaults. It makes sentry work differently from any other (Microsoft.Extensions.Logging) logger I'm aware of. It is also different from Sentry's Python logging integration, which honors the logging level. I understand that users who are unfamiliar with Microsoft.Extensions.Logging may be surprised that messages below Information are filtered by default. However the solution for that is a single line which can be included in documentation and sample programs.

Global filtering is a useful feature of Microsoft.Extensions.Logging, and it would continue to be useful with Sentry in addition to Sentry's internal filtering options.

Solution Brainstorm

The most correct solution in my opinion would be to revert #1992 and explain in documentation and samples how users can configure the filtering to send all messages to Sentry if they choose.

However with an eye to backward compatibility, perhaps an option BypassGlobalLogFilters could be added to SentryLoggingOptions which defaults to true. Documentation should mention that sentry bypasses global filters by default.

[jamescrosswell]

Hey @mattico, thanks for the feedback.

The most correct solution in my opinion would be to revert #1992 and explain in documentation and samples how users can configure the filtering to send all messages to Sentry if they choose.

I'm wondering if there is any justification for Sentry to behave differently to other loggers and possibly there is.

If you're sending a bunch of logs to something like Splunk, you might configure a reasonably conservative log level in the interests of reducing costs. By contrast, the logs that Sentry collects are mostly used to create bread crumbs if there is an error... and when that happens, you probably want as much information as possible. So I could see how people might want different log levels for Sentry vs other log consumers.

This could be done using provider specific filters... although the log levels will have to be configured in multiple places (since logs are not the only source of breadcrumbs in Sentry).

It's hard to know all the different ways people are using Sentry and say, with certainty, that this would be better or worse for everyone.

However with an eye to backward compatibility, perhaps an option BypassGlobalLogFilters could be added to SentryLoggingOptions which defaults to true. Documentation should mention that sentry bypasses global filters by default.

That sounds like a safe option without any downsides that I can see. @bruno-garcia any thoughts?

@mattico to unblock you immediately, you can use the SetBeforeBreadcrumb callback on the Sentry options to filter out breadcrumbs that you're not interested in.

[bruno-garcia]

The comments explain the thought process of the author:

  // All logs should flow to the SentryLogger, regardless of level.
  // Filtering of events is handled in SentryLogger, using SentryOptions.MinimumEventLevel
  // Filtering of breadcrumbs is handled in SentryLogger, using SentryOptions.MinimumBreadcrumbLevel

5.0.0 was a good target to change the default behavior. Not sure an option to bring back the old behavior is needed.