工作笔记(2)—Prometheus服务发现机制

工作笔记(2)—Prometheus服务发现机制

一、场景问题

在云原生、容器化的场景下，按需分配的方式成为主要的资源获取和使用方式。在这种情况下，所有的监控对象（基础设施、应用以及服务等）都在动态的变化。传统的基于Push模式的监控系统失去了一个固定地监控目标，不能很好的实时、准确地上报资源使用情况。

Prometheus是一种典型的基于Pull模式的监控系统框架，其主要通过定义static_configs配置文件，静态地去监控对象。为了解决上述问题，Prometheus引入可服务发现模式。其基本的解决方法就是引入一个服务中心代理，可以存储所有监控对象的访问信息，Prometheus只需要发送请求到服务注册中心就可以获取对应信息。

如上所示，体现Push和Pull的核心差异。相较于Push模式，Pull模式的优点可以简单总结为以下几点：

• 只要Exporter在运行，可以在任何地方（比如在本地），搭建你的监控系统；
• 可以更容易的查看监控目标实例的健康状态，并且可以快速定位故障；
• 更利于构建DevOps文化的团队；
• 松耦合的架构模式更适合于云原生的部署环境。

二、服务发现方式

根据Prometheus的相关代码，总结目前支持的服务发现方式：

// 代码源于prometheus/discovery/config/config.go
type ServiceDiscoveryConfig struct {
   
    StaticConfigs []*targetgroup.Group `yaml:"static_configs,omitempty"`
    DNSSDConfigs []*dns.SDConfig `yaml:"dns_sd_configs,omitempty"`
    FileSDConfigs []*file.SDConfig `yaml:"file_sd_configs,omitempty"`
    ConsulSDConfigs []*consul.SDConfig `yaml:"consul_sd_configs,omitempty"`
    ServersetSDConfigs []*zookeeper.ServersetSDConfig `yaml:"serverset_sd_configs,omitempty"`
    NerveSDConfigs []*zookeeper.NerveSDConfig `yaml:"nerve_sd_configs,omitempty"`
    MarathonSDConfigs []*marathon.SDConfig `yaml:"marathon_sd_configs,omitempty"`
    KubernetesSDConfigs []*kubernetes.SDConfig `yaml:"kubernetes_sd_configs,omitempty"`
    GCESDConfigs []*gce.SDConfig `yaml:"gce_sd_configs,omitempty"`
    EC2SDConfigs []*ec2.SDConfig `yaml:"ec2_sd_configs,omitempty"`
    OpenstackSDConfigs []*openstack.SDConfig `yaml:"openstack_sd_configs,omitempty"`
    AzureSDConfigs []*azure.SDConfig `yaml:"azure_sd_configs,omitempty"`
    TritonSDConfigs []*triton.SDConfig `yaml:"triton_sd_configs,omitempty"`
}

对应的模板如下：

# List of Azure service discovery configurations.
azure_sd_configs:
  [ - <azure_sd_config> ... ]

# List of Consul service discovery configurations.
consul_sd_configs:
  [ - <consul_sd_config> ... ]

# List of DNS service discovery configurations.
dns_sd_configs:
  [</