Zabbix 自动发现(LLD )

本文介绍了Zabbix自动发现(LLD)功能,其可按规则自动配置不确定数量的监测项。以服务器进程CPU和MEM使用情况监测为例,详细说明了实现步骤,包括编写获取服务名、进程CPU和MEM占用脚本,配置监测项,在模版上创建发现规则、项目原型和图形原型等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Zabbix 自动发现(LLD)

LLD : Low-level discovery

官网文档: https://www.zabbix.com/documentation/4.0/manual/discovery/low_level_discovery

作用: 可以指定规则(rule),来达成不确定数量的监测项的自动配置生成

自定义 LLD 规则, 参见上官网文档中的 Creating custom LLD rules 节,比较有用

比如使用 zabbix 实现服务器进程 CPU 、 MEM 的使用情况,则使用 LLD 较为合适

实际例子

在这里插入图片描述
如上图, Server CPU all 图表,服务进程数量等开好时才确定。下次开可能又不一样

下面,使用 LLD 来实现上述图表

1. 编写获取服务名脚本

例如 kgetserver.sh

#!/bin/bash
echo '{"data":['
n0=`ps -aux | grep Server | grep -v grep | grep -v $0 | grep -v kgetcpu | grep -v kgetmem | grep -v tail | wc -l`
ps -aux | grep Server | grep -v grep | grep -v $0 | grep -v kgetcpu | grep -v kgetmem | grep -v tail | awk -v n=$n0 '{printf "{\"{#PROCESSNAME}\":\"\\\"";for(i=11;i<=NF;i++){printf $i;if(i<NF)printf " "};printf "\\\"\"}";if(NR<n)printf ",";printf "\n"}'
echo ']}'

执行可输出:

{"data":[
{"{#PROCESSNAME}":"\"./MgrServer.dbg\""},
{"{#PROCESSNAME}":"\"./LogServer_Ex.dbg\""},
{"{#PROCESSNAME}":"\"./RecordServer_Ex.dbg --stderrthreshold 0 --log_dir ../log -s 1\""},
{"{#PROCESSNAME}":"\"./RecordServer_Ex.dbg --stderrthreshold 0 --log_dir ../log -s 2\""},
{"{#PROCESSNAME}":"\"./RecordServer_Ex.dbg --stderrthreshold 0 --log_dir ../log -s 3\""},
{"{#PROCESSNAME}":"\"./RecordServer_Ex.dbg --stderrthreshold 0 --log_dir ../log -s 4\""},
{"{#PROCESSNAME}":"\"./RecordServer_Ex.dbg --stderrthreshold 0 --log_dir ../log -s 5\""},
{"{#PROCESSNAME}":"\"./RecordServer_Ex.dbg --stderrthreshold 0 --log_dir ../log -s 6\""},
{"{#PROCESSNAME}":"\"./ProxyServer_Ex.dbg\""},
{"{#PROCESSNAME}":"\"./RedisSyncServer_Ex.dbg -s 1\""},
{"{#PROCESSNAME}":"\"./RedisSyncServer_Ex.dbg -s 2\""},
{"{#PROCESSNAME}":"\"./RedisSyncServer_Ex.dbg -s 3\""},
{"{#PROCESSNAME}":"\"./RedisSyncServer_Ex.dbg -s 4\""},
{"{#PROCESSNAME}":"\"./RedisSyncServer_Ex.dbg -s 5\""},
{"{#PROCESSNAME}":"\"./RedisSyncServer_Ex.dbg -s 6\""},
{"{#PROCESSNAME}":"\"./RobotServer_Ex.dbg\""},
{"{#PROCESSNAME}":"\"./LoginServer.dbg --stderrthreshold 0 --log_dir ../log -s 1\""},
{"{#PROCESSNAME}":"\"./LoginServer.dbg --stderrthreshold 0 --log_dir ../log -s 2\""},
{"{#PROCESSNAME}":"\"./LoginServer.dbg --stderrthreshold 0 --log_dir ../log -s 3\""}
]}

本脚本就是 rule ,通过本脚本可以找到要监测的服务项

再比如 kgetproc.sh

#!/bin/bash
echo '{"data":['
n0=`ps -aux | grep $1 | grep -v grep | grep -v $0 | grep -v kgetcpu | grep -v kgetmem | grep -v tail | grep -v defunct | wc -l`
ps -aux | grep $1 | grep -v grep | grep -v $0 | grep -v kgetcpu | grep -v kgetmem | grep -v tail | grep -v defunct | awk -v n=$n0 '{printf "{\"{#PROCESSNAME}\":\"\\\"";for(i=11;i<=NF;i++){printf $i;if(i<NF)printf " "};printf "\\\"\", \"{#PROCESSPID}\":";printf $2;printf ",\"{#PROCESSNO}\":"; printf NR; printf "}";if(NR<n)printf ",";printf "\n"}'
echo ']}'

