One approach to get to know a MongoDB system we are not familiar with is to start by checking the busiest collections. MongoDB provides the top administrative command for this purpose.
From the mongo shell, we can run db.adminCommand(“top”) to get a snapshot of all the collections at a specific point in time:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | ... "test.testcol" : { "total" : { "time" : 17432, "count" : 58 }, "readLock" : { "time" : 358, "count" : 57 }, "writeLock" : { "time" : 17074, "count" : 1 }, "queries" : { "time" : 100, "count" : 1 }, "getmore" : { "time" : 0, "count" : 0 }, "insert" : { "time" : 17074, "count" : 1 }, "update" : { "time" : 0, "count" : 0 }, "remove" : { "time" : 0, "count" : 0 }, "commands" : { "time" : 0, "count" : 0 } } ... |
In the extract above we can see some details about the testcol collection. For each operation type, we have the amount of server time spent (measured in microseconds), and a counter for the number of operations issued. The total section is simply the sum for all operation types against the collection.
In this case, I executed a single insert and then a find command to check the results, hence the counters are one for each of those operations.
So by storing samples of the above values in a set of metrics, we can easily see the trends and historical usage of a MongoDB instance.
Top Metrics in Percona Monitoring and Management (PMM)
PMM 2.26 includes updates to mongodb_exporter so we now have the ability to get metrics using the output of the MongoDB top command.
For example:
As you can see, the metric names correlate with the output of the top command we saw. In this release, the dbname and collection name is part of the metric name (that is subject to change in the future based on community feedback).
Collection and Index Stats
In addition to this, PMM 2.26 also includes the ability to gather database, collection, and index statistics. Using these metrics we can monitor collection counts, data growth, and index usage over time.
For example, we can collect the following information about a database:
And here are the colstats metrics for the test.testcol collection:
Note: By default, PMM won’t collect this information if you have more than 200 collections (this number is subject to change). The reason is to avoid too much overhead in metrics collection, which may adversely affect performance. You can override this behavior by using the –max-collections-limit option.
Enabling the Additional Collectors
The PMM client starts by default only with the diagnosticdata and replicasetstatus collectors enabled. We can run the PMM client with the –enable-all-collectors argument, to make all the new metrics available. For example:
1 | pmm-admin add mongodb --username=mongodb_exporter --password=percona --host=127.0.0.1 --port=27017 --enable-all-collectors |
If we want to override the limit mentioned above, use something like this:
1 | pmm-admin add mongodb --username=mongodb_exporter --password=percona --host=127.0.0.1 --port=27017 --enable-all-collectors -–max-collections-limit=500 |
We also have the ability to enable only some of the extra collectors. For example, if you want all collectors except topmetrics, specify:
1 | pmm-admin add mongodb --username=mongodb_exporter --password=percona --host=127.0.0.1 --port=27017 --enable-all-collectors --disable-collectors=topmetrics |
We can also filter which databases and collections we are interested in getting metrics about. The optional argument –stats-collections can be set with a namespace.
For example:
1 2 | –stats-collections=test (get data for all collections in test db) –stats-collections=test.testcol (get data only from testcol collection of testdb) |
Also, check the documentation page for more information.
Creating Dashboards
We can easily create dashboards using the newly available metrics. For example, to see the index usages, we can use the following promSQL expression:
1 | {__name__ =~ "mongodb_.*_accesses_ops"} |
This is what the dashboard would look like:
Note: If the image above is too small, you can open it in a new browser tab to see it better.
Conclusion
We can use these new metrics to create dashboards with the collections most written to (or most read from). We can also see what the characteristics of the workload are at a glance to determine if we are dealing with a read-intensive, mixed, or write-intensive system.
One of the most important uses for these new collectors and metrics is performance tuning. By knowing more about your top or “hottest” collections, you will likely be able to better tune your queries and indexing to improve overall performance. These new metrics on collections will be very helpful for performance tuning
Keep in mind these features are currently a technical preview, so they are disabled by default.
Percona Monitoring and Management is a best-of-breed open source database monitoring solution. It helps you reduce complexity, optimize performance, and improve the security of your business-critical database environments, no matter where they are located or deployed.
Download Percona Monitoring and Management Today
