Currently, whenever an index build is kicked off on a replica set, it tends to trigger a "host is down" alert. Although this is benign and a false positive alert the on-call DBA has to wake up in the middle of a night when this alert pages us to make sure the host is NOT DOWN. When the monitoring agent tries to ping a node (where index build is running) and fails to communicate with it, it tends to think that the host is down and triggers this alert, although the host is up and running. When an index build is kicked off, it is capture in the mongodb.log. If monitoring agent can check the mongodb.log for an index build or somehow be notified that an index build is running on a node, so NOT to trigger a host is down, that would really help with all the false positive alerts that are being generated.

The Ops Manager authentification process through SAML requires that the user's groups are specified in a dedicated SAML attribute sent by the IDP, so the user can connect to Ops Manager.

For this need, our IDP can only provide a field that contains free text. This field can contain many information, and can include special characters. We can add the Ops Manager groups in this field, among the existing text information.

However we need Ops Manager to parse this free field and get the groups information, which is not possible for now.

That's why we would like the implementation of regexp, or another solution, in OpsManager, so it can find the user's groups information in a "SAML Group Member Attribute" field containing many other information.

Hey!

We are using fluent-bit to push MongoDB logs to Elasticsearch. When there are already logs in the elastic index, where attr.error is an object, then it does not accept log lines in which this field is a string:

“error”:{“type”:“mapperparsingexception”,“reason”:“object mapping for [attr.error] tried to parse field [error] as object, but found a concrete value”}

There is log with string attr.error:

{“t”:{"$date":“2022-05-13T15:16:31.203+00:00”},“s”:“I”, “c”:“CONNPOOL”, “id”:22572, “ctx”:“MirrorMaestro”,“msg”:“Dropping all pooled connections”,“attr”:{“hostAndPort”:“mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017”,“error”:“ShutdownInProgress: Pool for mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017 has expired.”}}

There is log with object attr.error:

{“t”:{"$date":“2022-05-13T15:20:56.857+00:00”},“s”:“I”, “c”:“REPL_HB”, “id”:23974, “ctx”:“ReplCoord-680”,“msg”:“Heartbeat failed after max retries”,“attr”:{“target”:“alerta-mongodb-arbiter-0.alerta-mongodb-arbiter-headless.monitoring. svc.cluster.local:27017”,“maxHeartbeatRetries”:2,“error”:{“code”:93,“codeName”:“InvalidReplicaSetConfig”,“errmsg”:“replica set IDs do not match, ours: 61ea35f29cfd494fef169571; remote node’s: 61eef8589d065c56e61d6e52”}}}
bitnami/mongodb:4.4.12-debian-10-r18 docker image is used

Could you direct CONNPOOL error message to attr.error.errmsg instead of attr.error (the same as REPL_HB error message)?

I understand that I can make a filter in fluent-bit, but the root cause will remain a problem for other users using structured logging as well.
I think many people have this problem, but not everyone could notice the absence of some logs.

We would like to periodically provision queryable snapshots on a programmatic basis (aka Ops Manager public API call) to easily get a consistent dump of sharded clusters in order to put those dumps in a "very safe location". We want to use this as part of a last resort backup strategy. The idea is that a dump is much easier to be restored by a "last resort restore app" compared to the http-downloaded plain data files.

One other option to extract the contents of a sharded cluster would be to use "Long Running Queries" but this cannot be used along with mongodump.

When we run the Profiler, the runtime of "select" type queries are dramatically understated. This is because the Profiler only counts the time of the "query", and doesn't include how long it took to "fetch" the result set.

In one of our test cases, we "tuned" the query so it only shows as running 82 ms in the Profiler. However, when we actually run this same query in JavaScript, the runtime is 10 seconds. This is a very slow query which our end users experience many times a day.

Is there a way to configure Profiler to be more realistic, and include the "fetch time" as well as the "query" time?

Currently, the Profiler seems to be of little us in finding slow queries. We have to find them using other means.

Thank you.