# Observability (/connectors/concepts/observability)
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 [#overview]
Every gateway on the [shared HTTP server](/connectors/concepts/shared-http-server) shares one observability story. CloudEvents is documented here under Connectors; the AI gateways — [A2A and MCP](/aiway) — 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 [#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 [#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:
```bash
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](/operate/observability/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 [#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-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 |
```bash
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](/operate/observability/api-reference/dashboard-endpoints). Per-agent stats are populated from the same counters that feed `kubemq_a2a_requests_total`.
## Related [#related]