OPTIONS
翻译或纠错本页面

MongoDB监控

监控是所有数据库管理的重要组成部分。牢牢掌握 MongoDB 的报告将使您评估您的数据库的状态,并使您的部署不出意外。另外, 一种MongoDB 的常规操作参数允许您在它们恶化为失败之前进行诊断。

本文概略地介绍了可用的监控实用程序和在MongoDB中可用的统计报告。本文还介绍了监控副本集和分片集群的诊断策略和建议。

注解

MongoDB Management Service (MMS) 是一项托管监控服务,该服务收集和聚合数据以供直观地了解MongoDB部署的性能和操作。更多信息请参见 MMS documentation

监控策略

有三种方法可用于收集正字运行的 MongoDB 实例的状态数据:

  • 第一种,有一套随着MongoDB一起分发的实用程序提供了数据库活动的实时报告。

  • 第二种, database commands 返回有关当前数据库状态更高保真度的统计信息。

  • 第三种, MMS Monitoring Service 从正在运行的MongoDB部署收集数据并提供可视化和基于该数据的警报。MMS是MongoDB提供的免费服务。

每个策略可以帮助解决不同的问题,在不同的场景下各有其用。并且这些方法是相辅相成的。

MongoDB报告工具

本节概述了随MongoDB一起分发的报告方法。本节还提供了每一种方法最适合的那类问题的例子来帮助您选择合适的方法定位问题。

实用程序

MongoDB发行版包含了大量快速返回实例性能和活动统计信息的实用程序。通常情况下,这些程序对诊断问题和评估一般操作是最有用。

mongostat

mongostat 捕捉并返回各种类型(如插入、 查询、 更新、 删除等)数据库操作的计数。这些计数展示了服务器上的负载分布。

使用 mongostat 以了解操作类型的分布,并告知容量规划。详细信息请参见 mongostat manual

mongotop

mongotop 追踪并报告MongoDB实例当前的读取和写入活动,而且是基于每个集合报告这些统计数据。

使用 mongotop 来检查数据库的活动和使用是否符合您的期望。详细信息请参见 mongotop manual

REST 接口

MongoDB提供了简单的REST接口,可用于配置监控和警报脚本,以及其他管理任务。

要想配置 mongod 启用 REST,要么在启动 mongod 时使用 --rest 选项,要么在 configuration file 中设置 net.http.RESTInterfaceEnabledtrue

更多关于使用REST接口的信息,请参见文档 Simple REST Interface

HTTP 控制台

MongoDB提供了一个在一个简单的网页上展示诊断和监控信息的网络接口。该接口通过``localhost:<port>``访问, 其中的 <port>mongod 的端口大 1000

例如,如果一个正在本地运行的 mongod 使用默认的端口 27017,那么在 http://localhost:28017 可以访问到HTTP控制台。

命令

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

这些数据可以比上文讨论的实用程序提供更细层次的粒度。当开发自定义警报,或改变您的应用程序在响应您的实例的活动时的行为,请考虑在(您的)脚本和程序中使用其输出。 db.currentOp 方法是另一种用于确定数据库实例正在进行的操作的有用工具,。

serverStatus

serverStatus 命令,或外壳程序中的 db.serverStatus() 返回数据库状态的总览,具体包括磁盘使用状况、 内存使用状况、 连接、 日志和可用的索引。此命令迅速返回,并不会影响 MongoDB 性能。

serverStatus 输出MongoDB实例状态的总览。(然而我们)很少直接运行该命令。(因为)在大多数情况下,人们通过监控工具包括 MMS 看到的聚合过的数据才更有意义。尽管如此,所有管理员都应熟悉 serverStatus 提供的数据。

dbStats

dbStats 命令,或外壳程序中的 db.stats() 返回一份针对存储使用情况和数据卷的文档。 dbStats 显示了存储的使用量、包含在数据库中的数据的总量以及对象、集合和索引计数器。

使用此数据来监控特定数据库的状态和存储容量。该输出(的数据)也可以让你比较各数据库的使用情况,并确定数据库中 document 的平均大小。

collStats

collStats 在集合级别上提供类似 dbStats 的统计数据,包括集合中对象的计数、集合的大小、集合占用的硬盘空间总量以及集合索引的相关信息。

replSetGetStatus

replSetGetStatus 命令(对应外壳程序中的 rs.status() )返回复制集状态的总览。 replSetGetStatus 文档详细描述了复制集的状态和配置和有关复制集成员的统计信息。

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

第三方工具

许多第三方监控工具都直接或通过自己的插件支持MongoDB。

自托管的监控工具

以下这些是你必须在自己的服务器上安装、配置、维护的监控工具。(它们中的)大多数都是开源的。

工具

插件

描述

Ganglia mongodb-ganglia

报告内存使用、btree统计情况、主/从状态、当前操作、每秒的操作的Python脚本。

