Skip to content

AxonOps — AI-Native Control Plane for Open Source Data Platforms

Metrics Tables

The metrics virtual tables provide latency measurements, read statistics, and CQL-specific metrics for monitoring Cassandra performance.


These tables measure the full request lifecycle from the coordinator's perspective, including network time to replicas.

VIRTUAL TABLE system_views.coordinator_read_latency (
keyspace_name text,
table_name text,
count bigint,
max_ms double,
p50th_ms double,
p99th_ms double,
per_second double,
PRIMARY KEY ((keyspace_name, table_name))
)
ColumnTypeDescription
keyspace_nametextKeyspace name
table_nametextTable name
countbigintTotal read operations
p50th_msdoubleMedian latency (milliseconds)
p99th_msdouble99th percentile latency
max_msdoubleMaximum observed latency
per_seconddoubleCurrent operations per second

Example:

-- Find tables with high read latency
SELECT keyspace_name, table_name, p99th_ms, max_ms, per_second
FROM system_views.coordinator_read_latency
WHERE p99th_ms > 50;

Same schema as coordinator_read_latency, measuring write operations.

-- Read latency by table
SELECT keyspace_name, table_name, p99th_ms
FROM system_views.coordinator_read_latency
WHERE p99th_ms > 10;
-- Write latency by table
SELECT keyspace_name, table_name, p99th_ms
FROM system_views.coordinator_write_latency
WHERE p99th_ms > 10;

Same schema, measuring range scan operations (queries returning multiple rows).

-- Find tables with expensive scans
SELECT keyspace_name, table_name, p99th_ms, count
FROM system_views.coordinator_scan_latency
WHERE p99th_ms > 100;

These tables measure time spent on the local node only, excluding network overhead. Useful for isolating local vs network issues.

local_read_latency / local_write_latency / local_scan_latency

Section titled “local_read_latency / local_write_latency / local_scan_latency”

Same schema as coordinator tables, but measuring local processing time only.

-- Coordinator latency (includes network time)
SELECT keyspace_name, table_name, p99th_ms AS coordinator_p99
FROM system_views.coordinator_read_latency
WHERE p99th_ms > 20;
-- Local latency (local processing only)
SELECT keyspace_name, table_name, p99th_ms AS local_p99
FROM system_views.local_read_latency
WHERE p99th_ms > 20;
-- Compare results: if coordinator_p99 >> local_p99, network is the bottleneck

Interpretation:

ScenarioCoordinator p99Local p99Diagnosis
Both high100ms90msLocal disk/CPU issue
Coordinator high, local low100ms10msNetwork or remote replica issue
Both low5ms4msHealthy

Tracks how many rows are returned per read operation. High values may indicate inefficient queries or oversized partitions.

VIRTUAL TABLE system_views.rows_per_read (
keyspace_name text,
table_name text,
count bigint,
max double,
p50th double,
p99th double,
PRIMARY KEY ((keyspace_name, table_name))
)
ColumnTypeDescription
keyspace_nametextKeyspace name
table_nametextTable name
countbigintNumber of reads sampled
p50thdoubleMedian rows per read
p99thdouble99th percentile rows per read
maxdoubleMaximum rows in a single read

Example:

-- Find tables returning many rows per query
SELECT keyspace_name, table_name, p50th, p99th, max
FROM system_views.rows_per_read
WHERE max > 1000;

Warning thresholds:

MetricNormalWarningCritical
p50th< 100100-1000> 1000
p99th< 10001000-10000> 10000
max< 1000010000-100000> 100000

Tracks tombstone encounters during reads. High values indicate deletion patterns causing performance degradation.

VIRTUAL TABLE system_views.tombstones_per_read (
keyspace_name text,
table_name text,
count bigint,
max double,
p50th double,
p99th double,
PRIMARY KEY ((keyspace_name, table_name))
)
ColumnTypeDescription
keyspace_nametextKeyspace name
table_nametextTable name
countbigintNumber of reads sampled
p50thdoubleMedian tombstones per read
p99thdouble99th percentile tombstones
maxdoubleMaximum tombstones in a single read

