网络监控平台Shinken

Shinken是一个网络监控平台，可以通过一系列直观的方式监控网络内的各种健康状况。Shinken，单单这个名字接近于日语发音的“新建”，Shinken脱胎于Nagios，其实Shinken这个项目本身就是一帮Nagios项目的人无法忍受Nagios，自己跳出来重新用Python重构了一下——较低的版本甚至完全兼容Nagios的配置文件。

要吐槽的是Litrin在尝试安装的时候用了N个版本，0.x的根本找不到文档；1.x的文档很全，插件兼容性有问题；2.x文档有，插件全，就是明显的有bug。只能自己在github上fork之后提交补丁——好在当天就被采纳了。不过话说这也是开源项目的一个常态，一个项目一旦做到差不多，团队很快就会因为产品定义的不同出现分歧，然后一帮人就fork代码搞个新项目，最终的结果就是“一堆类似功能的项目，多的挑花眼却没有一个是完美的。”

安装前先简单了解下Shinken的架构，相比Shinken借鉴的Nagios，这个明显要复杂很多。

多种角色：不同于传统C/S架构，应该是出于分布式的考虑。Shinken的结构真的有些变态了。

Arbiter(仲裁): Arbiter节点读取本地的配置，然后将配置切分之后分发到多个合适的schedulers节点。
Scheduler(调度): scheduler节点负责分别管理poller和reactionner节点的任务调度。
Poller(轮询): poller节点通过各类插件执行scheduler节点的任务，获取各种健康指标。
Reactionner(响应): reactionner 节点的任务是一旦满足要求将触发event_handlers机制（比如发送通知等）。
Broker(中间人): broker节点的任务真的是中间人——导出和管理scheduler节点中的数据。
Receiver (接收人): 可选节点，在某些特定场景下可以通过reciver节点汇总数据（比如汇总私网内部数据，统一转发）。

除了Arbiter节点之外，任何的节点都可以不是唯一的。节点之间的关系也都是多对多的。
每一个节点都支持/依赖插件，或者说Shinken本身只是一个插件的框架而已。
保障性能和可靠性——根据CAP法则，放弃了一致性。




说了这么多的理论，开始动手吧！ 这次终于使用了Ubuntu1404的Server版。前边也介绍过，N多的版本都不完善，这里只能采用Ubuntu的apt方法来安装。这里为了省去前面的6种节点角色的复杂，只用“主控”和“受控”两种角色粗暴的示范安装过程。

主控端操作

#apt-get install shinken

看看哪些包被安装了

root@ubuntu14:~# dpkg -l | grep shinken
rc shinken 1.4-2 amd64 Flexible monitoring tool - Meta-package
ii shinken-common 1.4-2 amd64 Flexible monitoring tool - Common files
ii shinken-module-broker-webui 1.4-2 amd64 Shinken WebUI broker module
ii shinken-module-broker-webui-cfgpassword 1.4-2 amd64 Shinken cfg_password authentifcation module for WebUI broker
ii shinken-module-broker-webui-sqlitedb 1.4-2 amd64 Shinken Sqlite storage module for WebUI broker
ii shinken-module-retention-picklefile 1.4-2 amd64 Retention module for Arbiter, Scheduler or Broker

安装结束后，正常情况下，在你的/etc/init.d目录下将会有一系列以shinken开头的脚本。这个时候，如果你简单粗暴的server shinken start的话肯定是一堆的报错等着你。好吧，这个问题我找了很久才发现。 编辑/etc/default/shinken，将第34行修改为：

BIN=/usr/lib/python2.7/dist-packages/shinken/bin

这个时候再server shinken start应该会成功。其实shinken start的脚本是启动所有的关联的服务，你可以通过增加或删除/etc/default/shinken 配置中的AVAIL_MODULES选项起到变更角色的目的。 全部OK之后，你可以通过浏览器访问主节点7767端口看到一个Dashboard。不过目前仅仅只是监控本地的健康状况而已。

