Capture request and response bodies

[pavolloffay]

What are you trying to achieve?

I want to capture request and response bodies. The content can be used for business transaction monitoring and security.

To move this forward we need:

• data semantics e.g. http.request.body/http.response.body or be transport agnostic e.g. request.body, response.body.
• a configuration for auto instrumentations e.g. OTEL_INSTRUMENTATION_CAPTURE_REQUEST_BODY=bool

Additional context.

• business transaction monitoring http://trasier.com/
• capture request and response bodies in Java https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/1317

[Oberon00]

Related https://github.com/open-telemetry/opentelemetry-specification/issues/1061#issuecomment-704409768

EDIT: But here it may make sense to keep in one issue to define if we even want to support this at all. It seems problematic, both from a performance and also privacy perspective.

[pavolloffay]

EDIT: But here it may make sense to keep in one issue to define if we even want to support this at all. It seems problematic, both from a performance and also privacy perspective.

This is an opt-in feature not enabled by default only users who need this would enable it with all the implications of course.

[jbadeau]

This would be very useful for certain scenarios

[alfkonee]

Hello please has there been any progress made here. This specification would be really helpful in many enterprise Environments for also in many app dev scenarios for distributed trace of app data flow validations

[edtro]

upvoted this request :-) would be really usefull

[iquirino]

+1

[gmreads]

@pavolloffay Is this still a priority for you ? Were there any discussions within the Otel team ? I've been working on shipping custom sdks which capture request bodies.

How can we take this forward ? I would really like to make this happen. @Oberon00

[pavolloffay]

I haven't looked into this ticket since October 2020

[trask]

@gmreads check out https://github.com/open-telemetry/oteps/pull/219

[nirga]

I've been looking into this, and read through open-telemetry/oteps#219 . The short background is that we need a way to get the body of requests and responses through OpenTelemetry since this is how we generate and run tests at Traceloop. I don't think this is out of the ordinary for an observability protocol. Looking at tools like Sentry and others, you can regularly observe request/response bodies (with some obfuscation ofc).

Today, we patch the instrumentation for our clients so we can get the request body but the main problem is that there's no standard for this. I propose we standardize the semantic attribute name of http.request.body so that potential extensions to the standard SDK can tell which attribute name to use if they want to export this information.

Would love to start working on this.

[jack-berg]

Some context: open-telemetry/opentelemetry-specification#2888 proposed extending attributes to support complex types like maps and heterogenous arrays. If added, this would be a natural place to put http request / response bodies. Unfortunately, we didn't achieve consensus and the PR is currently closed. That effort could be restarted, but I think it would take new use cases and / or new arguments to move the needle.

[nirga]

Open a new PR for that open-telemetry/oteps#234

[axlrate]

(I asked this on oteps 234 as well)

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

[julealgon]

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

That doesn't make sense from a semantics point of view though... a piece of request/response data is not "an event" IMHO. And the HTTP span itself already represents a request or response, so there is no room to define a "send event" inside of that in my mind.

[chameleon82]

I would prefer to have body and other request/response attributes as a structured log. Moreover, to have the ability to separate them into different pipelines from other logs (different security and rotation policies). It is make sense to me to be able to select them by certain parameters and groups and able to process via anomaly detection tools. Currently, I do it this way already, but I had to write extra instruments and believe spec here will be helpful