- Administration >
- MongoDB监控
MongoDB监控¶
On this page
监控是所有数据库管理的重要组成部分。牢牢掌握 MongoDB 的报告将使您评估您的数据库的状态，并使您的部署不出意外。另外， 一种MongoDB 的常规操作参数允许您在它们恶化为失败之前进行诊断。
本文概略地介绍了可用的监控实用程序和在MongoDB中可用的统计报告。本文还介绍了监控副本集和分片集群的诊断策略和建议。
注解
MongoDB Management Service (MMS) 是一项托管监控服务，该服务收集和聚合数据以供直观地了解MongoDB部署的性能和操作。更多信息请参见 MMS documentation 。
监控策略¶
有三种方法可用于收集正字运行的 MongoDB 实例的状态数据：
第一种，有一套随着MongoDB一起分发的实用程序提供了数据库活动的实时报告。
第二种， 数据库命令 返回有关当前数据库状态更高保真度的统计信息。
第三种， MongoDB Cloud Manager，一个主机服务， Ops Manager, an on-premise solution available in MongoDB Enterprise Advanced ，提供了对从运行中的MongoDB部署上收集数据的监控 ，以及提供在那些数据上的可视化和警报。
每个策略可以帮助解决不同的问题，在不同的场景下各有其用。并且这些方法是相辅相成的。
MongoDB报表工具¶
本节概述了随MongoDB一起分发的报告方法。本节还提供了每一种方法最适合的那类问题的例子来帮助您选择合适的方法定位问题。
实用程序¶
MongoDB发行版包含了大量快速返回实例性能和活动统计信息的实用程序。通常情况下，这些程序对诊断问题和评估一般操作是最有用。
mongostat¶
mongostat 捕捉并返回各种类型（如插入、 查询、 更新、 删除等）数据库操作的计数。这些计数展示了服务器上的负载分布。
使用 mongostat 以了解操作类型的分布，并告知容量规划。详细信息请参见 mongostat 手册 。
mongotop¶
mongotop 追踪并报告MongoDB实例当前的读取和写入活动，而且是基于每个集合报告这些统计数据。
使用 mongotop 来检查数据库的活动和使用是否符合您的期望。详细信息请参见 mongotop manual 。
命令¶
MongoDB包含了许许多多报告数据库状态的命令。
这些数据可以比上文讨论的实用程序提供更细层次的粒度。当开发自定义警报，或改变您的应用程序在响应您的实例的活动时的行为，请考虑在（您的）脚本和程序中使用其输出。 db.currentOp 方法是另一种用于确定数据库实例正在进行的操作的有用工具，。
serverStatus¶
serverStatus 命令，或外壳程序中的 db.serverStatus() 返回数据库状态的总览，具体包括磁盘使用状况、 内存使用状况、 连接、 日志和可用的索引。此命令迅速返回，并不会影响 MongoDB 性能。
serverStatus 输出MongoDB实例状态的总览。（然而我们）很少直接运行该命令。（因为）在大多数情况下，人们通过监控工具包括 MMS 看到的聚合过的数据才更有意义。尽管如此，所有管理员都应熟悉 serverStatus 提供的数据。
dbStats¶
dbStats 命令，或外壳程序中的 db.stats() 返回一份针对存储使用情况和数据卷的文档。 dbStats 显示了存储的使用量、包含在数据库中的数据的总量以及对象、集合和索引计数器。
使用此数据来监控特定数据库的状态和存储容量。该输出（的数据）也可以让你比较各数据库的使用情况，并确定数据库中 document 的平均大小。
collStats¶
shell中的 collStats 或者 db.collection.stats() 在集合级别上提供类似 dbStats 的统计数据，包括集合中对象的计数、集合的大小、集合占用的硬盘空间总量以及集合索引的相关信息。
replSetGetStatus¶
replSetGetStatus 命令（对应外壳程序中的 rs.status() ）返回复制集状态的总览。 replSetGetStatus 文档详细描述了复制集的状态和配置和有关复制集成员的统计信息。
参照此数据以确保复制集配置正确，并检查当前主机和其他副本集成员之间的连接。
第三方工具¶
A number of third party monitoring tools have support for MongoDB, either directly, or through their own plugins.
自托管的监控工具¶
以下这些是你必须在自己的服务器上安装、配置、维护的监控工具。（它们中的）大多数都是开源的。
工具 |
插件 |
描述 |
|---|---|---|
| Ganglia | mongodb-ganglia | 报告内存使用、btree统计情况、主/从状态、当前操作、每秒的操作的Python脚本。 |
| Ganglia | gmond_python_modules | 解析 serverStatus 和 replSetGetStatus 命令的输出。 |
| Motop | None | MongoDB服务器的实时监控工具。每秒以历时长短排序展示目前的操作。 |
| mtop | None | 和top类似的工具 |
| Munin | mongo-munin | 检索服务器统计数据。 |
| Munin | mongomon | Retrieves collection statistics (sizes, index sizes, and each (configured) collection count for one DB). |
| Munin | munin-plugins Ubuntu PPA | 一些不在主要发行版中的、附加的munin插件。 |
| Nagios | nagios-plugin-mongodb | 一个用Python写的，简单的Nagios检查脚本。 |
| SPM Performance Monitoring | MongoDB Docker Agent | 还可以考虑 dex，一个MongoDB的索引和查询分析工具。该工具比较MongoDB的日志文件和索引并对索引提出建议。 |
Also consider dex, an index and query analyzing tool for MongoDB that compares MongoDB log files and indexes to make indexing recommendations.
参见
作为 MongoDB Enterprise 的一部分，你可以运行 MMS On-Prem，它提供了在你的基础设施上运行MMS功能的包。
托管（SaaS）监控工具¶
以下这些是被作为托管服务提供的监控工具，（它们）通常是通过付费订阅的。
名称 |
说明 |
|---|---|
| MongoDB Cloud Manager is a cloud-based suite of services for managing MongoDB deployments. MongoDB Cloud Manager provides monitoring, backup, and automation functionality. For an on-premise solution, see also Ops Manager, available in MongoDB Enterprise Advanced. | |
| Scout | 几个插件包括 MongoDB Monitoring, MongoDB Slow Queries, 以及 MongoDB Replica Set Monitoring. |
| Server Density | Dashboard for MongoDB，包含MongoDB特定的警报，复制故障转移的时间表以及iPhone、iPad、Android的移动应用程序。 |
| Application Performance Management | IBM有一个应用程序性能管理的SaaS产品，包括MongoDB的监控器以及其他应用程序和中间件。 |
| New Relic | New Relic offers full support for application performance management. In addition, New Relic Plugins and Insights enable you to view monitoring metrics from Cloud Manager in New Relic. |
| Datadog | Infrastructure monitoring to visualize the performance of your MongoDB deployments. |
| SPM Performance Monitoring | 在（进行）常规操作时， mongod 和 mongos 实例会向标准输出或日志文件写入当前帐号的所有服务器活动和操作。以下的运行时设置控制这些选项。 |
Process Logging¶
During normal operation, mongod and mongos instances report a live account of all server activity and operations to either standard output or a log file. The following runtime settings control these options.
- quiet. Limits the amount of information written to the log or output.
- verbosity. Increases the amount of information written to the log or output. You can also modify the logging verbosity during runtime with the logLevel parameter or the db.setLogLevel() method in the shell.
path。开启记录写入到文件，而不是标准输出。调整这个设置时必须指定完整的日志文件路径。
logAppend。增加信息到一个日志文件而不是覆盖原文件。
注解
你可以参照 mongod 或 mongos 的命令行参数指定这些配置操作。
例如：
mongod -v --logpath /var/log/mongodb/server1.log --logappend
以 verbose 模式启动 mongod 实例，并向 /var/log/mongodb/server1.log/ 所在的日志文件追加数据。
以下 database commands 也会影响日志:
logRotate。只反转 mongod 进程的日志文件. 参见 Rotate Log Files。
Log Redaction¶
3.4 新版功能: Available in MongoDB Enterprise only
A mongod running with security.redactClientLogData redacts messages associated with any given log event before logging, leaving only metadata, source files, or line numbers related to the event. security.redactClientLogData prevents potentially sensitive information from entering the system log at the cost of diagnostic detail.
For example, the following operation inserts a document into a mongod running without log redaction. The mongod has systemLog.component.query.verbosity set to 0:
db.clients.insertOne( { "name" : Joe, "PII" : "Sensitive Information" } )
This operation produces the following log event:
2016-09-23T13:51:43.572-0400 I COMMAND [conn1] command employeeData.directory
appName: "MongoDB Shell"
command: insert {
insert: "directory",
documents: [
{
_id: ObjectId('57e56baf6a71e2b785153aec'),
name: "Joe",
PII: "Sensitive Information"
}
],
...
A mongod running with security.redactClientLogData performing the same insert operation produces the following log event:
注解
The exact redacted output may change leading up to the MongoDB 3.4 release. This output is based on the 3.3 development series build.
2016-09-23T13:51:43.572-0400 I COMMAND [conn1] ###
Use redactClientLogData in conjunction with encryption to assist compliance with regulatory requirements.
诊断性能问题¶
除非受制于系统范围的约束，否则MongoDB对接入的连接没有限制。你可以使用 ulimit 命令或通过修改系统的 /etc/sysctl 文件来修改系统的限制。更多详情请参见 UNIX系统下 ulimit 的设置 。
复制和监控¶
除了对任意MongoDB实例基本的监控需求,对于复制集,管理员还必须监控 复制延迟.”复制延迟” 指的是从一个 primary 复制写操作到 secondary 所花的总时间.一些小的延迟间隔是可以接受的,但两个显著的问题会随着复制延迟的增长出现:
第一个，延迟期间发生的操作不会复制到一个或多个从节点。如果您使用复制以确保数据持久化，特别长的延迟可能会影响到您的数据集的完整性。
第二个,如果复制延迟超过操作日志(oplog) 的长度,那么MongoDB就不得不在从节点上执行一个初始化同步,即复制 primary 的所有数据并重建所有索引。这在正常情况下很少见，但如果你设置的oplog比默认值小，可能会出现该问题。
注解
oplog的大小仅可在第一次运行时通过 mongod 命令的 --oplogSize 参数或最好使用MongoDB配置文件中的 oplogSizeMB 进行配置.如果在运行 --replSet 选项之前你没有在命令行指定该参数, mongod 将创建默认大小的oplog.
默认情况下,oplog(的大小)在64位系统上是总的可用磁盘空间的5%。有关更改oplog大小的详细信息，请参阅 修改Oplog大小
对于复制延迟的原因，请参阅 Replication Lag.
复制问题通常是成员之间网络连接问题或是 primary 没有足够的资源来支持应用和复制的流量造成的结果。要检查副本的状态,可以在命令行中使用 replSetGetStatus 或如下助手：
rs.status()
文档 replSetGetStatus 提供了该输出的更深入的总览.一般情况下,查看 optimeDate 的值并特别留意 primary 和 secondary 成员们的时间差.
分片和监控¶
在大多数情况下, sharded clusters 的组件和所有其他的MongoDB实例同样受益于监测和分析。另外，集群需要更深入的监测以确保数据被高效地分发在各节点之间，并且分片操作正确地发挥了作用。
参见
See the 分片 documentation for more information.
配置服务器¶
The config database maintains a map identifying which documents are on which shards. The cluster updates this map as chunks move between shards. When a configuration server becomes inaccessible, certain sharding operations become unavailable, such as moving chunks and starting mongos instances. However, clusters remain accessible from already-running mongos instances.
Because inaccessible configuration servers can seriously impact the availability of a sharded cluster, you should monitor your configuration servers to ensure that the cluster remains well balanced and that mongos instances can restart.
MongoDB Cloud Manager and Ops Manager monitor config servers and can create notifications if a config server becomes inaccessible. See the MongoDB Cloud Manager documentation and Ops Manager documentation for more information.
均衡和数据块分布¶
最高效的 sharded cluster 部署能在分片间均匀地平衡 chunks .为了方便(达到)这一点,MongoDB有个分配数据的后台 balancer 进程以确保数据段总是最佳地分布 shards 间.
通过 mongo 的命令行将 db.printShardingStatus() 或 sh.status() 发布给 mongos .这将返回整个集群的概要–包括数据库名字和数据段列表.
稳定锁¶
几乎所有情况下，当平衡器变稳定时,他们使用过的所有锁将自动释放。然而，由于任意一个持续时间过长的锁都可能阻止以后的平衡，所以确保所有锁都是合法的非常重要。要检查数据库的锁定状态，(你可以)用 mongo 命令行连接到一个 mongos 实例。使用如下命令序列切换到 配置 数据库并展示分片数据库中所有的显式锁:
use config
db.locks.find()
对于正在活动的部署,上面的查询可以直观的显示.起源于随机选择的一个 mongos 的平衡进程使用了一种特殊的 “平衡器”–它可以阻止其他平衡活动的扩散.同样地,对 配置 数据库使用如下命令,即可检查 “平衡器” 锁的状态.
db.locks.find( { _id : "balancer" } )
在 3.4 版更改: Starting in 3.4, the primary of the CSRS config server holds the “balancer” lock, using a process id named “ConfigServer”. This lock is never released. To determine if the balancer is running, see Check if Balancer is Running.