Skip to main content

【译】MongoDB的监控

监控对于所有数据库管理而言都是一个非常重要的部分。牢牢掌握MongoDB的报表将会帮助我们了解数据库的状态,没有任何风险地维护我们的部署。此外,对MongoDB正常运维参数的一些常识可以帮助我们在出现故障之前诊断出问题。

这篇文档提供了MongoDB中可用监控工具和报表统计的概述。此外,还将结合搜啊诊断策略以及监控复制集和分片的建议。

监控策略

下面有三种方式可以用于收集关于运行中MongoDB实例状态的数据:

  • 首先,有一系列与MongoDB一起分布的实用工具提供数据库活动的实时报表
  • 第二,返回当前数据库更高保真状态统计的数据库命令
  • 第三,MongoDB Altas/MongoDB Cloud Manager等

每种策略都可以帮助回答不同的问题在不同的情景下都非常有用。这些方法是互补的。

MongoDB报表工具

这个部分介绍与MongoDB配套的报表方法,并且会提供一些每种方法最使用的问题示例,来帮助我们解决问题。

实用工具

MongoDB版本包括一系列实用的工具,能够快速返回关于实例性能和活动的统计。一般说来,这些对于诊断问题和获取正常操作最有用的工具。

mongostat

mongostat通过类型(例如,插入、查询、更新、删除等)来获取和返回数据库操作的计数。这些计数报告了服务器上的负载分布。

使用mongostat了解操作类型的分布和了解容量计划。

mongotop

mongotop追踪和报告一个MongoDB实例当前的读写行为,然后在每个集合的基础上报告这些统计数据。

使用mongotop来检查数据库活动和使用是否匹配我们的预期。

HTTP控制台

从3.2版本之后开始不再使用:MongoDB的HTTP接口

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

例如,如果本地运行的mongod使用的是默认的端口27017,可以通过 http://localhost:28017 获取HTTP控制台。

命令

这些数据可以提供一个比上面讨论的工具更佳粒度的报告。我们可以考虑使用脚本和程序中的它们的输出来开发定制化的警报或者修改与我们实例活动对应的应用中的行为。db.currentOp方法是另一个有用的工具用来识别数据库实例中正在运行的操作。

serverStatus

serverStatus命令或者shell中的db.serverStatus()返回数据库状态常见概述,包括磁盘使用、内存使用、连接、日志和索引都的细节。该命令能够快速返回并且不会影响MongoDB的性能。

serverStatus输出一个MongoDB实例的状态总和。这个命令很少直接运行。在大多数情况下,当聚合的时候,这些数据才会更有 意义。然而,所有的数据库管理员应该对serverStatus提供的数据非常熟悉。

dbStats

dbStats命令或者是shell中的db.stats()返回反映存储使用和数据体积的文档。dbStats体现了已经使用的存储大小、数据库中包含的数据量以及对象、集合和索引的计数。

使用这个数据来监控特定书库的状态和存储容量。这个输出也允许我们比较数据库之间的使用来确定数据库中的平均文档大小。

collStats

collStats命令或者shell中的db.collection.stats()提供了集合级别上类似于dbStats类似的功能包括集合中对象的计数、集合的大小、集合使用的磁盘空间大小以及索引的信息。

replSetGetStatus

replSetGetStatus命令(或者是shell中的res.status())返回我们数据集状态的总体情况.replSetGetStatus文档详细描述了复制集的状态和配置以及其成员的统计。

第三方工具

许多第三方检测工具都直接或通过它们的插件来支持MongoDB。

放置在自己主机上的监控工具

如果使用下面这些工具的话,我们必须在自己的服务器上安装、配置和维护这些监控工具。大部分都是开源的。

工具 插件 描述
Ganglia mongodb-ganglia 用于报告每秒操作、内存使用、btree统计、master/slave状态以及当前连接的Python 脚本。
Ganglia gmond_python_modules 解析从serverStatusreplSetGetStatus命令的输出。
Motop None MongoDB服务器的实时监控工具。每秒显示通过花费时间进行排序的当前操作。
mtop None 一个类似于top的工具
Munin mongo-munin 检索服务器统计
Munin mongomon 检索集合统计(大小、索引大小和一个数据库每个(配置的)集合计数)
Munin munin-plugins Ubuntu PPA 一些未在主版本中包含的其它munin插件
Nagios nagios-plugin-mongodb Python编写的简单Nagios检查脚本。
SPM 性能监控 MongoDB Docker代理 监控、异常检测和警报 SPM监控所有关键的MongoDB度量以及架构。Docker和其它应用度量,例如Node.js/Java/NGINX/Apach、HAProxy或者ElasticSearch。SPM可以在企业预制版中和云服务中可用,并提供度量和日志的关联。

也可以考虑dex,一个MongoDB的索引和查询分析工具,比较MongoDB日志文件和索引以进行索引的生成推荐。

主机的(SaaS)的监控工具

下面是一些通过主机服务提供的监控工具,一般是通过一个付费的订阅进行提供。
[MongoDB Cloud Manager](MongoDB Cloud Manager)
VividCortex
Scount
ServerDensity
Application Performance Management
New Relic
Datadog
SPM 性能监控

处理日志

