Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Beheben interner Serverfehler in Amazon DynamoDB
In DynamoDB deuten interne Serverfehler (500-Fehler) darauf hin, dass der Service die Anforderung nicht bearbeiten kann. Diese Fehler können aus verschiedenen Gründen auftreten, darunter z. B. vorübergehende Netzwerkprobleme in der Flotte, Infrastrukturprobleme, Probleme im Zusammenhang mit Speicherknoten und mehr.
Während des Lebenszyklus Ihrer DynamoDB-Tabelle können einige interne Serverfehler auftreten. Dies ist aufgrund des verteilten Charakters des Service zu erwarten und sollte in der Regel kein Grund zur Sorge sein. DynamoDB repariert und behebt automatisch alle vorübergehenden Probleme mit dem Service in Echtzeit, ohne dass Sie eingreifen müssen. Wenn Sie jedoch eine konstant hohe Anzahl interner Serverfehler bei Anfragen an Ihre Tabelle beobachten (wie in der SystemErrors-Metrik dargestellt), sollten Sie weitere Untersuchungen durchführen.
Themen
Untersuchen interner Serverfehler
Wenn Sie in Ihrer DynamoDB-Tabelle auf interne Serverfehler stoßen, sollten Sie die folgenden Optionen in Betracht ziehen:
Sieh dir das AWS Health Dashboard an.
Um das Problem zu identifizieren, überprüfen Sie zunächst das AWS Service Health Dashboard
und Ihr AWS Account Health Dashboard. Diese Dashboards bieten wertvolle Informationen über alle serviceweiten Probleme, die betroffenen Tabellen, die laufenden Probleme und die Ursache, nachdem das Problem behoben wurde. Wenn Sie die Details in diesen Dashboards überprüfen, erhalten Sie einen besseren Überblick über den aktuellen Status des von AWS-Services Ihnen verwendeten Dashboards und über mögliche Probleme, die Ihr Konto betreffen. Anhand dieser Informationen können Sie die nächsten Schritte zur Behebung des Problems und zur Minimierung von Betriebsunterbrechungen festlegen.
Wenden Sie sich an. Support
Wenn Sie längere, anhaltende Fehler in Ihren Anfragen feststellen, könnte dies auf ein Problem mit dem Dienst hinweisen. In der Regel gilt: Wenn Sie in den letzten 15 Minuten eine Gesamtfehlerrate von 1% oder mehr feststellen, ist dies ein geeigneter Zeitpunkt, um das Problem an das AWS Support-Team weiterzuleiten. Weitere Informationen finden Sie unter DynamoDB Service Level Agreement
. Wenn Sie einen Fall mit dem AWS Support-Team eröffnen, geben Sie die folgenden Informationen an, um den Fehlerbehebungsprozess zu beschleunigen:
-
Betroffene DDB; Tabellen oder sekundäre Indizes
-
Zeitfenster, in dem die Fehler festgestellt wurden
-
DynamoDB-Anforderungs-IDs, wie z. B.
4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG. Diese finden Sie in Ihren Anwendungsprotokollen.
Wenn Sie diese Details in die Support-Anfrage aufnehmen, kann das AWS Team das Problem besser verstehen und eine schnellere Lösung finden. Wenn Sie die Anforderungs-IDs nicht zur Hand haben, sollten Sie den Fall trotzdem mit den anderen verfügbaren Details protokollieren.
-
Minimieren der Auswirkungen interner Serverfehler
Wenn bei der Verwendung von DynamoDB interne Serverfehler auftreten, minimieren Sie deren Auswirkungen auf Ihre Anwendung. Beachten Sie dabei die folgenden bewährten Methoden:
-
Backoffs und Wiederholversuche verwenden: Das SDK-Standardverhalten von DynamoDB ist so konzipiert, dass es für die meisten Anwendungen die richtige Balance zwischen Backoff- und Wiederholungsstrategie findet. Sie können diese Einstellungen jedoch an die Toleranz Ihrer Anwendung in Bezug auf Ausfallzeiten und Leistungsanforderungen anpassen. Erfahren Sie mehr über Backoffs und Wiederholversuche, um nachzuvollziehen, wie Sie diese Einstellungen für Wiederholversuche optimieren können.
-
Letztendlich konsistente Lesevorgänge verwenden: Wenn Ihre Anwendung keine strikt konsistenten Lesevorgänge erfordert, sollten Sie die Verwendung letztendlich konsistenter Lesevorgänge in Betracht ziehen. Diese Lesevorgänge sind kostengünstiger und es ist weniger wahrscheinlich, dass vorübergehende Probleme aufgrund interner Serverfehler auftreten, da sie von einem der verfügbaren Speicherknoten aus verarbeitet würden. Weitere Informationen finden Sie unter DynamoDB-Lesekonsistenz.
Verbessern der operativen Einblicke
Die Aufrechterhaltung einer hohen Verfügbarkeit und Zuverlässigkeit Ihrer Anwendungen ist in der digitalen Landschaft von heute von entscheidender Bedeutung. Ein wichtiger Aspekt dabei ist die proaktive Überwachung Ihrer DynamoDB-Tabellen und globalen sekundären Indizes (GSIs) auf interne Serverfehler (ISEs). Indem Sie CloudWatch Alarme zur Überwachung dieser Fehler einrichten, können Sie sich einen besseren Überblick über den Betrieb verschaffen und auf potenzielle Probleme aufmerksam gemacht werden, bevor sich diese auf Ihre Endbenutzer auswirken. Dieser Ansatz steht im Einklang mit der Säule Operational Excellence des AWS Well-Architected Frameworks und stellt sicher, dass Ihr DynamoDB-Workload im Hinblick auf Leistung, Sicherheit und Zuverlässigkeit optimiert ist.
CloudWatch Alarme erstellen
Sie sollten CloudWatch Alarme in Ihren DynamoDB-Tabellen einrichten, um Benachrichtigungen für eine konstant hohe Anzahl interner Serverfehler zu erhalten, anstatt die Messobjekte manuell zu beobachten. Dies steht im Zusammenhang mit der Säule „Operational Excellence“ des Well-Architected Frameworks für alle anfallenden Workloads. AWS Weitere Informationen Verwenden Sie DynamoDB Well-Architected Lens zur Optimierung Ihrer DynamoDB-Arbeitslast zu Well-Architecting Ihren DynamoDB-Tabellen finden Sie unter.
Wenn Sie einen Alarm für die SystemErrors Metrik erstellen, geben Sie beide Operation Dimensionen TableName und an (oder TableName und GlobalSecondaryIndexName für einen globalen sekundären Index). DynamoDB sendet SystemErrors pro Vorgang, nicht nur bei eingeschaltetem Vorgang. Ein TableName Alarm, der diese Angabe enthält, TableName bleibt also nur im INSUFFICIENT_DATA Status und gibt keine Warnmeldungen aus.
