Enquête sur les erreurs internes du serveur Minimiser l'impact des erreurs internes du serveur Améliorer la prise de conscience opérationnelle

Résolution des erreurs internes du serveur dans Amazon DynamoDB

Dans DynamoDB, les erreurs internes du serveur (500 erreurs) 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 de réseau transitoires dans le parc, 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 pendant le 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 temporaire lié au service en temps réel, sans aucune intervention de votre part. Toutefois, si vous observez un nombre constamment élevé d'erreurs internes au serveur lors des requêtes adressées à votre table (comme le montre la SystemErrors métrique), vous devriez poursuivre vos recherches.

Rubriques

Enquête sur les erreurs internes du serveur
Minimiser l'impact des erreurs internes du serveur
Améliorer la prise de conscience opérationnelle

Enquête sur les erreurs internes du serveur

Si vous rencontrez des erreurs internes au serveur dans votre table DynamoDB, envisagez les options suivantes :

Consultez le AWS Health Dashboard.

Pour identifier le problème, la première étape consiste à consulter le AWS Service Health Dashboard et le AWS Account Health Dashboard. Ces tableaux de bord fournissent des informations précieuses sur les problèmes rencontrés à l'échelle du service, les tables concernées, les problèmes en cours et la cause première du problème une fois le problème résolu.

L'examen des informations contenues dans ces tableaux de bord vous permettra de mieux comprendre l'état actuel du système que Services AWS vous utilisez et les éventuels problèmes affectant votre compte. Ces informations peuvent vous aider à déterminer les prochaines étapes pour résoudre le problème et minimiser les perturbations de vos opérations.
Tendez la main à 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 de AWS Support. Consultez le contrat de niveau de service DynamoDB pour en savoir plus.

Lorsque vous ouvrez un dossier auprès de l'équipe de AWS Support, 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
- IDsDemande DynamoDB, telle 4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG que, que vous pouvez trouver dans les journaux de votre application.
L'inclusion de ces informations dans le dossier d'assistance aidera l' AWS équipe à comprendre le problème et à le résoudre plus rapidement. Si vous n'avez pas reçu la demande IDs, vous devez tout de même enregistrer le dossier avec les autres informations disponibles.

Minimiser l'impact des erreurs internes du serveur

Si des erreurs internes au serveur se produisent lors de l'utilisation de DynamoDB, minimisez leur impact sur votre application. Prenez en compte les meilleures pratiques suivantes :

Utilisez les interruptions et les nouvelles tentatives : les comportements par défaut du SDK de DynamoDB sont conçus pour trouver le juste équilibre pour la plupart des applications en termes de stratégie d'attente et de nouvelle tentative. Vous pouvez toutefois ajuster ces paramètres en fonction de la tolérance de votre application aux temps d'arrêt et des exigences de performance. Apprenez-en davantage sur les interruptions et les nouvelles tentatives pour comprendre comment affiner ces paramètres de réessai.
Utilisez éventuellement des lectures cohérentes — Si votre application ne nécessite pas de lectures très cohérentes, envisagez d'utiliser des lectures finalement cohérentes. Ces lectures sont moins coûteuses et moins susceptibles de rencontrer des problèmes transitoires en raison d'erreurs internes au 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 de lecture DynamoDB.

Améliorer la prise de 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 consiste à surveiller de manière proactive les erreurs internes du serveur (ISEs) dans vos tables DynamoDB et vos index secondaires globaux (). GSIs En créant des CloudWatch alarmes pour surveiller ces erreurs, vous pouvez acquérir une meilleure connaissance opérationnelle et être alerté des problèmes potentiels avant qu'ils n'affectent vos utilisateurs finaux. Cette approche est conforme au pilier de l'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 devez 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 métriques manuellement. Cela est lié au pilier de l'excellence opérationnelle du framework Well-Architected pour toute charge de travail. AWS Consultez Utilisation du cadre DynamoDB Well-Architected pour optimiser votre charge de travail DynamoDB pour en savoir plus sur la bonne architecture de vos tables DynamoDB.

Ces alarmes utilisent des mesures mathématiques personnalisées pour calculer le pourcentage de demandes ayant échoué pour une fenêtre de 5 minutes. La meilleure pratique recommandée consiste à configurer l'alarme pour qu'elle entre dans l'ALARMétat lorsque 3 points de données consécutifs dépassent le seuil de 1 %, ce qui signifie qu'au total 1 % des demandes échouent dans un délai de 15 minutes.

L'exemple ci-dessous est un AWS CloudFormation modèle qui peut vous aider à créer des CloudWatch alarmes sur votre table et des alarmes GSI sur la table.


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'

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Résolution des problèmes

Latence