現代系統需要監控#
現代軟體系統很少只是單一程式，而是由多個服務、元件和函式庫組成。當需要除錯時，快速準確地識別出故障的元件是首要任務。設置並運行基礎設施監控系統是達成此目標的最佳方式。
選擇監控工具#
作者以 Nagios 為例說明，但原則適用於任何監控系統。選擇正式的監控工具而非自行拼湊，因為 Nagios 等工具提供：
- 被動與主動的服務檢查與通知
- Dashboard 儀表板
- Round-robin 事件資料庫
- 不干擾的排程監控
- 高度可擴展性與龐大的社群 plugin
如果你的系統運行在雲端或使用常見的應用堆疊，也可以使用雲端監控服務（如 AWS CloudWatch）。
監控的三個層次#
要有效定位問題，必須監控應用程式的完整堆疊：
1. 主機層級#
- CPU 負載、記憶體使用
- 網路可達性、磁碟空間
- 執行中行程數、已登入使用者
- 軟體更新、開啟的 file descriptor
- 網路與磁碟頻寬、系統日誌
2. 服務層級#
- 資料庫、郵件伺服器、應用程式伺服器
- Cache、網路連線、備份
- Queue、訊息系統、授權
- Web 伺服器、目錄服務
3. 應用層級#
- 端對端可用性（如完成一筆 web 表單交易）
- 個別元件（web service、資料庫 table、靜態頁面、報表）
- 關鍵指標（回應延遲、排隊與完成的訂單數、活躍使用者數、失敗交易數、錯誤數、crash 數）
故障通知與分析#
當服務失敗時，Nagios 會：
- 在 web 介面更新服務狀態（綠/黃/紅）
- 立即透過 SMS 或 Email 通知
- 對偶發性故障，即時通知讓你能在失敗狀態下除錯，更容易找到原因
- 可設定自動在 issue tracker 開 ticket
檢視故障的時間分佈直方圖可以幫助識別其他因素（如高 CPU 負載或記憶體壓力）。如果你監控了完整堆疊，底層故障會引發連鎖反應——此時應從最底層的故障開始調查。
自訂監控 Plugin#
如果內建的 plugin 不符合需求，可以輕鬆自己撰寫。規則很簡單：
- 印出服務狀態
- 正常時 exit code 為 0
- 嚴重錯誤時 exit code 為 2
也可以自訂通知處理器，例如用 shell script 在服務失敗時自動在 GitHub 開 issue：
#!/bin/sh
TITLE="$1"
BODY="$2"
NLBODY="$(printf '%b' \"$BODY\")"
ghi open -m "$TITLE
$NLBODY
" >/dev/null重點回顧#
- 對由多個獨立行程組成的系統，使用基礎設施監控工具（如 Nagios）來快速定位故障元件
- 監控需涵蓋三個層次：主機、服務、應用程式
- 設定即時通知機制，在故障發生時第一時間收到警報
- 善用監控工具的歷史資料與直方圖分析故障模式