Apache Cassandra Monitoring: Key Metrics, Tools, and Best Practices

With Cassandra’s masterless ring, you can keep a cluster serving reads and writes while individual nodes drop out. To monitor that resilience, you need visibility beyond any single node because every node collects only its own metrics, and a slow replica, compaction backlog, or long garbage collection pause can surface as client timeouts somewhere else.

This guide covers the Cassandra metrics you should track, the Java Management Extensions (JMX) and OpenTelemetry paths that expose them, and the monitoring tools and alerting practices that help you detect degradation before clients do.

What Is Apache Cassandra Monitoring?

Apache Cassandra monitoring, or Cassandra cluster monitoring, is the practice of tracking performance metrics, system health, and resource utilization across every node in a cluster so you can catch degradation before clients do.

Cassandra manages its metrics with the Dropwizard Metrics library, which exposes them as JMX managed beans (MBeans) or virtual tables and can push them to external systems through built-in reporters.

Relational monitoring habits transfer poorly because Cassandra adds multi-master replication with tunable consistency, hinted handoff, background compaction of Sorted String Tables (SSTables), and gossip-based failure detection. A dashboard that ignores those mechanisms can report a healthy node while replicas diverge.

Why Monitoring Cassandra Is Uniquely Challenging

Attributing latency requires comparing coordinator and local metrics across nodes because a slow coordinator can hide a replica-level problem. In the documented read path, the coordinator sends a request to a replica and can retry against another replica when the first fails to respond in time. The client sees a slow coordinator even when the real cause is a replica stalled on garbage collection or buried in compaction.

Cassandra latency metrics split coordinator-level CoordinatorReadLatency from local ReadLatency, which lets you compare both views.

Collecting many metrics on each node also carries a cost, and that cost compounds nonlinearly during failures. In a long stop-the-world pause, the Java Virtual Machine (JVM) cannot gossip. Peers mark the node down and start storing hints while clients time out and retry elsewhere. When the pause ends, the node absorbs hint replay plus redirected traffic, which can trigger the next full collection.

Key Cassandra Metrics to Track

The Cassandra metrics documentation covers the MBeans below but doesn’t provide numeric thresholds for these examples. Vendor and operator figures can serve as starting points, but you should calibrate them against your workload.

Start with performance metrics, then connect them to resource pressure and Cassandra-specific internal work.

Performance Metrics

Cassandra exposes client performance metrics under type=ClientRequest. Read and write latency come from the scope=Read,name=Latency and scope=Write,name=Latency Timers, which carry mean, p50, p95, p99, and p999 attributes. The same scope exposes Timeouts and Unavailables counters.

Reads usually run slower than writes because they touch more I/O, and a frequently updated row spreads across several SSTables. A p99 far above p50 commonly traces to garbage collection pauses, disk saturation, or hot partitions.

Use workload baselines to set read and write warning levels rather than applying the same threshold to every table. The Timer’s OneMinuteRate attribute gives coordinator reads or writes per second, your baseline for Cassandra Query Language (CQL) throughput.

Resource Utilization Metrics

Resource monitoring should connect JVM pressure, CPU load, disk capacity, and thread-pool saturation. Track these resource signals together:

• Heap and garbage collection: Cassandra heap memory monitoring starts with the JVM’s memory and garbage collection metrics exposed over JMX. Sustained post-collection heap pressure or pauses that interrupt gossip warrant attention because long pauses trigger the failure spiral described above.
• CPU distribution: CPU above 80% on most nodes means overload, which clients see as timeouts, while high CPU on only a few nodes points at a hot partition or uneven load.
• Disk and compaction: Disk needs headroom because compaction can’t run without free space. A rising per-table LiveSSTableCount with slowing reads and a growing compaction backlog means compaction is falling behind; climbing SSTables with a healthy backlog usually point to a compaction strategy mismatch.
• Thread pools: Prioritize Cassandra thread pool metrics PendingTasks and TotalBlockedTasks in MutationStage, ReadStage, Native-Transport-Requests, and CompactionExecutor. Blocked tasks in the first two mean the node has already rejected or timed out client requests.

Together, these signals show when general resource pressure has started affecting Cassandra’s internal work.

Cassandra-Specific Metrics

Cassandra-specific metrics expose queued work, expired messages, replica communication, repair progress, and table behavior. Use the following groups to interpret that internal activity:

• Compaction backlog: The type=Compaction,name=PendingTasks gauge estimates queued work, and a steadily climbing count indicates that processing capacity isn’t keeping up. Read performance can degrade as the number of SSTables per read rises.
• Dropped messages: A Dropped meter tracks each message type, including MUTATION, READ, and HINT. Dropped messages signal a serious problem because they have already exceeded their configured timeout.
• Hints and repair: Hint metrics (TotalHints and TotalHintsInProgress under Storage, plus HintsSucceeded and HintsFailed under HintsService) show replicas failing to acknowledge each other. The PercentRepaired and BytesUnrepaired metrics track repair per table.
• Table and storage signals: No documented metric covers replication strategy, though a managed-service console can add an indicator. Per-table TombstoneScannedHistogram, the tombstones-to-live-cells ratio, EstimatedPartitionSizeHistogram, CommitLog, Storage, Client, and SSTable Index metrics round out the set.

Collecting these internal signals requires a path from Cassandra’s MBeans to your monitoring backend.

How Cassandra Exposes Metrics

JMX is the default and oldest path for Cassandra JMX monitoring. Any JMX client can read the MBeans above, which is how nodetool, JConsole, and the Prometheus JMX exporter all work.

nodetool is the operator’s quick check, with tpstats for thread pools, compactionstats for the backlog, and status for ring health, though it gives snapshots rather than trends. JMX polling slows as table counts and metric volume rise.

Dropwizard reporters offer a second path. Configured through metrics-reporter-config, they push metrics to Graphite or another backend from inside the Cassandra process without a JMX client in the loop.

OpenTelemetry is the third path, and it changed shape in 2026. The project deprecated the Collector’s JMX receiver on 2026-01-30, and later removed it in v0.157.0, because the receiver spawned a Java subprocess inside Collector images that ship no Java runtime.

Its replacement, the standalone JMX Scraper, runs as its own process, keeps the same target_system values including cassandra, and exports over the OpenTelemetry Protocol (OTLP). The Scraper still reads MBeans over remote JMX, so the polling cost applies. The gain is a vendor-neutral pipeline that carries Cassandra metrics next to logs and traces.

Apache Cassandra Monitoring Tools

Most options below read the same MBeans. They differ in what sits next to the Cassandra data. Some provide direct troubleshooting, while others retain trends or correlate telemetry.

Compare the operational models and adjacent capabilities before choosing:

• DataStax OpsCenter: Visual management, monitoring, and provisioning for DataStax Enterprise (DSE). Current releases support only DSE clusters, so teams on Apache Cassandra need something else.
• Prometheus and Grafana: The self-managed standard, fed by the JMX exporter or Instaclustr’s cassandra-exporter on each node, with community dashboards for both. You run the exporters, scrape configuration, and storage.
• JConsole and VisualVM: Direct JMX browsers for ad hoc incident troubleshooting, with no fleet-wide trends. Run JConsole remotely so it doesn’t load the node.
• Dynatrace: A JMX extension that auto-discovers Cassandra through OneAgent and reports thread pools, compaction, cache hit rates, and live SSTable count. It suits teams tracing application dependencies on the database.
• ManageEngine Applications Manager: A centralized console over JMX or Prometheus covering thread pools, dropped messages by type, and per-table storage. Capacity planning from pending-task trends suits ops-heavy teams without a dedicated site reliability engineering (SRE) practice.
• Nagios and Icinga: Threshold checks that call nodetool over the JMX port for node count, token balance, heap, and keyspace replication. They fit shops already running either scheduler.
• Instaclustr managed service: Collects metrics for clusters it runs and exposes a curated set through a Prometheus-format application programming interface (API).
• Full-stack observability tools, including Coralogix: Accept OTLP and Prometheus remote-write, the outputs of the JMX Scraper and Prometheus exporters. Cassandra metrics can then sit beside logs and traces in full-stack observability.

OpsCenter fits DSE, while Prometheus and Grafana suit teams that run their own stack. OTLP-based tools fit teams consolidating telemetry. Your choice depends on whether you want direct JMX troubleshooting, a self-managed metrics stack, or correlated logs, metrics, and traces.

Best Practices for Apache Cassandra Monitoring

Per-table visibility and alerts you can act on provide the most durable defense against Cassandra latency incidents. In one reported case on Cassandra 4.0.7 with a replication factor of five, reads at consistency level ONE against certain partitions fanned out to at least three replicas through speculative retry, and once those partitions got hot, the cluster pegged CPU, drove up latency, and threw timeouts.

A per-table SpeculativeRetries count climbing alongside CoordinatorReadLatency on the affected table would have shown those extra replica reads. Before raising read_request_timeout, you should check garbage collection times and review the data model for inefficient access patterns.

Apply that guidance through the following monitoring practices:

• Define healthy per workload before setting thresholds: Read-heavy tables are best judged on p99 read latency, cache hit rate, and SSTables per read, and write-heavy tables on write latency, pending compactions, and MemtableFlushWriter pending tasks.
• Monitor at the table level, not only the node: The special table all aggregates across keyspaces, but a hot table only appears in per-table SSTablesPerReadHistogram, EstimatedPartitionSizeHistogram, and CoordinatorReadLatency.
• Layer alerts by what you can act on: Treat heap, CPU, and disk as early warnings, and pending compactions and dropped messages as act-now signals. Alerting on every MBean breeds alert fatigue, and the actionable alerts get ignored.
• Alert on tombstone warnings: TombstoneWarnings gives advance notice of a bad deletion pattern before reads hit the failure threshold, which defaults to 100,000 tombstones, and throw TombstoneOverwhelmingException.
• Keep repair status on the dashboard: Hints are best effort, and repair doesn’t run automatically, which means deleted data can reappear if gc_grace_seconds expires before a repair covers it. Track PercentRepaired per table and repair well inside each gc_grace_seconds window, such as weekly with the default 10 days.
• Correlate with application traces: Drivers set their own timeouts, and when the client gives up first, the server keeps working on an abandoned request. Distributed tracing next to the coordinator-versus-local latency split shows which side timed out.

Start with per-table p99 latency and pending-compaction alerts on your busiest tables. Pair those alerts with repair, tombstone, and thread-pool views that explain why latency changed. Revisit the thresholds as workloads, schemas, and compaction strategies change.

Bring Cassandra Metrics into One Backend with Coralogix

Cassandra monitoring works across three layers. Performance covers p99 latency and CQL throughput, resource telemetry covers heap, CPU, disk, and garbage collection, and Cassandra internals cover compaction, dropped messages, and hinted handoff. Acting on any of those metrics from the JMX Scraper or a Prometheus exporter is faster when the same incident’s application traces and node logs sit next to them.

Coralogix ingests Cassandra metrics through OpenTelemetry-native ingestion or Prometheus Remote Write, and DataPrime queries those metrics in the same language as the logs and traces you need for the correlation.

Unlimited retention in your own cloud bucket keeps the long-term latency and SSTable trends that nodetool snapshots can’t show, and ingestion-based pricing with no per-host fees means adding nodes to the ring doesn’t add host charges. Remote Write points at your region’s Coralogix endpoint and authenticates with a Send-Your-Data API key.

You can compare coordinator latency, replica logs, and application traces side by side with a free 14-day Coralogix trial, with no credit card required. Send your Cassandra telemetry through OTLP from the JMX Scraper or Prometheus Remote Write from your exporter.

Frequently Asked Questions About Apache Cassandra Monitoring

These questions cover production adoption, threshold reviews, monitoring tradeoffs, and Kubernetes deployments. They also clarify how Cassandra’s distributed design changes the signals you need to collect. Use the answers to connect cluster-level symptoms with node and table metrics.

Is Apache Cassandra still widely used in production?

Yes. Apple, Netflix, and Uber are among its named adopters, and the Apache Software Foundation continues to develop the project. Maintenance releases continue on the 5.0, 4.1, and 4.0 lines.

Does Netflix still use Cassandra?

Netflix runs user sign-ups and viewing histories on Cassandra behind its key-value abstraction layer. In July 2026, dynamic partition splitting on its time-series abstraction reduced seconds-long reads to millisecond latency.

What are the biggest disadvantages of Cassandra from a monitoring perspective?

Cassandra has no central coordinator, so each node collects its own metrics, and you have to aggregate them externally. Eventual consistency can make expected replication lag look like divergence; PercentRepaired and repair-session state help tell the two apart. Reading the metrics has its own cost because JMX polling time grows with table count.

How often should Cassandra monitoring thresholds be reviewed?

Thresholds need a fresh look whenever the workload changes: a new table, a schema migration, or a compaction strategy switch all move what normal looks like for SSTable counts and latency. A quarterly review of thresholds, dashboards, and unused metrics is a reasonable floor for stable clusters, plus a post-incident check for monitoring gaps. Use each review to retire alerts that no longer lead to an operator action.

How is monitoring Cassandra in Kubernetes different from bare-metal or VM deployments?

Pod Internet Protocol (IP) addresses change on rescheduling, so static IP-based JMX targets break, and K8ssandra discovers pods through Prometheus Operator ServiceMonitor label selectors. The host resource metrics move from the Cassandra agent to node_exporter or a Vector sidecar, the same host signals general Kubernetes monitoring tracks. Cassandra still reports LiveDiskSpaceUsed and LiveSSTableCount per table per pod.