semantic-conventions

semantic-conventions copied to clipboard

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

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.

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.

This would be very useful for certain scenarios

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

upvoted this request :-) would be really usefull

+1

@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

I haven't looked into this ticket since October 2020

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

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.

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.

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

(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.

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.

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

If we consider observability from an enterprise solution perspective, the demand makes perfect sense and proves to be highly useful. However, if we take the perspective of agents alone, this demand might seem less relevant.

I assist companies in establishing enterprise-oriented observability. Managing performance, logs, and metrics is only the first step in an IT for IT approach. The real challenge lies in progressing to higher layers, namely an IT to Business approach.

At these higher levels, information derived from observability becomes strategically significant and even represents a considerable opportunity. By integrating use cases focused on real-time security with a business-oriented and customer behavior perspective, it becomes essential to have enriched data. This enables companies to capitalize on observability as a sub-datalake, integrated into the organization's global datalake.

In summary, it is crucial and timely to have this capability to transform observability into a strategic lever that serves the company.