在無伺服器架構中，監控和觀測性至關重要。構建關鍵健康儀錶板能提供系統整體運作狀態的概覽，整合速率、錯誤和持續時間等關鍵指標，快速判斷系統是否正常。然而，僅憑儀錶板不足以捕捉所有異常，還需搭配警示機制。根據能力的警示，著重於系統關鍵功能的健康狀態，避免過多細粒度指標警示造成的雜訊幹擾，更有效地指示問題所在。同時，服務等級目標（SLO）和服務等級指標（SLI）的設定，能量化服務品質和可靠性，確保服務符合預期水準。服務追蹤則透過追蹤段、子追蹤段、註解、中繼資料和異常等核心元件，提供深入的應用程式行為分析，協助診斷效能瓶頸和錯誤。
關鍵健康儀錶板
在第7章中，我們討論了測試的重要性，現在讓我們來看看如何將這種思維應用於營運。營運也可以從關注關鍵路徑中受益，但即使是關鍵路徑，也會有一些方面比其他方面更重要，特別是在評估大規模營運健康和效能時。您可以使用RED方法來評估系統和服務的關鍵健康狀況：
- 速率：接收請求的速率
- 錯誤：請求失敗的數量
- 持續時間：回應請求所需的時間
當推出新功能、服務或產品時，建立一個關鍵健康儀錶板是非常有用的，該儀錶板顯示核心元件的速率、錯誤和持續時間（見圖8-3）。此儀錶板應該收集應用程式或微服務中的所有關鍵指標，以提供系統健康狀況的單一檢視。一眼就可以立即回答“一切是否正常？”的問題。當然，在分散式無伺服器應用程式中，總是會有很多細微差別和隱藏元素對整體健康狀況有所影響，但這至少可以提供一個開始評估關鍵健康狀況的地方。
在發布程式碼變更到生產環境後，您可以使用儀錶板來監控變更的影響並及時發現任何錯誤。但是，您應該依靠警示來捕捉隨時間推移而出現的錯誤和暫時性故障，而不是不斷地觀察儀錶板。
使用關鍵健康儀錶板來發現潛在的異常效能。尋找圖表中的尖峰和曲線、觸發的警示以及第三方的狀態報告。關鍵健康儀錶板還可以包含有關使用中的服務、正在監控的關鍵指標以及連結（或如果有合適的API提供，即動態資料）到第三方狀態頁面的資訊。以這種方式構建全面儀錶板將使組織中的廣大人員能夠使用它來進行評估，而無需對被觀察到的系統有深入的瞭解。
雖然關鍵健康儀錶板可以在某些高壓情況下提供即時的安慰，例如產品發布和銷售活動，但您應該記住，它更有用（也更準確）的是將無伺服器應用程式作為一組不同的應用程式進行營運和觀察。如果您遵循本文中提供的指導，您將盡可能小心地解耦無伺服器微服務。這種故意的隔離應該繼續到營運，並且您應該抵制試圖將解耦服務作為一個整體系統進行監控的temptation。
能力警示
想象一下以下情景：您花了幾周時間設計和構建美麗的無伺服器架構，現在是發布它給使用者的時候了。但您認識到，一個勤奮的無伺服器工程師永遠不會在生產環境中營運一個沒有警示的應用程式。否則，您如何知道使用者是否遇到錯誤，如果他們沒有告訴您？您退一步，檢視系統中的所有元件：API Gateway REST API、多個由Lambda函式和Step Functions工作流程組成的微服務、DynamoDB表格來儲存應用程式狀態，以及多個連線所有服務在一起的EventBridge規則。您想知道哪些指標很重要以及何時應該觸發警示。哪些部分需要知道是否已經壞了，何時壞了？
接下來的是一個過於常見的經驗。具有大量針對非常具體指標和閾值的警示後，您的工程師很快就會被許多警示淹沒，其中很多是假陽性（閾值太低或選定的指標不正確）或被認為是可以接受的（“這通常失敗”）或預期的（“那是一個已知錯誤”）。
雖然這是一種引入警示到可觀測性實踐的完全可接受的開始（而且比沒有警示要好），但您應該知道有一種替代方法。根據能力的警示涉及評估系統或服務中關鍵元件或服務的整體健康狀況。假設系統的一個關鍵能力是生成PDF並將其儲存在S3。在這種情況下，您會將工作流程中此功能的各個元件的指標結合起來，形成對此服務健康狀況的整體概念，並在CloudWatch複合警示中建立可接受效能的基線。然後，您會在此閾值被突破時收到警示，並且會知道此功能的效能已經惡化到需要立即關注的地步。如果沒有根據能力的警示，您將會收到多個與特定資源指標相關的警示，這將會產生很多噪音，並且無法有效地指出需要關注哪個領域進行初始除錯工作。
理想情況下，您希望根據系統能力的健康狀況收到警示（見圖8-4）。監控整個系統的健康狀況太過寬泛，無法提供可行的見解，而監控系統元件的健康狀況又太過細膩，無法提供任何有用的指示。
服務等級目標（SLO）與觀測性
在設計和營運服務時，瞭解服務的品質和可靠性至關重要。服務等級目標（Service Level Objectives, SLOs）是一種用於衡量服務品質的方法，它定義了服務的效能和可靠性標準。SLOs 根據這樣一個認識：服務不可能永遠保持 100% 的成功率，必然會出現一些故障和失敗。因此，SLOs 的目的是確定在什麼條件下，服務的故障和失敗對使用者經驗的影響是可以接受的。
服務等級指標（SLIs）
服務等級指標（Service Level Indicators, SLIs）是用於衡量服務效能和可靠性的指標。SLIs 通常是二元的，例如，API 的回應時間是否在 6 秒內。根據 SLIs，可以設定 SLOs，例如，99.98% 的 API 請求需要在 6 秒內回應。
設定 SLOs
設定 SLOs 時，需要考慮使用者對服務品質的期望和容忍度。SLOs 應該設定在使用者開始感到明顯不滿之前的門檻以下。這樣，可以在不影響使用者信任和滿意度的情況下，允許一定程度的故障和失敗。
分離「什麼」和「為什麼」
在觀測性工程中，分離「什麼」和「為什麼」是非常重要的。警示和通知應該只告訴你「什麼」出了問題，而不是「為什麼」出了問題。後者需要透過日誌、追蹤、指標和儀錶板等工具來進行調查和分析。
事件驅動日誌
日誌是觀測性的重要組成部分，但在無伺服器應用中，日誌可能被過度使用，導致成本增加和安全問題。事件驅動日誌是一種更有效的方法，日誌應該只記錄事件的發生和 payload，而不是所有細節。使用標準事件封套，如 CloudEvents，可以確保日誌資料的一致性和查詢能力。
分散式追蹤
分散式追蹤是理解無伺服器系統行為的關鍵工具。它可以跨多個微服務和管理服務跟蹤請求和事件，提供系統整體健康狀態的檢視。AWS X-Ray 是一種原生的分散式追蹤解決方案，與 Amazon CloudWatch 完全整合，可以用於組態應用程式收集追蹤資料，並分析系統行為和效能。
服務追蹤的核心元件
服務追蹤是一種用於監控和分析應用程式行為的技術，特別是在無伺服器架構中。它涉及收集和分析應用程式的追蹤資料，以便更好地瞭解其效能、錯誤和瓶頸。以下是服務追蹤的核心元件：
1. 追蹤段（Segments）
追蹤段是指應用程式中的一個特定操作或請求，例如呼叫 API Gateway REST 端點或呼叫 Lambda 函式。每個追蹤段都包含有關該操作的詳細資訊，例如請求 URL 和方法、HTTP 回應程式碼以及請求的總持續時間。
2. 子追蹤段（Subsegments）
子追蹤段是指在一個追蹤段內進行的更細粒度的操作。例如，在一個呼叫 Lambda 函式的追蹤段中，每個步驟或任務都可以被表示為一個子追蹤段。子追蹤段包含與追蹤段相同的資訊，但更為細緻。
3. 註解（Annotations）
註解是指可以新增到追蹤資料中的鍵值對，以提供額外的上下文資訊。註解可以被索引，允許您根據註解資料過濾和分組追蹤資料。
4. 中繼資料（Metadata）
中繼資料是指可以附加到追蹤資料中的額外資訊，以提供更多上下文。中繼資料不會被用於搜尋追蹤資料，但可以在分析追蹤資料時提供有用的資訊。
5. 異常（Exceptions）
異常是指在執行儀表化請求時發生的錯誤。當異常發生時，追蹤資料將包含有關異常的詳細資訊，包括錯誤訊息和堆積疊跟蹤（如果可用）。
隨著無伺服器應用程式日益普及，有效監控其運作效能變得至關重要。本文探討了從關鍵健康儀錶板到服務追蹤等一系列監控策略，這些策略有效結合了指標、日誌和追蹤等不同導向。分析顯示，根據能力的警示能有效降低警示噪音，並提供更具體的行動方向，而服務等級目標（SLO）則能確保服務品質符合預期。然而，實務上，設定合理的SLO和SLI需要深入理解業務需求和使用者行為，這對許多團隊來說仍是一大挑戰。展望未來，自動化SLO管理和根據AI的異常檢測將成為重要的發展趨勢，進一步簡化監控流程並提升效率。玄貓認為，結合本文提出的監控策略，並持續關注新興技術，才能有效掌握無伺服器應用程式的運作狀況，確保系統穩定性和使用者經驗。
