Microsoft AZ-204: Azure 監視、診斷和 DevOps 整合 — 學習指南

By Laurynas Brazys · 6 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

屬於 Microsoft Azure Developer Associate AZ-204 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

Azure Monitor 與 Application Insights 為 Azure 應用程式提供了一個統一且以開發人員為中心的可觀測性堆疊。Application Insights 收集應用程式的遙測資料，例如請求、相依性、例外狀況與追蹤；而 Azure Monitor 則將跨資源的計量與日誌彙總到一個 Log Analytics 工作區，並驅動警示與 DevOps 整合。精通檢測選擇、遙測語意、可用性測試、Kusto 查詢語言 (KQL)、使用動作群組的警示、分散式追蹤，以及使用 ARM 範本的基礎設施即程式碼 (Infrastructure as Code)，可確保解決方案的可靠性、可診斷性與可自動化性。

Application Insights 檢測與遙測

Application Insights 資源是透過檢測金鑰或連線字串來識別以進行資料擷取。檢測金鑰是舊版的單一 GUID，供 SDK 用於路由遙測資料。連線字串是目前的建議作法；它包含檢測金鑰以及端點中繼資料 (擷取與 Live Metrics 端點)，並允許路由到非預設的端點 (適用於主權雲或私有雲)。在新的程式碼與組態中應使用連線字串；它讓未來的端點變更無需重新部署程式碼。在 App Service 中，於平台層級啟用 Application Insights 會將連線字串填入環境設定中，供自動偵測的執行階段使用。

檢測可透過 SDK 或自動檢測來完成。SDK 方法 (例如，.NET 的

undefined

、Node.js 的

undefined

，以及 Application Insights Java 代理程式) 提供程式碼層級的控制：可自訂事件、計量，並透過 TelemetryInitializers 與處理器 (包含自動調整取樣) 來豐富遙測資料。自動檢測 (無程式碼附加) 可用於 App Service 與某些運算堆疊，它使用網站擴充功能/代理程式來收集傳入的請求、相依性與例外狀況，無需任何程式碼變更。當您需要在背景作業中處理自訂事件、業務計量或明確的關聯性時，請使用 SDK 檢測；對於需要快速、低工作量可視性或隨即轉移 (lift-and-shift) 的工作負載，請使用無程式碼附加。在這兩種情況下，都應設定雲端角色名稱以在微服務架構中區分服務，並謹慎設定取樣以平衡精確度與成本。

Application Insights 會發出數種核心遙測類型：

Requests 捕捉傳入的作業 (HTTP 請求、函式調用)，包含持續時間、回應碼與成功狀態。
Dependencies 捕捉傳出的呼叫 (HTTP、SQL、Azure SDK 呼叫、佇列)，包含目標、類型、持續時間與成功狀態。
Exceptions 捕捉拋出的錯誤、堆疊追蹤，以及在明確追蹤時的已處理例外狀況。
Traces 捕捉日誌訊息；SDK 與熱門的日誌框架整合，因此日誌與遙測資料可共用關聯性。
Events 透過

undefined

捕捉自訂的、業務層級的事件，支援自訂維度與計數。

Metrics 捕捉數值量測；您可以追蹤自訂計量以監控 KPI，並在 Metrics Explorer 中檢視它們。

Application Insights 中的分散式追蹤關鍵在於關聯性。每個端對端作業都有一個作業 ID (在 W3C 術語中稱為追蹤 ID)，在所有相關的遙測資料中共享；每個 span 都有透過傳播標頭強制執行的父子關係。現代的 SDK 使用 W3C Trace Context (traceparent, tracestate)。KQL 中的

undefined

將同一個異動的 Requests、Dependencies、Exceptions 與 Traces 連結起來。請確保傳出的 HTTP 用戶端會傳播標頭；對於 .NET，

undefined

