Docs 菜单

监控自管理 MongoDB 部署

监控是所有数据库管理的关键组成部分。牢牢掌握 MongoDB 的报告将使你能够评估数据库的状态并在没有危机的情况下保持部署。此外,了解 MongoDB 的正常操作参数将使你能够在问题升级为故障之前对其进行诊断。

本文档概述了 MongoDB 提供的监控实用程序和报告统计信息。其中还介绍了监控副本集和分片集群的诊断策略和建议。

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

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

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

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

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

  • MongoDB Ops Manager 是 MongoDB Enterprise Advanced 中的本地部署解决方案,用于监控正在运行的 MongoDB 部署,以收集数据并根据该数据提供可视化和警报。

不同策略可以帮助回答不同的问题,适用于不同的情况。这些方法互为补充。

本节概述了 MongoDB 发行版提供的报告方法,并且还举例说明了每种方法最适合帮助解决何种问题。

MongoDB 发行版包含许多实用程序,它们可以快速返回有关实例性能和活动的统计信息。通常,这些信息对于诊断问题和评估正常运行非常有用。

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

使用 mongostat 来了解操作类型的分布并为容量规划提供信息。详情请参见 mongostat 参考页。

mongotop 追踪并报告 MongoDB 实例的当前读写活动,并按每个集合报告这些统计信息。

使用 mongotop 检查数据库活动和使用是否符合预期。详情请参见 mongotop 参考页。

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

这些数据在粒度上可能比上面讨论的实用程序更精细。可以考虑在脚本和程序中使用其输出来开发自定义警报,或修改应用程序的行为以响应实例的活动。db.currentOp() 方法是另一个有用工具,可识别数据库实例正在进行的操作。

serverStatus 命令或 shell 的 db.serverStatus(),会返回数据库状态的总体概述,详细说明磁盘使用情况、内存使用情况、连接、日志和索引访问权限。该命令可以快速返回,不会影响 MongoDB 性能。

serverStatus 输出了 MongoDB 实例状态的说明。此命令很少直接运行。在大多数情况下,聚合后的数据更有意义,使用 MongoDB Cloud ManagerOps Manager 等监控工具就会明白这一点。不过,所有管理员都应熟悉 serverStatus 提供的数据。

dbStats 命令,或 shell db.stats(),会返回一个解决存储使用情况和数据量的文档。dbStats 反映所使用的存储量、数据库中包含的数据量以及对象、集合和索引计数器。

使用此数据监视特定数据库的状态和存储容量。此输出还支持您比较数据库之间的使用情况,并确定数据库平均文档的大小。

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

replSetGetStatus 命令(在 Shell 中运行 rs.status())返回您的副本集状态的概要信息。replSetGetStatus 文档详细说明了副本集的状态和配置,以及其成员的统计信息。

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

这些是作为托管服务提供的监控工具,通常通过付费订阅的方式提供。

名称
注意

MongoDB Cloud Manager 是一系列基于云的服务,可用于管理 MongoDB 部署。MongoDB Cloud Manager 提供监控、备份和自动化功能。有关本地部署解决方案,另请参阅 MongoDB Enterprise Advanced 中提供的 Ops Manager。

VividCortex 以一秒钟的分辨率提供对 MongoDB 生产数据库工作负载和查询性能 的深入见解。追踪延迟、吞吐量、错误等,确保 MongoDB 上的应用程序具备可扩展性和卓越性能。

MongoDB 仪表盘、MongoDB 特定警报、复制故障转移时间线以及 iPhone、iPad 和 Android 移动应用程序。

IBM 的一款应用程序性能管理 SaaS 产品提供对 MongoDB 以及其他应用程序和中间件的监控器。

New Relic 为应用程序性能管理提供全面支持。此外,New Relic 插件和见解支持在 New Relic 中查看来自 Cloud Manager 的监控指标。

基础设施监控,以可视化方式呈现 MongoDB 部署的性能。

监控、异常检测和警报 SPM 监控所有关键 MongoDB 指标及基础设施,包括 Docker 和其他应用程序指标,例如 Node.js、Java、NGINX、Apache、HAProxy 或 Elasticsearch。SPM 用于将指标和日志关联起来。

Pandora FMS 提供监控 MongoDB 的 PandoraFMS-mongodb-monitoring 插件。

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

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

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

  • path。支持记录到文件,而非标准输出。调整此设置时,必须指定日志文件的完整路径。

  • logAppend。向日志文件添加信息,而不是覆盖文件。

注意

可以将这些配置操作指定为 mongodmongos 的命令行参数

例如:

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

verbose模式下启动 mongod实例,将数据附加到位于 /var/log/mongodb/server1.log/ 的日志文件中。

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

仅在 MongoDB Enterprise 中可用。

