监控 MongoDB

在本页面

• Monitoring Strategies

• MongoDB 报告工具

• Process Logging

• 诊断性能问题

• 复制和监视

• 分片和监视

• 存储节点看门狗

监视是所有数据库 Management 的重要组成部分。牢牢掌握 MongoDB 的报告，将使您能够评估数据库的状态并维持部署而不会出现危机。此外，MongoDB 的正常运行参数使您能够在问题升级为故障之前进行诊断。

本文档概述了 MongoDB 中可用的监视 Util 和报告统计信息。它还介绍了用于监视副本集和分片群集的诊断策略和建议。

Monitoring Strategies

有三种方法可以收集有关正在运行的 MongoDB 实例状态的数据：

• 首先，MongoDB 附带了一组 Util，可提供数据库活动的实时报告。

• 其次，database commands以更高的保真度返回有关当前数据库状态的统计信息。

• 第三，MongoDB Atlas是一种云托管的数据库即服务，用于运行，监视和维护 MongoDB 部署。 MongoDB 云 Management 器(托管服务和Ops Manager，MongoDB Enterprise Advanced 中提供的本地解决方案)提供监视以从正在运行的 MongoDB 部署中收集数据，并提供基于该数据的可视化和警报。

每种策略都可以帮助回答不同的问题，并且在不同的情况下很有用。这些方法是互补的。

MongoDB 报告工具

本节概述了随 MongoDB 分发的报告方法。它还提供了每种方法最适合您解决的各种问题的示例。

Utilities

MongoDB 发行版包含许多 Util，可快速返回有关实例性能和活动的统计信息。通常，这些对于诊断问题和评估正常操作最有用。

mongostat

mongostat按类型(例如插入，查询，更新，删除等)捕获并返回数据库操作的计数。这些计数报告服务器上的负载分布。

使用mongostat可以了解操作类型的分布并通知容量计划。有关详情，请参见mongostat manual。

mongotop

mongotop跟踪并报告 MongoDB 实例的当前读写活动，并基于每个集合报告这些统计信息。

使用mongotop检查您的数据库活动和使用是否符合您的期望。有关详情，请参见mongotop manual。

HTTP Console

在版本 3.6 中进行了更改：MongoDB 3.6 删除了 MongoDB 弃用的 HTTP 接口和 REST API。

Commands

MongoDB 包含许多报告数据库状态的命令。

这些数据可以提供比上面讨论的 Util 更好的粒度级别。考虑在脚本和程序中使用它们的输出来开发自定义警报，或者根据实例的活动来修改应用程序的行为。 db.currentOp方法是用于识别数据库实例正在进行的操作的另一个有用工具。

serverStatus

Shell 程序中的serverStatus命令或db.serverStatus()返回数据库状态的一般概述，其中详细介绍了磁盘使用情况，内存使用情况，连接，日记和索引访问。该命令将快速返回，并且不会影响 MongoDB 的性能。

serverStatus输出一个 MongoDB 实例状态的帐户。此命令很少直接运行。在大多数情况下，汇总数据时更有意义，就像使用MongoDB 云 Management 器和Ops Manager监视工具所看到的那样。但是，所有 Management 员都应该熟悉serverStatus提供的数据。

dbStats

Shell 程序中的dbStats命令或db.stats()返回一个文档，该文档涉及存储使用和数据量。 dbStats反映使用的存储量，数据库中包含的数据量以及对象，集合和索引计数器。

使用此数据监视特定数据库的状态和存储容量。此输出还允许您比较数据库之间的使用情况，并确定数据库中的平均document大小。

collStats

Shell 程序中的collStats或db.collection.stats()提供了类似于集合级别dbStats的统计信息，包括集合中对象的数量，集合的大小，集合使用的磁盘空间量以及有关其索引的信息。

replSetGetStatus

replSetGetStatus命令(来自 Shell 程序的rs.status())返回副本集状态的概述。 replSetGetStatus文档详细说明了副本集的状态和配置以及有关其成员的统计信息。

使用此数据可确保正确配置了复制，并检查了当前主机与副本集的其他成员之间的连接。

托管(SaaS)监视工具

这些是作为托管服务提供的监视工具，通常通过付费订阅提供。

Process Logging

在正常操作期间，mongod和mongos实例向标准输出或日志文件报告所有服务器活动和操作的实时帐户。以下运行时设置控制这些选项。

• quiet。限制写入日志或输出的信息量。

• verbosity。增加写入日志或输出的信息量。您还可以在运行时使用 Shell 中的logLevel参数或db.setLogLevel()方法修改日志记录的详细程度。

• path。启用日志记录到文件，而不是标准输出。调整此设置时，必须指定日志文件的完整路径。

• logAppend。将信息添加到日志文件，而不是覆盖文件。

mongod -v --logpath /var/log/mongodb/server1.log --logappend

以下database commands也影响日志记录：

• getLog。显示来自mongod进程日志的最新消息。

• logRotate。仅旋转mongod个进程的日志文件。参见旋转日志文件。

Log Redaction

