绿色记忆:Shinken学习笔记

Shinken学习笔记

By Alex

/ in Python

/ tags Monitoring, Shinken

0 Comments

Shinken简介

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

Shinken的优势包括：

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

特性列表

特性	说明
基于角色分离的守护程序	Shinken中的每个后端程序只做一种事情，这些后端程序有6类
强大的灵活性	大量的可拔插模块，让你能监控很多东西
从数据库导入配置	支持的数据库包括：GLPI、MySQL、MongoDB等
导出数据到数据库	支持的数据库包括：Graphite、InfluxDB、RRD、GLPI、CouchDB、Livestatus、MySQL、Oracle等
与WebUI集成	支持内置的WebUI，或者与Thruk、Adagios、Multisite、Nagvis、PNP4Nagios、NConf等集成
支持大量监控目标	数据库：MySQL、Oracle等关系型数据库；MongoDB等NoSQL；Memcached等缓存路由器/交换机：包括Cisco、Nortel、Procurve等公司的产品操作系统：Linux、Windows、Aix、HP-UX等网络协议：HTTP、SSH、LDAP、DNS、IMAP、FTP等应用程序：Weblogic、Exchange、AD、Tomcat等存储：IBM-DS、Safekit、Hacmp等
智能的SNMP轮询	如果你需要监控大量的路由器、交换机等基础设施，可以使用SNMP Booster模块
可扩容性	只需要在其它服务器上安装守护程序，负载均衡就会自动完成
高可用性	守护程序可以有多个备用的

架构

守护程序角色

角色	说明
Arbiter	此类守护程序负责：读取配置，拆分成N份（N=Scheduler的数量），然后分发给相应的其它守护程序管理高可用性：管理其它守护进程的健康状况，如果某个守护程序宕机，它负责把此守护程序管理的配置重新路由给其它空闲的守护程序接受用户输入，并路由给合适的守护程序同时只能有一个Arbiter处于活动状态，其它只能Standby 和Arbiter相关的模块包括：数据收集模块：NSCA、TSCA、Ws_arbiter 配置数据保存模块：MongoDB 状态保持模块：PickleRententionArbiter 配置数据导入模块：MySQLImport、GLPI 配置修改模块：vmware autolinking、IP_Tag
Scheduler	此类守护程序负责：分发检查（Check）给Poller、分发动作（Action）给Reactionner。它自己不会执行检查或动作处理检查结果队列（Check result queue）、分析结果，根据结果可能将动作请求纳入队列和Scheduler相关的模块包括：用于状态保持的模块：pickle、nagios、memcache、redis、MongoDB
Poller	依据Scheduler的指令，启动检查插件（Check plugins），检查完毕后，Poller把结果返回给Scheduler 和Poller相关的模块包括：数据获取模块：NRPE、CommandFile、SnmpBooster
Reactionner	发送通知、启动事件处理器（Event handler），集中处理和外部系统的通信和Reactionner相关的模块包括：外部通信模块：AndroidSMS
Broker	导出、管理来自Scheduler的数据，代理外部系统与Shinken的交互和Broker相关的模块包括： LiveStatus API模块——实时状态、状态保持、历史：SQLite（默认）、MongoDB 状态保持模块：Pickle、ToNdodb_Mysql、ToNdodb_Oracle 导出数据的模块：Graphite-Perfdata、NPCDMOD、raw_tcp、Syslog WebUI相关模块：WebUI、GRAPHITE_UI、PNP_UI
Receiver	被动的接收检查数据，并作为分布式的命令缓冲和Receiver相关的模块：被动数据获取模块：NSCA、TSCA、Ws_arbiter

安装

Linux

通过PIP安装

# 如果机器上没有安装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会使用下面的目录：

目录	说明
/etc/shinken	存放Shinken配置文件
/var/lib/shinken	存放Shinken模块、保留文件（Retention files）
/var/log/shinken	存放日志文件
/var/run/shinken	存放PID

Windows

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

Windows下所有目录都位于Shinken安装目录下，例如 /etc/shinken 对应 Windows下%SHINKEN_HOME%\etc 。

