簡單易用的 Zabbix 監控服務
上週六 (05/26)，是 DevOps Taiwan 的社群日。這次「Monitoring Tools 大亂鬥」一共邀請了 11 位講者，從雲端運算 (Cloud Computing) 的 AWS, Azure, GCP，和自由軟體 (Free Software) 的 Consul, ELK, Nagios, Prometheus, Zabbix 等各種監控工具來探討 CALMS 的監控、量測和建立回饋機制等關鍵議題。
感謝益師益友 Cheng-Wei Chen 的邀請，讓凍仁能代表 Zabbix 上台分享。這 15 分鐘的分享，主要以 Zabbix 的基礎觀念、系統架構等入門知識為主，然後用 Dockerize 的 Zabbix 進行簡單的 demo，最後補充些實戰經驗。
▲ 凍仁於 05/26 DevOps Taiwan 分享的 Zabbix 入門簡報。由於 Zabbix 現在就如同凍仁的眼，無時無刻幫團隊的大家看照數百的伺服器，故這次選了 eyes 的 cowsay 意像圖。
大家可在 chusiang/zabbix.dockerize | GitHub 找到簡報中的 docker-compose.yml，若手邊有 Docker 環境，不妨在本機跑個 Zabbix 把玩看看吧！
雖說前半段的 Monitoring Tools 大亂鬥很精采，但後半段的綜合座談才是本次活動的精華！以下就讓凍仁用文字的方式進行補充吧！
1. 可否分享一些你畢生難忘的監控異常事件？
剛接觸 Zabbix 時，藉由 net.if.list 的 key，自定了監控 VPN 網路連線狀態的項目。那時還寫了篇「透過 Zabbix 監控 VPN (PPPoE) 狀態」紀錄摸索兩天的心得呢！
2. 你挑選 Monitoring Tools 時，你會根據哪些項目來選擇工具？
在 Zabbix 的設計哲學裡，是支援讓 agent 同時傳送給多台 Zabbix server 的，但這會受限於網路環境；在網路獨立且互不相通的環境，可以藉由排程 (cron job) 進行最小限度的監控，例如每 20 分使用 curl 來詢問 Zabbix server 的 web (80 port) 是否正常。
4. 你目前比較常監控的環境（目標對象），你會監控哪些指標（Metric）？告警的條件又是？
盡可能另架一台機器進行測試，以不影響 Production 運作為主。
6. 請問如何長期保存監控系統的資料，而不影響系統效能？
在 Zabbix 裡，我們可以只保留 7 天或 1 個月的 item 紀錄，之後會自動被轉換成 Trend (趨勢)。好比圖片壓縮後，雖會失真，不會百分百與原圖一樣，但一般人的肉眼是難以分辨差別。
7. 針對累積的監控資料，你們會進行後續的分析與利用嗎？會運用在哪些方面？
藉由 Trend 所繪出的圖表極具價值，我們可以用它得知系統發生例外的時間點外，還可用它來推斷系統負載 (loading) 的成長速度。
8. 大量監控項目所形成的資料，資料庫該如何優化？需要優化那些項目才好？
以 Zabbix 而言，最肥的表格為 history 和 history_uint，真不行凍仁會直接清空 (truncate) 它們，但會掉 3 ~ 7 天的紀錄。最好還是藉由 SQL 指令進行保留，但這相對需耗費較長的時間處理。
9. 請問監控系統有再串接別的系統來達到自動化處理系統障礙的目標？
在 Zabbix 的 Action 可以接 Remote command，想怎麼串都可以，但請小心權限設置。這個自動化的 script 本身也是個系統，要判斷的東西自然也不會少，建議使用軟體工程的方式進行。
10. 如何有效的監控 API 運作情形，API 端開發是否有需要對應的處理?
凍仁會藉由 Zabbix 的 Web Monitoring 功能進行 API 的監控。若開發 API 時，可以把 Health Check 的機制考慮進來是最好的！
11. 是否可以分享針對不同量級（10 ~ 100、100 ~ 500、超過 1000 ~）的監控對象，分享您的經驗？像是會遇到的雷與坑？
先前在一台 4G RAM、2 Cores 的 VM 上，用 Dockerize 的 Zabbix server 監控 100 台機器可是綽綽有餘呢！其 Zabbix 官方文件也有提到「硬體配置範例」，請參閱簡報第 9 頁的表格。
當級量變大時，可參考簡報第中提到的方法，先加入 Zabbix Proxy Server (簡報第 12 頁)，再不行就把 Database 拆開吧 (簡報第 37 頁)！
14. 針對公司已經有許多舊有的監控系統，如何整合或是替換，分享技術方面與人溝通方面的挑戰
如果只是想藉由一個 Dashboard 來呈現多種監控工具的數據，不妨試試看 Grafana；若沒法靠第三方工具處理，那就手動刻一個吧！
雖說當時是公司要求，需透過 Zabbix 監控大大小小機器和服務，遠到混合雲的伺服器，近到各辦公室的 Windows 與 macOS 工作機；但掌握 Zabbix 這項技藝後，身為 IT 的凍仁終於可以化被動為主動，在顧客還沒發現問題時，先行通知開發團隊，並提供更詳細的資訊協助故障排除 (troubleshooting)。
身為一位 IT，手邊沒有監控工具協助，當例外工作發生時，又怎麼在最短的時間解決呢？
Zabbix 是個始於 1998 年的開源老將，它不像新興的監控工具如此炫麗，但卻是個簡單易用，監控範圍涵蓋極廣的 All-in-one 監控工具。若讀者有監控大量基礎建設的需求，不妨考慮一下 Zabbix 這套簡單易用的監控服務吧！
感謝益師益友 Cheng-Wei Chen 的邀請，讓凍仁能代表 Zabbix 上台分享。這 15 分鐘的分享，主要以 Zabbix 的基礎觀念、系統架構等入門知識為主，然後用 Dockerize 的 Zabbix 進行簡單的 demo，最後補充些實戰經驗。
▲ 凍仁於 05/26 DevOps Taiwan 分享的 Zabbix 入門簡報。由於 Zabbix 現在就如同凍仁的眼，無時無刻幫團隊的大家看照數百的伺服器，故這次選了 eyes 的 cowsay 意像圖。
 |
