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:
Überprüfen Sie das AWS Health Dashboard.
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 zu allen dienstweiten Problemen, den betroffenen Tabellen, laufenden Problemen und der Ursache nach der Behebung des Problems. Wenn Sie sich die Details in diesen Dashboards ansehen, erhalten Sie einen besseren Überblick über den aktuellen Status der von AWS-Services Ihnen verwendeten Software 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 in Ihren Anfragen länger andauernde, anhaltende Fehler feststellen, kann dies auf ein Problem mit dem Service hinweisen. In der Regel gilt: Wenn Sie in den letzten 15 Minuten eine Gesamtausfallrate von 1% oder mehr feststellen, ist es ein geeigneter Zeitpunkt, 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 die Fehlerbehebung 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 den Support-Fall 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). Durch die Einrichtung von CloudWatch Alarmen zur Überwachung dieser Fehler können Sie einen besseren Überblick über den Betrieb gewinnen und sich vor potenziellen Problemen warnen lassen, bevor sie sich auf Ihre Endbenutzer auswirken. Dieser Ansatz steht im Einklang mit dem Grundpfeiler 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 in Ihren DynamoDB-Tabellen CloudWatch Alarme eingerichtet haben, um Benachrichtigungen für eine konstant hohe Anzahl interner Serverfehler zu erhalten, anstatt die Metriken manuell zu beobachten. Dies steht im Einklang mit dem Grundpfeiler „Operational Excellence“ des Well-Architected Frameworks für alle Workloads. AWS Weitere Informationen Verwenden der Well-Architected DynamoDB-Linse 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 sowohl die als auch die TableName Operation Dimensionen an (oder TableName und GlobalSecondaryIndexName für einen globalen sekundären Index). DynamoDB sendet SystemErrors pro Vorgang, nicht nur bei Aktivierung, also einen TableName Alarm, der angibt, dass nur der INSUFFICIENT_DATA Status beibehalten wird und TableName niemals eine Warnung ausgegeben wird.