apm-agent-java
apm-agent-java copied to clipboard
Allow setting user_agent
Is your feature request related to a problem?
user_agent
is a standard transaction field, but I can't set it via the public API: https://www.elastic.co/guide/en/apm/server/current/exported-fields-apm-transaction.html#_user_agent_4
Describe the solution you'd like
Transaction transaction = ElasticApm.currentTransaction();
transaction.setUserAgent(...);
Describe alternatives you've considered
I'm not aware of any alternatives right now, except for #433, but that's still open, too.
Hi @kelunik,
In general we are not planning on extending the public API further, because we want to go with the OpenTelemetry-API as preferred option. We of course will continue to support the public API.
However, our OpenTelemetry API bridge also does not support overriding the built-in fields yet. This is something we eventually want to support, but it is not yet on our near term road map.
The user_agent
data you are referring to is generated as follows:
- The APM-agent captures the HTTP-headers (but doesn't do any special handling of
user_agent
there) - The APM-server copies the value from
http.request.headers.User-Agent
intouser_agent.original
- the APM traces ingest-pipeline takes care of parsing the value and generating the other
user_agent.*
fields
I can suggest you to try the following workaround for now:
- Capture your override for user_agent as a normal label via the public API
- Add a custom ingest pipeline for moving the value from your custom label into
user_agent.original
- Your custom ingest pipeline will have to redo the parsing and generation of the other
user_agent.*
fields, but you should be able to copy that from the standard APM ingest pipeline
We also would be willing to accept a PR for adding a Transaction.setHeader()
method to the public-API, though es explained earlier we would prefer to not extend it, as we'll have to continue to support it.
* The APM-server copies the value from `http.request.headers.User-Agent` into `user_agent.original`
That's good to know. Currently we have capture_headers
disabled for the service in question. Does that copy work in an case-insensitive way?
I can suggest you to try the following workaround for now:
* Capture your override for user_agent as a normal label via the public API * Add a [custom ingest pipeline](https://www.elastic.co/guide/en/apm/guide/current/ingest-pipelines.html#custom-ingest-pipelines) for moving the value from your custom label into `user_agent.original` * Your custom ingest pipeline will have to redo the parsing and generation of the other `user_agent.*` fields, but you should be able to copy that from the standard APM ingest pipeline
We also would be willing to accept a PR for adding a
Transaction.setHeader()
method to the public-API, though es explained earlier we would prefer to not extend it, as we'll have to continue to support it.
This sounds like a few too many custom steps IMO, so I'd prefer to work on a PR. It should probably be Transaction.addHeader()
instead of Transaction.setHeader()
?
Does that copy work in an case-insensitive way?
Yes, if you look at the extracted headers it just extracts the strings as they are
It should probably be
Transaction.addHeader()
instead ofTransaction.setHeader()
?
I think setting the header is right rather than appending. Since this would be for customized values, it should be entirely defined by the passed value