3.4 版中的新功能：仅在 MongoDB Enterprise 中可用

在记录之前，与任何给定的日志事件关联的mongod与_都会编辑messages，仅保留与该事件相关的元数据，源文件或行号。 security.redactClientLogData防止潜在的敏感信息进入系统日志，而这会花费诊断详细信息。

例如，以下操作将文档插入运行中的mongod，而无需编辑日志。 mongod的systemLog.component.command.verbosity设置为1：

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

此操作将产生以下日志事件：

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

mongod与security.redactClientLogData运行并执行相同的插入操作将产生以下日志事件：

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

redactClientLogData与静态加密和TLS/SSL(传输加密)结合使用可帮助遵守法规要求。

诊断性能问题

使用 MongoDB 开发和操作应用程序时，您可能需要分析数据库作为应用程序的性能。 MongoDB Performance讨论了一些可能影响性能的操作因素。

复制和监视

除了任何 MongoDB 实例的基本监视要求之外，对于副本集，Management 员还必须监视复制滞后。 “复制滞后”是指将对primary的写操作复制(即复制)到secondary所花费的时间。可以接受一些小的延迟时间，但是随着复制滞后的增加，出现了两个重大问题：

• 首先，在滞后期间发生的操作不会复制到一个或多个次级。如果您使用复制来确保数据的持久性，那么特别长的延迟可能会影响数据集的完整性。

• 其次，如果复制滞后超过操作日志(oplog)的长度，则 MongoDB 将必须在辅助数据库上执行初始同步，从primary复制所有数据并重建所有索引。在正常情况下，这种情况并不常见，但是如果您将操作日志配置为小于默认值，则可能会出现问题。

有关复制延迟的原因，请参见Replication Lag。

复制问题通常是由于成员之间的网络连接问题，或者是由于primary没有资源来支持应用程序和复制流量而导致的。要检查副本的状态，请在 Shell 程序中使用replSetGetStatus或以下帮助器：

rs.status()

replSetGetStatus参考提供了此输出的更深入的概述视图。通常，请注意optimeDate的值，并特别注意primary和secondary成员之间的时间差。

分片和监视

在大多数情况下，sharded clusters的组件将与所有其他 MongoDB 实例一样受益于相同的监视和分析。此外，群集需要进一步监视以确保数据在节点之间有效分布，并且分片操作正常运行。

Config Servers

config database维护一个 Map，该 Map 标识哪些文档位于哪些分片上。当分片之间chunks移动时，集群会更新此 Map。当无法访问配置服务器时，某些分片操作将变得不可用，例如移动块和启动mongos实例。但是，仍然可以从已运行的mongos实例访问群集。

由于无法访问的配置服务器会严重影响分片群集的可用性，因此，您应该监视配置服务器，以确保群集保持良好的平衡并且mongos实例可以重新启动。

MongoDB 云 Management 器和Ops Manager监视配置服务器，并可以在无法访问配置服务器时创建通知。有关更多信息，请参见MongoDB Cloud Manager 文档和Ops Manager 文档。

平衡和块分配

最有效的sharded cluster部署在各个分片之间平均平衡chunks。为了促进这一点，MongoDB 具有一个balancer后台进程，该进程分配数据以确保在shards之间始终始终以最佳方式分配块。

通过mongo shell 向mongos发出db.printShardingStatus()或sh.status()命令。这将返回整个集群的概述，包括数据库名称和块列表。

Stale Locks

要检查数据库的锁定状态，请使用mongo shell 连接到mongos实例。发出以下命令序列以切换到config数据库并在分片数据库上显示所有未完成的锁定：

use config
db.locks.find()

平衡过程采用特殊的“平衡器”锁，以防止发生其他平衡活动。在config数据库中，使用以下命令查看“ balancer”锁。

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

在版本 3.4 中进行了更改：从 3.4 开始，CSRS 配置服务器的主服务器使用名为“ ConfigServer”的进程 ID 持有“ balancer”锁。此锁永远不会释放。要确定平衡器是否正在运行，请参阅检查平衡器是否正在运行。

存储节点看门狗

3.6 版的新功能。

存储节点看门狗监视 MongoDB 使用的文件系统以检测无响应的条件。

可以通过mongod上的watchdogPeriodSeconds参数启用存储节点看门狗。

启用后，存储节点看门狗将监视以下目录：

• --dbpath目录

• 如果启用了journaling，则--dbpath目录中的journal目录

• --logpath文件的目录

• --auditPath文件的目录

如果包含这些目录的任何文件系统变得无响应，则存储节点看门狗终止mongod并以状态代码 61 退出。如果mongod充当primary，则终止将启动failover，从而允许另一个成员成为主用户。

mongod终止后，可能无法在相同的计算机上彻底重启它。

存储节点看门狗用来检测无响应的文件系统并终止所需的最大时间几乎是watchdogPeriodSeconds的值的两倍。

• 在 Linux 上使用 SNMP 监视 MongoDB

• 使用 SNMP 监视 MongoDB Windows

• Troubleshoot SNMP