Beheben interner Serverfehler in Amazon DynamoDB - Amazon DynamoDB
Untersuchen interner ServerfehlerMinimieren der Auswirkungen interner ServerfehlerVerbessern der operativen Einblicke

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.

Untersuchen interner Serverfehler

Wenn Sie in Ihrer DynamoDB-Tabelle auf interne Serverfehler stoßen, sollten Sie die folgenden Optionen in Betracht ziehen:

  1. Überprüfen Sie das AWS Health Dashboard.

    Um das Problem zu ermitteln, überprüfen Sie zunächst das AWSService Health Dashboard und Ihr AWS Account Health Dashboard. Diese Dashboards bieten wertvolle Informationen zu allen serviceweiten Problemen, betroffenen Tabellen, andauernden Problemen sowie der Ursache, sobald das Problem behoben wurde.

    Wenn Sie sich die Informationen in diesen Dashboards ansehen, erhalten Sie einen besseren Überblick über den aktuellen Status der von Ihnen verwendeten AWS-Services sowie ü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.

  2. Wenden Sie sich an Support.

    Wenn Sie in Ihren Anforderungen 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 Gesamtfehlerrate 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 beim 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 Informationen in den Supportfall aufnehmen, kann das AWS-Team das Problem besser nachvollziehen und schneller lösen. 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 Erstellung von CloudWatch-Alarmen zur Überwachung dieser Fehler können Sie bessere operative Einblicke gewinnen und sich vor potenziellen Problemen warnen lassen, bevor sie sich auf Ihre Endbenutzer auswirken. Dieser Ansatz steht im Einklang mit der Säule „Operational Excellence“ des AWS Well-Architected Framework und stellt sicher, dass Ihr DynamoDB-Workload im Hinblick auf Leistung, Sicherheit und Zuverlässigkeit optimiert ist.

Erstellen von CloudWatch-Alarmen

Sie sollten CloudWatch-Alarme für Ihre DynamoDB-Tabellen einrichten, 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 der operativen Exzellenz des Well-Architected Framework für alle Workloads auf AWS. Weitere Informationen zum Aufbau einer optimalen Architektur Ihrer DynamoDB-Tabellen finden Sie unter Verwenden der DynamoDB Well-Architected Lens zur Optimierung Ihres DynamoDB-Workloads.

Diese Alarme verwenden benutzerdefinierte Metrikberechnungen, um den Prozentsatz fehlgeschlagener Anforderungen für ein 5-Minuten-Fenster zu berechnen. Es wird empfohlen, den Alarm so zu konfigurieren, dass er in den ALARM-Status wechselt, wenn drei aufeinanderfolgende Datenpunkte den Schwellenwert von 1 % überschreiten, was bedeutet, dass insgesamt 1 % der Anforderungen innerhalb eines Zeitraums von 15 Minuten fehlschlagen.

Das folgende Beispiel ist eine CloudFormation-Vorlage, mit der Sie CloudWatch-Alarme für Ihre Tabelle und den GSI für die Tabelle erstellen können.

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'