Claus Ibsen created CAMEL-26490:
-----------------------------------
Summary: camel-telemetry - the http.url, url.path and
server.address span attributes should be presented like camel.uri
Key: CAMEL-26490
URL: https://issues.apache.org/jira/browse/CAMEL-26490
Project: Camel
Issue Type: Bug
Components: camel-telemetry, camel-tracing
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Fix For: 4.24.0, 4.22.3, 4.18.6
When a span starts, the span decorators of camel-telemetry and camel-tracing
set three attributes from the endpoint in a different form than {{camel.uri}},
which is presented the way {{Endpoint.toString()}} presents the endpoint URI.
*http.url*
When the exchange has neither a {{CamelHttpUrl}} nor a {{CamelHttpUri}} header
(for example a route that starts from a timer, a JMS queue or a file, or one
that removes the inbound {{CamelHttp*}} headers before it calls a service),
{{AbstractHttpSpanDecorator.getHttpURL}} takes {{http.url}} from the endpoint
URI, from the last occurrence of {{http:}} onwards. That value is not the URL
of the request:
* for camel-http and camel-vertx-http it includes all the Camel endpoint
options (such as {{connectTimeout}} or {{throwExceptionOnFailure}}), which are
Camel configuration and are not sent to the server
* for camel-vertx-http with an https address the value starts with
{{http://https://}}
* for camel-http with an https address the attribute is not set at all
*url.path and server.address*
{{AbstractSpanDecorator}} takes {{url.path}} from the raw endpoint URI, so for
an endpoint URI with user info the path starts with the user info and the host.
It takes {{server.address}} from {{EndpointServiceLocation.getServiceUrl()}} as
is.
The same code is in camel-tracing ({{org.apache.camel.tracing.decorators}}) and
camel-telemetry ({{org.apache.camel.telemetry.decorators}}), used by
camel-opentelemetry, camel-observation, camel-opentelemetry2 and
camel-micrometer-observability.
h3. Expected behaviour
* {{http.url}} is the HTTP address of the request, without the Camel endpoint
options.
* {{url.path}} is the path without the user info.
* All three are presented the same way as {{camel.uri}}.
h3. Proposed change
In both modules:
* {{AbstractHttpSpanDecorator.getHttpURL}}: keep the precedence (the
{{CamelHttpUrl}} header, then the {{CamelHttpUri}} header). Replace the
endpoint URI fallback: when the endpoint implements {{EndpointServiceLocation}}
and its service URL starts with {{http://}} or {{https://}}, use it (the
address the producer calls). Otherwise take the endpoint URI, strip a leading
component scheme ({{netty-http:}}, {{vertx-http:}}, {{undertow:}}) so it starts
at {{http://}} or {{https://}}, and drop the endpoint query.
* {{AbstractSpanDecorator}}: build {{url.path}} without the user info, and set
{{server.address}} as {{URISupport.sanitizeUri}} presents it.
* Present {{http.url}} (also when it comes from the headers) as
{{URISupport.sanitizeUri}} does for {{camel.uri}}.
h3. Tests
In the decorator tests of camel-telemetry and camel-tracing:
*
{{http://localhost:8080/test?connectTimeout=5000&throwExceptionOnFailure=false}}
gives {{http://localhost:8080/test}}
* {{vertx-http://https://localhost:8443/test?connectTimeout=5000}} gives
{{https://localhost:8443/test}}
* an endpoint that implements {{EndpointServiceLocation}} with service URL
{{https://localhost:8443/test?q=1}} gives that URL
* the https endpoint case sets {{http.url}} in {{beforeTracingEvent}}
* {{netty-http:http://...}} still gives {{http://...}}
* {{url.path}} of an endpoint URI with user info is the path only, and
{{server.address}} is presented as {{camel.uri}} is
* fix the existing header tests: they stub {{getHeader(name, String.class)}}
while the code calls {{getHeader(name)}}, so they currently pass through the
endpoint fallback
Upgrade guide: {{http.url}} without the HTTP headers is now the HTTP address
without the endpoint options, and is now also set for camel-http https
endpoints; {{url.path}} no longer includes the user info and host. Dashboards
or queries keyed on the old values may need a change.
_Filed by Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
