解读

在国内生产环境中，CouchDB 往往以 3～7 节点的多主集群形式部署，每个节点独立暴露 5984 端口。运维团队用 Grafana 做统一可视化，但 CouchDB 原生并不提供“集群视图”接口，因此必须借助外部发现机制让 Grafana 感知节点列表，并通过变量下拉框实现零脚本、零重启的节点切换。面试官想考察的是：你是否理解 CouchDB 的无中心架构、是否能把 Grafana 的变量模板与数据源动态化结合起来，以及是否具备可观测性落地的实战经验。

知识点

1. CouchDB 多主特性：每个节点都是完整副本，_membership 返回 all_nodes 与 cluster_nodes，但无 Leader 概念。
2. Grafana 变量类型：Query 变量支持 Prometheus、JSON API、Elasticsearch 等数据源；对 CouchDB 需自建 HTTP Endpoint或Prometheus Service Discovery。
3. 数据源模板化：Grafana 9.3+ 支持**${couchdb_node}** 直接写在 URL 路径或 Header 中，实现单数据源多实例复用。
4. 国内网络限制：若集群位于阿里云 VPC，需通过内网 SLB + 自定义域名暴露节点，避免 5984 端口直接公网开放。
5. 权限合规：生产环境必须开启 _admin 认证，Grafana 使用只读密钥访问 _node/_local/_stats，符合等保三级最小权限要求。
6. 高可用兜底：当变量选中节点宕机，Grafana 的**“Failover” 插件或Nginx 502 重试**可自动漂移到存活节点，避免面板空白。

答案

步骤一：构建节点发现接口
在任意一台 CouchDB 节点部署Python Flask 旁路服务，定时调用 GET /_membership，把 all_nodes 数组转成 JSON：
[{"text":"couchdb-1.aliyun.local","value":"10.0.1.11:5984"},…]
该接口自身做三节点探活，只返回健康实例，符合国内**“可观测性先行”**的规范。

步骤二：Grafana 侧配置变量

1. 新建 Query 变量，数据源选 JSON API（需插件）或 SimpleJson，URL 填 http://couchdb-discovery.internal:8080/nodes。
2. 设置 Refresh=On Time Range Change，保证节点列表实时。
3. 开启 Multi-value 与 Include All，方便对比多节点指标。

步骤三：模板化数据源
在 Grafana 新建 CouchDB 数据源，URL 填写 http://${couchdb_node}/_node/${couchdb_node}/_stats，并勾选 Forward OAuth Identity 关闭，使用Basic Auth只读账号。
面板 JSON 中所有查询的 datasource.uid 保持同一值，Grafana 会在请求前把变量动态替换为实际 IP:Port，实现单面板无差别切换。

步骤四：验证与灰度

1. 在测试组织先发布，确认杭州、上海双可用区节点切换延迟 <1s。
2. 通过阿里云云监控触发 5984 端口宕机演练，观察 Grafana 是否自动剔除失效变量项。
3. 完成运维评审后，再推到生产只读组织，符合国内**“变更三级审批”**流程。

拓展思考

1. 多云场景：若集群跨华为云与腾讯云，需把节点发现接口做成地域级 DNS-SD，通过 SRV 记录返回优先级，避免跨地域延迟。
2. 指标深度：CouchDB 的 _stats 只到 Erlang VM 级别，想看分区复制延迟，需额外采集 _scheduler/jobs 并写入 Prometheus Exporter，再用 Grafana 的Recording Rule预聚合，降低面板查询压力。
3. 权限更细：国内金融客户要求**“字段级脱敏”，可在发现接口侧对节点地址做AES 加密**，Grafana 变量获取后通过解密插件还原，满足人行金融数据分级要求。