Risoluzione degli errori interni del server in Amazon DynamoDB - Amazon DynamoDB
Analisi degli errori interni del serverRidurre al minimo l'impatto degli errori interni del serverMigliorare la consapevolezza operativa

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione degli errori interni del server in Amazon DynamoDB

In DynamoDB, gli errori interni del server (500 errori) indicano che il servizio non è in grado di soddisfare la richiesta. Questi errori possono verificarsi per vari motivi, ad esempio problemi transitori di rete nel parco veicoli, problemi di infrastruttura, problemi relativi ai nodi di storage e altro ancora.

È possibile che si verifichino alcuni errori interni del server durante il ciclo di vita della tabella DynamoDB. Ciò è previsto a causa della natura distribuita del servizio e di solito non dovrebbe essere motivo di preoccupazione. DynamoDB ripara e risolve automaticamente qualsiasi problema temporaneo con il servizio in tempo reale, senza richiedere alcun intervento da parte dell'utente. Tuttavia, se osservate un numero costantemente elevato di errori interni del server nelle richieste alla vostra tabella (come mostrato nella SystemErrors metrica), dovreste indagare ulteriormente.

Analisi degli errori interni del server

Se riscontri errori interni del server nella tabella DynamoDB, considera queste opzioni:

  1. Controllate il AWS Dashboard Health.

    Per identificare il problema, il primo passo è controllare il AWS Service Health Dashboard e il tuo AWS Pannello di controllo dello stato dell'account. Queste dashboard forniscono informazioni preziose su eventuali problemi a livello di servizio, tabelle interessate, problemi in corso e sulla causa principale una volta risolto il problema.

    La revisione dei dettagli in queste dashboard consentirà di comprendere meglio lo stato attuale di Servizi AWS che stai utilizzando ed eventuali problemi che riguardano il tuo account. Queste informazioni possono aiutarti a determinare i passaggi successivi per risolvere il problema e ridurre al minimo le interruzioni delle operazioni.

  2. Rivolgiti a AWS Support.

    Se riscontri errori prolungati e persistenti nelle tue richieste, ciò potrebbe indicare un problema con il servizio. Come regola generale, se riscontri un tasso di fallimento complessivo pari o superiore all'1% negli ultimi 15 minuti, è il momento giusto per segnalare il problema al AWS Team di supporto. Vedi, DynamoDB Service Level Agreement per saperne di più.

    Quando si apre un caso con AWS Team di supporto, fornisci i seguenti dettagli per velocizzare il processo di risoluzione dei problemi:

    • ImpattoDDB: tabelle o indici secondari

    • Finestra temporale in cui sono stati osservati gli errori

    • IDsRichiesta DynamoDB, ad 4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG esempio, che puoi trovare nei log dell'applicazione.

    L'inclusione di questi dettagli nella richiesta di supporto aiuterà a AWS il team comprende il problema e fornisce una risoluzione più rapida. Se non hai la richiestaIDs, dovresti comunque registrare il caso con gli altri dettagli disponibili.

Ridurre al minimo l'impatto degli errori interni del server

Se si verificano errori interni del server durante l'utilizzo di DynamoDB, riduci al minimo l'impatto di questi errori sulla tua applicazione, considera le seguenti best practice:

  • Utilizza backoff e nuovi tentativi: i SDK comportamenti predefiniti di DynamoDB sono progettati per trovare il giusto equilibrio per la maggior parte delle applicazioni in termini di strategia di back-off e ritry. Tuttavia, è possibile regolare queste impostazioni in base alla tolleranza dell'applicazione ai tempi di inattività e ai requisiti di prestazioni. Scopri di più su back-off e nuovi tentativi per capire come ottimizzare queste impostazioni di nuovi tentativi.

  • Usa letture alla fine coerenti: se la tua applicazione non richiede letture fortemente coerenti, prendi in considerazione l'utilizzo di letture alla fine coerenti. Queste letture hanno un costo inferiore ed è meno probabile che si verifichino problemi temporanei dovuti a errori interni del server, in quanto verrebbero eseguite da uno qualsiasi dei nodi di storage disponibili. Per ulteriori informazioni, consulta Coerenza di lettura di DynamoDB.

Migliorare la consapevolezza operativa

Mantenere un'elevata disponibilità e affidabilità delle applicazioni è fondamentale nel panorama digitale odierno. Un aspetto chiave è il monitoraggio proattivo degli errori interni del server (ISEs) nelle tabelle DynamoDB e negli indici secondari globali (). GSIs Creando CloudWatch allarmi per monitorare questi errori, è possibile acquisire una migliore consapevolezza operativa ed essere avvisati di potenziali problemi prima che si ripercuotano sugli utenti finali. Questo approccio è in linea con il pilastro dell'eccellenza operativa del AWS Well-Architected Framework, che garantisce che il carico di lavoro DynamoDB sia ottimizzato per prestazioni, sicurezza e affidabilità.

CloudWatch Creazione di allarmi

È necessario impostare degli CloudWatch allarmi sulle tabelle DynamoDB per ricevere notifiche per un numero costantemente elevato di errori interni del server anziché osservare le metriche manualmente. Ciò si ricollega al pilastro dell'eccellenza operativa del framework Well-Architected per qualsiasi carico di lavoro su AWS. Vedi Utilizzo di DynamoDB Well-Architected Lens per ottimizzare il carico di lavoro di DynamoDB per saperne di più su Well-Architecting delle tue tabelle DynamoDB.

Questi allarmi utilizzano parametri matematici personalizzati per calcolare la percentuale di richieste non riuscite per una finestra di 5 minuti. La best practice consigliata consiste nel configurare l'allarme in modo che entri nello ALARM stato quando 3 punti dati consecutivi superano la soglia dell'1%, il che significa che complessivamente l'1% delle richieste fallisce entro un periodo di 15 minuti.

L'esempio seguente è un AWS CloudFormation modello che può aiutarti a creare CloudWatch allarmi sul tuo tavolo e GSI sul tavolo.

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'