| ▲ 藉由 Docker 簡單地部署 Zabbix v3.4.9。 |
大家可在 chusiang/zabbix.dockerize | GitHub 找到簡報中的 docker-compose.yml，若手邊有 Docker 環境，不妨在本機跑個 Zabbix 把玩看看吧！
 |
| ▲ Zabbix Web UI 操作 Demo。 |
雖說前半段的 Monitoring Tools 大亂鬥很精采，但後半段的綜合座談才是本次活動的精華！以下就讓凍仁用文字的方式進行補充吧！
1. 可否分享一些你畢生難忘的監控異常事件？
剛接觸 Zabbix 時，藉由 net.if.list 的 key，自定了監控 VPN 網路連線狀態的項目。那時還寫了篇「透過 Zabbix 監控 VPN (PPPoE) 狀態」紀錄摸索兩天的心得呢！
2. 你挑選 Monitoring Tools 時，你會根據哪些項目來選擇工具？
- 公司政策：較重視資安的公司，一般較不願意使用外部第三方服務。
- 資源：公司肯不肯花錢買服務？預計投入多少硬體設備？預計預留 1 週？1 個月？或 1 年的監控紀錄？還有最重是的是團隊本身是否駕御得了該工具？不該造成團隊太大的負擔。
- 系統架構：有無要在 Production 導入 Docker 或 Kubernetes？這會是個很大的分水嶺。
在 Zabbix 的設計哲學裡，是支援讓 agent 同時傳送給多台 Zabbix server 的，但這會受限於網路環境；在網路獨立且互不相通的環境，可以藉由排程 (cron job) 進行最小限度的監控，例如每 20 分使用 curl 來詢問 Zabbix server 的 web (80 port) 是否正常。
4. 你目前比較常監控的環境（目標對象），你會監控哪些指標（Metric）？告警的條件又是？
- VM 為主。
- 先以 Zabbix 內建的 Template 為主進行基礎建設的監控，再依團隊需求微調，最後再向上往最具商業價值的地方著手進行。
- 告警的條件必需依照各個團隊量身打造，這裡就不詳談了。
盡可能另架一台機器進行測試，以不影響 Production 運作為主。
6. 請問如何長期保存監控系統的資料，而不影響系統效能？
在 Zabbix 裡，我們可以只保留 7 天或 1 個月的 item 紀錄，之後會自動被轉換成 Trend (趨勢)。好比圖片壓縮後，雖會失真，不會百分百與原圖一樣，但一般人的肉眼是難以分辨差別。
7. 針對累積的監控資料，你們會進行後續的分析與利用嗎？會運用在哪些方面？
藉由 Trend 所繪出的圖表極具價值，我們可以用它得知系統發生例外的時間點外，還可用它來推斷系統負載 (loading) 的成長速度。
8. 大量監控項目所形成的資料，資料庫該如何優化？需要優化那些項目才好？
以 Zabbix 而言，最肥的表格為 history 和 history_uint，真不行凍仁會直接清空 (truncate) 它們，但會掉 3 ~ 7 天的紀錄。最好還是藉由 SQL 指令進行保留，但這相對需耗費較長的時間處理。
9. 請問監控系統有再串接別的系統來達到自動化處理系統障礙的目標？
在 Zabbix 的 Action 可以接 Remote command，想怎麼串都可以，但請小心權限設置。這個自動化的 script 本身也是個系統，要判斷的東西自然也不會少，建議使用軟體工程的方式進行。
10. 如何有效的監控 API 運作情形，API 端開發是否有需要對應的處理?
凍仁會藉由 Zabbix 的 Web Monitoring 功能進行 API 的監控。若開發 API 時，可以把 Health Check 的機制考慮進來是最好的！
11. 是否可以分享針對不同量級（10 ~ 100、100 ~ 500、超過 1000 ~）的監控對象，分享您的經驗？像是會遇到的雷與坑？
先前在一台 4G RAM、2 Cores 的 VM 上，用 Dockerize 的 Zabbix server 監控 100 台機器可是綽綽有餘呢！其 Zabbix 官方文件也有提到「硬體配置範例」，請參閱簡報第 9 頁的表格。
當級量變大時，可參考簡報第中提到的方法，先加入 Zabbix Proxy Server (簡報第 12 頁)，再不行就把 Database 拆開吧 (簡報第 37 頁)！
14. 針對公司已經有許多舊有的監控系統，如何整合或是替換，分享技術方面與人溝通方面的挑戰
如果只是想藉由一個 Dashboard 來呈現多種監控工具的數據，不妨試試看 Grafana；若沒法靠第三方工具處理，那就手動刻一個吧！
活動照片
 |
