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 &registry{
		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

  1. Rename one of the conflicting metrics so counter vs other types don't share a name
  2. 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.