NATS monitoring is a distinct problem from general infrastructure monitoring. nats-server exposes a rich HTTP monitoring API on port 8222 (varz, connz, routez, subsz, gatewayz, leafz, healthz, jsz, accountz) plus a system-account event stream. A collector that does not understand those endpoints gives you a fraction of the picture. The most common buying mistake is assuming a general-purpose APM or a default Prometheus scrape delivers NATS depth. In practice, most general tools stop at varz-level counters, while JetStream stream and consumer health, per-account usage, and gateway and leaf-node topology need a collector built for NATS semantics.
Three dimensions decide most outcomes:
- Metric depth. Does the tool cover more than basic varz counters? JetStream streams and consumers, per-account metrics, routes, gateways, leaf nodes, and connection-level pending bytes are what separate a real NATS monitor from a checkbox integration.
- Collection resolution. NATS is a high-throughput messaging system. Message-rate spikes and slow-consumer buildup happen in seconds, so a 10 to 15 second polling interval routinely misses the incident you are trying to explain.
- Time to value and cost shape. Auto-detection and prebuilt content beat a stack you wire together yourself, and per-host pricing punishes the many-small-nodes deployment pattern NATS fleets tend to follow.
A note on pricing: we do not quote competitor list prices in this guide. List prices for usage-based platforms are almost meaningless without knowing your ingestion volume, retention, and seat count, and quoting them out of context misleads more than it informs. Instead, each card describes the pricing shape and what makes the bill grow, with a link to the vendor’s own pricing page.
If you are still building your runbooks, our NATS monitoring guides walk through the operational side: which endpoints matter, how to read slow-consumer signals, and how to structure alerts for JetStream.