Observability and OpenTelemetry
Note
OpenTelemetry export is opt-in and disabled by default. No telemetry leaves your deployment until you configure an OTLP endpoint, such as a collector or a compatible vendor service.
Introduction
XMPro products emit telemetry using OpenTelemetry, the vendor-neutral standard for traces, metrics, and logs. Each product exports over the OpenTelemetry Protocol (OTLP) to an endpoint that you nominate, which can be a collector you run or a vendor service that accepts OTLP directly. This means you can send XMPro telemetry to the observability backend you already operate, rather than one XMPro chooses on your behalf.
This section explains what each XMPro service emits, how to enable the export, and how to interpret the signals once they arrive. We'll cover the instrumented services, the three signal types, how OpenTelemetry relates to the Azure monitoring that Terraform deployments already configure, and what trace coverage currently extends to.
Instrumented Services
Six services emit telemetry. Each carries its own service.name, which is the resource attribute you filter on when building dashboards and alerts:
| Service | service.name |
|---|---|
| App Designer | xmpro.app_designer |
| Data Stream Designer | xmpro.data_stream_designer |
| Subscription Manager | xmpro.subscription_manager |
| Identity Server | xmpro.identity_server |
| XMPro AI | xmpro.ai_designer |
| Stream Host | xmpro.stream_host |
Subscription Manager and Identity Server are instrumented independently even though they are deployed alongside each other, so both appear in your backend as separate services.
Note
Identity Server exports traces and logs only. It does not emit metrics, so it will not appear in runtime, process, or request metric dashboards. Every other service emits all three signal types.
What XMPro Emits
All three OpenTelemetry signal types are exported to the same OTLP endpoint.
Traces: Incoming HTTP requests, outbound HTTP calls, SQL queries, and Entity Framework Core operations are captured automatically. Stream Host adds spans for its own stream and agent lifecycle operations. Utility endpoints such as /health and /version are excluded from traces by default so they don't dominate your trace volume.
Metrics: .NET runtime and process metrics (garbage collection, thread pool, CPU, and memory), HTTP client metrics, and ASP.NET Core request metrics. Stream Host adds 19 instruments covering stream throughput, agent activity, record counts, and host liveness. Identity Server is the exception and emits no metrics.
Logs: Structured log events, exported through Serilog's OTLP sink. When a log event is written inside an active trace, it carries the trace and span identifiers automatically, so your backend can correlate a log line back to the request that produced it.
A detailed per-product telemetry contract, listing every metric, span, and attribute with its stability classification, is planned for a future release.
Relationship to Azure Application Insights
OpenTelemetry export is additive. It does not replace the monitoring your deployment already configures for you.
An Azure Kubernetes (AKS) deployment provisions Log Analytics and an Application Insights connection as part of the cluster, and those remain available whether or not you enable OpenTelemetry. Enabling OpenTelemetry gives you a second, portable export path alongside them. You can run both, or use OpenTelemetry on its own if you prefer to consolidate telemetry from XMPro and your other systems in one backend.
This matters most in two situations:
- You already run an observability stack such as Grafana, Datadog, or Splunk, and want XMPro telemetry in the same place as everything else.
- You deploy on AWS Kubernetes (EKS), where the Azure-native monitoring services are not available.
Trace Coverage
Traces cover operations performed by the XMPro services themselves. This includes Stream Host operations such as starting and stopping a stream, and agent lifecycle events recorded by the host.
Note
Currently, agents loaded by Stream Host configure their own telemetry pipeline, so work performed inside an agent is not emitted as a child span of the host operation that triggered it. Per-agent trace correlation will be added in a future release.
To attribute activity to a specific agent in the meantime, use the Stream Host agent metrics together with the xmpro.agent.* attributes attached to them.
Where to Go Next
- Configure OpenTelemetry covers the configuration keys, activation requirements, and per-deployment setup.
- Exporting to a Backend shows a worked collector configuration and notes for common backends.
- XMPro Log Events documents the individual log events each product writes.
Summary
XMPro exports traces, metrics, and structured logs over OTLP from six independently identified services, using OpenTelemetry so that the choice of backend stays yours. Export is off until you configure an endpoint, and it runs alongside the Azure-native monitoring that Terraform deployments already provide rather than replacing it. Start with Configure OpenTelemetry to enable it, then Exporting to a Backend to route the signals to your observability stack.
Last modified: September 28, 2026