执行可输出:

[root@host-192-168-21-36 opt]# ./kgetproc.sh codis-server
{"data":[
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23790\"", "{#PROCESSPID}":28381,"{#PROCESSNO}":1},
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23791\"", "{#PROCESSPID}":28486,"{#PROCESSNO}":2},
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23792\"", "{#PROCESSPID}":28523,"{#PROCESSNO}":3},
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23793\"", "{#PROCESSPID}":28576,"{#PROCESSNO}":4},
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23794\"", "{#PROCESSPID}":28597,"{#PROCESSNO}":5},
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23795\"", "{#PROCESSPID}":28633,"{#PROCESSNO}":6},
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23796\"", "{#PROCESSPID}":28671,"{#PROCESSNO}":7},
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23797\"", "{#PROCESSPID}":28707,"{#PROCESSNO}":8},
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23798\"", "{#PROCESSPID}":28735,"{#PROCESSNO}":9},
{"{#PROCESSNAME}":"\"/home/fananchong/go/src/github.com/CodisLabs/codis/admin/../bin/codis-server 127.0.0.1:23799\"", "{#PROCESSPID}":28780,"{#PROCESSNO}":10}
]}
2. 编写获取某进程CPU 、 MEM 占用脚本

比如 kgetcpu.sh

#!/bin/bash

mypid=`ps aux | grep "$1" | grep -v grep | grep -v "$0" | grep -v tail | grep -v defunct | grep -v vi | awk '{print $2}'`
getactive=`top -b n 1 | awk -v v=$mypid '{if($1==v){print $9};}'`
if [[ -n $getactive ]]; then
    echo $getactive
else
    echo "0"
fi

比如 kgetmem.sh

#!/bin/bash

mypid=`ps aux | grep "$1" | grep -v grep | grep -v "$0" | grep -v tail | grep -v defunct | grep -v vi | awk '{print $2}'`
getactive=`top -b n 1 | awk -v v=$mypid '{if($1==v){print $6};}'`
if [[ ""$getactive != "" ]]; then
    if [[ ${getactive} =~ "g" ]];then
        getactive=${getactive%%g*}
        echo "$getactive*1024*1024" | bc
    else
        n=$[getactive*1024];
        echo $n
    fi
else
    echo "0"
fi

以上脚本定义了每个监测项要监测的内容

3. 配置监测项

比如 /etc/zabbix/zabbix_agentd.d/userparameter_mygraph.conf :

UserParameter=myGraph.server_cpu[*],sudo /opt/kgetcpu.sh $1
UserParameter=myGraph.server_mem[*],sudo /opt/kgetmem.sh $1
UserParameter=myGraph.server_process[*],sudo /opt/kgetserver.sh
UserParameter=myGraph.proc[*],sudo /opt/kgetproc.sh $1

重启服务

systemctl restart zabbix-agent.service

剩下的就是使用 zabbix frontend ,在页面上操作了

4. 模版(Templates)上创建 Discovery rule

在这里插入图片描述
类似上图

5. 模版(Templates)上创建 Item prototypes

在这里插入图片描述
类似上图

6. 模版(Templates)上创建 Graph prototype

在这里插入图片描述
类似上图

至此,所有监测项会自动生成

Host 上创建 Server CPU all 图形

(目前是手动创建的,按道理也可以自动生成。 有时间翻翻文档,再补上)

以上

