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.
In DynamoDB deuten interne Serverfehler (500 Fehler) darauf hin, dass der Dienst die Anforderung nicht bearbeiten kann. Diese Fehler können aus verschiedenen Gründen auftreten, 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 Dienstes 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
Untersuchung 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, betroffenen Tabellen, laufenden Problemen und der Ursache, sobald das Problem behoben wurde. 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ärindizes
-
Zeitfenster, in dem die Fehler beobachtet wurden
-
DynamoDB-Anfrage IDs, z. B.
4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG, die Sie in Ihren Anwendungsprotokollen finden.
Wenn Sie diese Details in den Support-Fall aufnehmen, kann das AWS Team das Problem besser verstehen und es schneller lösen. Wenn Ihnen die Anfrage nicht vorliegt IDs, sollten Sie den Fall trotzdem mit den anderen verfügbaren Details protokollieren.
-
Minimierung 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:
-
Verwenden Sie Backoffs und Wiederholungsversuche — Das standardmäßige SDK-Verhalten von DynamoDB ist darauf ausgelegt, für die meisten Anwendungen das richtige Gleichgewicht in Bezug auf Back-off- und Wiederholungsstrategie zu finden. Sie können diese Einstellungen jedoch an die Toleranz Ihrer Anwendung in Bezug auf Ausfallzeiten und die Leistungsanforderungen anpassen. Erfahren Sie mehr über Back-offs und Wiederholungsversuche, um zu erfahren, wie Sie diese Einstellungen für Wiederholungen optimieren können.
-
Eventuell konsistente Lesevorgänge verwenden — Wenn Ihre Anwendung keine stark konsistenten Lesevorgänge erfordert, sollten Sie eventuell konsistente Lesevorgänge verwenden. Diese Lesevorgänge sind kostengünstiger und es ist weniger wahrscheinlich, dass es aufgrund interner Serverfehler zu vorübergehenden Problemen kommt, da sie von einem der verfügbaren Speicherknoten aus bedient würden. Weitere Informationen finden Sie unter DynamoDB-Lesekonsistenz.
Verbesserung des betrieblichen Bewusstseins
Die Aufrechterhaltung einer hohen Verfügbarkeit und Zuverlässigkeit Ihrer Anwendungen ist in der heutigen digitalen Landschaft von entscheidender Bedeutung. Ein wichtiger Aspekt dabei ist die proaktive Überwachung auf interne Serverfehler (ISEs) in Ihren DynamoDB-Tabellen und globalen Sekundärindizes (). GSIs 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 Framework 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 der Säule Operational Excellence des Well-Architected-Frameworks für alle Workloads. AWS Weitere Informationen Verwenden der DynamoDB Well-Architected Lens zur Optimierung Ihres DynamoDB-Workloads zur Well-Architecting Ihrer DynamoDB-Tabellen finden Sie unter.
Diese Alarme verwenden benutzerdefinierte metrische Berechnungen, um den Prozentsatz fehlgeschlagener Anfragen für ein 5-Minuten-Fenster zu berechnen. Es wird empfohlen, den Alarm so zu konfigurieren, dass er in den ALARM Status wechselt, wenn 3 aufeinanderfolgende Datenpunkte den Schwellenwert von 1% überschreiten, was bedeutet, dass insgesamt 1% der Anfragen innerhalb eines Zeitraums von 15 Minuten fehlschlagen.
Das folgende Beispiel ist eine AWS CloudFormation Vorlage, die Ihnen helfen kann, CloudWatch Alarme für Ihre Tabelle und GSI für die Tabelle zu erstellen.
AWSTemplateFormatVersion: "2010-09-09"
Description: Sample template for monitoring DynamoDB
Parameters:
DynamoDBProvisionedTableName:
Description: Name of DynamoDB Provisioned Table to create
Type: String
MinLength: 3
MaxLength: 255
ConstraintDescription : https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html#limits-naming-rules
DynamoDBSNSEmail:
Description : Email Address subscribed to newly created SNS Topic
Type: String
AllowedPattern: "^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+$"
MinLength: 1
MaxLength: 255
Resources:
DynamoDBMonitoringSNSTopic:
Type: AWS::SNS::Topic
Properties:
DisplayName: DynamoDB Monitoring SNS Topic
Subscription:
- Endpoint: !Ref DynamoDBSNSEmail
Protocol: email
TopicName: dynamodb-monitoring
DynamoDBTableSystemErrorAlarm:
Type: 'AWS::CloudWatch::Alarm'
Properties:
AlarmName: 'DynamoDBTableSystemErrorAlarm'
AlarmDescription: 'Alarm when system errors exceed 1% of total number of requests for 15 minutes'
AlarmActions:
- !Ref DynamoDBMonitoringSNSTopic
Metrics:
- Id: 'e1'
Expression: 'm1/(m1+m2+m3)'
Label: SystemErrorsOverTotalRequests
- Id: 'm1'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'SystemErrors'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
- Id: 'm2'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'ConsumedReadCapacityUnits'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
- Id: 'm3'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'ConsumedWriteCapacityUnits'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
EvaluationPeriods: 3
Threshold: 1.0
ComparisonOperator: 'GreaterThanThreshold'
DynamoDBGSISystemErrorAlarm:
Type: 'AWS::CloudWatch::Alarm'
Properties:
AlarmName: 'DynamoDBGSISystemErrorAlarm'
AlarmDescription: 'Alarm when GSI system errors exceed 2% of total number of requests for 15 minutes'
AlarmActions:
- !Ref DynamoDBMonitoringSNSTopic
Metrics:
- Id: 'e1'
Expression: 'm1/(m1+m2+m3)'
Label: GSISystemErrorsOverTotalRequests
- Id: 'm1'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'SystemErrors'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
- Name: 'GlobalSecondaryIndexName'
Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
- Id: 'm2'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'ConsumedReadCapacityUnits'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
- Name: 'GlobalSecondaryIndexName'
Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
- Id: 'm3'
MetricStat:
Metric:
Namespace: 'AWS/DynamoDB'
MetricName: 'ConsumedWriteCapacityUnits'
Dimensions:
- Name: 'TableName'
Value: !Ref DynamoDBProvisionedTableName
- Name: 'GlobalSecondaryIndexName'
Value: !Join [ '-', [!Ref DynamoDBProvisionedTableName, 'gsi1'] ]
Period: 300
Stat: 'SampleCount'
Unit: 'Count'
ReturnData: False
EvaluationPeriods: 3
Threshold: 1.0
ComparisonOperator: 'GreaterThanThreshold'