标签归档:Nagios

使用Grafana+InfluxDB展示Nagios监控数据

 

概述

Nagios作为监控软件来说已经让人基本满意了,但是个人在使用中感觉还存在部分问题:

  1. 不能绘图

可能有同学会说不是有PNP4Nagios这样的软件吗?这个软件Nagios并没有默认携带,需要自己手动安装配置。

另外PHP4Nagios虽然已经能满足显示上的需求,但是绘图效果比较古老(图片来自网络,侵删):

PNP4Nagios sample

并且不能对某些数据进行对比(比如多台机器的负载情况在同一个图表中显示)。

  1. 无法查看历史数据

Nagios只能看到“现在”的数据,无法回顾历史以及查看趋势。

譬如,如果使用现有的Nagios,想要回顾周日半夜任务对系统的消耗时,就会比较抓瞎了。

方案

绘图

先说绘图。

绘图作为一个附加的功能,可以考虑现有的一些优秀的数据展现软件,譬如KibanaGrafana

个人认为,Kibana更适合展现日志计数类型的数据,并且本身没有权限控制等功能,这一点比较麻烦,虽然可以通过第三方插件或者HTTP Basic Auth来解决,但是总是增加了维护成本。

相比之下,Grafana带有权限控制,能支持相当多的时序数据库,从graphite、opentsdb、influxdb,当然也有ES。多条曲线同时展示时还可以看到具体数值,显示效果也相当不错。

Grafana sample from it's website

并且,Grafana在4.0后将会具有告警功能,玩法会变得更多。

最终选择Grafana作为展示端。

数据内容

提一下数据内容。

在这个方案中,我们展现的数据,实际上是Nagios插件产生的Performance Data(或者叫PERFDATA),如果自行编写的插件没有按照 PERFDATA 的格式输出信息,是不会被收集到InfluxDB中的。如果有自行编写业务监控插件,除了基本的返回码和错误信息之外,要考虑按照标准输出相关的信息,以便收集到InfluxDB中。

Nagios 3的插件多行输出格式为:

TEXT OUTPUT | OPTIONAL PERFDATA

LONG TEXT LINE 1

LONG TEXT LINE 2

LONG TEXT LINE N | PERFDATA LINE 2

PERFDATA LINE 3

PERFDATA LINE N

如磁盘信息的收集,单行模式很好理解,通过 | 分隔输出信息以及 PERFDATA;多行模式的话,引用官网的例子:

DISK OK – free space: / 3326 MB (56%); | /=2643MB;5948;5958;0;5968

/ 15272 MB (77%);

/boot 68 MB (69%);

/home 69357 MB (27%);

/var/log 819 MB (84%); | /boot=68MB;88;93;0;98

/home=69357MB;253404;253409;0;253414

/var/log=818MB;970;975;0;980

第一行仍然可以按照单行模式进行理解(红色部分是输出信息,橙色部分是 PERFDATA),从第二行开始,每行一个输出信息,最后将剩余的 PERFDATA 紧接着输出信息的最后一行,通过 | 分隔,逐行输出。

每项 PERFDATA 格式为:

引用上述例子的数据 /=2643MB;5948;5958;0;5968,可以看到对应关系为:

label /
value 263MB
warn 5498
crit 5958
min 0
max 5968

