分布式技术原理与算法解析04-如何搭建一个可靠的监控系统

如何搭建一个可靠的监控系统

监控系统的组成

• 数据收集
• 数据传输
• 数据处理和数据展示

ELK:ELK是Elasticsearch.Logstash,Kibana三个开源软件产品首字母的缩写，他们三个通常配合使用，所以被称为ELK Stack 下图是他的架构

分别的功能如下

• logstash负责数据的收集和传输，他支持动态地从个数据库源收集数据，并对数据进行过滤分析，格式化，然后存储到指定位置。
• elasticsearch负责数据处理，他是一个开源分布式搜索和分析引擎，具有可伸缩性，高可靠和易管理等特点，绝对能对大容量的数据进行处理分析搜索操作，通常被用作基础搜索引擎。
• Kibana：主要用于数据展示
  

Beats

• Packetbeat，用来收集网络流量数据
• Topbeat，用来收集系统，进程的CPU和内存使用情况等数据。
• Filebeat 用来收集文件数据
• Winlogbeat 用来收集Windows事件日志数据

如何搭建一套适合你的服务追踪系统

服务追踪系统的实现：

• 埋点数据收集，负责在服务端进行埋点，来收集服务调用的上下文数据
• 实时数据处理：负责对收集到的链路信息，按照traceId和spaceId进行串联和存储
• 数据链路展示：把处理后的服务调用数据，按照调用链的形式展示出来。

开源服务追踪方案：OpenZipKin

• Collector:负责收集探针Reporter埋点采集的数据，经过验证处理并建立索引。
• Storage：存储服务调用的链路数据，默认使用的是Cassandra是因为Twitter内部大量使用了 Cassandra，也可以替换成elasticsearch或者mysql
• Api: 将格式化和建立索引的链表数据以api的方式提供服务，比如被UI调用
• UI：以图形化的方式展示服务调用的链路数据。

工作原理

具体流程是:

• 通过业务的HTTP Clinet 前后引入服务追踪代码，这样在HTTP 方法“/foo"调用前，生成trace信息，TraceId:aa,SpanId:6b、annotaion:GET/foo,以及当前时刻的timestamp：11*****，然后调用返回结果记录下来耗时duration,之后再把这些trace信息和duration异步上传给Zipkin Collector.

服务节点是否存活

• 经典问题，如果遇到网络问题，大批服务提供者节点汇报给注册中心的心跳信息可能会传达失败，注册中心就会把他们从可用节点列表中移除出去，造成剩下的节点难以调用，可是实际上这些节点是可以调用的，引起雪崩，
• 方法：这个时候可以根据实际业务情况，设定一个阈值比例，即使遇到刚才说的这种情况，注册中心也不能摘除超过这个阈值比例节点。

心跳开关保护机制

• 针对网络抖动的情况，注册中心可能会不断变化，这时候消费者会频繁的接受到服务提供者节点变更的信息。
• 针对这种情况，需要一种保护机制，即使在网络频繁抖动的情况下，服务消费者也不至于同时去请求注册中心获取最新的节点信息。

服务节点摘除保护机制

• 正常情况下，服务提供者在进程启动时，会注册到注册中心，并每隔一段时候汇报心跳到注册中心，以标识自己的存活状态，如果隔了一段时候服务提供者没有汇报心跳给注册中心，注册中心就会认为该节点已经dead状态，从服务的可用节点列表移除出去

• 但是如果遇到网络问题，大批服务提供者节点汇报给注册中心都可能会传达失败，注册中心就会把他们都从可用节点列表移除出去，造成可用节点难以承受所有的调用，引起雪崩，这个时候就需要根据实际业务情况设定一个阈值，即使遇到这种情况注册中心也不能摘除超过这个阈值比例的节点。

静态注册中心

• 因为服务提供者是向服务消费者提供服务的，所以服务可不可以用，服务消费者最清楚，因此可以在服务消费者调用服务提供者是否成功来判断服务提供者是否可用。如果服务消费者调用服务提供者节点失败超过一定次数，可以在本地标记这个节点不可用。并且每隔一段时间，服务消费者向标记不可用的几点发起探测，如果探测成功， 就标记不可用节点为复活状态，重新发起调用。

总结
当遇到网络不稳定的时候，一般会出现以下两个问题：

• 一个是服务消费者同时并发请求注册中心获取最新的服务信息导致注册中心带宽被拉满，另一个就是服务提供者节点大量摘除的情况下，服务消费者没有足够的节点可以调用，导致服务“雪崩”