KubeMQ
ConnectorsConcepts

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/metrics

The 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):

MethodPathDescription
GET/api/agentsList registered agents with pagination
GET/api/agents/:idAgent detail plus a stats snapshot
curl http://localhost:8080/api/agents

The 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.

Was this page helpful?

On this page