Ops Manager 和Cloud Manager可以监控数据库指定的指标，包括页面错误、ops计数、队列长度、连通性以及复制集的状态。每个监控指标都可以设定告警，在系统出现问题之前主动的给管理员提供预警信息。
应用日志和数据库日志应用日志和数据库日志是系统排错的主要依据。有时候为了确认系统的故障是否是由应用引起的，就需要把应用日志和数据库日志关联起来。比如，用户写入高峰期会增加MongoDB系统写入容量，就会使底层存储过载。如果不把应用日志和数据库日志关联起来排错，遇到上述问题很可能认为是MongoDB的运行的程序引起的，而不会想到是应用引起的这个问题。
如果遇到错误或者意外的情况发生，提技术case的时候应该同时提供日志信息。主次节点以及mongod服务器、配置服务器上的日志信息会帮助技术支持软对快速的定位的问题的发生原因。
页面错误工作集数据超过内存，或者其他操作把工作集数据移出内存时，MongoDB系统的页面错误会激增。页面错误是MongoDB系统正常操作的一部分，但是建议管理员监控页面错误的容量，以便查看工作集的大小是否超过内存。大部分情况下，MongoDB系统的底层问题很有可能是由页面错误引起的。
硬盘除了内存，硬盘I/O也是MongoDB的一个关键性能指标，因为日志信息和数据写入会定时刷入到硬盘中。数据写入压力很大时，会引起硬件设备过载、进程抢夺资源以及RAID配置无法承受写入压力等情况。尽管引起问题的原因很多，使用iostat可以查看症状，比如较高的硬盘利用率和较高的写入队列等。
CPU有很多因素会使CPU的利用率增高。这在很多情况下是正常的，但是如果不是由于硬盘饱和或者页面错误导致的CPU利用率高，那么说明系统中肯定异常。比如，MapReduce中的无限循环，或者在没有索引的工作集中进行大量的数据写入，都会在不影响硬盘或者页面错误的情况下导致CPU过载。
连接MongoDB有连接池的功能，这样就可以充分利用资源。每个链接会消耗1M的RAM，所以需要谨慎的监控连接数，不要使连接数占用过多的RAM，节省资源用户工作集。连接数过载通常是由于客户端没有正常关闭链接，尤其是使用垃圾回收机制关闭链接的JAVA。
队列如果MongoDB不能及时完成所有请求，那么请求就会形成队列。一个健壮的系统，它的队列是比较低的。如果度量标准开始偏离了基线性能，比如，可能是由页面错误或者长时间的查询引起的，那么，应用的请求就会形成队列。因此，查看系统是否存在影响用户体验的一个重要指标就是队列。
系统配置MongoDB部署过程中经常需要对硬件进行调整。比如，我们经常会用硬盘子系统取代现有硬盘以便提供更好的性能和更大的容量。当硬件原件调整后，需要确认他们的配置适应系统部署。MongoDB对操作系统的性能和底层硬件是很敏感的，通常情况下，系统的默认设置并不是很理想。比如，文件系统的默认readahead值是几M，但是，通常会把这个值优化到32KB。如果新的存储系统使用默认的readahead值，而不进行优化，那么应用的性能会大幅降低。
分片平衡器分片的一个目的就是要平均的把数据分散到多个服务器中。如果各个服务器资源的利用率不是平均分配的，那说明系统肯定有潜在的问题存在。比如，分片键如果选择不合适，就会导致数据分配不均匀。这种情况下，大多数查询会被路由到单个mongod服务器中。因此，MongoDB系统会试图重新分配数据，使数据达到理想的平衡状态。尽管重新分配会使文档达到比较理想的分布状态，但是重新平衡的过程也会涉及到一些潜在的工作，重新平衡的过程也会使系统达到理想的性能状态。通过运行db.currentOp()可以查看当前系统运行的进程，包括集群中运行的重新平衡进程。
MongoDB3.4中，平衡器支持多线程数据迁移。多个节点可以同时进行迁移工作，有效的提高迁移效率。除此之外，平衡器的节流功能默认的是关闭的，可以把迁移的速度提高10倍以上。
如果系统部署过程中，需要加入新的片键，那么就有必要对数据进行重载，因为片键的值是固定不变的。建议编写脚本来读取文档，并且更新片键，并把数据再写回到数据库中。
复制延迟