启动和运行

验证配置

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

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

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

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

常用选项

选项	说明
--version	显示版本信息并退出
--proxy=PROXY	指定代理服务器，格式： http://user:password@proxy-server:port
-A API_KEY	上传包时使用的API Key
-l, --list	列出子命令
--init	初始化并生成配置文件shinken.ini
-D	调试模式
-v	打印更多信息
-c INICONFIG	指定shinken.ini位置

常用子命令

子命令	说明
desc	列出对象类型的属性
doc-compile	编译文档
doc-serve	发布在线文档
install	从shinken.io下载并安装包
inventory	列出本地安装的包
publish	发布包到shinken.io
search	在shinken.io搜索包
update	更新一个软件包

基本配置

在安装完毕后，你就获得一个基本的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

}

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

选项	用于	说明
host_name	Arbiter	Arbiter所在的机器的主机名，在高可用性场景下（两个或更多Arbiter）必须配置
poller_tags	Poller	该Poller管理的Poller tags

定义模块

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

模块具有公共的选项：

选项	说明
module_name	模块的名称，用于被其它组件（例如守护程序）引用
module_type	模块的类型，由模块本身提供的固定值

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

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

define module{

module_name simple-log

module_type simple-log

path /var/log/shinken/shinken.log

}

然后修改默认的Broker：

1	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运行时一同分发，需要单独获取。可以从：

等地方获取插件。很多插件都提供帮助，你应该通过阅读帮助来了解如何使用之： ./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%

}

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

On-Demand宏

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

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

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

$HOSTMACRONAME:host_name$

$SERVICEMACRONAME:host_name:service_description$

# 举例

$HOSTDOWNTIME:myhost$ #myhosq的宕机时间

$SERVICESTATEID:server:database$ #server的database服务的状态ID

$CONTACTEMAIL:john$ #john的电子邮件

On-Demand组宏

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

#语法格式。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$ 和On-Demand宏不可通过环境变量访问。

标准宏列表

参考官方文档。

主机检查

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

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

主机检查是并行执行的。

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

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

主机状态

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

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

插件结果	主机状态（初步）	父主机状态	主机状态（最终）
OK	UP		UP
WARNING	DOWN*	至少一个父主机UP，则最终状态为DOWN 所有父主机都DOWN/UNREACHABLE，则最终状态为UNREACHABLE
UNKNOWN	DOWN
CRITICAL	DOWN

状态变更

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

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

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

服务检查

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

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

与主机检查一样：

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

服务状态

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

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

状态变更

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

主动检查

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

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

主动数据获取模块

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

SNMP数据获取模块：SnmpBooster

NRPE数据获取模块：NRPE

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

被动检查

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

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

SNMP陷阱、安全报警。你永远不知道一定时间内有多少陷阱、报警
安装了代理（Agent）的主机上的聚合检查，这种检查的执行间隔会相当低
直接从英语程序中提交检查结果，不依赖于中介日志文件（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外部命令，以提交检查结果。该命令的格式为：

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

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

状态类型

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

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

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

重新检查

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

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

软状态

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

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

当对象进入软状态时：

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

硬状态

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

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

当对象进入硬状态时：

日志记录HARD状态
调用事件处理器来处理HARD状态
通知联系人，告知问题或者恢复。事件处理器执行时， $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-N个其它服务
一个服务可以依赖于其它主机上的服务
通过服务依赖配置，你可以在服务的某些状态下，抑制检查的执行、通知的发送
依赖关系可以仅在特定时间段内启用

服务依赖示例

# 位于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允许在返回状态数据的同时，附带记录可选的性能数据。你可以把性能数据返回给外部程序进行处理。

性能数据的类型

性能数据分为两个类别：

检查性能数据

与主机、服务检查的执行过程本身相关的性能数据，例如检查的：

延迟时间，即实际发起检查与计划检查之间的延迟，相关宏 $HOSTLATENCY$、$SERVICELATENCY$
消耗时间，即检查执行开始到结束的时间，相关宏$HOSTEXECUTIONTIME$、 $SERVICEEXECUTIONTIME$

