像MIUI同樣作Zabbix二次開發（7）——問答

Q：用Zabbix怎麼去監控IBM的power服務器（硬件方面的）

A：硬件監控，ipmi  和SNMP，帶外管理口集成

Q：ipmi獲取數據有時候回拉不到

A：ipmi的監控zabbix低版本的的確輪訓會不好，有這個問題，Zabbix在升級版本中也一直對這塊作了優化，儘可能用高版本的Zabbix

Q：ipmi 監控IBM服務器硬件的時候常常獲取不到數據，監控效果不好

A：是的，Zabbix的每一個版本都有所優化，ipmi也有相應的配置參數，相對調整也能夠加快輪訓

Q：業務監控怎麼作的

A：咱們是分兩層作的，一個業務自己可用性監控，一個是依賴監控，而後創建關係

Q：有用容器作Zabbix-server進程的案例嗎？

A：有，作過

Q：業務數據怎麼作

A：業務數據須要單獨作，咱們一般是獨立作一個應用再與咱們的平臺集成，集成主要在顯示層

Q：Oracle的監控，能詳細說說嗎

A：咱們讓DBA獨立寫的監控腳本，放棄了orabbix

Q：zabbix案例中最多監控多少設備？實施

A：看item

Q：大家代碼開源了嗎？

A：咱們研發了好久，投入很大，代碼暫時不開源，計劃明年開放一部分功能

Q：老師你好，能講講Zabbix對docker容器的監控方案嗎？

A：基本：運行狀態數量、統計數量、版本、暫停狀態數量、中止狀態數量

自動發現：IO讀寫操做字節數、容器狀態、CPU使用率百分比、磁盤使用、內存限制值、內存使用率、網絡收發字節、總緩存、交換分區、運行時間等等

Q：Zabbix Server做爲監控處理中心，怎麼作高可用？

A：WEB層，DB層，Proxy，層層實現，建議作一層冷備

Q：請問，如何作預警?

A：3.0以上就已經有這個功能了，經過相似Forecast這樣的函數實現，Forecast

Q：這兩個函數效果通常，有沒有更好的辦法？

A：原生的只要這兩個，能夠結合多種表達式作優化。

Q：監控觸發報警的閥值，能根據歷史採樣數據作到動態設置嗎

A：如今還不行，trigger仍是靜態的，須要作二次開發

Q：您好！如何把不一樣的磁盤分區報警發給不一樣的人，如WebLogic分區告警發給中間件管理員，oracle分區報警發給數據庫管理員，有什麼好辦法嗎？

A：經過告警和報表訂閱實現，Zabbix原生尚未

Q：容器上跑Zabbix-server的坑能講講嗎？

A：咱們2015年用docker跑過，發現了一些問題，好比說JDBC當時沒有提供，監控不了數據庫，最近的版本尚未嘗試。

Q：Zabbix-server的高可用，通常用什麼組件實現？zookeeper？keepalive？仍是其餘的？

A：咱們用keepalive

Q：剛纔你提到的IBM的小機的帶外管理口是指HMC管理口嗎

A：是的，拿Zabbix監控硬件須要掌握原廠的MIB庫

Q：請介紹下如何作告警收斂的？

A：咱們作了管理上的收斂，Zabbix原生能夠配置告警依賴，另外觸發器事件模式配置單重等，計劃將來在實踐不嘗試去作告警的智能收斂，這個步驟咱們會相對謹慎，寧肯適當多發，也不漏發，避免影響監控的覆蓋率和準確率

Q：監控觸發報警的閥值，能根據歷史採樣數據作到動態設置嗎，有結合一些數據挖掘算法的案例嗎

A：須要二開

Q：Zabbix和自動化部署工具，如salt集成有這方面的經驗嗎？

A：作過一些測試，使用salt自動部署須要解決的問題

1.     rpm包的打包（這個問題不大，官方有提供）

2.    rpm 安裝（pkg模塊）

3.     配置文件調整(file模塊)

4.    服務自啓動（service）

5.     配置文件的適配（使用salt的pillar實現）

基本上涉及salt的pkg（包管理模塊）、file(文件管理模塊)、service（服務管理模塊）、pillar模塊這四個模塊。

Q：Zabbix的版本升級有沒有坑?

A：按官方提示操做，逐漸升級版本

1.     不建議跨版本升級，由於版本間可能有表字段的變動，版本跨越太大可能致使系統沒法運行

2.     若是非要跨版本升級的話，建議將主機和模板導出，部署完再作導入

3.     若是不是研究的話，版本升級不建議太激進