Shinken是一个开源的IT监控框架，基于Python编写。Shinken从2009年开始发布，起初是作为一个简单的监控解决方案，由于越来越多的模块的加入，至2014年它被重新定位为“框架”。

Shinken的优势包括：

1. 跨平台，它可以在Windows、Linux上部署和运行
2. 独立性，不依赖于其它监控解决方案
3. 可扩容，能够很好的支持不断扩张的、大规模的监控需求

守护程序角色

# 如果机器上没有安装pip
apt-get install python-pip python-pycurl
# 添加shiken专用户
adduser shinken
# 安装shinken
pip install shinken

使用这种方式，你可以方便的调试或者修改Shinken的源码：

adduser shinken
wget http://www.shinken-monitoring.org/pub/shinken-2.4.tar.gz
tar -xvzf shinken-2.4.tar.gz
cd shinken-2.4
python setup.py install

在生产环境下可以设置Shinken为自启动：

# RedHat / CentOS
chkconfig shinken on
# Debian / Ubuntu
update-rc.d shinken defaults

# 启动
service shinken start

你可以可以通过脚本启动：

./bin/launch_all.sh

开发环境下，如果你需要修改Shinken源码，需使用第二种安装方式。然后注释掉shinken.cfg中用户、组信息，以当前用户的身份启动Shinken：

./bin/shinken-scheduler -c /etc/shinken/daemons/schedulerd.ini -d
./bin/shinken-poller -c /etc/shinken/daemons/pollerd.ini -d
./bin/shinken-broker -c /etc/shinken/daemons/brokerd.ini -d
./bin/shinken-reactionner -c /etc/shinken/daemons/reactionnerd.ini -d
./bin/shinken-arbiter -c /etc/shinken/shinken.cfg -d
./bin/shinken-receiver -c /etc/shinken/daemons/receiverd.ini -d

安装后以及运行时，Shinken会使用下面的目录：

安装步骤参考Linux下基于源码的安装方式，不需要添加用户，解压可以手工进行。

Windows下所有目录都位于Shinken安装目录下，例如

/etc/shinken

Windows下%SHINKEN_HOME%\etc

每次修改配置后，你都应该在重启Shinken之前进行验证，因为配置存在问题会导致Shinken无法启动。

调用下面的命令执行验证：

/usr/bin/shinken-arbiter -v -c /etc/shinken/shinken.cfg 

如果配置存在错误，该命令会输出ERROR信息并指出问题所在位置。警告信息一般可以忽略。

# 启动
/etc/rc.d/init.d/shinken start
# 重启
/etc/rc.d/init.d/shinken restart
# 停止
/etc/rc.d/init.d/shinken stop

Shinken提供了一个同名的命令，可以用于在shinken.io上检索、安装，上传包（Pack，包含对象定义模板）或者模块（扩充Shinken功能的Python模块）。初次使用该命令，需要初始化：

# 首次使用shinken命令时执行
shinken --init

http://user:password@proxy-server:port

在安装完毕后，你就获得一个基本的Shinken配置，可以直接启动之。

/etc/shinken/daemons目录存放了*.ini文件，这些文件描述了在本机需要运行的守护程序。基本配置下Shinken单机运行，因而此目录下有5个文件（Arbiter的配置在主配置文件中）。分别定义Broker、Poller、Reactionner、Receiver、Scheduler这五个守护程序使用的端口、工作目录等重要信息。

需要注意的是，这些守护程序不一定要在单机上运行，你可以分散部署，只需要将它们作为对象引用到主配置文件中。

我们看一下配置文件的内容：

[daemon]

# 该程序启动后，立即修改工作目录为：
workdir = /var/run/shinken
logdir  = /var/log/shinken
# PID文件，有了它以后我们可以杀死该守护程序
pidfile=%(workdir)s/schedulerd.pid
# TCP监听端口，默认：
# scheduler: 7768
# poller: 7771
# reactionner: 7769
# broker: 7772
# arbiter: 7770
port=7768
# TCP监听地址
host=0.0.0.0
# 用于运行守护程序的用户，以及用户的组
user=shinken
group=shinken
# 如果设置为1，则你可以在root用户下运行此守护程序
idontcareaboutsecurity=0

# Set to 0 if you want to make this daemon NOT run
# 是否启用此守护程序，如果设置为0则不会运行
daemon_enabled=1


#-- SSL相关的配置 --
use_ssl=0
# WARNING : Use full paths for certs
#ca_cert=/etc/shinken/certs/ca.pem
#server_cert=/etc/shinken/certs/server.cert
#server_key=/etc/shinken/certs/server.key
hard_ssl_name_check=0
http_backend=auto
daemon_thread_pool_size=16

#-- 和该守护程序相关的本地日志配置 --
# Enabled by default to ease troubleshooting
use_local_log=1
local_log=%(logdir)s/schedulerd.log

# accepted log level values= DEBUG,INFO,WARNING,ERROR,CRITICAL
log_level=WARNING

# The path to the modules directory
modules_dir=/var/lib/shinken/modules

守护程序作为Shinken架构中的一种资源，必须在主配置文件中进行定义，才能被使用。 