下面就假定主控节点监控另一台主机nfs的网络连通状况
vi /etc/shinken/hosts/nfs.cfg

define host{
use linux
address 10.239.21.24
host_name nfs
}
define service{
use ssh ; Name of service template to use

host_name nfs
service_description SSH check
retry_interval 1
check_interval 5
max_check_attempts 2
check_command check_ssh
notifications_enabled 0
}

重起shinken之后就会看到一个对NFS主机SSH端口的监控。

如果你只需要拿到远端主机ping状态，TCP端口之类简单的几个指标的话，这种模式已经足够了，可如果需要知道远端主机的进程数量、磁盘空间等数据，那就需要在被控端上做文章。这里就简单的介绍下通过被控端上安装poller的方式实现。

被控端操作

开始都差不多，照贴

#apt-get install shinken

编辑/etc/default/shinken，将第34行修改为：

BIN=/usr/lib/python2.7/dist-packages/shinken/bin

由于被控端只需要一个poller和一个scheduler即可，可以关闭其他服务，修改39行

AVAIL_MODULES="poller scheduler"

启动shinken:

root@ubuntu14:/etc/shinken/hosts# service shinken start
Starting poller:
...done.

启动列表确实短了很多

回到主控端操作

vi /etc/shinken/hosts/test.cfg，添加被控端指标

define host{
use linux
host_name test
address 10.239.21.49 #被控端IP
}

define service{

use local-service ; Name of service template to use
host_name test
service_description PING
check_command check_ping!100.0,20%!500.0,60%
}

define service{
use local-service ; Name of service template to use
host_name test
service_description Root Partition
check_command check_local_disk!20%!10%!/
}
define service{
use                             local-service         ; Name of service template to use
host_name                       test
service_description             Total Processes
check_command                   check_local_procs!250!400!RSZDT
}

vi /etc/shinken/shinken-specific/poller.cfg，追加一个新的poller

define poller {
poller_name     poller-test  #poller名称
address         10.239.21.49 #被控端IP
port            7771         #端口，默认就是7771

## Optional
manage_sub_realms   0   ; Does it take jobs from schedulers of sub-Realms?
min_workers         0   ; Starts with N processes (0 = 1 per CPU)
max_workers         0   ; No more than N processes (0 = 1 per CPU)
processes_by_worker 256 ; Each worker manages N checks
polling_interval    1   ; Get jobs from schedulers each N minutes
timeout             3   ; Ping timeout
data_timeout        120 ; Data send timeout
max_check_attempts  3   ; If ping fails N or more, then the node is dead
check_interval      60  ; Ping node every N seconds

modules
realm   All
}

vi /etc/shinken/shinken-specific/scheduler.cfg，追加一个新的scheduler

define scheduler {
scheduler_name      scheduler-remote ; Just the name
address             10.239.21.46   ; IP or DNS address of the daemon
port                7768        ; TCP port of the daemon
## Optional
spare               0   ; 1 = is a spare, 0 = is not a spare
weight              1   ; Some schedulers can manage more hosts than others
timeout             3   ; Ping timeout
data_timeout        120 ; Data send timeout
max_check_attempts  3   ; If ping fails N or more, then the node is dead
check_interval      60  ; Ping node every N seconds

modules PickleRetention

realm   All

skip_initial_broks  0

satellitemap     poller-remote=10.239.21.46:7771 ; 被控端IP
}

重起主控端shinken服务，配置生效后，你会在webUI的’All’选项中发现新增test主机的各项指标。

需要说明的是，对于很多特定的场景下，需要获得特定主机拿到的指标（比如对于路由状况的指标）。Shinken提供了poller_tag和realm的参数设定。不同的是poller_tag是poller级别的，realm是scheduler级别的。这里就暂时不做详细解释了。而且包括本例中客户机上也可以不启动scheduler。还是强调一下，Shinken是一个弹性相当好的架构！