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

記一次zabbix server掛掉的事件