與 AI SDK 會自動處理此問題。相依性追蹤會檢測常見的用戶端 (HTTP、SQL、Service Bus、Storage)。當服務跨越邊界 (例如，從 App Service 到 AKS) 時，一致的傳播會產生一個單一的連接異動地圖。對於非同步與基於訊息的流程，請確保 SDK 在訊息中繼資料中捕捉並傳遞關聯性 ID；大多數 Azure SDK 預設會這樣做。

可用性測試與綜合監控

可用性測試從多個地理位置驗證外部的可達性與回應能力。URL ping 測試會以設定的頻率從多個測試位置發出 HTTP 請求，並驗證狀態碼、SSL 健康狀況與可選的內容比對。使用重試與多個位置來減少誤報，並針對測試失敗設定警示以獲得可採取行動的通知。

多步驟可用性測試在過去會執行已錄製的、帶有狀態 cookie 的 HTTP 請求序列以驗證工作流程。傳統的多步驟 Web 測試已被淘汰；對於多重請求或需驗證的情境，請透過檢測您自己的用戶端或服務，使用

undefined

API (或 OpenTelemetry 匯出器) 來發出

undefined

，以實作綜合測試。這種方法允許自訂驗證、承載以及特定領域的驗證，同時保留集中式的報告與警示。

自訂

undefined

讓您能控制：

測試名稱、執行位置與序列識別碼，用於趨勢分析與重複資料刪除。
基於您的驗證邏輯的持續時間與成功語意，而不僅僅是 HTTP 狀態。
豐富的訊息與自訂維度，用於提供根本原因的提示以及與後端遙測資料的關聯。

將可用性測試與後端的相依性及請求遙測資料結合，以快速區分端點可用性問題 (網路、DNS、TLS)、應用程式失敗 (例外狀況、逾時) 與下游服務中斷 (SQL、外部 API)。將可用性測試失敗連結到動作群組，以驅動事件工作流程。

使用 ARM 範本達成可監控性與可重複部署

Azure Resource Manager (ARM) 範本以程式碼形式宣告式地定義資源與監控組態。一個範本的結構包含：

$schema 與 contentVersion 用於識別範本版本。
parameters 用於外部化的值（例如，工作區名稱、位置、SKU）。針對機密資訊使用 secureString/secureObject。
variables 用於計算值以避免重複。
resources 用於宣告式部署 Application Insights、Log Analytics 工作區、警示規則、動作群組與診斷設定。
outputs 用於發出值，例如 Application Insights 的 connectionString，供下游部署階段使用。

使用連結或巢狀範本來組合複雜的部署。一個部署資源 (Microsoft.Resources/deployments) 透過 templateLink (外部 URI) 參考子範本，或將其內嵌。透過 parameters 或 parametersLink 傳遞參數物件，定義 dependsOn 以排序，並跨環境重複使用模組。透過 ARM 實現預設可監控性的範例如下：

部署一個 Log Analytics 工作區，並設定 workspaceResourceId 輸出，供 Application Insights 資源使用（工作區模式）。
建立 Application Insights（工作區模式）並輸出其 connectionString；避免暴露舊版的檢測金鑰。
在資源（例如 App Service、Key Vault、Storage）上啟用 Diagnostic settings，將日誌與指標串流至工作區及/或 Event Hub。
佈建 metric alerts (microsoft.insights/metricAlerts) 並設定條件與維度，以及 scheduled query alerts (microsoft.insights/scheduledQueryRules) 並使用 KQL，透過資源 ID 連結動作群組。
定義 action groups (microsoft.insights/actionGroups) 並設定電子郵件/簡訊與 webhook 接收器；將地址與端點參數化，以進行特定於環境的路由。

採用條件與複製迴圈以實現可擴展的部署（例如，將診斷設定應用於一組資源 ID）。使用 ARM 函式，例如 resourceId、subscriptionResourceId、reference、concat 與 guid，來建立動態參考與穩定的名稱。透過 ARM 或 App Service 組態資源提供的應用程式設定，集中管理 role name 慣例與取樣，以保持跨服務的遙測組態一致性。

