mongodb_exporter无法反映GridFS真实磁盘使用，因其不采集fs.chunks/fs.files集合的storageSize，仅暴露数据库级逻辑数据量指标；需自建采集器执行collStats命令并暴露Prometheus指标。
不能直接监控 GridFS 磁盘占用 —— mongodb_exporter 不采集 GridFS 文件大小或底层存储用量，它只暴露数据库级指标（如 mongodb_mongod_storage_data_size_bytes），而该值反映的是 WiredTiger 引擎的「逻辑数据量」，不是 GridFS 实际占的磁盘空间。
为什么 mongodb_exporter 无法反映 GridFS 真实磁盘使用？
GridFS 是 MongoDB 的文件存储抽象层，实际把大文件拆成 fs.chunks 和 fs.files 两个集合存储。但：
• mongodb_exporter 默认不采集集合级大小（即使启用了 collection 收集，也只返回文档数、平均对象大小等，不包含磁盘块占用）
• WiredTiger 的 dataSize / storageSize 统计在 db.stats() 中，但 exporter 不将其映射为指标
• node_filesystem_* 属于系统层指标，和 GridFS 无语义关联，只能告诉你挂载点总用量，无法区分是 GridFS 还是普通集合占的
真正能用的替代方案：用 db.runCommand({ "collStats": "fs.chunks" }) 手动补指标
必须绕过 exporter，自己写一个轻量采集器（例如 Python 脚本），定期执行命令并暴露为 Prometheus 格式 HTTP 接口：
• 连接 MongoDB，执行 db.runCommand({ "collStats": "fs.chunks", "scale": 1024 })
• 提取 storageSize 字段（单位字节），加上 fs.files 的 storageSize
• 拼成 Prometheus 文本格式，例如：
gridfs_storage_bytes{collection="fs.chunks"} 2485671936<br>gridfs_storage_bytes{collection="fs.files"} 12456960
• 用 Flask 或 http.server 暴露 /metrics，让 Prometheus 抓取
配置 Prometheus 抓取时的关键注意点
如果你已部署了自定义 GridFS 指标端点：
• 在 prometheus.yml 的 scrape_configs 下新增 job，不要复用 mongodb_exporter 的 target
• 设置合理的 scrape_interval（建议 ≥ 30s，避免对主节点造成额外压力）
• 加上 relabel_configs 注入 job 和 instance 标签，否则 Grafana 查询时无法区分多个分片上的 GridFS
• 若 MongoDB 启用了认证，你的采集脚本必须带 username/password 参数，且账号需有 read 权限到 fs.* 集合（不能只靠 readAnyDatabase）
最常被忽略的一点：GridFS 占用增长往往滞后于业务上传行为，单纯看瞬时值容易误判；建议在 Grafana 里叠加 rate(gridfs_storage_bytes[1h]) 曲线，观察每小时净增趋势，比绝对值更有预警价值。
