![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/08\/mongodb_exporter_logo.png?w=1024\"){kind=logo}
<\/figure>\n\n\n\n\n\n\n\nMongoDB is an open-source NoSQL database that stores data in flexible, JSON-like documents gathered together in collections unlike data stored in a relational database in tables, rows, and columns, with the relationship of entities. MongoDB is a document-oriented database which means it works on principles of dealing with \u201cdocuments\u201d; it allows you to express data in its natural form, the way it\u2019s meant to be. Moreover, it provides more flexibility, as fields can vary from document to document and data structure can change over time as well.<\/p>\n\n\n\n
Need for<\/strong> Monitoring of MongoDB<\/strong><\/h2>\n\n\n\nThe database is an extremely critical component for the high performance of applications, and most of the time its performance is directly proportional to application performance. Yet in quite a few cases, organizations ignore this fact leading to performance degradation and incidentally failing to identify issues proactively. In addition, it also helps you calculate your database resource requirements in various situations and helps you provision your database with the right amount of resources in the future.<\/p>\n\n\n\n
In this blog, we are going to cover the key metrics which are needed to monitor the MongoDB database. We are using the Prometheus stack to capture the metrics using MongoDB exporter.<\/p>\n\n\n\n
Key Metrics of Mongodb we are collecting<\/strong> (Mongodb Dashboard<\/a><\/strong>)<\/h2>\n\n\n\nMongoDB Service UP<\/strong>: This metric depicts whether your MongoDB database service is running on the server or not. So, prompt alerting on this one is self-explanatory.<\/p>\n\n\n\nMongoDB Uptime:<\/strong> How long was MongoDB service\/database running? This is a time-based metric and it will reset once the MongoDB service gets restarted. It is a frequently looked-up metric for troubleshooting, especially, in containerized environments.<\/p>\n\n\n\nMongoDB Connections<\/strong><\/p>\n\n\n\nOnce the database starts, it listens to a particular IP address and port for requests. This is how connections are established with clients. By running db.serverStatus().connections<\/code> we can check the current, total, and active connections of the MongoDB database. If we plot these connections in a graph with history, we can also measure the peak, normal, and low traffic time. This helps us schedule the patching and upgrading activities of databases and applications.<\/p>\n\n\n\nInstant increases in traffic can lead to performance issues. This can be visualized by using the current connections metric. It can notify about the drastic change in traffic patterns via alerting as well.<\/p>\n\n\n\n
- Current Connections<\/strong>: The number of incoming connections from the client to the database server, also includes any shell connections or connections from other servers as well. <\/li>
- Total Created Connections<\/strong>: Include all incoming connections created to the server, and includes connections that have since closed.<\/li>
- Available Connections:<\/strong> The number of unused incoming connections available<\/li>
- Active Connections:<\/strong> Number of client connections that currently have operations in progress.<\/li><\/ul>\n\n\n\n
OPCounters<\/strong><\/p>\n\n\n\nA document that reports the average number of operations in a database by type since the MongoDB instance last started is known as OPCounters. We are going to monitor opcounters.insert, opcounters.query, opcounters.update, opcounters.delete, opcounters.getmore, and opcounters.command metrics from MongoDB which tell us the number of inserts, update, delete, getMore operations respectively. Moreover, also going to get the metrics about the number of queries and commands received on MongoDB.<\/p>\n\n\n\n
Total Collections Per DB<\/strong><\/p>\n\n\n\nIt is always beneficial to track the total number of collections in MongoDB. A collection is a group of documents just like the tables in Relational databases. These metrics can help to keep a record of the number of collections per database.<\/p>\n\n\n\n
Total Indexes Per DB<\/strong><\/p>\n\n\n\nThe indexes are special data structures that support the efficient execution of queries in MongoDB. It stores some information like the field or sub-field of the document to find the right data in less time. This metric lets you know how many indexes are created per DB.<\/p>\n\n\n\n
Allocated Storage to Collections and Indexes<\/strong><\/p>\n\n\n\nThe metrics illustrate the total amount of storage in bytes allocated to each collection and index in the MongoDB database. So, for example, it is necessary to monitor these metrics in scenarios where a chunk of data got deleted. It will reflect in these metrics and should trigger an alert about this intended or unintended activity. It will also be helpful where storage drastically increases as it can lead to a crash of database service.<\/p>\n\n\n\n
Replication Metrics<\/strong><\/p>\n\n\n\nMongoDB can be deployed in Primary and Secondary replication mode over multiple servers which ensures that your database is highly available, and it can store your data in multiple physical partitions called shards. Normally, in a production environment replica set is recommended. So, we are going to monitor the following key metrics.<\/p>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/08\/mongodb_replication.png?w=1006\")
<\/figure>\n\n\n\n- OPLog Size: <\/strong>The OPLog(Operation Logs) is a special capped collection that keeps a record of all operations that modify the data stored in your database. So this OPLog size should be consistent, if this is less than 25% or more than 50% this metric should trigger an alert.<\/li>
- Replication Lag: <\/strong>In replication mode, the primary MongoDB server replicates its data to the secondary MongoDB server. For better performance this replication should be up to date and as fast as possible. Replication lags tell us how far a secondary MongoDB server is behind from Primary one. We want replication lag as small as possible. There can be multiple reasons like the issue with networking Latency or Throughput etc. So, this alert should trigger when replication lag crosses a particular threshold.<\/li><\/ul>\n\n\n\n
MongoDB Server Metrics<\/strong><\/p>\n\n\n\nThe monitoring and alerting of MongoDB server metrics are as important as capturing the MongoDB Database metrics. For example, CPU, and memory utilization of the server. This can tell us the overall load on the server, the server can also crash because of a high load, or your MongoDB service consumes the whole memory of the server. So, decide on a suitable threshold like 70% or 80%, and trigger an alert whenever utilization of these metrics crosses this threshold. Apart from that, we also need to consider Network I\/O and Disk I\/O metrics as well. If these metrics cross the threshold on regular basis with the normal working of the application and normal traffic, it indicates that we have under-provisioned our MongoDB cluster.<\/p>\n\n\n\n
Tools We are going to use to Monitor MongoDB<\/strong><\/p>\n\n\n\n- Prometheus<\/strong> – An open-source time series database for event monitoring and alert manager by Cloud Native Computing Foundation(CNCF).<\/li>
- Grafana<\/strong> – An open-source project used for analytics and visualizations of the metrics from any database.<\/li>
- MongoDB Exporter<\/strong> – A Prometheus exporter which acts like an agent to publish the metrics (http:\/\/your_server_ip:9216\/metrics)<\/li>
- Node Exporter<\/strong> – Another Prometheus exporter is used to collect server metrics, such as CPU and memory utilization, disk space-related metrics, etc.<\/li><\/ul>\n\n\n\n
![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/08\/promtheus_arch.png?w=1024\")
<\/figure>\n\n\n\nSetup MongoDB Exporter<\/strong><\/p>\n\n\n\nWe are going to use MongoDB Exporter developed by Percona<\/a>. In the following steps, we will run MongoDB Exporter as a service along with Node Exporter on the MongoDB Server.<\/p>\n\n\n\nTo isolate the ownership of the Prometheus Exporters services, we will create separate users without a home directory and shell so that nobody can log in to these users.<\/p>\n\n\n\n
sudo useradd --no-create-home --shell \/bin\/false exporter<\/code><\/pre>\n\n\n\nAfterward, Download the latest MongoDB Exporter from here<\/a>. Extract the archive file and copy the binary file to \/use\/local\/bin<\/code>.<\/p>\n\n\n\nwget https:\/\/github.com\/percona\/mongodb_exporter\/releases\/download\/v0.34.0\/mongodb_exporter-0.34.0.linux-amd64.tar.gz\n\ntar xvzf mongodb_exporter-0.34.0.linux-amd64.tar.gz\n\nsudo mv mongodb_exporter \/usr\/local\/bin\/<\/code><\/pre>\n\n\n\nNow change the ownership of the binary file.<\/p>\n\n\n\n
sudo chown exporter:exporter \/usr\/local\/bin\/mongodb_exporter<\/code><\/pre>\n\n\n\nAccessing MongoDB should be authenticated and authorized. MongoDB Exporter going to get metrics from MongoDB Cluster. So, we need a user who can authenticate the MongoDB Database and should have the right set of permissions to read all the data. We need to create an Administrator account with clusterMonitor role.<\/p>\n\n\n\n
use admin\n\ndb.createUser(\n {\n user: \"mongodb_exporter\",\n pwd: \"password\",\n roles: [\n { role: \"clusterMonitor\", db: \"admin\" },\n { role: \"read\", db: \"local\" }\n ]\n }\n)<\/code><\/pre>\n\n\n\nThe output should be like this:<\/p>\n\n\n\n
Successfully added user: { \n \"user\" : \"mongodb_exporter\", \n \"roles\" : [ \n { \n \"role\" : \"clusterMonitor\",\n \"db\" : \"admin\" \n }, \n { \n \"role\" : \"read\", \n \"db\" : \"local\" \n } \n ] \n} <\/code><\/pre>\n\n\n\nNow We have to run the MongoDB Exporter service with the above mongodb_exporter user authentication with the following command in which we are going to provide the MONGODB_URI<\/code> the parameter in the command line.<\/p>\n\n\n\n\/usr\/local\/bin\/mongodb_exporter --mongodb.uri=mongodb:\/\/mongodb_exporter:password@localhost:27017 --collect-all<\/code><\/pre>\n\n\n\nNow we have MongoDB Exporter binary, user, and mongodb_exporter user to authenticate the Database. The next step would be to create a service to run MongoDB Exporter Binary and collect metrics. Create the following file in \/etc\/systemd\/system\/<\/code> directory to create a mongodb_exporter service.<\/p>\n\n\n\n[Unit]\nDescription=Mongodb Exporter\nWants=network-online.target\nAfter=network-online.target\n\n[Service]\nUser=exporter\nGroup=exporter\nType=simple\nExecStart=\/usr\/local\/bin\/mongodb_exporter --mongodb.uri=mongodb:\/\/mongodb_exporter:password@localhost:27017 --collect-all\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n\n\n\nTo use the newly created service, reload systemd<\/code>.<\/p>\n\n\n\nsudo systemctl daemon-reload<\/code><\/pre>\n\n\n\nWe can restart the service after reloading the system daemon.<\/p>\n\n\n\n
sudo systemctl start mongodb_exporter.service<\/code><\/pre>\n\n\n\nTo check the status of the service, run the following command.<\/p>\n\n\n\n
sudo systemctl status mongodb_exporter.service<\/code><\/pre>\n\n\n\nIf we want to make sure that MongoDB Exporter service runs even after rebooting the server as well, we need to enable the service.<\/p>\n\n\n\n
sudo systemctl enable mongodb_exporter.service<\/code><\/pre>\n\n\n\nSetup Node Exporter<\/strong><\/p>\n\n\n\nDownload the latest Node Exporter binary, click here<\/a><\/p>\n\n\n\nTo set up the Node Exporter through Ansible, click here<\/a><\/p>\n\n\n\nTo Install Node Exporter on Linux with Systemd service, click here<\/a>.<\/p>\n\n\n\nSetup Prometheus<\/strong><\/p>\n\n\n\nDownload the latest Prometheus<\/strong> binary from here<\/a>.<\/p>\n\n\n\nTo set up The Prometheus through Ansible, please click here<\/a>.<\/p>\n\n\n\nIf you want to install Prometheus as a service, you can follow the steps from here<\/a>.<\/p>\n\n\n\nSetup Grafana<\/strong><\/p>\n\n\n\nTo Download and Install Grafana please check here<\/a>.<\/p>\n\n\n\nTo Set up the Grafana through Ansible, please click here<\/a>.<\/p>\n\n\n\nConfigure MongoDB Exporter and Node Exporter with Prometheus<\/strong><\/p>\n\n\n\nTo Configure MongoDB Exporter and Node Exporter with Prometheus, we need to add the following configuration in prometheus.yml<\/code>.<\/p>\n\n\n\n- job_name: 'mongodb'\n scrape_interval: 5s\n static_configs:\n - targets: ['mongodb_exporter_ip:9216', 'mongodb_exporter_ip:9100']<\/code><\/pre>\n\n\n\nIn targets, we need to add the server IP where exporters are running, and 9216 and 9100 is the port of MongoDB and Node Exporter.<\/p>\n\n\n\n
Set Prometheus As Data Source<\/strong> in Grafana<\/p>\n\n\n\nFirstly we need to add Prometheus as the data source in Grafana to fetch the metrics data. Add the Datasource like below.<\/p>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/08\/prometheus_data_srouce.webp?w=567\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Import MongoDB Dashboard<\/a> in Grafana<\/strong><\/p>\n\n\n\nAfter setting up Prometheus as a data source, we are going to import the MongoDB dashboard with the ID. This Id is a unique ID given by Grafana when we upload a custom dashboard.
We need to click the Plus sign on the left menu bar from the Garfana homepage. Then click on the import, we will be on the import page, where we can provide a unique Garfana Dashboard ID and then load the dashboard. In this blog, we are going to import https:\/\/grafana.com\/grafana\/dashboards\/16490-opstree-mongodb-dashboard\/<\/code> this dashboard and the ID of this dashboard is 16490.<\/p>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/08\/import_page-1.png?w=1024\")
<\/figure>\n\n\n\n
Or if we have a Dashboard in JSON format, or we downloaded the dashboard, we can import it by uploading the JSON file from the local machine.<\/p>\n\n\n\n
Screenshots of MongoDB Dashboard created by us<\/strong><\/p>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/08\/mongodb_dashboard_1-1.png?w=1024\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/08\/mongodb_dashboard_2-1.png?w=1024\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/opstree.com\/blog\/\/wp-content\/uploads\/2022\/08\/mongodb_dashboard_3-1.png?w=1024\")
<\/figure>\n\n\n\nConclusion<\/strong><\/p>\n\n\n\nThe purpose of this blog was to dig a little deeper into MongoDB Concepts. The use of the MongoDB database and identifying the key metrics which can be monitored. We also set up a fully operational end-to-end monitoring pipeline for MongoDB with respect to the metrics we talked about in this blog. We published the custom dashboard in Grafana, check here<\/a>.<\/p>\n\n\n\nNow, in our next blog, we will talk about MongoDB Monitoring from an SRE perspective.<\/p>\n\n\n\n
Want to check other dashboards published by us, please check here<\/a>.<\/p>\n\n\n\nBlog Pundits: Naveen Verma<\/a> and Sandeep Rawat<\/a><\/strong><\/p>\n\n\n\nOpstree<\/a><\/strong>\u00a0is an End to End DevOps solution provider.<\/p>\n\n\n\n
MongoDB Service UP<\/strong>: This metric depicts whether your MongoDB database service is running on the server or not. So, prompt alerting on this one is self-explanatory.<\/p>\n\n\n\n MongoDB Uptime:<\/strong> How long was MongoDB service\/database running? This is a time-based metric and it will reset once the MongoDB service gets restarted. It is a frequently looked-up metric for troubleshooting, especially, in containerized environments.<\/p>\n\n\n\n MongoDB Connections<\/strong><\/p>\n\n\n\n Once the database starts, it listens to a particular IP address and port for requests. This is how connections are established with clients. By running Instant increases in traffic can lead to performance issues. This can be visualized by using the current connections metric. It can notify about the drastic change in traffic patterns via alerting as well.<\/p>\n\n\n\n OPCounters<\/strong><\/p>\n\n\n\n A document that reports the average number of operations in a database by type since the MongoDB instance last started is known as OPCounters. We are going to monitor opcounters.insert, opcounters.query, opcounters.update, opcounters.delete, opcounters.getmore, and opcounters.command metrics from MongoDB which tell us the number of inserts, update, delete, getMore operations respectively. Moreover, also going to get the metrics about the number of queries and commands received on MongoDB.<\/p>\n\n\n\n Total Collections Per DB<\/strong><\/p>\n\n\n\n It is always beneficial to track the total number of collections in MongoDB. A collection is a group of documents just like the tables in Relational databases. These metrics can help to keep a record of the number of collections per database.<\/p>\n\n\n\n Total Indexes Per DB<\/strong><\/p>\n\n\n\n The indexes are special data structures that support the efficient execution of queries in MongoDB. It stores some information like the field or sub-field of the document to find the right data in less time. This metric lets you know how many indexes are created per DB.<\/p>\n\n\n\n Allocated Storage to Collections and Indexes<\/strong><\/p>\n\n\n\n The metrics illustrate the total amount of storage in bytes allocated to each collection and index in the MongoDB database. So, for example, it is necessary to monitor these metrics in scenarios where a chunk of data got deleted. It will reflect in these metrics and should trigger an alert about this intended or unintended activity. It will also be helpful where storage drastically increases as it can lead to a crash of database service.<\/p>\n\n\n\n Replication Metrics<\/strong><\/p>\n\n\n\n MongoDB can be deployed in Primary and Secondary replication mode over multiple servers which ensures that your database is highly available, and it can store your data in multiple physical partitions called shards. Normally, in a production environment replica set is recommended. So, we are going to monitor the following key metrics.<\/p>\n\n\n\n MongoDB Server Metrics<\/strong><\/p>\n\n\n\n The monitoring and alerting of MongoDB server metrics are as important as capturing the MongoDB Database metrics. For example, CPU, and memory utilization of the server. This can tell us the overall load on the server, the server can also crash because of a high load, or your MongoDB service consumes the whole memory of the server. So, decide on a suitable threshold like 70% or 80%, and trigger an alert whenever utilization of these metrics crosses this threshold. Apart from that, we also need to consider Network I\/O and Disk I\/O metrics as well. If these metrics cross the threshold on regular basis with the normal working of the application and normal traffic, it indicates that we have under-provisioned our MongoDB cluster.<\/p>\n\n\n\n Tools We are going to use to Monitor MongoDB<\/strong><\/p>\n\n\n\n Setup MongoDB Exporter<\/strong><\/p>\n\n\n\n We are going to use MongoDB Exporter developed by Percona<\/a>. In the following steps, we will run MongoDB Exporter as a service along with Node Exporter on the MongoDB Server.<\/p>\n\n\n\n To isolate the ownership of the Prometheus Exporters services, we will create separate users without a home directory and shell so that nobody can log in to these users.<\/p>\n\n\n\n Afterward, Download the latest MongoDB Exporter from here<\/a>. Extract the archive file and copy the binary file to Now change the ownership of the binary file.<\/p>\n\n\n\n Accessing MongoDB should be authenticated and authorized. MongoDB Exporter going to get metrics from MongoDB Cluster. So, we need a user who can authenticate the MongoDB Database and should have the right set of permissions to read all the data. We need to create an Administrator account with clusterMonitor role.<\/p>\n\n\n\n The output should be like this:<\/p>\n\n\n\n Now We have to run the MongoDB Exporter service with the above mongodb_exporter user authentication with the following command in which we are going to provide the Now we have MongoDB Exporter binary, user, and mongodb_exporter user to authenticate the Database. The next step would be to create a service to run MongoDB Exporter Binary and collect metrics. Create the following file in To use the newly created service, reload We can restart the service after reloading the system daemon.<\/p>\n\n\n\n To check the status of the service, run the following command.<\/p>\n\n\n\n If we want to make sure that MongoDB Exporter service runs even after rebooting the server as well, we need to enable the service.<\/p>\n\n\n\n Setup Node Exporter<\/strong><\/p>\n\n\n\n Download the latest Node Exporter binary, click here<\/a><\/p>\n\n\n\n To set up the Node Exporter through Ansible, click here<\/a><\/p>\n\n\n\n To Install Node Exporter on Linux with Systemd service, click here<\/a>.<\/p>\n\n\n\n Setup Prometheus<\/strong><\/p>\n\n\n\n Download the latest Prometheus<\/strong> binary from here<\/a>.<\/p>\n\n\n\n To set up The Prometheus through Ansible, please click here<\/a>.<\/p>\n\n\n\n If you want to install Prometheus as a service, you can follow the steps from here<\/a>.<\/p>\n\n\n\n Setup Grafana<\/strong><\/p>\n\n\n\n To Download and Install Grafana please check here<\/a>.<\/p>\n\n\n\n To Set up the Grafana through Ansible, please click here<\/a>.<\/p>\n\n\n\n Configure MongoDB Exporter and Node Exporter with Prometheus<\/strong><\/p>\n\n\n\n To Configure MongoDB Exporter and Node Exporter with Prometheus, we need to add the following configuration in In targets, we need to add the server IP where exporters are running, and 9216 and 9100 is the port of MongoDB and Node Exporter.<\/p>\n\n\n\n Set Prometheus As Data Source<\/strong> in Grafana<\/p>\n\n\n\n Firstly we need to add Prometheus as the data source in Grafana to fetch the metrics data. Add the Datasource like below.<\/p>\n\n\n\n <\/p>\n\n\n\n Import MongoDB Dashboard<\/a> in Grafana<\/strong><\/p>\n\n\n\n After setting up Prometheus as a data source, we are going to import the MongoDB dashboard with the ID. This Id is a unique ID given by Grafana when we upload a custom dashboard. Screenshots of MongoDB Dashboard created by us<\/strong><\/p>\n\n\n\n Conclusion<\/strong><\/p>\n\n\n\n The purpose of this blog was to dig a little deeper into MongoDB Concepts. The use of the MongoDB database and identifying the key metrics which can be monitored. We also set up a fully operational end-to-end monitoring pipeline for MongoDB with respect to the metrics we talked about in this blog. We published the custom dashboard in Grafana, check here<\/a>.<\/p>\n\n\n\n Now, in our next blog, we will talk about MongoDB Monitoring from an SRE perspective.<\/p>\n\n\n\n Want to check other dashboards published by us, please check here<\/a>.<\/p>\n\n\n\n Blog Pundits: Naveen Verma<\/a> and Sandeep Rawat<\/a><\/strong><\/p>\n\n\n\n Opstree<\/a><\/strong>\u00a0is an End to End DevOps solution provider.<\/p>\n\n\n\ndb.serverStatus().connections<\/code> we can check the current, total, and active connections of the MongoDB database. If we plot these connections in a graph with history, we can also measure the peak, normal, and low traffic time. This helps us schedule the patching and upgrading activities of databases and applications.<\/p>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\nsudo useradd --no-create-home --shell \/bin\/false exporter<\/code><\/pre>\n\n\n\n\/use\/local\/bin<\/code>.<\/p>\n\n\n\nwget https:\/\/github.com\/percona\/mongodb_exporter\/releases\/download\/v0.34.0\/mongodb_exporter-0.34.0.linux-amd64.tar.gz\n\ntar xvzf mongodb_exporter-0.34.0.linux-amd64.tar.gz\n\nsudo mv mongodb_exporter \/usr\/local\/bin\/<\/code><\/pre>\n\n\n\nsudo chown exporter:exporter \/usr\/local\/bin\/mongodb_exporter<\/code><\/pre>\n\n\n\nuse admin\n\ndb.createUser(\n {\n user: \"mongodb_exporter\",\n pwd: \"password\",\n roles: [\n { role: \"clusterMonitor\", db: \"admin\" },\n { role: \"read\", db: \"local\" }\n ]\n }\n)<\/code><\/pre>\n\n\n\nSuccessfully added user: { \n \"user\" : \"mongodb_exporter\", \n \"roles\" : [ \n { \n \"role\" : \"clusterMonitor\",\n \"db\" : \"admin\" \n }, \n { \n \"role\" : \"read\", \n \"db\" : \"local\" \n } \n ] \n} <\/code><\/pre>\n\n\n\nMONGODB_URI<\/code> the parameter in the command line.<\/p>\n\n\n\n\/usr\/local\/bin\/mongodb_exporter --mongodb.uri=mongodb:\/\/mongodb_exporter:password@localhost:27017 --collect-all<\/code><\/pre>\n\n\n\n\/etc\/systemd\/system\/<\/code> directory to create a mongodb_exporter service.<\/p>\n\n\n\n[Unit]\nDescription=Mongodb Exporter\nWants=network-online.target\nAfter=network-online.target\n\n[Service]\nUser=exporter\nGroup=exporter\nType=simple\nExecStart=\/usr\/local\/bin\/mongodb_exporter --mongodb.uri=mongodb:\/\/mongodb_exporter:password@localhost:27017 --collect-all\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>\n\n\n\nsystemd<\/code>.<\/p>\n\n\n\nsudo systemctl daemon-reload<\/code><\/pre>\n\n\n\nsudo systemctl start mongodb_exporter.service<\/code><\/pre>\n\n\n\nsudo systemctl status mongodb_exporter.service<\/code><\/pre>\n\n\n\nsudo systemctl enable mongodb_exporter.service<\/code><\/pre>\n\n\n\nprometheus.yml<\/code>.<\/p>\n\n\n\n- job_name: 'mongodb'\n scrape_interval: 5s\n static_configs:\n - targets: ['mongodb_exporter_ip:9216', 'mongodb_exporter_ip:9100']<\/code><\/pre>\n\n\n\n<\/figure>\n\n\n\n
We need to click the Plus sign on the left menu bar from the Garfana homepage. Then click on the import, we will be on the import page, where we can provide a unique Garfana Dashboard ID and then load the dashboard. In this blog, we are going to import https:\/\/grafana.com\/grafana\/dashboards\/16490-opstree-mongodb-dashboard\/<\/code> this dashboard and the ID of this dashboard is 16490.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Or if we have a Dashboard in JSON format, or we downloaded the dashboard, we can import it by uploading the JSON file from the local machine.<\/p>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\n