插件性能数据

与特定插件相关，可能包括丢包率、磁盘剩余空间、处理器负载、当前登陆用户数量……等等插件在执行时获取的任何度量数据

插件性能数据相关的宏有$HOSTPERFDATA$ 、$SERVICEPERFDATA$，不是所有插件都支持性能数据

插件性能数据

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

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

类似这样的输出，可以通过 $HOSTOUTPUT$ 或者 $SERVICEOUTPUT$ 宏来获取。

可选的，插件还可以返回性能数据，以管道符号 | 和上述可读数据分隔：

1	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/ 下有很多样例配置文件可供参考。

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

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

简介

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

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

配置文件类别	说明
主配置文件	即 shinken.cfg 文件，它是整个配置的入口点，它会作为命令行参数传递给Arbiter
守护程序定义文件	定义守护程序，依据类型的不同存放在不同的目录中，例如poller目录存放的是Poller守护程序目录中每个文件对应一个守护程序实例
模块定义文件	位于modules目录中，每个模块具有自己的配置文件由于模块由守护程序加载，因而守护程序定义文件会通过 module 指令引用这些模块定义文件
资源文件	存储用户定义的宏，主要用于存放敏感信息，例如密码在主配置文件中需要使用 resource_file 指令引用资源文件
对象定义文件	定义各种对象，例如主机、服务、主机组、联系人、联系人组，等等你可以在主配置文件中多次使用 cfg_file 或 cfg_dir 指令，来引用对象定义

主配置文件配置项

配置项

说明

cfg_dir

这两个属于声明（statements）而非参数（parameters）
Arbiter会这些配置文件，或者目录中的.cfg文件。对于目录，Arbiter会递归的读取，这些被读取的文件中如果包含这两条声明，会被忽略

cfg_file

retention_update_interval

自动的状态保持（State Retention）更新间隔，单位分钟，默认60
该参数指示Scheduler自动保存Retention数据的间隔，如果设置为0则不会定期保存，但是Shinken重启或关闭时仍然会保存

max_service_check_spread

Shinken启动后，最长多少分钟内服务、主机被检查，默认30
该参数用于确保主机、服务状态在一定时间内被检查

max_host_check_spread

service_check_timeout

服务检查最大消耗时间（秒），如果超时Shinken会杀死Check并返回一个CRITICAL状态并记录超时错误日志。该配置作为终止不正常运作的插件的最后手段。默认值：

1 2	service_check_timeout=60 host_check_timeout=30

host_check_timeout

timeout_exit_status

超时的退出状态，可选值0、1、2、3，默认2
当超时时由Shinken自动设置

flap_history

对象状态的历史数值的保持数量，这些历史值用于判断对象处于动荡——状态频繁变化——的状态。默认20

max_plugins_output_length

负责检查的插件（Checks plugin）输出的最大字节数，默认8192

enable_problem_impacts_states_change

布尔值0/1默认0，当一个主机/服务受一个根源性问题（例如服务所属的主机、主机的parent宕机）影响时，是否改变其状态

如果启用，服务的状态会变成UNKNOWN而主机的状态会变成UNREACHABLE，直到下一轮检查

disable_old_nagios_parameters_whining

布尔值0/1默认0，如果启用，在检查配置时所有通知、警告消息禁用

use_timezone

覆盖时区设置

enable_environment_macros

布尔值0/1默认1，是否将所有标准宏作为环境变量，暴露给检查、通知、事件处理器

log_initial_states

布尔值0/1默认1，是否强制记录所有主机/服务的初始状态，即使它们是OK

no_event_handlers_during_downtimes

布尔值0/1默认0，Shinken是否在主机/服务处于计划内宕机时间内，仍然运行事件处理器

Arbiter默认配置
适用于所有Arbiter

workdir

守护程序的工作目录，默认/var/run/shinken/。对于Arbiter默认值为lock_file所在目录

lock_file

Arbiter作为后台程序（-d）运行时存放PID的文件

local_log

守护程序日志文件位置，默认/var/log/shinken/arbiterd.log

