工作笔记(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:
[</