open-telemetry / opentelemetry-dotnet

The OpenTelemetry .NET Client
https://opentelemetry.io
Apache License 2.0
3.09k stars 736 forks source link

Allow Ability to disable log argument attributes but still include scope attributes #5726

Open ttindell2 opened 1 week ago

ttindell2 commented 1 week ago

Package

OpenTelemetry

Is your feature request related to a problem?

No response

What is the expected behavior?

When using open telemetry logger, and you have code like this:

using var logger = Logger.BeginScope(new Dictionary<string, string>() { { "Service", "SuperImportantService" }, {"FileName", "FILE"} });

Logger.LogDebug("Service name {name} is running on {computer}, and will process file {file}",  "NAME", "COMPUTER", "FILE");

you will get a log state with this:

"Service": "SuperImportantService",
"FileName": "FILE",
"name": "NAME",
"computer": "COMPUTER",
"file": "FILE"

And if you have another log in the same scope:

Logger.LogDebug("Service name {ServiceName} is taking {time} and processing {name}",  "SERVICENAME", "TIME",  "FILE");

you will get a log state like this:

{
"Service": "SuperImportantService",
"FileName": "FILE",
"ServiceName":"SERVICENAME"
"time": "TIME",
"name": "FILE"
} 

And as you have more and more log statements, the amount of state keys gets higher. Some Exporters aggregate these keys into columns, and the columns start to expand to unmanageable amounts.

The request is to add a OpenTelemetryLoggerOptions called IncludeLogArguments that is defaulted to true. If true, it will append the log arguments. And if false, it will not include the log arguments.

Which alternative solutions or features have you considered?

The only alternative is to fix every log statement in code to be the same "key" name or to break logging practices and not use arguments in your logging statements.

Additional context

No response

cijothomas commented 1 week ago

The only alternative is to fix every log statement in code to be the same "key" name

How would that help? There is no de-duplication done, so duplicates will be added to attributes!

I think we have some issues previously opened about controlling scopes more granularly, but dont think I have seen concerns about attributes itself. Maybe I didn't quite understand the concern raised in this issue...