log_level

日志级别，可选：DEBUG,INFO,WARNING,ERROR,CRITICAL，默认WARNING

shinken_user

Arbiter进程（主进程）的有效（Effective）用户

shinken_group

Arbiter进程的有效组

modules_dir

模块存放的目录，默认/var/lib/shinken/modules

daemon_enabled

布尔值0/1默认1，设置为0则Arbiter不会运行

use_ssl

布尔值0/1默认0，是否使用SSL，如果启用，则其它守护程序也必须启用

ca_cert

CA证书

server_cert

服务器证书

server_key

服务器密钥

hard_ssl_name_check

布尔值0/1默认0，启用SSL名称检查

http_backend

使用的HTTP后端组件，可选：auto, cherrypy, swsgiref

主配置文件进阶配置项

perfdata_timeout

主机/服务性能数据处理器命令（performance data processor command ）的处理超时
默认5秒，如果超时，处理器被终结并在日志中记录警告

process_performance_data

是否处理主机/服务检查的性能数据
如果你希望使用PNP、NagiosGrapher、Graphite等工具，需要设置为1

host_perfdata_command

主机/服务的性能数据处理命令
每次主机/服务检查后，都会调用这些命令处理性能数据

service_perfdata_command

host_perfdata_file

允许你指定一个存储性能数据的文件，供外部程序后续处理

service_perfdata_file

host_perfdata_file_template

性能数据文件的格式模板

service_perfdata_file_template

host_perfdata_file_mode

性能数据存储文件的操作模式：
a 附加模式（默认）；w写模式；p非阻塞的读写模式，写入管道时使用

service_perfdata_file_mode

cached_host_check_horizon

多久（秒）以内的历史检查结果被认为是“当前的”
默认15秒，过大的值会导致不精确的结果，但是大的值会提高性能

cached_service_check_horizon

use_large_installation_tweaks

设置为1，可以在大规模环境下提高性能，但是会丢失一些特性

enable_flap_detection

是否启用状态动荡检测，默认0

low_service_flap_threshold

单位百分比，下限默认25，上限默认50
用于设定检测状态动荡的上下限阈值

low_host_flap_threshold

high_service_flap_threshold

high_host_flap_threshold

event_handler_timeout

事件处理器的执行超时时间，默认30秒

notification_timeout

通知的发送超时时间，默认30秒

ocsp_timeout

ocsp执行的超时时间，默认15秒

ochp_timeout

ochp执行的超时时间，默认15秒

check_service_freshness

是否允许Shinken检测被动检查的“新鲜度”，用于确认是否被动检查被定期的发送给Shinken

check_host_freshness

service_freshness_check_interval

新鲜度检查的时间间隔，默认60秒

host_freshness_check_interval

human_timestamp_log

日志中的时间戳，是否保存为人类可读的方式
默认0，保存为unixtime格式

date_format

日期格式，可选值：iso8601、strict-iso8601、us、euro

resource_file

指定资源文件的位置

triggers_dir

指定触发器的位置，会递归的寻找*.trig文件

idontcareaboutsecurity

是否允许以root身份运行守护程序，默认否

enable_notifications

是否启用通知机制，默认1

check_external_commands

指示Shinken是否检查外部命令文件（ External Command File ），以发现需要被Arbiter执行的命令

command_file

外部命令文件（命名管道）的路径

execute_service_checks

是否执行主机/服务状态主动检查，默认1

execute_host_checks

accept_passive_service_checks

是否接收主机/服务状态被动检查结果，默认1

accept_passive_host_checks

enable_event_handlers

是否启用事件处理器

use_syslog

是否记录系统日志，仅Linux

log_notifications

是否记录通知发送情况，默认1

log_event_handlers

是否记录事件处理器执行情况，默认1

log_external_commands

是否记录外部命令执行情况，默认1

interval_length

单位时间间隔（interval）的长度，默认60秒
很多其它配置项间接受到该配置项的影响

注意，Shinken并没有被设计为硬实时监控系统，因此把这个参数设置为5或者更低的值不是好主意

