0

Could someone please shed some light on these mongodb 3.6.5 server log messages on the primary node of a 3-member replicaset? rs.status() says all the nodes are up and running but seeing a ton of (I)nformational logs.

2019-01-16T00:07:24.819+0000 I ACCESS [conn95] Unauthorized: not authorized on admin to execute command { replSetGetStatus: "1", $db: "admin", $clusterTime...

1

Unauthorized: not authorized on admin to execute command { replSetGetStatus: "1", $db: "admin", $clusterTime...

The message indicates there is a user or application trying to run the replSetGetStatus command without having the correct privileges.

This command returns the current state of your replica set from the point of view of the server that processed the command. If this error is logged frequently, it is likely the result of a monitoring script or agent.

You can track down the source by searching the MongoDB server logs for related connection history. The first few lines for a given connection ID will usually include client metadata (optional, so will vary by driver/application) as well as the username used with authentication enabled.

For example, using a Linux-like command line to find the first entries for conn95:

> grep conn95 mongod.log | head -2
2019-01-15T21:41:19.026+1100 I NETWORK  [conn95] received client metadata from 192.168.1.123:59354 conn95: { driver: { name: "PyMongo", version: "3.6.0" }, os: { type: "Darwin", name: "Darwin", architecture: "x86_64", version: "10.14.2" }, platform: "CPython 2.7.14.final.0", application: { name: "monitoring-agent v1.2.3-dev" } }
2019-01-15T21:41:19.027+1100 I ACCESS   [conn95] Successfully authenticated as principal monitoring-agent on admin

These log lines include the following info:

  • the connection originated from 192.168.1.123
  • the client application identified itself as monitoring-agent v1.2.3-dev
  • the application successfully authenticated as user monitoring-agent via the admin database

If this is an expected connection from a monitoring agent, the likely fix would be to grant a role which includes the required access for replSetGetStatus (for example, the built-in clusterMonitor role):

use admin;
db.grantRolesToUser("monitoring-agent", [{ role: "clusterMonitor", db: "admin" }]);

If the connection is unexpected, you could determine an appropriate action based on the source IP or other details. You may wish to shutdown a monitoring app that is no longer required or remove the associated user account and block connections via your firewall. See MongoDB Security Checklist for some available security measures to consider.

  • Turns out Studio 3T is sending those commands to the cluster. Any idea why a client would need to keep sending those commands every few seconds? – GBackMania Jan 17 at 23:00
  • 1
    @GBackMania Best to ask Studio 3T support about specific replSetGetStatus usage in their application, but my guess would be that this is related to a deployment monitoring feature. Standard MongoDB drivers connect to individual replica set members rather than relying on the view from a single member. – Stennie Jan 17 at 23:09

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.