通常，守护程序定义文件依据类型的不同，存放在不同目录中，并且每个文件对应一个守护程序。该文件使用类似于对象定义的语法，描述此守护程序的名称、如何连接、是否Standby（Spare）。下面是一个Scheduler定义的例子：

define scheduler {
    # 守护程序的名称
    scheduler_name      scheduler-master
    # 如何连接到此守护程序
    address             localhost 
    port                7768
    # 是否备用
    spare               0
    # 权重，某些Scheduler可以管理更多的主机
    weight              1
    # PING超时
    timeout             3
    # 数据发送超时
    data_timeout        120 
    # 如果PING超时多少次，认为此节点挂掉
    max_check_attempts  3
    # 每60秒PING此节点
    check_interval      60
    # 此守护程序加载的模块
    modules
    # 所属的领域，用于多数据中心等大型场景
    realm   All
    skip_initial_broks  0
    use_ssl	          0
    hard_ssl_name_check   0
}

注意，某些守护程序有特殊的配置选项，例如：

所有守护程序都可以使用模块。对于Broker来说模块是必须的，它依赖模块来完成实际的工作。基本配置没有预定义任何模块。

模块具有公共的选项：

每个模块具有自己的其它特殊配置项，需要查看模块的文档。

这里，我们定义一个模块，为基本配置增加日志记录的功能：

define module{
     module_name      simple-log
     module_type      simple-log
     path             /var/log/shinken/shinken.log
}

然后修改默认的Broker：

modules            simple-log

默认情况下simple-log模块是没有安装的，因此你会在/var/log/shinken/brokerd.log中发现警告信息：The module type simple-log for simple-log was not found in modules。执行下面的命令来安装模块：

# 到shinken.io搜索包
shinken search log
# 安装模块到/var/lib/shinken/modules/目录下
shinken install simple-log

重启Shinken，你会发现所有守护程序的日志被收集到 /var/log/shinken/shinken.log文件中了。

Shinken包含一系列内部模块，这些模块可以被多种守护程序加载，参与到数据获取中去。这些模块包括NPRE、SNMP等。

Shinken同时依赖于外部程序——检查插件（Check plugins）来监控更多种类的设备、应用、以及网络服务。

插件可以是编译好的可执行文件或者脚本，它们可以被调用，以便检查主机/服务的状态。Shinken使用插件的调用返回值来确定主机、服务的当前状态，以及被监控服务的性能数据。

插件作为监控逻辑组件和被监控主机/服务之间的抽象层。具有一定的接口规范，你可以编写自己的插件来监控任何东西。

Shinken插件有很多，支持的监控协议包括：WMI, SNMP, SSH, NRPE, TCP, UDP, ICMP, OPC, LDAP 等。

支持的监控对象包括各种OS、服务器和网络硬件、各种网络协议、各种性能数据、应用程序和数据库。

插件没有和Shinken运行时一同分发，需要单独获取。可以从：

1. Monitoring Plugins Project
2. Nagios Downloads Page
3. NagiosExchange.org

等地方获取插件。很多插件都提供帮助，你应该通过阅读帮助来了解如何使用之：

./check_http --help

Shinken的灵活性依赖于宏机制，你可以在命令中使用宏。通过宏你可以引用主机、服务等信息。

Shinken宏使用

$

$$

在执行命令前，Shinken会替换命令定义中所有宏为实际值，这些值由上下文决定。宏替换发生在任何命令上，包括主机/服务检查、通知、事件处理器等。

你可以使用

$ARGn$

# 定义命令
define command{
  command_name    check_ping
  # ARG1表示第一个入参
  command_line    /var/lib/shinken/libexec/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
}

调用命令时，以

!

define service{
  host_name    linux
  # 调用命令。给check_ping命令传递了两个参数，每个参数以叹号开始
  # 200.0,80%
  # 400.0,40%
  check_command    check_ping!200.0,80%!400.0,40%
}

如果调用命令需要传递叹号（!）本身，可以使用反斜杠转义。 

通常，当你使用主机/服务宏时，这些宏指向当前命令所针对的主机/服务。如果你想引用其它主机/服务时，可以使用按需宏机制。

按需宏和普通宏类似，只是它后缀一个用于识别主机/服务的标识符：

# 语法格式。把HOSTMACRONAME、SERVICEMACRONAME替换成真实的宏名称，:后面替换成真实的属性值即可
$HOSTMACRONAME:host_name$
$SERVICEMACRONAME:host_name:service_description$

# 举例
$HOSTDOWNTIME:myhost$   #myhosq的宕机时间
$SERVICESTATEID:server:database$  #server的database服务的状态ID
$CONTACTEMAIL:john$   #john的电子邮件

你还可以使用宏来获得一个组中的全部联系人、主机、服务的属性，使用特定分隔符分隔多个值：

#语法格式。HOSTMACRONAME等替换成真实的宏名称，*group_name替换为真实的组名称，delimiter替换为分隔符即可
$HOSTMACRONAME:hostgroup_name:delimiter$
$SERVICEMACRONAME:servicegroup_name:delimiter$
$CONTACTMACRONAME:contactgroup_name:delimiter$

你在主机、服务、联系人等的定义中声明的定制对象变量（custom object variables） 均可以作为宏使用：

