From 1b5887e02cd6e8ed6727f12b7abc95ebb928095e Mon Sep 17 00:00:00 2001 From: riverbuilding Date: Tue, 8 Oct 2019 10:09:46 -0400 Subject: [PATCH] Update why-need-service-discovery.md --- sd/why-need-service-discovery.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sd/why-need-service-discovery.md b/sd/why-need-service-discovery.md index 24fd7b1..70481e3 100644 --- a/sd/why-need-service-discovery.md +++ b/sd/why-need-service-discovery.md @@ -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) @@ -17,4 +17,4 @@ * 只要Exporter在运行，你可以在任何地方（比如在本地），搭建你的监控系统； * 你可以更容易的查看监控目标实例的健康状态，并且可以快速定位故障； * 更利于构建DevOps文化的团队； -* 松耦合的架构模式更适合于云原生的部署环境。 \ No newline at end of file +* 松耦合的架构模式更适合于云原生的部署环境。