grafana/k6 · error
metric %q is not a counter
Error message
metric %q is not a counter
What it means
The OTel registry found a cached instrument under this metric name, but its stored dynamic type is not Float64Counter — a different metric kind (histogram/gauge) already claimed the same name in the counters map.
Source
Thrown at internal/output/opentelemetry/registry.go:36
histograms sync.Map
rateCounters sync.Map
}
// newRegistry creates a new registry.
func newRegistry(meter otelMetric.Meter, logger logrus.FieldLogger) *registry {
return ®istry{
meter: meter,
logger: logger,
}
}
func (r *registry) getOrCreateCounter(name, unit string) (otelMetric.Float64Counter, error) {
if counter, ok := r.counters.Load(name); ok {
if v, ok := counter.(otelMetric.Float64Counter); ok {
return v, nil
}
return nil, fmt.Errorf("metric %q is not a counter", name)
}
opts := []otelMetric.Float64CounterOption{}
if unit != "" {
opts = append(opts, otelMetric.WithUnit(unit))
}
c, err := r.meter.Float64Counter(name, opts...)
if err != nil {
return nil, fmt.Errorf("failed to create counter for %q: %w", name, err)
}
r.logger.Debugf("registered counter metric %q", name)
r.counters.Store(name, c)
return c, nil
}
View on GitHub (pinned to 01ffac6f24)
Solutions
- Rename one of the conflicting metrics so counter vs other types don't share a name
- Avoid registering the same metric name with different types in one run
Defensive patterns
Strategy: type-guard
When it happens
Trigger: Thrown at internal/output/opentelemetry/registry.go:36 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of grafana/k6@01ffac6f24 (2026-08-18).
Data as JSON: /api/errors/5ae2d18642bb268d.
Report an issue: GitHub.