#语法格式。
$_HOSTvarname$
$_SERVICEvarname$
$_CONTACTvarname$

#举例：
define host{
  ...
  # 定制变量必须以_开头
  _MACADDRESS    00:01:02:03:04:05
  ...
}
# 你可以使用 $_HOSTMACADDRESS$ 来访问MAC地址这一定制变量

大部分宏被导出为环境变量，脚本或者命令可以很容易的引用之。

$USERn$

参考官方文档。

以下时机Shinken的守护程序对主机执行检查：

1. 根据主机的check_interval、retry_interval选项周期性、定时检查。如果check_interval设置为0则不进行周期性检查
2. 当主机下某个服务的状态改变，按需检查
3. 作为主机可到达性逻辑的一部分，按需检查。这种情况下，主机是路由器等网络设备
4. 在进行预测性主机依赖性检查（predictive host dependency checks）时，按需进行

主机检查是并行执行的。

按需检查的性能可以通过已缓存的主机检查（Cached Host Checks）极大的提高。Shinken可以放弃检查执行，而使用最近的检查结果。

通过定义主机执行依赖（host execution dependencies），你可以基于其它一个或多个主机的状态，禁止某一主机的检查。

被检查的主机可以处于三种状态之一：UP、DOWN、UNREACHABLE。

主机检查由插件进行，插件的返回状态和主机状态映射如下表。注意，依据插件结果初步判定为DOWN时，需要依赖于父主机状态，来确定主机的真实（最终）状态：

Shinken可能发现主机状态在UP/DOWN/UNREACHABLE之间变化，并采取一定的操作。

状态变革会导致不同的状态类型（State types）：HARD/SOFT，可能相应的触发事件处理器或者通知。

当主机状态频繁变化时，称为动荡（flapping），动荡的一个例子是，主机由于某种原因反复的重启（例如系统更新导致）。Shinken可以在检测到动荡后暂停通知发送，直到主机状态稳定下来。 

以下时机Shinken的守护程序对服务执行检查：

1. 根据服务的check_interval、retry_interval选项周期性、定时检查
2. 在进行预测性服务依赖性检查（predictive service dependency checks）时，按需进行

与主机检查一样：

1. 缓存可以很大的提高On-demand服务检查的性能
2. 检查是并行执行的
3. 通过定义服务执行依赖（service execution dependencies），你可以基于其它一个或多个服务的状态，禁止某一服务的检查

被检查的服务可以处于几种状态之一：OK、WARNING、UNKNOWN、CRITICAL。

服务检查由插件执行，插件的返回状态直接对应到上面几个服务状态。

服务的状态变更、动荡的处理和主机类似。

主动检查是Shinken主要使用的检查方式。主动检查由Shinken发起，依据计划周期性的执行。具体步骤如下：

1. 周期性、On-demand触发检查
2. 守护程序调用插件，并传递必要信息
3. 插件执行实际的坚持并报告结果给守护程序
4. 守护程序处理结果，执行适当的操作，例如发送通知、执行事件处理器

集成的数据获取模块，是可以被守护程序启动的组件。这些组件可以高性能的获取数据，效率比周期性的调用插件脚本高。

SNMP数据获取模块：SnmpBooster

NRPE数据获取模块：NRPE

NRPE是一种通信协议，它和安装在远程主机上的代理（Agent）进行交互。

Shinken也支持被动的得到对象的状态。被动检查由外部程序发起，并将检查结果提交给Shinken。

对于天生异步的、不能通过轮询（Polling）很好的检查的服务，被动检查很适用。适合被动检查的例子包括：

1. SNMP陷阱、安全报警。你永远不知道一定时间内有多少陷阱、报警
2. 安装了代理（Agent）的主机上的聚合检查，这种检查的执行间隔会相当低
3. 直接从英语程序中提交检查结果，不依赖于中介日志文件（syslog、event log等）

在主配置文件中设置accept_passive_service_checks为1。对于不需要主动检查的主机、服务，设置passive_checks_enabled为0。

外部程序可以向Shinken的外部命令管道（external command pipe）写入一条PROCESS_SERVICE_CHECK_RESULT外部命令，以提交检查结果。该命令的格式为：

# timestamp，格式为time_t即1970到现在的秒数。执行服务检查的时间点
# host_name，服务所属主机的短名
# svc_description，服务定义中的服务描述
# return_code，检查结果，0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN
# plugin_output，插件的文本输出
[timestamp] PROCESS_SERVICE_CHECK_RESULT;configobjects/host_name;svc_description;return_code;plugin_output

被检查的服务必须在Shinken中预先定义，否则提交的检查结果自动丢弃。

外部程序可以向Shinken的外部命令管道（external command pipe）写入一条PROCESS_HOST_CHECK_RESULT外部命令，以提交检查结果。该命令的格式为：

# host_status，主机状态 0=UP, 1=DOWN, 2=UNREACHABLE
[timestamp] PROCESS_HOST_CHECK_RESULT;configobjects/host_name;configobjects/host_status;plugin_output

与主动检查不同，Shinken不会把结果作为初步结果，进而根据父主机状态判断最终结果。你提交的必须就是主机的实际状态。 

被监控主机/服务的当前状态（Current state）由两个字段决定：

