【Zabbix】 ZBX的豆知识

chenqb

　　ZBX
　　ZBX虽然看上去是个很庞大的系统，但是相对架构还是比较简单的，而且我接触比较长时间了，很多东西觉得没有什么记的必要，所以以这种零碎的形式来记录一些小知识点。
　　■　　ZBX用户权限问题
　　ZBX用户分成三个等级，Zabbix Super Admin，Zabbix Admin和Zabbix User，其权限由大至小。
　　Super Admin可以统治全局，查看所有主机组的所有主机的配置和数据（配置指的是Configuration里的设置，而数据自然是Monitoring-Latest data里的数据了）。同时SuperAdmin还可以给任何一个用户重设密码，加减权限等。因为对所有主机都有读写权限，所以任何主机出问题了也会默认给SuperAdmin报警。这通常不符合业务逻辑（一个产品线的报警只要报给这个产品线的负责人就可以了），所以一般情况下，一个系统只要有一个SuperAdmin并且不要设任何接受报警的媒体就可以了。
　　Admin用户对他掌控下的主机有配置和看数据的权限，因为ZBX里面，一个用户对哪些主机有权限取决于这个用户所处的用户组（SuperAdmin除外，不论在哪个组都对全局有权限），所以Admin其实是组长一样的角色。Admin用户有权修改自己组主机的监控配置。
　　User用户是普通用户，只对自己组的主机有看数据的权限，不能进行监控配置，界面上根本没有Configuration这个按钮。
　　■　　Admin用户忘记密码了怎么办
　　一般用户忘记密码可以用Admin登录来强行更改密码，如果是Admin用户忘记了密码，就只能到数据库里去修改记录了。
　　数据库中有users表，记录着所有跟zabbix用户相关的信息。可以执行以下SQL重置Admin用户的密码：
　　

update zabbix.users　　

set passwd = md5('123456')    /*123456可以替换成任何默认密码*/　　
where alias='Admin';
　　

　　■　　关于维护期设置的正确姿势
　　今天才发现，之前所有做过的维护期设置其实都是无效的。。我只是在Confituration-Maintainance里添加了一条active的maintainance再关联了一些主机/主机组，并没有创建period，所以维护期并没有执行。正确姿势是在设置完维护期名字，种类，活跃时间等信息；以及完成主机&主机组的关联之后：

　　还要进行period的设置，各项参数也都是顾名思义，不多说了：

　　设置结束之后，主机列表里的相关主机的Status字段会从enabled变为In maintainance，这才表示这个主机正式进入维护状态了。
　　值得一提的是，对于体量比较大，主机比较多的监控体系，从Enabled变成In maintainance这个过程有点慢的，耐心等待一下吧。
　　■　　对本机的监控
　　在一般配置情况下，似乎不能有效地对127.0.0.1这个IP进行监控。也就是说，即使想要监控服务器上面部署的一些东西，或者以本ZBX服务器为节点去监控一些数据，那在WEB配置的时候，相关主机的IP一定要写本机的非127开头的IP。
　　■　　进行自定义脚本告警时需要注意，即使脚本运行是出错了，只要到了脚本运行这一步，Zabbix就会认为已经做到了sent告警信息，在日志里可以查到是sent状态。但其实脚本都出错了怎么可能还会sent了呢。这一点需要特别注意！！！
　　至于脚本可能出了什么错就要具体情况具体分析了。今天又碰到了配置文件没写绝对路径导致GG的情况。看来把配置文件的信息和验证写在if __name__ == "__main__"外面是一个很不好的习惯呐，以后改过来！
　　■　　关于system.uptime这个key
　　这个key是监测了系统的uptime作为指标，在zabbix自带的os linux template里面对这个指标有一个trigger，就是当本次取值比上次取值小的时候就认为系统是重启了。这个trigger还被定义成了info级别的警报。但是uptime并不一定重启时才会发生trigger指定的情况。比如昨晚一台服务器重装了系统，却在今早莫名其妙报了重启的警，但是实际上，从zabbix的角度来看重装这个动作，包含了重启+删zabbix_agent两个动作。重启意味着uptime置零，而删了agent导致这个置零的情况无法告警，只能在重装之后报出cannot reach zabbix_agent这个警。而直到今天早上我重新启动了zabbix_agent之后，收集到了一个远小于重装前的uptime，这个uptime虽然不是零但是仍然出发重启告警，因此在早上告了那个警。
　　■　　客户端主动模式监控
　　一直以来都知道Zabbix支持客户端主动推数据，然而一直以来也都没用过。在我们这边的实践，改成主动模式主要就是要修改配置文件然后重启客户端进程。配置文件可以考虑在zabbix_agent.conf中加上include=/path/to/zabbix_agentd.conf。然后再在zabbix_agentd.conf中加上相关的一些配置比如ServerActive要指出推数据指向的服务端的IP，Hostname指出的是服务端的名字。据说要和某个值必须一致，但是我好像使用默认的Zabbix server就是可以的。。RefreshActiveChecks指出了客户端会隔多少时间去询问服务端要推送哪些item的数据，这个配置比较坑，最大可以配置3600，也就是说你新配置一个zabbix agent(active)类型的item之后，最多可能要等将近一个小时才能再web界面上看到客户端那边推过来的数据。好几次我取不到数据百思不得其解，最后发现原来是这个配置项的锅。。
　　■　　日志监控简介
　　日志监控是Zabbix一个比较重要的功能，其一定要是主动模式的监控。主要分成了两个key即log和logrt。两者的区别在于第一个参数是指定的一个文件名还是可以是一个正则表达式。比如log[/opt/zabbix.mon] 和 logrt[/opt/.+\.mon]就是体现区别了。后者会监控/opt下所有.mon文件的变化情况并记录下来，前者则只针对zabbix.mon这一个文件。　
　　日志监控之所以比自定义的文件监控脚本好用的一点在于它会自动记录上一次日志写到什么地方，从而在新一次的数据采集中只推送上一次取样到这一次取样这段时间内新增的日志数据。
　　默认情况下zabbix采集到的日志数据会一条不落原原本本地推送到服务端，也可以配置log以及logrt的第二个参数regexp。顾名思义这是一个正则式，其作用是对采集到的日志记录逐行遍历，符合正则式的才会被推送出来，另外log和logrt的最后一个参数可以匹配这个正则式中的子模式，使客户端不仅在推数据的时候在行的层面上有一个过滤，在行内也可以控制只输出一部分内容。需要注意的是这两个参数都要加引号，否则不会生效。例子：log[/opt/zabbix.mon,"(.*)\|4\|$",,,skip,"\1"]。至于其他的参数的意义各是什么，网上资料很多，官方也有说明就不多说了
　　■　　Zabbix的默认Graph的正确查看方法
　　就是看呗。。不过trends和history还是有些不一样的。history就是有一说一的采集到的监控元数据，其表现通常是上下起伏波动大的，毛糙多的（对于监控间隔比较小的Item来说）。然后就是trends，trends一般是history设置的保存天数之前的，比如设置保存history七天，那么七天前的Graph就变成了trends，然后trends这个图上有三条线，zabbix根据history的数据对每小时的数据进行聚合，挑出最大值、平均值和最小值，分别对应trends图上的粉红线，深绿线，浅绿线。