运维自动化重点解读之监控系统（三）：架构(1)
2016-02-20 19:33:33   来源： Reboot运维开发 51CTO博客    评论：0 点击：

几个开源监控系统的PUSH、PULL选择

zabbix：带agent方式。agent主动推送数据到服务端。 从client的角度看，是PUSH数据到Server。

Cacti：SNMP协议，无Client，或者说Client是SNMP Client。从Client角度看，是PULL。

ganglia：从Client角度看，是PUSH。

在我过去生产环境所构造的监控系统里面，我们采用了PUSH和PULL结合的方式来达到及时性、到达率的同时解决。我们站在Client的角度来描述这个解决方案。对于监控项的生效，Web端变更之后立即使用PUSH的方式来通知Client。但这里一定有达到率的问题。比如Client所在服务器死机了、重启了、当时网络有问题不可达等等。所以我们在Client端，支持定时PULL。定时去主动联系Server端，获取自己应该生效的监控内容。

HASH

怎么突然又说到HASH了呢?HASH先来个概念普及吧!看完概念还是不了解的同学，自行面壁去，你计算机数据结构一定没好好学。

我说HASH是因为要为后面介绍高可用性架构有关系的。

HASH你别直接拿去搜，用百度的结果就是哈士奇。

关键词可以是哈希。

Hash，一般翻译做“散列”，也有直接音译为“哈希”的，就是把任意长度的输入(又叫做预映射， pre-image)，通过散列算法，变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，所以不可能从散列值来唯一的确定输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。

Hash在算法里面是很基础但使用非常广泛的。特别是在大数据量的情况下。

我这里强调Hash，是想说它的一个作用之一就是散列。把输入散列到几个地方去。提到Hash不得不提一个词叫做一致性Hash，这个算法对于解决缓存命中率有很大好处。在内存缓存、CDN等存储系统中经常使用。

Hash的精髓之一就是按照某种计算规则，把输入散列到不同的输出通道上去。

无状态和有状态

我们拿无状态协议来体验一下无状态是个什么概念。

协议的状态是指下一次传输可以“记住”这次传输信息的能力。典型的如HTTP协议是不会为了下一次连接而维护这次连接所传输的信息，由于Web服务器要面对很多浏览器的并发访问，为了提高Web服务器对并发访问的处理能力，在设计HTTP协议时规定Web服务器发送HTTP应答报文和文档时，不保存发出请求的Web浏览器进程的任何状态信息。这有可能出现一个浏览器在短短几秒之内两次访问同一对象时，服务器进程不会因为已经给它发过应答报文而不接受第二期服务请求。由于Web服务器不保存发送请求的Web浏览器进程的任何信息，因此HTTP协议属于无状态协议(Stateless Protocol)。

监控系统里面的HASH和状态

监控系统对数据的处理，主要是过滤异常数据出来并报警。比如某个服务器的CPU利用率超过了95%，需要报警。但这个时候突然数据处理模块所在服务器宕机了。那么，这个异常数据很有可能就丢掉了。

监控系统常见的报警条件是： CPU利用率超过95%，算一次异常。如果5分钟内有3次异常，报警给运维。

这里就有几个数字需要处理，5分钟，3次。前面提到的宕机，会导致一次异常数据丢掉了。假设5分钟内出现了3次，丢掉了一次，那自然不会报警出来。这就是一个有状态的场景。

有状态的情况下，做自动切换或者负载均衡，需要把状态也带过去才行。

比较典型的还有session的问题。如果web是多台主机负载均衡的时候，session存本地是会出问题的。因为用户有可能通过负载均衡的调度，多次请求落在不同的主机上。 本来HTTP协议是无状态的，支持负载均衡的调度。但因为session这个有状态的产物，必须要把session放在公共存储上才行。

结合前面提到的那个架构图。数据进入到了数据计算和报警模块。我们如何保证这个数据计算和报警模块是个高可用的架构。

答案是，把输入的监控数据Hash到不同的数据计算和报警模块实例上去，并且最好是无状态或者弱状态的计算过程。（未完待续）

【编辑推荐】