無伺服器應用程式由於其分散式特性及自動擴充套件機制，使得傳統的監控方式難以有效運作。開發者需要更專注於各服務的關鍵指標與整合性的監控策略，才能確保應用程式穩定執行。本文除了介紹 AWS 常見服務的監控重點外，也強調了合成監控的重要性，並提供設定警示的最佳實務，以協助開發者建立更完善的無伺服器應用程式監控系統。
伺服器無法執行的挑戰
在無伺服器架構中，執行應用程式的挑戰與傳統伺服器架構不同。無伺服器架構的特點是自動擴充套件和按需付費，對於開發人員和維運人員來說，這是一個新的挑戰。
自動擴充套件和按需付費
無伺服器架構中的自動擴充套件和按需付費是其主要優點之一。開發人員可以根據實際需求動態擴充套件應用程式，而不需要關心底層基礎設施。然而，這也意味著開發人員需要了解其應用程式的擴充套件單位和成本，以避免意外的費用。
應用程式監控和除錯
在無伺服器架構中，應用程式監控和除錯更加複雜。由於沒有傳統的伺服器日誌和監控資料，開發人員需要使用新的工具和方法來監控和除錯其應用程式。
伺服器無法執行的趨勢
伺服器無法執行的趨勢是將業務邏輯從自定義程式碼轉移到應用程式整合。這意味著開發人員需要更多地關注應用程式之間的整合和工作流程，而不是自定義程式碼。
###bug 和執行時錯誤
在無伺服器架構中，bug 和執行時錯誤更加難以預測和修復。由於應用程式的複雜性和動態性，bug 和執行時錯誤可能會在執行時出現，而不是在開發階段。
解決方案
為瞭解決這些挑戰，開發人員需要採用新的方法和工具，例如：
- 使用雲原生監控和除錯工具
- 實作自動擴充套件和按需付費
- 集中於應用程式整合和工作流程
- 使用新的除錯和故障排除方法
透過採用這些方法和工具，開發人員可以更好地應對無伺服器架構中的挑戰，並打造更加可靠和高效的應用程式。
圖表翻譯：
graph LR
A[無伺服器架構] --> B[自動擴充套件和按需付費]
B --> C[應用程式監控和除錯]
C --> D[伺服器無法執行的趨勢]
D --> E[_bug_ 和執行時錯誤]
E --> F[解決方案]
F --> G[雲原生監控和除錯工具]
G --> H[實作自動擴充套件和按需付費]
H --> I[集中於應用程式整合和工作流程]
I --> J[使用新的除錯和故障排除方法]
內容解密：
以上內容介紹了無伺服器架構中的挑戰和解決方案。無伺服器架構的自動擴充套件和按需付費是其主要優點之一，但也帶來了新的挑戰，例如應用程式監控和除錯的複雜性。伺服器無法執行的趨勢是將業務邏輯從自定義程式碼轉移到應用程式整合，這意味著開發人員需要更多地關注應用程式之間的整合和工作流程。bug 和執行時錯誤在無伺服器架構中更加難以預測和修復，因此開發人員需要採用新的方法和工具來解決這些挑戰。
瞭解伺服器無法預測的擴充套件挑戰
在設計伺服器無法預測的擴充套件時，瞭解各個 AWS 服務的限制和配額是非常重要的。每個服務都有其自己的限制和配額，例如 Kinesis 流的輸入和傳遞緩衝區限制、DynamoDB 的讀寫容量限制和 API Gateway 的回應延遲追蹤。
服務限制和配額
AWS 服務的限制和配額是設計伺服器無法預測的擴充套件的重要考量。瞭解這些限制和配額可以幫助您設計出更好的架構和選擇合適的服務。例如，Lambda 函式有其自己的限制，例如並發執行數量和記憶體使用量，而 API Gateway 有其自己的限制，例如請求數量和回應延遲。
伺服器無法預測的擴充套件挑戰
伺服器無法預測的擴充套件挑戰包括：
- 瞭解服務限制和配額
- 設計合適的架構
- 選擇合適的服務
- 監控和最佳化服務效能
伺服器無法預測的觀察性
伺服器無法預測的觀察性是指在設計伺服器無法預測的擴充套件時，需要考慮系統的觀察性。觀察性是指系統可以被檢視和分析以瞭解其行為、效能和健康狀態。
觀察性的重要性
觀察性對於伺服器無法預測的擴充套件至關重要，因為它可以幫助您：
- 瞭解系統的行為和效能
- 快速定位和解決問題
- 最佳化系統的效能和可擴充套件性
觀察性的實作
觀察性的實作可以透過以下方式：
- 使用監控工具和技術
- 設計合適的架構和選擇合適的服務
- 實作日誌和追蹤機制
伺服器無法預測的關鍵路徑觀察
伺服器無法預測的關鍵路徑觀察是指在設計伺服器無法預測的擴充套件時，需要關注系統的關鍵路徑。關鍵路徑是指系統中最重要的部分，需要始終保持運作。
關鍵路徑觀察的重要性
關鍵路徑觀察對於伺服器無法預測的擴充套件至關重要，因為它可以幫助您：
- 瞭解系統的關鍵路徑
- 快速定位和解決問題
- 最佳化系統的效能和可擴充套件性
關鍵路徑觀察的實作
關鍵路徑觀察的實作可以透過以下方式：
- 使用監控工具和技術
- 設計合適的架構和選擇合適的服務
- 實作日誌和追蹤機制
內容解密
上述內容解釋了設計伺服器無能預測的擴充套件需要考慮哪些因素，包括服務限制和配額、系統觀察性和關鍵路徑觀察。這些因素對於設計伺服器無法預測的擴充套件至關重要，可以幫助您設計出更好的架構和選擇合適的服務。
graph LR
A[服務限制和配額] --> B[系統觀察性]
B --> C[關鍵路徑觀察]
C --> D[設計伺服器無法預測的擴充套件]
圖表翻譯
上述圖表展示了設計伺服器無法預測的擴充套件需要考慮哪些因素，包括服務限制和配額、系統觀察性和關鍵路徑觀察。這些因素之間存在著密切的關係，需要綜合考慮才能設計出更好的架構和選擇合適的服務。
瞭解伺服器無法觀察的重要性
在無伺服器架構中，觀察和監控系統的效能和健康狀態至關重要。這是因為無伺服器應用程式通常具有複雜的架構，難以預測和控制。因此，實作有效的觀察和監控機制以確保系統的可靠性和效率至關重要。
DynamoDB 監控
DynamoDB 提供了多個監控指標，包括 ConsumedReadCapacityUnits、ConsumedWriteCapacityUnits 和 ThrottledRequests，以幫助您瞭解表格的效能和健康狀態。您還可以設定警示來監控這些指標，以便在發生問題時及時發現和處理。
SQS 監控
SQS 的 ApproximateAgeOfOldestMessage 指標可以幫助您瞭解佇列中最舊的訊息的狀態。您可以設定警示來監控這個指標，以便在訊息超過最大保留期時及時發現和處理。
Kinesis Firehose 監控
Kinesis Firehose 提供了多個監控指標，包括 DataFreshness 和 Success，以幫助您瞭解資料處理的效率和健康狀態。您還可以監控 ThrottledRecords 指標來瞭解流處理錯誤的狀態。
EventBridge 監控
EventBridge 提供了多個監控指標，包括 TriggeredRules 和 DeadLetterInvocations，以幫助您瞭解規則觸發和事件傳遞的狀態。您還可以監控 FailedInvocations 指標來瞭解目標接收事件的狀態。
合成監控
合成監控涉及向您的應用程式傳送人工流量，以測試其功能和效能。這種方法可以幫助您瞭解低流量臨界路徑的效能和健康狀態。您可以使用 Amazon CloudWatch Synthetics 來實作合成監控。
度量、警示和警示
度量是提供系統效能和健康狀態洞察力的資料。警示是指當度量超過某個閾值時觸發的動作。警示是指當警示觸發時執行的動作，例如傳送訊息或建立錯誤報告。合理使用度量、警示和警示可以幫助您及時發現和處理系統問題。
警示屬性
一個好的警示應該具有以下屬性：
- 明顯：使用者經驗或臨界路徑的影回應該是明顯的。
- 可行：警示應該與明確的動作相關聯。
- 獨特：警示應該是唯一的。問題不應該由多個警示反映。你應該為每個不同的問題接收一個警示。
服務級別目標和能力警示
服務級別目標和能力警示可以幫助您決定使用哪些度量和指標來觸發警示，並將噪音降至最低。這些概念將在後面的章節中進行介紹。
從系統架構的整體性視角來看，構建穩定可靠的無伺服器應用程式，除了需掌握各服務的特性與限制外，更需建立全面的監控與告警機制。本文深入探討了無伺服器架構中，從自動擴充套件的成本控制、應用程式除錯的複雜性，到服務整合趨勢帶來的挑戰，並針對 DynamoDB、SQS、Kinesis Firehose 和 EventBridge 等關鍵服務，提供了具體的監控指標建議。尤其值得注意的是，合成監控的應用能有效彌補低流量情境下，傳統監控方式的不足，進一步提升系統穩定性。然而，僅僅堆積疊監控指標並不足夠，如何有效地設定警示，避免告警疲勞，才是真正考驗技術團隊功力之處。玄貓認為，開發團隊應著重於定義清晰、可操作且唯一的警示策略，並結合服務級別目標(SLO)與容量規劃，才能將監控系統的效能最大化，確保無伺服器應用程式在高度彈性與複雜性兼具的環境下，持續穩定地提供服務。未來，隨著無伺服器技術的持續發展，預期將出現更自動化、更智慧化的監控與告警解決方案，進一步簡化開發流程，降低營運成本。