对象继承

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

基础知识

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

define someobjecttype{

object-specific variables ...

# 对象的名称，可以被其它对象引用，对于同一类型的对象，其名称必须唯一

name template_name

# 你想从中继承属性/变量的“模板对象”

use name_of_template_to_use

# 是否向Shinken注册此定义，如果该定义纯粹是作为模板使用的不完全定义，应该设置为0

# 默认1，表示注册，该字段不会被继承

}

本地变量vs继承的变量

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

继承层次

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会从相关对象继承值：

对象类型	变量	隐含继承源
Services	contact_groups	关联的host定义
Host Escalations	contact_groups	关联的host定义
Service Escalations	contact_groups	关联的service定义

多重继承

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

define host{

name generic-host

active_checks_enabled 1

check_interval 10

}

define host{

name development-server

check_interval 15

notification_options d,u,r

}

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列表前面的模板，具有更高的优先级。

继承覆盖（Inheritance overriding）

上面提到过，通过隐含继承，可以让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属性可以从模板继承。

继承排除（Inheritance exclusions）

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

define host {

use web-front

host_name web-back-01

service_excludes mgr

}

对象定义文件配置项

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

对象分类

对象类别	说明
主机（Hosts）	主机是监控逻辑中的中心对象之一。主机包括以下重要特征：主机常常是网络中的一个物理设备，例如服务器、工作站、路由器、交换机、打印机等主机拥有某种形式的地址，例如IP、MAC 主机拥有1-N个与之关联的服务主机可以和其它主机具有父子关系，这呈现了真实世界的网络结构，用于网络可到达性检查
主机组（Host Groups）	将一系列主机分组，可以：在WebUI中查看一组相关主机的状态简化配置
服务（Services）	服务是监控逻辑中的中心对象之一。它附属于主机，可以是：主机的某个属性值：CPU负载、磁盘用量、启动时间等主机提供的某种服务：HTTP、POP3、FTP、SSH等其它与主机关联的东西，例如DNS记录
服务组（Service Groups）	将一系列服务分组，可以：在WebUI中查看一组相关服务的状态简化配置
联系人（Contacts）	联系人是指在通知处理中牵涉进来的人员的信息：联系人可以包含1-N种通知方法，例如电话、邮件、即时消息联系人接收他们负责的主机、服务的通知信息
联系人组（Contact Groups）	联系人的分组，用于简化通知的配置，例如当特定主机、服务发生故障时通知若干个联系人
命令（Commands）	命令用于告知Shinken需要执行什么程序、脚本以便：执行主机、服务检查发送通知执行事件处理器等等
时间段（Time Periods）	时间段用于控制：何时主机、服务可以被监控何时联系人可以被通知

主机定义

定义格式：

# 语法

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

}

选项列表：

选项

说明

host_name

用于识别主机的短名称，在主机组、服务中引用的就是该名称
对应宏$HOSTNAME$

alias

用于识别主机的长名称
对应宏$HOSTALIAS$

display_name

在WebUI中的显示名称，默认为host_name

address

主机的通信地址，一般是IP
对应宏 $HOSTADDRESS$

parents

逗号分隔的父主机的短名称，父主机常常是路由器、交换机、防火墙等位于监控服务器与目标主机之间的网络设备
位于同一网段的目标主机不需要设置该字段

hostgroups

逗号分隔的、所属的主机组的短名称

check_command

用于检查主机开/关状态的命令的短名称，典型情况下命令使用PING来确定主机是否连通，命令必须返回状态码0来表示主机OK，否则Shinken一律认为主机宕机

initial_state

主机的初始状态，默认的，Shinken认为主机是开启的，可选值：
o 正常；d 宕机；u不可达

max_check_attempts

如果返回状态不是OK，Shinken会重试对主机的检查的最大次数

check_interval

周期性的对主机进行检查，检查的间隔
除非你修改 interval_length的默认值60，否则单位为分钟

retry_interval

在到达max_check_attempts前，重新检查的执行间隔
除非你修改 interval_length的默认值60，否则单位为分钟

active_checks_enabled

