Monitoring for MongoDB监测MongoDB

Free Monitoring免费监控

MongoDB offers free Cloud monitoring for standalones or replica sets.MongoDB为Standalone或副本集提供免费云监控。

By default, you can enable/disable free monitoring during runtime using db.enableFreeMonitoring() and db.disableFreeMonitoring().默认情况下，可以使用db.enableFreeMonitoring()和db.disableFreeMonitoring()在运行时启用/禁用自由监视。

Free monitoring provides up to 24 hours of data. 免费监控可提供多达24小时的数据。For more details, see Free Monitoring.有关更多详细信息，请参阅免费监控。

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.MongoDB发行版包括许多实用程序，可以快速返回有关实例性能和活动的统计信息。通常，这些对诊断问题和评估正常运行最有用。

Commands命令

MongoDB includes a number of commands that report on the state of the database.MongoDB包含许多报告数据库状态的命令。

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() method is another useful tool for identifying the database instance's in-progress operations.db.currentOp()方法是另一个用于识别数据库实例正在进行的操作的有用工具。

Log Redaction日志编辑

Available in MongoDB Enterprise only仅在MongoDB Enterprise中提供

A mongod running with security.redactClientLogData redacts messages associated with any given log event before logging, leaving only metadata, source files, or line numbers related to the event. 使用security.redactClientLogData运行的mongod会在记录之前对与任何给定日志事件相关的消息进行编辑，只留下与事件相关的元数据、源文件或行号。security.redactClientLogData prevents potentially sensitive information from entering the system log at the cost of diagnostic detail.security.redactClientLogData防止潜在的敏感信息进入系统日志，但会以牺牲诊断细节为代价。

For example, the following operation inserts a document into a mongod running without log redaction. The mongod has systemLog.component.command.verbosity set to 1:例如，以下操作将一个文档插入到运行时没有日志编辑的mongod中。mongod将systemLog.component.command.verbosity设置为1：

db.clients.insertOne( { "name" : "Joe", "PII" : "Sensitive Information" } )

This operation produces the following log event:此操作将生成以下日志事件：

2017-06-09T13:35:23.446-04:00 I COMMAND  [conn1] command internal.clients
   appName: "MongoDB Shell"
   command: insert {
      insert: "clients",
      documents: [ {
            _id: ObjectId('593adc5b99001b7d119d0c97'),
            name: "Joe",
            PII: " Sensitive Information"
         } ],
      ordered: true
   }
   ...

A mongod running with security.redactClientLogData performing the same insert operation produces the following log event:使用security.redactClientLogData运行的mongod执行相同的插入操作，会生成以下日志事件：

2017-06-09T13:45:18.599-04:00 I COMMAND  [conn1] command internal.clients
   appName: "MongoDB Shell"
   command: insert {
      insert: "###", documents: [ {
         _id: "###", name: "###", PII: "###"
      } ],
      ordered: "###"
   }

Use redactClientLogData in conjunction with Encryption at Rest and TLS/SSL (Transport Encryption) to assist compliance with regulatory requirements.将redactClientLogData与Rest加密和TLS/SSL（传输加密）结合使用，以帮助遵守法规要求。

Flow Control流量控制

Starting in MongoDB 4.2, administrators can limit the rate at which the primary applies its writes with the goal of keeping the majority committed lag under a configurable maximum value flowControlTargetLagSeconds.从MongoDB 4.2开始，管理员可以限制主应用其写操作的速率，目的是将大多数提交的延迟保持在可配置的最大值flowControlTargetLagSeconds之下。

By default, flow control is enabled.默认情况下，流量控制处于启用状态。

See also: Check the Replication Lag.另请参见：检查复制延迟。

Replica Set Status副本集状态

Replication issues are most often the result of network connectivity issues between members, or the result of a primary that does not have the resources to support application and replication traffic. 复制问题通常是由于成员之间的网络连接问题，或者是由于primary没有资源来支持应用程序和复制流量。To check the status of a replica, use the replSetGetStatus or the following helper in the shell:要检查副本的状态，请使用replSetGetStatus或shell中的以下帮助程序：

rs.status()

