zabbix：3.0版本，采用一个server，多个proxy的模式（别人装的，我刚入职，接手不久）
系统：Linux X86_64
配置：4 core 8G内存
经过：
上午11点，上完厕所回来发现dashboard上有大量告警，都是zabbix agent has no data for 15 min on hostname。
第一反应是不是某人批量改了hotname导致的（hostname和zabbix上web端配置的主机名不一样会有这个告警，agent配置文件里面没有指明hostname的话；之前常有个别运维这样干）
但是一想也不对，主机设备都不是一个业务的，不可能出现批量更改主机名的情况，随机打开几台的配置，发现都是一个proxy，怀疑是这个proxy出问题。这时候发现点击web页面有些卡（server配置低，WiFi网，之前也会卡的）
发现这台proxy是之前就挂的机器很多，平时就很卡。所以怀疑是proxy死了。
登录proxy机器，看负载没问题，proxy状态也正常，不过还是重启了下；
再回来看dashboard，发现告警的设备越来越多，而且告警的短信和邮件都没再收到，感觉是server出问题了
赶快登录server服务器，发现processor load的三个值都破60了（设备配置是4核），内存即将满了（8G）。前台web页面也卡的不行了。
首先先用重启大法吧，同时看zabbix_server.log。发现起来后有个日志报内存不够，接着有一行报请增加historyindexcachesize配置参数
接着server就死掉了。
一方面请系统运维帮忙扩下资源（后扩到8核16G），自己更改下zabbix_server.conf的参数配置，当时调高了包括上面在内的多个参数
再重启，发现每次都是同步到历史数据的时候又死了
赶紧找DBA看看怎么回事（我们的mysql数据库是DBA维护的）
DBA看后没有什么问题，只是负载有点高，找他清理下历史数据，只保留最近一个月的（之前设置的是90天，趋势数据是720天，我的天啊，保留这么长服务器性能数据有啥用，对我们一个高速增长的公司来说）
我这边再重启，发现比之前好多了，server起来了，同时赶快把发送告警的action关掉，以防告警泛滥
但是十几分钟后又挂了，妈的。发现是之前积压的告警队列太多了，action不停的调发送邮件，短信，钉钉的脚本导致server负载很高
这怎么办呢，不知道怎么清理告警队列，有人说清理alert的数据表，这绝对不可能啊。。后来查到个办法，把发送告警的几个脚本内容都情况，这样action调用就很快了。
真管用了，看到积压的告警在一直减少。
but，最后还400多个没恢复，看zabbix 队列，发现基本都是最上面说的那台proxy上面的
去这台proxy上，改了下zabbix_proxy.conf的那几个参数，调低了向server同步的数据的时间间隔，调高了HistoryCacheSize的值
重启proxy，很快就好了。
别忘了把action都开启，把告警的脚本都恢复回去
这时候zabbix server有个告警:Zabbix value cache working in low memory mode 一直没恢复。感觉是我刚才把CacheSize调的太高了导致的，把它再调低点，重启告警恢复了。具体原因待研究。
具体参考：
http://blog.csdn.net/zhs2014150551/article/details/48975931
http://www.ttlsa.com/zabbix/zabbix_server-conf-detail/ （这个建议，汉语解释较多）
http://www.xiaomastack.com/2014/10/10/zabbix02/（推荐）
http://www.ixdba.net/archives/2017/11/873.htm（后面看很全面）
从中可以看出一个开源的监控软件也有很多要学习的地方，路漫漫其修远兮，静下心来看看官方文档
补充：事后查原因，发现告警大约是11点开始的，看zabbix server的load,processor load的值在10点半的时候开始飙升，大约涨了4-5倍。但是那个时间点并没有做什么操作。
但是我们的zabbix有很多的api接口供外部调用，做数据展示什么的，当时某部门在频繁的拉去数据，还有很多的grafana展示要用，怀疑是查询数据库太多导致了数据库负载升高，zabbix server连接数据库变慢，负载增加。
后面一方面减少历史数据的保留时间，一方面增加系统资源，一方面调整api接口，不再查询主库，查询备库。