1. 主机或服务的状态（status，先前所有提及的状态，都是这个单词），即OK, WARNING, UP, DOWN...
2. 主机或服务所处的状态类型（State type）

状态类型有两种：软状态（SOFT）、硬状态（HARD）。状态类型非常重要，它们用于决定何时执行事件处理器，何时发送最初的通知。

为了防止因为临时故障而错误的报警，Shinken允许配置主机/服务的max_check_attempts。最有在最大尝试次数到达后，才会认为是真正出现问题。

重新检查与状态类型密切相关

以下情况下，服务/主机处于软状态：

1. 当服务/主机从OK/UP变为non-OK/non-UP状态后，到达max_check_attempts之前。这种情况称为软错误
2. 当服务/主机从软错误中恢复时。这种情况称为软恢复

当对象进入软状态时：

1. 日志记录SOFT状态，仅当你在主配置文件启用log_service_retries或log_host_retries时
2. 调用事件处理器来处理SOFT状态。这是软状态下重要的行为，你可以在到达HARD状态前积极的修复问题。事件处理器执行时， $HOSTSTATETYPE$、 $SERVICESTATETYPE$宏的值为SOFT提示当前处于软状态

以下情况下，服务/主机处于硬状态：

1. 服务/主机从OK/UP变为non-OK/non-UP状态后，到达max_check_attempts之后仍然没有恢复。这种情况称为硬错误
2. 当服务/主机从硬错误转换到其它错误状态时，例如WARNING、CRITICAL
3. 当服务的检查结果是一个non-OK状态且它所属主机为DOWN或UNREACHABLE状态
4. 当服务/主机从硬错误状态恢复。这种情况称为硬恢复
5. 当被动检查结果送达，默认总是认为是硬状态。除非启用passive_host_checks_are_soft选项

当对象进入硬状态时：

1. 日志记录HARD状态
2. 调用事件处理器来处理HARD状态
3. 通知联系人，告知问题或者恢复。事件处理器执行时， $HOSTSTATETYPE$、 $SERVICESTATETYPE$宏的值为HARD提示当前处于硬状态

我们常说“外网挂了”，外网真的会挂吗？几乎不可能，问题肯定出现在你的机器到Internet的链路上。链路上的任何一个路由器/交换机出现故障，你都会无法上网。

在Shinken的监控业务中也是这样，守护程序所在机器到目标主机之间的链路上任何一个节点出现故障，目标主机都会处于non-UP状态。Shinken有能力区分这个non-Up是DOWN还是UNREACHABLE，前提是你正确的配置网络依赖。

你必须站在Shinken守护程序的角度来看问题，守护程序需要经过哪些主机（网络设备）才能到到目标主机？你需要把这些中介的设备配置为目标主机的祖先主机，例如：

# 父子关系的配置必须真实的反映网络拓扑
define host{
  host_name    Switch1
  parents    Shinken  #声明自己的父主机，父主机总是离Shinken守护程序更近（跳数少）
}
define host{
  host_name    Web
  parents    Switch1
}
define host{
  host_name    FTP
  parents    Switch1
}
define host{
  host_name    Router1
  parents    Switch1
}
define host{
  host_name    somewebsite.com
  parents    Router1
}

类似上面的配置，形成从守护程序到目标主机的单向图，Shinken依据此图判断目标主机是不可达，还是宕机。 

某些情况下你可能有多重链路可以到达目标主机，此时应该为目标主机（或者链路上的中介节点）配置多个父主机。

只有全部父主机不可达、宕机，子主机才会被判定为不可达。

Shinken只会针对问题的根源（Root problems）发送通知，这避免了发送大量的通知给联系人。只有主机状态是DOWN时通知才会发送，主机是UNREACHABLE时不会发送，但是它的某个祖先主机的DOWN通知可能被发送。

同样的，DOWN/UNREACHABLE主机上服务的通知也不会发送，它们不是问题的根源所在。

服务和主机（逻辑）依赖是Shinken的高级特性。允许你基于其它主机/服务的状态，来控制目标主机/服务的行为。

以服务依赖为例，一个Web服务常常会依赖于一个数据库服务。如果数据库服务宕机了，你向联系人通知说Web服务挂了是没有意义的。你应该正确配置服务之间的依赖关系，以便Shinken能够报告问题的根源。

关于服务依赖，你需要知道：

1. 一个服务可以依赖于1-N个其它服务
2. 一个服务可以依赖于其它主机上的服务
3. 通过服务依赖配置，你可以在服务的某些状态下，抑制检查的执行、通知的发送
4. 依赖关系可以仅在特定时间段内启用

# 位于srv-web上的service服务
define service{
  host_name              srv-web
  service_description    Http
  # 依赖位于srv-db上的mysql服务
  service_dependencies   srv-db,mysql
}

依赖是可以继承（inherited，应该理解为传递性依赖）。以上面的例子讲，假设mysql服务依赖srv-dns,dns，那么http出现问题时会检查mysql，进一步会检查srv-dns以确认问题根源。

网络依赖同样会影响问题根源的判断，如果http出现问题的同时发现srv-db宕机，那么后者会被看作问题的根源，前者只作为后者的impact。

