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

[monotek]

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.

[floatinginbits]

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.

[monotek]

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.

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

[monotek]

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

[lisenet]

@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).