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
<a name="TroubleshootingInternalServerErrors"></a>

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](metrics-dimensions.md#SystemErrors)), è opportuno indagare ulteriormente.

**Topics**
+ [Indagine degli errori interni del server](#ServerErrors-investigating)
+ [Ridurre al minimo l’impatto degli errori interni del server](#ServerErrors-minimizing-impact)
+ [Miglioramento della consapevolezza operativa](#ServerErrors-improving-operational-awareness)

## Indagine degli errori interni del server
<a name="ServerErrors-investigating"></a>

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

1. **Controlla la AWS Health Dashboard.**

   Per identificare il problema, il primo passo è controllare il [AWS Service Health Dashboard](https://health.aws.amazon.com/health/status) e il tuo AWS Account Health Dashboard. 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 ti consentirà di comprendere meglio lo stato attuale del dispositivo Servizi AWS che stai utilizzando e gli eventuali problemi che riguardano il tuo account. Queste informazioni possono aiutare a determinare le fasi successive per risolvere il problema e ridurre al minimo le interruzioni delle operazioni.

1. **Rivolgiti a. Supporto**

   Errori prolungati nelle richieste potrebbero 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 team di AWS Support. Per maggiori informazioni, consulta l’[Accordo sul livello di servizio di DynamoDB](https://aws.amazon.com/dynamodb/sla/).

   Quando apri un caso con il team di AWS Support, 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
   +  IDsRichiesta DynamoDB, ad `4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG` esempio, che puoi trovare nei log dell'applicazione.

   L'inclusione di questi dettagli nella richiesta di supporto aiuterà il AWS team a comprendere il problema e a fornire una risoluzione più rapida. Se non hai ricevuto la richiesta IDs, devi comunque registrare il caso con gli altri dettagli disponibili.

## Ridurre al minimo l’impatto degli errori interni del server
<a name="ServerErrors-minimizing-impact"></a>

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](HowItWorks.ReadConsistency.md).

## Miglioramento della consapevolezza operativa
<a name="ServerErrors-improving-operational-awareness"></a>

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 Operational Excellence del AWS Well-Architected Framework, garantendo che il carico di lavoro DynamoDB sia ottimizzato per prestazioni, sicurezza e affidabilità.

**Creazione di allarmi CloudWatch **

È 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. AWS Consulta [Utilizzo di DynamoDB Well-Architected Lens per ottimizzare il carico di lavoro di DynamoDB](bp-wal.md) 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 CloudFormation modello che può aiutarti a creare CloudWatch allarmi sulla tabella e GSI sulla tabella.

```
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'
```