前言
服务发现(Service Discovery)经常用在微服务治理以及配置管理上,在负载且动态变化的环境下如果没有服务发现就无法可靠的感知服务的新增、变更、删除等。服务发现可以说是基础设施服务的基石之一。
静态配置
项目中部署prometheus的时候,最开始如果需要额外添加一台机器,需要手动更新prometheus的配置文件,再重新启动。对于一组比较少的服务器的测试环境中,这种手动方式添加配置信息是最简单的方法。
当我们使用各类exporter分别对系统、数据库和HTTP服务进行监控指标采集,对于所有监控指标对应的Target的运行状态和资源使用情况,都是用Prometheus的静态配置功能 static_configs 来手动添加主机IP和端口,然后重载服务让Prometheus发现。
对于小型的系统环境,使用 static_configs 指定各 target 即可解决问题,但是在中大型的系统环境或具有较强动态性的云计算环境来说,静态配置有很多弊端。
弊端
但是实际生产环境中,对于成百上千的节点组成的大型集群又或者Kubernetes这样的大型集群,很明显,手动方式捉襟见肘,也带来很大的运维成本。
手动配置的方式不适用于生产环境,考虑被监控的主机、应用的规模以及动态调整的特点,在云环境下,特别是容器环境下,抓取目标地址是经常变动的,所以用静态的方式就不能满足这些场景了。
服务发现
为此,Prometheus设计了一套服务发现功能。Prometheus通过使用"服务发现"来通过自动化的机制来检测、分类和试别新的变更的目标。
对于Prometheus这一类基于Pull模式的监控系统,显然也无法继续使用的static_configs的方式静态的定义监控目标。而对于Prometheus而言其解决方案就是引入一个中间的代理人(服务注册中心),这个代理人掌握着当前所有监控目标的访问信息,Prometheus只需要向这个代理人询问有哪些监控目标控即可, 这种模式被称为服务发现。
优点
通过服务发现的方式,管理员可以在不重启Prometheus服务的情况下动态的发现需要监控的Target实例信息。
动态服务发现能够自动发现集群中的新端点,并加入到配置中,通过服务发现,Prometheus能查询到需要监控的Target列表,然后轮询这些Target获取监控数据。
Prometheus 服务发现能够自动检测分类,并且能够识别新节点和变更节点。也就是说,可以在容器或者云平台中,自动发现并监控节点或更新节点,动态的进行数据采集和处理。
Prometheus 可以集成到多种不同的开源服务发现工具上,以便动态发现需要监控的目标。Prometheus 可以很好的集成到 Kubernetes 平台上,通过其 API Server 动态发现各类被监控的 Pod、Service、Endpoint、Ingress 及 Node 对象,还支持基于文件实现的动态发现。
原理
Prometheus默认是采用pull方式拉取监控数据的,也就是定时去目标主机上抓取metrics数据,每一个抓取的目标需要暴露一个HTTP接口,Prometheus通过这个暴露的接口就可以获取到相应的指标数据,这种方式需要由目标服务决定采集的目标有哪些,通过配置在scrape_configs中的各种job来实现,无法动态感知新服务,如果后面增加了节点或者组件信息,就得手动修改配置文件,并重启Prometheus,很不友好,对于Prometheus这