Change the HTTP Request default span name

[aguimaraes]

Is your feature request related to a problem? Please describe. Most of our HTTP requests coming from outside the perimeter are going through an API Gateway. Since the default HTTP request instrumentation uses the schema <method> <host> to name spans, we end up with multiple calls like GET api.example.com without being able to easily differentiate between the different endpoints we are calling. When we need to quickly identify a problem with individual calls, it becomes hard exercise quickly.

Describe the solution you'd like I would like to be able to change the default span name for HTTP requests on initialisation time using an environment variable or a php.ini param.

Describe alternatives you've considered We could also change the default schema to use <method> <path> instead and we would start to see: GET api.example.com/user/333.

Additional context Current Spec suggests the same naming schema: https://github.com/elastic/apm/blob/main/specs/agents/tracing-instrumentation-http.md

[intuibase]

Hey @aguimaraes

For transactions (incoming http requests) we're using path as transaction name For outgoing spans (like curl requests) we using method and host as a span name

Could you please clarify what you would like to see in span and transaction name?

Regards, Pawel

[aguimaraes]

hey @intuibase, thank you for the reply. I want to be able to change the default name with an environment variable. e.g. I would like to add the path for the outgoing spans since everything goes to an API gateway and every request looks the same.

[SergeyKleyman]

Hi @aguimaraes

For now we don't have such feature planned near term but as a potential workaround we can propose transforming data with custom ingest pipelines. Spans for outgoing HTTP requests have URL in their context so it can be used to create a new name.

In the future we plan to allow registering a span processors (as PHP callable-s) at agent level that will allow modifying spans before they sent out - will this approach be useful to you?

[aguimaraes]

yes @SergeyKleyman, the future approach would work perfectly for our use case. Thanks for the workaround suggestion too! Have a great day!