apache/seatunnel · warning
Ignoring attempted add of a metric due to being null for nam
Error message
Ignoring attempted add of a metric due to being null for name {}. What it means
AbstractMetricsContext.addMetric guards against registering a null Metric instance. A null metric is rejected with a warning and not stored, so the named metric silently disappears from reports. This is a defensive check in the metrics registry: counter(name, ...) or meter(name, ...) was handed a null Metric object.
Source
Thrown at seatunnel-api/src/main/java/org/apache/seatunnel/api/common/metrics/AbstractMetricsContext.java:63
}
@Override
public Meter meter(String name) {
if (metrics.containsKey(name)) {
return (Meter) metrics.get(name);
}
return this.meter(name, new ThreadSafeQPSMeter(name));
}
@Override
public <M extends Meter> M meter(String name, M meter) {
this.addMetric(name, meter);
return meter;
}
protected void addMetric(String name, Metric metric) {
if (metric == null) {
log.warn("Ignoring attempted add of a metric due to being null for name {}.", name);
} else {
synchronized (this) {
Metric prior = this.metrics.put(name, metric);
if (prior != null) {
this.metrics.put(name, prior);
log.warn(
"Name collision: MetricsContext already contains a Metric with the name '"
+ name
+ "'. Metric will not be reported.");
}
}
}
}
@Override
public String toString() {
return "AbstractMetricsContext{" + "metrics=" + metrics + '}';
}View on GitHub (pinned to cf67b549a7)
Solutions
- Find where the null Metric is produced and initialize it before registering.
- Check that the underlying metric registry/backend is initialized before creating counters/meters.
- Guard the factory call: only call addMetric when the metric instance is non-null.
- Log at DEBUG which code path returns null and fix the provider.
Example fix
// before
Counter c = registry.counter(name); // may return null
metricsContext.addMetric(name, c);
// after
Counter c = registry.counter(name);
if (c != null) {
metricsContext.addMetric(name, c);
} Defensive patterns
Strategy: type-guard
Validate before calling
if (name == null || name.isEmpty()) throw new IllegalArgumentException("metric name required"); Type guard
if (metric == null) { LOG.warn("skipping null metric {}", name); return; } metricsContext.addMetric(name, metric); Try / catch
// not exception-based; guard inputs before addMetric
Prevention
- Never let metric factory methods return null; initialize registries first
- Null-check metrics before registration
- Add unit tests asserting metricsContext.counter(name) returns non-null
When it happens
Trigger: Calling addMetric(name, null) directly, or counter()/meter() factory methods that return null (e.g. a null-returning metric registry lookup) and then pass the result to addMetric.
Common situations: Custom metric registries or third-party metric backends (Prometheus/Dropwizard adapters) returning null for unregistered metrics; plugin code constructing metrics lazily and passing an uninitialized reference.
Related errors
- Name collision: MetricsContext already contains a Metric wit
- Collect realtime metrics failed
- splitId must not be null
- sourcePath is null
- ResultSet cannot be null
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/57a363d05b4bfb23.
Report an issue: GitHub.