View a markdown version of this page

Risoluzione degli errori interni del server in Amazon DynamoDB - Amazon DynamoDB

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 AWS Health Dashboard.

    Per identificare il problema, il primo passo è controllare il AWS Service Health Dashboard 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 dopo la risoluzione del problema.

    La revisione dei dettagli in queste dashboard ti consentirà di comprendere meglio lo stato attuale del servizio che Servizi AWS stai utilizzando e gli eventuali problemi potenziali che interessano il tuo account. Queste informazioni possono aiutare a determinare le fasi successive per risolvere il problema e ridurre al minimo le interruzioni delle operazioni.

  2. Rivolgiti a. Supporto

    Se riscontri errori prolungati e prolungati 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 team di AWS Support. Per maggiori informazioni, consulta l’Accordo sul livello di servizio di DynamoDB.

    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

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

    L'inclusione di questi dettagli nella richiesta di supporto aiuterà il AWS team a comprendere il problema e a fornire 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 CloudWatch allarmi per monitorare questi errori, è possibile acquisire una migliore consapevolezza operativa ed essere avvisati di potenziali problemi prima che abbiano ripercussioni 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 per qualsiasi carico di lavoro. Well-Architected AWS Vedi Utilizzo di DynamoDB Lens per ottimizzare il carico di lavoro Well-Architected DynamoDB per saperne di più sulle Well-Architecting tue tabelle DynamoDB.

Quando crei un allarme sulla SystemErrors metrica, specifica entrambe le Operation dimensioni TableName e (o TableName e GlobalSecondaryIndexName per un indice secondario globale). DynamoDB SystemErrors emette per operazione, non TableName solo, quindi un allarme che specifica rimane TableName solo nello INSUFFICIENT_DATA stato e non avvisa mai.