一 服务发现适用场景

• Prometheus Server的数据抓取工作基于pull模型，因而，它必须要事先知道各Target的位置，然后才能从相应地exporter或Instrumentation中抓取数据；
  • 对于小型的系统环境来说，通过static_configs指定各Target便能解决问题，这也是最简单的配置方法；
    • 每个Target用一个网络端点（ip:port）进行标识
  • 对于中大型的系统环境或具有较强动态性的云计算环境来说，静态配置显然难以使用；
  • 因此，Prometheus为此专门设计了一组服务发现机制，以便于能够基于服务注册中自动发现、检测、分类可被监控的各Target，以及更新发生了变动的Target；

二 指标抓取生命周期

• 在每个scrape_interval期间，Prometheus都会检测执行的作业（job）；
• 这些作业首先会根据job上指定的发现配置生成target列表，此即服务发现过程；
  • 服务发现会返回一个target列表，其中包含一组称为元数据的标签，这些标签都以“__meta__”为前缀；
  • 服务发现还会根据目标配置来设置其它标签，这些标签带有“__”前缀和后缀，包括“__scheme__”、"__address__"和“__metrics_path__”,分别保存有target支持使用协议（http或https，默认http）、target第地址及指标的URL路径（默认为/metrics）；
  • 若URL路径中存在任何参数，则它们的前缀会设置为"__param__";
  • 这些目标列表和标签会返回给Prometheus，其中的一些标签也可以配置中覆盖；
• 配置标签会在抓取的生命周期中被重复利用以生成其它标签，例如，指标上的instance标签的默认值就来自于__address__标签的值；
• 对于发现的各目标。Prometheus提供了可以重新标记（relabel）目标的机会；
  • 它定义在job配置段的relabel_config配置中，通常用于实现如下功能：
    • 将来自服务发现的元数据标签中的信息附加到指标的标签上；
    • 过滤指标；
• 这之后便是数据抓取、以及指标返回的过程；
• 抓取而来的指标在保存之前，还允许用户对指标从新达标并过滤的方式；
  • 它定义在job配置段的metric_relabel_configs配置中，常用于实现如下功能：
    • 删除不必要的指标；
    • 从指标中删除敏感或不需要的标签；
    • 添加、编辑或修改指标的标签值或标签格式；

三 Prometheus可集成的服务发现机制

• 公有或私有IaaS云自身保存有平台上的所有资源信息，其API Server便可以作为Prometheus的服务发现媒介；
  • azure、ec2、digitalocean、gce；
• Prometheus也可以集成到多种不用的开源服务发现工具上，以动态发信啊需要监控的目标；
  • consul、Eureka Zookeeper Serverse或Airbnb Nerve等；
• Prometheus也可以很好的集成到kubernetes平台上，通过其API Server动态发现各类被监控的Pod、Service、Endpoint、Ingress和Node对象；
  • 它也支持基于docker swarm和marathon两款编排工具进行服务发现；
• Prometheus还支持基于DNS或文件的动态发现机制；