布尔值0/1，是否启用主动的状态检查

passive_checks_enabled

布尔值0/1，是否启用被动的状态检查

check_period

引用时间段的短名，指示何时允许执行主动状态检查

obsess_over_host

check_freshness

布尔值0/1，指示是否对该主机启用freshness checks

freshness_threshold

指定freshness的阈值（单位秒），如果设置为0则Shinken自动确定阈值

event_handler

引用一个命令的短名，当主机状态变化时，该命令被作为事件处理器执行

event_handler_enabled

布尔值0/1，是否启用事件处理器

low_flap_threshold

在状态动荡检测时，指定高、低状态变化阈值

high_flap_threshold

flap_detection_enabled

布尔值0/1，是否启状态动荡检测

flap_detection_options

状态动荡检测逻辑使用哪些状态，o、d、u的组合，逗号分隔

process_perf_data

是否对该主机启用性能数据处理

retain_status_information

是否在Shinken重启后，仍然保持（retain）该主机的状态

retain_nonstatus_information

是否在Shinken重启后，仍然保持（retain）该主机的非状态信息

contacts

逗号分隔的联系人短名称

contact_groups

逗号分隔的联系人组短名称

notification_interval

如果主机状态持续在d、u，则在重复通知联系人前需要等待的时间
除非你修改interval_length的默认值60，否则单位为分钟

first_notification_delay

第一次发送通知的延迟时间，如果在此期间主机状态变为o则不会发送通知
除非你修改interval_length的默认值60，否则单位为分钟

notification_period

引用时间段的短名，指示何时允许发送通知

notification_options

哪些主机状态会导致通知的发送，逗号分隔：
d宕机；u不可达；r恢复正常；f开始或结束状态动荡；s计划内的启动和停机
如果设置为n，则不会发送任何关于该主机的通知

notifications_enabled

是否启用针对该主机的状态通知

stalking_options

启用对该主机哪些状态的跟踪，逗号分隔的o、d、u

notes

主机的备注字段

notes_url

主机的备注URL

action_url

可以提供针对主机的额外操作的URL

icon_image

主机的图标

icon_image_alt

图标不可用时显示的文字

vrml_image

与statuswrl CGI相关

statusmap_image

与statusmap相关

2d_coords

在statusmap CGI中绘制主机时，主机的二维坐标

3d_coords

在statuswrl CGI中绘制主机时，主机的三维坐标

realm

定义主机归属的领域，主机将被领域的一个Scheduler管理

poller_tag

定义主机的poller_tag，该主机上的任何检查，只能被poller_tags包含该poller_tag的Poller执行

reactionner_tag

与上面类似，指定哪些Reactionner才能处理来自该主机的通知

business_impact

指示该主机的重要性，0-5之间，默认2，数字越大越重要

resultmodulations

与resultmodulations对象连接，从而应用modulation到主机

escalations

与escalations对象连接，从而应用escalations规则到主机

business_impact_modulations

与business_impact_modulations对象连接

icon_set

设置在Shinken Web UI中的图标，可用值：database, disk, network_service, server

maintenance_period

指定一个周期性的维护时间

service_overrides

用于覆盖属于该主机的服务的选项，在使用继承（inherited，例如从一个pack中）来的服务时很有用，它允许你为服务提供不一样的值

举例：HTTP服务（继承自http pack）用于生产环境时可能需要24x7启用通知，而演示环境可能仅需要工作时间启用通知。这时你可以覆盖：

1	service_overrides HTTP,notification_period workhours

你可以指定多个覆盖项，但是每个项应当占据独立的一行

service_excludes

从主机中排除服务，逗号分隔。服务可能来自从一个pack中继承，或者附加到当前主机所属的组上

service_includes

和上面的功能类似，但是指出该主机仅仅包含的服务

labels

任意逗号分隔的多个标签

business_rule_output_template

商业规则的输出模板

business_rule_smart_notifications

用于启用智能化的针对商业规则的通知，可以用于在底层问题被确认后，停止继续发送通知

business_rule_downtime_as_ack

business_rule_host_notification_options

