記一次zabbix server掛掉的事件

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接口，再也不查詢主庫，查詢備庫。