Ganglia gmond_python_modules

解析 serverStatusreplSetGetStatus 命令的输出。

Motop None

MongoDB服务器的实时监控工具。每秒以历时长短排序展示目前的操作。

mtop None

和top类似的工具

Munin mongo-munin

检索服务器统计数据。

Munin mongomon

检索集合统计数据(大小,索引大小,以及每个DB(设置的)文档的计数)。

Munin munin-plugins Ubuntu PPA

一些不在主要发行版中的、附加的munin插件。

Nagios nagios-plugin-mongodb

一个用Python写的,简单的Nagios检查脚本。

Zabbix mikoomi-mongodb

监视器可用性,资源利用率​,健康,性能和其他重要的指标。

还可以考虑 dex,一个MongoDB的索引和查询分析工具。该工具比较MongoDB的日志文件和索引并对索引提出建议。

作为 MongoDB Enterprise 的一部分,你可以运行 MMS On-Prem,它提供了在你的基础设施上运行MMS功能的包。

托管(SaaS)监控工具

以下这些是被作为托管服务提供的监控工具,(它们)通常是通过付费订阅的。

名称

说明

MongoDB Management Service

MMS是一个基于云的管理MongoDB部署的服务套件。MMS提供了监控和备份功能。

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的监控器以及其他应用程序和中间件。

处理日志

在(进行)常规操作时, mongodmongos 实例会向标准输出或日志文件写入当前帐号的所有服务器活动和操作。以下的运行时设置控制这些选项。

  • quiet。减少了写入日志或输出的信息量。

  • verbosity.。增加了写入日志或输出的信息量。

  • path。开启记录写入到文件,而不是标准输出。调整这个设置时必须指定完整的日志文件路径。

  • logAppend。增加信息到一个日志文件而不是覆盖原文件。

注解

你可以参照 mongodmongos 的命令行参数指定这些配置操作。

例如:

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

verbose 模式启动 mongod 实例,并向 /var/log/mongodb/server1.log/ 所在的日志文件追加数据。

以下 database commands 也会影响日志:

诊断性能问题

MongoDB中性能的降低通常是存储在数据库的的数据量、系统RAM总量、数据库的连接数和数据库处于锁定状态的总时间之间关系的函数。

在某些情况下,由于流量负载、数据访问模式或虚拟环境中托管系统上硬件的可用性,性能问题可能是暂时的。一些用户体验到的性能下降是由于不适当、不合理的索引策略或是作为不良的模型设计模式的结果。其它情况下,性能问题(的出现)可能表示数据库正在满负荷下运行,(因此这也是告诉我们)是时候向数据库中添加额外的容量。

以下是MongoDB性能下降的一些原因。

MongoDB使用锁机制确保数集合的一致性。然而,如果指定的操作需要很长时间运行或是队列的形式,会因为请求和操作等待锁而导致性能下降。与锁相关的性能降低可能是间歇性的。要查看是否是锁影响了性能,你可以查看 globalLock section of the serverStatus 输出中的数据。如果 globalLock.currentQueue.total 一直很高,那么有可能大量的请求正在等待锁。这表明可能存在影响性能的并发问题。

如果 globalLock.totalTimeuptime 高,(那么说明)数据库已经很长一段时间处于锁状态了。如果 globalLock.ratio 也较高,MongoDB可能正在处理大量长时间运行的查询。长时间运行的查询往往是多种因素造成的:无效的索引的使用,没有优化过的数据模型设计,不良的查询结构,系统架构问题,或 page faults 和硬盘读取导致的内存不足。

内存使用

MongoDB使用内存映射文件来存储数据。给定足够大的数据集,MongoDB进程会占用系统中所有可用的内存。虽然这是设计的一部分,并且给予MongoDB卓越的性能,但该内存映射文件使得确定RAM对于特定的数据集是否足够变难。

serverStatus 的度量指标 memory usage statuses 的输出可以洞察MongoDB的内存使用情况。检查驻留内存的使用(即 mem.resident):如果其超过了系统内存的总量 并且 磁盘上还有显著数据量的数据未在内存中,你的负载可能已经超出了系统的能力。

你也应该检查映射的内存总量(即 mem.mapped。)如果该值大于系统内存量,某些操作将需要磁盘访问 page faults 以便从虚拟内存中读取数据,这会对性能产生负面影响。

缺页中断

缺页中断出现在MongoDB向它当前没有位于物理内存的数据文件的部分读取或写入数据时。相比之下,操作系统的缺页中断发生在物理内存耗尽,物理内存中的页面被交换到磁盘上。

由MongoDB引发的缺页中断被报告为每秒发生的缺页中断的总数。要检查确缺页中断状况,请参见 serverStatus 输出中 extra_info.page_faults 的值。

Windows上的MongoDB同时对软硬缺页中断进行计数。

