【问题标题】:Prometheus dns service discovery in docker swarm relabel instancedocker swarm relabel 实例中的 Prometheus dns 服务发现
【发布时间】:2018-06-29 08:46:35
【问题描述】:

我的问题是对Prometheus dns service discovery in docker swarm 的补充。

我定义prometheus抓取目标如下:

- job_name: 'node-exporter'
  dns_sd_configs:
  - names:
    - 'tasks.nodeexporter'
    type: 'A'
    port: 9100

这可以正常工作,但会导致 prometheus 使用 docker 容器的 IP 作为实例标签。

我尝试重新标记实例标签,如下所示:

relabel_configs:
- source_labels: [__meta_dns_name]
  target_label: instance

但是这样做会导致节点导出器的所有实例都具有相同的标签“tasks.nodeexporter”。

是否有可能将实例标签重新标记为诸如 tasks.nodexporter_1、tasks.nodeexporter_2、...之类的东西?

【问题讨论】:

    标签: docker docker-swarm prometheus service-discovery


    【解决方案1】:

    Prometheus 不支持 docker swarm 设置的服务发现,因为 swarm 端缺少许多功能。

    dns 服务发现是减轻这些缺失功能的一种方法,但我认为这不是一个好的解决方案,我建议不要在生产中使用它:

    • 无法提供其他信息,例如使用 SRV 记录
    • 没有关于应该运行多少个实例的信息
    • 由于 dns 仅列出健康的任务,当一项任务不再被认为是健康的时,抓取目标的数量会减少,这使得对行为不端的容器发出警报会变得更加困难
    • 当容器死亡并重新启动时,您将观察到新实例,因为没有可用的任务槽等信息

    总而言之,这些问题不允许这种方法成为监控系统的可靠来源。

    如果你真的很喜欢使用 docker swarm,你应该考虑通过以编程方式查询 docker api 并使用 Prometheus 的 file_sd 服务发现机制来构建一个更可持续的解决方案。请参阅容器解决方案的此 poc 以供参考:https://github.com/ContainerSolutions/prometheus-swarm-discovery

    【讨论】:

    • 感谢您的提示。我会看看它并考虑一下。现在这听起来像是更好的方法,甚至解决了我的问题,因为 docker 任务名称已经包含在标签中。在我尝试实施后,这个答案将被接受。
    猜你喜欢
    • 2018-07-07
    • 1970-01-01
    • 1970-01-01
    • 2021-02-20
    • 1970-01-01
    • 2020-04-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多