No DynamoDB, erros internos do servidor (500 erros) indicam que o serviço não consegue atender à solicitação. Esses erros podem ocorrer por vários motivos, como problemas transitórios de rede na frota, problemas de infraestrutura, problemas relacionados ao nó de armazenamento e muito mais.
Você pode encontrar alguns erros internos do servidor durante o ciclo de vida da sua tabela do DynamoDB. Isso está previsto devido à natureza distribuída do serviço e geralmente não deve ser motivo de preocupação. O DynamoDB repara e corrige automaticamente quaisquer problemas transitórios com o serviço em tempo real, sem exigir sua intervenção. No entanto, se você observar um número consistentemente alto de erros internos do servidor nas solicitações à tabela (conforme visto na métrica SystemErrors), investigue mais a fundo.
Tópicos
Investigar erros internos do servidor
Se você encontrar erros internos do servidor na tabela do DynamoDB, considere estas opções:
Verifique o AWS Health Dashboard.
Para identificar o problema, a primeira etapa é verificar o AWSService Health Dashboard
e o AWS Account Health Dashboard. Esses painéis fornecem informações valiosas sobre quaisquer problemas no serviço como um todo, tabelas afetadas, problemas contínuos e a causa raiz depois que o problema é resolvido. A análise dos detalhes nesses painéis fornecerá uma melhor compreensão do status atual dos Serviços da AWS que você está usando e de quaisquer possíveis problemas que estejam afetando sua conta. Essas informações podem ajudar você a determinar as próximas etapas para resolver o problema e minimizar quaisquer interrupções nas operações.
Entre em contato com o Suporte.
Se você observar erros prolongados e persistentes nas solicitações, isso pode indicar um problema com o serviço. Como regra geral, se você observar uma taxa geral de falhas de 1% ou mais nos últimos 15 minutos, é o momento apropriado para encaminhar o problema para a equipe do AWS Support. Consulte o Contrato de nível de serviço do Amazon DynamoDB
para saber mais. Ao abrir um caso com a equipe do AWS Support, forneça os seguintes detalhes para ajudar a acelerar o processo de solução de problemas:
-
DDB afetado; tabelas ou índices secundários
-
Janela de tempo em que os erros foram observados
-
IDs de solicitação do DynamoDB, como
4KBNVRGD25RG1KEO9UT4V3FQDJVV4KQNSO5AEMVJF66Q9ASUAAJG, que você pode encontrar nos logs da aplicação.
Incluir esses detalhes no caso de suporte ajudará a equipe da AWS a entender o problema e fornecer uma solução mais rápida. Se você não tiver os IDs de solicitação, ainda assim deverá registrar o caso com os outros detalhes disponíveis.
-
Minimizar o impacto dos erros internos do servidor
Se ocorrerem erros internos do servidor ao usar o DynamoDB, minimize o impacto deles na aplicação. Considere as seguintes práticas recomendadas:
-
Use recuos e novas tentativas: os comportamentos padrão do SDK foram projetados para encontrar o equilíbrio certo para a maioria das aplicações em termos de estratégia de recuo e nova tentativa. No entanto, você pode ajustar essas configurações com base na tolerância da aplicação aos requisitos de tempo de inatividade e desempenho. Saiba mais sobre recuos e novas tentativas para entender como você pode ajustar as respectivas configurações.
-
Use leituras finais consistentes: se a aplicação não exigir leituras altamente consistentes, considere usar as leituras finais consistentes. Essas leituras custam menos e têm menor probabilidade de apresentar problemas transitórios devido a erros internos do servidor, pois seriam atendidas por qualquer um dos nós de armazenamento disponíveis. Para ter mais informações, consulte Consistência de leitura do DynamoDB.
Melhorar o reconhecimento operacional
Manter a alta disponibilidade e confiabilidade das aplicações é crucial no cenário digital atual. Um aspecto importante disso é o monitoramento proativo de erros internos do servidor (ISEs) nas tabelas do DynamoDB e nos índices secundários globais (GSIs). Ao criar alarmes do CloudWatch para monitorar esses erros, você pode obter melhor reconhecimento operacional e receber alertas sobre possíveis problemas antes que eles afetem os usuários finais. Essa abordagem se alinha ao pilar de excelência operacional do AWS Well-Architected Framework, garantindo que o workload do DynamoDB seja otimizado para apresentar desempenho, segurança e confiabilidade.
Criar alarmes do CloudWatch
Você deve ter os alarmes do CloudWatch definidos nas tabelas do DynamoDB para receber notificações sobre números consistentemente altos de erros internos do servidor, em vez de observar as métricas manualmente. Isso está relacionado ao pilar de excelência operacional da estrutura Well-Architected para qualquer workload em AWS. Consulte Usar Lentes do Well-Architected para DynamoDB para otimizar uma workload do DynamoDB para saber mais sobre Well-Architecting de tabelas do DynamoDB.
Esses alarmes usam métrica (matemática) personalizada para calcular a porcentagem de solicitações com falha em uma janela de cinco minutos. A prática recomendada é configurar o alarme para entrar no estado ALARM em que 3 pontos de dados consecutivos ultrapassam o limite de 1%, o que significa que 1% das solicitações falham em um período de 15 minutos.
O exemplo abaixo é um modelo do AWS CloudFormation que pode ajudar você a criar alarmes do CloudWatch na tabela e o GSI na tabela.
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'