监控自托管 MongoDB 部署

监控策略

MongoDB 提供了各种方法来收集有关运行中的 MongoDB 实例状态的数据。

• MongoDB 分发了一套实用程序，它可以提供数据库活动的实时报告。

• MongoDB 提供了各种数据库命令，这些命令可以更精确地返回有关当前数据库状态的统计信息。

• MongoDB Atlas 是一个云托管的数据库即服务，用于运行、监控和维护 MongoDB 部署。

• MongoDB Cloud Manager 是一个托管服务，用于监控运行中的 MongoDB 部署以收集数据，并根据这些数据提供可视化和警报。

• MongoDB Ops Manager 是 MongoDB 企业高级版中提供的本地解决方案，用于监控运行中的 MongoDB 部署以收集数据，并根据这些数据提供可视化和警报。

每种策略都可以帮助回答不同的问题，并在不同的环境中非常有用。这些方法是互补的。

MongoDB 报告工具

本节提供了 MongoDB 随附的报告方法的概述。同时，它还提供了每个方法最适合帮助解决的问题的示例。

进程日志

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

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

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

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

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

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

以下 数据库命令 也会影响日志记录

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

• logRotate。仅旋转 mongod 进程的日志文件。请参阅 旋转日志文件。

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

{
   "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,
         ...
      }
      ...
   }
}

{
   "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": "###",
         ...
      }
      ...
   }
}

诊断性能问题

随着您开发和使用 MongoDB 应用程序，您可能希望像分析应用程序的性能一样分析数据库的性能。有关影响性能的操作因素，请参阅 MongoDB 性能。

复制和监控

除了任何MongoDB实例的基本监控需求之外，对于副本集，管理员必须监控复制延迟。"复制延迟"指的是将（即复制）主节点上的写操作复制到主节点所需的时间。一些小的延迟可能是可接受的，但随着复制延迟的增加，将出现重大问题，包括

• 主节点上不断增长的缓存压力。

• 在延迟期间发生的操作未复制到一或多个从节点。如果您使用复制来确保数据持久性，异常长的延迟可能会影响数据集的完整性。

• 如果复制延迟超过了操作日志（oplog）的长度，则MongoDB必须在从节点上执行初始同步，复制主节点的所有数据并重建所有索引。[1] 在正常情况下，这种情况很少发生，但如果您将oplog配置为小于默认值，则可能会出现此问题。

  注意

  oplog的大小只能在第一次运行时通过向--oplogSize参数传递给mongod命令或更倾向于在MongoDB配置文件中的oplogSizeMB设置中进行配置。如果您在运行带有--replSet选项之前未指定此选项，则mongod将创建默认大小的oplog。

  默认情况下，在64位系统上，oplog是可用磁盘空间的5%。有关更改oplog大小的更多信息，请参阅更改自管理副本集成员的Oplog大小。

rs.status()

分片和监控

在大多数情况下，分片集群的组件可以从与其他所有MongoDB实例相同的监控和分析中受益。此外，集群需要进一步的监控以确保数据在节点之间有效分布，并且分片操作运行得当。

use config
db.locks.find()

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

存储节点看门狗

存储节点看门狗会监控以下MongoDB目录以检测文件系统无响应：

• --dbpath 目录

• --dbpath 目录内的 journal 目录

• --logpath 文件所在的目录

• --auditPath 文件所在的目录

默认情况下，存储节点看门狗是禁用的。您只能在启动时通过将 watchdogPeriodSeconds 参数设置为大于或等于60的整数来启用存储节点看门狗。然而，一旦启用，您可以在运行时暂停存储节点看门狗并重新启动。有关详细信息，请参阅 watchdogPeriodSeconds 参数。

如果包含被监控目录的任何文件系统变得无响应，存储节点看门狗将终止 mongod 并以状态码61退出。如果 mongod 是副本集的主节点，则终止将启动一个 故障转移，允许其他成员成为主节点。

一旦 mongod 终止，它可能无法在 同一 机器上干净地重启。

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