Despite setting logging.level = ‘error’ in alloy.river, it appears that prometheus.exporter.mongodb is outputting thousand lines of logs.
The log volume of our monitoring stack is consuming several GB’s of storage capacity in Splunk where Openshift logs are being forwarded to.
Has anyone encountered similar issue and any workaround /solution to address this issue ?
This appears to match the issue tracked in grafana/alloy#5258. Another user reported the same symptom: prometheus.exporter.mongodb producing large volumes of JSON logs even with logging.level = "error" configured.
The important caveat is that the issue doesn’t have a confirmed root cause from a maintainer. The reporter speculated it was related to the embedded exporter, but that hasn’t been verified in the issue.
If your logs look similar, then it’s likely the same issue. If not, could you share a few sample log lines (with any sensitive information removed)? That would help determine whether they’re expected collector warnings or something different.
Until it’s resolved upstream, the most reliable workaround is to filter/drop these log lines before they reach Splunk (for example, in the OpenShift log forwarder or at Splunk ingest time).
I’d also keep an eye on #5258 for updates, since that’s where any fix or maintainer explanation is likely to appear.
Yes, the issue is exactly same and I came across the post and seem to have closed without any solutions. The exporter is printing all metrics reference to console output and multiple lines are generated per second.
\[
{
"host": "",
"latencyStats": {
"commands": {
"latency": 0,
"ops": 0,
"queryableEncryptionLatencyMicros": 0
},
"reads": {
"latency": 37727491,
"ops": 60226,
"queryableEncryptionLatencyMicros": 0
},
"transactions": {
"latency": 0,
"ops": 0,
"queryableEncryptionLatencyMicros": 0
},
"writes": {
"latency": 0,
"ops": 0,
"queryableEncryptionLatencyMicros": 0
}
},
"localTime": "2026-08-05T07:24:59.338Z",
"ns": "DIGITAL_Template_Management_Application.NOTIFICATION_Templates",
"storageStats": {
"avgObjSize": 428,
"capped": false,
"count": 2,
"freeStorageSize": 53248,
"indexBuilds": [ ],
"indexSizes": {
"*id*": 73728
},
"nindexes": 1,
"numOrphanDocs": 0,
"scaleFactor": 1,
"size": 856,
"storageSize": 73728,
"totalIndexSize": 73728,
"totalSize": 147456
}
}
\]
\[
{
"host": "",
"latencyStats": {
"commands": {
"latency": 0,
"ops": 0,
"queryableEncryptionLatencyMicros": 0
},
"reads": {
"latency": 38185779,
"ops": 60226,
"queryableEncryptionLatencyMicros": 0
},
"transactions": {
"latency": 0,
"ops": 0,
"queryableEncryptionLatencyMicros": 0
},
"writes": {
"latency": 0,
"ops": 0,
"queryableEncryptionLatencyMicros": 0
}
},
"localTime": "2026-08-05T07:24:59.34Z",
"ns": "DIGITAL_Template_Management_Application.SMS_Templates",
"storageStats": {
"avgObjSize": 405,
"capped": false,
"count": 3,
"freeStorageSize": 32768,
"indexBuilds": [ ],
"indexSizes": {
"*id*": 53248
},
"nindexes": 1,
"numOrphanDocs": 0,
"scaleFactor": 1,
"size": 1217,
"storageSize": 53248,
"totalIndexSize": 53248,
"totalSize": 106496
}
}
\]
\[
{
"host": "",
"latencyStats": {
"commands": {
"latency": 0,
"ops": 0,
"queryableEncryptionLatencyMicros": 0
},
"reads": {
"latency": 55039203,
"ops": 60226,
"queryableEncryptionLatencyMicros": 0
},
"transactions": {
"latency": 0,
"ops": 0,
"queryableEncryptionLatencyMicros": 0
},
"writes": {
"latency": 0,
"ops": 0,
"queryableEncryptionLatencyMicros": 0
}
},
"localTime": "2026-08-05T07:24:59.343Z",
"ns": "a2a_framework.agent_cards",
"storageStats": {
"capped": false,
"count": 0,
"freeStorageSize": 0,
"indexBuilds": [ ],
"indexSizes": {
"*id*": 4096,
"agent_id_1": 4096
},
"nindexes": 2,
"numOrphanDocs": 0,
"scaleFactor": 1,
"size": 0,
"storageSize": 4096,
"totalIndexSize": 8192,
"totalSize": 12288
}
}
\]
\[
{
Thanks for sharing the sample logs. This is the same issue tracked in #5258, and it has since been addressed by PR #6392 →
I’d recommend upgrading to the first Alloy release that includes that PR (I haven’t verified which tagged release contains it yet, so it’s worth checking the release notes/changelog).
Until you’re able to upgrade →
enable_diagnostic_data, enable_db_stats, enable_top_metrics, and enable_coll_stats. Also make sure collect_all = false, otherwise all collectors are enabled regardless of the individual enable_* settings.