Shinken允许在返回状态数据的同时，附带记录可选的性能数据。你可以把性能数据返回给外部程序进行处理。

性能数据分为两个类别：

Shinken插件至少会返回一行人类可读的文本，用来描述某种类型的可度量数据，例如check_ping插件返回的文本可以如下：

PING ok - Packet loss = 0%, RTA = 0.80 ms

类似这样的输出，可以通过

$HOSTOUTPUT$

$SERVICEOUTPUT$

可选的，插件还可以返回性能数据，以管道符号

|

PING ok - Packet loss = 0%, RTA = 0.80 ms | percent_packet_loss=0, rta=0.80

输出中的性能数据部分，可以通过 

$HOSTPERFDATA$ 

$SERVICEPERFDATA$

Shinken守护程序不直接处理性能数据，因此它也不关心其格式。

如果你需要处理性能数据，则需要启用process_performance_data选项，并配置Shinken，让性能数据写入到文件，或者执行命令。

选项host_perfdata_command、service_perfdata_command用于指定处理性能数据的命令。下面是命令的例子：

define command{
  command_name    store-service-perfdata
  command_line    /bin/echo -e "$LASTSERVICECHECK$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICESTATE$\t$SERVICEATTEMPT$\t
                                $SERVICESTATETYPE$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t
                                $SERVICEPERFDATA$" >> /var/lib/shinken/service-perfdata.dat
}

调用命令的方式可能会导致较高的CPU负载，特别是需要处理大量主机/服务时，最好先写入文件，然后由外部程序处理。使用host_perfdata_file、service_perfdata_file选项你可以指定写入到什么文件；而host_perfdata_file_template、service_perfdata_file_template 选项用于指定输出的模板。

在让Shinken真正能工作之前，你需要配置若干个文件。在目录

/etc/shinken/

编辑任何配置文件时，都要记住：

1. #开头的行是注释，不进行处理
2. 变量名大小写敏感

从2.0开始Shinken引入新的配置文件布局，基本的配置文件现在被分割到多个小的文件中。新的布局更好管理，例如一个文件对应一个对象的配置。

配置文件可以分为以下几类：

shinken.cfg

module

resource_file

cfg_file

cfg_dir

service_check_timeout=60
host_check_timeout=30 

在进行对象定义的时候，你可以使用对象继承机制，降低配置文件字段的冗余。

所有对象都可以使用以下三个和继承、递归相关的变量：

define someobjecttype{
       object-specific variables ...
       # 对象的名称，可以被其它对象引用，对于同一类型的对象，其名称必须唯一
       name            template_name
       # 你想从中继承属性/变量的“模板对象”
       use             name_of_template_to_use
       # 是否向Shinken注册此定义，如果该定义纯粹是作为模板使用的不完全定义，应该设置为0
       # 默认1，表示注册，该字段不会被继承
       register        [0/1]
}

有一点很重要，对象在本地自己定义的变量，总是比继承自模板的优先级高。也就是说，对象定义可以覆盖继承得到的值。

Shinken不限制对象继承的深度，上述的覆盖行为从祖代向子代逐步进行。

你在主机/服务/联系人中声明的自定义变量（_开头的），可以和普通变量一样被继承。

对于字符串类型的变量，你可以将其设置为null，防止从模板继承值：

event_handler null

默认的，你在对象里声明一个变量，会覆盖模板中的同名变量。

对于标准变量（非自定义）的字符串变量，Shinken支持所谓加性继承（additive inheritance），即把对象声明的值附加到继承值的后面。

要启用加性继承，只需要在声明值的时候前缀+号：

# 模板
hostgroups              all-servers

# use模板的对象
hostgroups             +linux-servers,web-servers
# 实际相当于
hostgroups             all-servers,linux-servers,web-servers

通常情况下，你要么继承，要么声明一个变量值，但是由几个例外情况。在这些情况下，Shinken会从相关对象继承值：

 一个对象可以同时继承多个模板，例如：

define host{
       name                    generic-host
       active_checks_enabled   1
       check_interval          10
       register                0
}
define host{
       name                    development-server
       check_interval          15
       notification_options    d,u,r
       register                0
}
define host{
       use                    generic-host,development-server
       host_name              devweb
}

对象devweb的实际定义相当于：

define host{
       host_name               devweb1
       active_checks_enabled   1
       check_interval          10
       notification_options    d,u,r
}

可以看到，声明在use列表前面的模板，具有更高的优先级。 

上面提到过，通过隐含继承，可以让Service自动从Host继承特定变量。对于不支持隐含继承的变量，你可以在主机中使用指令：

# 对于属于该主机的xxx服务，设置其yyy为zzz
service_overrides xxx,yyy zzz
# 支持多行值
service_overrides xxx,yyy zzz
                  aaa,bbb ccc

# 举例
define host {
       host_name               web-back-01
       hostgroups              web
       service_overrides       HTTP,notification_options c,r
}

这样可以避免从Pack中继承不匹配实际需求的值。

注意：service_overrides属性可以从模板继承。

你可以使用service_excludes指令，从Pack中排除继承得来的服务定义：

define host {
       use                     web-front
       host_name               web-back-01
       service_excludes        mgr
}