business_rule_service_notification_options

snapshot_enabled

是否启用针对该主机的快照

snapshot_command

执行快照时启动的命令

snapshot_period

允许快照调用的时间段

snapshot_criteria

启用快照的状态列表（通常都是坏的状态），逗号分隔

snapshot_interval

两次快照执行的最小间隔
除非你修改interval_length的默认值60，否则单位为分钟

trigger_name

主动/被动检查结果得到后，执行的触发器，触发器文件trigger_name.trig必须被预先保存在触发器目录或者子目录中

trigger_broker_raise_enabled

主机组定义

选项	说明
hostgroup_name	用于识别主机组的短名称
alias	一个较长的别名
members	归属为该组的主机成员，亦可在主机定义的hostgroups配置项声明归属关系
hostgroup_members	把其它组的成员加入到本组
realm	该组的所有成员属于的领域

服务定义

选项

说明

host_name

该服务在哪个主机上运行（属于哪个主机），指定主机的短名

hostgroup_name

让目标组的所有主机都具有该服务，支持逻辑操作符：&逻辑与；|逻辑或（亦可用逗号,）；!逻辑非、支持括号限定优先级。举例：

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

service_description

服务的描述，一个主机下，不得有两个服务具有相同的描述

display_name

在UI中显示的名称

servicegroups

所属的服务组的短名，逗号分隔

is_volatile

声明服务是否“易变的”，默认否

duplicate_foreach

用于基于一个服务定义，生成多个类似的服务

check_command

指定用于检查该服务状态的命令的短名称，主配置文件选项service_check_timeout限制了命令执行的最大时间

由一个内部定义的、特殊用途的命令 bp_rule ，该命令不需要定义。该命令不是执行一个特定的插件，而是依据其它服务的状态来执行一个逻辑操作，例如：

# 支持逻辑操作符

# 如果websrv1的apache服务或者websrv2的apache服务OK，并且dbsrv1上的oracle数据库OK

# 那么当前服务的状态判断为OK

bp_rule(websrv1,apache | websrv2,apache) & dbsrv1,oracle

initial_state

默认的，Shinken认为所有服务的状态是正常（OK），你可以覆盖默认状态：
o正常；w警告；u未知；c关键（错误）

max_check_attempts

参考主机配置同名配置项

check_interval

retry_interval

active_checks_enabled

passive_checks_enabled

check_period

obsess_over_service

check_freshness

freshness_threshold

event_handler

event_handler_enabled

low_flap_threshold

high_flap_threshold

flap_detection_enabled

flap_detection_options

process_perf_data

retain_status_information

retain_nonstatus_information

notification_interval

notification_interval

notification_period

notification_options

notifications_enabled

contacts

contact_groups

stalking_options

notes

notes_url

action_url

icon_image

icon_image_alt

poller_tag

reactionner_tag

business_impact

icon_set

maintenance_period

service_dependencies

定义该服务依赖的其它服务，在通知时有用，为了避免通知泛滥，Shinken只会将Root问题通知给联系人，此配置项用于发现问题的根

值格式： host,service_description,host,service_description ，其中主机可以忽略，表示依赖于当前主机下的服务

host_dependency_enabled

可以移除服务和它的主机之间的依赖关系，对于需要依据其自身而不是所属主机进行通知的volatile服务有用

labels

参考主机配置同名配置项

business_rule_output_template

business_rule_smart_notifications

business_rule_downtime_as_ack

business_rule_host_notification_options

business_rule_service_notification_options

snapshot_enabled

snapshot_command

snapshot_period

snapshot_criteria

snapshot_interval

trigger_name

trigger_broker_raise_enabled

集成

如何查看数据

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

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

基于内存直接访问的UI

使用Shinken WebUI

安装必要的模块：

# 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，内部集成了身份验证、存储、日志模块，简化了安装和配置。

安装模块：

1 2	pip install bottle shinken install webui2

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

基于网络访问（Livestatus）的UI

基于Livestatus的前端包括：

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

启用Livestatus模块

获得livestatus模块定义：

