Skip to content

Commit

Permalink
Merge pull request #44 from riverbuilding/patch-5
Browse files Browse the repository at this point in the history
Update why-need-service-discovery.md
  • Loading branch information
yunlzheng committed Nov 27, 2019
2 parents b6599a5 + 1b5887e commit 6e95548
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion sd/why-need-service-discovery.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

这种按需的资源使用方式对于监控系统而言就意味着没有了一个固定的监控目标,所有的监控对象(基础设施、应用、服务)都在动态的变化。对于Nagias这类基于Push模式传统监控软件就意味着必须在每一个节点上安装相应的Agent程序,并且通过配置指向中心的Nagias服务,受监控的资源与中心监控服务器之间是一个强耦合的关系,要么直接将Agent构建到基础设施镜像当中,要么使用一些自动化配置管理工具(如Ansible、Chef)动态的配置这些节点。当然实际场景下除了基础设施的监控需求以外,我们还需要监控在云上部署的应用,中间件等等各种各样的服务。要搭建起这样一套中心化的监控系统实施成本和难度是显而易见的。

而对于Prometheus这一类基于Pull模式的监控系统,显然也无法继续使用的static_configs的方式静态的定义监控目标。而对于Prometheus而言其解决方案就是引入一个中间的代理人(服务注册中心),这个代理人掌握着当前所有监控目标的访问信息,Prometheus只需要向这个代理人询问有哪些监控目标控即可, 这种模式被称为服务发现。
而对于Prometheus这一类基于Pull模式的监控系统,显然也无法继续使用的static_configs的方式静态的定义监控目标。而对于Prometheus而言其解决方案就是引入一个中间的代理人(服务注册中心),这个代理人掌握着当前所有监控目标的访问信息,Prometheus只需要向这个代理人询问有哪些监控目标即可, 这种模式被称为服务发现。

![基于服务发现与注册中心动态发现监控目标](./static/prometheus-sd.png)

Expand Down

0 comments on commit 6e95548

Please sign in to comment.