监控 MongoDB

在本页面

监控是所有数据库管理的关键组成部分。牢固掌握 MongoDB 的报告将使您能够评估数据库的 state 并保持部署而不会出现危机。此外,MongoDB 的正常操作参数意味着您可以在问题升级到故障之前对其进行诊断。

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

注意 MongoDB Atlas是 cloud-hosted database-as-a-service。 MongoDB Cloud Manager,一个托管服务,Ops Manager,一个 on-premise 解决方案,提供 MongoDB 实例的监视,备份和自动化。有关文档,请参阅Atlas 文档MongoDB Cloud Manager 文档Ops Manager 文档

监测策略

有三种方法可以收集有关 running MongoDB 实例的 state 的数据:

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

MongoDB 报告工具

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

公用事业

MongoDB 发行版包含许多实用程序,可以快速 return 关于实例的 performance 和 activity 的统计信息。通常,这些对于诊断问题和评估正常操作最有用。

mongostat

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

使用mongostat了解操作类型的分布并通知容量规划。有关详细信息,请参阅mongostat 手册

mongotop

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

使用mongotop检查您的数据库活动是否正常并使用匹配您的期望。有关详细信息,请参阅mongotop 手册

HTTP Console

更改 version 3.6: MongoDB 3.6 将已弃用的 HTTP 接口和 REST API 移除到 MongoDB。

命令

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

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

serverStatus

serverStatus命令或 shell 中的db.serverStatus()返回数据库状态的一般概述,详细说明磁盘使用情况,memory 使用,连接,日记和索引访问。该命令快速返回,不会影响 MongoDB performance。

serverStatus输出 MongoDB 实例的 state 帐户。此命令很少直接 run。在大多数情况下,聚合时数据更有意义,正如人们在监测工具中看到的那样,包括MongoDB Cloud ManagerOps Manager。尽管如此,所有管理员都应该熟悉serverStatus提供的数据。

dbStats

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

使用此数据可以监视特定数据库的 state 和存储容量。此输出还允许您比较数据库之间的使用并确定数据库中的平均文献大小。

collStats

shell 中的collStatsdb.collection.stats(),它提供与集合 level 类似的dbStats的统计信息,包括集合中 objects 的计数,集合的大小,集合使用的磁盘空间量以及有关其索引的信息。

replSetGetStatus

replSetGetStatus命令(shell 中的rs.status())返回副本集状态的概述。 replSetGetStatus文档详细说明了副本集的 state 和 configuration 以及有关其成员的统计信息。

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

托管(SaaS)监控工具

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

名称笔记
MongoDB Cloud ManagerMongoDB Cloud Manager 是用于管理 MongoDB 部署的 cloud-based 服务套件。 MongoDB Cloud Manager 提供监控,备份和自动化功能。对于 on-premise 解决方案,另请参见Ops Manager,MongoDB Enterprise Advanced 中提供
VividCortexVividCortex 以 one-second 分辨率提供对 MongoDB production 数据库工作负载和查询 performance的深入见解。跟踪延迟,吞吐量,错误等,以确保 MongoDB 上的 application 的可伸缩性和出色的性能。
侦察几个插件,包括MongoDB 监控MongoDB 慢速查询MongoDB 副本集监控
服务器密度MongoDB 的仪表板, MongoDB 特定警报,复制故障转移时间线以及 iPhone,iPad 和 Android 移动应用程序。
Application Performance ManagementIBM 有一个 Application Performance Management SaaS 产品,其中包括 MongoDB 和其他应用程序和中间件的监视器。
New RelicNew Relic 为 application performance management 提供全面支持。此外,New Relic 插件和数据分析使您可以在 New Relic 中查看来自 Cloud Manager 的监控 metrics。
Datadog基础设施监测可视化 MongoDB 部署的 performance。
SPM 性能监控监控,异常检测和警报 SPM 监控所有 key MongoDB metrics 以及基础设施。 Docker 和其他 application metrics,e.g. Node.js,Java,NGINX,Apache,HAProxy 或 Elasticsearch。 SPM 提供 metrics 和日志的关联。

Process Logging

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

  • 安静。限制写入 log 或输出的信息量。

  • 赘言。增加写入 log 或输出的信息量。您还可以使用LOGLEVEL参数或 shell 中的db.setLogLevel()方法在运行时修改 logging 详细程度。

  • 路径。启用 logging 到文件,而不是标准输出。调整此设置时,必须指定 log 文件的完整路径。

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

注意详细模式下启动mongod实例,将数据附加到/var/log/mongodb/server1.log/的 log 文件。

以下数据库命令也会影响 logging:

Log Redaction

version 3.4 中的新功能:仅适用于 MongoDB Enterprise

在 logging 之前__ running 与security.redactClientLogData编辑消息与任何给定的 log event 相关联,只留下与 event 相关的元数据,源 files 或 line numbers。 security.redactClientLogData防止潜在敏感信息以诊断详细信息为代价进入系统 log。

对于 example,以下操作将文档插入mongod running 而不使用 log redaction。 mongodsystemLog.component.command.verbosity设置为1

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

此操作生成以下 log event:

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

__ running 与security.redactClientLogData执行相同的 insert 操作会产生以下 log event:

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

redactClientLogDataRest 加密TLS/SSL(传输加密)结合使用可帮助遵守法规要求。

诊断 Performance 问题

在使用 MongoDB 开发和操作 applications 时,您可能希望将数据库的 performance 分析为 application。 MongoDB Performance讨论了可能影响绩效的一些运营因素。

复制和监控

注意 对于 MongoDB 3.6 部署,从 version 3.6.11 开始,副本集的辅助成员现在log oplog 条目需要比缓慢操作阈值更长的时间才能应用。将使用文本applied op: <oplog entry> took <num>msREPL component 下的诊断 log中为辅助节点记录这些慢速 oplog 消息。这些缓慢的 oplog 条目仅取决于慢速操作阈值。它们不依赖于 log 级别(在系统或 component level 上),或者分析 level,或者慢操作 sample 率。探查器不捕获慢速 oplog 条目。

除了任何 MongoDB 实例的基本监视要求之外,对于副本_set,管理员必须监视复制滞后。 “复制延迟”是指将上的写操作复制(i.e.复制)到次要所需的 time 时间。一些小的延迟期可能是可以接受的,但随着复制滞后的增加,出现了两个重大问题:

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

  • 其次,如果复制延迟超过了操作 log(OPLOG)的长度,那么 MongoDB 将必须在辅助节点上执行初始同步,从复制所有数据并重建所有索引。在正常情况下这种情况并不常见,但如果将 oplog 配置为小于默认值,则可能会出现问题。

注意 oplog 的大小只能在第一个 run 期间使用 mongod 命令的--oplogSize 参数进行配置,或者最好是 MongoDB configuration 文件中的 oplogSizeMB 设置。如果在使用--replSet 选项 running 之前未在命令 line 上指定此项,则 mongod 将创建一个默认大小的 oplog。 默认情况下,oplog 占 64-bit 系统总可用磁盘空间的 5%。有关更改 oplog 大小的更多信息,请参阅更改 Oplog 的大小

有关复制滞后的原因,请参阅复制滞后

复制问题通常是成员之间网络连接问题的结果,或者是没有资源支持 application 和复制流量的的结果。要检查副本的状态,请在 shell 中使用replSetGetStatus或以下帮助程序:

rs.status()

replSetGetStatus reference 提供了此输出的更多 in-depth 概述视图。通常,watch 的 value,并特别注意次要成员之间的 time 差异。

分片和监控

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

也可以看看 有关更多信息,请参阅拆分文档。

配置服务器

配置数据库维护一个 map,用于标识哪些文档在哪些分片上。 cluster 在在分片之间移动时更新此 map。当 configuration 服务器变得不可访问时,某些分片操作变得不可用,例如移动块和启动mongos实例。但是,群集仍可从 already-running mongos实例访问。

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

MongoDB Cloud ManagerOps Manager监视配置服务器,并且如果配置服务器变得不可访问,则可以创建通知。有关详细信息,请参阅MongoDB Cloud Manager 文档Ops Manager 文档

平衡和块分布

最有效的分片 cluster部署在分片之间平衡。为了实现这一点,MongoDB 有一个后台平衡器 process,它分配数据以确保块总是最佳地分布在碎片之间。

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

陈旧的锁

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

use config
db.locks.find()

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

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

更改 version 3.4:从 3.4 开始,CSRS 配置服务器的主服务器使用名为“ConfigServer”的 process id 保持“balancer”锁。这个锁永远不会释放。要确定平衡器是否正在运行,请参阅检查 Balancer 是否 Running

存储节点看门狗

version 3.6 中的新内容。

注意 仅在 MongoDB Enterprise 中可用。不适用于 macOS。

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

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

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

如果包含这些目录的任何文件系统无响应,存储节点看门狗将终止mongod并以状态 code 为 61 退出。如果mongod用作,则终止启动故障转移,允许其他成员成为主要成员。

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

存储节点看门狗可以用来检测无响应的文件系统并终止的最大 time 几乎是watchdogPeriodSeconds的 value 的两倍。