> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Monitoring a Self-Managed MongoDB Deployment Monitoring is a critical component of all database administration. A firm grasp of MongoDB's reporting will allow you to assess the state of your database and maintain your deployment without crisis. Additionally, a sense of MongoDB's normal operational parameters will allow you to diagnose problems before they escalate to failures. This document presents an overview of the available monitoring utilities and the reporting statistics available in MongoDB. It also introduces diagnostic strategies and suggestions for monitoring replica sets and sharded clusters. ## Monitoring Strategies MongoDB provides various methods for collecting data about the state of a running MongoDB instance: - MongoDB distributes a set of utilities that provides real-time reporting of database activities. - MongoDB provides various [database commands](https://www.mongodb.com/docs/manual/reference/command.md#std-label-database-commands) that return statistics regarding the current database state with greater fidelity. - [MongoDB Atlas](https://www.mongodb.com/atlas/database) is a cloud-hosted database-as-a-service for running, monitoring, and maintaining MongoDB deployments. - [MongoDB Cloud Manager](https://www.mongodb.com/products/tools/cloud-manager) is a hosted service that monitors running MongoDB deployments to collect data and provide visualization and alerts based on that data. - MongoDB Ops Manager is [an on-premises solution available in MongoDB Enterprise Advanced](https://www.mongodb.com/products/mongodb-enterprise-advanced) that monitors running MongoDB deployments to collect data and provide visualization and alerts based on that data. Each strategy can help answer different questions and is useful in different contexts. These methods are complementary. ## MongoDB Reporting Tools This section provides an overview of the reporting methods distributed with MongoDB. It also offers examples of the kinds of questions that each method is best suited to help you address. ### Utilities The MongoDB distribution includes a number of utilities that quickly return statistics about instances' performance and activity. Typically, these are most useful for diagnosing issues and assessing normal operation. #### `mongostat` [`mongostat`](https://www.mongodb.com/docs/database-tools/mongostat.md#mongodb-binary-bin.mongostat) captures and returns the counts of database operations by type (e.g. insert, query, update, delete, etc.). These counts report on the load distribution on the server. Use [`mongostat`](https://www.mongodb.com/docs/database-tools/mongostat.md#mongodb-binary-bin.mongostat) to understand the distribution of operation types and to inform capacity planning. See the [`mongostat`](https://www.mongodb.com/docs/database-tools/mongostat.md#mongodb-binary-bin.mongostat) reference page for details. #### `mongotop` [`mongotop`](https://www.mongodb.com/docs/database-tools/mongotop.md#mongodb-binary-bin.mongotop) tracks and reports the current read and write activity of a MongoDB instance, and reports these statistics on a per collection basis. Use [`mongotop`](https://www.mongodb.com/docs/database-tools/mongotop.md#mongodb-binary-bin.mongotop) to check if your database activity and use match your expectations. See the [`mongotop`](https://www.mongodb.com/docs/database-tools/mongotop.md#mongodb-binary-bin.mongotop) reference page for details. ### Commands MongoDB includes a number of commands that report on the state of the database. These data may provide a finer level of granularity than the utilities discussed above. Consider using their output in scripts and programs to develop custom alerts, or to modify the behavior of your application in response to the activity of your instance. The [`db.currentOp()`](https://www.mongodb.com/docs/manual/reference/method/db.currentop.md#mongodb-method-db.currentOp) method is another useful tool for identifying the database instance's in-progress operations. #### `serverStatus` The [`serverStatus`](https://www.mongodb.com/docs/manual/reference/command/serverstatus.md#mongodb-dbcommand-dbcmd.serverStatus) command, or [`db.serverStatus()`](https://www.mongodb.com/docs/manual/reference/method/db.serverstatus.md#mongodb-method-db.serverStatus) from the shell, returns a general overview of the status of the database, detailing disk usage, memory use, connection, journaling, and index access. The command returns quickly and does not impact MongoDB performance. [`serverStatus`](https://www.mongodb.com/docs/manual/reference/command/serverstatus.md#mongodb-dbcommand-dbcmd.serverStatus) outputs an account of the state of a MongoDB instance. This command is rarely run directly. In most cases, the data is more meaningful when aggregated, as one would see with monitoring tools including [MongoDB Cloud Manager](https://www.mongodb.com/products/tools/cloud-manager) and [Ops Manager](https://www.mongodb.com/products/mongodb-enterprise-advanced). Nevertheless, all administrators should be familiar with the data provided by [`serverStatus`.](https://www.mongodb.com/docs/manual/reference/command/serverstatus.md#mongodb-dbcommand-dbcmd.serverStatus) #### `dbStats` The [`dbStats`](https://www.mongodb.com/docs/manual/reference/command/dbstats.md#mongodb-dbcommand-dbcmd.dbStats) command, or [`db.stats()`](https://www.mongodb.com/docs/manual/reference/method/db.stats.md#mongodb-method-db.stats) from the shell, returns a document that addresses storage use and data volumes. The [`dbStats`](https://www.mongodb.com/docs/manual/reference/command/dbstats.md#mongodb-dbcommand-dbcmd.dbStats) reflect the amount of storage used, the quantity of data contained in the database, and object, collection, and index counters. Use this data to monitor the state and storage capacity of a specific database. This output also allows you to compare use between databases and to determine the average [document](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-document) size in a database. #### `collStats` The [`collStats`](https://www.mongodb.com/docs/manual/reference/command/collstats.md#mongodb-dbcommand-dbcmd.collStats) or [`db.collection.stats()`](https://www.mongodb.com/docs/manual/reference/method/db.collection.stats.md#mongodb-method-db.collection.stats) from the shell that provides statistics that resemble [`dbStats`](https://www.mongodb.com/docs/manual/reference/command/dbstats.md#mongodb-dbcommand-dbcmd.dbStats) on the collection level, including a count of the objects in the collection, the size of the collection, the amount of disk space used by the collection, and information about its indexes. #### `replSetGetStatus` The [`replSetGetStatus`](https://www.mongodb.com/docs/manual/reference/command/replsetgetstatus.md#mongodb-dbcommand-dbcmd.replSetGetStatus) command ([`rs.status()`](https://www.mongodb.com/docs/manual/reference/method/rs.status.md#mongodb-method-rs.status) from the shell) returns an overview of your replica set's status. The `replSetGetStatus` document details the state and configuration of the replica set and statistics about its members. Use this data to ensure that replication is properly configured, and to check the connections between the current host and the other members of the replica set. #### Hosted (SaaS) Monitoring Tools These are monitoring tools provided as a hosted service, usually through a paid subscription. | Name | Notes | | --- | --- | | [MongoDB Cloud Manager](https://www.mongodb.com/products/tools/cloud-manager) | MongoDB Cloud Manager is a cloud-based suite of services for managing MongoDB deployments. MongoDB Cloud Manager provides monitoring, backup, and automation functionality. For an on-premises solution, see also [Ops Manager, available in MongoDB Enterprise Advanced.](https://www.mongodb.com/products/mongodb-enterprise-advanced) | | [VividCortex](https://www.vividcortex.com/) | VividCortex provides deep insights into MongoDB [production database workload and query performance](https://www.vividcortex.com/product/how-it-works) -- in one-second resolution. Track latency, throughput, errors, and more to ensure scalability and exceptional performance of your application on MongoDB. | | [Server Density](http://www.serverdensity.com) | [Dashboard for MongoDB](http://www.serverdensity.com/mongodb-monitoring/), MongoDB specific alerts, replication failover timeline and iPhone, iPad and Android mobile apps. | | [Application Performance Management](http://ibmserviceengage.com) | IBM has an Application Performance Management SaaS offering that includes monitor for MongoDB and other applications and middleware. | | [New Relic](http://newrelic.com/) | New Relic offers full support for application performance management. In addition, New Relic Plugins and Insights enable you to view monitoring metrics from Cloud Manager in New Relic. | | [Datadog](https://www.datadoghq.com/) | [Infrastructure monitoring](http://docs.datadoghq.com/integrations/mongodb/) to visualize the performance of your MongoDB deployments. | | [SPM Performance Monitoring](https://sematext.com/spm) | [Monitoring, Anomaly Detection and Alerting](https://sematext.com/spm/integrations/mongodb-monitoring/) SPM monitors all key MongoDB metrics together with infrastructure incl. Docker and other application metrics, e.g. Node.js, Java, NGINX, Apache, HAProxy or Elasticsearch. SPM provides correlation of metrics and logs. | | [Pandora FMS](http://www.pandorafms.com/) | Pandora FMS provides the [PandoraFMS-mongodb-monitoring](http://blog.pandorafms.org/how-to-monitor-mongodb-or-how-to-keep-your-users-happy/) plugin to monitor MongoDB. | ## Process Logging During normal operation, [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) and [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instances report a live account of all server activity and operations to either standard output or a log file. The following runtime settings control these options. - [`quiet`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.quiet). Limits the amount of information written to the log or output. - [`verbosity`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.verbosity). Increases the amount of information written to the log or output. You can also modify the logging verbosity during runtime with the [`logLevel`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.logLevel) parameter or the [`db.setLogLevel()`](https://www.mongodb.com/docs/manual/reference/method/db.setloglevel.md#mongodb-method-db.setLogLevel) method in the shell. - [`path`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.path). Enables logging to a file, rather than the standard output. You must specify the full path to the log file when adjusting this setting. - [`logAppend`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.logAppend). Adds information to a log file instead of overwriting the file. **Note:** You can specify these configuration operations as the command line arguments to [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) or [`mongos`.](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) For example: ```javascript mongod -v --logpath /var/log/mongodb/server1.log --logappend ``` Starts a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) instance in [`verbose`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-systemLog.verbosity) mode, appending data to the log file at `/var/log/mongodb/server1.log/`. The following [database commands](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-database-command) also affect logging: - [`getLog`](https://www.mongodb.com/docs/manual/reference/command/getlog.md#mongodb-dbcommand-dbcmd.getLog). Displays recent messages from the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) process log. - [`logRotate`](https://www.mongodb.com/docs/manual/reference/command/logrotate.md#mongodb-dbcommand-dbcmd.logRotate). Rotates the log files for [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) processes only. See [Rotate Log Files.](https://www.mongodb.com/docs/manual/tutorial/rotate-log-files.md) ### Log Redaction *Available in MongoDB Atlas and MongoDB Enterprise only* A [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) or [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) running with [`redactClientLogData`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.redactClientLogData) redacts any message accompanying a given log event before logging, leaving only metadata, source files, or line numbers related to the event. [`redactClientLogData`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.redactClientLogData) prevents potentially sensitive information from entering the system log at the cost of diagnostic detail. For example, the following operation inserts a document into a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) running without log redaction. The [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) has the [log verbosity level](https://www.mongodb.com/docs/manual/reference/log-messages.md#std-label-log-messages-configure-verbosity) set to `1`: ```javascript db.clients.insertOne( { "name" : "Joe", "PII" : "Sensitive Information" } ) ``` This operation produces the following log event: ```javascript { "t": { "$date": "2024-07-19T15:36:55.024-07:00" }, "s": "I", "c": "COMMAND", ... "attr": { "type": "command", ... "appName": "mongosh 2.2.10", "command": { "insert": "clients", "documents": [ { "name": "Joe", "PII": "Sensitive Information", "_id": { "$oid": "669aea8792c7fd822d3e1d8c" } } ], "ordered": true, ... } ... } } ``` When [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) runs with [`redactClientLogData`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.redactClientLogData) and performs the same insert operation, it produces the following log event: ```javascript { "t": { "$date": "2024-07-19T15:36:55.024-07:00" }, "s": "I", "c": "COMMAND", ... "attr": { "type": "command", ... "appName": "mongosh 2.2.10", "command": { "insert": "###", "documents": [ { "name": "###", "PII": "###", "_id": "###" } ], "ordered": "###", ... } ... } } ``` Use [`redactClientLogData`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.redactClientLogData) in conjunction with [Encryption at Rest](https://www.mongodb.com/docs/manual/core/security-encryption-at-rest.md#std-label-security-encryption-at-rest) and [TLS/SSL (Transport Encryption)](https://www.mongodb.com/docs/manual/core/security-transport-encryption.md#std-label-transport-encryption) to assist compliance with regulatory requirements. ## Diagnosing Performance Issues As you develop and operate applications with MongoDB, you may want to analyze the performance of the database as the application. [MongoDB Performance](https://www.mongodb.com/docs/manual/administration/analyzing-mongodb-performance.md#std-label-performance) discusses some of the operational factors that can influence performance. ## Replication and Monitoring Beyond the basic monitoring requirements for any MongoDB instance, for replica sets, administrators must monitor *replication lag*. "Replication lag" refers to the amount of time that it takes to copy (i.e. replicate) a write operation on the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) to a [secondary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-secondary). Some small delay period may be acceptable, but significant problems emerge as replication lag grows, including: - Growing cache pressure on the primary. - Operations that occurred during the period of lag are not replicated to one or more secondaries. If you're using replication to ensure data persistence, exceptionally long delays may impact the integrity of your data set. - If the replication lag exceeds the length of the operation log ([oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog)) then MongoDB will have to perform an initial sync on the secondary, copying all data from the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) and rebuilding all indexes. This is uncommon under normal circumstances, but if you configure the oplog to be smaller than the default, the issue can arise. **Note:** The size of the oplog is only configurable during the first run using the [`--oplogSize`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--oplogSize) argument to the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) command, or preferably, the [`oplogSizeMB`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-replication.oplogSizeMB) setting in the MongoDB configuration file. If you do not specify this on the command line before running with the [`--replSet`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--replSet) option, [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) will create a default sized oplog. By default, the oplog is 5 percent of total available disk space on 64-bit systems. For more information about changing the oplog size, see the [Change the Oplog Size of Self-Managed Replica Set Members.](https://www.mongodb.com/docs/manual/tutorial/change-oplog-size.md) ### Flow Control Administrators can limit the rate at which the primary applies its writes with the goal of keeping the [`majority committed`](https://www.mongodb.com/docs/manual/reference/command/replsetgetstatus.md#mongodb-data-replSetGetStatus.optimes.lastCommittedOpTime) lag under a configurable maximum value [`flowControlTargetLagSeconds`.](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.flowControlTargetLagSeconds) By default, flow control is [`enabled`.](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.enableFlowControl) See also: [Check the Replication Lag.](https://www.mongodb.com/docs/manual/tutorial/troubleshoot-replica-sets.md#std-label-replica-set-replication-lag) ### Replica Set Status Replication issues are most often the result of network connectivity issues between members, or the result of a [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) that does not have the resources to support application and replication traffic. To check the status of a replica, use the [`replSetGetStatus`](https://www.mongodb.com/docs/manual/reference/command/replsetgetstatus.md#mongodb-dbcommand-dbcmd.replSetGetStatus) or the following helper in the shell: ```javascript rs.status() ``` The [`replSetGetStatus`](https://www.mongodb.com/docs/manual/reference/command/replsetgetstatus.md#mongodb-dbcommand-dbcmd.replSetGetStatus) reference provides a more in-depth overview view of this output. In general, watch the value of [`optimeDate`](https://www.mongodb.com/docs/manual/reference/command/replsetgetstatus.md#mongodb-data-replSetGetStatus.members-n-.optimeDate), and pay particular attention to the time difference between the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) and the [secondary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-secondary) members. The oplog can grow past its configured size limit to avoid deleting the [`majority commit point`.](https://www.mongodb.com/docs/manual/reference/command/replsetgetstatus.md#mongodb-data-replSetGetStatus.optimes.lastCommittedOpTime) ### Slow Application of Oplog Entries Secondary members of a replica set now [log oplog entries](https://www.mongodb.com/docs/manual/core/replica-set-oplog.md#std-label-slow-oplog-application) that take longer than the slow operation threshold to apply. These slow oplog messages: - Are logged for the secondaries in the [`diagnostic log`.](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--logpath) - Are logged under the [`REPL`](https://www.mongodb.com/docs/manual/reference/log-messages.md#mongodb-data-REPL) component with the text `applied op: took ms`. - Do not depend on the log levels (either at the system or component level) - Do not depend on the profiling level. - Are affected by [`slowOpSampleRate`.](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-operationProfiling.slowOpSampleRate) The profiler does not capture slow oplog entries. ## Sharding and Monitoring In most cases, the components of [sharded clusters](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-sharded-cluster) benefit from the same monitoring and analysis as all other MongoDB instances. In addition, clusters require further monitoring to ensure that data is effectively distributed among nodes and that sharding operations are functioning appropriately. **See also:** See the [Sharding](https://www.mongodb.com/docs/manual/sharding.md) documentation for more information. ### Config Servers The [config database](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-config-database) maintains a map identifying which documents are on which shards. The cluster updates this map as [chunks](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-chunk) move between shards. When a configuration server becomes inaccessible, certain sharding operations become unavailable, such as moving chunks and starting [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instances. However, clusters remain accessible from already-running [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instances. Because inaccessible configuration servers can seriously impact the availability of a sharded cluster, you should monitor your configuration servers to ensure that the cluster remains well balanced and that [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instances can restart. [MongoDB Cloud Manager](https://www.mongodb.com/products/tools/cloud-manager) and [Ops Manager](https://www.mongodb.com/products/mongodb-enterprise-advanced) monitor config servers and can create notifications if a config server becomes inaccessible. See the [MongoDB Cloud Manager documentation](https://www.mongodb.com/docs/cloud-manager/) and [Ops Manager documentation](https://www.mongodb.com/docs/ops-manager/current/application/) for more information. ### Balancing and Chunk Distribution The most effective [sharded cluster](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-sharded-cluster) deployments evenly balance [chunks](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-chunk) among the shards. To facilitate this, MongoDB has a background [balancer](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-balancer) process that distributes data to ensure that chunks are always optimally distributed among the [shards.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-shard) Issue the [`db.printShardingStatus()`](https://www.mongodb.com/docs/manual/reference/method/db.printshardingstatus.md#mongodb-method-db.printShardingStatus) or [`sh.status()`](https://www.mongodb.com/docs/manual/reference/method/sh.status.md#mongodb-method-sh.status) command to the [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) from within [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh). This returns an overview of the entire cluster including the database name, and a list of the chunks. ### Stale Locks To check the lock status of the database, connect to a [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) instance using [`mongosh`](https://www.mongodb.com/docs/mongodb-shell.md#mongodb-binary-bin.mongosh). Issue the following command sequence to switch to the `config` database and display all outstanding locks on the shard database: ```javascript use config db.locks.find() ``` The balancing process takes a special "balancer" lock that prevents other balancing activity from transpiring. In the `config` database, use the following command to view the "balancer" lock. ```javascript db.locks.find( { _id : "balancer" } ) ``` The primary of the CSRS config server holds the "balancer" lock, using a process ID named "ConfigServer". This lock is never released. To determine if the balancer is running, see [Check if Balancer is Running.](https://www.mongodb.com/docs/manual/tutorial/manage-sharded-cluster-balancer.md#std-label-sharding-balancing-is-running) ## Storage Node Watchdog **Note:** The [Storage Node Watchdog](https://www.mongodb.com/docs/manual/administration/monitoring.md#std-label-storage-node-watchdog) is available in both the Community and MongoDB Enterprise editions. The Storage Node Watchdog monitors the following MongoDB directories to detect filesystem unresponsiveness: - The [`--dbpath`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--dbpath) directory - The `journal` directory inside the [`--dbpath`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--dbpath) directory - The directory of [`--logpath`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--logpath) file - The directory of [`--auditPath`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--auditPath) file **Note:** Starting in MongoDB 6.1, journaling is always enabled. As a result, MongoDB removes the `storage.journal.enabled` option and the corresponding `--journal` and `--nojournal` command-line options. By default, the Storage Node Watchdog is disabled. You can only enable the Storage Node Watchdog on a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) at startup time by setting the [`watchdogPeriodSeconds`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.watchdogPeriodSeconds) parameter to an integer greater than or equal to 60. However, once enabled, you can pause the Storage Node Watchdog and restart during runtime. See [`watchdogPeriodSeconds`](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.watchdogPeriodSeconds) parameter for details. If any of the filesystems containing the monitored directories become unresponsive, the Storage Node Watchdog terminates the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) and exits with a status code of 61. If the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) is the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) of a replica set, the termination initiates a [failover](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-failover), allowing another member to become primary. Once a [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) has terminated, it may not be possible to cleanly restart it on the *same* machine. **Note: Symlinks** If any of its monitored directories is a symlink to other volumes, the Storage Node Watchdog does not monitor the symlink target. For example, if the [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) uses [`storage.directoryPerDB: true`](https://www.mongodb.com/docs/manual/reference/configuration-options.md#mongodb-setting-storage.directoryPerDB) (or [`--directoryperdb`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#std-option-mongod.--directoryperdb)) and symlinks a database directory to another volume, the Storage Node Watchdog does not follow the symlink to monitor the target. The maximum time the Storage Node Watchdog can take to detect an unresponsive filesystem and terminate is nearly *twice* the value of [`watchdogPeriodSeconds`.](https://www.mongodb.com/docs/manual/reference/parameters.md#mongodb-parameter-param.watchdogPeriodSeconds)