| ▲ 即將開始的 Monitoring Tools 大亂鬥。 |
 |
| ▲ 會後的講者合照。可以一次聽到各家的解決方案，並進行交流，這可是講者才懂進階學習法啊！ |
後語
凍仁與 Zabbix 的邂逅，是 3 年前的春天，比 Ansible 還早一年。想不到 3 年後可以在台上把 Shortie Lo 前輩傳授的技藝分享給他人！雖說當時是公司要求，需透過 Zabbix 監控大大小小機器和服務，遠到混合雲的伺服器，近到各辦公室的 Windows 與 macOS 工作機；但掌握 Zabbix 這項技藝後，身為 IT 的凍仁終於可以化被動為主動，在顧客還沒發現問題時，先行通知開發團隊，並提供更詳細的資訊協助故障排除 (troubleshooting)。
身為一位 IT，手邊沒有監控工具協助，當例外工作發生時，又怎麼在最短的時間解決呢？
Zabbix 是個始於 1998 年的開源老將，它不像新興的監控工具如此炫麗，但卻是個簡單易用，監控範圍涵蓋極廣的 All-in-one 監控工具。若讀者有監控大量基礎建設的需求，不妨考慮一下 Zabbix 這套簡單易用的監控服務吧！
相關連結：
★ chusiang/zabbix.dockerize | GitHub
★ 簡單易用的 Zabbix 監控服務 by 凍仁翔 | Speaker Deck
★ 簡單易用的 Zabbix 監控服務 by 凍仁翔 | SlideShare
★ DevOps Taiwan - Monitoring Tools 大亂鬥 - 提問募集 | HackMD
★ 京東 MySQL 監控之 Zabbix 優化、自動化 | 壹讀
資料來源：
★ Zabbix Official website
★ Zabbix manual 3.4 | Zabbix Documentation
★ Monitoring Tools 大亂鬥會後戚謝文 | DevOps Taiwan
對 Zabbix 有興趣的伙伴，不妨加入 Telegram 的 Zabbix Taiwan 群組。相信有不少問題都可以在此找到解答。
回覆刪除→ https://t.me/zabbix_tw