Zabbix⾃定义监控项（模板）
虽然Zabbix提供了很多的模板（简单理解为监控项的集合），在zabbix界⾯点击share按钮就可以直接跳到模板⼤全的官⽅⽹站，但是由于模板内的监控项数量太多不好梳理且各种模板质量参差不齐，还是建议针对⾃⼰要监控的主机或产品⾃定义模板（Linux服务器主机的监控使⽤默认模板就可以）。
之前⼀篇笔记描述了如何安装和配置zabbix架构，详见：，本⽂分四个⼩节描述如何⾃定义监控项：
⽂章概述
⾃定义模板的步骤
如何配置告警
监测数据的可视化
⼀、⽂章概述
什么是模板？模板就是⼀系列定义好了的监控项+触发器的集合，例如zabbix定义了Linux OS的监控模板，可以监控Linux的系统状况。官⽹也提供了很多常见模板的下载。
我把zabbix的模板⼤致分三类：
zabbix⾃带的内置模板，这类模板不但有官⽅定义的item key和trigger，还内置了获取item value的命令。最典型的就是Linux OS的监控，这个模板的⼤多数监控项⽆需你⾃⼰配置监控信息的获取命令，即插即⽤。
zabbix提供的常⽤模板，此类模板zabbix只是为你定义好了监控项的key和key的数据类型（key只有unsigned number，float，character，log，text五种类型），并未提供内置的item value获取功能，需要你⼿动为这些key编写获取监控信息的命令。
⾃定义的模板，此类模板是完全由⽤户⾃⼰创建的模板，你可以⾃定义个性化的key名字和返回类型，并通过特定的命令或脚本或应⽤提供的接⼝去获取监控信息。
linux系统是哪个个⼈推荐的是针对特定的产品⾃⼰创建特定的模板，这样才能实现灵活定制。你可以选择import⽹上提供的各种模板，也可以将⾃⼰搞的模板export出去供他⼈使⽤。
本⽂以监控mysql QPS为例，⾃⼰定义⼀个mysql的监控模板（zabbix有mysql的监控模板，本例只是为了⽰例）。
⼆、⾃定义模板步骤
1.创建模板
模板名称⾃定义为MySQL_MONITOR,⾪属的主机组选择Templates/Databases就好(或都不选择)，属于哪个主机组不影响使⽤，模板是对任意主机组内的主机可⽤的。
⽽且主机组不⽌可以表⽰主机的集合，也可以⽤于表⽰模板的集合，你可以创建⼀个名为DATABASE_TEMPLATES的虚拟主机组，专门⽤于存放⾃⼰编写的各种数据库的模板，例如mysql,mongo,oracle等的监控模板。
2.创建模板内的监控项
下⾯就是建好的模板，可以看到模板主要包含items，trigger等对象，其他的暂不需要太多关注。
由于我们就是⽤于监控mysql的，因此这个模板内没必要建applications(applications是⽤于对items分组的)，直接建个item，这⾥只需要定义个name和key以及type就好了：
type⼀般选择zabbix agent或zabbix agent(active)，现在⼀般后者居多因为可以进⾏active check减少server压⼒，只需要在agent端配相关的active check项即可。
特别提⽰：如果你的server端版本远⾼于agent端，那么建议item的类型选择zabbix agent，主动式的item可能会有BUG（遇到过获取的数据异常的问题），即便确认⾼版本服务端兼容低版本客户端，但保险起见还是版本⼀致的好。
此时在看MySQL_MONITOR模板就会发现多了⼀个监控项（item）。
3.获取监控值
监控项已经建好了，怎么从客户端获取监控信息呢？⾸先需要修改agent端的配置⽂件并重启agentd：
vi f
UserParameter=mysql.qps,mysql -uleo -pleo -e "show global status like 'Queries'"|grep Queries|awk '{print $2}'
UserParameter的格式是固定的，有以下两种：
UserParameter=key,command
UserParameter=key[*],command
其中第⼀种很好理解，key就是你定义的监控项key，本例中就是mysql.qps，command就是获取监控信息的命令，本例中就是mysql -uleo -pleo -e "show global status like 'Queries'"|grep Queries|awk '{print $2}'
第⼆种是第⼀种格式的进阶版，允许你为command提供输⼊参数，这⾥都是位置传参的可以定义从$1-$
9的9个参数，这种格式的好处在于你可以使⽤⼀个接受位置传参的脚本获取多个监控值，⽽不⽤为每个监控项都写⼀个获取监控值的脚本。
4.为主机添加监控项
监控项设置好之后，只需要把监控项加⼊主机即可，这样就可以实现对主机对应item的监控。
⼀般来说可以直接在主机界⾯create item，但是本例为了⽅便演⽰如何集成监控项到模板使⽤的是template，因此直接把模板应⽤到主机即可。注意下图要点击add然后update才能更新主机所⽤的模板们。
5.查看监控数据
如果获取监控值的脚本或命令运⾏正常，且返回值与key type⼀致，那么现在在仪表板的latest data就可以看到监控的值了：
6.完善监控项
当前监控的mysql qps其实只是queries并没有p(er)s(econd)，如果⽤queries/uptime得到的也只是⼀个平均QPS，⽽我们⼀般想要监测的都是类似于过去30s平均qps这种更有意义的值，如果要⽤脚本或者程序脚本来获取的话⼯作量就⼤了，⽽⽤zabbix很简单。
我们去item的界⾯进⾏修改(如果很熟悉要监控的产品的话其实创建模板时就可以为item设置preprocessing)：
只需要对获取的监控值做预处理就可以了，我们选择change per second,zabbix server就会⾃动将持续获取的监控值们进⾏处理，得到⼀个每秒均值，由于我们的qps收集间隔是30s，最终得到的qps就是过去30s数据库的平均qps。
现在再去看latest data看到的就是qps的30秒平均值了，更多地数据预处理步骤的解释可以参考官⽹链接：
三、告警配置
在第⼆步中描述的是如何设置模板及监控项，那么在监控项超过阈值之后如何进⾏告警呢？涉及的zabbix组件主要有3个：trigger,action,media type，此外还涉及到user实体。
1.如何设置触发器？
我们直接在模板中添加触发器，触发器的触发条件可以是⼀个监控项超过阈值或多个监控项超过阈值的逻辑联合条件，本例只演⽰mysql.qps超过阈值的告警。
红⾊箭头标出的就是需要注意的地⽅，其中severity可以选择告警的严重性（没其他作⽤，仅仅是标⽰这个告警有多重要的），本例选择当监控值超过0.2时就告警......使⽤expression constructor还可以实现条件的逻辑联合，例如AND，OR等。
2.查看告警效果
默认告警信息是直接显⽰在dashboard的，我们到mysql⾥噼⾥啪啦⼀顿操作把qps拉上来，然后去仪表板看下：
可以看到告警信息了，他会告诉你这个告警持续的时间，如果问题被解决，那么告警会变为绿⾊，并在
仪表板显⽰⼀段时间后消失：
3.设置邮件告警
默认告警只显⽰到仪表板，如果想要实现短信或邮件告警还需要额外配置组件。
3.1创建media type并添加到user
默认zabbix⾃带了email,jabber,sms媒体类型，你只需要在-Media types下进⼊Email项，填写好SMTP的相关信息，并根据SMTP服务器的类型选好验证模式即可，不过我这⾥为了加⼀种media type来演⽰，选择新建脚本类型的media type，使⽤linux⾃带的sendmail或者⾃⼰编写SendMail.sh脚本来发送邮件。
上述的3个参数是zabbix预定义的3个宏，有这3个宏⾜够了，我们在使⽤脚本发送邮件时只需要按顺序把脚本的输⼊参数设置为这3个参数即可。如果你⽤的邮件发送脚本的参数不是此顺序，那么⽤shell再包装⼀层即可，确保脚本输⼊参数是这3个。
Ps:Zabbix内置的完整宏列表参见：
关于宏使⽤的⼀些提⽰：
获取trigger被触发时的item value可以使⽤宏{ITEM.LASTVALUE}，如果触发器内有多个item的触发条件，那么可以使⽤{ITEM.LASTVALUE<1-9>}定位具体是哪个item，1-9是指item在trigger中出现的顺序，最多9个，例如{ITEM.LASTVALUE1}
内置宏并⾮在所有情况下可⽤，曾经遇到过官⽹⽀持的版本下某些内置宏获取不到值的BUG，例如3.4版本时{TRIGGER.SEVERITY}宏在trigger name中不可⽤，但是在邮件中可⽤，后来猜测是因为SEVERITY 本⾝是trigger的⼀个属性，在trigger未实例化之前不能调⽤⾃⾝的属性。如果在action中调⽤trigger的各种宏就不会出错了。
除了正常的内置宏外，zabbix还⽀持⽤户⾃定义宏和底层的发现规则宏(LLD)，分别为{$MACRO}和{#MACRO}的表⽰格式，其中：
关于⽤户⾃定义宏的创建参照
关于如何在模板的⾃动发现规则中定义LLD宏，参照
模板的discovery rules的本质其实是⼀个⼦模板，其中定义了⼀系列的item、trigger、graph等对象的prototypes。这些prototypes（即原型）都是使⽤发现规则宏定义的，本质上是⽤宏变量代替要监控的具体对象。例如常规的监控项可以将key命名为linux.fs[/root]来监控/root⽬录，但是如果要监控N多⽬录呢，我们要建N个item吗？不，有了discovery rules和[low level]discovery macros(LLD)我们就可以只定义⼀个discovery
rules，prototypes所引⽤的具体⽬录可以⽤宏{#FSNAME}来代替，即linux.fs[{#FSNAME}]这样⼀个item prototypes就可以满⾜所有⽬录的监控，我们只需要使⽤提前定义好的脚本获取⼀系列的键值对，其中键就是我们的LLD宏，⽽值就是获取的⼀系列要监控的⽬录名，脚本输出需要如下所⽰：
{
"data":[
{ "{#FSNAME}":"/", "{#FSTYPE}":"rootfs" },
{ "{#FSNAME}":"/sys", "{#FSTYPE}":"sysfs" },
{ "{#FSNAME}":"/proc", "{#FSTYPE}":"proc" },
{ "{#FSNAME}":"/dev", "{#FSTYPE}":"devtmpfs" },
{ "{#FSNAME}":"/dev/pts", "{#FSTYPE}":"devpts" },
{ "{#FSNAME}":"/lib/init/rw", "{#FSTYPE}":"tmpfs" },
{ "{#FSNAME}":"/dev/shm", "{#FSTYPE}":"tmpfs" },
{ "{#FSNAME}":"/home", "{#FSTYPE}":"ext3" },
{ "{#FSNAME}":"/tmp", "{#FSTYPE}":"ext3" },
{ "{#FSNAME}":"/usr", "{#FSTYPE}":"ext3" },
{ "{#FSNAME}":"/var", "{#FSTYPE}":"ext3" },
{ "{#FSNAME}":"/sys/fs/fuse/connections", "{#FSTYPE}":"fusectl" }
]
}
这样discovery rules的prototypes就会遍历{#FSNAME}，⾃动为所有检测到的⽬录创建item、trigger、graph等。
接下来继续说为⽤户添加media type:
在media type创建完毕后需要为user添加媒体类型，其中NIWAHD（Not classified,Information,Warning,Average,High,Disaster ）是问题严重程度的英⽂⾸字母，邮件告警发送的email地址也是在user实体这⾥配置的：
3.2创建action
建好了media type，并为⽤户添加上就完事了吗？不，那只是提供了邮件发送的功能和通道，为了实现监测值异常告警还需要添加action，所谓action就是当触发器被触发时，告警不⽌显⽰在仪表板，还会通过邮件告警媒介将特定的信息发送给指定的user实体。
⼀个功能完整的action可以按上图的⼩标题分3部分（第4个忽略）：action condition，operations和recovery operations，分表表⽰动作触发的条件，触发后的具体操作，问题恢复时的操作。
上边的message可以⾃定义的更丰富些，可以⽤中⽂编写，配置完之后需要点击add按钮添加，本图只是展⽰如何配置。其中{}括起来的都是zabbix的宏。
拓展：关于operations中的steps(操作步骤)和step duration(操作步长)
步长是操作步骤的执⾏间隔，⽽step(操作步骤)是在operation details中定义的，step数字只是代表执⾏的优先度。
例如你可以建多个operations，每个都是step 1，那么当告警触发时这些step为1的操作就会被全部即时执⾏，你还可以在⼀个operation中将steps设为1-3，那么这个operation就会每隔⼀个操作步长执⾏⼀次共执⾏3次停⽌。
你还可以设置了step1、step3，那么执⾏完step1之后就会经过两个步长的时间继续执⾏step3，每个步骤都可以⾃定义不同的操作和操作步长（⾃定义的操作步长为0表⽰默认使⽤统⼀的操作步长1h）。
需要注意的是action并没有执⾏周期，即⼀个触发器类型的action只会执⾏⼀次，如果需要在问题解决之前每隔⼀段时间发出⼀次告警只能通过将action的operation step设为1-0来解决（0表⽰⽆限次数即每隔1⼩时执⾏⼀次action operation）。
发表评论