以下簡述印象比較深刻的幾個坑:二次開發(fā)的方式:2011剛開始做的時候,我們直接修改zabbix開源的源代碼,實現(xiàn)了一些功能自以為做得還不錯,但是后來zabbix升級一個大版本,發(fā)現(xiàn)zabbix做的比我們高明多了,所以之后,我們都盡量不去動zabbix的源碼,動也只是做操作層面的改進,用戶交互的改良。
?
模板:一開始我們想得很簡單,網(wǎng)上收集一堆模板,這個事就算做完了,后來發(fā)現(xiàn)這只是個開始,默認的模板考慮的深度還不夠,需要持續(xù)改良和積累。
?
不必要的Item:在做IT基礎架構監(jiān)控的時候,尤其是網(wǎng)絡監(jiān)控的時候,對于Item的啟用對于指標收集的及時性和數(shù)據(jù)容量的控制至關重要,一開始我們幾乎啟用了所有Item,后來發(fā)現(xiàn)監(jiān)控的效率和數(shù)據(jù)庫日增量實在讓人受不了,最后,想辦法壓制了一些很少被用到的Item,改進的效果非常明顯。
?
Oracle的監(jiān)控:用原生的Orabbix監(jiān)控Oracle時,會有些問題,比如說常見的審計問題,需要DBA持續(xù)優(yōu)化。數(shù)據(jù)清理的問題:zabbix默認配置了Housekeeping來清理數(shù)據(jù),但是根據(jù)我們的經(jīng)驗,在執(zhí)行清理的時候除了影響數(shù)據(jù)庫運行,還有約15%的系統(tǒng)資源的損耗,因此,我們默認關閉了這個功能,將這個功能腳本頁面化了。其他問題:監(jiān)控頻率無法做到秒級別web撥測只支持get和post,中文亂碼腳本下發(fā)只支持shell,并且搭配告警等觸發(fā),無法手動IPMI輪訓存在延時告警有時會無法自動恢復SNMP監(jiān)控請求一個監(jiān)控項一個連接請求… …
?
以下簡單列舉我們的常見優(yōu)化的幾個方向:
?
高可用部署:高可用部署依賴可預見的監(jiān)控規(guī)模和組織對監(jiān)控系統(tǒng)的重視程度漸次加強,最簡單的起碼做到Web和DB的分離;其次,做到數(shù)據(jù)庫層面的高可用;然后,分布式代理,甚至代理層的高可用;然后,考慮Web層的負載,最后,有條件的可以加一層冷備。
?
數(shù)據(jù)庫優(yōu)化:zabbix的數(shù)據(jù)庫優(yōu)化是被提到最多的,通常矛盾最突出的也是MySQL的性能,通常的解決辦法是:表分區(qū);優(yōu)化Item;多采用主動方式采集;Housekeeper優(yōu)化;優(yōu)化觸發(fā)器表達式;數(shù)據(jù)庫主從,Proxy模式;zabbix配置文件調優(yōu);分表;提高機器配置(SSD)。
?
數(shù)據(jù)庫監(jiān)控:上一節(jié)提到Oracle監(jiān)控的坑,其他數(shù)據(jù)庫也一樣,多采用自己可控的監(jiān)控方式。鏈路監(jiān)控:單獨把鏈路監(jiān)控提出來,對于一些有分支機構的組織來說顯得尤其必要。歷史數(shù)據(jù)存檔與清理:通常限定詳細監(jiān)控數(shù)據(jù)的保存時間,只保留趨勢數(shù)據(jù),轉存或清理歷史數(shù)據(jù),我們采用腳本頁面化的方式實現(xiàn)。
?
監(jiān)控平臺的自監(jiān)控:監(jiān)控zabbix本身的狀態(tài)。