<think>我们正在讨论Zabbix自动发现OLT设备的配置。根据引用内容,我们知道ZabbixAgent部署在被监控目标上,用于收集数据并发送给ZabbixServer。但是,OLT设备通常不支持直接安装ZabbixAgent,因此我们需要通过SNMP来监控。自动发现(Discovery)功能可以自动发现网络中的设备,并对其应用监控项、触发器等。对于OLT设备,我们通常需要自动发现其下联的ONU设备,因为每个OLT下有大量的ONU。步骤概述:1.确保OLT设备已启用SNMP,并记录SNMP版本(如v2c或v3)和认证信息(communitystring等)。2.在Zabbix中创建自动发现规则,使用SNMPOID来发现OLT下的ONU接口。3.创建监控项原型、触发器原型等,以便为每个发现的ONU创建监控项和触发器。具体配置:第一步:准备SNMP信息在OLT上启用SNMP,并确定用于发现ONU的OID。根据引用[3],我们可以通过MIB库查找OID。通常,OLT厂商会提供MIB库,其中包含ONU信息的OID。例如,对于华为OLT,ONU状态OID可能是:.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15(具体以实际MIB为准)。第二步:在Zabbix中创建自动发现规则1.进入Zabbix控制台,选择要监控的主机(即OLT)。2.在该主机上创建自动发现规则:名称:例如“DiscoverONUs”类型:SNMPagentKey:自定义,如discovery.onuSNMPOID:填写用于获取ONU列表的OID。注意,这个OID应该返回一个索引列表(每个ONU一个索引)。3.在“过滤器”中,可以设置正则表达式过滤不需要的项。第三步:创建监控项原型在自动发现规则中,创建监控项原型。例如,创建一个监控ONU状态的监控项原型:名称:ONU{#ONU_INDEX}StatusKey:例如onu.status[{#ONU_INDEX}]SNMPOID:使用发现规则中获取的索引变量{#ONU_INDEX}来构建完整的OID。例如,如果基础OID是.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15,那么完整的OID可能是:.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15.{#ONU_INDEX}(注意:具体OID结构需参考厂商MIB)第四步:创建触发器原型例如,当ONU状态为离线时触发告警:名称:ONU{#ONU_INDEX}isdown表达式:{HOST:onu.status[{#ONU_INDEX}].last()}<>1(假设1表示在线)第五步:测试保存后,Zabbix将定期执行自动发现,发现ONU并创建监控项和触发器。注意:由于不同厂商的OLT的MIB不同,以上OID仅为示例,请根据实际设备替换。引用[3]中提到,我们可以通过Interfaces表来查找接口索引对应的接口信息。在自动发现中,我们也可以利用这个特性,通过另一个OID获取ONU的别名(描述),并作为LLD宏变量,这样在监控项和触发器中就可以使用ONU的名称而不是索引。例如,我们可以创建一个额外的监控项原型来获取ONU的名称,然后将其作为宏变量{#ONU_NAME}。具体方法是在自动发现规则中同时获取两个OID:一个用于索引,一个用于名称。这需要使用“SNMPwalk”或通过Zabbix的“值映射”功能来实现。自动发现规则配置示例(SNMPwalk方式):在自动发现规则的“SNMPOID”中,我们可以指定一个OID,该OID返回的是一系列索引。但是,如果我们想同时获取索引和名称,可以使用OID树。例如,如果我们知道ONU名称的OID基础为.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.2(同样以华为为例),那么我们可以这样设置:自动发现规则的SNMPOID:discover_onu实际上,我们可以通过一个OID获取多个值,然后使用过滤器提取索引和名称。但是,Zabbix自动发现规则支持返回JSON格式的数据,其中包含多个宏变量。因此,我们需要使用“SNMPwalk”并配合JavaScript预处理来构建JSON。然而,更简单的方式是使用Zabbix的“SNMP批量请求”功能,但该功能在自动发现规则中默认不支持。因此,常见的做法是先获取索引列表,然后在监控项原型中通过另一个OID获取名称。另一种方法是:在自动发现规则中,我们只获取ONU的索引(例如,通过OID.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15,该OID返回的每个实例的最后一个数字就是索引)。然后在监控项原型中,我们使用另一个OID(如.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.2.{#ONU_INDEX})来获取该ONU的名称。但是,这样每个ONU都需要一个额外的SNMP请求来获取名称,可能会增加SNMP负载。为了优化,我们可以在自动发现规则中一次性获取索引和名称。这需要编写一个脚本来处理(例如使用外部脚本或Zabbix的预处理)。但是,在纯SNMP方式下,我们可以使用以下技巧:自动发现规则SNMPOID:.1.3.6.1.4.1.2011.6.128.1.1.2.46.1(假设这是ONU表的OID)然后,在预处理中,我们可以使用“正则表达式”或“自定义JavaScript”来解析返回的多个值,并构建一个JSON数组,每个元素包含ONU_INDEX和ONU_NAME。但是,由于操作较为复杂,且需要根据具体设备调整,这里我们使用第一种简单方法:只获取索引,然后在需要名称的地方再单独获取。因此,自动发现规则配置:SNMPOID:.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15(这个OID返回的是每个ONU的状态,但我们可以只取索引部分)返回的数据可能是:.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15.1=1.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15.2=1...自动发现规则将提取索引(即最后一个数字)作为宏变量{#SNMPINDEX}(这是默认的宏)。但是,我们也可以自定义宏名称。在自动发现规则中,我们可以设置:宏:{#ONU_INDEX}值:$1(然后使用正则表达式来提取索引)正则表达式示例:^\.\d+(\.(\d+))$但这样无法匹配整个OID。实际上,Zabbix在解析SNMP返回时,会自动将OID的最后一个数字作为索引?不完全是。另一种方式:在自动发现规则中,我们可以使用“预处理”步骤,选择“正则表达式”,然后设置:模式:^\.\d+\.(\d+)$输出:\1这样,每个返回的OID会被提取出最后一个数字,并作为{#SNMPINDEX}的值。但我们也可以自定义宏。在自动发现规则中,我们定义宏:宏:{#ONU_INDEX}值:{#SNMPINDEX}(因为预处理后,每个值对应的OID的最后一个数字被提取为SNMPINDEX)然后,在监控项原型中,我们就可以使用{#ONU_INDEX}来构建OID。总结:自动发现配置的关键在于找到正确的OID,并理解返回的数据结构。由于不同厂商的OLT差异较大,建议先使用snmpwalk命令在服务器上测试:snmpwalk-v2c-cpublic<OLT_IP><OID>例如,测试ONU状态OID:snmpwalk-v2c-cpublic10.1.1.1.1.3.6.1.4.1.2011.6.128.1.1.2.46.1.15根据返回结果调整自动发现规则。最后,参考引用[1]和[2],我们确保ZabbixServer和Agent的部署正确,并且能够与OLT进行SNMP通信。注意:自动发现规则创建后,可能需要一段时间才能发现设备,可以在“最新数据”中查看。相关问题:1.如何测试SNMPOID是否可用?2.自动发现规则没有发现任何设备,可能的原因是什么?3.如何为自动发现的ONU创建图形?</think>以下是Zabbix自动发现OLT设备的配置教程,结合SNMP协议实现自动发现和管理: ### 一、配置前准备 1. **启用OLT的SNMP服务** 在OLT设备管理界面开启SNMP服务(v2c或v3),设置community string(如`public`)和访问权限[^1]。 2. **获取关键OID** - 接口索引OID:`1.3.6.1.2.1.2.2.1.1`(ifIndex) - 接口描述OID:`1.3.6.1.2.1.2.2.1.2`(ifDescr) - 流量统计OID: - 入流量:`1.3.6.1.2.1.2.2.1.16.{#SNMPINDEX}`(ifInOctets) - 出流量:`1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}`(ifOutOctets)[^3] --- ### 二、Zabbix自动发现配置步骤 #### 步骤1:创建自动发现规则 1. **路径**:`配置` → `主机` → 选择OLT主机 → `发现规则` → `创建发现规则` 2. **关键参数**: ```yaml 名称:OLT Interface Discovery 类型:SNMP agent Key:olt.if.discovery SNMP OID:discovery[{#IFDESCR}, 1.3.6.1.2.1.2.2.1.2] // 获取接口描述 更新间隔:1h ``` #### 步骤2:配置LLD过滤器 ```yaml 过滤器: {#IFDESCR}:正则表达式匹配ONU接口命名规则 示例:.*(PON|ONU).* // 过滤出PON/ONU接口 ``` #### 步骤3:创建监控项原型 1. **入流量监控项**: ```yaml 名称:入流量 - {#IFDESCR} Key:onu.in.traffic.[{#SNMPINDEX}] SNMP OID:1.3.6.1.2.1.2.2.1.16.{#SNMPINDEX} 单位:bps(自动计算速率) ``` 2. **出流量监控项**: ```yaml 名称:出流量 - {#IFDESCR} Key:onu.out.traffic.[{#SNMPINDEX}] SNMP OID:1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX} ``` #### 步骤4:创建触发器原型 ```yaml 名称:ONU {#IFDESCR} 离线 表达式:{host:onu.status[{#SNMPINDEX}].max(5m)}=0 严重性:严重 ``` --- ### 三、验证配置 1. **执行发现**: 在`监控` → `最新数据`中过滤`olt.if.discovery`,查看发现的ONU接口数据[^3]。 2. **故障模拟**: 手动断开ONU,检查是否触发告警。 --- ### 四、优化建议 1. **接口重命名**: 在预处理中使用JavaScript将`{#IFDESCR}`转换为易读名称(如`PON0/1/1` → `OLT1-Slot0-Port1`)。 2. **批量监控**: 对同型号OLT使用模板功能,批量应用发现规则。 3. **性能调优**: 调整SNMP超时为`5s`,避免因响应延迟阻塞进程。 > **注**:不同厂商OLT的OID可能不同,需通过`snmpwalk`命令验证: > ```bash > snmpwalk -v2c -c public <OLT_IP> 1.3.6.1.2.1.2.2.1.2 > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

fananchong2

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值