2018-06-01

簡單易用的 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 意像圖。

▲ 藉由 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?這會是個很大的分水嶺。
3. 你是如何 Monitoring Monitoring systems?

在 Zabbix 的設計哲學裡,是支援讓 agent 同時傳送給多台 Zabbix server 的,但這會受限於網路環境;在網路獨立且互不相通的環境,可以藉由排程 (cron job) 進行最小限度的監控,例如每 20 分使用 curl 來詢問 Zabbix server 的 web (80 port) 是否正常。

4. 你目前比較常監控的環境(目標對象),你會監控哪些指標(Metric)?告警的條件又是?
  • VM 為主。
  • 先以 Zabbix 內建的 Template 為主進行基礎建設的監控,再依團隊需求微調,最後再向上往最具商業價值的地方著手進行。
  • 告警的條件必需依照各個團隊量身打造,這裡就不詳談了。
5. 你如何確認你設置的監控指標、告警條件是否正確?是否能正確用來識別服務為正常狀態?

盡可能另架一台機器進行測試,以不影響 Production 運作為主。

6. 請問如何長期保存監控系統的資料,而不影響系統效能?

在 Zabbix 裡,我們可以只保留 7 天或 1 個月的 item 紀錄,之後會自動被轉換成 Trend (趨勢)。好比圖片壓縮後,雖會失真,不會百分百與原圖一樣,但一般人的肉眼是難以分辨差別。

7. 針對累積的監控資料,你們會進行後續的分析與利用嗎?會運用在哪些方面?

藉由 Trend 所繪出的圖表極具價值,我們可以用它得知系統發生例外的時間點外,還可用它來推斷系統負載 (loading) 的成長速度。

8. 大量監控項目所形成的資料,資料庫該如何優化?需要優化那些項目才好?

以 Zabbix 而言,最肥的表格為 historyhistory_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

沒有留言 :

張貼留言

謝謝您的寶貴意見,凍仁一定會盡快回覆。😉