通过多次使用cfg_file、cfg_dir指令，你可以编写多个对象定义文件。安装好Shinken后，/etc/shinken/目录中有很多样例对象定义文件，这些文件存放在各自的目录中。

定义格式： 

# 语法
define host {
    optionname   optionvalue
}

# 示例
define host{
    host_name                      bogus-router
    alias                          Bogus Router #1
    address                        192.168.1.254
    parents                        server-backbone
    check_command                  check-host-alive
    check_interval                 5
    retry_interval                 1
    max_check_attempts             5
    check_period                   24x7
    process_perf_data              0
    retain_nonstatus_information   0
    contact_groups                 router-admins
    notification_interval          30
    notification_period            24x7
    notification_options           d,u,r
    realm                          Europe
    poller_tag                     DMZ
    icon_set                       server
}

选项列表：

service_overrides      HTTP,notification_period workhours

hostgroup_name=(linux|windows)&!qualification,routers

bp_rule

# 支持逻辑操作符
# 如果websrv1的apache服务或者websrv2的apache服务OK，并且dbsrv1上的oracle数据库OK
# 那么当前服务的状态判断为OK
bp_rule(websrv1,apache | websrv2,apache) & dbsrv1,oracle

host,service_description,host,service_description

通过Shinken支持的接口，管理员可以直观的看到监控数据，例如主机/服务的状态。

Shinken自带一个WebUI，你也可以使用其它开源/商业的Web前端，这些前端使用LiveStatus API或者SQL backend。LiveStatus具有很好的实时性、可扩容性和灵活性。

安装必要的模块：

# Web UI
shinken install webui
# 身份验证机制
shinken install auth-cfg-password
# 用户配置存储
shinken install sqlitedb

修改模块定义（安装WebUI模块后，此定义会自动生成）：

define module {
    module_name         webui
    module_type         webui
    host                0.0.0.0     # 监听所有网络接口
    port                7767
    auth_secret         CHANGEME    # 修改，防止Cookie伪造
    allow_html_output   1           # 是否允许插件输出HTML特殊字符
    max_output_length   1024        # 插件输出的最大长度
    manage_acl          1           # Use contacts ACL. 0 allow actions for all.
    play_sound          0           # 出现新的未确认问题时播放声音
    login_text          Welcome on Shinken WebUI   # 登陆表单提示信息
    modules             auth-cfg-password SQLitedb # 使用Shinken联系人进行身份验证，使用SQLitedb存储用户设置
}

修改用于登陆的联系人：

# 基本配置已经包含此联系人
define contact{
    use             generic-contact
    contact_name    admin
    email           shinken@localhost
    # 修改密码
    password        admin             
    is_admin        1
    expert          1
}

然后，需要让代理加载此模块定义：

define broker {
    ...
    modules   webui
}

现在你可以访问 http://ip:7767/user/login并登陆了。

使用Shinken WebUI2 

新版本的WebUI，内部集成了身份验证、存储、日志模块，简化了安装和配置。

安装模块：

pip install bottle
shinken install webui2

完毕后修改代理定义，把webui模块改为webui2，重启Shinken即可。

基于Livestatus的前端包括：

1. Thruk，适用于中小规模的场景
2. Multisite，适用于最大规模的可扩容性需求
3. Nagvis，用于图形化的展示，可以显示网络拓扑图，并标注每个主机的状态

获得livestatus模块定义：

# 使用SQLite存储历史日志
shinken install logstore-sqlite
# 获得livestatus模块定义
shinken install livestatus

在代理定义中加载livestatus模块

define broker {
    modules   webui2,livestatus
} 

禁用SELinux： 

SELINUX=disabled

安装必要的软件：

yum install httpd
yum install mod_fcgid

wget http://download.thruk.org/pkg/v2.08/rhel7/x86_64/libthruk-2.08-1.rhel7.x86_64.rpm
rpm -ivh ./libthruk-2.08-1.rhel7.x86_64.rpm
wget http://download.thruk.org/pkg/v2.08/rhel7/x86_64/thruk-base-2.08-1.rhel7.x86_64.rpm
rpm -ivh ./thruk-base-2.08-1.rhel7.x86_64.rpm 
wget http://download.thruk.org/pkg/v2.08/rhel7/x86_64/thruk-plugin-reporting-2.08-1.rhel7.x86_64.rpm
rpm -ivh ./thruk-plugin-reporting-2.08-1.rhel7.x86_64.rpm
wget http://download.thruk.org/pkg/v2.08/rhel7/x86_64/thruk-2.08-1.rhel7.x86_64.rpm
rpm -ivh ./thruk-2.08-1.rhel7.x86_64.rpm 

chkconfig httpd on
service httpd start

上述步骤完毕后，你可以通过http://ip/thruk/来访问Thruk了，默认登陆用户名密码是thrukadmin/thrukadmin。

enable_shinken_features = 1
<Component Thruk::Backend>
    <peer>
        name   = External Shinken
        type   = livestatus
        <options>
            peer    = 127.0.0.1:50000
        </options>
    </peer>
</Component>

注意livestatus的IP和端口要和livestatus的模块定义匹配。

