Risoluzione degli errori interni del server in Amazon DynamoDB - Amazon DynamoDB
Indagine degli errori interni del serverRidurre al minimo l’impatto degli errori interni del serverMiglioramento della 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 istanze, problemi di infrastruttura, problemi relativi ai nodi di archiviazione e altro ancora.

È possibile che si verifichino alcuni errori interni del server durante il ciclo di vita della tabella DynamoDB. Questa evenienza è prevista in ragione della natura distribuita del servizio e non dovrebbe di norma costituire motivo di preoccupazione. DynamoDB ripara e risolve automaticamente gli eventuali problemi temporanei con il servizio in tempo reale, senza richiedere alcun intervento da parte dell’utente. Tuttavia, in caso di numeri costantemente elevati di errori interni del server nelle richieste alla tabella (come mostrato nella metrica SystemErrors), è opportuno indagare ulteriormente.

Indagine degli errori interni del server

In caso di riscontro di errori interni del server nella tabella DynamoDB, considera queste opzioni:

  1. Controlla la Dashboard AWS Health.

    Per identificare il problema, la prima fase è controllare la Dashboard AWS Service Health e la Dashboard Stato dell’account AWS. 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.

    L’analisi dei dettagli presenti in queste dashboard consentirà di comprendere meglio lo stato corrente dei Servizi AWS in uso e gli eventuali problemi potenziali che interessano l’account. Queste informazioni possono aiutare a determinare le fasi successive per risolvere il problema e ridurre al minimo le interruzioni delle operazioni.

  2. Contatta il Supporto.

    Errori prolungati nelle richieste potrebbero indicare un problema con il servizio. In linea generale, un tasso di errore complessivo pari o superiore all’1% negli ultimi 15 minuti indica che è opportuno procedere con l’inoltro del problema al team del Supporto AWS. Per maggiori informazioni, consulta l’Accordo sul livello di servizio di DynamoDB.

    Durante l’apertura di un caso con il team del Supporto AWS, fornisci i seguenti dettagli per velocizzare il processo di risoluzione dei problemi:

    • Database DDB, tabelle o indici secondari interessati

    • Finestra temporale in cui sono stati osservati gli errori

    • ID di richiesta DynamoDB, come 4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG, reperibile nei log delle applicazioni.

    L’inclusione di questi dettagli nella richiesta di supporto aiuterà il team AWS a comprendere il problema e offrire una risoluzione più rapida. Qualora non si disponga degli ID delle richieste è comunque necessario registrare log del caso con gli altri dettagli disponibili.

Ridurre al minimo l’impatto degli errori interni del server

In caso di errori interni del server durante l’utilizzo di DynamoDB, prendi in considerazione le seguenti best practice per ridurne al minimo l’impatto sull’applicazione:

  • Usa backoff e ripetizioni dei tentativi: i comportamenti degli SDK predefiniti di DynamoDB sono progettati per trovare il giusto equilibrio per la maggior parte delle applicazioni in termini di strategia di backoff e ripetizioni dei tentativi. Tuttavia, è possibile regolare queste impostazioni in base alla tolleranza dell’applicazione ai tempi di inattività e ai requisiti delle prestazioni. Approfondisci i backoff e le ripetizioni dei tentativi per capire come ottimizzare queste impostazioni di ripetizione dei tentativi.

  • Usa letture a coerenza finale: se l’applicazione non richiede un’elevata consistenza di lettura, prendi in considerazione l’utilizzo di letture a coerenza finale. Queste letture hanno un costo inferiore e rendono meno probabile il verificarsi di problemi temporanei dovuti a errori interni del server, in quanto vengono servite da uno qualsiasi dei nodi di archiviazione disponibili. Per ulteriori informazioni, consulta Coerenza di lettura di DynamoDB.

Miglioramento della 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 nelle tabelle DynamoDB e negli indici secondari globali (GSI). Creando allarmi CloudWatch per monitorare questi errori è possibile acquisire una migliore consapevolezza operativa e ricevere avvisi sui potenziali problemi prima che abbiano un impatto sugli utenti finali. Questo approccio è in linea con il pilastro Eccellenza operativa del framework AWS Well-Architected, poiché garantisce che il carico di lavoro DynamoDB sia ottimizzato per prestazioni, sicurezza e affidabilità.

Creazione di allarmi CloudWatch

È necessario impostare gli allarmi CloudWatch sulle tabelle DynamoDB per ricevere notifiche in caso di numeri costantemente elevati di errori interni del server anziché, così da non dover analizzare le metriche manualmente. Questo approccio si lega al pilastro Eccellenza operativa del framework Well-Architected per qualsiasi carico di lavoro su AWS. Consulta Utilizzo di DynamoDB Well-Architected Lens per ottimizzare il carico di lavoro di DynamoDB per saperne di più su come progettare le tabelle DynamoDB secondo i principi del Well-Architecting.

Questi allarmi utilizzano metriche matematiche personalizzate per calcolare la percentuale di richieste non riuscite per un periodo di 5 minuti. La best practice consigliata consiglia di configurare l’allarme in modo che entri nello stato ALARM quando 3 punti dati consecutivi superano la soglia dell’1%, il che significa che complessivamente l’1% delle richieste non va a buon fine entro un periodo di 15 minuti.

L’esempio seguente è un modello CloudFormation che può aiutare a creare allarmi CloudWatch nella tabella e nel GSI.

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'