Smokeping线上配置搭建笔记

通常情况下，smokeping主机和被监控的主机之间都会存在网络延迟和丢包情况。因此现在比较热火的分布式，多节点监控架构似乎迫在眉睫，而smokeping完全支持master/slave多节点监控 smokeping的主从结构，默认是开启master和slave所有的检测指针去检测远程主机(当然这个选项也是有个参数可以控制，只让slave去检测远程主机)。一个master可以管理多个slave，而且slave配置起来也很简单 slave从master上获取自己的配置信息，所有的检测数据以及web呈现都在master上，slave只负责按照从master获取的配置信息进行数据检测，所以说master/slave的架构也只需要维护好master的配置文件即可，其他的信息slave都会动态获取到。Smoking 检测分布式的检测方式是被动模式，由从节点启动时获得主节点的config 文件，然后进行数据检测收集，收集完毕后直接将数据提交给主节点。主从通信验证是通过类似于rsync的密码认证方式，在启动slave节点时指定--shared-secret=filename 来和主进行密码验证 架构：slave通过master的web接口与master保持正常的通信，slave在初始化启动连接到master的时候，master会告诉slave的作业内容，当slave完成了一轮作业内容时便会将结果返回给master，如果分配给slave的任务发生了改变，master会告诉slave，其他slave已经交付的结果 其实一个slave就是一个单独的实例，slave的配置信息来自于master,不是来自于本地配置文件(这样就减少了大量的维护成本)，slave在完成每一轮的作业任务后，就会尝试连接master提交自己的结果。如果无法连接到master，这个结果将会和下一轮的结果一块发送给master，master收到结果后，将检测的数据存储在一个以perl的可存储形式的文件中，以便于重启了smokeping实例后，不会丢失这些数据。

从官方获取的master,slave的架构图的流向可以看出，slave均是从master上获取配置信息，并将结构汇集给master.

   [slave 1]     [slave 2]      [slave 3]
        |             |              |
        +-------+     |     +--------+
                |     |     |
                v     v     v
              +---------------+
              |    master     |
              +---------------+