Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Résolution des problèmes liés aux erreurs internes du serveur dans Amazon DynamoDB
Dans DynamoDB, les erreurs internes du serveur (erreurs 500) indiquent que le service n’est pas en mesure de traiter la demande. Ces erreurs peuvent survenir pour diverses raisons, telles que des problèmes passagers de réseau dans la flotte, des problèmes d’infrastructure, des problèmes liés aux nœuds de stockage, etc.
Il est possible que vous rencontriez des erreurs internes au serveur au cours du cycle de vie de votre table DynamoDB. Cela est attendu en raison de la nature distribuée du service et ne devrait généralement pas être une source de préoccupation. DynamoDB répare et résout automatiquement tout problème passager lié au service en temps réel, sans aucune intervention de votre part. Toutefois, si vous observez un nombre constamment élevé d’erreurs internes du serveur lors des demandes adressées à la table (comme le montre la métrique SystemErrors), vous devriez poursuivre votre examen.
Rubriques
Examen des erreurs internes du serveur
Si vous rencontrez des erreurs internes du serveur dans la table DynamoDB, envisagez les options suivantes :
Consultez le tableau de bord de AWS santé.
Pour identifier le problème, la première étape consiste à consulter le tableau de bord de l'état du AWS service
et le tableau de bord de l'état de votre AWS compte. Ces tableaux de bord fournissent des informations précieuses sur tous les problèmes affectant l'ensemble du service, les tables concernées, les problèmes en cours et la cause première une fois le problème résolu. L'examen des détails de ces tableaux de bord vous permettra de mieux comprendre l'état actuel de votre utilisation et de tout problème potentiel affectant votre compte. Services AWS Ces informations peuvent vous aider à déterminer les prochaines étapes pour résoudre le problème et minimiser les perturbations de vos opérations.
Contactez Support.
Si vous observez des erreurs prolongées et persistantes dans vos demandes, cela peut indiquer un problème avec le service. En règle générale, si vous constatez un taux d'échec global de 1 % ou plus au cours des 15 dernières minutes, c'est le moment idéal pour signaler le problème à l'équipe d' AWS assistance. Consultez le contrat de niveau de service DynamoDB
pour en savoir plus. Lorsque vous ouvrez un dossier auprès de l'équipe d' AWS assistance, fournissez les informations suivantes pour accélérer le processus de dépannage :
-
DDB concerné ; tables ou index secondaires
-
Période pendant laquelle les erreurs ont été observées
-
ID de demande DynamoDB, tels que
4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG, disponibles dans les journaux des applications.
L'inclusion de ces informations dans le dossier de support aidera l' AWS équipe à comprendre le problème et à le résoudre plus rapidement. Si vous n’avez pas les ID de demande, vous devez tout de même journaliser le cas avec les autres informations disponibles.
-
Minimisation de l’impact des erreurs internes du serveur
Si des erreurs internes du serveur se produisent lors de l’utilisation de DynamoDB, minimisez leur impact sur votre application. Prenez en compte les bonnes pratiques suivantes :
-
Utilisez les backoffs et les nouvelles tentatives : les comportements par défaut du kit SDK de DynamoDB sont conçus pour trouver le bon équilibre pour la plupart des applications en termes de backoff et de stratégie de nouvelle tentative. Vous pouvez toutefois ajuster ces paramètres en fonction de la tolérance de votre application à la durée d’indisponibilité et de ses exigences de performance. En savoir plus sur les backoffs et les nouvelles tentatives pour comprendre comment optimiser ces paramètres de nouvelle tentative.
-
Utilisez des lectures cohérentes à terme : si votre application ne nécessite pas de lectures fortement cohérentes, envisagez d’utiliser des lectures cohérentes à terme. Ces lectures sont moins coûteuses et moins susceptibles de rencontrer des problèmes passagers en raison d’erreurs internes du serveur, car elles seraient effectuées à partir de n’importe quel nœud de stockage disponible. Pour de plus amples informations, veuillez consulter Cohérence en lecture DynamoDB.
Amélioration de la conscience opérationnelle
Le maintien de la haute disponibilité et de la fiabilité de vos applications est crucial dans le paysage numérique actuel. L’un des principaux aspects de cette approche est la surveillance proactive des erreurs internes du serveur (ISE) dans les tables DynamoDB et les index secondaires globaux (GSI). En créant CloudWatch des alarmes pour surveiller ces erreurs, vous pouvez acquérir une meilleure conscience opérationnelle et être alerté des problèmes potentiels avant qu'ils n'affectent vos utilisateurs finaux. Cette approche est conforme au pilier d'excellence opérationnelle du AWS Well-Architected Framework, garantissant que votre charge de travail DynamoDB est optimisée en termes de performances, de sécurité et de fiabilité.
Création d' CloudWatch alarmes
Vous devriez configurer des CloudWatch alarmes sur vos tables DynamoDB pour recevoir des notifications en cas de nombre constamment élevé d'erreurs internes au serveur au lieu d'observer les mesures manuellement. Cela est lié au pilier d'excellence opérationnelle du Well-Architected cadre pour toute charge de travail AWS. Consultez Utilisation de l' Well-Architected objectif DynamoDB pour optimiser votre charge de travail DynamoDB pour en savoir plus sur Well-Architecting vos tables DynamoDB.
Lorsque vous créez une alarme sur la SystemErrors métrique, spécifiez à la fois les Operation dimensions TableName et (ou TableName et GlobalSecondaryIndexName pour un index secondaire global). DynamoDB émet des signaux SystemErrors par opération, et non séparément. Ainsi, une alarme qui spécifie ne fait que TableName rester dans l'INSUFFICIENT_DATAétat et ne déclenche jamais d'alerte. TableName
