Capture body for HTTP requests + incoming messages

[jackshirazi]

Classic agent link

• https://www.elastic.co/guide/en/apm/agent/java/current/config-core.html#config-capture-body

What it does

For transactions that are HTTP requests, the Java agent can optionally capture the request body (e.g. POST variables). For transactions that are initiated by receiving a message from a message broker, the agent can capture the textual message body.

Implementation difficulty, location, and dynamism

• Already implemented
• https://opentelemetry.io/docs/zero-code/java/agent/configuration/#capturing-servlet-request-parameters
• https://opentelemetry.io/docs/zero-code/java/agent/configuration/#capturing-consumer-message-receive-telemetry-in-messaging-instrumentations
• Not dynamic

@akhileshpok please feedback on whether this really needs to be supported as a dynamic capability

[akhileshpok]

@jackshirazi - I have not heard that this parameter needs to be dynamic. Let me check with the customer!

[akhileshpok]

@jackshirazi - Yes, this parameter needs to be dynamic.

[SylvainJuge]

I don't think the mentioned configuration options here provide the same thing as what we call "body capture" in classic agent.

What is supported by OTel Java is the following:

• capture servlet request parameters:
  • this is equivalent of HTTP request body capture for HTTP POST/PUT with simple variables
  • this does not include the whole HTTP request body, for example a POST request with an XML document would not be captured
• OTEL_INSTRUMENTATION_MESSAGING_EXPERIMENTAL_RECEIVE_TELEMETRY_ENABLED
  • when set to false (default) no span is created when receiving a message, only when sending one.
  • this can be verified by running com.example.javaagent.smoketest.AgentFeaturesSmokeTest#messagingHeaderCapture, when set to true we have a 4th span created when receiving the message.

What is being supported with capture_body is the following:

• request input is buffered and copied as-is to the transaction captured
• support is framework-specific and has some limitations on the input: needs to have an heuristic on content type to be readable as text.
• for incoming messages, they are copied if their content is text

[SylvainJuge]

I've researched a bit how we could prototype this:

• using a InstrumenterCustomizerProvider allows to add/remove attributes, so it could be used to add the body attribute to the request span
• we can easily add a custom extension to wrap the Servlet request before the generic servlet inrumentation, however this is not always the one creating the span, for example with tomcat.
• the InstrumenterCustomizerProvider is generic by default, thus we need to have heuristics applied for each instrumentation that creates spans in order to be able to access the actual request object in a type-safe way (for example: tomcat instrumentation is distinct from generic servlet span, so we need to have dedicated code for tomcat and maybe a few other containers)