1、Zabbix是什麼？
首先是定性，zabbix提供了全套的監控解決方案，即採集數據——存儲和展示數據——定義告警觸發條件——觸發告警，這樣一個完整的監控流程（在zabbix裏對應的術語，也及配置流程爲：主機——監控項——觸發器——動作，zabbix中的主機是個泛稱，泛指任意類型的被監控對象）。
在一些基本場景下，可以做到拿來就用。但zabbix並不死板，在上述四個階段都可以靈活定製。我自己親身經歷的從nagios遷移到zabbix的過程，讓我深刻體會到這是一個既靈活又簡單的系統。Nagios社區的所有監控插件，都可以完美地用到zabbix中，且配置更爲快捷。
2、如何採集監控數據？
如何採集數據，可以由我們自己天馬行空地發揮。zabbix支持非常豐富的數據採集方式，既可以在服務端從被監控端拉取數據（方式包括zabbix agent、snmp、http、ssh、ODBC等等），也可以從被監控端或者任何其他地方向服務器端推送數據（對應的監控項類型爲 zabbix agent active、zabbix trapper）。這意味着zabbix的監控能力絕不僅限於其web端展示的那些，而是可以監控你用任意方式採集到的任意數據。
3、配置告警的觸發條件需要注意什麼？
zabbix的告警觸發條件配置十分靈活。但是，不建議配置過於複雜，簡單的觸發條件才能最大可能地避免誤觸發或者關鍵時候未觸發。能夠配置簡單觸發條件的前提是提供監控數據要足夠簡單，比如一個數字、一個字符串，而不應當一段文字、N個數字。
4、zabbix支持什麼告警方式？應當選擇什麼告警方式？
觸發告警的動作，即告警要以何種方式發送給何人，在zabbix裏也是可以靈活定義的。如最基本的郵件告警，短信告警，最近幾個版本增加的webhook告警等等，也可以選擇自定義腳本，基本上能夠想到的告警方式都可以實現。
至於選擇什麼樣的告警方式，要去取決於實際接收人的使用習慣，比如公司愛用微信辦公，就可以把基本告警配置爲企業微信告警；公司愛用郵件辦公，就使用郵件告警；愛用釘釘辦公，就可以試下webhook機器人。
5、告警應當發送給什麼人？如何做到不同的告警發送給不同的人？
告警應當發送給對應的負責人，比如A項目的告警發送A項目的負責人甲，B項目的告警發送B項目的負責人乙，而不應當把A項目的告警發送給甲、乙，告警亂髮的後果就是長此以往，接收人將不在對告警有敏感性，很有可能錯過重要告警。
要做到不同的告警發送給不同的人，在創建主機時要合理的分配“主機羣組”，不同項目的主機放到不同的羣組下，不同類型的主機放到不同的羣組下，這樣我們在配置“動作”時，就可以用最簡單的條件精準的推送告警。
6、zabbix的觸發器嚴重性級別有什麼用？如何選擇嚴重性級別？如何做到不同的嚴重性級別採用不同的告警方式？
這三個問題是強相關的，我合在一起回答。觸發器的嚴重性級別，不是簡單用來在告警內容中顯示的，它最大的用處是用來配置“動作”，將不同級別的告警用逐漸升級的方式發送給不同的人。
無需處理的告警，級別可定爲信息；需要處理，但不緊急的告警，級別可定爲警告；急需處理，但不影響業務的告警，級別可定爲嚴重；急需處理，且已影響某一功能模塊的告警，級別可定爲嚴重；萬分緊急，可導致業務癱瘓的告警，可定爲災難。
以上級別的告警，對應的告警推送手段可爲郵件——短信——電話，推送人可爲直接負責人——組長——分管領導——領導。定義好觸發的嚴重性級別，就可以在配置動作時方便地實現不同級別的告警採用不同的方式。
7、監控系統如何做到高可用？
這是一個通用的問題，與監控系統無關。業務系統如何做高可用，監控系統依葫蘆畫瓢就行，沒有特殊的地方。甚至，你可以直接建設兩套相同的監控系統，zabbix的agent端和proxy都支持配置多套server。
8、在使用的zabbix agent時，passive模式和active模式有什麼區別？如何選擇？網絡上如何配置？
passive模式下，數據由server主動向agent索取；active模式下，數據由agent主動向server推送；（可以類比爲http方法的get、post）。proxy與server的關係與之相同。
選擇何種方式見仁見智，一般性原則爲：所有agent儘可能配置爲passive模式，所有proxy推薦選擇active模式，這樣在web端可以清晰地顯示agent的在線狀態，也不會對server造成太大壓力。當然如果監控數量不多，全部選擇passive模式也是很好的，因爲passive模式下，無需考慮時間同步問題。在zabbix中，passive模式下的監控數據時間是以server/proxy的本地時間爲準的，active模式下的監控數據時間是已agent本地時間爲準的。所以如果使用active模式，必須保證各節點間的時間同步。
如果使用passive模式，則agent所在節點需開放10050端口入訪權限，而無需開放出訪權限，相對應的只需給server端開放出訪權限。此時就可以在agent配置文件中註釋掉ServerActive=*，以避免額外的消耗主機性能及日誌報錯。
如果使用active模式，則server所在節點需開放10051端口入訪權限，無需開放出訪權限，相對應的agent端只需要開放出訪權限。此時就可以將agent配置文件中的StartAgents=3調整爲StartAgents=0，以避免額外的端口暴露和性能消耗。
9、zabbix agent配置文件中的hostname一定要和web端一致嗎？
不一定。如果agent使用的是passive模式，則該字段沒有用處，也無需與web端一致。但如果agent使用的是active模式，則兩端必須保持一致，否則agent將不知道數據發往何處。
雖然如此，但仍建議兩端保持一致。
10、zabbix應部署在何處？
應部署在網絡通達，極可能擁有上帝視角的地方。舉個例子，比如樹形網絡，zabbix就應當部署在根處，這樣某一分叉發生故障可以很容易地判斷。如果是網形網絡，則部署在任何方便的地方都差不多，儘可能保障到各節點網絡暢通即可。
11、主機可見名稱的定義原則？
建議採用：項目_用途_IP_(負責人_電話)這樣的命名形式，好處很多，用了就知道。
12、告警的內容如何定義？
如果採用郵件形式，則標題要簡潔且包含關鍵信息，舉個例子：“A項目B主機磁盤空間將滿”，這樣的標題讓我們可以在不打開郵件的情況下就可直接去處理故障了，相比一句簡單的“磁盤空間告警”顯然要優秀很多。如果使用電話告警，則只需播報關鍵信息即可，而不要長篇大論，在關鍵時間讓人員電話佔線。
詳細的內容附在正文，重要信息除了標題中列出的內容外，還應包括告警觸發/恢復時間，當時監控項的具體數據，還可附上相關的監控圖表。
13、一個小細節，閾值的設定？
對於磁盤空間這類數據存在波動性的監控項，相關的告警和恢復閾值，不應當簡單地配置成剩餘空間小於10%告警，大於10%恢復。而應當配置爲小於10%告警，大於15%恢復。否則當數據在10%左右波動的時候，會不斷地觸發告警/恢復。
14、zabbix agent有何用？
除了直接提供一些基本的監控項外，還可以很容易的添加一些自定義監控項，只需要在配置文件中指定key和數據獲取命令即可。
暫時先想到這麼多，以上僅是一些經驗性思考，歡迎大家指正。詳細的技術細節，如果大家有疑問，也歡迎探討。