MongoDB的缺页中断计数器在性能较差时会显著增加,这可能与有限的物理内存环境相关。缺页中断还可能在访问更大的数据集时增加,例如,在扫描整个集合时。有限的偶尔发生的MongoDB缺页中断并不一定表示有问题或需要调整数据库。

单页故障很快完成,不存在什么问题。然而,总的来说,大量的页面错误通常表示MongoDB从磁盘读取的数据太多。在多数情况下,MongoDB的读锁在缺页中断后将退出以允许其他进程读取并避免在等待下一个页面读取到内存中时发生阻塞。这种方法提高了并发,并提高了高容量系统整体的吞吐量。

提高MongoDB可访问的RAM量有助于减少缺页中断的频率。如果目前没有这种条件,你可以考虑在你的布署中部署一个 sharded cluster 或你的布署中添加 shards ,一边在 mongod 实例之间分配负载。

更多信息请参见 什么是缺页中断?

连接数

在某些情况下,应用层(即客户端)和数据库之间的连接数会压制服务器处理请求的能力。这会导致性能不正常。serverStatus 文档中的如下字段提供了直观的展示:

  • globalLock.activeClients 包含一个计算在内存或队列中有激活操作的客户端总数的计数器。

  • connections 包含如下两个字段 :

    • current 当前连接到数据库实例的客户端的总数.

    • available 可供新的客户端访问的未使用的连接的总数(英文原文为:the total number of unused collections available for new clients,我认为此处的collections是笔误,应是connections).

如果由于大量并发的应用请求导致请求占用很高,数据库可能满足不了(应用的)需求。如果是这个原因(造成的),那么你需要增加MongoDB布署的容量。对于读频繁的应用,增加你的 replica set 的大小并将读操作分配到 secondary 成员。对于写频繁的应用,布署 sharding 并向 sharded cluster 增加一个或多个 shards 以在各 mongod 实例间分担负载。

连接数(达到)峰值时也可能造成应用或驱动程序错误。所有官方支持的MongoDB驱动程序都实现了连接池。连接池允许客户端更有效地利用和重用连接。连接数特别高,尤其又没有相应的工作负荷,(这种情况)往往表明驱动程序或其他配置错误。

除非受制于系统范围的约束,否则MongoDB对接入的连接没有限制。你可以使用 ulimit 命令或通过修改系统的 /etc/sysctl 文件来修改系统的限制。更多详情请参见 UNIX系统下 ulimit 的设置

数据库分析

MongoDB的 “探查器” 是一个可以帮助确定低效的查询和操作的系统数据库分析系统。

可以使用如下的分析级别:

级别

设置

0

关。不分析

1

开。但只包含 “缓慢的” 操作

2

开。包含*所有*操作

Enable the profiler by setting the profile value using the following command in the mongo shell:

db.setProfilingLevel(1)

slowOpThresholdMs 的设置定义了何谓 “慢” 的操作。(如果)要设置阈值——即超过它探查器就认为某操作 “慢”(和因此该被列入级别”1”的分析数据) ,你可以设置 slowOpThresholdMs 作为 db.setProfilingLevel() 操作的运行时参数。

参考

The documentation of db.setProfilingLevel() for more information about this command.

默认情况下, mongod 将所有被 slowOpThresholdMs 定义为 “慢” 的操作记录在它的 log 中。

注解

由于数据库探查器会对性能产生负面影响,仅仅用合适的时间间隔启用探查并尽可能少地用在生产环境中.

你应当基于每个 mongod 启用探查.该设置不会在 replica setsharded cluster 中传播.

你可以在 mongo 命令行中使用 show profile 命令,以在数据库的 system.profile 集合中查看探查器的输出结果,或者你可以使用以下操作:

db.system.profile.find( { millis : { $gt : 100 } } )

这将返回所有持续时间超过100 毫秒的操作。确保此处指定的值 (‘在这个例子中是 “100”) 在 slowOpThresholdMs 阈值以上。

参见

Optimization Strategies for MongoDB 讲述了改善数据库查询和操作性能的策略.

复制和监控

除了对任意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 的值并特别留意 primarysecondary 成员们的时间差.

分片和监控

在大多数情况下,:term:sharded clusters <sharded cluster> 的组件和所有其他的MongoDB实例同样受益于监测和分析。另外,集群需要更深入的监测以确保数据被高效地分发在各节点之间,并且分片操作正确地发挥了作用。

参见

更多信息请参阅 分片概念介绍 .

配置服务器

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.

由于不可访问的配置服务器会严重影响一个分片集群的可用性,(所以),您应该监控配置服务器以确保群集保持良好的平衡并且 mongos 实例可以重新启动。

MMS Monitoring 可以监控配置服务器并在配置服务器不可访问时创建通知.

均衡和数据块分布

最高效的 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" } )

如果这个锁存在,确保平衡进程显式地使用了该锁。