Prometheus NATS exporter

A messaging system needs monitoring beyond whether its process is running: operators may need to see connections, routes and message-stream behavior. The NATS Prometheus Exporter reads selected NATS monitoring endpoints and combines their measurements into an endpoint Prometheus can scrape. It helps bring broker observations into shared dashboards and alerts. Collection should cover the intended servers and message entities, and both the NATS monitoring interface and the exporter endpoint need their own network and access controls.

Current guidance

Current upstream supports selected HTTP monitoring endpoints such as server, connection, route and JetStream observations. It also identifies NATS Surveyor as a different approach using a System account, so the two should be evaluated by collection architecture rather than treated as identical chart names.

Decide whether metrics need to describe individual servers, accounts, streams or consumers. Detailed connection and JetStream labels can grow quickly and disclose operational identifiers. Keep NATS monitoring interfaces on a controlled network: the monitoring port is unauthenticated by default. The exporter’s http_user and http_pass options protect Prometheus scrapes of the exporter; they do not add authentication to the NATS server’s monitoring port. Configure TLS and access controls for each exposed endpoint, and ensure scrape discovery reaches the intended servers instead of repeatedly sampling only one service endpoint.

When replacing the historical exporter, inventory endpoint flags, metric prefixes, scrape labels and dashboards. Validate counts with a small known publication/subscription workload and, where relevant, a JetStream stream and consumer. Check how missing servers and denied monitoring access appear in alerts. A healthy exporter process alone cannot establish message durability or consumer progress; neither was tested as part of this source review.