监控 mongot 部署

mongot 是一个基于 Lucene、由 Java虚拟机（JVM）托管的内存映射搜索引擎。它的运行特性与 mongod 不同：

信号类别

category	它告诉您什么
健康	`mongot` 进程是否已启动、完成启动并准备接受工作。
复制	`mongot` 进程是否与 `mongod` 变更流同步。如果不同步，此数据将告诉您其落后的程度。
索引	mongot 进程是否正在建立和维护索引、合并是否正在进行以及初始同步是否正在进行。
查询	`$search`、`$searchMeta` 和 `$vectorSearch` 之间的延迟、吞吐量和错误率。
执行程序池	线程池利用率和队列深度。这里的饱和预测了查询延迟的降级。
JVM	与 Java 虚拟机（JVM）上的堆、垃圾回收和线程相关的指标。
记录	与 CPU、内存、硬盘 I/O、网络相关的指标（在进程或容器级别）。
存储	与 IOPS、页面错误率和空间有关的指标。
内嵌	启用自动化嵌入时，对 Voyage AI 终结点的吞吐量和错误率。

这些是要监控的关键信号。如果您只能监控少数信号，请从这些信号开始：

50百分位数 (p50) 和 99百分位数 (p99) 对 $search 和 $vectorSearch. 的查询延迟。请特别关注 p99，因为 mongot 部署在存储或内存压力下会呈现非线性降级。p99 会在 p50 之前出现问题。
索引管理请求的延迟，例如createSearchIndex、getSearchIndexes和$listSearchIndexes聚合阶段。这些请求的峰值可能表示mongot忙碌或无法从mongod访问。

自 mongod 应用上次更改事件以来的时间。此信号直接暴露为 mongot_index_stats_indexing_replicationLagMs（每索引，毫秒）。从不到一秒到几秒的小型稳态滞后是正常的。但是，滞后增加表明 mongot 无法跟上。持续滞后最终会脱离 oplog 并强制重新同步。重新同步比滞后本身更糟糕，因为它需要完全重建索引。完全索引重建计算成本高且耗时。
mongot_index_stats_* 每个搜索索引都会发出指标，并且只有在至少存在一个索引时才会出现。在没有索引的全新部署中，复制延迟系列不存在，而不是零。这很正常。

查询执行器和索引执行器的队列深度。持续的非零队列深度表示饱和，并且查询正在等待工作线程。这是一个非常早的警告，延迟将会增加。

持续的磁盘 IOPS 超过设备的安全运行点表明存储是瓶颈。存储类咨询阈值为 1,000 持续 IOPS，作为标志。有关详情，请参阅mongot 的存储类建议。
缺页率。持续搜索缺页高于 1,000/秒表明操作系统反复从磁盘中拉取索引页面，而不是从缓存中提供这些页面。在 IOPS 升高的情况下，这是关键路径上内存压力的典型信号。

mongot dataPath 卷上的可用空间少于 20% 会导致可用性问题。合并可能需要超出实时索引占用空间的磁盘空间。如果卷的大小不合适，可能会导致静默失败。

处于稳定状态的健康 mongot 部署具有以下信号：

如果所有这些都是真的，则认为部署是健康的。如果存在任何偏移，请参阅相关页面以获取更深入的指标进行调查。

Atlas 用户具有：

自管理用户具有：

自管理用户必须在投入生产之前建立监控。

后退

备份和恢复

来年

为新部署设置监控