标签:gre web proc ret 系统服务 技术 关系 src 运维
一、概述由于工作关系很久没有更新博客了,本文基于生产配置,是zabbix系列的另一补充;本次要讲的是zabbix Low-level discovery简称(LLD),我们在配置items(监控项)时,有时需要对类似的Items进行添加,换句话说,多台机器上的某一监控具有类似的items,如系统开放的服务,再如磁盘分区,网卡名称等,后两种zabbix已经自带,今天我们以自定义监控每个系统开放的服务来说明 LLD的使用逻辑;
和普通items获取不同的是,LLD 脚本在获取返回时,格式必须是json形式;
和自动发现不同的是,自动发现通过网络发现设备;而LLD是针对主机或模板中用来自动发现定义的items和添加触发器和图形的;
本次测试操作基于zabbix3.4.4 本文中的相关脚本和模板下载
1、获取开放的服务
任何获取items都要基于程序脚本,LLD发现也不例外,以下是获取系统开放服务脚本discovery_services.sh
# cat /usr/local/zabbix-3.4.4/scripts/discovery_services.sh
#!/bin/bash
proarray=($(find /var/run/ -name "*.pid" 2> /dev/null||egrep -v ‘(rpc|php_daemon|haldaemon|irqbalance|console-kit-daemon)‘ |awk -F‘/‘ ‘{print $NF}‘|awk -F‘.‘ ‘{print $1}‘)) # 排除不监控的服务
length=${#proarray[@]}
printf "{\n"
printf ‘\t‘"\"data\":["
printf "\t"
printf ‘\n\t\t{‘
printf "\"{#PRO_NAME}\":\"iptables\"}" #必须要添加的iptables
printf ","
for ((i=0;i<$length;i++))
do
printf ‘\n\t\t{‘
printf "\"{#PRO_NAME}\":\"${proarray[$i]}\"}"
if [ $i -lt $[$length-1] ];then
printf ‘,‘
fi
done
printf "\n\t]\n"
printf "}\n"
说明:以上脚本基于 /var/run下的pid进行监控开放的服务,所以如果是公司运维人员自已经开发的管理脚本服务,pid文件请按默认的放到/var/run下 ,这样就不会漏掉,再说大部分系统或知名程序都遵守这一规定,你为什么不能遵守呢?
在一台监控机器上执行如下:
记住这里的{#PRO_NAME} 这个就是自动发现规则中的宏变量;另外这个脚本返回的是json格式;
2、检查系统状态
对获取的服务进行检查
# cat /usr/local/zabbix-3.4.4/scripts/program_status.sh
#!/bin/bash
procjetName="${1:-NULL}"
LOCK_PATH="/var/lock/subsys"
RUN_PATH="/var/run"
ret_ok=1
ret_critical=3
ret_unknown=4
if [[ ${procjetName} == "NULL" ]] ; then
echo ${ret_unknown}
fi
if [ -f "${LOCK_PATH}/${procjetName}" ] || [ -f "${RUN_PATH}/${procjetName}.pid" ] || [ -f "${RUN_PATH}/${procjetName}/${procjetName}.pid" ] ; then
echo ${ret_ok}
else
echo ${ret_critical}
fi
以上脚本检查如果服务存在则返回1 否则返回 3 ,如果服务不存在则返回4
检查的原则就是在/var/run/下是否有和服务同名的pid文件存在,或/var/run/服务/服务.pid存在,对于像iptabls这种则检查 /var/run/subsys/服务.pid 三种情况满足一种即可;
运行效果如下:
对iptables服务检查 返回 1说明 iptables正常
关闭iptables 再次进行检查:
而对httpd服务进行检查,由于本机根本没有httpd服务,所以返回的是3
3、定义items
# cat /usr/local/zabbix-3.4.4/etc/zabbix_agentd.conf.d/LLD_Services.conf
UserParameter=services.scan,/bin/bash /usr/local/zabbix-3.4.4/scripts/discovery_services.sh
UserParameter=services.status[*],/bin/bash /usr/local/zabbix-3.4.4/scripts/program_status.sh $1
这里需要在web页上添加,和添加items很类似;
进入web端;单击 配置--模板--配置模板--创建模板-- 这里模板名叫 “Ickey Services status” --创建应用集("Services_status") 如图:
如上图点自动发现规则在模板中创建 自动发现规则 -- 创建自动发现规则 如图:
这里需要注意的是 键值: servies.scan 即item 是在2.3小节的配置文件中定义的,不可乱写
再配置上图中的过滤器 配置变量(宏)如图:
此处的{#PRO_NAME}就是上面2.1节中脚本返回的变量; -- 保存
创建 配置 监控项原型 如图:
填写名称,等相关信息如图:
此处需要注意的$1 和键值 是 2.3 定义items中的$1 也即是服务名; 保存;
创建触发器类型
如图:
说明:触发器名称:即是 “服务名” is down
表达式的意思就是 当发现某服务返回的值不是 1时发出警告
保存 这个 模板中的自动发现规则 就完成啦
接下来就是在主机上应用模板,可以批量添加;这里就忽略了;
看下效果图:
可以看到此主机应用了模板后已经可以拿到监控项数据了,我们来关闭这台主机的防火墙服务试试,看看触发器是否正常;
如图:
再把iptables服务启动
可以看到服务关闭和启动可以报警与恢复;至此自动发现服务已经可以正常使用啦!通过这个实例,希望大家能理解自动发现规则的原理逻辑!本文基于生产故有些截图带有涂;主要用于备忘与分享,如有错误之处欢迎留言!
zabbix自定义自动发现服务(low-level-discovery)监控系统服务
标签:gre web proc ret 系统服务 技术 关系 src 运维
原文地址:http://blog.51cto.com/dyc2005/2178939