KubeMQ
ConnectorsAMQP 1.0Reference

Connections & Observability

The AMQP 1.0 connector's observability surface — the connections/links detail endpoints, the 11 Prometheus metric families, the SSE group, and audit events.

This reference documents the AMQP 1.0 connector's observability surface: the HTTP detail endpoints, the 11 Prometheus metric families, the SSE metrics group, and the audit events the connector emits.

HTTP detail endpoints

The connector registers two read-only JSON routes on the internal API port (8080), network-protected like all /api/* routes. They are registered up front and nil-check the live provider, so they respond 200 with empty lists until the connector is wired (and even when AMQP 1.0 is disabled), returning 503 only while the API service is not yet ready.

Method & pathReturns
GET /api/amqp10/connections{ "connections": [Amqp10ConnectionDTO…], "total": <n> }
GET /api/amqp10/links{ "links": [Amqp10LinkDTO…], "total": <n> }

Amqp10ConnectionDTO

JSON fieldTypeMeaning
client_idstringauth ClientID, or the container-id when anonymous
container_idstringOPEN container-id (sanitized)
productstringfrom OPEN properties, if the client sent them
versionstringfrom OPEN properties, if sent
sessionsintlive sessions on the connection
linksintlive links across all sessions
connected_atstringRFC3339 timestamp
source_ipstringpeer IP
saslstringplain / anonymous / external / none
tlsboolTLS-terminated connection

Amqp10LinkDTO

JSON fieldTypeMeaning
client_idstringowning connection's ClientID
namestringpeer-assigned link name
rolestringsender / receiver (server perspective)
addressstringresolved terminus address
patternstringqueues / events / events-store / commands / queries / …
channelstringresolved KubeMQ channel
creditint64current link credit (server view)
unsettledint64deliveries awaiting settlement
durablebooldurable subscription link
dynamicbooldynamic-node terminus link

AMQP 1.0 has no exchange/binding topology, so there is no topology endpoint (unlike the AMQP 0-9-1 / RabbitMQ connector). The link list is the topology view.

Prometheus metrics — 11 families

The connector exposes 11 kubemq_amqp10_* metric families: 3 gauges + 8 counters. All are scraped from the standard KubeMQ metrics endpoint.

Gauges (3)

MetricLabelsMeaning
kubemq_amqp10_connectionscurrent open connector connections
kubemq_amqp10_sessionscurrent open connector sessions
kubemq_amqp10_linksrole (sender/receiver)current attached links by server role

Counters (8)

MetricLabelsMeaning
kubemq_amqp10_transfers_totaldirection (in/out), patterntransfers by direction and KubeMQ pattern
kubemq_amqp10_dispositions_totaloutcome (accepted/released/modified/rejected)terminal dispositions by outcome
kubemq_amqp10_rpc_requests_totalpattern (commands/queries)RPC requests routed through the connector
kubemq_amqp10_errors_totalscope (conn/session/link)connector error conditions by scope
kubemq_amqp10_transfers_in_dropped_totalinbound transfers dropped: oversize / no-consumer / pre-settled failure
kubemq_amqp10_events_dropped_no_credit_totalevents dropped on an outbound link with no credit (fire-hose semantics)
kubemq_amqp10_events_store_dropped_stalled_totalevents-store messages dropped when the credit-0 buffer stalled (link DETACH)
kubemq_amqp10_rpc_late_responses_totalRPC responses arriving after the requester went away

The two drop counters to watch

These are the connector's data-loss footgun signals — on a healthy producer/consumer they should stay at 0:

  • kubemq_amqp10_events_dropped_no_credit_total — increments every time the connector has an events/ message to deliver but the consumer link has zero credit. Events are at-most-once fire-hose: with no credit the message is silently dropped. Grant standing credit continuously.
  • kubemq_amqp10_events_store_dropped_stalled_total — increments when a durable events-store consumer stops granting credit and the credit-0 bounded buffer overflows, forcing a DETACH with lost messages. Replenish credit eagerly.

kubemq_amqp10_transfers_in_dropped_total covers three causes, not one. Its help text is "inbound AMQP 1.0 transfers dropped (oversize, no consumer, pre-settled failure)". It counts an oversize inbound transfer, a transfer with no consumer, and a pre-settled routing failure — do not read it as pre-settled-only.

SSE metrics group

The live dashboard streams a snapshot of these metrics as an api.Amqp10MetricsGroup over the metrics SSE channel. The store mirrors the same gauges and counters as the Prometheus families above (the store clamps gauges at 0 and the Prometheus mirror follows the clamp, so the two never diverge).

Audit events

The AMQP 1.0 connector emits exactly two audit events: auth.success and auth.failure. It does not emit client.connected or client.disconnected — those are not part of this connector's audit surface.

Both come from the SASL layer:

EventWhenFields
auth.successSASL outcome OKClientID, Transport: "amqp10", SourceIP, Metadata{mechanism}
auth.failureSASL rejectedClientID, Transport: "amqp10", SourceIP, Error (sanitized reason), Metadata{mechanism}

The mechanism metadata is plain / anonymous / external, and SourceIP is the peer IP. The full failure reason lives only in the auth.failure audit record — the SASL wire outcome carries the code alone (the no-leak rule; see Error Conditions).

To observe connection lifecycle (count, age, source IP, SASL mechanism), poll GET /api/amqp10/connections or scrape kubemq_amqp10_connectionsnot the audit log.

Was this page helpful?

On this page