For APM auto-instrumentation, is there a way to capture the full request paths (ie. /home/login.do , /home/search.do) and to disable normalization (ie. /home/*.do)

[PsychicMushrooms]

Is there a system property for JAVA auto-instrumentation, or .NET, to not allow spans to be normalized (eg. /home/*.do) and instead capture the full request path such as these:

/home/login.do
/home/search.do

[dmathieu]

This doesn't look like a collector issue. You should ask this question directly in the SDK's repository.
https://github.com/open-telemetry/opentelemetry-java
https://github.com/open-telemetry/opentelemetry-dotnet

[Cloud-Architect-Emma]

To add to @dmathieu's pointer, for Java auto-instrumentation specifically,
the URL normalization (e.g. /home/*.do) is controlled by the instrumentation
library, not the collector. You can disable or customize it using:

• OTEL_INSTRUMENTATION_HTTP_SERVER_ACTIVE_REQUESTS_DURATION_BUCKETS
  not directly relevant, but shows the level of control available
• For servlet-based apps, set the system property:
  otel.instrumentation.servlet.experimental.capture-request-parameters=true
• To retain full paths, look at:
  otel.instrumentation.http.server.captured-request-headers

The most direct solution is to use the otel.java.experimental.http-server-metric-attributes.set
system property or configure the http.server.request.duration metric attributes
in your instrumentation config to include the full path.

For .NET, the equivalent is configuring the OTEL_DOTNET_EXPERIMENTAL_ASPNETCORE_DISABLE_URL_QUERY_REDACTION
environment variable, and path normalization can be influenced via the
RoutePattern attribute.

Best bet: ask specifically in https://github.com/open-telemetry/opentelemetry-java-instrumentation
for Java, or https://github.com/open-telemetry/opentelemetry-dotnet for .NET,
as @dmathieu suggested, the instrumentation maintainers there will know the
exact current property names.

[s3onghyun]

That normalized value is the http.route (the matched route template), and it is used deliberately to keep span names low-cardinality. For HTTP server spans the name is {method} {http.route}, e.g. GET /home/*.do, so the route is in the name on purpose. There is no flag to make the raw concrete path the span name, and you generally would not want it there since it would explode cardinality.

The full concrete path is already captured, just as an attribute rather than the span name. Under current stable HTTP semconv that is url.path (plus url.query, and url.full on client spans); the older 1.x names were http.target / http.url. So aggregate and filter on url.path, not on the span name.

If a backend really must show the full path as the span name, rewrite it in the Collector with the transform processor (OTTL):

processors:
  transform:
    error_mode: ignore
    trace_statements:
      - set(span.name, span.attributes["url.path"]) where span.attributes["url.path"] != nil

Nothing needs to be un-normalized at the instrumentation level.