.NET OpenTelemetry troubleshooting

Work through the .NET-specific checks below first, then the shared checks at the bottom.

Custom spans or metrics never appear

The tracer and meter providers only collect from sources you register. A custom ActivitySource whose name was never passed to AddSource, or a Meter never passed to AddMeter, produces no data and reports no error.

• Confirm the name in AddSource("MyCompany.MyApp") matches the string passed to new ActivitySource("MyCompany.MyApp") exactly, including case.
• Confirm the same for AddMeter and the Meter name.
• Confirm you used the null-conditional operator on the activity (activity?.SetTag(...)); StartActivity returns null when the source is not registered, and a plain activity.SetTag would throw.

See custom instrumentation for the full registration pattern.

No data under IIS, but it works under Kestrel

With in-process hosting, the ASP.NET Core Module runs the worker inside the IIS process, so environment variables set in a shell do not reach the application.

• Set OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_HEADERS, OTEL_SERVICE_NAME, and OTEL_RESOURCE_ATTRIBUTES in web.config under <aspNetCore><environmentVariables>, or on the IIS application pool.
• Recycle the application pool after changing web.config so the worker picks up the new values.
• Standalone Kestrel reads the process environment directly; if it works under Kestrel but not IIS, the cause is almost always the environment variables not reaching the IIS worker.

Note

service.environment is set only from OTEL_RESOURCE_ATTRIBUTES, not from ASPNETCORE_ENVIRONMENT. If the environment shown in Osuite is wrong, check that attribute.

Exporter cannot connect

If the SDK is configured but no telemetry reaches Osuite, the OTLP export is failing.

• Confirm OTEL_EXPORTER_OTLP_ENDPOINT includes the https:// scheme and the :443 port, for example https://ingest.<region>.osuite.io:443. A missing scheme causes the exporter to fail to build the request.
• The .NET SDK OTLP exporter defaults to gRPC. If your network only allows HTTP, set OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf. The automatic instrumentation defaults to http/protobuf; set OTEL_EXPORTER_OTLP_PROTOCOL=grpc if you need gRPC there. The endpoint is the same for both.
• Confirm OTEL_EXPORTER_OTLP_HEADERS is exactly x-osuite-ingest-token=<your-ingest-token> with no quotes in the value.

Enabling diagnostic output

• SDK in code — enable self-diagnostics by placing an OTEL_DIAGNOSTICS.json file next to the application binary. It logs exporter and SDK errors to a file, which surfaces export failures that are otherwise silent.
• Automatic instrumentation — set OTEL_DOTNET_AUTO_LOG_DIRECTORY to a writable path and check the logs there. If no logs are written, the CLR profiler did not attach — confirm you sourced instrument.sh (Linux/macOS) or ran Register-OpenTelemetryForCurrentSession (Windows) in the same session that starts the app.

Standard checks

No data in Osuite after a few minutes? Work through these checks.

• Endpoint — confirm the exporter targets exactly ingest.<region>.osuite.io:443 for your region, over TLS.
• Token — confirm the ingest header carries a valid <your-ingest-token> and has not been rotated.
• Pipeline — confirm the signal you expect (traces, logs, or metrics) is wired into an active pipeline with the otlp/osuite exporter attached.
• Export errors — check the application or Collector logs for OTLP export failures (auth, DNS, TLS, connection refused).
• Network — confirm the host has outbound access to the ingest endpoint on port 443.
• Timing — allow up to a minute for the first data to appear before assuming a failure.

Still stuck? Ask the Investigation Agent or contact support.