踩過的那些坑
從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本身的狀態
