search

open-telemetry / oteps

OpenTelemetry Enhancement Proposals
https://opentelemetry.io
Apache License 2.0
326 stars 157 forks source link

Trace Payload Collection #234

Open nirga opened 1 year ago

nirga commented 1 year ago

Continuing the work started by @ronyis at #219.

We're proposing semantic attributes for reporting payloads (of HTTP requests, DB queries, etc.) as part of OpenTelemetry. This should be optional for users who wish to use it and can provide consumers of OpenTelemetry with a standard option for getting payloads out of trace instrumentation.

Previous instrumentation libraries (pre-otel) have successfully implemented it so I think this is something that will be welcomed by the community.

Would love to get your feedback and work on getting this accepted.

mishushakov commented 9 months ago

Would love to see that happen at Step CI 😉

axlrate commented 3 months ago

Should the payload be a span event instead of a span attribute? Most backends have higher size limits for span events.

mmanciop commented 3 months ago

Should the payload be a span event instead of a span attribute? Most backends have higher size limits for span events.

Lumigo does this with span attributes, and the experience was that a truncation to 1024, 2048 or 4096 or power thereof was often good enough. (The complex bit was performing truncation that would keep validity of the data format, e.g., JSON.) Users have means via SDK configuration to change the attribute truncation threshold. I think setting this data as span events would be very unintuitive in terms of data model. I don't think we should use an unintuitive data model to work around limitations of backends. Moreover, for an important use-case like this, I can imagine backends makings exceptions for the specific keys we'd use.

codefromthecrypt commented 5 days ago

might be worthwhile to ping folks who did some things in this space, even if moved on since.