一、概述
由于工作关系很久没有更新博客了，本文基于生产配置，是zabbix系列的另一补充；本次要讲的是zabbix Low-level discovery简称（LLD），我们在配置items（监控项）时，有时需要对类似的Items进行添加，换句话说，多台机器上的某一监控具有类似的items,如系统开放的服务，再如磁盘分区，网卡名称等，后两种zabbix已经自带，今天我们以自定义监控每个系统开放的服务来说明 LLD的使用逻辑;
和普通items获取不同的是，LLD 脚本在获取返回时，格式必须是json形式;
和自动发现不同的是，自动发现通过网络发现设备;而LLD是针对主机或模板中用来自动发现定义的items和添加触发器和图形的;
本次测试操作基于zabbix3.4.4 本文中的相关脚本和模板下载
二、LLD脚本
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 'ntt{'
printf ""{#PRO_NAME}":"iptables"}" #必须要添加的iptables
printf ","
for ((i=0;i<$length;i++))
do
printf 'ntt{'
printf ""{#PRO_NAME}":"${proarray[$i]}"}"
if [ $i -lt $[$length-1] ];then
printf ','
fi
done
printf "nt]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很类似;
1、创建模板
进入web端;单击 配置–模板–配置模板–创建模板– 这里模板名叫 “Ickey Services status” –创建应用集(“Services_status”) 如图：
2、创建自动发现规则（LLD）
如上图点自动发现规则在模板中创建 自动发现规则 — 创建自动发现规则 如图：
这里需要注意的是 键值： servies.scan 即item 是在2.3小节的配置文件中定义的，不可乱写
再配置上图中的过滤器 配置变量（宏）如图：
此处的{#PRO_NAME}就是上面2.1节中脚本返回的变量; — 保存
3、创建 配置 监控项原型
如图：
填写名称，等相关信息如图：
此处需要注意的$1 和键值 是 2.3 定义items中的$1 也即是服务名; 保存;
4、创建触发器类型
如图：
说明：触发器名称：即是 “服务名” is down
表达式的意思就是 当发现某服务返回的值不是 1时发出警告
保存 这个 模板中的自动发现规则 就完成啦
但是这里存在一个问题，当我们机器上yum工具时，会在/var/run下生成yum.pid这样就会侦测到一个新服务，yum，但yum执行完后yum.pid会被删除，此时触发器就会报yum is down，为了解决这类问题，我们可以修改触发器报警策略，修改成如下：
意思就是，最后状态不是1 同时一小时前的状态是1;这样那此在/var/run生成临时pid的程序就不会被触发;
接下来就是在主机上应用模板，可以批量添加;这里就忽略了;
5、测试
看下效果图：
可以看到此主机应用了模板后已经可以拿到监控项数据了，我们来关闭这台主机的防火墙服务试试，看看触发器是否正常;
如图：
再把iptables服务启动
可以看到服务关闭和启动可以报警与恢复;至此自动发现服务已经可以正常使用啦！通过这个实例，希望大家能理解自动发现规则的原理逻辑！本文基于生产故有些截图带有涂;主要用于备忘与分享，如有错误之处欢迎留言！
