管理MongoDB：准备、监视和灾难恢复
Ops Manager是由开发数据库的工程师创建的，是运行MongoDB的最简单方法，使操作团队易于部署、监视、备份和扩展MongoDB。Ops Manager的许多功能在托管在云中的MongoDB Cloud Manager服务中也是可用的。今天，云管理器支持成千上万的部署，包括从一台到几百台服务器的系统。使用MongoDB Enterprise Advanced运行部署的组织可以在Ops Manager和Cloud Manager之间进行选择。
Ops Manager和Cloud Manager结合了最佳实践来帮助保持被管理的数据库健康和优化。它们通过单击按钮或通过API调用将复杂的手动任务转换为可靠的自动化过程来确保操作的连续性：
部署。任何拓扑，任何规模
升级。几分钟之内，不用停机
扩展。扩展容量，而不需要关闭应用程序。
时间点，计划备份。只需几次单击即可将完整的运行集群恢复到任何时间点，因为灾难是不可预测的。
性能警报。监视100多个系统度量并在系统降级之前获得自定义警报。
Roll Out索引。通过逐个节点引入新的索引来避免对应用程序的影响——从第二索引开始，然后是降级的主索引。
管理区域。配置分片区域，以命令将哪些数据存储在何处。
Operations Rapid Start服务为您的操作和开发团队提供了运行和管理MongoDB的技巧和工具。此约定提供介绍性的管理员培训和定制咨询，以帮助您设置和使用MongoDB Ops Manager或MongoDB Cloud Manager（对于那些不想在内部维护自己的管理和备份基础设施的操作团队可用）。
部署与升级
Ops Manager在MongoDB系统中协调跨服务器的关键操作任务。它通过安装在每个服务器上的代理与基础设施通信。服务器可以驻留在公共云或私有数据中心。Ops Manager可靠地编排管理员传统上手动执行的任务——部署新集群、升级、创建时间点备份、推出新索引和许多其他操作任务。
Ops Manager被设计成通过不断评估状态并根据需要做出调整来适应出现的问题。以下是具体内容：
- Ops Manager代理安装在服务器上（MongoDB将在其中部署），或者通过诸如Chef或Puppet之类的配置工具，或者由管理员安装。
- 管理员为系统创建新的设计目标，或者作为对现有部署的修改（例如，升级、oplog大小调整、新分片），或者作为新系统。
- 代理定期向Ops Manager中央服务器签入并接收新的设计指令。
- 代理创建并遵循实现设计的计划。使用复杂的规则引擎，代理会随着条件的变化不断调整他们的个人计划。在许多故障场景（如服务器故障和网络分区）面前，代理将修改其计划以达到安全状态。
- 几分钟后，系统被安全可靠地部署。
除了部署新数据库之外，Ops Manager和Cloud Manager还可以“附加”或导入现有的MongoDB部署并接管它们的控制。
除了初始部署，Ops Manager和Cloud Manager还可以通过添加分片和副本集成员来动态调整容量大小。其他维护任务，如升级MongoDB或调整操作日志的大小，可以从几十或数百个手动步骤减少到单击按钮，所有这些操作都具有零停机时间。
一个常见的DBA任务是在生产系统中推出新的索引。为了最小化对活动系统的影响，最佳实践是执行滚动索引构建——从每个从节点开始，在与一个从节点交换角色之后，对原始主节点进行更改。虽然这个滚动过程可以手动执行，但是Ops Manager和Cloud Manager可以跨MongoDB副本集自动化该过程，从而减少操作开销和由错误排序的管理过程导致的故障转移。
管理员可以直接使用Ops Manager接口，或者从现有企业工具（包括流行的监视和编排框架）调用Ops Manager RESTful API。特定的集成提供了领先的应用程序性能管理（APM）工具。详细信息将在本指南的稍后部分介绍。
监测与容量规划
系统性能和容量规划是应该作为MongoDB部署的一部分处理的两个重要主题。计划的一部分应该包括建立数据卷、系统负载、性能和系统容量利用率的基线。这些基线应该反映您期望系统在生产中执行的工作负载，并且它们应该随着用户数量、应用程序特性、性能SLA或其他因素的改变而定期重新审视。
基线将帮助您理解系统何时按设计运行，以及何时开始出现可能影响用户体验质量或对系统至关重要的其他因素的问题。监视MongoDB系统的异常行为非常重要，以便能够采取措施主动地解决问题。以下是监视MongoDB的最流行工具，并且还描述了应该监视的系统的不同方面。
使用Ops Manager与Cloud Manager监控
具有图表、自定义仪表板和自动报警，Ops Manager跟踪100个以上的主要数据库和系统健康指标，包括操作计数器、内存和CPU利用率、复制状态、打开连接数、队列和任何节点状态。
图4：Ops Manager：简单、直观、强大。单击一次即可部署和升级整个集群。
这些度量被安全地报告给Ops Manager和Cloud Manager，在浏览器中对它们进行处理、聚合、警告和可视化，让管理员可以轻松地实时确定MongoDB的健康状况。视图可以基于显式的权限，因此项目团队可以限制权限，仅访问他们自己的应用程序，而系统管理员可以监视组织中的所有MongoDB部署。
从MongoDB 3.4开始，Ops Manager允许每隔10秒收集一次遥测数据，高于之前最小的60秒间隔
可以回顾历史的表现，以便建立业务基线和支持能力规划。通过Ops Manager RESTful API，与现有监视工具的集成也很简单，使来自Ops Manager的深刻了解成为跨操作的统一视图的一部分。
Ops Manager允许管理员在关键指标超出范围时设置自定义警报。可以针对影响单个主机、副本集、代理和备份的一系列参数配置警报。警报可以通过SMS、电子邮件、网络钩子、Flowdock、HipChat和Slack发送，或者集成到现有的事件管理系统（如PagerDuty）中，以便在潜在问题升级到成本高昂的中断之前主动警告它们。
如果使用Cloud Manager，还可以与MongoDB支持工程师共享对监视数据的访问，从而通过消除在不同团队之间传送日志的需要，提供快速的问题解决方案。
图5：Ops Manager提供MongoDB部署的实时和历史可见性。
硬件监控
Munin node是一个开源软件程序，它监控硬件并报告磁盘和RAM利用率等指标。Ops Manager可以从Munin节点收集此数据，并将其与Ops Manager仪表板中可用的其他数据一起提供。虽然每个应用程序和部署都是唯一的，但是用户应该为磁盘利用率的高峰、网络活动的主要变化以及平均查询长度/响应时间的增加创建警报。、
mongotop
mongotop是与MongoDB一起提供的实用程序。它跟踪并报告MongoDB集群的当前读写活动。mongotop提供集合级别的统计数据。
mongostat
mongostat是与MongoDB一起提供的实用程序。它显示了MongoDB系统中所有服务器的实时统计数据。mongostat提供了所有操作的全面概述，包括更新、插入、页面错误、索引丢失以及系统健康的许多其他重要度量的计数。mongostat类似于Linux工具vmstat。
MongoDB Compass
尝试解析文本输出可以显著增加解决查询性能问题的时间。MongoDB Compass现在被扩展为可视化mongotop和mongostat生成的相同的实时性能统计数据，允许DBA生成服务器状态和查询性能的即时快照。
一些其他的流行工具
有许多流行的开源监控工具，MongoDB插件可用于这些工具。如果使用WiredTiger存储引擎配置MongoDB，则确保工具使用WiredTiger兼容的驱动程序：
• Nagios
• Ganglia
• Cacti
• Scout
• Zabbix
• Datadog
Linux实用工具
其他的一些通用的使用工具可以用来监控MongoDB系统的不同方面：
- iostat： 用来统计存储子系统的信息
- vmstat： 用来统计虚拟内存的信息
- netstat： 用来统计网络信息
- sar：定期捕获各种系统统计信息并存储它们以便分析
Windows实用工具
要监视的东西
Ops Manager和Cloud Manager可用于监视数据库指定的度量，包括页面错误、ops计数器、队列、连接和副本集状态。可以针对每个监控指标配置警报，以便在用户遇到问题之前主动警告管理员潜在的问题。
应用程序日志与数据库日志
应用程序日志和数据库日志应该监视错误和其他系统信息。为了确定应用程序中的活动是否最终负责系统中的其他问题，关联应用程序和数据库日志非常重要。例如，用户写入的激增可能增加对MongoDB的写入量，这反过来又会压倒底层存储系统。如果没有应用程序和数据库日志的相关性，那么可能需要花费更多不必要的时间来确定，是应用程序写入的增加，还是MongoDB中运行的某些进程导致的。
在发生错误、异常或意外行为的情况下，在开启支持案例时，应该保存日志并将其上传到MongoDB。在主副本集成员和从副本集成员上运行的mongod进程以及mongos和config进程中的日志将使支持团队能够更快地根除任何问题。
页面错误
当工作集不再适合内存，或者其他操作已经将工作集数据从内存中移出时，MongoDB系统中的页面故障量可能会激增。页面错误是MongoDB系统正常操作的一部分，但是应该监视页面错误的数量，以便确定工作集是否正在增长到内存大小已经不适合的级别了，以及是否有合适的备选方案，如跨多个服务器增加内存或分片。在大多数情况下，MongoDB系统中问题的根本问题往往是页面错误。还要使用指南前面讨论的工作集估计器。
磁盘
除了内存之外，磁盘I/O对于MongoDB系统也是一个关键的性能考虑因素，因为写操作是日志记录的，并且有规律地被发送到磁盘。在沉重的写负载下，底层磁盘子系统可能变得不堪重负，或者其他进程可能与MongoDB争用，或者RAID配置可能不足以满足写的操作。其他潜在的问题可能是根本原因，但是症状通常通过iostat可见，表现为用于写操作的磁盘利用率高和队列高。
CPU
各种各样的问题可能触发高CPU利用率。在大多数情况下，这可能是正常的，但如果观察到高CPU利用率而没有其他问题，如磁盘饱和或页面故障，则系统中可能存在不寻常的问题。例如，具有无限循环的MapReduce作业，或者对来自工作集的大量文档进行排序和过滤的查询，如果没有良好的索引覆盖率，可能导致CPU出现峰值，而不触发磁盘系统中的问题或页面故障。
连接数
MongoDB驱动程序实现了连接池，以便于资源的有效使用。每个连接消耗1MB的RAM，所以要小心监视连接的总数，这样它们就不会压倒RAM，并减少工作集的可用内存。这通常发生在客户端应用程序没有正确地关闭它们的连接，或者特别是Java时，依赖于垃圾收集来关闭连接。
运算计数器
应用程序的利用率基线将帮助您确定操作的正常计数。如果这些计数开始显著偏离您的基线，那么它可能是应用程序中发生了更改或正在进行恶意攻击的指示符。
队列
MongoDB无法及时完成所有请求，则请求将开始排队。健康的部署将显示出非常低的队列。如果度量开始偏离基线性能，例如由很高频的页面错误（MMAPv1）或长时间运行的查询导致的，则来自应用程序的请求将开始排队。因此，队列是确定是否存在会影响用户体验的问题的最佳首选位置。
系统配置
在MongoDB部署过程中对硬件和软件进行更改并不罕见。例如，可以替换磁盘子系统以提供更好的性能或增加的容量。当组件更改时，确保它们的配置适合于部署非常重要。MongoDB对操作系统和底层硬件的性能非常敏感，在某些情况下，系统配置的默认值并不理想。例如，文件系统的默认预读(readahead)可以是几个MB，而MongoDB对接近32KB的预读值(readahead )进行了优化。如果安装新的存储系统而不对预读进行从默认设置到适当设置的更改，则应用程序的性能可能显著降低。
分片平衡器
分片的目标之一是跨多个服务器均匀地分布数据。如果服务器资源的利用率在服务器之间不是大致相等的，那么可能存在部署有问题的底层问题。例如，选择不当的片键可能导致不均匀的数据分布。在这种情况下，大多数（如果不是全部）查询将指向管理数据的单个mongod。此外，MongoDB可能正在尝试重新分发文档，以便在服务器之间实现更理想的平衡。虽然重新分发最终将导致更理想的文档分发，但是与重新平衡数据相关的大量工作以及该活动本身可能妨碍实现期望的性能SLA。通过运行db.currentOp()，您将能够确定集群当前正在执行什么工作，包括跨分片重新平衡文档。
在MongoDB 3.4中，平衡器支持并行数据迁移。多个节点对可以同时执行平衡迁移，从而显著提高大型集群中的平衡器吞吐量。此外，WiredTiger的均衡器节流现在默认情况下是关闭的，从而加速了10倍的迁移效率。
如果在部署过程中确定应该使用新的片键，则需要用新的片键重新加载数据，因为片键的指定和值是不可变的。为了支持使用新的片键，可以编写一个脚本来读取每个文档、更新片键并将其写回数据库。
复制滞后
复制滞后是对主复制集成员进行写操作以复制到从成员所需的时间。少量的延迟是正常的，但是随着复制滞后的增长，可能会出现显著的问题。复制延迟的典型原因包括网络延迟或连接性问题，以及磁盘延迟，例如从设备的吞吐量低于主设备的吞吐量。
Config服务器可用性
在分片环境中，需要运行三个或更多个config服务器。config服务器对于理解文档在分片之间的位置至关重要。在这种情况下，数据库将继续运行，但是平衡器将无法移动块，并且其他维护活动将被阻塞，直到所有三个config服务器都可用。
默认情况下，Config服务器被部署为MongoDB副本集模式。Config服务器副本集可以跨越三个以上的数据中心，最多支持50个副本集成员，从而提供更高水平的可用性和更低的跨区域延迟。查看文档以了解更多信息。