Skip to main content
airmux records operational metrics through OpenTelemetry. Each process defaults its service.name to airmux-control-plane or airmux-data-plane; set OTEL_SERVICE_NAME to override it.

Export metrics with OTLP

Set these variables on each process to send metrics to an OpenTelemetry Collector or another OTLP-compatible backend:
OTLP export is disabled unless OTEL_METRICS_EXPORTER includes otlp. The exporter also honors standard OTLP headers, certificate, timeout, compression, and periodic export interval variables.

Scrape with Prometheus

Each standalone control-plane and data-plane listener exposes unauthenticated Prometheus metrics at /metrics. The all-in-one public listener does not proxy this path. Scrape the internal listeners from a monitoring network:
Do not expose either metrics endpoint to the public internet. Metrics omit organization, workspace, user, request, bundle, model, and provider identifiers. Request metrics use bounded dimensions such as route, dialect, stream mode, outcome, status class, and provider family.

Monitor the control plane

The publication-age gauge resets to zero after restart. The pending count comes from durable state and is the authoritative backlog size.

Monitor the data plane

Set alerts

Alert on sustained changes rather than a single failed request. Useful starting signals include:
  • Readiness returning 503
  • Growing bundle publication backlog or age
  • bundle_manifest_rejected remaining 1, or rejected and failed bundle polls increasing
  • metering_admission_total increasing for full or closed
  • Growing metering outbox count or oldest-event age
  • Failed metering exports or credential backend failures
  • Sustained increases in failed HTTP requests or upstream attempts
Choose thresholds based on normal traffic and polling intervals for your deployment.