apache/cassandra · error · RuntimeException
Unknown metric
Error message
Unknown metric
What it means
This generic metric lookup (the mymetricname special-case handler) only recognizes a fixed set of metric names; anything else reaches the fallback throw new RuntimeException("Unknown metric " + metricName). It signals the caller asked for a metric this accessor does not support.
Solutions
- Use one of the explicitly supported metric names for this method.
- Call the type-specific accessor (getStorageMetric, getCompactionMetric, getTableMetric) that matches the metric's type instead.
- Extend the method's switch to map the desired metric and rebuild the tools jar.
- Inspect the JMX tree directly (e.g. via jconsole) to confirm the metric exists, then choose the right accessor.
Example fix
// before
probe.getMetric("SomeUnmappedMetric"); // unknown
// after
probe.getStorageMetric("SomeUnmappedMetric"); // use the matching accessor Defensive patterns
Strategy: try-catch
Validate before calling
if (!SUPPORTED_METRICS.contains(metricName))
throw new IllegalArgumentException("Metric not supported by this accessor: " + metricName); Try / catch
try {
return probe.getMetric(metricName);
} catch (RuntimeException e) {
if (String.valueOf(e.getMessage()).startsWith("Unknown metric"))
throw new IllegalArgumentException("Unsupported metric " + metricName + "; use a type-specific accessor", e);
throw e;
} Prevention
- Do not assume the method is a generic pass-through to any metric
- Match the metric's JMX type to the right NodeProbe accessor
- Confirm the metric exists via jconsole/JMX dump before scripting
- Extend the switch and rebuild the tools jar if you need new mappings
When it happens
Trigger: Calling the generic per-type metric getter with a name not handled by any of its branches — the name may exist in JMX but is not mapped by this NodeProbe method.
Common situations: Users assuming the method is a generic pass-through to any Cassandra metric; metric renamed between versions; copying examples for a different accessor (table vs storage vs generic).
Understand the failure class
Background: Invalid enum value errors: "Unknown type", "Invalid scope", "must be one of" — when a string is not on the library's allowed list — this error's family across 23 libraries.
Related errors
- Unknown client metric
- Unknown compaction metric
- appendAll() can only be called on non-frozen collections
- Can not initialize cluster with empty cluster identifier
- Can't abort bootstrap for - it does not exist in cluster…
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/516b45418ef2bd59.
Report an issue: GitHub.
Appendix: source
Thrown at src/java/org/apache/cassandra/tools/NodeProbe.java:2346
new ObjectName("org.apache.cassandra.metrics:type=CIDRGroupsMappingCache,name=" + metricName),
CassandraMetricsRegistry.JmxCounterMBean.class).getCount();
case CIDRAuthorizerMetrics.CIDR_GROUPS_CACHE_RELOAD_LATENCY:
case CIDRAuthorizerMetrics.LOOKUP_CIDR_GROUPS_FOR_IP_LATENCY:
return JMX.newMBeanProxy(
mbeanServerConn,
new ObjectName("org.apache.cassandra.metrics:type=CIDRGroupsMappingCache,name=" + metricName),
CassandraMetricsRegistry.JmxTimerMBean.class).getMean();
default:
if (metricName.contains(CIDRAuthorizerMetrics.CIDR_ACCESSES_REJECTED_COUNT_PREFIX) ||
metricName.contains(CIDRAuthorizerMetrics.CIDR_ACCESSES_ACCEPTED_COUNT_PREFIX))
{
return JMX.newMBeanProxy(
mbeanServerConn,
new ObjectName("org.apache.cassandra.metrics:type=mymetricname,name=" + metricName),
CassandraMetricsRegistry.JmxCounterMBean.class).getCount();
}
throw new RuntimeException("Unknown metric " + metricName);
}
}
catch (MalformedObjectNameException e)
{
throw new RuntimeException(e);
}
}
public Map<String, Long> getCountsMetricsFromVtable()
{
return cfmProxy.getCountsMetricsFromVtable();
}
public Map<String, List<Double>> getLatenciesMetricsFromVtable()
{
return cfmProxy.getLatenciesMetricsFromVtable();
}
View on GitHub (pinned to 88fd0f6a0e)