New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Usability concerns regarding logging enrichment and tags collision #4947
Comments
Hello @NatMarchand, thank you for reaching out. I agree that some tags share same names in HttpClient and HTTP logging components, but you can easily distinguish them using:
Additionally, you can also add your custom enricher (one that implements @klauco any other thoughts here? |
@NatMarchand, I see where the confusion is coming from. |
That's not totally true. I've pinpointed the problem:
Issue the following log (with otel console exporter):
See the http.request.header.user-agent added twice, one from my browser calling the server and the other from the httpclient outgoing. When using otlp exporter, only the last "survive" Repro code
|
What is the expected behaviour -- completely omit the incoming HTTP request headers from the outgoing HTTP request logging, or include them with different names? |
If I had a magic wand, as I want to have both information, I'd make it on different prefix : |
Okay, that happens because you added With regards to the magic wand, you can always create your custom processor that derives from |
Alternatively, you can use |
Yes, it's what we find really interesting with enrichment: we have some headers that allow us to troubleshoot or correlate (we use UserAgent to know which of our service make the call or the cloudflare RayId). That avoid us to make a first call to find the TraceId from them and then filter on this (these) TraceId.
I'm not sure if in the BaseProcessor I'm able to determine if such attribute comes from the enrichment of the request and delete it or from the outgoing call and keep it.
See my first point, what we found really interesting is to filter logs against headers without join. |
I would encourage you to rely on |
All OTel attributes can be used on traces, metrics, or logs, we don't differentiate attributes by signal. Here it seems we have an interesting issue - when enriching logs the new attributes clash with existing ones - I guess the enricher should be responsible for the conflict resolution and/or use dedicated namespace to add attributes to. |
Hi!
I'm currently trying log enrichment on an app but I think there's a problem of usability.
In the simple case where I have an AspNet server endpoint which makes a HttpClient request however all the tags collide for example http.request.header, http.response.header. In my logs I don't know if the header comes from the incoming request or outgoing request.
I do understand that there are OTEL conventions however they seem to apply only for tracing not logs.
The text was updated successfully, but these errors were encountered: