KubeMQ
OperateObservability

Observability

Monitor KubeMQ end to end — Prometheus metrics, OpenTelemetry tracing, structured logs, an audit trail, the dashboard, and the management API on port 8080.

KubeMQ reports on itself across several complementary surfaces. An always-on Prometheus exporter, opt-in OpenTelemetry traces and metrics, structured JSON logs, a CloudEvents audit trail, a built-in web dashboard, and an HTTP/WebSocket management API all expose what the server is doing right now and what it has done. This section is the operator's home for monitoring KubeMQ in production — how to scrape metrics, wire up tracing, read the logs, query the audit log, and consume the management API.

Each surface answers a different question: Prometheus metrics give you the quantitative time series, tracing shows you the path of a single message across patterns, logs and the audit trail record discrete events, the dashboard renders the live picture, and the management API is the programmatic interface behind it all.

The observability surfaces

SurfaceWhat it gives youWhere it's servedAlways-on?
Prometheus metricsCounters, gauges, and histograms for every messaging pattern, queues, RPC latency, cluster health, and the agent platformGET /metrics (:8080)Yes
OpenTelemetry tracingDistributed traces and OTel metrics over OTLP to Jaeger, Grafana Tempo, or DatadogOTLP export to an external collectorNo (opt-in)
Structured loggingJSON log lines on stdout — levels, the field set, and trace correlationstdoutYes
Audit loggingA CloudEvents v1.0 trail of auth, lifecycle, and data-plane error eventsGET /api/v1/audit (:8080)Yes
Built-in dashboardA live web view of channels, clients, queues, the patterns, cluster topology, and agents:8080Yes
Management APIThe HTTP and WebSocket interface for health, stats, snapshots, audit query, and dashboard actions:8080Yes

Push vs pull

KubeMQ uses a pull-first model for metrics and a push-first model for traces, and the two can run at the same time. Logs are written to stdout and captured by your runtime.

SignalModelConsumer
Prometheus metricsPull — Prometheus scrapes GET /metrics on demandPrometheus / Grafana
Dashboard snapshotsPull — the dashboard polls the snapshot endpointsBuilt-in dashboard
OpenTelemetry tracesPush — the OTLP exporter pushes to a collectorJaeger / Tempo / Datadog
OpenTelemetry metricsPush — the meter provider exports periodicallyOTLP-compatible metrics backend
Audit eventsPull — the REST query APIOperator / SIEM
LogsPush — JSON written to stdout, captured by the runtimeLog aggregator (Loki, Splunk, etc.)

The Prometheus exporter always runs — it also powers the built-in dashboard. OpenTelemetry is opt-in and is enabled through the telemetry settings.

Where each surface is served

The management API port (:8080) is the same in-process port that serves the dashboard, the metrics endpoint, the stats and snapshot endpoints, and the audit query API. When control-plane auth is enabled, every endpoint below requires at least the ReadOnly role.

SurfaceEndpointAccess (control-plane auth on)
Prometheus scrapeGET /metrics (:8080)ReadOnly+
Dashboard snapshotsGET /api/snapshot, GET /api/cluster-snapshotReadOnly+
Audit queryGET /api/v1/audit, GET /api/v1/audit/statsReadOnly+
Channel and client statsGET /v1/stats/channels, GET /v1/stats/clientsReadOnly+
Live message monitorWebSocket /api/monitorReadOnly+
Real-time cluster streamWebSocket /api/connectionReadOnly+
Billing summaryGET /billingReadOnly+
OTLP exportOTLP gRPC (:4317) or HTTP (:4318) to an external collectorCollector-side
Application logsstdout (JSON)

Start here

Configure it

Where the settings live

The raw configuration keys for telemetry, audit, and server-event notifications — with their Docker and Helm naming, defaults, and valid values — live in the Observability settings reference. That page is the source of truth for the settings; this section covers the concepts, how-to, and the full management API.

Was this page helpful?

On this page