在正常操作期间,mongod和mongos实例报告所有服务器活动和操作的动态计数到一个标准输出或者一个日志文件中。下面的运行时间设置控制了这些选项:

  • quiet 限制了写入日志或输出的信息量。
  • verbosity 提高写入日志或输出的信息量。我们也可以在运行的同时使用loglevel参数或者shell中的db.setLogLevel()方法来修改日志中的信息显示。
  • path 允许日志到一个文件而不是标准输出。在调整配置时,我们必须制定日志文件的完整路径。
  • logAppend 向日志文件中增加信息而不是覆盖文件。

注意:我们可以将这些配置操作作为命令行参数发送给mongod或mongos中。例如:mongod -v --logpath /var/log/mongodb/server1.log --logappend。在verbose模式启动一个mongod实例,将数据叠加到/var/log/mongodb/server1.log/位置的日志中。

下面的数据库命令也会影响日志:

  • getLog 展示mongod进程日志中最新的信息。
  • logRotate 只循转mongod进程的日志文件。

日志修订

3.4版本开始:只在MongoDB企业版中提供
运行着security.redactClientLogData的mongod在记录日志之前修订与任何给定日志时间相关的信息,只留下元数据、源文件或者与时间祥光的行数。security.redactClientLogData防止在小号诊断细节的情况下组织潜在的敏感信息进入到系统日志。

例如,下面的操作向一个没有日志修订的mongod中插入文档。mongodsystemLog.component.command.verbosity设置为1

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

该操作有下面的日志事件:

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
   }

而运行着security.redactClientLogData的mongod执行相同的操作生成下面的日志事件:

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

使用redactClienLogData与加密一同使用来满足规则要求。

诊断性能问题

当我们使用MongoDB开发和运维应用时,我们想要分析数据库作为应用的性能。MongoDB性能讨论了一些可能会影响性能的运维因素。

复制和监控

除了对任何MongoDB实例的基础监控要求之外,对于复制集而言,管理员必须监控复制集延迟。“复制集演延迟”指的是从主节点复制到从节点复制所花费的时间大小。一些小的延迟时间段可以接受,但是当复制延迟增加时,会出现两个非常严重的问题:

  • 首先,在延迟阶段出现的操作没有复制到一个或多个从节点。如果我们使用复制集来保证数据的持久化,异常长的延迟可能会影响我们数据的可靠性。
  • 其次,如果复制的延迟超过了操作日志的长度,那么MongoDB将会必须在从节点上执行初始化并行,将所有的数据从主节点复制到从节点,并且重建所有索引。在正常情况下,这是不正常的操作,但是如果我们将操作复制配置到小于默认值, 那么这个问题有可能会出现。

注意:操作日志的大小只能在第一次运行的时候在mongod命令中使用--oplogSize参数进行配置,或者,更推荐的是:在MongoDB的配置文件中设置oplogSizeMB。如果我们没有在使用--reploSet选项之前指定该命令行,mongod将会创建默认大小的日志。默认地,日志在64位系统中位全部可用磁盘空间的5%。

复制问题最常见的原因是成员之间网络的连通性问题,或者是主节点没有资源支持应用和复制流量的结果、可以使用replSetGetStatus或者shell中下面的帮助来检查复制集的状态:

rs.status()

replSetGetStatus参考提供了一个关于这个结果更加深入的概述。一般说来,可以查看optimeDate和特别光柱主节点和从节点成员之间的时间差。

分片和监控

在大多数情况下,分片集群的组件可以和所有其它MongoDB实例一样从相同的监控和分析中受益。此外,集群要求进一步的监控以保证数据在节点之间是高效地分布并且分片操作正在正常运行。

配置服务器

配置数据库维护了一个map,标识哪些文档位于哪些分片上。当块在不同的分片上移动时,集群更新map。当一个配置服务器变得不可到达时,一些分片操作将会不可用。例如迁移块和启动mongos实例。但是,集群将会在已经运行的mongos实例上保持可用。

由于不可到达的配置服务器可能会严重影响分片集群的可用性,我们应该监控我们的配置服务器以保证集群宝成均衡和mongos实例可以重启。

均衡和块分布

最高效的分片集群将块均匀分布在分片中。为了实现这个,MongoDB有一个后台的均衡进程能够将数据进行分发,以保证数据块经常在分片中均匀分布。

通过mongo shell向 mongos发送db.printShardingStatus() 或者sh.status()命令。它们将会返回整体集群的概述,包括:数据库名称和一系列的块列表。

过时的锁

想要检查数据库的锁状态时,使用mongo shell连接到一个mongos实例。使用下面的命令序列切换到config数据库然后展示分片数据库中的所有锁:

use config
db.locks.find()

均衡过程中使用一个特殊的balancer锁来阻止发生其它均衡活动。在config数据库中,使用下面的命令来查看balancer锁。

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

从3.4开始,CSRS配置服务器的主节点使用一个进程ID为ConfigServer的进程持有balancer锁。这个锁永远不会被释放。

参考文献

  • https://docs.mongodb.com/manual/administration/monitoring/
打赏
微信扫一扫支付
微信logo微信扫一扫, 打赏作者吧~

mickey

记录生活,写给几十年后的自己。