Describe the bug
When using mongodb_exporter 0.51.0 against MongoDB 8.3.1 with the --collector.diagnosticdata collector enabled, the exporter logs duplicated metric registration errors related to mongodb_ss_opLatencies_transactions_histogram_micros.
The exporter appears to internally collect the same metric more than once during the gather phase, causing Prometheus registry conflicts.
The metrics endpoint itself (/metrics) does not visibly expose duplicated metrics, but the exporter continuously logs errors during collection.
To Reproduce
Steps to reproduce the behavior:
- Run MongoDB 8.3.1
- Start
mongodb_exporter with:
mongodb_exporter \
--web.listen-address=:9104 \
--mongodb.uri="mongodb://127.0.0.1:27017/" \
--collector.diagnosticdata
Observe exporter logs
The issue also happens with additional collectors enabled, but can be reproduced with ONLY:
--collector.diagnosticdata
Expected behavior
The exporter should collect metrics successfully without duplicated metric registration errors.
mongodb_ss_opLatencies_transactions_histogram_micros should either:
- be deduplicated internally before registration
- or exposed only once
Logs
time=2026-05-14T09:33:40.953Z level=ERROR source=http_error_logger.go:47 msg="error gathering metrics:" error="[from Gatherer #2] collected metric "mongodb_ss_opLatencies_transactions_histogram_micros" { label:{name:"cl_id" value:""} label:{name:"cl_role" value:""} untyped:{value:24576}} was collected before with the same name and label values" total_errors=64 error_no=58
Additional observations:
curl localhost:9104/metrics does NOT visibly show duplicated metrics
The error happens during exporter gather/registration phase
Disabling --collector.diagnosticdata removes the issue completely
--compatible-mode=false and --no-compatible-mode do not change behavior
Environment
- OS: Fedora CoreOS
- Environment: Podman Container
- MongoDB version: 8.3.1
- mongodb_exporter version: 0.51.0
Additional context
The issue appears specific to MongoDB 8.3.x telemetry changes and the diagnosticdata collector.
The problem can be reproduced with only:
--collector.diagnosticdata
No other collectors are required to trigger the issue.
The metrics endpoint still responds, but the exporter continuously logs gather errors.
Describe the bug
When using
mongodb_exporter0.51.0 against MongoDB 8.3.1 with the--collector.diagnosticdatacollector enabled, the exporter logs duplicated metric registration errors related tomongodb_ss_opLatencies_transactions_histogram_micros.The exporter appears to internally collect the same metric more than once during the gather phase, causing Prometheus registry conflicts.
The metrics endpoint itself (
/metrics) does not visibly expose duplicated metrics, but the exporter continuously logs errors during collection.To Reproduce
Steps to reproduce the behavior:
mongodb_exporterwith:mongodb_exporter \ --web.listen-address=:9104 \ --mongodb.uri="mongodb://127.0.0.1:27017/" \ --collector.diagnosticdataObserve exporter logs
The issue also happens with additional collectors enabled, but can be reproduced with ONLY:
--collector.diagnosticdata
Expected behavior
The exporter should collect metrics successfully without duplicated metric registration errors.
mongodb_ss_opLatencies_transactions_histogram_micros should either:
Logs
time=2026-05-14T09:33:40.953Z level=ERROR source=http_error_logger.go:47 msg="error gathering metrics:" error="[from Gatherer #2] collected metric "mongodb_ss_opLatencies_transactions_histogram_micros" { label:{name:"cl_id" value:""} label:{name:"cl_role" value:""} untyped:{value:24576}} was collected before with the same name and label values" total_errors=64 error_no=58
Additional observations:
curl localhost:9104/metrics does NOT visibly show duplicated metrics
The error happens during exporter gather/registration phase
Disabling --collector.diagnosticdata removes the issue completely
--compatible-mode=false and --no-compatible-mode do not change behavior
Environment
Additional context
The issue appears specific to MongoDB 8.3.x telemetry changes and the diagnosticdata collector.
The problem can be reproduced with only:
No other collectors are required to trigger the issue.
The metrics endpoint still responds, but the exporter continuously logs gather errors.