监控自管理 MongoDB 部署

监控策略

MongoDB 提供了多种方法来收集有关正在运行的 MongoDB 实例状态的数据：

• MongoDB 分发了一组实用程序，可实时报告数据库活动。

• MongoDB 提供了多个数据库命令，它们能以更高的保真度返回有关当前数据库状态的统计数据。

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

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

• MongoDB Ops Manager 是 MongoDB Enterprise Advanced 中的本地部署解决方案，用于监控正在运行的 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 的大小只能在第一次运行时使用 mongod 命令的 --oplogSize 的参数进行配置，或者最好是在 MongoDB 配置文件中的 oplogSizeMB 设置中配置。如果在使用 --replSet 选项运行之前没有在命令行中指定此值，mongod 将创建一个默认大小的 oplog。

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

rs.status()

分片和监控

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

use config
db.locks.find()

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

Storage Node Watchdog

Storage Node Watchdog 监控以下 MongoDB 目录以检测文件系统无响应情况：

• --dbpath 目录

• --dbpath 目录中的 journal 目录

• --logpath 文件的目录

• --auditPath 文件的目录

默认情况下，存储节点监测处于禁用状态。您只能在启动时，通过将 watchdogPeriodSeconds 参数设置为大于或等于 60 的整数来启用 mongod 上的存储节点监测功能。但是，一旦启用，您就可以暂停存储节点监测并在运行时重新启动。详情参见 watchdogPeriodSeconds 参数。

如果包含受监控目录的任何文件系统无响应，存储节点监测将终止mongod并退出，状态代码为 61。如果 mongod 是副本集的主节点，则终止会启动故障转移，从而允许其他成员成为主节点。

mongod 一旦终止，可能就无法在同一台机器上干净利落地重新启动。

存储节点监测功能检测无响应文件系统并终止可以使用的最长时间几乎是 watchdogPeriodSeconds 值的两倍。