ApplicationInsights-dotnet icon indicating copy to clipboard operation
ApplicationInsights-dotnet copied to clipboard

ApplicationInsightsLogger doesn't respect Category LogLevel

Open stevendarby opened this issue 2 years ago • 4 comments

As per https://github.com/dotnet/aspnetcore/issues/42950 I have added the following to my appsettings.json Logging:LogLevel section in order to filter out logging by the ASP.NET Core ExceptionHandlerMiddleware: "Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware": "None"

I can confirm this works for the ConsoleLogger. However, I'm still seeing exceptions tracked in application insights with the category "Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware" which suggests to me that the app insights logger isn't respecting its configured log level.

I can provide a repo if really needed.

stevendarby avatar Aug 10 '22 16:08 stevendarby

https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core#how-do-i-customize-ilogger-logs-collection

cijothomas avatar Aug 10 '22 17:08 cijothomas

I'm not clear on what this means. There is no example for targeting a category, which might help. Are you saying that the application insights logger doesn't respect the standard way of configuring log levels. Isn't that a bug?

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-6.0#configure-logging

"A specific log provider is not specified, so LogLevel applies to all the enabled logging providers except for the Windows EventLog."

stevendarby avatar Aug 10 '22 17:08 stevendarby

So, what I had previously, which didn't work:

 "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware": "None" 
    }
  }

and now this, which does seem to work:

 "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware": "None" 
    },
    "ApplicationInsights": {
      "LogLevel": {
        "Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware": "None"
      }
    }
  }

I want to apply the category filter to all loggers, so I need to keep it in the general section too. The duplication is unfortunate.

I also don't quite understand the justification for requiring an explicit override for the ApplicationInsights logger which is given in your link:

It doesn't capture it because the SDK adds a default logging filter that instructs ApplicationInsights to capture only Warning logs and more severe logs. ApplicationInsights requires an explicit override.

Why does this prevent the LogLevel for the specific category - applied in the general section - being applied to the application insights logger? Thanks in advance for any further info.

stevendarby avatar Aug 10 '22 20:08 stevendarby

Why does this prevent the LogLevel for the specific category - applied in the general section - being applied to the application insights logger?

If you used Microsoft.ApplicationInsights.AspNetCore package, and enabled application insights using the one liner services.AddApplicationInsightsTelemetry(), then it automatically inserts a Filter rule to only send Warning or above to ApplicationInsightsLoggerProvider. Since this is a specific rule, it wins over the general one you have. Hence you need to give more specific filter to override.

cijothomas avatar Aug 10 '22 20:08 cijothomas

I think the request here is (please @stevendarby correct me if I'm wrong): you have to write the "Logging":"ApplicationInsights":"LogLevel" section, rather than just the "Logging":"LogLevel" section.

Normally, a provider such as AppInsights, when not otherwise specified, is expected to use what is written in the common section "Logging":"LogLevel".

But, if we write something like:

 "Logging": {
    "LogLevel": {
      "Default": "Warning",
      "My.Example": "Trace" 
    }
  }

... sadly the traces with "My.Example" category would not be logged. But if we do something like:

 "Logging": {
    "LogLevel": {
      "Default": "Warning"
    },
    "ApplicationInsights": {
      "LogLevel": {
        "My.Example": "Trace"
      }
    }
  }

... this works.

I think the problem here is that, by default, ApplicationInsights use "Warning" as default severity level. If you don't specify the "Logging":"ApplicationInsights":"LogLevel" config section, the "warning" filter rule will overwrite the rules in "Logging":"LogLevel".

gioce90 avatar Jan 23 '23 22:01 gioce90

Normally, a provider such as AppInsights, when not otherwise specified, is expected to use what is written in the common section "Logging":"LogLevel".

^ This is true for application insights logger provider as well.

cijothomas avatar Jan 24 '23 00:01 cijothomas

I think the problem here is that, by default, ApplicationInsights use "Warning" as

^ This is not the behavior of ApplicationInsightsLoggingProvider. It is the case when you use Microsoft.ApplicationInsights.AspNetCore package, to enable all telemetry (tracing, logging, metrics, etc.) with a one-liner (AddApplicationInsightsTelemetry()).

cijothomas avatar Jan 24 '23 00:01 cijothomas

This issue is stale because it has been open 300 days with no activity. Remove stale label or this will be closed in 7 days. Commenting will instruct the bot to automatically remove the label.

github-actions[bot] avatar Nov 21 '23 00:11 github-actions[bot]