Example:

-- Find tables with tombstone problems
SELECT keyspace_name, table_name, p50th, p99th, max
FROM system_views.tombstones_per_read
WHERE p99th > 100;

Tombstone Thresholds

MetricNormalWarningCritical
p50th< 1010-100> 100
p99th< 100100-1000> 1000
max< 10001000-10000> 10000 (may cause TombstoneOverwhelmingException)

Common causes of high tombstone counts:

  • Queue-like access patterns (insert, process, delete)
  • Wide partitions with range deletes
  • TTL expiration on many cells
  • Frequent null updates

Metrics specific to BATCH statement execution.

Deprecated in Cassandra 5.1

The system_views.batch_metrics table is deprecated since Cassandra 5.1 and will be removed in a future release. Use system_metrics.batch_group or system_metrics.type_histogram instead.

VIRTUAL TABLE system_views.batch_metrics (
name text PRIMARY KEY,
max bigint,
p50th double,
p999th double,
p99th double
)
Metric NameDescription
partitions_per_logged_batchPartitions touched per logged batch
partitions_per_unlogged_batchPartitions touched per unlogged batch
partitions_per_counter_batchPartitions touched per counter batch

Example:

SELECT name, p50th, p99th, max
FROM system_views.batch_metrics;
name | p50th | p99th | max
-------------------------------+-------+-------+-----
partitions_per_logged_batch | 1.0 | 3.0 | 15
partitions_per_unlogged_batch | 1.0 | 1.0 | 5
partitions_per_counter_batch | 1.0 | 1.0 | 2

Multi-Partition Batches

High partitions_per_logged_batch values indicate anti-pattern usage:

  • p99th > 5: Review batch usage patterns
  • max > 50: Likely misusing batches for bulk loading

See BATCH documentation for proper batch usage.


CQL layer metrics including prepared statement cache statistics.

Deprecated in Cassandra 5.1

The system_views.cql_metrics table is deprecated since Cassandra 5.1 and will be removed in a future release. Use system_metrics.cql_group instead.

VIRTUAL TABLE system_views.cql_metrics (
name text PRIMARY KEY,
value double
)
Metric NameDescription
prepared_statements_countNumber of prepared statements in cache
prepared_statements_evictedPrepared statements evicted from cache
prepared_statements_executedTotal prepared statement executions
regular_statements_executedTotal non-prepared statement executions
prepared_statements_ratioRatio of prepared to total statements

Example:

SELECT name, value FROM system_views.cql_metrics;
name | value
-------------------------------+------------
prepared_statements_count | 1247
prepared_statements_evicted | 23
prepared_statements_executed | 987654321
regular_statements_executed | 12345
prepared_statements_ratio | 0.999987

Prepared Statement Best Practices

MetricHealthyWarning
prepared_statements_ratio> 0.95< 0.90
prepared_statements_evictedLow/stableGrowing rapidly

Low ratio indicates applications not using prepared statements—causes:

  • Higher CPU usage for query parsing
  • Larger network payloads
  • No query plan caching benefits

-- Read latency overview
SELECT keyspace_name, table_name, count, p50th_ms, p99th_ms, per_second
FROM system_views.coordinator_read_latency
WHERE per_second > 0;
-- Write latency overview
SELECT keyspace_name, table_name, count, p50th_ms, p99th_ms, per_second
FROM system_views.coordinator_write_latency
WHERE per_second > 0;
-- Scan latency overview
SELECT keyspace_name, table_name, count, p50th_ms, p99th_ms, per_second
FROM system_views.coordinator_scan_latency
WHERE per_second > 0;
-- Alert: High read latency
SELECT keyspace_name, table_name, p99th_ms
FROM system_views.coordinator_read_latency
WHERE p99th_ms > 100;
-- Alert: Tombstone accumulation
SELECT keyspace_name, table_name, p99th, max
FROM system_views.tombstones_per_read
WHERE p99th > 500;
-- Alert: Poor prepared statement usage
SELECT name, value
FROM system_views.cql_metrics
WHERE name = 'prepared_statements_ratio'
AND value < 0.90;