Observability
Prometheus metrics, OpenTelemetry tracing, and the AI dashboard shared by KubeMQ's HTTP gateways — CloudEvents, plus A2A and MCP (documented under Aiway).
The connectors emit Prometheus metrics and OpenTelemetry traces on the same observability surface as the rest of kubemq-server, plus a dedicated AI dashboard for agents and MCP — so you watch connector traffic with the tools you already run.
Overview
Every gateway on the shared HTTP server shares one observability story. CloudEvents is documented here under Connectors; the AI gateways — A2A and MCP — are documented under Aiway, but they run on the same server and report through this same surface:
- Prometheus metrics for A2A requests, MCP tool calls, registry operations, and active SSE streams, scraped from the management API port (
:8080). - OpenTelemetry tracing for every HTTP request through the connector middleware chain.
- A web AI dashboard (Agents and MCP) that reads cluster-aggregated metrics.
No extra configuration turns connector telemetry on — it follows the server's existing metrics and tracing setup.
How it works
Connectors record metrics inline as they handle requests; the metrics exporter publishes them on the management API port (:8080) for Prometheus to scrape, while the dashboard reads the same data through the internal API.
Connectors report metrics to the exporter on the management API port (:8080); Prometheus scrapes it and the AI dashboard reads the internal API.
Prometheus metrics
Connector metrics are exposed on the management API port (:8080) at /metrics, alongside the core KubeMQ messaging metrics. Scrape it the same way:
curl http://localhost:8080/metricsThe connectors emit kubemq_mcp_* and kubemq_a2a_* series; the full series — names, types, and labels — is documented in Observability → Prometheus Metrics.
The A2A method label is sanitized against a fixed allowlist of known A2A methods. Any unrecognized method is recorded as unknown so a malformed or malicious request stream cannot explode Prometheus label cardinality.
In a cluster, these counters are aggregated across all nodes so the totals you see reflect the whole deployment rather than a single replica.
OpenTelemetry tracing
Every request that enters the shared HTTP server passes through OpenTelemetry instrumentation in the middleware chain, traced under the service name kubemq-http. When tracing is enabled on the server, connector requests appear in your traces automatically — there is nothing connector-specific to configure.
The AI dashboard
The KubeMQ web dashboard includes an AI area for the agent platform:
- Agents — every registered agent and its live request stats (total requests, errors, average latency, last-seen time).
- MCP — tool usage drawn from the MCP metrics above.
The dashboard reads from an internal management API on the management API port (:8080):
| Method | Path | Description |
|---|---|---|
GET | /api/agents | List registered agents with pagination |
GET | /api/agents/:id | Agent detail plus a stats snapshot |
curl http://localhost:8080/api/agentsThe full /api/agents and /api/agents/:id reference — parameters, response envelope, and stats fields — is documented in Observability → Dashboard Endpoints. Per-agent stats are populated from the same counters that feed kubemq_a2a_requests_total.
Related
Was this page helpful?
Connectors
KubeMQ's built-in protocol gateways — CloudEvents on the shared HTTP server, plus AMQP, RabbitMQ, AWS, MQTT, STOMP, and GCP wire-protocol connectors.
Shared HTTP Server
One HTTP server on port 9090 fronts every connector — its middleware chain, the enable model, and reserved channel prefixes.