Where are the collection and db stats ?

[dcram]

When I start the exporter with docker, no stats about my collections and databases are printed.

I tried many combinations of the CLI launcher's options, like this one:

docker run -d \
    --name mongodb-exporter \
    --rm \
    -v /etc/ssl/certs/ca.pem:/etc/ssl/certs/ca.pem:ro \
    -p 9216:9216 \
    percona/mongodb_exporter:0.30 --mongodb.uri=mongodb://user:pwd@hostname:27017/admin?tls=true&tlsCAFile=/etc/ssl/certs/ca.pem --discovering-mode --collector.collstats --log-level=debug --collector.dbstats

I can see many many lines in the output metrics: (small excerpt below)

...
mongodb_ss_metrics_commands_logout_total{cl_id="6017e8a5092e64150701e3b8",cl_role="",rs_nm="rs0",rs_state="1"} 0
# HELP mongodb_ss_metrics_commands_mapReduce_failed serverStatus.metrics.commands.mapReduce.
# TYPE mongodb_ss_metrics_commands_mapReduce_failed untyped
mongodb_ss_metrics_commands_mapReduce_failed{cl_id="6017e8a5092e64150701e3b8",cl_role="",rs_nm="rs0",rs_state="1"} 0
# HELP mongodb_ss_metrics_commands_mapReduce_total serverStatus.metrics.commands.mapReduce.
# TYPE mongodb_ss_metrics_commands_mapReduce_total untyped
mongodb_ss_metrics_commands_mapReduce_total{cl_id="6017e8a5092e64150701e3b8",cl_role="",rs_nm="rs0",rs_state="1"} 0
# HELP mongodb_ss_metrics_commands_mapreduce_shardedfinish_failed serverStatus.metrics.commands.mapreduce.shardedfinish.
# TYPE mongodb_ss_metrics_commands_mapreduce_shardedfinish_failed untyped
mongodb_ss_metrics_commands_mapreduce_shardedfinish_failed{cl_id="6017e8a5092e64150701e3b8",cl_role="",rs_nm="rs0",rs_state="1"} 0
# HELP mongodb_ss_metrics_commands_mapreduce_shardedfinish_total serverStatus.metrics.commands.mapreduce.shardedfinish.
# TYPE mongodb_ss_metrics_commands_mapreduce_shardedfinish_total untyped
mongodb_ss_metrics_commands_mapreduce_shardedfinish_total{cl_id="6017e8a5092e64150701e3b8",cl_role="",rs_nm="rs0",rs_state="1"} 0
# HELP mongodb_ss_metrics_commands_mergeAuthzCollections_failed serverStatus.metrics.commands._mergeAuthzCollections.
# TYPE mongodb_ss_metrics_commands_mergeAuthzCollections_failed untyped
mongodb_ss_metrics_commands_mergeAuthzCollections_failed{cl_id="6017e8a5092e64150701e3b8",cl_role="",rs_nm="rs0",rs_state="1"} 0
# HELP mongodb_ss_metrics_commands_mergeAuthzCollections_total serverStatus.metrics.commands._mergeAuthzCollections.
# TYPE mongodb_ss_metrics_commands_mergeAuthzCollections_total untyped
mongodb_ss_metrics_commands_mergeAuthzCollections_total{cl_id="6017e8a5092e64150701e3b8",cl_role="",rs_nm="rs0",rs_state="1"} 0
# HELP mongodb_ss_metrics_commands_mergeChunks_failed serverStatus.metrics.commands.mergeChunks.
...

But none seems to match any of my collections and databases.

Our server is running MongoDB 4.0, as single instance (size-1 replica set)

Am I doing anything wrong ?

[ShashankSinha252]

Hi @dcram , thanks for reporting this issue.

Since you see some metrics, it should not be a connectivity issue. To rule out privilege issues in MongoDB for the user used by you, can you execute dbStats or collStats command by connecting to MongoDB via mongo shell?

$ db.runCommand( { collStats : "col" } ) # Replace col with collection in the DB being used
$ db.runCommand({"dbStats":1})

In case of a privilege issue, you'll need to add collStats and dbStats privilege for the user. Alternatively, you can create a new user with the same privileges.

[dcram]

Thanks @ShashankSinha252 . Your answer first helped me solve my issue, and led me to another one.

Trying to play with mongosh and answer to you, I figured out that I had the following issue with my connection uri:

1. it was missing the target database name as the path
2. it was missing the param authSource=admin

The right connection uri, if I want to read the dbStats and any collStats from the database mydb1 with mongosh, is then:

mongosh mongodb://user:pwd@hostname:27017/mydb1?tls=true&authSource=admin&tlsCAFile=/etc/ssl/certs/ca.pem 

However, this exact same uri does set as the value of the --mongodb.uri option, throws an authentication issue issue:

docker run -d \
    --name mongodb-exporter \
    --rm \
    -v /etc/ssl/certs/ca.pem:/etc/ssl/certs/ca.pem:ro \
    -p 9216:9216 \
    percona/mongodb_exporter:0.30 --mongodb.uri=mongodb://user:pwd@hostname:27017/mydb1?tls=true&authSource=admin&tlsCAFile=/etc/ssl/certs/ca.pem --discovering-mode --collector.collstats --log-level=debug --collector.dbstats

which produces the following error logs:

time="2022-02-02T14:15:54Z" level=info msg="Starting HTTP server for http://:9216/metrics ..." source="server.go:140"
time="2022-02-02T14:15:55Z" level=error msg="Cannot connect to MongoDB: cannot connect to MongoDB: connection() error occured during connection handshake: auth error: sasl conversation error: unable to authenticate using mechanism \"SCRAM-SHA-1\": (AuthenticationFailed) Authentication failed."

Again, when I set admin as the db name in place of mydb1, authentication and metrics rendering work just fine, but I get no db nor collection stats:

time="2022-02-02T14:20:08Z" level=info msg="Starting HTTP server for http://:9216/metrics ..." source="server.go:140"

[ShashankSinha252]

Hi @dcram , glad to hear you made some progress.

time="2022-02-02T14:15:54Z" level=info msg="Starting HTTP server for http://:9216/metrics ..." source="server.go:140"
time="2022-02-02T14:15:55Z" level=error msg="Cannot connect to MongoDB: cannot connect to MongoDB: connection() error occured during connection handshake: auth error: sasl conversation error: unable to authenticate using mechanism \"SCRAM-SHA-1\": (AuthenticationFailed) Authentication failed."

This error signifies that SCRAM-SHA-1 based verification failed on server. I've seen this happen when MongoDB is not able to find a user in the authentication database (though there may be more scenarios).

I am also curious about the parameters you have used for MongoDB exporter. --log-level and --collector.collstats are not valid flags for percona/mongodb_exporter:0.30 image. Please check on your end to see if there is something I missed.

I ended up using the following setup to test this issue on my end. You can give it a shot on see if it helps you gain further insights.

• docker-compose.yml

  
  version: '3'

services: db: image: mongo:4.0 hostname: db container_name: db volumes:

• ./certs:/certs:ro
• ./scripts:/scripts:ro entrypoint: ["/scripts/setup.sh"] exporter: image: percona/mongodb_exporter:0.30 hostname: exporter container_name: exporter depends_on:
• db links:
• db ports:
• 9216:9216 volumes:
• ./certs:/certs:ro entrypoint: ["/mongodb_exporter", "--mongodb.uri=mongodb://read:read@db:27017/?authSource=admin&tls=true&tlsCAFile=/certs/test-ca.pem", "--log.level=info", "--discovering-mode", "--collector.dbstats"]

• scripts/setup.sh (don't forget to provide execute permission to script)

  
  #!/bin/sh

mongod --sslMode requireSSL --sslPEMKeyFile /certs/test-server.pem --sslCAFile /certs/test-ca.pem --bind_ip_all --sslAllowConnectionsWithoutCertificates & sleep 5 mongo --nodb /scripts/setup.js --sslAllowInvalidCertificates --ssl

if [ $? -eq 0 ] then echo "Setup done" tail -f /dev/null else echo "Setup failed" fi

- `scripts/setup.js`

db = connect( 'mongodb://db:27017/admin?ssl=true&sslCAFile=/certs/test-ca.pem' );

db.createUser({ user: "admin", pwd: "admin", roles: [ {role: "root", db: "admin"} ] })

db.createUser({ user: "read", pwd: "read", roles: [ {role: "read", db: "admin"} ] })

- Certificates created in certs folder using instructions available from MongoDB [[A](https://docs.mongodb.com/manual/appendix/security/appendixA-openssl-ca/#appendix-ca-certificate), [B](https://docs.mongodb.com/manual/appendix/security/appendixB-openssl-server/#std-label-appendix-server-certificate), [C](https://docs.mongodb.com/manual/appendix/security/appendixC-openssl-client/#std-label-appendix-client-certificate)]

Open `http://localhost:9216/metrics` in a browser. In case of failure message, retry after 10-15 seconds. You should see metrics about MongoDB, along with database and index statistics.

[denisok]

@dcram I will close this one as it is stale, feel free to re-open or maybe you have the same as #452