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可以替换成任何默认密码*/
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__"外面是一个很不好的习惯呐，以后改过来！
再补充一点，zabbix默认通过绝对路径来调用脚本，比如自定义告警脚本是alert.py的话，那么其实际调用方式是/foo/bar/alert.py，而不是python alert.py。对于DOS和unix换行符不一致引起的错误在这种情况下就很容易被忽视了。
■ 关于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图上的粉红线，深绿线，浅绿线。
■ 服务正常运行但web界面无法访问
今天突然遇到了zabbix的这么一个问题，监控数据正常在收集，告警正常在发送，但是web界面就是无法访问。
众所周知，zabbix的网页界面基本上是属于一个LAMP架构的应用（至少在我们使用的老版本上还是）。因此LAMP中的任意一环出现问题都可能导致网页无法访问。
比如今天的场合，首先差了数据库mysql没有出现问题，系统Linux所有表现也都正常。
想着干脆重启下zabbix-server服务吧，果然重启的时候报错找不到libmysqlclient.so.16库。原来上周为了适应另一个应用，将mysql更新到了5.6，由于是通过源码安装，一次性地把原先/usr/lib64下各种关于mysql客户端的库都从16更新到了18。那么该怎么办，如果直接降级客户端库，zabbix能用回来但是另外应用就有问题。好在mysql官方提供了一个叫做MySQL-shared-compat的rpm包。这个包中给出了相关版本Mysql可以用到的所有版本的客户端库。下载(https://dev.mysql.com/downloads/file/?id=476497)来MySQL-shared-compat-5.5.60-1.el6.x86_64.rpm这个包之后可以：
rpm -qpl MySQL-shared-compat-5.5.-.el6.x86_64.rpm
查看这个rpm包中安装的所有文件。
rpm -ivh安装此包之后，到/usr/lib64中看，果然有了从12到16的所有libmysqlclient包。再重启zabbix-server服务。不报错了。
然而还是无法访问web。。。
还剩下一个apache没有排查，于是就查看了/var/log/httpd/下的httpd日志。果然在今天凌晨不知出于什么原因，httpd进行过一次重启。在拉起php的过程中发现了libmysqlclient库的缺失，httpd启动虽然成功，但是后端的php服务（也就是zabbix-server-web服务）其实没有正常启动。虽然刚才我已经重启了zabbix-server整个服务，但是apache还没感知到？ 因此重启了httpd服务，然后终于可以访问了。所以对于这种一环依赖一环的应用，可能会需要将好几个环都重启下，使得变更生效的情况！
■ 安装windows客户端
从zabbix官网下载到了对应版本的windows客户端。
客户端的包中含有bin和conf两个目录。bin下面主要是zabbix_agentd.exe文件，而conf下面只有一个zabbix_agent.win.conf文件，是配置文件。
修改配置文件中的配置之后，和Linux客户端程序不同，Windows中首先要运行zabbix_agentd.exe -i进行安装。然后再zabbix_agentd.exe -s启动服务。另外默认读取的配置文件是c:\zabbix_agent.conf，如果不是这个配置文件，那么和Linux中一样需要加-c参数来指明配置文件的位置。
在进行上述所有命令的操作的时候，一定要保证命令行窗口是通过管理员权限打开的。
如果在操作过程中报错说cannot start service之类的错误，先确认是否是管理员权限打开的cmd。如果确认了还是报错，那么可以先zabbix_agentd.exe -d来删除服务，再重新打开管理员权限的cmd，重新-i安装,-s启动。这样应该就可以了。
安装完成后看netstat -an相应端口是否成功打开了。