完成配置后，重启Shinken，然后登陆到Thruk。在左侧菜单点击Config Tool，右上角Configuration Type选择Backends，点击Test测试。参考下图：

注意：从启动Shinken到livestatus可用，可能需要几分钟时间。

你可以使用预定义的模板来监控Windows设备，并获得内存用量、CPU负载、磁盘用量、系统服务状态、进程、系统事件日志等方面的信息。

有两种方法监控Windows设备：

1. 基于代理的方式：在目标设备上安装NSClient++
2. 无代理的方式：通过WMI协议直接通过网络轮询Windows状态

前提条件：你需要一个合法的Windows本地/域账号，用于执行WMI查询。

安装windows包：

shinken install windiws

安装必要的Perl模块：

yum -y install perl-Number-Format 
yum -y install perl-Config-IniFiles 
yum -y install -y perl-DateTime  

修改主机配置：

define host{
   # 继承windows模板
   use                     windows  
   _DOMAIN                 $DOMAIN$
   _DOMAINUSERSHORT        logonuser
   _DOMAINPASSWORD         passwd
}

与Windows设备的监控类似，你也可以监控Linux的内存用量、CPU负载、磁盘用量、进程等方面的信息。

你可以通过多种方式来监控Linux：

1. 通过SNMP代理
2. 基于一个本地的代理，可以高频率获取数据，支持主动、被动通信方式
3. 基于SSH的方式，只适用于非频繁的检测，可扩容性差

首先，你需要在目标设备上安装SNMP守护程序：

# CentOS 7
yum install net-snmp net-snmp-devel net-snmp-libs net-snmp-utils
systemctl enable snmpd
systemctl start  snmpd

# Debian/Ubuntu
apt-get install snmpd
sudo update-rc.d snmpd defaults
service snmpd start

修改snmpd的配置文件：

# Ubuntu 14.04
# 注释掉 agentAddress  udp:127.0.0.1:161，添加
agentAddress udp:161,udp6:[::1]:161
# 将 rocommunity public  default    -V systemonly 改为
rocommunity public

# CentOS 7
# 把默认的两行view systemview去掉，改为：
view systemview included .1.3.6.1

# 最好更改团体名（下面的public），以避免安全问题
# CentOS 7
com2sec notConfigUser  default       public
# Ubuntu 14.04
rocommunity public  default    -V systemonly

然后，你需要在监控服务器上执行以下操作：

1. 安装Perl的SNMP支持：

   yum -y install perl-Net-SNMP

    
2. 安装相关Shinken包：

   shinken install linux-snmp

    
3. 修改主机配置：
   

   define host{
       # 继承linux-snmp模板
       use                 linux-snmp
       # 指定团体名，默认是读取宏$SNMPCOMMUNITYREAD$的值，你可以在资源中定义该宏
       _SNMPCOMMUNITY      public
       # 监控哪个网络接口的使用情况
       _NET_IFACES         eth0
   }

完毕后，重启Shinken即可。

某些廉价的交换机、集线器没有IP地址，因而无法监控。相反的，一些高档网络设备则提供SNMP查询功能。

Shinken支持监控：

1. 丢包率、延迟
2. SNMP状态信息，需要交换机支持SNMP
3. 带宽/通信速率，需要安装MRTG，需要交换机支持SNMP

define service{
   use                    generic-service
   host_name              router
   service_description    PING
   # CRITICAL：RTA大于600ms或者丢包率不小于60%
   # WARNING：RTA大于200ms或者丢包率不小于20%
   # OK：RTA小于200ms并且丢包率小于20%
   check_command          check_ping!200.0,20%!600.0,60%
}

你可以执行命令：

snmpwalk -v1 -c public 192.168.1.1 -m ALL .1

监控命令举例：

# 监控路由器已经启动的时间
check_command        check_snmp!-C public -o sysUpTime.0
# 监控端口1的连接状态
check_command       check_snmp!-C public -o ifOperStatus.1 -r 1 -m RFC1213-MIB

如果你安装了MRTG ，则Shinken支持通过

check_mrtgtraf

define service{
   use                 generic-service
   host_name           router
   # 端口1的带宽使用情况
   service_description Port 1 Bandwidth Usage
   check_command       check_local_mrtgtraf!/var/lib/mrtg/192.168.1.253_1.log!AVG!1000000,2000000!5000000,5000000!10
}

通过该插件，你可以监控任意支持SNMP的网络设备（主要是交换机、路由器）的网络使用情况、CPU负载、内存使用、端口使用、硬件状态等方面的信息。 监控命令举例：

# 列出所有接口的状态
/var/lib/shinken/libexec/check_nwc_health --hostname 192.168.0.1 --timeout 60 --community "public" --mode interface-status
# 显示健康状态 
/var/lib/shinken/libexec/check_nwc_health --hostname 192.168.0.1 --timeout 60 --community "public" --mode hardware-health

支持JetDirect协议的打印机往往也启用了SNMP，可以通过插件check_hpjd监控之。

安装包：

shinken install hp-printers

修改主机配置：

define host {
    use    printer-hp
} 

这里的公共服务是指对外开放的，可以通过网络访问的服务、应用或者协议。公共服务的例子包括：HTTP、POP3、IMAP、FTP、SSH等。

