使用 etcd 实现自定义服务发现

概述

在SRE实践中，服务发现（Service Discovery）是实现系统可观测性和自动化运维的关键环节。监控系统（如Prometheus）必须能够动态、准确地感知服务实例的变更，才能确保监控覆盖的完整性和数据的新鲜度。虽然许多主流平台和云服务商提供了原生的服务发现机制，但企业内部可能运行着自定义的、基于特定技术栈（如etcd）的服务目录。本文介绍如何构建一个轻量级工具，将基于etcd的自定义服务发现系统与Prometheus集成，从而实现监控目标的自动同步，避免因手动配置监控目标而引入的人为错误和配置滞后。

核心概念

理解本方案需要掌握以下几个核心概念：

etcd: 一个分布式、强一致性的键值存储系统，常用于服务配置、发现和协调。在本例中，它作为服务实例信息的可靠数据源。
文件服务发现 (File-based Service Discovery): Prometheus支持的一种发现机制。它监控一个或多个JSON文件，文件内容定义了以列表形式组织的目标组（Target Groups）。当文件内容变化时，Prometheus会自动重新加载监控目标。
目标组 (Target Group): 一个JSON对象，包含需要被抓取（scrape）的targets（实例地址列表）和关联的labels（标签）。标签会附加到从该目标获取的所有时间序列数据上，例如用于区分不同的job。
Watch 机制: etcd提供的功能，允许客户端监听某个键或目录的变更事件。这比轮询（polling）更高效，能实时响应服务实例的增删改。

本方案的核心思路是：编写一个常驻程序（守护进程），连接到etcd集群，监听特定路径（如/services）下的所有变更。当服务实例发生增、删、改时，程序会将最新的实例信息转换为Prometheus所需的“目标组”JSON格式，并写入到指定文件。Prometheus则通过文件服务发现机制监听该文件，从而自动完成监控目标的更新。

实践

实现一个连接etcd与Prometheus文件服务发现的工具，主要分为以下几个步骤：

1. 定义数据模型与程序入口

程序需要接收etcd服务器地址和输出文件路径作为参数。内部使用map结构来维护当前从etcd同步过来的服务和实例状态。例如，一个名为node_exporter的服务，其实例10.0.33.1:54423会被存储在services["node_exporter"]["10.0.33.1:54423"]中。主函数初始化客户端，首次递归读取/services下的所有子树，完成初始同步。

2. 实现实时监听与状态同步

为了实现实时同步，程序应使用etcd的Watch功能。在一个独立的goroutine中启动递归监听，将所有变更事件（创建、更新、删除）发送到一个通道。主循环从该通道读取事件，并根据事件类型（如update或delete）调用相应的处理函数来更新内存中的服务状态。每次状态变更后，都必须调用持久化方法将最新状态写入文件。

3. 核心方法实现

handle(node, handler): 递归遍历etcd节点树，对每个符合/services/<service_name>/<instance_id>路径格式的节点调用传入的处理函数（update或delete）。
update(node): 解析节点键，将实例地址（node.Value）更新到内存的服务状态中。如果服务不存在，则创建新的服务条目。
delete(node): 解析节点键。如果删除的是实例节点，则从对应服务中移除该实例；如果删除的是整个服务目录节点，则移除该服务的所有实例信息。
persist(): 将内存中的服务状态转换为TargetGroup切片。每个服务对应一个TargetGroup，其targets是该服务所有实例地址的列表，labels中包含job标签（值为服务名）。最后，将这个切片以JSON格式写入配置的输出文件（如tgroups.json）。

4. 部署与配置

运行工具：执行./etcd_sd -target-file /etc/prometheus/tgroups.json，使工具开始监听etcd并维护目标文件。
配置Prometheus：在prometheus.yml中启用文件服务发现，指向工具生成的同一个文件。

scrape_configs:
- job_name: 'default' # job标签将被目标组中的labels覆盖
  file_sd_configs:
  - names: ['/etc/prometheus/tgroups.json']

完成以上步骤后，etcd中服务实例的任何变化都会近乎实时地反映到Prometheus的抓取目标中。

SRE 要点

将此自定义服务发现方案应用于生产环境，需要考虑其对系统可靠性和运维效率的影响。

与可靠性的关联

减少配置漂移：自动化同步消除了人工更新监控配置的步骤，降低了因配置遗漏或错误导致监控盲区的风险，直接提升了监控系统的可靠性。
工具自身的高可用：此同步工具本身成为一个关键的辅助组件。应将其部署为受进程管理器（如systemd）或容器编排平台管理的守护进程，确保崩溃后能自动重启。其故障不应影响已有的监控数据采集，但会暂停目标的自动更新。
etcd依赖性：方案引入了对etcd集群的强依赖。需要确保etcd集群的稳定性和高性能，避免因etcd故障导致服务发现中断。可以考虑为工具添加连接重试和缓存机制。

最佳实践与常见反模式

最佳实践：
- 为工具设计健壮的错误处理和日志记录，便于排查同步问题。
- 在变更管理流程中，将etcd中服务信息的变更视为“基础设施即代码”的一部分。
- 可以考虑结合其他服务发现机制（如consul_sd_configs、kubernetes_sd_configs）作为补充，形成多来源的目标发现策略。
常见反模式：
- 忽略工具的监控：不对该同步工具自身的健康状况（如是否在运行、最近一次同步是否成功、是否有错误日志）进行监控。
- 高频轮询替代Watch：使用定时任务高频读取etcd全量数据并覆盖写入文件，这会对etcd造成不必要的负载，且实时性差。务必使用Watch机制。
- 文件写入原子性不足：直接写入正在被Prometheus读取的文件可能导致读取到不完整的内容。应采用“写入临时文件，然后原子性重命名”的模式。