UOM 表示 unit of measurement,即单位,可以是:

  • 不设定(即数字)
  • s(或者msus
  • 百分数%
  • 字节B(或者KB, MB, TB

详情可以参阅 Nagios Plugin Development Guidelines 以及 Nagios Plugin API

数据落地

只有Grafana是不能完成期望的工作的,Grafana只是展现工具,需要有数据源才能展现。

目前主力使用的时序数据库是ES,但是可以看到Nagios官方网站上关于绘图这一主题推荐的插件中没有看到写入到ES中的插件(ES倒是可以把输出作为监控信息交给Nagios,参见)。

查阅资料,graphite性能可能存在问题,opentsdb需要有专业的运维同学维护(毕竟是Hadoop衍生产品),InfluxDB兼顾了性能和运维成本,考虑使用。

值得一提的是,InfluxDB提供了Web管理端,查询语句上类似SQL,便捷程度让人满意。

数据收集

落地方式确定之后,需要考虑如何将Nagios收集的诸如load、CPU、内存使用等信息存入InfluxDB了。

graphios可以相当便捷的完成这一工作。这是一个将Nagios perf data写入到InfluxDB中的工具。配置也相当便捷,基本上按照README即可完成。

Nagflux看起来也是不错,然而问题在于这个适用于4.x版本的Nagios,在不打算升级Nagios的情况下,只能放弃。

但是,凡事总有例外,使用软件的特定组合的情况下,会出现一些问题。

数据解析异常

graphios在Nagios官网上声称匹配3.x版本的Nagios,但是在与实际使用的Nagios 3.5结合时,会出现部分perf data无法成功解析的情况,检查后发现Nagios 3.5的部分数据在graphios读取时,并没有按数据协议组织,导致解析错误。

对此,针对输出数据,修改了解析所在部分源码进行了匹配,筛选出了所需数据。

InfluxDB版本

提示的InfluxDB版本较新,为0.13,然而,在graphios的配置文件中,backend部分,只有enable_influxdb09以及enable_influxdb选项,默认使用的json数据写入协议已经在0.13废弃

上述问题,考虑到版本后续兼容性,将0.13视作0.9版本配置,并且配置数据写入协议为line即可(即配置influxdb_line_protocol = True)。

为了让graphios永驻后台,可以考虑使用supervisord等工具。

展现样例

load

load

CPU

CPU

小结

使用Nagios+graphios+InfluxDB+Grafana可以将监控数据以更好的方式进行展现,并能够回顾历史,查看趋势,随着Grafana的升级,还可以有更多的玩法。

Nagios检查域名是否可连通

 

概述

日常服务器使用中,可能存在某些服务器被意外的更改路由表等问题,在多张网卡的情况下,可能会出现Nagios可以发现服务器,但是实际上服务器对外连接不可用的情况。

这必然是对服务有着致命打击的,将其纳入监控势在必行。

分析

大多数时候,我们只需要要关心这个服务需要访问的域名的连通性,即主机的连通性,可以考虑通过nagios定时ping。如果是web服务,还可以通过curl判断访问情况。

思路确定的话,那么编写插件即变得很容易。针对Nagios的使用上,可以考虑定义自定义命令,通过nrpe调用客户端上的插件,通过主动检查的方式进行。

通过nrpe调用命令的设置上有一个很有趣的地方,客户端定义的指令和服务端定义的指令有一个位置的偏移,因为服务端的调用check_nrpe插件第一个参数$ARG1必定是客户端上的命令名称。所以服务端的定义的$ARG2将会被作为到客户端的$ARG1使用。

例如,服务端指定命令为:

客户端的命令为:

服务端 客户端
\(ARG1\) check_domain_accessibilty
\(ARG2\) \(ARG1\)
\(ARG3\) \(ARG2\)
\(ARG4\) \(ARG3\)

可以看到的对应关系为:

插件代码

插件代码通过shell编写,按照Nagios插件的特定,只出现OK/CRITICAL/UNKNOWN三种情况。

考虑到内网请求是主要关注的点,连通性不佳(如ping丢包)也会被归类到CRITICAL之中,用于提醒SA关注。

自定义Nagios报警脚本

概述

Nagios可以使用邮件报警,但是如果使用IM软件提供的API进行报警的话,时效性上来说必然是会更好的。

另外如果使用自定义的报警脚本,可以针对报警做更多的事情,譬如限频,异步发送,记录入库等操作。

总而言之就是可以拥有更为灵活的工具。

关键点

开发语言

众多的Nagios插件均使用Perl编写,如 监控Redis 中使用到的工具。

选用Perl语言对于我来说并不是一个好的选择,如果选用了Perl,那么在主要使用PHP的环境下,不能方便的重复利用已有框架的各种工具,同时从语言的熟悉程度上来说,自然是PHP胜过Perl。

综上,选用PHP作为插件开发语言。

选用PHP作为Nagios报警插件的开发语言,需要在脚本的首行指定 Shebang ,即指定PHP可执行程序的绝对路径,形如:

Shebang之下仍然需要使用 <?php 标签。

同时,为了能让Nagios能直接执行报警插件,需要赋予可执行权限:

脚本输入输出

输入

脚本的输入方式与普通的命令行工具并无太多区别,可以使用 getopt 来获取输入的参数。

由于需要实现限频,以及针对主机和服务做一些处理,定义了如下的参数:

参数 说明
u 通知用户
m 报警消息体
r 频率限制值,秒为单位
h 主机
p 端口
l 通知等级,即OK/CRITICAL/WARNING/UNKNOW等
n 通知类型,即PROBLEM/CUSTOM等

限频的目的在于防止接收过多信息,避免必须处理的信息无法及时被发现。

而针对服务恢复正常的信息,不需要限频。

输出

Nagios的插件通过返回值确定这次检验的状态,即:

Exit code 状态
0 OK
1 WARNING
2 CRITICAL
3 UNKNOWN

不过由于是报警脚本,不妨直接让脚本返回0吧。

自定义变量

Nagios在调用编写的报警脚本时,通过定义好的command格式,完成传参。

对应到每一个联系人,需要有变量告知联系人的联系方式,针对IM,比如QQ,自然是QQ号。查阅Nagios预定义宏,会发现并没有QQ号这样的预定义宏。

当然可以选用预定义的 CONTACTPAGER 。考虑到寻呼机已经几乎没人使用了,可以借用一下变量。

针对各种工具(IM/内部通信接口/短信平台接口等),需要自定义。

关于自定义,Nagios的文档已有说明,这里简单提及一下:

  • 自定义变量必须以_开头以防止与预定义变量冲突
  • 自定义变量使用时需要转为全大写
  • 自定义变量会在前方加上所属的对象类型

针对第三点,简单说来,针对Contact,即联系人这一对象,如果定义了名为uid的自定义变量,那么,在contact的配置中,需要写成_uid,而实际在配置command时,会变为$_CONTACTUID$

配置commands

新增一个发送报警命令send_pm,定义这一自定义报警的调用方式。

参数列表正如上文提及的。

报警内容为了简短,只会发送主机名、服务名称以及检查结果的首行。

配置contacts

在需要报警的联系人配置中,加上自定义的uid变量,以及指定报警方法:

以上。

使用Nagios监控Redis-按内存使用率监控

概述

本文是 使用Nagios监控Redis 的补充记录。

根据前期选用的插件,通过直接针对 used_memory_rss 设定监控阈值完成监控,而这一阈值的问题在于是使用字节数的表示的,如果要按照36GB70%设定阈值监控,就需要将监控的值设定为(结果已四舍五入):

这一数字对于config文件来说,以及监控用户来说并不友好。

解决

插件本身也提供了直接通过使用率进行监控的使用方式,我们所需要做的就是告知插件对应实例的最大内存容量,即:

这一参数可以使用人类友好的单位表示方式表示数值。

同时设定阈值需要使用 -m 参数,即:

即通过逗号分隔 warncritical 两个级别的报警阈值。如同手册所说的,必须与 -M 同时使用。

我们所需要做的就是在 /nip/etc/objects/commands.cfgnipnagios安装目录的缩写,根据实际情况决定)中新增或者修改一个命令:

同时在 /nip/etc/conf/services.cfg 中使用这一命令:

当然,也可以修改插件完成。

以上。

使用Nagios监控Redis

近期新上项目之后出现了后台服务的一些诡异的问题,追查之后发现居然有个Redis的实例把分配的几十G内存给用满了……

终于意识到之前“土法炼钢”的不科学的地方,惭愧之余迅速的想要给Redis加上基本的监控。

最初的想法是直接自己写脚本轮询各个实例的info信息,然后自行parse,当前运行Redis的实例不多,感觉工作量并不大,然而这时候想起组内之前的监控是在用Nagios,觉得为什么不让更专业的软件来完成这项工作呢?于是决定通过Nagios来完成监控。

以下会使用/nip指代Nagios的安装路径,以实际安装路径为准。

Nagios配置

Nagios分为Server和Client,通过各个插件完成对Client的监控,并且在Server中收集展现。

既然运用了Nagios,自然就要按照它的设计思路来进行使用,其实也就是使用合适的插件,同时也不想再造轮子,Google之后确定使用这一项目中的check_redis.pl插件(然而这一文件自2013年7月之后没有过更新了……),这一插件从功能上基本上满足了我对使用内存连接数key个数特定队列长度的监控需求。

这一插件基本上是帮助完成了从redis-cli -h host -p port infoNagios的收集展现过程,所以本身只要在Server上安装即可。

安装插件

安装插件本身并不复杂,只需要download & copy即可,即copy到/nip/libexec目录,并chmod +x赋予可执行权限即可。

然而,真正头疼的是这个插件的依赖安装,由于在服务器上初始化cpan的工作始终无法完成,无奈之下只好通过手工安装依赖。

这一插件的依赖分别是:

  • ExtUtils-MakeMaker
  • IO-Socket-Timeout
  • Try-Tiny
  • Redis

可以在cpan的网站上搜索下载tar.gz文件,解压后基本都通过:

这一过程完成依赖的安装过程。

配置Nagios

想要让监控正常的run起来,配置也是很关键的一个因素,个人认为,配置主要针对监控对象以及监控动作。

监控对象

对于监控对象来说,其实就是标明哪台Server上有着对应的服务,同时还可以对他们进行分组。

监控对象的声明,可以在/nip/etc/conf/hosts.cfg中的对应Server配置中增加一个别名,如:

声明的别名会在报警邮件中得以展现。

同时,需要在/nip/etc/conf/hostgroups.cfg中,为这一批机器分组,以便对一组实例完成监控。

监控动作

对Redis监控,首先要保证Redis实例可访问,不过这一点不用特别配置Nagios,我们需要做的只是针对我们关心数值,进行声明以及配置报警阈值即可。

首先需要在/nip/objects/commands.cfg中配置一个检查指令:

以上参数的含义可以通过/nip/libexec/check_redis.pl --help查看详情:

上述command的含义为针对主机$HOSTADDRESS$的指定端口$ARG1$,检查参数为$ARG2$(可以对照redis-cli info),在$ARG3$设定WARNING级别告警的数值,在$ARG4$设定CRITICAL级别告警的数值,同时生成数据(-f)。

在配置完监控指令之后,还需要针对之前的已经声明的主机组配置使用监控指令进行监控,在/nip/etc/conf/services.cfg增加一项配置:

此处根据个人的实际业务情况,当使用的内存超过28G(30064771072 = 40 * 0.7 * 1024 * 1024 * 1024,以下类比)或者key个数超过30w个时会发出WARNING信息,而在当使用36G内存或者key个数超过40w个时,发出CRITICAL警报。

Nagioscheck_command在参数前使用!,之后的数值针对每一个监控属性,~表示不关注,而对应位置的数值则标称各自的报警阈值。

最后

修改了配置之后,Nagios需要重启才能开始执行监控,那么为了防止因为修改配置而出错,需要通过Nagios先行检测配置文件的正确性:

Nagios的报错信息非常详细,基本可以直接定位到出错的行数。

检查正确之后自然就是重启,等待数据的到来。