mongodb_exporter icon indicating copy to clipboard operation
mongodb_exporter copied to clipboard

Is there any config possible that recreates exporter behaviour as in version v0.11.2?

Open monotek opened this issue 2 years ago • 5 comments

Is your feature request related to a problem? Please describe.

The DB we're moniotoring has several thousands of collections.

After updating the exporter from version v0.11.2 to the lates version v0.35.0 we get a lot more metrics exported as before, which results in a load of up to 4 CPU and up to 5GB of ram for the exporter.

Before in v0.11.2, where we used --suppress.collectshardingstatus flag, i was as about 0.01 CPU max and 30MB Ram max.

We tried v0.35.0 with:

--no-discovering-mode --collector.diagnosticdata --collector.replicasetstatus --collector.dbstats --collector.topmetrics --compatible-mode

But the metrics output is still a lot bigger as before.

Describe the solution you'd like A config option to restore the v0.11.2 behaviour.

Describe alternatives you've considered Forking v0.11.2 and update dependencies.

monotek avatar Dec 07 '22 11:12 monotek

Hi @monotek. I understand that your issue lies with resource consumption.

With newer versions of MongoDB exporter, you no longer have to use all collectors. Most collectors are disabled by default. This means you can selectively enable collectors which are required. We also provide runtime for collectors as part of metrics, so that can be utilised by you to figure out the errant collector.

You can use this information to disable the collector taking too long. If you want us to take a look at the collector, you can file a bug with usage details and we'll take a look at the resource consumption.

ShashankSinha252 avatar Dec 08 '22 06:12 ShashankSinha252

We already don't use --collect-all. Which of the collectors we use (see above) should be removed? As far as i see the diagnosticdata collector is most expensive but if i disable this one also the metrics we use are missing.

monotek avatar Dec 08 '22 08:12 monotek

#609 might fix some of the performance issues as each run, no matter what collectors are enabled, counts the collections present.

ghost avatar Dec 23 '22 14:12 ghost

What made our case even worse was the bitnami mongodb helm chart, which did the readinessprobe on /metrics.

https://github.com/bitnami/charts/blob/main/bitnami/mongodb/templates/replicaset/statefulset.yaml#L461

monotek avatar Dec 23 '22 14:12 monotek

@monotek a very similar problem here, running the exporter on K8s would eventually kill the pod due to liveness probe failure because it takes so long to gather and publish /metrics data (not to mention high CPU load).

lisenet avatar Jan 26 '23 18:01 lisenet