本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
疑難排解 Amazon DynamoDB 中的內部伺服器錯誤
在 DynamoDB 中，內部伺服器錯誤 (500 錯誤) 表示服務無法處理請求。這些錯誤可能由多種原因導致，例如機群中的暫時性網路問題、基礎設施異常或儲存節點相關問題等。
在 DynamoDB 資料表的生命週期內，您可能會遇到一些內部伺服器錯誤。由於服務的分散式架構，這屬於預期行為，通常無需特別關注。DynamoDB 會即時自動修復服務的任何暫時性問題，無需使用者介入。不過，如果您在對資料表的請求中觀察到持續高比例的內部伺服器錯誤 (如 SystemErrors 指標所示)，建議進一步調查。
調查內部伺服器錯誤
若您在 DynamoDB 資料表中發生內部伺服器錯誤，請考慮以下作法：
檢查 AWS 運作狀態儀表板。
若要識別問題，第一個步驟是檢查AWS 服務運作狀態儀表板
和 AWS 您的帳戶運作狀態儀表板。這些儀表板提供有關解決問題後任何服務範圍問題、受影響的資料表、持續問題和根本原因的寶貴資訊。 檢閱這些儀表板中的詳細資訊，可讓您更深入了解 AWS 服務 正在使用的 的目前狀態，以及影響您帳戶的任何潛在問題。此資訊可協助您決定後續行動，以解決問題並將營運中斷降至最低。
請聯絡 支援。
如果您在請求中觀察到長時間持續的錯誤，可能表示服務有問題。一般而言，如果您在過去 15 分鐘內看到整體故障率為 1% 或更高，則適合將問題呈報至 AWS 支援團隊。如需更多資訊，請參閱 DynamoDB 服務水準協議
。 向 AWS 支援團隊開立案例時，請提供下列詳細資訊，以協助加速疑難排解程序：
-
受影響的 DDB：資料表或次要索引
-
錯誤發生的觀察時間範圍
-
DynamoDB 請求 ID (例如
4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG)，可在應用程式日誌中找到。
在支援案例中包含這些詳細資訊，將有助於 AWS 團隊了解問題並提供更快的解決方法。即使沒有請求 ID，也應使用其他可用資訊建立支援案例。
-
將內部伺服器錯誤的影響降至最低
若在使用 DynamoDB 時發生內部伺服器錯誤，請採取以下最佳實務，以將對應用程式的影響降至最低：
-
使用退避與重試機制 – DynamoDB 的預設 SDK 行為設計旨在為大多數應用程式在退避與重試策略間取得最佳平衡。不過，您可根據應用程式對停機時間的容忍度與效能需求調整這些設定。進一步了解退避與重試機制，以掌握如何微調重試設定。
-
使用最終一致讀取 – 若應用程式不需高度一致性讀取，建議採用最終一致讀取。此類讀取成本較低，且較不易因內部伺服器錯誤而遭遇暫時性問題，因其可由任一可用儲存節點提供。如需詳細資訊，請參閱DynamoDB 讀取一致性。
提升營運覺察
在現今數位環境中，維持應用程式的高可用性與可靠性至關重要。其中一個關鍵作法是主動監控 DynamoDB 資料表與全域次要索引 (GSI) 中的內部伺服器錯誤 (ISE)。透過建立 CloudWatch 警示監控這些錯誤，您可提升營運覺察，並在潛在問題影響最終使用者前收到通知。此方法符合 AWS Well-Architected Framework 的卓越營運支柱，確保您的 DynamoDB 工作負載已針對效能、安全性和可靠性進行最佳化。
建立 CloudWatch 警示
應在 DynamoDB 資料表上設定 CloudWatch 警示，以接收持續高比例內部伺服器錯誤的通知，而非手動監控指標。這與 Well-Architected 架構中任何工作負載的卓越營運支柱有關 AWS。如需進一步了解如何依 Well-Architecting 原則設計您的 DynamoDB 資料表，請參閱 使用 DynamoDB Well-Architected Lens 來最佳化您的 DynamoDB 工作負載。
當您在SystemErrors指標上建立警示時，請同時指定 TableName和 Operation維度 （或全域次要索引GlobalSecondaryIndexName的 TableName和 )。DynamoDB SystemErrors會在每次操作時發出，而不是TableName單獨發出，因此指定 的警示只會TableName保持在 INSUFFICIENT_DATA 狀態，永遠不會發出警示。
