Solución de problemas de errores del servidor internos en Amazon DynamoDB - Amazon DynamoDB
Investigación de los errores del servidor internosMinimización del impacto de los errores del servidor internosMejora del conocimiento operativo

Solución de problemas de errores del servidor internos en Amazon DynamoDB

En DynamoDB, los errores del servidor internos (errores 500) indican que el servicio no puede atender la solicitud. Estos errores se pueden producir por varios motivos, como problemas transitorios de red en la flota, problemas de infraestructura, problemas relacionados con los nodos de almacenamiento, etc.

Es posible que se produzcan algunos errores del servidor internos durante el ciclo de vida de la tabla de DynamoDB. Esto es normal debido a la naturaleza distribuida del servicio y, por lo general, no debería ser motivo de preocupación. DynamoDB repara y soluciona automáticamente cualquier problema transitorio del servicio en tiempo real, sin que sea necesaria su intervención. Sin embargo, si observa un número elevado y constante de errores del servidor internos en las solicitudes a la tabla (como se ve en la métrica SystemErrors), debería investigar con más detalle.

Investigación de los errores del servidor internos

Si encuentra errores del servidor internos en la tabla de DynamoDB, considere estas opciones:

  1. Consulte el panel de AWS Health.

    Para identificar el problema, el primer paso es revisar el Panel de estado del servicio de AWS y el panel de estado de la cuenta de AWS. Estos paneles proporcionan información valiosa sobre cualquier problema que afecte a todo el servicio, las tablas afectadas, los problemas actuales y la causa raíz una vez resuelto el problema.

    La revisión de los detalles de estos paneles le permitirá comprender mejor el estado actual de los Servicios de AWS que está utilizando y cualquier problema potencial que afecte a la cuenta. Esta información puede ayudarle a determinar los próximos pasos para abordar el problema y minimizar cualquier interrupción en las operaciones.

  2. Contacte con AWS Support.

    Si observa errores prolongados y persistentes en las solicitudes, es posible que se trate de un problema con el servicio. Como regla general, si observa una tasa de errores general del 1 % o más en los últimos 15 minutos, es el momento adecuado para plantear el problema al equipo de AWS Support. Consulte el Acuerdo de nivel de servicio de DynamoDB para obtener más información.

    Al abrir un caso con el equipo de AWS Support, proporcione los siguientes detalles para ayudar a agilizar el proceso de solución de problemas:

    • DDB afectado; tablas o índices secundarios

    • Periodo temporal en el que se observaron los errores

    • ID de solicitud de DynamoDB, como 4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG, que puede encontrar en los registros de la aplicación.

    La inclusión de estos detalles en el caso de soporte ayudará al equipo de AWS a entender el problema y a resolverlo más rápido. Si no tiene los ID de la solicitud, debe registrar el caso con el resto de detalles disponibles.

Minimización del impacto de los errores del servidor internos

Si se producen errores del servidor internos cuando se use DynamoDB, minimice el impacto de los mismos en la aplicación, tenga en cuenta las siguientes prácticas recomendadas:

  • Uso de retrasos y reintentos: los comportamientos predeterminados del SDK de DynamoDB están diseñados para encontrar el equilibrio adecuado para la mayoría de las aplicaciones en términos de estrategia de retrasos y reintentos. Sin embargo, puede ajustar esta configuración en función de la tolerancia de la aplicación al tiempo de inactividad y a los requisitos de rendimiento. Obtenga más información sobre los retrasos y los reintentos para saber cómo puede ajustar esta configuración de reintento.

  • Uso de lecturas coherentes posteriores: si la aplicación no requiere lecturas altamente coherentes, considere la posibilidad de utilizar lecturas coherentes posteriores. Estas lecturas cuestan menos y es menos probable que se produzcan problemas transitorios debido a errores del servidor internos, ya que se realizarían desde cualquiera de los nodos de almacenamiento disponibles. Para obtener más información, consulte Coherencia de lectura de DynamoDB.

Mejora del conocimiento operativo

El mantenimiento de una alta disponibilidad y fiabilidad de las aplicaciones es crucial en el panorama digital actual. Un aspecto clave de esto es la supervisión proactiva de los errores del servidor internos (ISE) en las tablas y los índices secundarios globales (GSI) de DynamoDB. Al crear alarmas de CloudWatch para supervisar estos errores, puede obtener un mejor conocimiento operativo y recibir alertas sobre posibles problemas antes de que afecten a los usuarios finales. Este enfoque se alinea con el pilar de excelencia operativa del marco de AWS Well-Architected, lo que garantiza que la carga de trabajo de DynamoDB esté optimizada en términos de rendimiento, seguridad y fiabilidad.

Creación de alarmas de CloudWatch

Debe configurar las alarmas de CloudWatch en las tablas de DynamoDB para recibir notificaciones de un número elevado y constante de errores internos del servidor, en lugar de observar las métricas manualmente. Esto se relaciona con el pilar de excelencia operativa del marco Well-Architected para cualquier carga de trabajo en AWS. Consulte Uso del enfoque Well-Architected de DynamoDB para optimizar su carga de trabajo de DynamoDB para obtener más información sobre cómo diseñar correctamente las tablas de DynamoDB.

Estas alarmas utilizan métricas personalizadas para calcular el porcentaje de solicitudes erróneas en un periodo de 5 minutos. La práctica recomendada es configurar la alarma para que entre en el estado ALARM cuando 3 puntos de datos consecutivos superen el umbral del 1 %, lo que significa que, en general, el 1 % de las solicitudes producen un error en un periodo de 15 minutos.

El siguiente ejemplo es una plantilla de AWS CloudFormation que puede ayudarle a crear alarmas de CloudWatch en la tabla y GSI en la tabla.

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'