In this article, I’ll explain how to monitor MongoDB clusters using official mongo Go drivers. We will also learn to build a monitor-mongodb-cluster API endpoint to provide collective coverage of MongoDB server infrastructure.
The mongo-go-driver provides monitoring structures to gather information from the connection pool, mongo command queries, and server connection heartbeats in the MongoDB cluster.
Official Monitoring Packages
1. Connection Pool Monitoring
The PoolMonitor monitors the MongoDB connection pool lifecycle using the pool event listeners.
In the following code snippet, the Pool Event listeners are triggered in a different case that will automatically get called whenever the MongoDB connection pool executes the lifecycle method.
2. Mongo Command Monitoring
The command monitor will trigger each mongo transaction with its success/failure events.
In the following code snippet, the CommandMonitor callback function gets triggered based on the mongo transaction results.
If the “insert” mongo query has executed a transaction then, the first “Started” function gets called, and the “Succeeded/Failed” function gets triggered upon the mongo-query result.
3. Server Monitoring
The ServerMonitor captures the multiple mongo server events that the client can listen to generate server heartbeat reports by reading the server monitoring structure.
The server heartbeat monitor analyzes the communication between the mongo client and the mongo cluster replica sets. The ServerMonitor structure provides a monitoring reporting structure of mongo server events and the mongo transactions success/failure records.
In this code snippet, the ServerMonitor callback method gets triggered for each mongo server event.
Monitoring API endpoint
The monitoring structure information is marshaled into a JSON array and the API endpoint responds to the client request for the go-live readiness monitoring information.
Run the mongo monitoring POC
After running the above code, we can see immediately the mongo connection pool monitor triggered the initial connection pool lifecycle methods. The number of connection instances created after completing the connection event returned to the pool.
Conn1: Connection pool created to perform “Ping” request to check mongo server connection status. After receiving the “Pong” response connection instance returned to the pool.
Conn2: connection pool created to “ListDatabaseNames” in the MongoDB cluster. After receiving the list of database names, the connection instance returned to the pool.
In this scenario, a maximum of 2 connection instances was created and returned to the pool. The pool monitoring lifecycle method calls counts are stored atomically.
Response /api/monitor-mongodb-cluster endpoint result:
We can see MongoDB monitoring results generated after performing connection events and a few database query transactions.
- The pool monitor shows connections instances created and returned to the pool.
- The heartbeat records show the connection instances created in the pool and performed the server connection heartbeat lifecycle.
- As there is no failed heartbeat in this connection flow, so ServerHeartbeatFailed JSON array remains empty.
- The command monitor shows, there are two mongo commands “ping”, “listDatabases” that have been executed in the cluster.
- cmdMonitorStart JSON array shows the number of commands attempted to execute in the cluster and cmdMonitorSucceed JSON array shows the corresponding succeeded commands with their requestIDs.
- In this case, there are no failed mongo commands, so the cmdMonitorFailed JSON array remains empty.
Monitoring failure scenarios
- In case the MongoDB cluster is down serverHeartbeatFailed JSON array will show connection failure records.
Let’s try stopping the MongoDB cluster to create the failed server heartbeat scenario.
$ sudo systemctl stop mongod
The mongo monitor API endpoint shows few failure records generated in the serverHeartbeatFailed JSON array. We can see the interrupted shutdown message with the Error Code in the connection failure record.
The MongoDB cluster monitoring information provides the nodes’ performance and in-depth connection status coverage with collective server heartbeats matrices. The cluster network traffic report helps to analyze the cluster downtime scenarios. The monitoring endpoints provide the real-time status of the cluster that is critical in the go-live readiness of the MongoDB server infrastructure.
So, this is the overview of monitoring MongoDB cluster using mongodb-go-driver event structures.
I hope you find this article useful :)