.NET AutoInstrumentation Disparity - Metrics vs Traces

[Huckletoon]

Hey all,

We've been seeing some odd behaviors in our .NET CORE applications on Linux that are being auto-instrumented. There is a disparity between the HTTP request telemetry; in some cases, the OTel SDK is producing metrics for routes that we are not able to see Trace spans for. On rare occasions, it's the other way around - some routes produce traces, but not metrics.

We suspect there may be some conflict with some of these applications also performing some manual instrumentation, or perhaps there's some difference in how the auto-instrumentation detects and registers activities. However, we're at a loss of where to continue looking - could someone please provide some ideas on things to check?

Attempted Triaging

We've ran the auto-instrumentation with debug env vars enabled for one of our applications. This application has 3 endpoints: GET /health, GET /swagger/v1/swagger.json, and POST /api/messages. Traces and metrics are generated for the first two, but traces are missing for /api/messages. No errors are thrown, nothing seems out of the ordinary, and the tracer reportedly started without issue - however, we observed no reference in the logs to the last endpoint.

Desired Behavior

For a given auto-instrumented application, HTTP Request telemetry should be generating identical Trace spans and Metrics for the same routes.

[Kielek]

@Huckletoon, could you please provide Minimal, Reproducible Example?
It will be easier to start investigation.

Blind shot - it is possible, that it can be treated as GET or GET /api/{somethingHere} or simlar, low cardinality pattern.

[pjanotti]

SIG: closing per lack of activity