使用 redactClientLogData 运行的 mongodmongos 会在记录之前编辑与校订给定日志事件附带的任何消息,只留下与该事件相关的元数据、源文件或行号。redactClientLogData 以诊断细节为代价,防止潜在的敏感信息进入系统日志。

例如,以下操作将文档插入到不进行日志编辑的 mongod 运行中。mongod日志冗长级别设置为 1

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

mongod 结合 redactClientLogData 运行并执行相同的插入操作时,会产生以下日志事件:

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

redactClientLogData静态加密TLS/SSL(传输加密)结合使用,以帮助遵守监管要求。

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

除了任何 MongoDB 实例的基本监控要求之外,对于副本集,管理员还必须监控复制延迟。“复制延迟”是指主节点上的写入操作拷贝(即复制)到从节点所需的时间。一些小的延迟时间可能是可以接受的,但随着复制滞后的增长,会出现严重的问题,包括:

  • 主成员缓存压力不断增加。

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

  • 如果复制延迟超过操作日志 (oplog) 的长度,则 MongoDB 将不得不在从节点上执行初始同步,从主节点复制所有数据并重新构建所有索引。[1] 这在正常情况下并不常见,但如果将 oplog 配置为小于默认值,则可能出现此问题。

    注意

    oplog 的大小只能在第一次运行时使用 mongod 命令的 --oplogSize 的参数进行配置,或者最好是在 MongoDB 配置文件中的 oplogSizeMB 设置中配置。如果在使用 --replSet 选项运行之前没有在命令行中指定此值,mongod 将创建一个默认大小的 oplog。

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

从 MongoDB 4.2 开始,管理员可以限制主节点应用写入的速率,目标是将 majority committed 延迟保持在可配置的最大 flowControlTargetLagSeconds 值以下。

默认情况下,流量控制为 enabled

注意

要启用流量控制,副本集/分片集群必须具有: featureCompatibilityVersion (fCV)4.2 ,且读关注(read concern)为 majority enabled。也就是说,如果 fCV 不是 4.2 或读关注已被禁用,则已启用的流量控制将不会生效。

另请参阅:检查复制延迟。

复制问题通常是由成员之间的网络连接问题造成的,或者是主节点没有资源来支持应用程序和复制流量的结果。要检查副本的状态,请使用 replSetGetStatus 或 Shell 中的以下辅助工具:

rs.status()

replSetGetStatus参考提供了更深入的输出概览。 一般来说,要注意 optimeDate 的值,尤其要注意主节点从节点之间的时间差。

[1] oplog 的大小可能会超过其配置的大小限制,从而避免删除 majority commit point

现在,副本集的从节点会记录应用时间超过慢操作阈值的 oplog 条目。这些慢 oplog 消息:

  • diagnostic log中针对从节点记录。

  • 记录在 REPL 组件下,该组件将含有文本 applied op: <oplog entry> took <num>ms

  • 不依赖日志级别(系统级别或组件级别)

  • 不依赖于分析级别。

  • slowOpSampleRate 影响。

分析器不会捕获慢 oplog 条目。

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

提示

另请参阅:

有关更多信息,请参阅分片文档。

配置数据库维护标识哪些文档在哪些分片上的地图。 当数据段在分片之间移动时,集群会更新此地图。 当配置服务器变得不可访问时,某些分片操作将变得不可用,例如移动数据段和启动 mongos 实例。 但是,仍然可以从已经运行的 mongos 实例访问集群。

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

MongoDB Cloud ManagerOps Manager 可以监控配置服务器,还可以在配置服务器无法访问时创建通知。有关详细信息,请参阅 MongoDB Cloud Manager 文档Ops Manager 文档

最有效的分片集群部署可以均衡分片之间的数据段。 为此,MongoDB 有一个后台负载均衡器进程来分配数据,以确保数据块在分片之间始终保持最佳分布状态。

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

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

use config
db.locks.find()

均衡进程采用特殊的“负载均衡器”锁,可防止其他均衡活动发生。在config数据库中,使用以下命令查看“负载均衡器”锁。

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

CSRS 配置服务器的主节点使用名为“ConfigServer”的进程 ID 持有“负载均衡器”锁。此锁永远不会打开。要确定负载均衡器是否在运行,请参阅检查负载均衡器是否在运行

注意

存储节点监测在 Community 版本和 MongoDB Enterprise 版本中均可用。

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

注意

从 MongoDB 6.1 开始,日志始终处于启用状态。因此,MongoDB 会删除 storage.journal.enabled 选项以及相应的 --journal--nojournal 命令行选项。

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

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

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

注意

Symlinks

如果 Storage Node Watchdog 监控的目录是通往其他卷的符号链接,则 Storage Node Watchdog 不会监控该符号链接目标。

例如,如果 mongod 使用 storage.directoryPerDB: true(或 --directoryperdb)并将数据库目录符号链接到另一个卷,则 Storage Node Watchdog 不会沿着该符号链接来监控目标。

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