實務問題情境

Adobe 需要為一個建構在 Azure App Service API 和 AKS 微服務上的新多區域媒體處理管線，建立端到端的觀測能力。他們要求能快速偵測延遲衰退、跨服務的分散式追蹤、對公開端點進行主動的可用性檢查，以及將事件自動路由到其 on-call 系統，並具備基礎設施即程式碼的可重複性。

使用連接字串以 Application Insights 檢測服務

設定每個 App Service 與 AKS 工作負載使用 Application Insights 連接字串，而非舊版金鑰，以確保正確的擷取端點與未來可支援的路由。為每個服務設定 cloud role names，以便進行清晰的篩選與對應。在核心 API 中選擇基於 SDK 的檢測來發出領域事件與指標；為輔助服務啟用無程式碼附加 (codeless attach)，以加速涵蓋範圍。原因：連接字串提供端點的靈活性；SDK 提供自訂遙測，而無程式碼附加則能降低導入成本。

啟用分散式追蹤與相依性追蹤

確保對外的 HTTP 客戶端與 Azure SDK 會傳播 W3C 追蹤內容；在 KQL 中驗證 operation_Id 的連續性。對於背景訊息流 (Service Bus)，確認 SDK 會注入與提取關聯性；在使用自訂標頭的地方，用 TelemetryInitializers 進行補充。原因：一致的追蹤傳播能在微服務之間產生準確的端到端延遲與故障歸因。

實作可用性測試與自訂綜合檢查

從多個地理位置為公開 API 設定 URL ping 測試，並在一個輕量級的健康狀態端點上進行內容匹配。對於需要驗證的流程（權杖獲取與媒體提交），實作一個綜合客戶端，呼叫該工作流程並發出包含執行位置與詳細訊息的 TrackAvailability 結果。原因：URL pings 提供快速的外部驗證；TrackAvailability 支援超越基本 ping 的複雜、需驗證的業務流程。

將資料集中到 Log Analytics 工作區並路由平台日誌

部署一個工作區，並在 App Services、AKS 控制平面日誌、Key Vault 與 Storage 上設定 Diagnostic settings，將日誌與指標串流到該工作區。確保 Application Insights 資源是基於工作區的，以統一查詢。原因：單一工作區能實現跨服務的 KQL，將請求、相依性與平台日誌結合起來，進行全面的調查。

建立帶有動作群組的指標與日誌警示

針對請求持續時間的百分位數與依地點區分的可用性定義指標警示，使用動態閾值，並按 cloud role name 分割。新增排程查詢警示，按操作名稱偵測錯誤突增，並使用 KQL 在 operation_Id 上進行 join，以與相依性故障建立關聯。原因：指標警示提供近乎即時的偵測；日誌警示能捕捉無法用簡單閾值表達的複雜模式。

透過動作群組與 webhooks 整合事件回應

設定一個 action group，包含給服務擁有者的電子郵件、給 on-call 負責人的簡訊，以及一個使用 Common Alert Schema 連接到 Adobe 事件平台的安全 webhook。新增一個 Logic App 接收器，用最近的 KQL 查詢結果與拓撲元資料來豐富 payload。原因：多管道通知能減少 MTTA；webhook 與 Logic App 能實現自動化工單建立與內容豐富的事件。

使用 ARM 範本將監控程式碼化

編寫 ARM 範本以部署 Log Analytics 工作區、Application Insights（工作區模式）、診斷設定、指標警示、排程查詢警示與動作群組。將環境名稱、區域與聯絡點參數化；輸出 Application Insights connectionString 供下游應用程式組態使用。對於團隊擁有的模組（平台 vs. 應用程式），使用連結範本。原因：基礎設施即程式碼確保在開發、預備與生產環境中有一致、可重複的觀測能力，並支援 CI/CD。