The replSetGetStatus reference provides a more in-depth overview view of this output. replSetGetStatus参考提供了此输出的更深入的概览视图。In general, watch the value of optimeDate, and pay particular attention to the time difference between the primary and the secondary members.一般来说，注意optimeDate的值，并特别注意主要成员和次要成员之间的时间差。

Free Monitoring免费监控

Slow Application of Oplog EntriesOplog条目应用缓慢

Starting in version 4.2 (also available starting in 4.0.6), secondary members of a replica set now log oplog entries that take longer than the slow operation threshold to apply. 从版本4.2开始（也可从4.0.6开始使用），副本集的次要成员现在会记录需要比慢速操作阈值更长时间才能应用的oplog条目。These slow oplog messages:这些缓慢的oplog消息：

• Are logged for the secondaries in the diagnostic log.在诊断日志中记录辅助设备的。
• Are logged under the REPL component with the text applied op: <oplog entry> took <num>ms.记录在REPL组件下，文本为applied op: <oplog entry> took <num>ms。
• Do not depend on the log levels (either at the system or component level)不要依赖于日志级别（系统或组件级别）
• Do not depend on the profiling level.不要依赖于分析级别。

• May be affected by slowOpSampleRate, depending on your MongoDB version:可能会受到slowOpSampleRate的影响，具体取决于您的MongoDB版本：

  • In MongoDB 4.2 and earlier, these slow oplog entries are not affected by the slowOpSampleRate. 在MongoDB 4.2及更早版本中，这些缓慢的oplog条目不受slowOpSampleRate的影响。MongoDB logs all slow oplog entries regardless of the sample rate.无论采样率如何，MongoDB都会记录所有慢速oplog条目。
  • In MongoDB 4.4 and later, these slow oplog entries are affected by the slowOpSampleRate.在MongoDB 4.4及更高版本中，这些较慢的oplog条目会受到slowOpSampleRate的影响。

The profiler does not capture slow oplog entries.探查器不会捕获较慢的oplog条目。

Config Servers配置服务器

The config database maintains a map identifying which documents are on which shards. 配置数据库维护一个地图，标识哪些文档在哪些分片上。The cluster updates this map as chunks move between shards. 当区块在分片之间移动时，集群会更新此地图。When a configuration server becomes inaccessible, certain sharding operations become unavailable, such as moving chunks and starting mongos instances. 当配置服务器变得不可访问时，某些分片操作将变得不可用，例如移动块和启动mongos实例。However, clusters remain accessible from already-running mongos instances.但是，集群仍然可以从已经运行的mongos实例访问。

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 instances can restart.由于无法访问的配置服务器会严重影响分片集群的可用性，因此您应该监控配置服务器，以确保集群保持良好平衡，并且mongos实例可以重新启动。

MongoDB Cloud Manager and Ops Manager monitor config servers and can create notifications if a config server becomes inaccessible. MongoDB云管理器和Ops Manager监控配置服务器，并在配置服务器无法访问时创建通知。See the MongoDB Cloud Manager documentation and Ops Manager documentation for more information.有关更多信息，请参阅MongoDB云管理器文档和Ops Manager文档。

Balancing and Chunk Distribution平衡和组块分布

The most effective sharded cluster deployments evenly balance chunks among the shards. 最有效的分片集群部署会在分片之间均匀地平衡块。To facilitate this, MongoDB has a background balancer process that distributes data to ensure that chunks are always optimally distributed among the shards.为了便于实现这一点，MongoDB有一个后台均衡器进程，用于分配数据，以确保块始终以最佳方式分布在分片之间。

Issue the db.printShardingStatus() or sh.status() command to the mongos from within mongosh. 从mongosh内部向mongos发出db.printShardingStatus()或sh.status()命令。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 instance using mongosh. 要检查数据库的锁定状态，请使用mongosh连接到mongos实例。Issue the following command sequence to switch to the config database and display all outstanding locks on the shard database:发出以下命令序列以切换到config数据库并显示分片数据库上所有未完成的锁：

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.在config数据库中，使用以下命令查看“均衡器”锁。

db.locks.find( { _id : "balancer" } )