解读

在国内金融、政务、IoT 等 CouchDB 落地场景中，附件（attachment）常被用来存储证照扫描件、设备日志包、图片等大对象。一旦附件读写出现积压，会拖慢整个复制链，甚至触发移动端同步超时。
“att_read_time” 是 couch_stats 中 attachment 维度的直方图指标，单位纳秒，记录每次附件读取耗时。面试时，面试官想确认候选人能否：

1. 把“高耗时”翻译成可量化的阈值；
2. 结合集群拓扑、磁盘类型、并发量给出判断逻辑；
3. 给出可落地的监控+报警方案，而不是只背指标名。

知识点

1. 指标来源：CouchDB 内部使用 Folsom 直方图统计，通过 /_node/<name>/_stats/couchdb/attachment_read_time 暴露，字段包含 min、max、mean、median、95/99/999 分位。
2. 单位换算：返回值为 ns，面板展示需 ÷1 000 000 转为 ms，方便与磁盘 RTT 对比。
3. 基线建立：
   • SSD 本地盘：mean ≤ 2 ms、P99 ≤ 8 ms；
   • 云盘（ESSD PL1）：mean ≤ 5 ms、P99 ≤ 20 ms；
   • 机械盘或 NFS：mean ≤ 15 ms、P99 ≤ 50 ms。
     超过基线即可判定“附件存储层出现瓶颈”。
4. 关联指标：
   • httpd_request_time 同步上涨 → 附件拖累整体查询；
   • open_databases 不变但 couch_file 句柄数飙升 → 附件句柄泄漏；
   • 操作系统 iostat -x 中 %util > 70% 且 await 与 att_read_time 同步抬高 → 磁盘层瓶颈确认。
5. 监控工具链：
   • 开源：Prometheus + couchdb_exporter，Grafana 面板配置 99 分位告警；
   • 阿里云 SLS：通过 Logtail 采集 /_stats，用 SQL 计算 P99；
   • 政务私有云：Zabbix 5.0 以上支持直方图拆点，触发器表达式 last(couchdb.att_read_time.p99)>20ms 连续 3 次即告警。
6. 采样频率：生产环境 30 s 拉取一次即可，过密会加重 beam.smp CPU。

答案

第一步，采集指标：
curl -u $USER:$PASS http://127.0.0.1:5984/_node/couchdb@127.0.0.1/_stats/couchdb/attachment_read_time
拿到 percentile.99 字段，除以 1 000 000 得到毫秒值。

第二步，设定阈值：

• 若使用 SSD，P99 连续 5 分钟 > 8 ms 即判定瓶颈；
• 若使用云盘，P99 > 20 ms 且同时 httpd_request_time P99 上涨 30% 以上，判定瓶颈。

第三步，根因确认：

1. 登录节点执行 iotop -a，看 beam.smp 是否占满磁盘 IO；
2. ls -lh data/*.couch 观察数据库体积，若单库 > 50 GB 且附件占比 > 70%，考虑 sharding 或 分离附件到对象存储；
3. 检查是否启用 compression=snappy，未压缩的 PDF/图片会放大读延迟。

第四步，应急与优化：

• 短期：提高 max_open_files、升级 ESSD PL2、增加 file_cache_size；
• 长期：把只读附件迁移至 MinIO 或 OSS，CouchDB 仅存元数据与缩略图，彻底消除 att_read_time 抖动。

拓展思考

1. 如果集群开启 跨区域复制，附件读取可能发生在目标端生成校验和时。此时 att_read_time 飙高，但源端磁盘正常，如何通过 复制会话日志 定位是哪一端的 reader 进程？
2. 在移动端离线同步场景，用户可能一次性拉取上百张图片附件。如何结合 att_read_time 与 replication_jobs 指标，动态限流以避免 4G 网络下超时重试？
3. 国内等保 2.0 要求审计所有附件访问。若开启 access_logger，高并发下日志写盘会叠加在 att_read_time 上，如何拆分“业务读”与“审计写”各自耗时，避免误判瓶颈？