踩過的那些坑

從2011年開始玩Zabbix，踩過的坑著實不少，被研發的同事吐了無數槽，所謂“情到深度又愛又恨“。以下簡述印象比較深刻的幾個坑：

二次開發的方式：2011剛開始做的時候，我們直接修改Zabbix開源的原始碼，實現了一些功能自以為做得還不錯，但是後來Zabbix升級一個大版本，發現Zabbix做的比我們高明多了，所以之後，我們都儘量不去Zabbix的原始碼，動也只是做操作層面的改進，使用者互動的改良。

模板：一開始我們想得很簡單，網上收集一堆模板，這個事就算做完了，後來發現這只是個開始，預設的模板考慮的深度還不夠，需要持續改良和積累。

不必要的Item：在做IT基礎架構監控的時候，尤其是網路監控的時候，對於Item的啟用對於指標收集的及時性和資料容量的控制至關重要，一開始我們幾乎啟用了所有Item，後來發現監控的效率和資料庫日增量實在讓人受不了，最後，想辦法壓制了一些很少被用到的Item，改進的效果非常明顯。

Oracle的監控：用原生的Orabbix監控Oracle時，會有些問題，比如說常見的審計問題，需要DBA持續優化。

資料清理的問題：Zabbix預設配置了Housekeeping來清理資料，但是根據我們的經驗，在執行清理的時候除了影響資料庫執行，還有約15%的系統資源的損耗，因此，我們預設關閉了這個功能，將這個功能指令碼頁面化了。

其他問題：

監控頻率無法做到秒級別

web撥測只支援get和post，中文亂碼

指令碼下發只支援shell，並且搭配告警等觸發，無法手動

IPMI輪訓存在延時

告警有時會無法自動恢復

SNMP監控請求一個監控項一個連線請求

… …

常見優化的方向

以下簡單列舉我們的常見優化的幾個方向：

高可用部署：高可用部署依賴可預見的監控規模和組織對監控系統的重視程度漸次加強，最簡單的起碼做到Web和DB的分離；其次，做到資料庫層面的高可用；然後，分散式代理，甚至代理層的高可用；然後，考慮Web層的負載，最後，有條件的可以加一層冷備。

資料庫優化：Zabbix的資料庫優化是被提到最多的，通常矛盾最突出的也是MySQL的效能，通常的解決辦法是：表分割槽；優化Item；多采用主動方式採集；Housekeeper優化；優化觸發器表示式；資料庫主從，Proxy模式；Zabbix配置檔案調優；分表；提高機器配置（SSD）。

資料庫監控：上一節提到Oracle監控的坑，其他資料庫也一樣，多采用自己可控的監控方式。

鏈路監控：單獨把鏈路監控提出來，對於一些有分支機構的組織來說顯得尤其必要。

歷史資料存檔與清理：通常限定詳細監控資料的儲存時間，只保留趨勢資料，轉存或清理歷史資料，我們採用指令碼頁面化的方式實現。

監控平臺的自監控：監控Zabbix本身的狀態