解读

CouchDB 的 replication_failures 指标反映复制任务因网络、认证、冲突或磁盘等问题而失败的次数。国内生产环境普遍要求 5 分钟内发现-响应-记录，否则会被视为 SLO 破线。面试官想确认三件事：

1. 能否用 开源+国产化 组件完成指标采集、判断、告警、工单闭环；
2. 是否熟悉 CouchDB 暴露指标的途径（/_stats、/_active_tasks、/_node/_stats）以及 失败原因细分；
3. 是否能把 Jira 的创建、更新、关闭 与告警生命周期对齐，避免风暴。

知识点

1. 指标来源
   • /_stats/replicator 下的 failures 计数器，单位是累计值，需要自行算 rate()。
   • /_scheduler/jobs 返回每个复制任务的 state=failed 及 reason 字段。
2. 采集方案
   • Prometheus + exporter：社区有 couchdb-prometheus-exporter，也可基于 couchdb-exporter 二次开发，把 scheduler/jobs 解析成 couchdb_replication_failures_total{job_id, target, reason}。
   • 夜莺/Nightingale 作为国产统一告警平台，可直接抓取 Prometheus 数据。
3. 告警规则
   • increase(couchdb_replication_failures_total[5m]) > 0 且 持续 5 分钟，用 for: 5m 保证不是瞬时抖动。
   • 附加 标签：cluster、shard、target_node、reason，方便后续 Jira 组件 自动分派。
4. Jira 自动化
   • Alertmanager Webhook → 自研 gateway（Python/Go）→ Jira REST API（/rest/api/2/issue）。
   • Issue 模板 字段：
     – Summary：【CouchDB】复制失败持续 5 分钟
     – Labels：CouchDB、replication、{{ $labels.reason }}
     – Description：Markdown 表格列出失败任务、target、error、日志链接、Grafana 图表短链。
   • 幂等性：用 alertname+cluster+job_id 做 Jira 查询 JQL，若已存在 未关闭 工单则更新 comment，否则新建。
   • 自动恢复：当 increase==0 持续 3 分钟，调用 Jira API 添加 comment 并 transition 到 Resolved。
5. 权限与安全
   • Jira API Token 存在 K8s Secret 或 阿里云 KMS，RBAC 限制仅 alert-gateway 服务账号可读。
   • HTTP 双向 TLS 保证 CouchDB→Exporter 链路安全，满足国内 等保 2.0 要求。
6. 高可用
   • Alertmanager 三节点 集群，gateway 做 无状态 Deployment，HPA 按 QPS 自动扩容。
   • Jira 侧使用 Data Center 版，负载均衡 避免单点。

答案

给出一套可直接落地的 最小可用架构：

1. 指标侧：部署 couchdb-exporter，采集 /_scheduler/jobs，暴露 couchdb_replication_failures_total。
2. 规则侧：在 Prometheus 中写告警

   - alert: CouchDBReplicationFailures
     expr: increase(couchdb_replication_failures_total[5m]) > 0
     for: 5m
     labels:
       severity: critical
       team: dba
     annotations:
       summary: "CouchDB 复制失败持续 5 分钟"
       description: "集群 {{ $labels.cluster }} 任务 {{ $labels.job_id }} 因 {{ $labels.reason }} 失败"
   

3. 通知侧：Alertmanager 配置 webhook 指向内部 jira-gateway 服务。
4. 工单侧：jira-gateway 收到 JSON 后
   – 用 JQL 查询 project = COUCH AND summary ~ "复制失败" AND status != Closed；
   – 若无匹配，则 POST /rest/api/2/issue，body 包含 fields 与 labels；
   – 若已存在，则 POST /rest/api/2/issue/{key}/comment 追加 失败次数+时间戳。
5. 恢复侧：告警解除后，gateway 调用 transition id 将工单置为 Resolved 并备注 “复制已恢复，failures 归零”。
6. 测试：用 iptables 模拟 目标节点 5984 端口丢包，观察 failures 上升，5 分钟后 收到 Jira 工单，工单号 自动 @ 相关 DBA 与 SRE。

拓展思考

1. 多集群场景：若 CouchDB 部署在 两地三中心，需把 cluster 标签 映射到 Jira 的自定义字段“影响机房”，方便 值班经理 按地域分派。
2. 失败原因细分：把 401、timeout、checkpoint_missing 分别映射到 Jira 的 Priority：
   – 401 → High（权限问题需立即处理）；
   – timeout → Medium（网络抖动可延后）。
3. 容量联动：若 failures 与 disk_almost_full 同时告警，gateway 自动在 Jira 中创建 子任务 关联 运维值班组，实现 一站式跟踪。
4. 国产化替代：若公司使用 禅道 而非 Jira，只需把 jira-gateway 换成 zentao-gateway，调用 禅道 API（/api/v1/bugs），逻辑完全一致，可展示 横向适配能力。