MongoDB Atlas 看不到的诊断记录：用 FTDC 找回实例运行现场

预计阅读时间：7 分钟

MongoDB 服务器自带一台低调的“飞行记录仪”：FTDC（Full Time Diagnostic Data Capture）。它持续把运行指标写入 diagnostic.data，并通过增量编码和压缩保存较长时间的历史。来源文章指出，一台 MongoDB 服务器每秒会记录约 5,700 项指标。对排查偶发慢查询、复制延迟尖峰、缓存抖动和磁盘拥塞来说，这类时间序列现场往往比一段日志更有价值。

但在 MongoDB Atlas 中，运维人员通常无法直接取得这些原始 FTDC 文件。这意味着托管平台的监控图表可以告诉你“发生了什么”，而 FTDC 更接近回答“当时服务器内部各子系统分别在做什么”。

FTDC 记录的不是业务日志

FTDC 不是 mongod.log 的替代品。日志适合追踪单个事件，例如连接断开、选举、索引构建失败或慢操作；FTDC 则是连续采样的诊断快照，覆盖服务器状态中的大量计数器和资源指标。

可以把两者的职责分开：

日志用于定位明确事件及其上下文。
慢查询日志或 profiler 用于关联具体请求、集合和索引。
FTDC 用于还原一段时间内 CPU、内存、连接、锁、WiredTiger、复制和网络指标如何共同变化。

例如，业务方报告“每天 10:05 左右写入变慢”，单独看慢日志可能只能看到大量操作耗时增加。结合 FTDC 的时间序列，才可能进一步判断是缓存压力上升、磁盘队列堆积、checkpoint 活动，还是复制链路开始落后。

为什么 Atlas 用户会感到信息缺口

Atlas 提供监控、告警和托管诊断能力，但原始 FTDC 目录属于底层服务器运行现场，并不是普通 Atlas 用户可像自管主机那样直接下载、离线解析的文件集合。

这并不表示 Atlas 监控不足，而是可观测性的边界不同：

Atlas 监控适合日常容量观察、告警和托管服务运维。
原始 FTDC适合需要做深度事后分析、与主机指标对齐、或交由数据库支持工程师研究的场景。
自管 MongoDB可以自行保留、归档和分析 FTDC，但也要自行承担访问控制、磁盘容量和诊断数据管理责任。

因此，迁移到 Atlas 时不要假设所有自管环境中的诊断取证流程都能原样保留。对于严格的故障分析要求，应提前确认需要哪些 Atlas 指标、日志导出能力和支持流程。

在自管实例中收集 FTDC

在自管 MongoDB 节点上，FTDC 通常位于 dbPath 下的 diagnostic.data 目录。实际位置取决于你的 mongod.conf 配置，例如：

storage:
  dbPath: /var/lib/mongodb
systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log

对应的诊断目录通常是：

/var/lib/mongodb/diagnostic.data

故障发生后，可以用下面的脚本收集一份带时间戳的诊断包。运行前将 MONGO_DBPATH 改为实际 dbPath；脚本只读取并打包文件，不会修改 MongoDB 配置或重启服务。

#!/usr/bin/env bash
set -euo pipefail

MONGO_DBPATH="/var/lib/mongodb"
FTDC_DIR="${MONGO_DBPATH}/diagnostic.data"
OUT_DIR="/tmp/mongodb-diagnostics"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
ARCHIVE="${OUT_DIR}/ftdc-${STAMP}.tar.gz"

if [[ ! -d "${FTDC_DIR}" ]]; then
  echo "FTDC directory not found: ${FTDC_DIR}" >&2
  exit 1
fi

mkdir -p "${OUT_DIR}"
tar -C "${MONGO_DBPATH}" -czf "${ARCHIVE}" diagnostic.data
sha256sum "${ARCHIVE}" | tee "${ARCHIVE}.sha256"
echo "Created: ${ARCHIVE}"

保存为 collect-ftdc.sh 后执行：

chmod +x collect-ftdc.sh
sudo ./collect-ftdc.sh

打包前要确认输出目录不在 MongoDB 的数据目录内，避免诊断包本身占用数据库磁盘空间。若要把文件交给外部支持团队，还应按内部安全规范检查其中是否可能关联主机名、时间信息或其他运维元数据。

把 FTDC 纳入故障处理流程

FTDC 的价值取决于时间关联，而不是单次随手导出。一个实用流程是：

统一记录告警时间，使用 UTC，避免应用、数据库和监控系统时区不一致。
同时保留 mongod.log、操作系统指标和 FTDC 归档。
记录当时的版本、部署拓扑、节点角色及刚发生的变更。
在保留期结束前完成归档，因为循环写入的诊断数据会逐渐覆盖较早历史。
将 FTDC 曲线与慢查询、复制延迟、磁盘延迟及应用请求量放到同一时间轴上分析。

不要把 FTDC 当作“打开就能得到结论”的万能工具。它更适合验证假设：写入延迟升高时 WiredTiger 指标是否同步异常？主节点复制压力增加是否早于选举？某次发布后连接数和资源消耗是否出现结构性变化？

采用建议

对于自管 MongoDB，建议把 diagnostic.data 视为故障现场的一部分，和日志、配置快照及系统指标一起进入事件响应清单。对于 Atlas，重点应转向可获得的监控维度、日志保留策略和支持升级路径，并在上线前验证它们是否覆盖关键排障场景。

关键不在于收集更多文件，而在于确保发生性能事件时，你仍能拿到足够连续、足够可信的数据来重建当时的运行状态。