# 使用SQLite存储历史日志

shinken install logstore-sqlite

# 获得livestatus模块定义

shinken install livestatus

在代理定义中加载livestatus模块

define broker {

modules webui2,livestatus

}

使用Thruk作为Shinken前端

安装Thruk

禁用SELinux：

1	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。

将Shinken配置为Thruk的后端

enable_shinken_features = 1

<peer>

name = External Shinken

type = livestatus

peer = 127.0.0.1:50000

</options>

</peer>

</Component>

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

连通性测试

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

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

如何监控...

Windows设备

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

监控方式

有两种方法监控Windows设备：

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

基于WMI的监控

前提条件：你需要一个合法的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

}

Linux设备

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

监控方式

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

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

基于SNMP的监控

首先，你需要在目标设备上安装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

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

安装Perl的SNMP支持： yum -y install perl-Net-SNMP
安装相关Shinken包： shinken install linux-snmp

修改主机配置：

define host{

# 继承linux-snmp模板

use linux-snmp

# 指定团体名，默认是读取宏$SNMPCOMMUNITYREAD$的值，你可以在资源中定义该宏

_SNMPCOMMUNITY public

# 监控哪个网络接口的使用情况

_NET_IFACES eth0

}

完毕后，重启Shinken即可。

路由器和交换机

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

Shinken支持监控：

丢包率、延迟
SNMP状态信息，需要交换机支持SNMP
带宽/通信速率，需要安装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%

}

监控SNMP

你可以执行命令： 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

}

使用check_nwc_health

通过该插件，你可以监控任意支持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/HTTPS

安装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

安装ftp包： shinken install ftp

修改主机配置：

define host{

# 继承ftp模板

use ftp

}

监控SSH

安装ssh包： shinken install ssh

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

监控MySQL

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

安装mysql包： shinken install mysql

安装MySQL的Perl驱动： yum install -y perl-DBD-MySQL

修改主机配置：

define host{

# 继承MySQL模板

use mysql

_MYSQLUSER pems

_MYSQLPASSWORD pemsroot

}

监控IIS

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

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

安装需要的包：

1 2	shiken install windows shinken install iis

修改主机配置：

define host {

# 继承iis和windows

user iis,windows

}

监控其它公共服务

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

# 监控邮件服务

shinken install imap

shinken install smtp

shinken install pop3

常见问题

主机检查报错：[Errno 2] No such file or directory

报错示例

[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，就会报找不到文件的错误。

解决办法

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

Nagios Core Plugins：你可以下载50个核心Nagios插件
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

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

1	$NAGIOSPLUGINSDIR$=/usr/local/libexec

https服务检查报错

check_http: Invalid option - SSL is not available

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

检查MySQL报错

cannot connect to information_schema. Can't locate DBI.pm

出现此错误的原因是没有安装Perl的MySQL驱动，安装即可： yum -y install -y perl-DBD-MySQL

监控Windows设备时报错

Can't locate Number/Format.pm

出现此错误的原因是缺少对应的Perl模块，安装即可： yum -y install perl-Number-Format

can't locate Config/IniFiles.pm

出现此错误的原因是缺少对应的Perl模块，安装即可： yum -y install perl-Config-IniFiles

Can't locate DateTime.pm

出现此错误的原因是缺少对应的Perl模块，安装即可： yum -y install -y perl-DateTime

CentOS下Shinken启动System V脚本报错

log_warning_msg: command not found

安装缺少的函数库： yum -y install redhat-lsb redhat-lsb-core

基于SNMP的监控报错

/bin/sh: /var/lib/shinken/libexec/check_netint.pl: No such file or directory

某些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

/bin/sh: /var/lib/shinken/libexec/check_nwc_health: No such file or directory

该插件是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/

Can't locate Module/Load.pm in @INC

# 初次使用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

← Kubernetes学习笔记

Shinken学习笔记

Shinken学习笔记

Leave a Reply Cancel reply

ABOUT ME

ABOUT GMEM

GMEM HISTORY

MIRROR INFO

Meta

Recent Posts

TOPLINKS

Recent Comments