使用 etcd 进行自定义服务发现
2015 年 8 月 17 日作者 Fabian Reinartz
在 上一篇文章 中,我们介绍了 Prometheus 中许多新的服务发现方式。自那时以来,发生了很多事情。我们改进了内部实现,并收到了社区的精彩贡献,增加了对 Kubernetes 和 Marathon 服务发现的支持。它们将在 0.16 版本发布时提供。
我们还讨论了 自定义服务发现 的主题。
并非所有类型的服务发现都足够通用,可以直接包含在 Prometheus 中。很可能你的组织有一个专有的系统,你只需要让它与 Prometheus 一起工作。这并不意味着你不能享受自动发现新监控目标的益处。
在这篇文章中,我们将实现一个小型实用程序,该程序基于高度一致的分布式键值存储 etcd ,将自定义服务发现方法连接到 Prometheus。
etcd 和 Prometheus 中的目标
我们虚构的服务发现系统在定义的密钥架构下存储服务及其实例。
/services/<service_name>/<instance_id> = <instance_address>
Prometheus 现在应该为所有现有服务自动添加和删除目标,就像它们出现和消失一样。我们可以与 Prometheus 基于文件的服务发现集成,该服务发现监视一组描述目标(作为目标组列表)的文件,格式为 JSON。
一个目标组由与一组标签关联的地址列表组成。这些标签将附加到从这些目标检索到的所有时间序列上。从 etcd 中的服务发现中提取的一个目标组示例可能如下所示:
{
"targets": ["10.0.33.1:54423", "10.0.34.12:32535"],
"labels": {
"job": "node_exporter"
}
}
程序
我们需要一个小型程序,该程序连接到 etcd 集群,查找 /services 路径下的所有服务,并将它们写入目标组文件。
让我们开始一些基础工作。我们的工具提供两个标志:连接到的 etcd 服务器以及写入目标组的文件。在内部,服务表示为从服务名称到实例的映射。实例是从 etcd 路径中的实例标识符到其地址的映射。
const servicesPrefix = "/services"
type (
instances map[string]string
services map[string]instances
)
var (
etcdServer = flag.String("server", "http://127.0.0.1:4001", "etcd server to connect to")
targetFile = flag.String("target-file", "tgroups.json", "the file that contains the target groups")
)
我们的 main 函数解析标志并初始化包含当前服务的对象。然后,我们连接到 etcd 服务器并递归读取 /services 路径。我们将给定路径的子树作为结果接收,并调用 srvs.handle,它为子树中的每个节点递归执行 srvs.update 方法。update 方法修改我们 srvs 对象的状态,使其与 etcd 中子树的状态保持一致。最后,我们调用 srvs.persist,它将 srvs 对象转换为目标组列表,并将它们写入 -target-file 标志指定的文件。
func main() {
flag.Parse()
var (
client = etcd.NewClient([]string{*etcdServer})
srvs = services{}
)
// Retrieve the subtree of the /services path.
res, err := client.Get(servicesPrefix, false, true)
if err != nil {
log.Fatalf("Error on initial retrieval: %s", err)
}
srvs.handle(res.Node, srvs.update)
srvs.persist()
}
假设我们有一个可行的实现。我们现在可以每 30 秒运行一次此工具,以获得当前服务发现中目标的大致准确视图。
但是我们能做得更好吗?
答案是是的。etcd 提供 watches,允许我们监听任何路径及其子路径的更新。有了它,我们就能立即获知更改并立即应用它们。我们也不必一遍又一遍地处理整个 /services 子树,这对于大量的服务和实例来说可能很重要。
我们将 main 函数扩展如下:
func main() {
// ...
updates := make(chan *etcd.Response)
// Start recursively watching for updates.
go func() {
_, err := client.Watch(servicesPrefix, 0, true, updates, nil)
if err != nil {
log.Errorln(err)
}
}()
// Apply updates sent on the channel.
for res := range updates {
log.Infoln(res.Action, res.Node.Key, res.Node.Value)
handler := srvs.update
if res.Action == "delete" {
handler = srvs.delete
}
srvs.handle(res.Node, handler)
srvs.persist()
}
}
我们启动一个 goroutine,该 goroutine 递归监视 /services 中条目的更改。它永远阻塞,并将所有更改发送到 updates 通道。然后,我们从通道读取更新并像以前一样应用它。但是,如果实例或整个服务消失,我们会使用 srvs.delete 方法调用 srvs.handle。
我们在每次更新结束时再次调用 srvs.persist,将更改写入 Prometheus 正在监视的文件。
修改方法
到目前为止,这在概念上是可行的。剩下的就是 update 和 delete 处理程序方法以及 persist 方法。
update 和 delete 由 handle 方法调用,该方法会为子树中的每个节点调用它们,前提是路径有效。
var pathPat = regexp.MustCompile(`/services/([^/]+)(?:/(\d+))?`)
func (srvs services) handle(node *etcd.Node, handler func(*etcd.Node)) {
if pathPat.MatchString(node.Key) {
handler(node)
} else {
log.Warnf("unhandled key %q", node.Key)
}
if node.Dir {
for _, n := range node.Nodes {
srvs.handle(n, handler)
}
}
}
update
update 方法根据 etcd 中更新的节点修改我们 services 对象的状态。
func (srvs services) update(node *etcd.Node) {
match := pathPat.FindStringSubmatch(node.Key)
// Creating a new job directory does not require any action.
if match[2] == "" {
return
}
srv := match[1]
instanceID := match[2]
// We received an update for an instance.
insts, ok := srvs[srv]
if !ok {
insts = instances{}
srvs[srv] = insts
}
insts[instanceID] = node.Value
}
delete
delete 方法根据从 etcd 删除的节点,从我们 services 对象中删除实例或整个作业。
func (srvs services) delete(node *etcd.Node) {
match := pathPat.FindStringSubmatch(node.Key)
srv := match[1]
instanceID := match[2]
// Deletion of an entire service.
if instanceID == "" {
delete(srvs, srv)
return
}
// Delete a single instance from the service.
delete(srvs[srv], instanceID)
}
persist
persist 方法将我们 services 对象的状态转换为 TargetGroups 列表。然后,它将此列表以 JSON 格式写入 -target-file。
type TargetGroup struct {
Targets []string `json:"targets,omitempty"`
Labels map[string]string `json:"labels,omitempty"`
}
func (srvs services) persist() {
var tgroups []*TargetGroup
// Write files for current services.
for job, instances := range srvs {
var targets []string
for _, addr := range instances {
targets = append(targets, addr)
}
tgroups = append(tgroups, &TargetGroup{
Targets: targets,
Labels: map[string]string{"job": job},
})
}
content, err := json.Marshal(tgroups)
if err != nil {
log.Errorln(err)
return
}
f, err := create(*targetFile)
if err != nil {
log.Errorln(err)
return
}
defer f.Close()
if _, err := f.Write(content); err != nil {
log.Errorln(err)
}
}
上线
一切就绪,我们如何运行它?
我们只需使用配置好的输出文件启动我们的工具:
./etcd_sd -target-file /etc/prometheus/tgroups.json
然后,我们使用相同的文件配置 Prometheus 进行基于文件的服务发现。最简单的配置如下所示:
scrape_configs:
- job_name: 'default' # Will be overwritten by job label of target groups.
file_sd_configs:
- names: ['/etc/prometheus/tgroups.json']
就这样。现在,我们的 Prometheus 与服务及其通过 etcd 进入和离开我们服务发现的实例保持同步。
结论
如果 Prometheus 不直接支持你组织的某种服务发现,不要绝望。使用一个小实用程序,你可以轻松地弥合差距,并从监控目标的无缝更新中获益。这样,你就可以从部署方程式中移除对监控配置的更改。
非常感谢我们的贡献者 Jimmy Dyson 和 Robert Jacob 添加了对 Kubernetes 和 Marathon 的本地支持。另请查看 Keegan C Smith 关于基于文件的 EC2 服务发现 的看法。
你可以在 GitHub 上找到 这篇博文的完整源代码 。