Datadog Cassandra Metric Gaps in the Default Integration
In the Cassandra Monitoring Tools Comparison 2026, I looked at the choice between a Cassandra-focused operations platform, a self-managed Prometheus stack, and broad observability products such as Datadog. This article goes one level deeper into Datadog’s shipped Cassandra integration.
The distinction is worth making because “Datadog can collect Cassandra metrics” is true, but incomplete. A default integration is a starting point, not a description of every JMX metric that Cassandra can publish. Datadog’s Cassandra check is useful for local read and write latency, disk consumption, basic table health, selected thread-pool queues, dropped messages, commit log size, and node availability. Datadog also has host metrics and standard JVM telemetry alongside this Cassandra-specific mapping.
That is enough to answer a sensible first question: are reads slow, are writes slow, and is a node filling its disks? It is not enough to diagnose many of the incidents Cassandra operators spend their time on. Repair progress, hint delivery, streaming, unavailable errors, compaction pressure, internode queues, and client connection health are not in the default collection set.
At a glance, the gap between Datadog’s default mapping and Cassandra’s available telemetry looks like this. Cassandra begins with its node-level metric families, then expands per keyspace, table, and peer. The table count alone changes the scale quickly: 60 user tables expose more than 6,900 table metric names on each node before attributes, percentiles, keyspace rollups, or per-peer metrics are included.
| Figure | What it shows |
|---|---|
| 72 | Distinct cassandra.* metric names in Datadog's published Cassandra catalogue. |
| ~7 | Cassandra JMX metric families addressed by the default mapping, out of roughly 30 families Cassandra 4.1 and 5.0 publish. |
| 115+ | Metric names Cassandra 5.0 exposes for every table, before attributes, percentiles, or dimensions are selected. |
| 6,900+ | Table metric names Cassandra publishes on one node with 60 user tables, before attributes, percentiles, keyspace rollups, or per-peer metrics. |
| 350 | Datadog's standard per-node metric collection ceiling, before a support exception is needed; it does not cover Cassandra's full metric output. |
These are not metrics that Datadog cannot ingest. They are metrics that are not collected by the shipped Cassandra configuration, and the 350-metrics-per-instance limit makes collecting all of them impractical on a table-heavy cluster.
This review is based on Datadog’s current metrics.yaml and metric catalogue, read on 3 September 2026, against the Apache Cassandra 4.1 and 5.0 metric references. The configuration can change, so check the version installed with your Agent before making a production decision.
Datadog Default Metrics
The shipped Cassandra metric configuration has a deliberately narrow shape. At table level it collects local ReadLatency and WriteLatency percentiles, request rates, SSTable counts, disk usage, pending compactions, flush counts, tombstones scanned, SSTables per read, partition-size information, and a few cache and compression values. It excludes the Cassandra system keyspaces from that table-level collection.
At node level it includes selected request and internal thread-pool queues, dropped-message rates, storage exceptions, commit log size and pending tasks, key-cache hit rate, a cluster member count from the failure detector, and a small number of garbage-collection counters. A separate cassandra_nodetool integration can add nodetool status-style node state and ownership gauges.
This is a competent default for a general observability platform. It does not need to be dismissed to explain where it stops. The useful operational question is what you can see after an alert has fired, and what you still need to collect or investigate elsewhere.
Datadog Metric Gaps
The tables below distinguish between metrics that are absent from the shipped configuration, areas where only part of the relevant data is collected, and the smaller set that is adequately covered for the stated question. The metric names are Cassandra JMX names, not proposed Datadog dashboard names.
Repair, hints, streaming, and read repair
| Operational question | Default status | Cassandra metrics not collected by default |
|---|---|---|
| Is data repaired, pending repair, or unrepaired? | Absent | Table PercentRepaired, BytesRepaired, BytesUnrepaired, BytesPendingRepair |
| Are repair jobs progressing or failing? | Absent | RepairJobsStarted, RepairJobsCompleted, RepairTime, RepairPrepareTime, RepairSyncTime, ValidationTime, AnticompactionTime, BytesValidated, PartitionsValidated; Storage:RepairExceptions; Repair retry and preview-failure metrics |
| Are hints accumulating or being delivered? | Absent | Storage:TotalHints, Storage:TotalHintsInProgress; HintsService:HintsSucceeded, HintsFailed, HintsTimedOut, and delay metrics |
| Is bootstrap, rebuild, decommission, or repair streaming underway? | Absent | Streaming:IncomingBytes, OutgoingBytes per peer; TotalIncomingBytes, TotalOutgoingBytes, TotalOutgoingRepairBytes, IncomingProcessTime |
| Are repair-side thread pools saturated? | Absent | AntiEntropyStage, ValidationExecutor, CompactionExecutor, Repair-Task, RepairJobTask, StreamReceiveTask, PaxosRepairStage |
| Is read repair firing or timing out? | Absent | ReadRepair:Attempted, RepairedBlocking, RepairedBackground, RepairTimedOut, SpeculatedRead, SpeculatedWrite; table read-repair request and inconsistency metrics |
Request outcomes and latency detail
| Operational question | Default status | Cassandra metrics not collected by default |
|---|---|---|
| Are requests failing or unavailable? | Absent | ClientRequest:Failures, Unavailables across all scopes; Cassandra 5.0 TombstoneAborts and ReadSizeAborts |
| Which consistency level is degraded? | Absent | ClientRequest read and write scopes per consistency level, including LOCAL_QUORUM, EACH_QUORUM, and ONE |
| Is coordinator latency different from replica-local latency? | Absent | Table CoordinatorReadLatency, CoordinatorWriteLatency, CoordinatorScanLatency |
| Is the tail moving beyond p99? | Partial | Max, 999thPercentile, Mean, and total-latency counters; p99 is collected only for table read and write latency |
| Is LWT contention increasing? | Partial | ContentionHistogram, ConditionNotMet, UnfinishedCommit, UnknownResult, and Paxos:LinearizabilityViolations |
| Are materialized-view writes healthy? | Partial | ViewReplicasAttempted, ViewReplicasSuccess, ViewPendingMutations, and view write timeout and failure metrics |
| Are local read and write request rates available? | Covered | OneMinuteRate is collected from the relevant latency MBeans |
Compaction, cache, memtable, and commit log detail
| Operational question | Default status | Cassandra metrics not collected by default |
|---|---|---|
| Is compaction keeping up? | Partial | Compaction:PendingTasks, PendingTasksByTableName, CompletedTasks, TotalCompactionsCompleted, BytesCompacted, CompactionsAborted, CompactionsReduced, SSTablesDroppedFromCompaction; the compaction executor pool |
| Is the chunk cache helping the read path? | Absent | Cache scoped to ChunkCache: Hits, Misses, Requests, HitRate, Capacity, Size, Entries, MissLatency |
| Are key, row, and counter caches correctly sized? | Partial | Cache capacity, size, entries, requests, and 1/5/15-minute hit rates; the complete CounterCache family |
| Is memtable pressure building? | Partial | MemtableOnHeapDataSize, MemtableOffHeapDataSize, MemtableLiveDataSize, MemtableSwitchCount, MemtableColumnsCount, AllMemtables*; MemtablePool:BlockedOnAllocation, PendingFlushTasks |
| Is the commit log causing stalls? | Partial | WaitingOnCommit, WaitingOnSegmentAllocation, CompletedTasks, OverSizedMutations |
| Do SSTable shape and compaction state point to a problem? | Partial | EstimatedPartitionCount, UnleveledSSTables, MinPartitionSize, OldVersionSSTableCount, MaxSSTableSize, MaxSSTableDuration, EstimatedPartitionSizeHistogram, SSTableCountPerLevel |
| Is off-heap usage rising through filters and indexes? | Partial | BloomFilterFalsePositives, BloomFilterDiskSpaceUsed, BloomFilterOffHeapMemoryUsed, IndexSummaryOffHeapMemoryUsed, CompressionMetadataOffHeapMemoryUsed |
| Is speculative retry doing useful work or adding load? | Absent | Table SpeculativeRetries, SpeculativeFailedRetries, SpeculativeInsufficientReplicas, AdditionalWrites |
| Is direct-memory or networking buffer pressure visible? | Absent | BufferPool size, used size, capacity, hits, misses, and overflow size for chunk-cache and networking pools |
Internode communication
| Operational question | Default status | Cassandra metrics not collected by default |
|---|---|---|
| Are internode queues backing up, and towards which peer? | Absent | Per-peer Connection metrics for large, small, and urgent message pending tasks and bytes, completed tasks and bytes, drops due to timeout, overload, and error, plus timeouts |
| Is inbound messaging seeing corruption, throttling, or expiry? | Absent | InboundConnection:CorruptFramesRecovered, CorruptFramesUnrecovered, ErrorBytes, ErrorCount, ExpiredBytes, ExpiredCount, ThrottledCount, ThrottledNanos, ProcessedBytes, ScheduledBytes |
| Is cross-node or cross-datacentre latency increasing? | Absent | Messaging:CrossNodeLatency, per-datacentre latency, and per-verb wait latency |
| What caused dropped messages? | Partial | Drop Count, internal and cross-node dropped latency; the default keeps only the one-minute rate |
| Is gossip healthy beyond up/down member counts? | Partial | Failure-detector phi values and simple states, Gossiper state, and the GossipStage pool |
| Is the dynamic snitch penalising replicas? | Absent | DynamicEndpointSnitch:Scores and Severity |
Client, CQL, and workload behaviour
| Operational question | Default status | Cassandra metrics not collected by default |
|---|---|---|
| How many native clients are connected, and under which protocol or user? | Absent | Client:connectedNativeClients, connectedNativeClientsByUser, clientsByProtocolVersion, connections |
| Are authentication failures or protocol errors increasing? | Absent | Client:AuthSuccess, AuthFailure, ProtocolException, UnknownException |
| Is native transport saturated or shedding requests? | Absent | Transport ThreadPools metrics for Native-Transport-Requests; Client:PausedConnections, RequestDiscarded, TimedOutBeforeProcessing, Queued |
| Is the prepared-statement cache thrashing? | Absent | CQL:PreparedStatementsCount, PreparedStatementsEvicted, PreparedStatementsExecuted, RegularStatementsExecuted, PreparedStatementsRatio |
| What is the client request and response volume? | Absent | ClientMessageSize bytes sent and received; ClientRequestSize rows and columns read and written |
| Are oversized batches appearing? | Absent | Batch:PartitionsPerLoggedBatch, PartitionsPerUnloggedBatch, PartitionsPerCounterBatch |
| Are query guardrails warning or aborting work? | Partial | Tombstone, read-size, row-index-size, and live-scanned warning and abort metrics; the default has tombstone-scan percentiles only |
JVM and node state
| Operational question | Default status | Detail |
|---|---|---|
| Are heap, file descriptors, and thread counts available? | Covered | Datadog collects standard JVM memory, file-descriptor, thread, and buffer metrics |
| Is G1 major-GC activity reported correctly? | Requires verification | The configuration names G1 Mixed Generation; standard HotSpot exposes G1 Old Generation, so test the reported counter on the JVM in use |
| Can pause distribution, allocation rate, or safepoint time be diagnosed? | Absent | The default has cumulative GC count and time, not per-pause duration, allocation rate, promotion, evacuation failure, or safepoint data |
| Are keyspace-level Cassandra rollups available? | Absent | The Keyspace metric family, including WriteFailedIdealCL and IdealCLWriteLatency |
| Can system keyspace and node lifecycle state be inspected? | Absent | System keyspaces are excluded from table collection; StorageService operation mode, bootstrap state, joining/leaving/moving nodes, schema-version state, and related data are not collected |
| Are Storage-Attached Indexes visible in Cassandra 5.0? | Absent | StorageAttachedIndex query timeouts, builds in progress, disk usage, query latency, and memtable index flush errors |
| Are host CPU, disk, and network available? | Covered | Datadog host metrics provide this independently of the Cassandra metric mapping |
Missing Anti-Entropy Metrics
The repair, hints, streaming, and read-repair rows above are the most consequential omissions. The default check does not collect any of those families.
These are not edge cases. A Cassandra cluster can continue serving traffic while hints grow, a repair falls behind, or streaming work changes the I/O and network profile of a node. Local read latency and disk usage alone do not explain that state.
Repair also needs more than a chart of counters. Scheduling, completion history, range selection, failures, and the relationship between repair and cluster load are operational state rather than a small group of JMX metrics. A generic metric collector does not provide that workflow by itself, even when its JMX configuration has been expanded.
Request Failure and Unavailable Metrics
Datadog collects Timeouts for the read and write ClientRequest scopes. It does not collect Failures or Unavailables by default.
That distinction changes how an incident is understood. A timeout indicates that the coordinator did not receive the required responses before the deadline. An unavailable exception tells you that the coordinator could already see that the consistency level could not be met. A failure can point to replica-side errors, overloaded resources, or request processing problems. An application team experiences all three as failed work, but the next diagnostic step is different for each one.
The default configuration also does not break request outcomes down by consistency level. If LOCAL_QUORUM requests are failing in one datacentre while ONE requests continue to work, a cluster-wide latency or timeout view will not show that split. Cassandra exposes the relevant scopes over JMX; they need deliberate selection and tagging before they become useful in Datadog.
There is a related limitation in the latency data. Table read and write metrics include p75, p95, and p99, while many of the other latency families stop at p75 and p95. The shipped check does not request maximum latency, p99.9, total-latency counters, or a full coordinator-versus-replica view. That is enough for a broad health view, but it leaves less evidence when a small group of requests is driving the complaint.
Missing Latency Metrics
When an alert says read latency has moved, the useful question is which part of the database changed at the same time. These are the four diagnostic paths an operator normally needs to compare.
| Diagnostic path | Metrics to compare | Default coverage |
|---|---|---|
| Compaction | Queue depth, completed tasks, bytes compacted, aborted work, and the compaction executor show whether the storage engine is falling behind. | Partial: per-table pending compactions and bytes written only |
| Write path | Memtable memory, allocation blocking, commit-log waits, segment allocation, and oversized mutations separate a full write path from a slow coordinator. | Partial: pending flushes and total commit-log size only |
| Read path | Chunk-cache activity, filter effectiveness, index-summary memory, and compression metadata help explain why reads are now doing more work. | Partial: key-cache hit rate and selected table metrics only |
| Replica path | Per-peer queues, message timeouts, cross-node latency, and replica-local metrics test whether the coordinator is waiting elsewhere. | Absent: not collected |
None of these signals proves a root cause on its own. Together, they let an operator test the most likely Cassandra explanations while the event is still occurring, rather than switching between ad hoc JMX queries, nodetool, logs, and guesswork.
Missing Internode and Client Metrics
The default check has one dropped-message rate by verb. It does not provide enough detail to identify where traffic is queuing, whether a peer is overloaded, or whether a client workload is producing the pressure.
| Diagnostic path | Metrics to compare | Default coverage |
|---|---|---|
| Peer queues | Large, small, and urgent connection queues, bytes in flight, and drops by timeout, overload, or error identify the affected peer. | Absent: not collected |
| Network transit | Cross-node, per-datacentre, and per-verb wait latency separates a local processing issue from an internode path problem. | Absent: not collected |
| Native transport | Connection counts, authentication failures, protocol errors, transport queues, discarded requests, and pre-processing timeouts describe client pressure. | Absent: not collected |
| CQL behaviour | Prepared-statement evictions, executions, ratios, batch-size histograms, guardrail warnings, and SAI metrics expose query patterns that a basic dashboard cannot. | Absent: not collected |
For Cassandra 5.0 users, the same gap includes Storage-Attached Index build progress, query timeouts, disk usage, and flush errors. Tombstone-scan percentiles are included, while warnings and aborts for tombstones, read size, row-index size, and related query controls are not.
Datadog Metric Limit
Datadog documents a standard ceiling of 350 metrics per instance for its Cassandra integration, with support engagement required for a higher limit.
The table metrics in Cassandra are multiplied by keyspace and table. Per-peer connection and streaming metrics multiply by node. Consistency-level request metrics multiply again. Cassandra 5.0 exposes more than 115 metric names per table before choosing attributes and dimensions. A cluster with dozens of tables can use the available budget quickly if every percentile, cache metric, thread pool, and request scope is included.
Adding everything also creates an operational cost: more cardinality to manage, more dashboards and alert rules to maintain, and potentially more custom-metric cost. The answer is not to leave the defaults untouched; it is to select metrics around the failure modes that are relevant to the cluster.
A practical first configuration tranche is usually made of low-cardinality, cluster-level signals:
jmx_metrics:
# Error outcomes in addition to latency and timeouts
- include:
domain: org.apache.cassandra.metrics
type: ClientRequest
name: [Failures, Unavailables]
attribute: [Count, OneMinuteRate]
# Hints and compaction backlog
- include:
domain: org.apache.cassandra.metrics
type: Storage
name: [TotalHints, TotalHintsInProgress]
- include:
domain: org.apache.cassandra.metrics
type: Compaction
name: [PendingTasks, CompletedTasks, BytesCompacted]
# Streaming and native transport pressure
- include:
domain: org.apache.cassandra.metrics
type: Streaming
name: [TotalIncomingBytes, TotalOutgoingBytes]
attribute: [Count]
- include:
domain: org.apache.cassandra.metrics
type: ThreadPools
path: transport
name: [ActiveTasks, PendingTasks, CurrentlyBlockedTasks]Treat that as a starting point to validate against your Cassandra and Agent versions, not a configuration to copy blindly. Review the resulting metric count and tags before rolling it across every node. The next tier, including per-table repair state, per-peer connection queues, and consistency-level request data, needs a hard budget and an explicit decision about how those metrics will be used.
There is also one small JVM detail worth checking in a live environment. Datadog’s current configuration names G1 Mixed Generation as a major collector. Standard HotSpot exposes G1 collectors as G1 Young Generation and G1 Old Generation; if the collector name does not match the JVM, the reported major-GC counter will not be populated. Test the metric on the Java build running Cassandra rather than assuming the dashboard is correct.
AxonOps Cassandra Monitoring
Datadog’s default Cassandra integration can show that reads or writes are slow, or that a node is filling its disks. From that data alone, it cannot reliably distinguish compaction pressure, memtable or commit-log stalls, repair or streaming activity, peer queue buildup, unavailable errors, consistency-level degradation, or native-transport pressure. The diagnosis has to be completed elsewhere with JMX queries, nodetool, logs, and local scripts.
Someone then has to choose the additional MBeans, stay within the metric ceiling, decide which dimensions are worth collecting, define tags, build dashboards, write alerts, connect them to runbooks, and keep the configuration aligned with Cassandra releases and changing workloads.
AxonOps starts with the Cassandra operating questions in this article. It can collect tens of thousands of Cassandra metrics from each node, alongside repair progress and history, backup status, service checks, logs, configuration, nodetool activity, and Cassandra-specific alerts. The dashboards are organised around the database state being investigated: repair, compaction, request path, table, node, or backup. The volume of collected data does not become one generic dashboard for an operator to work through.
AxonOps AI is trained using Cassandra source code, Cassandra documentation, and Cassandra operational best practices. It can assess the metrics alongside logs, events, configuration, and operational history. That lets an engineer examine a latency change, failed request, repair concern, or cluster-health issue with the related Cassandra context available together, rather than trying to reconstruct it across separate tools.
See Apache Cassandra Monitoring for the AxonOps monitoring model. For the wider product comparison, see Cassandra Monitoring Tools Comparison 2026.