Open madhub opened 9 months ago
non relevant attributes : LogRecord.attributes collection contains ActionId, ActionName, ConnectionId,
There are likely coming from ILogger scopes. The only option today to avoid these, is to not enable scopes support. (They are not enabled by default.)
There isn't any fine grained control over scopes today, and this is something that needs to be addressed.
non relevant attributes : LogRecord.attributes collection contains ActionId, ActionName, ConnectionId,
There are likely coming from ILogger scopes. The only option today to avoid these, is to not enable scopes support. (They are not enabled by default.)
There isn't any fine grained control over scopes today, and this is something that needs to be addressed.
Yes these are coming from log scope, but I need logger scope for application adds application specific attributes in logger scope. This is the only way to enrich logs with application specific attributes , need to have some extensibility to filter out the attributes that are not relevant for application .
List<KeyValuePair<string,object?>> logContext= new List<KeyValuePair<string,object?>
{
new KeyValuePair<string, object?>( "CustomerId","1234"),
new KeyValuePair<string, object?>( "OrderId","768"),
}
using (logger.BeginScope( logContext ))
{
logger.LogInformation("Processing credit card payment");
}
@cijothomas
Can't we provide some option in OpenTelemetryLoggerOptions
that takes Scope filter as an option to retain or remove items ? Or some way by installing custom export processor
simple pseudo code here,
public class OpenTelemetryLoggerOptions
{
public Fun<bool ,...> ScopeFilter { get;set;}
}
Its definitely possible to offer some filtering ability, need to write up a proposal (or multiple), and gather feedback.
Could you create a more specific issue to tackle this? ILogger
is adding more filtering capability in the next release, and it may be worth checking if scope based filtering should come as part of that or it should be solved at OTel level. A separate issue will help track this issue.
Its definitely possible to offer some filtering ability, need to write up a proposal (or multiple), and gather feedback. Could you create a more specific issue to tackle this?
ILogger
is adding more filtering capability in the next release, and it may be worth checking if scope based filtering should come as part of that or it should be solved at OTel level. A separate issue will help track this issue.
Done #5239
Now I see more attributes in every log statement.Is there way to remove/disable it ?
"telemetry.sdk.language": "dotnet",
"telemetry.sdk.name": "opentelemetry",
"telemetry.sdk.version": "1.9.0"
Now I see more attributes in every log statement.Is there way to remove/disable it ?
"telemetry.sdk.language": "dotnet", "telemetry.sdk.name": "opentelemetry", "telemetry.sdk.version": "1.9.0"
There looks like Resources from OTel. No, they are not added to every statement. They are a separate concept, though it is entirely possible for a backend to copy all Resource attributes to every Log, but that is not done by OpenTelemetry/Exporters in this repo.
Doc for Resource: https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/logs/customizing-the-sdk#setresourcebuilder
ResourceBuilder.CreateDefault()
- is adding a bunch of spec-mandated defaults, including the ones like "telemetry.sdk.language" etc. If you don't want the defaults, you can use ResourceBuilder.CreateEmpty()
and then add any resource you want explicitly. In other words, while OTel does have a default for Resource, it also allows one to override them to be empty.
"telemetry.sdk.language": "dotnet", "telemetry.sdk.name": "opentelemetry", "telemetry.sdk.version": "1.9.0"
Thanks . It is the ResourceBuilder CreateDefault() that added the TelemetrySdk details . Now with ResourceBuilder.CreateEmpty()
and adding required service details , we don't see TelemetrySdk in log statements
Question
How to remove duplicate & non relevant attributes from the Otlp Log record before it is exported to OTLP log collector destination
I tried adding my own
LogProcessor
using an derived implementation ofBaseProcessor<LogRecord>
. it does not work becauseLogRecord.attributes
does not have these values when Otel library calls my implementationSample json log for reference
Use Github Discussions.