Azure Monitor指標、日誌及警示如何配合？

先了解問題：雲端服務如何維持可用性

Azure Monitor 是 Azure 的可觀測性平台，透過 Metrics、Logs、Activity Log、Application Insights 及警示規則，把資源健康、效能及操作事件連接起來。有效監控不只是收集最多數據，而是把關鍵服務的正常基線、可操作告警及回應責任清楚定義。 對企業而言，設計的價值在於把技術設定轉化為可量度、可監控及可恢復的服務能力。下文從架構、操作流程、安全控制及本地部署情境逐步說明，方便管理員建立自己的檢查清單。

任何雲端配置都應先在測試環境驗證，再以最小範圍推進生產。記錄變更前後的設定、測試時間、責任人及回復方法，出現異常時才可以快速還原，而不是在事故中猜測哪一項設定曾經被修改。

Metrics與Logs的分工

Metrics 是按時間序列儲存的數值，例如 CPU 百分比、請求數、延遲及可用性，適合快速繪圖、容量趨勢及近即時警示。Logs 則是較詳細的結構化或文字事件，例如登入、應用例外、網絡流量及資源操作記錄，適合以 KQL 關聯搜尋及事後調查。Activity Log 聚焦 Azure 控制平面的訂閱操作，不能取代客戶端或應用程式日誌。

根據 Microsoft Azure Monitor概覽，可觀測性要把不同來源的資料連接到分析及行動。日誌管理亦應參考 NIST日誌管理指南，在收集、傳輸、保留、存取及完整性之間取得平衡。

監控資料層次與取捨

建立可操作的警示

1. 定義服務目標——先寫清楚可用性、延遲、錯誤率、備份成功率等服務指標，再選擇資料來源。
2. 建立正常基線——以工作日、非工作日及高峰時段分開觀察，不要直接套用沒有業務背景的固定門檻。
3. 設定條件及評估窗口——指定聚合方式、連續失敗次數、維護時段及自動解決策略，避免瞬時尖峰造成噪音。
4. 連接行動群組——按嚴重程度通知值班人員、工單系統或自動化流程，並設有清楚的擁有人。
5. 定期回顧告警——檢查觸發率、誤報、未處理告警及事故結果，刪除無人跟進或重複的規則。

好的告警應回答「發生什麼事、影響誰、何時開始、下一步做什麼」。例如「API錯誤率在五分鐘內超過5%，由訂單服務負責人處理」比單純寫「CPU超過80%」更容易帶來正確行動。

Log Analytics與KQL查詢思維

送入 Log Analytics workspace 前，應先按安全、營運及成本需要選擇資料類型，設定保留期及角色存取。KQL 查詢宜從明確的時間範圍、資源類型及事件類別開始，再逐步加入統計與關聯，並保存經驗證的查詢作為工作簿或告警規則。不要把所有原始資料永久保存而沒有分類，這會增加成本，也令調查時難以辨識真正訊號。

對登入、網絡及資源操作記錄，應保留來源、時間戳記、結果、資源識別碼及關聯 ID；對個人資料及機密內容則要最小化收集並限制存取。可將 Azure Monitor 與 網絡故障排查流程連接，令告警能快速指向網絡或應用層。

香港企業的監控落地

企業可先為 VPN、網站、ERP、備份及門禁管理等關鍵服務建立服務地圖，為每項服務指定指標、日誌來源、告警擁有人及維護窗口。辦公室與雲端之間的網絡問題，應同時觀察 Connection Monitor、NSG/防火牆日誌及應用請求，避免只看其中一層。

監控是持續流程，不是設定一次便完成。每月檢視無效告警，每季以演練驗證通知、權限及值班聯絡資料，並在事故後更新基線。網絡分段可參閱什麼是網絡分段？及什麼是零信任架構？。

常見問題

延伸閱讀

權威資料來源

Microsoft Learn：Azure Monitor概覽；NIST SP 800-92：Guide to Computer Security Log Management。