官方的Nagios/Shinken插件支持很多常见服务、协议的监控。如果找不到合适的插件，你也可以自己开发。

安装http包：

shinken install http

修改主机配置：

define host{
        # 继承http或（和）https模板
        use                http,https  
        # 监听端口
        _CHECK_HTTP_PORT   80
        _CHECK_HTTPS_PORT  443
        # 测试的URI
        _CHECK_HTTP_URI    /index.html
        _CHECK_HTTPS_URI   /index.html
}

安装ftp包：

shinken install ftp

修改主机配置：

define host{
        # 继承ftp模板
        use               ftp
}

安装ssh包：

shinken install ssh

修改主机配置，继承ssh。注意，如果你的主机已经继承linux，则不需要再继承ssh。

使用Shinken你可以很好的监控MySQL的运行状态，获取包括InnoDB缓冲池状态、连接数、查询缓存命中率、缓慢查询、锁争用在内的数据。

安装mysql包：

shinken install mysql

安装MySQL的Perl驱动：

yum install -y perl-DBD-MySQL

修改主机配置：

define host{
        # 继承MySQL模板
        use                     mysql
        _MYSQLUSER              pems
        _MYSQLPASSWORD          pemsroot
} 

前提条件：你需要一个合法的Windows本地/域账号。

你可以监控：连接数、错误数量、登陆用户数等方面的信息。

安装需要的包：

shiken install windows
shinken install  iis

修改主机配置：

define host {
    # 继承iis和windows
    user    iis,windows
}

Shinken还提供了很多其它的包，方便你监控常见的服务：

# 监控邮件服务
shinken install imap
shinken install smtp
shinken install pop3

[1467096368] ERROR: [Shinken] Fail launching command: /usr/lib/nagios/plugins/check_ping -H localhost -w 1000,100% -c 3000,100% -p 1 [Errno 2] No such file or directory False

Shinken基本配置中的命令，主要是调用$NAGIOSPLUGINSDIR$目录下的监控插件（命令行），例如：

define command {
    command_name    check_ping
    command_line    $NAGIOSPLUGINSDIR$/check_icmp -H $HOSTADDRESS$ -w 3000,100% -c 5000,100% -p 10
}

宏$NAGIOSPLUGINSDIR$指向插件的安装目录，该宏的默认值定义在： 

# Nagios legacy macros
$USER1$=$NAGIOSPLUGINSDIR$
$NAGIOSPLUGINSDIR$=/usr/lib/nagios/plugins

#-- Location of the plugins for Shinken
$PLUGINSDIR$=/var/lib/shinken/libexec

如果你没有安装这些插件，或者安装位置不是/usr/lib/nagios/plugins，就会报找不到文件的错误。

你可以从多个地方获取插件：

1. Nagios Core Plugins：你可以下载50个核心Nagios插件
2. The Monitoring Plugins Project：监控插件项目，这个开源项目维护更多的插件

安装插件的示例脚本：

yum -y install openssl openssl-devel

wget https://www.monitoring-plugins.org/download/monitoring-plugins-2.1.2.tar.gz
tar xzf monitoring-plugins-2.1.2.tar.gz 
cd monitoring-plugins-2.1.2/
./configure --with-openssl
make && make install

修改宏定义，指向监控插件实际安装目录：

$NAGIOSPLUGINSDIR$=/usr/local/libexec

出现此错误的原因是编译插件的时候没有安装OpenSSL，参考上面的脚本，先安装OpenSSL再配置、构建、安装插件。

出现此错误的原因是没有安装Perl的MySQL驱动，安装即可：

yum -y install -y perl-DBD-MySQL

出现此错误的原因是缺少对应的Perl模块，安装即可：

yum -y install perl-Number-Format

出现此错误的原因是缺少对应的Perl模块，安装即可：

yum -y install perl-Config-IniFiles

出现此错误的原因是缺少对应的Perl模块，安装即可：

yum -y install -y perl-DateTime

安装缺少的函数库：

yum -y install redhat-lsb redhat-lsb-core

某些Shinken插件可能没有随基本配置安装，你可以到shiken-plugins网站下载：

cd /var/lib/shinken/libexec
wget https://raw.githubusercontent.com/Sysnove/shinken-plugins/master/check_netint.pl
chmod +x check_netint.pl

该插件是Native应用程序，需要手工编译：

wget https://labs.consol.de/assets/downloads/nagios/check_nwc_health-5.7.1.1.tar.gz
tar xzf check_nwc_health-5.7.1.1.tar.gz  && rm -f check_nwc_health-5.7.1.1.tar.gz
cd check_nwc_health-5.7.1.1/
./configure  && make
cp plugins-scripts/check_nwc_health* /var/lib/shinken/libexec/

# 初次使用cpanm命令时
cpan App::cpanminus

# 安装Load模块
cpanm Module::Load

# cpanm默认安装位置为~/perl5/lib/perl5/无法被check_nwc_health命令找到，因此需要手工拷贝一下
mkdir /usr/lib64/perl5/vendor_perl/Module
cp /root/perl5/lib/perl5/Module/Load.pm /usr/lib64/perl5/vendor_perl/Module

The post Shinken学习笔记 appeared first on 绿色记忆.