Alarmes recomendados

As seções a seguir listam as métricas para as quais recomendamos que você defina alarmes de práticas recomendadas. Para cada métrica, também são exibidas as dimensões, a intenção do alarme, o limite recomendado, a justificativa do limite, a duração do período e o número de pontos de dados.

Algumas métricas podem aparecer duas vezes na lista. Isso acontece quando alarmes diferentes são recomendados para combinações diferentes de dimensões dessa métrica.

Pontos de dados para alarme é o número de pontos de dados que devem ser violados para enviar o alarme para o estado ALARME. Períodos de avaliação é o número de períodos que são levados em conta quando o alarme é avaliado. Se esses números forem iguais, o alarme entrará em estado ALARME somente quando esse número de períodos consecutivos tiver valores que ultrapassem o limite. Se Pontos de dados para alarme for menor que os Períodos de avaliação, será um alarme "M de N" e o alarme entrará em estado ALARME se pelo menos os pontos de dados de Pontos de dados para alarme estiverem violando qualquer conjunto de pontos de dados de Períodos de avaliação. Para ter mais informações, consulte Avaliar um alarme.

Amazon API Gateway

4XXError

Dimensões: ApiName, estágio

Descrição do alarme: esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar um problema na autorização ou nos parâmetros da solicitação do cliente. Isso também pode significar que um recurso foi removido ou que um cliente está solicitando um recurso que não existe. Considere a possibilidade de ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando os erros 4XX. Ademais, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por recurso e método e restringir a origem dos erros. Os erros também podem ser causados por exceder o limite de controle de utilização configurado. Se as respostas e os logs estiverem relatando taxas altas e inesperadas de erros 429, siga este guia para solucionar esse problema.

Intenção: esse alarme pode detectar altas taxas de erros no lado do cliente para as solicitações do API Gateway.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 4XX. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 4XX que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

5XXError

Dimensões: ApiName, estágio

Descrição do alarme: esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar que há algo errado no back-end da API, na rede ou na integração entre o gateway da API e a API de back-end. Essa documentação pode ajudar a solucionar a causa dos erros 5xx.

Intenção: esse alarme pode detectar altas taxas de erros no lado do servidor para as solicitações do API Gateway.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 5XX. No entanto, é possível ajustar o limite de acordo com o tráfego das solicitações e com as taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 5XX que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.

Período: 60

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: GREATER_THAN_THRESHOLD

Contagem

Dimensões: ApiName, estágio

Descrição do alarme: esse alarme ajuda a detectar um baixo volume de tráfego para o estágio da API REST. Isso pode ser um indicador de um problema com a aplicação que chama a API, como o uso de endpoints incorretos. Também pode ser um indicador de um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.

Intenção: esse alarme pode detectar um volume de tráfego inesperadamente baixo para o estágio da API REST. Recomendamos que você crie esse alarme se sua API receber um número previsível e consistente de solicitações em condições normais. Caso as métricas detalhadas do CloudWatch estejam ativadas e você possa prever o volume normal de tráfego por método e recurso, recomendamos que você crie alarmes alternativos para ter um monitoramento mais detalhado das quedas de volume de tráfego para cada recurso e método. Esse alarme não é recomendado para APIs que não esperam tráfego constante e consistente.

Estatística: SampleCount

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite com base na análise de dados históricos para determinar qual é a contagem de solicitações de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de baixo tráfego normal e esperado. Por outro lado, configurá-lo em um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: LESS_THAN_THRESHOLD

Contagem

Dimensões: ApiName, estágio, recurso, método

Descrição do alarme: esse alarme ajuda a detectar um baixo volume de tráfego para o recurso e o método da API REST no estágio. Isso pode indicar um problema com a aplicação que está chamando a API, como o uso de endpoints incorretos. Também pode ser um indicador de um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.

Intenção: esse alarme pode detectar um volume de tráfego inesperadamente baixo para o recurso e o método da API REST no estágio. Recomendamos que você crie esse alarme se sua API receber um número previsível e consistente de solicitações em condições normais. Esse alarme não é recomendado para APIs que não esperam tráfego constante e consistente.

Estatística: SampleCount

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite com base na análise de dados históricos para determinar qual é a contagem de solicitações de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de baixo tráfego normal e esperado. Por outro lado, configurá-lo em um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: LESS_THAN_THRESHOLD

Contagem

Dimensões: ApiId, estágio

Descrição do alarme: esse alarme ajuda a detectar um baixo volume de tráfego para o estágio da API HTTP. Isso pode indicar um problema com a aplicação que está chamando a API, como o uso de endpoints incorretos. Também pode ser um indicador de um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.

Intenção: esse alarme pode detectar um volume de tráfego inesperadamente baixo para o estágio da API HTTP. Recomendamos que você crie esse alarme se sua API receber um número previsível e consistente de solicitações em condições normais. Caso as métricas detalhadas do CloudWatch estejam ativadas e você possa prever o volume normal de tráfego por rota, recomendamos que você crie alarmes alternativos a esse para que haja um monitoramento mais detalhado das quedas no volume de tráfego de cada rota. Esse alarme não é recomendado para APIs que não esperam tráfego constante e consistente.

Estatística: SampleCount

Limite recomendado: depende da sua situação

Justificativa do limite: defina o valor limite com base na análise de dados históricos para determinar qual é a contagem de solicitações de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de baixo tráfego normal e esperado. Por outro lado, configurá-lo em um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: LESS_THAN_THRESHOLD

Contagem

Dimensões: ApiId, estágio, recurso, método

Descrição do alarme: esse alarme ajuda a detectar um baixo volume de tráfego para a rota da API HTTP no estágio. Isso pode indicar um problema com a aplicação que está chamando a API, como o uso de endpoints incorretos. Isso também pode indicar um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.

Intenção: esse alarme pode detectar um volume de tráfego inesperadamente baixo para a rota da API HTTP no estágio. Recomendamos que você crie esse alarme se sua API receber um número previsível e consistente de solicitações em condições normais. Esse alarme não é recomendado para APIs que não esperam tráfego constante e consistente.

Estatística: SampleCount

Limite recomendado: depende da sua situação

Justificativa do limite: defina o valor limite com base na análise de dados históricos para determinar qual é a contagem de solicitações de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de baixo tráfego normal e esperado. Por outro lado, configurá-lo em um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: LESS_THAN_THRESHOLD

IntegrationLatency

Dimensões: ApiId, estágio

Descrição do alarme: esse alarme ajuda a detectar se há alta latência de integração para as solicitações de API em um estágio. Você pode correlacionar o valor da métrica IntegrationLatency com a métrica de latência correspondente do seu back-end, como a métrica Duration para integrações do Lambda. Isso ajuda a determinar se o back-end da API está demorando mais para processar as solicitações dos clientes devido a problemas de performance ou se há alguma outra sobrecarga da inicialização ou da inicialização a frio. Além disso, considere a possibilidade de ativar o CloudWatch Logs para sua API e verificar se há erros nos registros que possam estar causando os problemas de alta latência. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para obter uma visão dessa métrica por rota, o que ajudará você a restringir a origem da latência da integração.

Intenção: esse alarme pode detectar quando as solicitações do API Gateway em um estágio têm uma alta latência de integração. Recomendamos esse alarme para APIs de WebSocket e o consideramos opcional para APIs HTTP porque elas já têm recomendações de alarme separadas para a métrica de latência. Caso as métricas detalhadas do CloudWatch estejam ativadas e você tenha diferentes requisitos de performance de latência de integração por rota, recomendamos que você crie alarmes alternativos para ter um monitoramento mais refinado da latência de integração para cada rota.

Estatística: p90

Limite recomendado: 2000,0

Justificativa do limite: o valor limite sugerido não funciona para todas as workloads da API. No entanto, você pode usá-lo como um ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência mais alta em geral, defina um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar os dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, usá-la para ajustar o valor limite adequadamente.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

IntegrationLatency

Dimensões: ApiId, estágio, rota

Descrição do alarme: esse alarme ajuda a detectar se há alta latência de integração para as solicitações da API de WebSocket para uma rota em um estágio. Você pode correlacionar o valor da métrica IntegrationLatency com a métrica de latência correspondente do seu back-end, como a métrica Duration para integrações do Lambda. Isso ajuda a determinar se o back-end da API está demorando mais para processar solicitações de clientes devido a problemas de performance ou se há alguma outra sobrecarga de inicialização ou inicialização a frio. Além disso, considere a possibilidade de ativar o CloudWatch Logs para sua API e verificar se há erros nos registros que possam estar causando os problemas de alta latência.

Intenção: esse alarme pode detectar quando as solicitações do API Gateway para uma rota em um estágio têm alta latência de integração.

Estatística: p90

Limite recomendado: 2000,0

Justificativa do limite: o valor limite sugerido não funciona para todas as workloads da API. No entanto, você pode usá-lo como um ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência maior em geral, você pode definir um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar os dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, usá-la para ajustar o valor limite adequadamente.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latência

Dimensões: ApiName, estágio

Descrição do alarme: esse alarme detecta alta latência em um estágio. Encontre o valor da métrica IntegrationLatency para verificar a latência do back-end da API. Se as duas métricas estiverem alinhadas em sua maior parte, o back-end da API será a fonte de maior latência e você deve investigar se há problemas. Considere também ativar o CloudWatch Logs e verificar se há erros que possam estar causando a alta latência. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por recurso e método e restringir a origem da latência. Se aplicável, consulte os guias de solução de problemas com o Lambda ou de solução de problemas para endpoints de API otimizados para borda.

Intenção: esse alarme pode detectar quando as solicitações do API Gateway em um estágio têm alta latência. Se você tiver as métricas detalhadas do CloudWatch ativadas e tiver diferentes requisitos de performance de latência para cada método e recurso, recomendamos que crie alarmes alternativos para ter um monitoramento mais detalhado da latência de cada recurso e método.

Estatística: p90

Limite recomendado: 2500,0

Justificativa do limite: o valor limite sugerido não funciona para todas as workloads da API. No entanto, você pode usá-lo como um ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência maior em geral, você pode definir um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar dados históricos para determinar qual é a latência de linha de base esperada para a workload da aplicação e, em seguida, ajustar o valor limite adequadamente.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latência

Dimensões: ApiName, estágio, recurso, método

Descrição do alarme: esse alarme detecta alta latência para um recurso e método em um estágio. Encontre o valor da métrica IntegrationLatency para verificar a latência do back-end da API. Se as duas métricas estiverem alinhadas, o back-end da API será a fonte de maior latência e você deve investigar se há problemas de performance. Considere também ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando a alta latência. Você também pode consultar os guias de solução de problemas com o Lambda ou de solução de problemas para endpoints de API otimizados para borda, se aplicável.

Intenção: esse alarme pode detectar quando as solicitações do API Gateway para um recurso e método em um estágio têm alta latência.

Estatística: p90

Limite recomendado: 2500,0

Justificativa do limite: o valor limite sugerido não funciona para todas as workloads da API. No entanto, você pode usá-lo como um ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência maior em geral, você pode definir um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, ajustar o valor limite adequadamente.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latência

Dimensões: ApiId, estágio

Descrição do alarme: esse alarme detecta alta latência em um estágio. Encontre o valor da métrica IntegrationLatency para verificar a latência do back-end da API. Se as duas métricas estiverem alinhadas, o back-end da API será a fonte de maior latência e você deve investigar se há problemas de performance. Considere também ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando a alta latência. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por rota e restringir a origem da latência. Você também pode consultar o guia de solução de problemas com integrações do Lambda, se aplicável.

Intenção: esse alarme pode detectar quando as solicitações do API Gateway em um estágio têm alta latência. Caso as métricas detalhadas do CloudWatch estejam ativadas e você tenha diferentes requisitos de performance de latência por rota, recomendamos que você crie alarmes alternativos para ter um monitoramento mais detalhado da latência de cada rota.

Estatística: p90

Limite recomendado: 2500,0

Justificativa do limite: o valor limite sugerido não funciona para todas as workloads da API. No entanto, ele pode ser usado como ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e na latência aceitável, na performance e nos requisitos de SLA da API. Se for aceitável que a API tenha uma latência mais alta em geral, você poderá definir um valor limite mais alto para torná-la menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, ajustar o valor limite adequadamente.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Latência

Dimensões: ApiId, estágio, recurso, método

Descrição do alarme: esse alarme detecta alta latência para uma rota em um estágio. Encontre o valor da métrica IntegrationLatency para verificar a latência do back-end da API. Se as duas métricas estiverem mais alinhadas, o back-end da API será a fonte de maior latência e deve-se investigar quanto a problemas de performance. Considere também ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando a alta latência. Você também pode consultar o guia de solução de problemas com integrações do Lambda, se aplicável.

Intenção: esse alarme é usado para detectar quando as solicitações do API Gateway para uma rota em um estágio têm alta latência.

Estatística: p90

Limite recomendado: 2500,0

Justificativa do limite: o valor limite sugerido não funciona para todas as workloads da API. No entanto, ele pode ser usado como ponto de partida para o limite. Em seguida, você pode escolher diferentes valores limite com base na workload e nos requisitos aceitáveis de latência, performance e SLA da API. Se for aceitável que a API tenha uma latência maior em geral, você pode definir um valor limite mais alto para tornar o alarme menos sensível. No entanto, se for esperado que a API forneça respostas quase em tempo real, defina um valor limite mais baixo. Você também pode analisar dados históricos para determinar a latência de linha de base esperada para a workload da aplicação e, em seguida, ajustar o valor limite adequadamente.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

4xx

Dimensões: ApiId, estágio

Descrição do alarme: esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar um problema na autorização ou nos parâmetros da solicitação do cliente. Isso também pode significar que uma rota foi removida ou que um cliente está solicitando uma rota que não existe na API. Considere a possibilidade de ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando os erros 4xx. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por rota, o que ajudará você a restringir a origem dos erros. Os erros também podem ser causados por exceder o limite de controle de utilização configurado. Se as respostas e os logs estiverem relatando taxas altas e inesperadas de erros 429, siga este guia para solucionar esse problema.

Intenção: esse alarme pode detectar altas taxas de erros no lado do cliente para as solicitações do API Gateway.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 4xx. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 4xx que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

5xx

Dimensões: ApiId, estágio

Descrição do alarme: esse alarme detecta uma alta taxa de erros do lado do cliente. Isso pode indicar que há algo errado no back-end da API, na rede ou na integração entre o gateway da API e a API de back-end. Essa documentação pode ajudar você a solucionar a causa dos erros 5xx.

Intenção: esse alarme pode detectar altas taxas de erros no lado do servidor para as solicitações do API Gateway.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 5xx. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar qual é a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 5xx que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.

Período: 60

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: GREATER_THAN_THRESHOLD

MessageCount

Dimensões: ApiId, estágio

Descrição do alarme: esse alarme ajuda a detectar baixo volume de tráfego para o estágio da API de WebSocket. Isso pode indicar um problema quando os clientes chamam a API, como o uso de endpoints incorretos ou problemas com o back-end que envia mensagens aos clientes. Isso também pode indicar um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.

Intenção: esse alarme pode detectar um volume de tráfego inesperadamente baixo para o estágio da API de WebSocket. Recomendamos que você crie esse alarme se a sua API receber e enviar um número previsível e consistente de mensagens em condições normais. Caso as métricas detalhadas do CloudWatch estejam ativadas e você possa prever o volume normal de tráfego por rota, é melhor criar alarmes alternativos a esse para ter um monitoramento mais refinado das quedas no volume de tráfego para cada rota. Não recomendamos esse alarme para APIs que não esperam tráfego constante e consistente.

Estatística: SampleCount

Limite recomendado: depende da sua situação

Justificativa do limite: defina o valor limite com base na análise de dados históricos para determinar qual é a contagem de mensagens de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de tráfego normal e baixo esperado. Por outro lado, a definição de um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: LESS_THAN_THRESHOLD

MessageCount

Dimensões: ApiId, estágio, rota

Descrição do alarme: esse alarme ajuda a detectar um baixo volume de tráfego para a rota da API de WebSocket no estágio. Isso pode indicar um problema com os clientes que chamam a API, como o uso de endpoints incorretos, ou problemas com o back-end que envia mensagens aos clientes. Isso também pode indicar um problema com a configuração ou as permissões da API, tornando-a inacessível para os clientes.

Intenção: esse alarme pode detectar um volume de tráfego inesperadamente baixo para a rota da API de WebSocket no estágio. Recomendamos que você crie esse alarme se a sua API receber e enviar um número previsível e consistente de mensagens em condições normais. Não recomendamos esse alarme para APIs que não esperam tráfego constante e consistente.

Estatística: SampleCount

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite com base na análise de dados históricos para determinar qual é a contagem de mensagens de linha de base esperada para sua API. Definir o limite em um valor muito alto pode fazer com que o alarme seja muito sensível em períodos de tráfego normal e baixo esperado. Por outro lado, a definição de um valor muito baixo pode fazer com que o alarme não perceba quedas menores e anômalas no volume de tráfego.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: LESS_THAN_THRESHOLD

ClientError

Dimensões: ApiId, estágio

Descrição do alarme: esse alarme detecta uma alta taxa de erros do cliente. Isso pode indicar um problema nos parâmetros de autorização ou de mensagem. Isso também pode significar que uma rota foi removida ou que um cliente está solicitando uma rota que não existe na API. Considere a possibilidade de ativar o CloudWatch Logs e verificar se há algum erro que possa estar causando os erros 4xx. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para visualizar essa métrica por rota, o que ajudará você a restringir a origem dos erros. Os erros também podem ser causados por exceder o limite de controle de utilização configurado. Se as respostas e os logs estiverem relatando taxas altas e inesperadas de erros 429, siga este guia para solucionar esse problema.

Intenção: esse alarme pode detectar altas taxas de erros do cliente para as mensagens do API Gateway de WebSocket.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros 4xx. Você pode ajustar o limite de acordo com o tráfego das solicitações e com as taxas de erro aceitáveis. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 4xx que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

ExecutionError

Dimensões: ApiId, estágio

Descrição do alarme: esse alarme ajuda a detectar uma alta taxa de erros de execução. Isso pode ser causado por erros 5xx de sua integração, problemas de permissão ou outros fatores que impedem a invocação bem-sucedida da integração, como o fato de a integração ter passado por um controle de utilização ou ter sido excluída. Considere ativar o CloudWatch Logs para sua API e verificar os registros quanto ao tipo e à causa dos erros. Além disso, considere a possibilidade de ativar as métricas detalhadas do CloudWatch para obter uma visão dessa métrica por rota, o que ajudará você a restringir a origem dos erros. Essa documentação também pode ajudá-lo a solucionar a causa de qualquer erro de conexão.

Intenção: esse alarme pode detectar altas taxas de erros de execução para as mensagens da API Gateway de WebSocket.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: o limite sugerido detecta quando mais de 5% do total de solicitações estão recebendo erros de execução. Você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como para se adequar às taxas de erro aceitáveis. Você pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros de execução que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.

Período: 60

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon EC2 Auto Scaling

GroupInServiceCapacity

Dimensões: AutoScalingGroupName

Descrição do alarme: esse alarme ajuda a detectar quando a capacidade do grupo está abaixo da capacidade desejada para sua workload. Para solucionar problemas, verifique se há falhas de inicialização em suas atividades de escalonamento e confirme se a configuração da capacidade desejada está correta.

Intenção: esse alarme pode detectar uma baixa disponibilidade em seu grupo do Auto Scaling devido a falhas de inicialização ou inicializações suspensas.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite deve ser a capacidade mínima necessária para executar sua workload. Na maioria dos casos, é possível definir isso para corresponder à métrica GroupDesiredCapacity.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: LESS_THAN_THRESHOLD

Amazon CloudFront

5xxErrorRate

Dimensões: DistributionID, Região=Global

Descrição do alarme: esse alarme monitora a porcentagem de respostas de erro 5xx do seu servidor de origem para ajudar você a detectar se o serviço CloudFront está com problemas. Consulte Como solucionar problemas de respostas de erro da sua origem para obter informações que ajudem a entender os problemas com o servidor. Além disso, ative as métricas adicionais para obter métricas de erro detalhadas.

Intenção: esse alarme é usado para detectar problemas com o atendimento de solicitações do servidor de origem ou problemas com a comunicação entre o CloudFront e seu servidor de origem.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme é altamente dependente da tolerância para respostas 5xx. Você pode analisar dados históricos e tendências e, em seguida, definir o limite adequadamente. Como os erros 5xx podem ser causados por problemas transitórios, recomendamos que você defina o limite como um valor maior que 0 para que o alarme não seja muito sensível.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

OriginLatency

Dimensões: DistributionID, Região=Global

Descrição do alarme: o alarme ajuda a monitorar se o servidor de origem está demorando muito para responder. Se o servidor demorar muito para responder, isso pode levar a um tempo limite. Consulte Encontre e corrija respostas atrasadas de aplicações no seu servidor de origem se você tiver valores OriginLatency consistentemente altos.

Intenção: esse alarme é usado para detectar problemas com o servidor de origem que está demorando muito para responder.

Estatística: p90

Limite recomendado: depende da sua situação

Justificativa do limite: você deve calcular o valor de cerca de 80% do tempo limite da resposta de origem e usar o resultado como valor limite. Se essa métrica estiver consistentemente próxima do valor de tempo limite da resposta de origem, é possível que você comece a receber erros 504.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

FunctionValidationErrors

Dimensões: DistributionID, FunctionName, Região=Global

Descrição do alarme: esse alarme ajuda a monitorar os erros de validação do CloudFront Functions para que você possa tomar medidas para resolvê-los. Analise os logs do CloudWatch Functions e observe o código da função para encontrar e resolver a causa-raiz do problema. Consulte Restrições nas funções de borda para entender as configurações incorretas comuns do CloudFront Functions.

Intenção: esse alarme é usado para detectar erros de validação do CloudFront Functions.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: um valor maior que 0 indica um erro de validação. Recomendamos definir o limite como 0, pois os erros de validação implicam um problema quando o CloudFront Functions é transferido de volta para o CloudFront. Por exemplo, o CloudFront precisa do cabeçalho HTTP Host para processar uma solicitação. Não há nada que impeça um usuário de excluir o cabeçalho Host em seu código do CloudFront Functions. Mas quando o CloudFront recebe a resposta de volta e o cabeçalho Host está ausente, o CloudFront gera um erro de validação.

Período: 60

Pontos de dados para o alarme: 2

Períodos de avaliação: 2

Operador de comparação: GREATER_THAN_THRESHOLD

FunctionExecutionErrors

Dimensões: DistributionID, FunctionName, Região=Global

Descrição do alarme: esse alarme ajuda a monitorar os erros de execução do CloudFront Functions para que você possa tomar medidas para resolvê-los. Analise os logs do CloudWatch Functions e observe o código da função para encontrar e resolver a causa-raiz do problema.

Intenção: esse alarme é usado para detectar erros de execução do CloudFront Functions.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: recomendamos definir o limite como 0, pois um erro de execução indica um problema com o código que ocorre no runtime.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

FunctionThrottles

Dimensões: DistributionID, FunctionName, Região=Global

Descrição do alarme: esse alarme ajuda você a monitorar se o CloudFront Functions está com controle de utilização. Caso sua função esteja com um controle de utilização, isso significa que ela está demorando muito para ser executada. Para evitar o controle de utilização de funções, considere otimizar o código da função.

Intenção: esse alarme pode detectar quando o CloudFront Functions está com um controle de utilização, de modo que você possa reagir e resolver o problema para proporcionar uma experiência tranquila ao cliente.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: recomendamos definir o limite como 0 para permitir uma resolução mais rápida dos controles de utilização da função.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon Cognito

SignUpThrottles

Dimensões: UserPool, UserPoolClient

Descrição do alarme: esse alarme monitora a contagem de solicitações com controle de utilização. Se os usuários estiverem constantemente com um controle de utilização, você deverá aumentar o limite solicitando um aumento da cota de serviços. Consulte Cotas no Amazon Cognito para saber como solicitar um aumento de cotas. Para tomar medidas proativas, considere monitorar a cota de uso.

Intenção: esse alarme ajuda a monitorar a ocorrência de solicitações de cadastro com controle de utilização. Isso pode ajudar você a saber quando tomar medidas para atenuar qualquer degradação na experiência de cadastro. O controle de utilização contínuo das solicitações é uma experiência negativa de cadastro do usuário.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: um grupo de usuários bem provisionado não deve encontrar nenhum controle de utilização que se estenda por vários pontos de dados. Portanto, um limite típico para uma workload esperada deve ser zero. Para uma workload irregular com picos frequentes, você pode analisar dados históricos para determinar o controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Uma solicitação de controle de utilização deve ser testada novamente para minimizar o impacto na aplicação.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

SignInThrottles

Dimensões: UserPool, UserPoolClient

Descrição do alarme: esse alarme monitora a contagem de solicitações com controle de utilização de autenticação do usuário. Caso os usuários estejam constantemente passando por controle de utilização, talvez seja necessário aumentar o limite solicitando um aumento da cota de serviços. Consulte Cotas no Amazon Cognito para saber como solicitar um aumento de cotas. Para tomar medidas proativas, considere monitorar a cota de uso.

Intenção: esse alarme ajuda a monitorar a ocorrência de solicitações de login com controle de utilização. Isso pode ajudar você a saber quando tomar medidas para atenuar qualquer degradação na experiência de login. O controle de utilização contínuo das solicitações é uma experiência ruim de autenticação do usuário.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: um grupo de usuários bem provisionado não deve encontrar nenhum controle de utilização que se estenda por vários pontos de dados. Portanto, um limite típico para uma workload esperada deve ser zero. Para uma workload irregular com picos frequentes, você pode analisar dados históricos para determinar o controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Uma solicitação de controle de utilização deve ser testada novamente para minimizar o impacto na aplicação.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

TokenRefreshThrottles

Dimensões: UserPool, UserPoolClient

Descrição do alarme: você pode definir o valor do limite para se adequar ao tráfego da solicitação, bem como para corresponder ao controle de utilização aceitável para solicitações de atualização de token. O controle de utilização é usado para proteger seu sistema de muitas solicitações. No entanto, é importante monitorar se o provisionamento também é insuficiente para o seu tráfego normal. Você pode analisar dados históricos para encontrar o controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite de alarme para que ele seja maior do que o nível de controle de utilização aceitável. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um valor muito baixo para o limite pode fazer com que o alarme seja sensível.

Intenção: esse alarme ajuda a monitorar a ocorrência de solicitações de atualização de token com controle de utilização. Isso pode ajudar você a saber quando tomar medidas para atenuar possíveis problemas, para garantir uma experiência de usuário tranquila e a integridade e confiabilidade do seu sistema de autenticação. O controle de utilização contínuo das solicitações é uma experiência ruim de autenticação do usuário.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite também pode ser definido/ajustado para se adequar ao tráfego da solicitação, bem como ao controle de utilização aceitável para solicitações de atualização de token. O controle de utilização existe para proteger seu sistema de muitas solicitações. No entanto, é importante monitorar se o provisionamento para o tráfego normal também está insuficiente e verificar se isso está causando o impacto. Os dados históricos também podem ser analisados para verificar qual é o controle de utilização aceitável para a workload da aplicação, e o limite pode ser ajustado para um nível mais alto do que o controle de utilização aceitável habitual. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um valor muito baixo para o limite pode fazer com que o alarme seja sensível.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

FederationThrottles

Dimensões: UserPool, UserPoolClient, IdentityProvider

Descrição do alarme: esse alarme monitora a contagem de solicitações de federação de identidades com controle de utilização. Se você observar um controle de utilização constante, isso pode indicar que é necessário aumentar o limite solicitando um aumento da cota de serviços. Consulte Cotas no Amazon Cognito para saber como solicitar um aumento de cotas.

Intenção: esse alarme ajuda a monitorar a ocorrência de solicitações de federação de identidades com controle de utilização. Isso pode ajudar você a responder proativamente a gargalos de performance ou configurações incorretas e garantir uma experiência de autenticação tranquila para seus usuários. O controle de utilização contínuo das solicitações é uma experiência ruim de autenticação do usuário.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: você pode definir o limite para se adequar ao tráfego da solicitação, bem como para corresponder ao controle de utilização aceitável para solicitações de federação de identidades. O controle de utilização é usado para proteger seu sistema de um número excessivo de solicitações. No entanto, é importante monitorar se o provisionamento também é insuficiente para o seu tráfego normal. Você pode analisar os dados históricos para encontrar o controle de utilização aceitável para a workload da aplicação e, em seguida, definir o limite para um valor acima do nível de controle de utilização aceitável. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um valor muito baixo para o limite pode fazer com que o alarme seja sensível.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon DynamoDB

AccountProvisionedReadCapacityUtilization

Dimensões: nenhuma

Descrição do alarme: esse alarme detecta se a capacidade de leitura da conta está atingindo o limite provisionado. Se isso ocorrer, você poderá aumentar a cota da conta para utilização da capacidade de leitura. Você pode visualizar suas cotas atuais para unidades de capacidade de leitura e solicitar aumentos usando o Service Quotas.

Intenção: o alarme pode detectar se a utilização da capacidade de leitura da conta está se aproximando da utilização da capacidade de leitura provisionada. Se a utilização atingir seu limite máximo, o DynamoDB começará a realizar o controle de utilização nas solicitações de leitura.

Estatística: máxima

Limite recomendado: 80,0

Justificativa do limite: defina o limite para 80%, de modo que uma medida (como aumentar os limites da conta) possa ser tomada antes de atingir a capacidade total para evitar o controle de utilização.

Período: 300

Pontos de dados para o alarme: 2

Períodos de avaliação: 2

Operador de comparação: GREATER_THAN_THRESHOLD

AccountProvisionedWriteCapacityUtilization

Dimensões: nenhuma

Descrição do alarme: esse alarme detecta se a capacidade de gravação da conta está atingindo o limite provisionado. Se isso ocorrer, você poderá aumentar a cota da conta para utilização da capacidade de gravação. Você pode visualizar suas cotas atuais para unidades de capacidade de gravação e solicitar aumentos usando o Service Quotas.

Intenção: esse alarme pode detectar se a utilização da capacidade de gravação da conta está se aproximando da utilização da capacidade de gravação provisionada. Se a utilização atingir seu limite máximo, o DynamoDB começará a realizar o controle de utilização das solicitações de gravação.

Estatística: máxima

Limite recomendado: 80,0

Justificativa do limite: defina o limite para 80%, para que a medida (como aumentar os limites da conta) possa ser tomada antes de atingir a capacidade total para evitar o controle de utilização.

Período: 300

Pontos de dados para o alarme: 2

Períodos de avaliação: 2

Operador de comparação: GREATER_THAN_THRESHOLD

AgeOfOldestUnreplicatedRecord

Dimensões: TableName, DelegateDoperation

Descrição do alarme: esse alarme detecta o atraso na replicação para um fluxo de dados do Kinesis. Em operação normal, AgeOfOldestUnreplicatedRecord deve estar na ordem dos milissegundos. Esse número cresce com base em tentativas de replicação malsucedidas causadas por escolhas de configuração controladas pelo cliente. Exemplos de configurações controladas pelo cliente que levam a tentativas de replicação malsucedidas são uma capacidade de fluxo de dados do Kinesis com provisionamento insuficiente que leva a um controle de utilização excessivo ou uma atualização manual das políticas de acesso do fluxo de dados do Kinesis que impede o DynamoDB de adicionar dados ao fluxo de dados. Para manter essa métrica o mais baixa possível, você precisa garantir o provisionamento correto da capacidade do fluxo de dados do Kinesis e certificar-se de que as permissões do DynamoDB não foram alteradas.

Intenção: esse alarme pode monitorar tentativas de replicação malsucedidas e o atraso resultante na replicação para o fluxo de dados do Kinesis.

Estatística: máxima

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite de acordo com o atraso de replicação desejado, medido em milissegundos. Esse valor depende dos requisitos de sua workload e da performance esperada.

Período: 300

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: GREATER_THAN_THRESHOLD

FailedToReplicateRecordCount

Dimensões: TableName, DelegateDoperation

Descrição do alarme: esse alarme detecta o número de registros que o DynamoDB não conseguiu replicar para o fluxo de dados do Kinesis. Determinados itens com mais de 34 KB podem se expandir em tamanho para alterar registros de dados maiores que o limite de 1 MB para itens do Kinesis Data Streams. Essa expansão de tamanho ocorre quando os itens com mais de 34 KB contêm um grande número de valores de atributos booleanos ou vazios. Valores de atributos booleanos e vazios são armazenados como 1 byte no DynamoDB, mas expandem até 5 bytes quando são serializados usando JSON padrão para replicação do Kinesis Data Streams. O DynamoDB não consegue replicar esses registros de alteração para o fluxo de dados do Kinesis. O DynamoDB ignora esses registros de dados de alteração e continua automaticamente a replicar registros subsequentes.

Intenção: esse alarme pode monitorar o número de registros que o DynamoDB não conseguiu replicar para o seu fluxo de dados do Kinesis devido ao limite de tamanho de item dos fluxos de dados do Kinesis.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: defina o limite como 0 para detectar quaisquer registros que o DynamoDB não conseguiu replicar.

Período: 60

Pontos de dados para o alarme: 1

Períodos de avaliação: 1

Operador de comparação: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensões: TableName

Descrição do alarme: esse alarme detecta se há um grande número de solicitações de leitura passando por um controle de utilização para a tabela do DynamoDB. Para solucionar o problema, consulte Solução de problemas de controle de utilização no Amazon DynamoDB.

Intenção: esse alarme pode detectar o controle de utilização contínuo de solicitações de leitura na tabela do DynamoDB. O controle de utilização contínuo das solicitações de leitura pode afetar negativamente as operações de leitura de sua workload e reduzir a eficiência geral do sistema.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite de acordo com o tráfego de leitura esperado para a tabela do DynamoDB, levando em conta um nível aceitável de controle de utilização. É importante monitorar se você está com provisionamento insuficiente e não está causando um controle de utilização consistente. Você também pode analisar os dados históricos para encontrar o nível de controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite para que seja mais alto do que o nível de controle de utilização habitual. As solicitações com controle de utilização devem ser repetidas pela aplicação ou serviço, pois são transitórias. Portanto, um limite muito baixo pode fazer com que o alarme seja sensível demais, causando transições de estado indesejadas.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

ReadThrottleEvents

Dimensões: TableName, GlobalSecondaryIndexName

Descrição do alarme: esse alarme detecta se há um grande número de solicitações de leitura sendo limitadas para o índice secundário global da tabela do DynamoDB. Para solucionar o problema, consulte Solução de problemas de controle de utilização no Amazon DynamoDB.

Intenção: o alarme pode detectar o controle de utilização contínuo de solicitações de leitura para o índice secundário global da tabela do DynamoDB. O controle de utilização contínuo das solicitações de leitura pode afetar negativamente as operações de leitura de sua workload e reduzir a eficiência geral do sistema.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite de acordo com o tráfego de leitura esperado para a tabela do DynamoDB, levando em conta um nível aceitável de controle de utilização. É importante monitorar se você está com provisionamento insuficiente e não está causando um controle de utilização consistente. Você também pode analisar os dados históricos para encontrar um nível de controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite para que seja mais alto do que o nível de controle de utilização aceitável habitual. As solicitações com controle de utilização devem ser repetidas pela aplicação ou serviço, pois são transitórias. Portanto, um limite muito baixo pode fazer com que o alarme seja sensível demais, causando transições de estado indesejadas.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

ReplicationLatency

Dimensões: TableName, ReceivingRegion

Descrição do alarme: o alarme detecta se a réplica em uma região para a tabela global está atrasada em relação à região de origem. A latência poderá aumentar se uma região da AWS ficar degradada e você tiver uma tabela de réplica nessa região. Nesse caso, você pode redirecionar temporariamente as atividades de leitura e gravação da aplicação para outra região da AWS. Se você estiver usando 2017.11.29 (herdado) de tabelas globais, verifique se as unidades de capacidade de gravação (WCUs) são idênticas para cada uma das tabelas de réplica. Você também pode seguir as recomendações em Práticas recomendadas e requisitos de gerenciamento de capacidade.

Intenção: o alarme pode detectar se a tabela de réplica em uma região está ficando para trás na replicação das alterações de outra região. Isso pode fazer com que sua réplica se desvie das outras réplicas. É útil saber a latência de replicação de cada região da AWS e alertar se essa latência de replicação aumenta continuamente. A replicação da tabela se aplica somente a tabelas globais.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme depende muito do seu caso de uso. Latências de replicação superiores a três minutos geralmente são motivo de investigação. Analise a importância e os requisitos do atraso de replicação e analise as tendências históricas. Em seguida, selecione o limite adequadamente.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

SuccessfulRequestLatency

Dimensões: TableName, operação

Descrição do alarme: esse alarme detecta uma alta latência para a operação da tabela do DynamoDB (indicada pelo valor da dimensão da Operation no alarme). Consulte este documento de solução de problemas para solucionar problemas de latência no Amazon DynamoDB.

Intenção: esse alarme pode detectar uma alta latência para a operação da tabela do DynamoDB. A latência mais alta para as operações pode afetar negativamente a eficiência geral do sistema.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o DynamoDB fornece latência de um dígito de milissegundos, em média, para as operações singleton, como GetItem, PutItem e assim por diante. No entanto, é possível definir o limite com base na tolerância aceitável para a latência do tipo de operação e da tabela envolvida na workload. Você pode analisar os dados históricos dessa métrica para descobrir a latência usual da operação da tabela e, em seguida, definir o limite para um número que represente o atraso crítico da operação.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_THRESHOLD

SystemErrors

Dimensões: TableName

Descrição do alarme: esse alarme detecta um número alto e contínuo de erros de sistema para as solicitações de tabela do DynamoDB. Se você continuar recebendo erros 5xx, abra o AWS Service Health Dashboard para verificar se há problemas operacionais no serviço. Você pode usar esse alarme para receber notificações caso haja um problema prolongado de serviço interno do DynamoDB, e isso ajuda você a se correlacionar com o problema que a aplicação cliente está enfrentando. Consulte Tratamento de erros com o DynamoDB para obter mais informações.

Intenção: esse alarme pode detectar erros de sistema contínuos para as solicitações de tabela do DynamoDB. Os erros do sistema indicam erros de serviço interno do DynamoDB e ajudam a correlacionar com o problema que o cliente está enfrentando.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite de acordo com o tráfego esperado, levando em conta um nível aceitável de erros do sistema. Você também pode analisar dados históricos para encontrar a contagem de erros aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros do sistema devem ser testados novamente pela aplicação/serviço, pois são transitórios. Portanto, um limite muito baixo pode fazer com que o alarme seja sensível demais, causando transições de estado indesejadas.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

ThrottledPutRecordCount

Dimensões: TableName, DelegateDoperation

Descrição do alarme: esse alarme detecta os registros que estão tendo controle de utilização pelo fluxo de dados do Kinesis durante a replicação da captura de dados de alteração para o Kinesis. Esse controle de utilização ocorre devido à capacidade insuficiente do fluxo de dados do Kinesis. Se você perceber controle de utilização excessivo e regular, talvez seja necessário aumentar o número de fragmentos de fluxos do Kinesis proporcionalmente ao throughput de gravação observada da tabela. Para saber mais sobre a determinação do tamanho de um fluxo de dados do Kinesis, consulte Como determinar o tamanho inicial de um fluxo de dados do Kinesis.

Intenção: esse alarme pode monitorar o número de registros com controle de utilização pelo fluxo de dados do Kinesis devido à capacidade insuficiente do fluxo de dados do Kinesis.

Estatística: máxima

Limite recomendado: depende da sua situação

Justificativa do limite: é possível que haja algum controle de utilização durante picos de uso excepcionais, mas os registros com controle de utilização devem permanecer o mais baixo possível para evitar maior latência de replicação (o DynamoDB tenta novamente enviar registros com controle de utilização para o fluxo de dados do Kinesis). Defina o limite para um número que possa ajudar você a detectar o controle de utilização excessivo regular. Você também pode analisar os dados históricos dessa métrica para encontrar as taxas de controle de utilização aceitáveis para a workload da aplicação. Ajuste o limite para um valor que a aplicação possa tolerar com base no seu caso de uso.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_THRESHOLD

UserErrors

Dimensões: nenhuma

Descrição do alarme: esse alarme detecta um número alto e contínuo de erros de usuário para as solicitações da tabela do DynamoDB. Você pode verificar os logs da aplicação cliente durante o período do problema para ver por que as solicitações são inválidas. Você pode verificar o código de status HTTP 400 para ver o tipo de erro que você está recebendo e tomar as medidas necessárias. Talvez seja necessário corrigir a lógica da aplicação para criar solicitações válidas.

Intenção: esse alarme pode detectar erros de usuário contínuos para as solicitações da tabela do DynamoDB. Os erros do usuário para operações solicitadas significam que o cliente está produzindo solicitações inválidas e está falhando.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite como zero para detectar quaisquer erros do lado do cliente. Ou você pode defini-lo com um valor mais alto se quiser evitar o acionamento do alarme para um número muito baixo de erros. Decida com base no seu caso de uso e no tráfego das solicitações.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensões: TableName

Descrição do alarme: esse alarme detecta se há um grande número de solicitações de gravação passando por um controle de utilização para a tabela do DynamoDB. Consulte Solução de problemas de controle de utilização no Amazon DynamoDB para solucionar o problema.

Intenção: esse alarme pode detectar o controle de utilização contínuo de solicitações de gravação na tabela do DynamoDB. O controle de utilização contínuo das solicitações de gravação pode afetar negativamente as operações de gravação de sua workload e reduzir a eficiência geral do sistema.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite de acordo com o tráfego de gravação esperado para a tabela do DynamoDB, levando em conta um nível aceitável de controle de utilização. É importante monitorar se você está com provisionamento insuficiente e não está causando um controle de utilização consistente. Você também pode analisar os dados históricos para encontrar o nível aceitável de controle de utilização para a workload da aplicação e, em seguida, ajustar o limite para um valor mais alto do que o nível aceitável de controle de utilização habitual. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um limite muito baixo pode fazer com que o alarme seja sensível demais, causando transições de estado indesejadas.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

WriteThrottleEvents

Dimensões: TableName, GlobalSecondaryIndexName

Descrição do alarme: esse alarme detecta se há um grande número de solicitações de gravação sendo limitadas para o índice secundário global da tabela do DynamoDB. Consulte Solução de problemas de controle de utilização no Amazon DynamoDB para solucionar o problema.

Intenção: esse alarme pode detectar o controle de utilização contínuo de solicitações de gravação para o índice secundário global da tabela do DynamoDB. O controle de utilização contínuo das solicitações de gravação pode afetar negativamente as operações de gravação de sua workload e reduzir a eficiência geral do sistema.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite de acordo com o tráfego de gravação esperado para a tabela do DynamoDB, levando em conta um nível aceitável de controle de utilização. É importante monitorar se você está com provisionamento insuficiente e não está causando um controle de utilização consistente. Você também pode analisar os dados históricos para encontrar o nível de controle de utilização aceitável para a workload da aplicação e, em seguida, ajustar o limite para um valor mais alto do que o nível de controle de utilização aceitável usual. As solicitações de controle de utilização devem ser repetidas pela aplicação/serviço, pois são transitórias. Portanto, um valor muito baixo pode fazer com que o alarme seja sensível demais, o que causa transições de estado indesejadas.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon EBS

VolumeStalledIOCheck

Dimensões: VolumeId, InstanceId

Descrição do alarme: este alarme ajuda você a monitorar o desempenho de E/S dos seus volumes do Amazon EBS. Essa verificação detecta problemas subjacentes com a infraestrutura do Amazon EBS, como problemas de hardware ou software nos subsistemas de armazenamento subjacentes aos volumes do Amazon EBS, problemas de hardware no host físico que afetam a acessibilidade dos volumes do Amazon EBS da sua instância do Amazon EC2 e pode detectar problemas de conectividade entre a instância e os volumes do Amazon EBS. Se a verificação Stalled IO falhar, você poderá esperar a AWS resolver o problema ou pode tomar medidas, como substituir os volumes afetados ou parar e reiniciar a instância à qual o volume está anexado. Na maioria dos casos, quando essa métrica falha, o Amazon EBS diagnostica e recupera automaticamente o volume em alguns minutos.

Intenção: este alarme pode detectar o status dos seus volumes do Amazon EBS para determinar quando esses volumes estão danificados e não conseguem concluir as operações de E/S.

Estatística: máxima

Limite recomendado: 1,0

Justificativa do limite: quando uma verificação de status falha, o valor dessa métrica é 1. O limite é definido de modo que, sempre que a verificação de status falhar, o alarme estará no estado ALARME.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Amazon EC2

CPUUtilization

Dimensões: InstanceId

Descrição do alarme: esse alarme ajuda a monitorar a utilização da CPU de uma instância do EC2. Dependendo da aplicação, níveis de utilização consistentemente altos podem ser normais. Porém, se a performance for prejudicada e a aplicação não for limitada por E/S de disco, memória ou recursos de rede, uma CPU no limite máximo poderá indicar um gargalo de recursos ou problemas de performance da aplicação. A alta utilização da CPU pode indicar que é necessário fazer um upgrade para uma instância que consome mais CPU. Se o monitoramento detalhado estiver ativado, você poderá alterar o período para 60 segundos em vez de 300 segundos. Para obter mais informações, consulte Habilitar ou desabilitar o monitoramento detalhado para instâncias.

Intenção: esse alarme é usado para detectar a alta utilização da CPU.

Estatística: média

Limite recomendado: 80,0

Justificativa do limite: normalmente, é possível definir o limite de utilização da CPU para 70% a 80%. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload. Para alguns sistemas, a utilização consistentemente alta da CPU pode ser normal e não indicar um problema, enquanto para outros pode ser motivo de preocupação. Analise os dados históricos de utilização da CPU para identificar o uso, descubra qual utilização da CPU é aceitável para seu sistema e defina o limite adequadamente.

Período: 300

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: GREATER_THAN_THRESHOLD

StatusCheckFailed

Dimensões: InstanceId

Descrição do alarme: esse alarme ajuda a monitorar as verificações de status do sistema e as verificações de status da instância. Se qualquer um dos tipos de verificação de status falhar, esse alarme deverá estar no estado ALARME.

Intenção: esse alarme é usado para detectar os problemas subjacentes com as instâncias, incluindo falhas na verificação do status do sistema e falhas na verificação do status da instância.

Estatística: máxima

Limite recomendado: 1,0

Justificativa do limite: quando uma verificação de status falha, o valor dessa métrica é 1. O limite é definido de modo que, sempre que a verificação de status falhar, o alarme estará no estado ALARME.

Período: 300

Pontos de dados para o alarme: 2

Períodos de avaliação: 2

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

StatusCheckFailed_AttachedEBS

Dimensões: InstanceId

Descrição do alarme: esse alarme ajuda a monitorar se os volumes do Amazon EBS anexados a uma instância estão acessíveis e são capazes de concluir operações de E/S. Essa verificação de status detecta problemas subjacentes na infraestrutura do Amazon EBS ou com a computação, por exemplo:

• Problemas de hardware ou software nos subsistemas de armazenamento subjacentes aos volumes do Amazon EBS

• Problemas de hardware no host físico que afetam a acessibilidade dos volumes do Amazon EBS

• Problemas de conectividade entre a instância e os volumes do Amazon EBS

Quando houver uma falha na verificação de status do EBS anexado, você poderá esperar que a Amazon resolva o problema ou adotar medidas por conta própria, p. ex., substituir os volumes afetados ou interromper e reiniciar a instância.

Intenção: esse alarme é usado para detectar volumes inacessíveis do Amazon EBS conectados a uma instância. Isso pode causar falhas nas operações de E/S.

Estatística: máxima

Limite recomendado: 1,0

Justificativa do limite: quando uma verificação de status falha, o valor dessa métrica é 1. O limite é definido de modo que, sempre que a verificação de status falhar, o alarme estará no estado ALARME.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Amazon ElastiCache

CPUUtilization

Dimensões: CacheClusterId, CacheNodeId

Descrição do alarme: esse alarme ajuda a monitorar a utilização da CPU de toda a instância do ElastiCache, incluindo os processos do mecanismo de banco de dados e outros processos em execução na instância. O AWS Elasticache é compatível com dois tipos de mecanismo: Memcached e Redis. Quando atingir uma alta utilização da CPU em um nó do Memcached, considere aumentar a escala verticalmente do tipo de instância ou adicionar novos nós de cache. Para o Redis, se sua workload principal for de solicitações de leitura, você deve considerar adicionar mais réplicas de leitura ao cluster de cache. Se a sua workload principal for de solicitações de gravação, considere adicionar mais fragmentos para distribuir a workload em mais nós primários, caso esteja executando no modo em cluster, ou aumentar a escala verticalmente do seu tipo de instância, caso esteja executando o Redis no modo sem cluster.

Intenção: esse alarme é usado para detectar a alta utilização da CPU dos hosts do ElastiCache. É útil obter uma visão ampla do uso da CPU em toda a instância, incluindo processos que não são do mecanismo.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite como a porcentagem que reflete um nível crítico de utilização da CPU para sua aplicação. Para o Memcached, o mecanismo pode usar até núcleos num_threads. Para o Redis, o mecanismo é basicamente de thread único, mas pode usar núcleos adicionais, se disponíveis, para acelerar a E/S. Na maioria dos casos, você pode definir o limite para cerca de 90% da CPU disponível. Como o Redis é de thread único, o valor limite real deve ser calculado como uma fração da capacidade total do nó.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

CurrConnections

Dimensões: CacheClusterId, CacheNodeId

Descrição do alarme: esse alarme detecta uma alta contagem de conexões, o que pode indicar uma carga pesada ou problemas de performance. Um aumento constante de CurrConnections pode levar ao esgotamento das 65 mil conexões disponíveis. Isso pode indicar que as conexões foram fechadas incorretamente no lado da aplicação e permaneceram estabelecidas no lado do servidor. É preciso considerar o uso de pooling de conexões ou tempos limite de conexão ociosa para limitar o número de conexões feitas ao cluster ou, no caso do Redis, considerar o ajuste do tcp-keepalive em seu cluster para detectar e encerrar possíveis pares mortos.

Intenção: o alarme ajuda a identificar altas contagens de conexões que podem afetar a performance e a estabilidade do cluster do ElastiCache.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme depende muito do intervalo aceitável de conexões para o seu cluster. Revise a capacidade e a workload esperada de seu cluster do ElastiCache e analise as contagens históricas de conexões durante o uso regular para estabelecer uma linha de base e, em seguida, selecione um limite adequadamente. Lembre-se de que cada nó comporta até 65 mil conexões simultâneas.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_THRESHOLD

DatabaseMemoryUsagePercentage

Dimensões: CacheClusterId

Descrição do alarme: esse alarme ajuda você a monitorar a utilização da memória do seu cluster. Quando DatabaseMemoryUsagePercentage atinge 100%, a política de memória máxima do Redis é acionada e podem ocorrer remoções com base na política selecionada. Se nenhum objeto no cache corresponder à política de remoção, as operações de gravação falharão. Algumas workloads esperam ou dependem de remoções, mas, se não for o caso, você precisará aumentar a capacidade de memória do seu cluster. Você pode escalar verticalmente seu cluster adicionando mais nós primários, ou aumentá-lo usando um tipo de nó maior. Consulte Escalabilidade de clusters do ElastiCache for Redis para obter detalhes.

Intenção: esse alarme é usado para detectar a alta utilização de memória do seu cluster para que você possa evitar falhas ao gravar no cluster. É útil saber quando você precisará aumentar a escala verticalmente do seu cluster caso sua aplicação não espere passar por remoções.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: dependendo dos requisitos de memória da sua aplicação e da capacidade de memória do seu cluster do ElastiCache, você deve definir o limite para a porcentagem que reflete o nível crítico de uso de memória do cluster. Você pode usar dados históricos de uso de memória como referência para o limite aceitável de uso de memória.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

EngineCPUUtilization

Dimensões: CacheClusterId

Descrição do alarme: esse alarme ajuda a monitorar a utilização da CPU de um thread do mecanismo Redis dentro da instância do ElastiCache. Os motivos comuns para o alto nível de CPU do mecanismo são comandos de longa execução que consomem muita CPU, um alto número de solicitações, um aumento de novas solicitações de conexão de cliente em um curto período de tempo e grandes remoções quando o cache não tem memória suficiente para armazenar novos dados. Você deve considerar a Escalabilidade de clusters do ElastiCache for Redis adicionando mais nós ou aumentando a escala verticalmente do seu tipo de instância.

Intenção: esse alarme é usado para detectar a alta utilização da CPU do thread do mecanismo Redis. Ele é útil caso deseje monitorar o uso da CPU do próprio mecanismo de banco de dados.

Estatística: média

Limite recomendado: 90,0

Justificativa do limite: defina o limite como uma porcentagem que reflita o nível crítico de utilização da CPU do mecanismo para a sua aplicação. Você pode fazer um benchmark do seu cluster usando sua aplicação e a workload esperada para correlacionar a utilização do EngineCPUUtilization e a performance como referência e, em seguida, definir o limite adequadamente. Na maioria dos casos, você pode definir o limite para cerca de 90% da CPU disponível.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

ReplicationLag

Dimensões: CacheClusterId

Descrição do alarme: esse alarme ajuda a monitorar a integridade da replicação do cluster do ElastiCache. Um alto atraso de replicação significa que o nó primário ou a réplica não consegue manter o ritmo da replicação. Se a atividade de gravação for muito alta, considere escalar o cluster adicionando mais nós primários ou ampliando-o usando um tipo de nó maior. Consulte Escalabilidade de clusters do ElastiCache for Redis para obter detalhes. Se suas réplicas de leitura estiverem sobrecarregadas pela quantidade de solicitações de leitura, considere adicionar mais réplicas de leitura.

Intenção: esse alarme é usado para detectar um atraso entre as atualizações de dados no nó primário e sua sincronização com o nó de réplica. Ele ajuda a garantir a consistência dos dados de um nó de cluster de réplica de leitura.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite de acordo com os requisitos de sua aplicação e o possível impacto do atraso da replicação. Você deve considerar as taxas de gravação esperadas da sua aplicação e as condições de rede para o atraso de replicação aceitável.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon EC2 (AWS/ElasticGPUs)

GPUConnectivityCheckFailed

Dimensões: InstanceId, EGPUId

Descrição do alarme: esse alarme ajuda a detectar falhas de conexão entre a instância e o acelerador do Elastic Graphics. O Elastic Graphics usa a rede de instâncias para enviar comandos OpenGL a uma placa gráfica remotamente anexada. Além disso, uma área de trabalho que executa uma aplicação OpenGL com um acelerador do Elastic Graphics geralmente é acessada usando a tecnologia de acesso remoto. É importante distinguir entre um problema de performance relativo à renderização do OpenGL ou à tecnologia de acesso remoto da área de trabalho. Para saber mais sobre o problema, consulte Investigar problemas na performance da aplicação.

Intenção: esse alarme é usado para detectar problemas de conectividade da instância com o acelerador do Elastic Graphics.

Estatística: máxima

Limite recomendado: 0,0

Justificativa do limite: o valor limite de 1 indica que a conectividade falhou.

Período: 300

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: GREATER_THAN_THRESHOLD

GPUHealthCheckFailed

Dimensões: InstanceId, EGPUId

Descrição do alarme: esse alarme ajuda você a saber quando o status do acelerador gráfico do Elastic não está íntegro. Se o acelerador não estiver íntegro, consulte as etapas de solução de problemas em Resolver problemas de status não íntegros.

Intenção: esse alarme é usado para detectar se o acelerador do Elastic Graphics não está íntegro.

Estatística: máxima

Limite recomendado: 0,0

Justificativa do limite: o valor limite de 1 indica uma falha na verificação de status.

Período: 300

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon ECS

CPUReservation

Dimensões: ClusterName

Descrição do alarme: esse alarme ajuda a detectar uma alta reserva de CPU no cluster do ECS. A alta reserva de CPU pode indicar que o cluster está ficando sem CPUs registradas para a tarefa. Para solucionar problemas, você pode adicionar mais capacidade, escalar o cluster ou configurar o ajuste de escala automático.

Intenção: o alarme é usado para detectar se o número total de unidades de CPU reservadas por tarefas no cluster está atingindo o total de unidades de CPU registradas para o cluster. Isso ajuda você a saber quando aumentar a escala do cluster verticalmente. Alcançar o total de unidades de CPU do cluster pode resultar na falta de CPU para tarefas. Se o escalonamento gerenciado dos provedores de capacidade do EC2 estiver ativado ou se você tiver associado o Fargate a provedores de capacidade, esse alarme não é recomendado.

Estatística: média

Limite recomendado: 90,0

Justificativa do limite: defina o limite para reserva de CPU em 90%. Como alternativa, você pode escolher um valor mais baixo com base nas características do cluster.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

CPUUtilization

Dimensões: ClusterName, ServiceName

Descrição do alarme: esse alarme ajuda você a detectar uma alta utilização da CPU do serviço do ECS. Se não houver nenhuma implantação de ECS em andamento, a utilização máxima da CPU poderá indicar um gargalo de recursos ou problemas de performance da aplicação. Para solucionar o problema, você pode aumentar o limite da CPU.

Intenção: esse alarme é usado para detectar a alta utilização da CPU no serviço do ECS. A alta utilização consistente da CPU pode indicar um gargalo de recursos ou problemas de performance da aplicação.

Estatística: média

Limite recomendado: 90,0

Justificativa do limite: as métricas de serviço para utilização da CPU podem exceder 100% de utilização. No entanto, recomendamos que você monitore a métrica quanto à alta utilização da CPU para evitar o impacto em outros serviços. Defina o limite para cerca de 90% a 95%. Recomendamos que você atualize suas definições de tarefas para refletir o uso real a fim de evitar problemas futuros com outros serviços.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

MemoryReservation

Dimensões: ClusterName

Descrição do alarme: esse alarme ajuda você a detectar uma reserva de memória alta no cluster do ECS. A alta reserva de memória pode indicar um gargalo de recursos para o cluster. Para solucionar problemas, analise a performance da tarefa de serviço para ver se a utilização da memória da tarefa pode ser otimizada. Além disso, é possível registrar mais memória ou configurar o ajuste de escala automático.

Intenção: o alarme é usado para detectar se o total de unidades de memória reservadas por tarefas no cluster está atingindo o total de unidades de memória registradas para o cluster. Isso pode ajudar você a saber quando aumentar a escala verticalmente do cluster. Atingir o total de unidades de memória do cluster pode fazer com que o cluster não consiga iniciar novas tarefas. Se você tiver o escalonamento gerenciado dos provedores de capacidade do EC2 ativado ou se tiver associado o Fargate a provedores de capacidade, esse alarme não é recomendado.

Estatística: média

Limite recomendado: 90,0

Justificativa do limite: defina o limite para reserva de memória em 90%. Você pode ajustar isso para um valor mais baixo com base nas características do cluster.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

HTTPCode_Target_5XX_Count

Dimensões: ClusterName, ServiceName

Descrição do alarme: esse alarme ajuda você a detectar uma alta contagem de erros no lado do servidor para o serviço do ECS. Isso pode indicar que há erros que fazem com que o servidor não consiga atender às solicitações. Para solucionar o problema, verifique os logs da aplicação.

Intenção: esse alarme é usado para detectar uma alta contagem de erros no lado do servidor para o serviço do ECS.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: calcule o valor de cerca de 5% de seu tráfego médio e use esse valor como ponto de partida para o limite. Você pode encontrar o tráfego médio usando a métrica RequestCount. Você também pode analisar dados históricos para determinar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente. Os erros 5XX que ocorrem com frequência precisam receber um alarme. No entanto, definir um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

TargetResponseTime

Dimensões: ClusterName, ServiceName

Descrição do alarme: esse alarme ajuda você a detectar um tempo de resposta alvo alto para solicitações de serviço do ECS. Isso pode indicar que há problemas que fazem com que o serviço não consiga atender às solicitações a tempo. Para solucionar problemas, verifique a métrica CPUUtilization para verificar se o serviço está ficando sem CPU ou verifique a utilização da CPU de outros serviços downstream dos quais seu serviço depende.

Intenção: esse alarme é usado para detectar um tempo de resposta alvo alto para solicitações de serviço do ECS.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme depende muito do seu caso de uso. Analise a criticidade e os requisitos do tempo alvo de resposta do serviço e analise o comportamento histórico dessa métrica para determinar níveis de limite adequados.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon ECS com o Container Insights

EphemeralStorageUtilized

Dimensões: ClusterName, ServiceName

Descrição do alarme: este alarme ajuda a detectar a alta utilização do armazenamento temporário no cluster do Fargate. Se o uso do armazenamento temporário for consistentemente alto, você poderá verificá-lo e aumentá-lo.

Intenção: este alarme será usado para detectar a alta utilização do armazenamento temporário para o cluster do Fargate. A alta utilização de um armazenamento temporário de forma consistente pode indicar que o disco está cheio e pode resultar em falhas do contêiner.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite como cerca de 90% do tamanho do armazenamento temporário. É possível ajustar esse valor com base na utilização aceitável do armazenamento temporário do cluster do Fargate. Para alguns sistemas, a alta utilização de um armazenamento temporário de forma consistente pode ser normal, enquanto para outros, pode resultar em falhas do contêiner.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

RunningTaskCount

Dimensões: ClusterName, ServiceName

Descrição do alarme: este alarme ajuda a detectar uma baixa contagem de tarefas em execução do serviço ECS. Caso a contagem de tarefas em execução seja muito baixa, isso pode indicar que a aplicação não consegue lidar com a carga de serviço e pode resultar em problemas de performance. Caso não haja tarefas em execução, o serviço Amazon ECS pode estar indisponível ou pode haver problemas de implantação.

Intenção: este alarme é usado para detectar se o número de tarefas em execução está muito baixo. Uma baixa contagem de tarefas em execução de forma consistente pode indicar problemas de implantação ou de performance do serviço ECS.

Estatística: média

Limite recomendado: 0,0

Justificativa do limite: é possível ajustar o limite com base na contagem mínima de tarefas em execução do serviço ECS. Se a contagem de tarefas em execução for 0, o serviço do Amazon ECS estará indisponível.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: LESS_THAN_OR_EQUAL_TO_THRESHOLD

instance_filesystem_utilization

Dimensões: InstanceId, ContainerInstanceId e ClusterName

Descrição do alarme: este alarme ajuda a detectar uma alta utilização do sistema de arquivos do cluster do ECS. Se a utilização do sistema de arquivos for consistentemente alta, verifique o uso do disco.

Intenção: este alarme é usado para detectar uma alta utilização do sistema de arquivos para o cluster do Amazon ECS. Uma alta utilização do sistema de arquivos de forma consistente pode indicar um gargalo de recursos ou problemas de performance da aplicação e pode impedir a execução de novas tarefas.

Estatística: média

Limite recomendado: 90,0

Justificativa do limite: é possível definir o limite de utilização do sistema de arquivos para cerca de 90 a 95%. Você pode ajustar esse valor com base no nível aceitável de capacidade para o sistema de arquivos do cluster do Amazon ECS. Para alguns sistemas, uma alta utilização do sistema de arquivos de forma consistente pode ser normal e não indicar problemas, enquanto que para outros, pode ser um motivo de preocupação e pode resultar em problemas de performance e impedir a execução de novas tarefas.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon EFS

PercentIOLimit

Dimensões: FileSystemID

Descrição do alarme: esse alarme ajuda a garantir que a workload permaneça dentro do limite de E/S disponível para o sistema de arquivos. Se a métrica atingir o limite de E/S de forma consistente, considere transferir a aplicação para um sistema de arquivos que use a performance máxima de E/S como modo. Para solucionar o problema, verifique os clientes que estão conectados ao sistema de arquivos e as aplicações dos clientes que controlam a utilização do sistema de arquivos.

Intenção: esse alarme é usado para detectar o quanto o sistema de arquivos está próximo de atingir o limite de E/S do modo de performance de uso geral. Uma porcentagem consistentemente alta de E/S pode ser um indicador de que o sistema de arquivos não pode ser escalonado com relação a solicitações de E/S suficientes, e o sistema de arquivos pode ser um gargalo de recursos para as aplicações que usam o sistema de arquivos.

Estatística: média

Limite recomendado: 100,0

Justificativa do limite: quando o sistema de arquivos atinge seu limite de E/S, ele pode responder mais lentamente às solicitações de leitura e gravação. Portanto, é recomendável que a métrica seja monitorada para evitar o impacto nas aplicações que usam o sistema de arquivos. O limite pode ser definido em torno de 100%. No entanto, esse valor pode ser ajustado para um valor menor com base nas características do sistema de arquivos.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

BurstCreditBalance

Dimensões: FileSystemID

Descrição do alarme: esse alarme ajuda a garantir que haja um saldo de crédito de estouro disponível para o uso do sistema de arquivos. Quando não houver crédito de burst disponível, o acesso das aplicações ao sistema de arquivos será limitado devido ao baixo throughput. Se a métrica cair para 0 de forma consistente, considere alterar o modo de throughput para o modo de throughput Elástico ou Provisionado.

Intenção: esse alarme é usado para detectar o baixo saldo de crédito de burst do sistema de arquivos. Um saldo de crédito de burst baixo e consistente pode ser um indicador da diminuição do throughput e do aumento da latência de E/S.

Estatística: média

Limite recomendado: 0,0

Justificativa do limite: quando o sistema de arquivos fica sem créditos de burst e mesmo que o throughput de linha de base seja menor, o EFS continua a fornecer um throughput medido de 1 MiBps para todos os sistemas de arquivos. No entanto, recomenda-se que a métrica seja monitorada quanto ao baixo saldo de crédito de burst para evitar que o sistema de arquivos atue como gargalo de recursos para as aplicações. O limite pode ser definido em torno de 0 bytes.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: LESS_THAN_OR_EQUAL_TO_THRESHOLD

Amazon EKS com o Container Insights

node_cpu_utilization

Dimensões: ClusterName

Descrição do alarme: esse alarme ajuda a detectar a alta utilização da CPU nos nós de processamento do cluster do EKS. Se a utilização for consistentemente alta, isso pode indicar a necessidade de substituir os nós de processamento por instâncias que tenham mais CPU ou a necessidade de escalar o sistema horizontalmente.

Intenção: esse alarme ajuda a monitorar a utilização da CPU dos nós de processamento no cluster do EKS para que a performance do sistema não diminua.

Estatística: máxima

Limite recomendado: 80,0

Justificativa do limite: recomenda-se definir o limite como menor ou igual a 80% para permitir tempo suficiente para depurar o problema antes que o sistema comece a sofrer impacto.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

node_filesystem_utilization

Dimensões: ClusterName

Descrição do alarme: esse alarme ajuda a detectar a alta utilização do sistema de arquivos nos nós de processamento do cluster do EKS. Se a utilização for consistentemente alta, talvez seja necessário atualizar os nós de processamento para que tenham um volume de disco maior, ou talvez seja necessário escalar horizontalmente.

Descrição do alarme: esse alarme ajuda a monitorar a utilização do sistema de arquivos dos nós de processamento no cluster do EKS. Se a utilização atingir 100%, isso pode levar à falha da aplicação, a gargalos de E/S do disco, à remoção de pods ou ao fato de o nó deixar de responder completamente.

Estatística: máxima

Limite recomendado: depende da sua situação

Justificativa do limite: se houver pressão suficiente no disco (o que significa que o disco está ficando cheio), os nós serão marcados como não íntegros e os pods serão removidos do nó. Os pods em um nó com pressão de disco são removidos quando o sistema de arquivos disponível é menor do que os limites de remoção definidos no kubelet. Defina o limite do alarme para que você tenha tempo suficiente para reagir antes que o nó seja removido do cluster.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

node_memory_utilization

Dimensões: ClusterName

Descrição do alarme: esse alarme ajuda a detectar a alta utilização de memória nos nós de processamento do cluster do EKS. Se a utilização for consistentemente alta, isso pode indicar a necessidade de escalar o número de réplicas de pod ou otimizar a sua aplicação.

Intenção: esse alarme ajuda a monitorar a utilização da memória dos nós de processamento no cluster do EKS para que a performance do sistema não diminua.

Estatística: máxima

Limite recomendado: 80,0

Justificativa do limite: recomenda-se definir o limite como menor ou igual a 80% para permitir que se tenha tempo suficiente para depurar o problema antes que o sistema comece a sofrer impacto.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

pod_cpu_utilization_over_pod_limit

Dimensões: ClusterName, Namespace, serviço

Descrição do alarme: esse alarme ajuda a detectar a alta utilização da CPU em pods do cluster do EKS. Se a utilização for consistentemente alta, isso poderá indicar a necessidade de aumentar o limite da CPU para o pod afetado.

Intenção: esse alarme ajuda a monitorar a utilização da CPU dos pods pertencentes a um Serviço do Kubernetes no cluster do EKS para que você possa identificar rapidamente se o pod de um serviço está consumindo mais CPU do que o esperado.

Estatística: máxima

Limite recomendado: 80,0

Justificativa do limite: recomenda-se definir o limite como menor ou igual a 80% para permitir que se tenha tempo suficiente para depurar o problema antes que o sistema comece a sofrer impacto.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

pod_memory_utilization_over_pod_limit

Dimensões: ClusterName, Namespace, serviço

Descrição do alarme: esse alarme ajuda a detectar a alta utilização de memória em pods do cluster do EKS. Se a utilização for consistentemente alta, isso poderá indicar a necessidade de aumentar o limite de memória para o pod afetado.

Intenção: esse alarme ajuda a monitorar a utilização da memória dos pods no cluster do EKS para que a performance do sistema não diminua.

Estatística: máxima

Limite recomendado: 80,0

Justificativa do limite: recomenda-se definir o limite como menor ou igual a 80% para permitir que se tenha tempo suficiente para depurar o problema antes que o sistema comece a sofrer impacto.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon Kinesis Data Streams

GetRecords.IteratorAgeMilliseconds

Dimensões: StreamName

Descrição do alarme: esse alarme pode detectar se a idade máxima do iterador é muito alta. Para aplicações de processamento de dados em tempo real, configure a retenção de dados de acordo com a tolerância do atraso. Isso geralmente ocorre em minutos. Para aplicações que processam dados históricos, use essa métrica para monitorar a velocidade de recuperação. Uma solução rápida para impedir a perda de dados é aumentar o período de retenção enquanto você soluciona o problema. Também é possível aumentar o número de trabalhadores que processam registros em sua aplicação do consumidor. As causas mais comuns para o aumento gradual da idade do iterador são recursos físicos insuficientes ou lógica de processamento de registros que não foi escalonada com um aumento no throughput do fluxo. Consulte o link para obter mais detalhes.

Intenção: esse alarme é usado para detectar se os dados no seu fluxo vão expirar por terem sido preservados por muito tempo ou porque o processamento de registros está muito lento. Ele ajuda a evitar a perda de dados após atingir 100% do tempo de retenção do fluxo.

Estatística: máxima

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme depende muito do período de retenção do fluxo e da tolerância de atraso no processamento dos registros. Revise seus requisitos e analise as tendências históricas e, em seguida, defina o limite para o número de milissegundos que representa um atraso crítico no processamento. Se a idade de um iterador ultrapassar 50% do período de retenção (por padrão, 24 horas, configurável até 365 dias), haverá um risco de perda de dados devido à expiração do registro. Você pode monitorar a métrica para garantir que nenhum dos seus fragmentos se aproxime desse limite.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

GetRecords.Success

Dimensões: StreamName

Descrição do alarme: essa métrica é incrementada sempre que os consumidores leem com êxito os dados do fluxo. O GetRecords não retorna nenhum dado quando lança uma exceção. A exceção mais comum é ProvisionedThroughputExceededException, pois a taxa de solicitação do fluxo é muito alta ou porque o throughput disponível já foi atendido para o segundo em questão. Reduzir a frequência ou o tamanho de suas solicitações. Para obter mais informações, consulte Limites de fluxos no Guia do desenvolvedor do Amazon Kinesis Data Streams e Repetições de erro e recuo exponencial na AWS.

Intenção: esse alarme pode detectar se a recuperação de registros do fluxo pelos consumidores está falhando. Ao definir um alarme para essa métrica, você pode detectar proativamente qualquer problema com o consumo de dados, como o aumento das taxas de erro ou a diminuição das recuperações bem-sucedidas. Isso permite que você tome medidas oportunas para resolver possíveis problemas e mantenha um pipeline de processamento de dados regular.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: dependendo da importância da recuperação de registros do fluxo, defina o limite com base na tolerância da sua aplicação para registros com falha. O limite deve ser a porcentagem correspondente de operações bem-sucedidas. Você pode usar dados históricos da métrica GetRecords como referência para a taxa de falha aceitável. Também é preciso considerar as novas tentativas ao definir o limite, pois os registros com falha podem ser tentados novamente. Isso ajuda a evitar que picos transitórios acionem alertas desnecessários.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: LESS_THAN_THRESHOLD

PutRecord.Success

Dimensões: StreamName

Descrição do alarme: esse alarme detecta quando o número de operações de PutRecord com falha ultrapassa o limite. Investigue os logs do produtor de dados para encontrar as causas principais das falhas. O motivo mais comum é o throughput provisionado insuficiente no fragmento que causou o ProvisionedThroughputExceededException. Isso acontece porque a taxa de solicitação do fluxo é muito alta ou o throughput tentado para ser ingerido no fragmento é muito alto. Reduzir a frequência ou o tamanho de suas solicitações. Para obter mais informações, consulte Limites de fluxos e Repetições de erro e recuo exponencial na AWS.

Intenção: esse alarme pode detectar se a ingestão de registros no fluxo está falhando. Ele ajuda a identificar problemas na gravação de dados no fluxo. Ao definir um alarme para essa métrica, é possível detectar proativamente quaisquer problemas de produtores na publicação de dados no fluxo, como aumento das taxas de erro ou diminuição dos registros publicados com êxito. Isso permite que você tome medidas oportunas para resolver possíveis problemas e mantenha um processo de ingestão de dados confiável.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: dependendo da importância da ingestão de dados e do processamento para o seu serviço, defina o limite com base na tolerância da sua aplicação para registros com falha. O limite deve ser a porcentagem correspondente de operações bem-sucedidas. É possível usar dados históricos da métrica PutRecord como referência para a taxa de falha aceitável. Também é preciso considerar as novas tentativas ao definir o limite, pois os registros com falha podem ser tentados novamente.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: LESS_THAN_THRESHOLD

PutRecords.FailedRecords

Dimensões: StreamName

Descrição do alarme: esse alarme detecta quando o número de operações PutRecords com falha excede o limite. O fluxo de dados do Kinesis tenta processar todos os registros em cada solicitação PutRecords, mas uma única falha de registro não interrompe o processamento dos registros subsequentes. O principal motivo dessas falhas é exceder o throughput de um fluxo ou de um fragmento individual. As causas comuns são picos de tráfego e latências de rede que fazem com que os registros cheguem ao fluxo de forma desigual. Você deve detectar registros processados sem sucesso e tentar novamente em uma chamada subsequente. Consulte Tratamento de falhas ao usar PutRecords para obter mais detalhes.

Intenção: esse alarme pode detectar falhas consistentes ao usar a operação em lote para colocar registros no seu fluxo. Ao definir um alarme para essa métrica, é possível detectar proativamente um aumento no número de registros com falha, o que permite tomar medidas oportunas para resolver os problemas subjacentes e garantir um processo de ingestão de dados regular e confiável.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite para o número de registros com falha que reflete a tolerância da aplicação para registros com falha. Você pode usar dados históricos como referência para o valor de falha aceitável. Também é preciso considerar as novas tentativas ao definir o limite, pois os registros com falha podem ser tentados novamente em chamadas PutRecords subsequentes.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

ReadProvisionedThroughputExceeded

Dimensões: StreamName

Descrição do alarme: o alarme rastreia o número de registros que resultam no controle de utilização da capacidade de throughput de leitura. Se você perceber que o controle de utilização está sendo constante, considere adicionar mais fragmentos ao seu fluxo para aumentar o throughput de leitura provisionado. Se houver mais de uma aplicação de consumo em execução no fluxo e elas compartilharem o limite do GetRecords, recomendamos que você registre novas aplicações de consumo via distribuição aprimorada. Se a adição de mais fragmentos não reduzir o número de controles de utilização, é possível que haja um fragmento "quente" que esteja sendo lido mais do que os outros fragmentos. Ative a distribuição aprimorada, localize o fragmento "quente" e divida-o.

Intenção: esse alarme pode detectar se os consumidores passam por um controle de utilização quando excedem o throughput de leitura provisionado (determinado pelo número de fragmentos que você tem). Nesse caso, não será possível fazer a leitura do fluxo, e o fluxo pode começar a fazer o backup.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: normalmente, as solicitações com controle de utilização podem ser repetidas e, portanto, definir o limite como zero torna o alarme muito sensível. No entanto, o controle de utilização consistente pode afetar a leitura do fluxo e deve acionar o alarme. Defina o limite como uma porcentagem de acordo com as solicitações com controle de utilização para as configurações da aplicação e de repetição.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

SubscribeToShardEvent.MillisBehindLatest

Dimensões: StreamName, ConsumerName

Descrição do alarme: esse alarme detecta quando o atraso do processamento de registros na aplicação ultrapassa o limite. Problemas transitórios, como falhas na operação da API em uma aplicação downstream, podem causar um aumento repentino na métrica. É necessário investigar se isso ocorre de forma consistente. Uma causa comum é que o consumidor não está processando registros com rapidez suficiente devido a recursos físicos insuficientes ou à lógica de processamento de registros que não foi escalonada com um aumento no throughput do fluxo. O bloqueio de chamadas no caminho crítico geralmente é a causa de lentidão no processamento de registros. Você pode aumentar o paralelismo aumentando o número de fragmentos. Você também deve confirmar se os nós de processamento subjacentes têm recursos físicos suficientes durante o pico de demanda.

Intenção: esse alarme pode detectar atraso na assinatura do evento de fragmento do fluxo. Isso indica um atraso no processamento e pode ajudar a identificar possíveis problemas com a performance da aplicação do consumidor ou com a integridade geral do fluxo. Quando o atraso no processamento torna-se significativo, você deve investigar e resolver quaisquer gargalos ou ineficiências das aplicações do consumidor para garantir o processamento de dados em tempo real e minimizar o acúmulo de dados.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme depende muito do atraso que sua aplicação pode tolerar. Analise os requisitos da sua aplicação e analise as tendências históricas e, em seguida, selecione um limite adequadamente. Quando a chamada SubscribeToShard for bem-sucedida, o consumidor começará a receber eventos SubscribeToShardEvent pela conexão persistente por até cinco minutos, após os quais será necessário chamar o SubscribeToShard novamente para renovar a assinatura se quiser continuar a receber registros.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

WriteProvisionedThroughputExceeded

Dimensões: StreamName

Descrição do alarme: esse alarme detecta quando o número de registros que resultam no controle de utilização da capacidade de throughput de gravação atingiu o limite. Quando seus produtores excedem o throughput de gravação provisionado (determinado pelo número de fragmentos que você tem), eles passam por um controle de utilização e você não poderá colocar registros no fluxo. Para resolver o controle de utilização consistente, você deve considerar a adição de fragmentos ao seu fluxo. Isso aumenta seu throughput de gravação provisionado e evita o controle de utilização no futuro. Você também deve considerar a escolha da chave de partição ao ingerir registros. A chave de partição aleatória é preferível porque distribui os registros uniformemente entre os fragmentos do fluxo, sempre que possível.

Intenção: esse alarme pode detectar se os seus produtores estão sendo rejeitados para gravar registros devido ao controle de utilização do fluxo ou do fragmento. Se o seu fluxo estiver no modo Provisionado, a configuração desse alarme ajudará você a tomar medidas proativas quando o fluxo de dados atingir seus limites, permitindo otimizar a capacidade provisionada ou tomar medidas de escalonamento adequadas para evitar a perda de dados e manter o processamento de dados regular.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: normalmente, as solicitações com controle de utilização podem ser repetidas, portanto, definir o limite como zero torna o alarme muito sensível. No entanto, o controle de utilização consistente pode afetar a gravação no fluxo, e você deve definir o limite de alarme para detectar isso. Defina o limite como uma porcentagem de acordo com as solicitações com controle de utilização para as configurações da aplicação e de repetição.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Lambda

ClaimedAccountConcurrency

Dimensões: nenhuma

Descrição do alarme: esse alarme ajuda a monitorar se a simultaneidade de suas funções do Lambda está se aproximando do limite de simultaneidade por região da sua conta. Uma função começa a passar por um controle de utilização ao atingir o limite de simultaneidade. Você pode realizar as ações a seguir para evitar o controle de utilização.

1. Solicitar um aumento de simultaneidade nesta região.

2. Identificar e reduzir qualquer simultaneidade reservada ou simultaneidade provisionada não utilizada.

3. Identificar problemas de desempenho nas funções para aumentar a velocidade de processamento e, portanto, melhorar o throughput.

4. Aumentar o tamanho de lote das funções para que cada invocação de função processe mais mensagens.

Intenção: esse alarme pode detectar proativamente se a simultaneidade de suas funções do Lamba está se aproximando da cota de simultaneidade no nível de região da sua conta para que você possa agir. As funções passam por um controle de utilização se ClaimedAccountConcurrency atingir a cota de simultaneidade no nível de região da conta. Se você estiver usando Simultaneidade reservada (RC) ou Simultaneidade provisionada (PC), esse alarme proporcionará mais visibilidade sobre a utilização da simultaneidade em comparação a um alarme em ConcurrentExecutions.

Estatística: máxima

Limite recomendado: depende da sua situação

Justificativa do limite: você deve calcular o valor de aproximadamente 90% da cota de simultaneidade definida para a conta na região e usar o resultado como valor limite. Por padrão, sua conta tem uma cota de simultaneidade de mil em todas as funções de uma região. No entanto, verifique a cota da sua conta no painel do Service Quotas.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_THRESHOLD

Erros

Dimensões: FunctionName

Descrição do alarme: esse alarme detecta altas contagens de erros. Os erros incluem as exceções lançadas pelo código, bem como as exceções lançadas pelo runtime do Lambda. Você pode verificar os logs relacionados à função para diagnosticar o problema.

Intenção: o alarme ajuda a detectar altas contagens de erros em invocações de funções.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite como um número maior que zero. O valor exato pode depender da tolerância a erros em sua aplicação. Entenda a criticidade das invocações que a função está tratando. Para algumas aplicações, qualquer erro pode ser inaceitável, enquanto outras aplicações podem permitir uma certa margem de erro.

Período: 60

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: GREATER_THAN_THRESHOLD

Controles de utilização

Dimensões: FunctionName

Descrição do alarme: esse alarme detecta um alto número de solicitações de invocação com controle de utilização. O controle de utilização ocorre quando não há simultaneidade disponível para aumentar a escala verticalmente. Há várias abordagens para resolver esse problema. 1) Solicitar um aumento de simultaneidade do AWS Suporte nesta região. 2) Identificar problemas de performance na função para aumentar a velocidade de processamento e, portanto, melhorar o throughput. 3) Aumentar o tamanho do lote da função para que mais mensagens sejam processadas por cada invocação de função.

Intenção: o alarme ajuda a detectar um alto número de solicitações de invocação com controle de utilização para uma função do Lambda. É importante saber se as solicitações estão sendo constantemente rejeitadas devido ao controle de utilização e se você precisa melhorar a performance da função do Lambda ou aumentar a capacidade de simultaneidade para evitar o controle de utilização constante.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite como um número maior que zero. O valor exato do limite pode depender da tolerância da aplicação. Defina o limite de acordo com seu uso e os requisitos de escalonamento da função.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

Duration (Duração)

Dimensões: FunctionName

Descrição do alarme: esse alarme detecta tempos de longa duração para o processamento de um evento por uma função do Lambda. As longas durações podem ser causadas por alterações no código da função, fazendo com que a função demore mais para ser executada, ou que as dependências da função demorem mais.

Intenção: esse alarme pode detectar uma longa duração de funcionamento de uma função do Lambda. A alta duração do runtime indica que uma função está levando mais tempo para ser invocada e também pode afetar a capacidade de simultaneidade da invocação se o Lambda estiver lidando com um número maior de eventos. É fundamental saber se a função do Lambda está constantemente levando mais tempo de execução do que o esperado.

Estatística: p90

Limite recomendado: depende da sua situação

Justificativa do limite: o limite para a duração depende de sua aplicação, das workloads e de seus requisitos de performance. Para requisitos de alta performance, defina o limite para um tempo mais curto para verificar se a função está atendendo às expectativas. Você também pode analisar dados históricos de métricas de duração para ver se o tempo gasto corresponde à expectativa de performance da função e, em seguida, definir o limite para um tempo maior do que a média histórica. Certifique-se de definir o limite inferior ao tempo limite da função configurada.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

ConcurrentExecutions

Dimensões: FunctionName

Descrição do alarme: esse alarme ajuda a monitorar se a simultaneidade da função está se aproximando do limite de simultaneidade no nível de região da sua conta. Uma função começa a passar por um controle de utilização ao atingir o limite de simultaneidade. Você pode realizar as ações a seguir para evitar o controle de utilização.

1. Solicitar um aumento de simultaneidade nesta região.

2. Identificar problemas de desempenho nas funções para aumentar a velocidade de processamento e, portanto, melhorar o throughput.

3. Aumentar o tamanho de lote das funções para que cada invocação de função processe mais mensagens.

Para obter melhor visibilidade da utilização da simultaneidade reservada e da simultaneidade provisionada, defina um alarme para a nova métrica ClaimedAccountConcurrency.

Intenção: esse alarme pode detectar proativamente se a simultaneidade da função está se aproximando da cota de simultaneidade no nível de região da sua conta para que você possa agir. Uma função passa por um controle de utilização ao atingir a cota de simultaneidade no nível de região da conta.

Estatística: máxima

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite para cerca de 90% da cota de simultaneidade definida para a conta na região. Por padrão, sua conta tem uma cota de simultaneidade de mil em todas as funções de uma região. No entanto, você pode verificar a cota da sua conta, pois ela pode ser aumentada entrando em contato com o suporte da AWS.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_THRESHOLD

Lambda Insights

Recomendamos definir alarmes de práticas recomendadas para as seguintes métricas do Lambda Insights.

memory_utilization

Dimensões: function_name

Descrição do alarme: esse alarme é usado para detectar se a utilização da memória de uma função do Lambda está se aproximando do limite configurado. Para solucionar problemas, você pode tentar 1) Otimizar seu código. 2) Dimensionar corretamente sua alocação de memória, estimando com precisão os requisitos de memória. Você pode consultar o Lambda Power Tuning para realizar essa operação. 3) Use o pooling de conexões. Consulte Using Amazon RDS Proxy with Lambda para o pooling de conexões para o banco de dados do RDS. 4) Você também pode considerar a possibilidade de projetar suas funções para evitar o armazenamento de grandes quantidades de dados na memória entre as invocações.

Descrição do alarme: esse alarme é usado para detectar se a utilização da memória para a função do Lambda está se aproximando do limite configurado.

Estatística: média

Sugestão de limite: 90,0

Justificativa do limite: defina o limite como 90% para receber um alerta quando a utilização da memória exceder 90% da memória alocada. Você pode ajustar isso para um valor mais baixo caso se preocupe com a workload para a utilização da memória. Você também pode verificar os dados históricos dessa métrica e definir o limite adequadamente.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon VPC (AWS/NATGateway)

ErrorPortAllocation

Dimensões: NatGatewayId

Descrição do alarme: esse alarme ajuda a detectar quando o gateway NAT não consegue alocar portas para novas conexões. Para resolver esse problema, consulte Resolver erros de alocação de portas em um gateway NAT.

Intenção: esse alarme é usado para detectar se o gateway NAT não pôde alocar uma porta de origem.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: se o valor de ErrorPortAllocation for maior que zero, isso significa que muitas conexões simultâneas para um único destino popular estão abertas por meio do gateway NAT.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

PacketsDropCount

Dimensões: NatGatewayId

Descrição do alarme: esse alarme ajuda a detectar quando os pacotes são descartados pelo gateway NAT. Isso pode ocorrer devido a um problema com o gateway NAT, portanto, verifique o painel de integridade do serviço da AWS para saber o status do gateway NAT da AWS em sua região. Isso pode ajudar você a correlacionar o problema de rede relacionado ao tráfego usando o gateway NAT.

Intenção: esse alarme é usado para detectar se os pacotes estão sendo descartados pelo gateway NAT.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: você deve calcular o valor de 0,01% do tráfego total no gateway NAT e usar esse resultado como valor limite. Use dados históricos do tráfego no gateway NAT para determinar o limite.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Link privado da AWS (AWS/PrivateLinkEndpoints)

PacketsDropped

Dimensões: ID da VPC, ID do endpoint da VPC, tipo de endpoint, ID da sub-rede, nome do serviço

Descrição do alarme: esse alarme ajuda a detectar se o endpoint ou o serviço de endpoint não está íntegro por meio do monitoramento do número de pacotes descartados pelo endpoint. Observe que os pacotes maiores que 8500 bytes que chegam ao endpoint da VPC são descartados. Para solução de problemas, consulte Solucionar problemas de conectividade entre um endpoint da VPC de interface e um serviço de endpoint.

Intenção: esse alarme é usado para detectar se o endpoint ou o serviço de endpoint não está íntegro.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite de acordo com o caso de uso. Se você quiser estar ciente do status de não integridade do endpoint ou do serviço de endpoint, defina o limite baixo para ter a chance de corrigir o problema antes de uma grande perda de dados. Você pode usar dados históricos para entender a tolerância de pacotes descartados e definir o limite adequadamente.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Link privado da AWS (AWS/PrivateLinkServices)

RstPacketsSent

Dimensões: ID do serviço, balanceador de carga Arn, Az

Descrição do alarme: esse alarme ajuda você a detectar alvos não íntegros de um serviço de endpoint com base no número de pacotes de redefinição enviados aos endpoints. Ao depurar erros de conexão com um consumidor do seu serviço, você pode validar se o serviço está redefinindo as conexões com a métrica RstPacketsSent ou se algo mais está falhando no caminho da rede.

Intenção: esse alarme é usado para detectar alvos não íntegros de um serviço de endpoint.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: o limite depende do caso de uso. Se o seu caso de uso puder tolerar que os alvos não sejam íntegros, você poderá definir o limite como alto. Se o caso de uso não tolerar alvos não íntegros, você poderá definir um limite como muito baixo.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon RDS

CPUUtilization

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar a alta utilização da CPU de forma consistente. A utilização da CPU mede o tempo não ocioso. Considere usar o Monitoramento Aprimorado ou o Insights de Performance para analisar qual tempo de espera está consumindo a maior parte do tempo da CPU (guest, irq, wait, nice e assim por diante) para o MariaDB, o MySQL, o Oracle e o PostgreSQL. Em seguida, avalie quais consultas consomem a maior quantidade de CPU. Se não for possível ajustar a workload, considere migrar para uma classe de instância de banco de dados maior.

Intenção: este alarme é usado para detectar uma alta utilização da CPU de forma consistente a fim de evitar tempos de resposta muito altos e o atingimento do tempo limite. Se desejar verificar a microexpansão da utilização da CPU, é possível definir um tempo de avaliação inferior para o alarme.

Estatística: média

Limite recomendado: 90,0

Justificativa do limite: os aumentos randômicos no consumo da CPU podem não prejudicar a performance do banco de dados, mas manter uma elevada utilização da CPU pode prejudicar futuras solicitações para o banco de dados. Dependendo da workload geral do banco de dados, a alta utilização da CPU na instância do RDS ou do Aurora pode degradar a performance geral.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

DatabaseConnections

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme detecta um grande número de conexões. Analise as conexões existentes e encerre aquelas que estiverem no estado “em repouso” ou que foram encerradas incorretamente. Considere usar um grupo de conexões para limitar o número de novas conexões. Como alternativa, aumente o tamanho da instância de banco de dados para usar uma classe com mais memória e, portanto, com um valor padrão mais alto para “max_connections”, ou aumente o valor de “max_connections” no RDS e no MySQL e PostgreSQL do Aurora para a classe atual, caso ela seja compatível com sua workload.

Intenção: este alarme é usado para ajudar a evitar conexões rejeitadas quando o número máximo de conexões para o banco de dados é atingido. Esse alarme não é recomendado se você altera a classe da instância de banco de dados com frequência, pois realiza alterações na memória e no número máximo de conexões padrão.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o número de conexões permitidas depende do tamanho da classe da instância de banco de dados e dos parâmetros específicos para o mecanismo de banco de dados relacionados aos processos ou às conexões. Você deve calcular um valor entre 90 e 95% do número máximo de conexões para seu banco de dados e usar esse resultado como o valor limite.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

EBSByteBalance%

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar uma baixa porcentagem de créditos de throughput restantes. Para solução de problemas, verifique problemas de latência no RDS.

Intenção: este alarme é usado para detectar uma baixa porcentagem de créditos de throughput restantes no bucket de intermitência. A baixa porcentagem de saldo para bytes pode causar problemas de gargalo de throughput. Esse alarme não é recomendado para instâncias do Aurora PostgreSQL.

Estatística: média

Limite recomendado: 10,0

Justificativa do limite: um saldo de créditos de throughput inferior a 10% é considerado ruim e você deve definir o limite adequadamente. Além disso, é possível definir um limite mais baixo se a aplicação puder tolerar um throughput mais baixo para a workload.

Período: 60

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: LESS_THAN_THRESHOLD

EBSIOBalance%

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar uma baixa porcentagem de créditos de IOPS restantes. Para obter uma solução de problemas, consulte problemas de latência no RDS.

Intenção: este alarme é usado para detectar uma baixa porcentagem de créditos de E/S restantes no bucket de intermitência. A baixa porcentagem de saldo para IOPS pode causar problemas de gargalo de IOPS. Esse alarme não é recomendado para instâncias do Aurora.

Estatística: média

Limite recomendado: 10,0

Justificativa do limite: um saldo de créditos de IOPS inferior a 10% é considerado ruim e você pode definir o limite adequadamente. Além disso, é possível definir um limite mais baixo se a aplicação puder tolerar um número de IOPS mais baixo para a workload.

Período: 60

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: LESS_THAN_THRESHOLD

FreeableMemory

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar pouca memória que pode ser liberada, o que pode significar que há um aumento nas conexões do banco de dados ou que a instância pode estar sob alta pressão de memória. Verifique a pressão de memória ao monitorar as métricas do CloudWatch para SwapUsage, além de realizar o monitoramento para FreeableMemory. Se o consumo de memória da instância for frequentemente muito alto, indica que você deve verificar a workload ou atualizar a classe da instância. Para as instâncias de banco de dados de leitor do Aurora, considere adicionar mais instâncias de banco de dados de leitor ao cluster. Para obter informações sobre como solucionar problemas do Aurora, consulte problemas de memória que pode ser liberada.

Intenção: este alarme é usado para ajudar a evitar a falta de memória, o que pode resultar em conexões rejeitadas.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: dependendo da workload e da classe da instância, valores diferentes para o limite podem ser apropriados. Preferencialmente, a memória disponível não deve ser inferior a 25% da memória total por períodos prolongados. Para o Aurora, é possível definir o limite próximo pa 5%, porque a métrica próxima de zero significa que a instância de banco de dados aumentou a escala verticalmente o máximo possível. Você pode analisar o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: LESS_THAN_THRESHOLD

FreeLocalStorage

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar pouco armazenamento local livre. A edição do Aurora compatível com PostgreSQL usa o armazenamento local para armazenar logs de erros e arquivos temporários. O Aurora MySQL usa armazenamento local para armazenar logs de erros, logs gerais, logs de consultas lentas, logs de auditoria e tabelas temporárias que não são do InnoDB. Esses volumes de armazenamento local são apoiados pelo Amazon EBS e podem ser ampliados ao usar uma classe de instância de banco de dados maior. Para obter a solução de problemas, verifique instâncias do Aurora compatíveis com PostgreSQL e compatíveis com MySQL.

Intenção: este alarme é usado para detectar o quão perto a instância de banco de dados do Aurora está de atingir o limite de armazenamento local, se você não usar o Aurora Sem Servidor v2 ou versões posteriores. O armazenamento local pode atingir a capacidade máxima quando você armazena dados não persistentes, como tabelas temporárias e arquivos de log, no armazenamento local. Esse alarme pode evitar um erro de falta de espaço que ocorre quando a instância de banco de dados fica sem o armazenamento local.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: você deve calcular cerca de 10% a 20% da quantidade de armazenamento disponível com base na velocidade e na tendência de uso do volume e, em seguida, usar esse resultado como o valor limite para tomar medidas proativas antes que o volume atinja o limite.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: LESS_THAN_THRESHOLD

FreeStorageSpace

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme monitora uma pequena quantidade de espaço de armazenamento disponível. Considere aumentar a escala verticalmente para o armazenamento do banco de dados caso você frequentemente se aproxime dos limites de capacidade de armazenamento. Inclua algum buffer para acomodar aumentos não previstos na demanda das aplicações. Como alternativa, considere habilitar o ajuste de escala automático para o armazenamento do RDS. Além disso, considere liberar mais espaço ao excluir dados e logs não utilizados ou desatualizados. Para obter mais informações, verifique o documento do RDS para quando não há mais espaço de armazenamento e o documento sobre problemas de armazenamento do PostgreSQL.

Intenção: este alarme ajuda a evitar problemas de armazenamento cheio. O alarme pode evitar o tempo de inatividade que ocorre quando a instância de banco de dados fica sem armazenamento. Não recomendamos usar esse alarme se você tiver o ajuste de escala automático para o armazenamento habilitado ou caso realize alterações da capacidade de armazenamento da instância de banco de dados com frequência.

Estatística: mínima

Limite recomendado: depende da sua situação

Justificativa do limite: o valor do limite dependerá do espaço de armazenamento atualmente alocado. Normalmente, você deve calcular o valor de 10% do espaço de armazenamento alocado e usar esse resultado como valor limite.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: LESS_THAN_THRESHOLD

MaximumUsedTransactionIDs

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a evitar a conclusão de IDs de transação para o PostgreSQL. Consulte as etapas para a solução de problemas nesta publicação do blog para investigar e resolver o problema. Você também pode consultar esta publicação do blog para se familiarizar ainda mais com os conceitos de autovacuum, os problemas comuns e as práticas recomendadas.

Intenção: este alarme é usado para ajudar a evitar a conclusão de IDs de transação para o PostgreSQL.

Estatística: média

Limite recomendado: 1.0E9

Justificativa do limite: definir este limite para um bilhão deverá fornecer tempo hábil para que você investigue o problema. O valor padrão para autovacuum_freeze_max_age é de 200 milhões. Se o tempo da transação mais antiga for de um bilhão, o autovacuum terá problemas para manter esse limite abaixo da meta de 200 milhões de IDs de transação.

Período: 60

Pontos de dados para o alarme: 1

Períodos de avaliação: 1

Operador de comparação: GREATER_THAN_THRESHOLD

ReadLatency

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar a alta latência de leitura. Se a latência de armazenamento for alta, é porque a workload está excedendo os limites de recursos. É possível analisar a utilização de E/S em relação à configuração da instância e do armazenamento alocado. Consulte a solução de problemas de latência de volumes do Amazon EBS causada ​​por um gargalo de IOPS. Para o Aurora, é possível alternar para uma classe da instância que tenha configuração de armazenamento I/O-Optimized. Consulte Planning I/O in Aurora para obter orientação.

Intenção: este alarme é usado para detectar alta latência de leitura. Geralmente, os discos de banco de dados têm baixa latência de leitura e de gravação, mas podem apresentar problemas que podem causar operações com alta latência.

Estatística: p90

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme depende muito do seu caso de uso. Latências de leitura superiores a 20 milissegundos são provavelmente motivo para uma investigação. Também é possível definir um limite mais alto caso a aplicação possa ter uma latência mais alta para as operações de leitura. Avalie a criticidade e os requisitos para a latência de leitura e analise o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

ReplicaLag

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda você a compreender quantos segundos uma réplica tem de diferença quando comparada com a instância primária. Uma réplica de leitura do PostgreSQL relata um atraso de replicação de até cinco minutos caso não haja transações de usuário ocorrendo na instância de banco de dados de origem. Quando a métrica ReplicaLag atinge zero, a réplica alcançou a instância de banco de dados primária. Se a métrica ReplicaLag retornar -1, significa que a replicação não está ativa no momento. Para obter orientações relacionadas ao RDS para PostgreSQL, consulte as práticas recomendadas de replicação. Para solucionar problemas relacionados à métrica ReplicaLag e erros relacionados, consulte a solução de problemas para ReplicaLag.

Intenção: este alarme pode detectar o atraso da réplica, que reflete a perda de dados que pode ocorrer em caso de falha da instância primária. Se a réplica tiver uma diferença muito grande quando comparada com a instância primária e ela falhar, faltarão dados na réplica que estavam na instância primária.

Estatística: máxima

Limite recomendado: 60,0

Justificativa do limite: normalmente, o atraso aceitável depende da aplicação. Recomendamos não mais do que 60 segundos.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: GREATER_THAN_THRESHOLD

WriteLatency

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar a alta latência de gravação. Se a latência de armazenamento for alta, é porque a workload está excedendo os limites de recursos. É possível analisar a utilização de E/S em relação à configuração da instância e do armazenamento alocado. Consulte a solução de problemas de latência de volumes do Amazon EBS causada ​​por um gargalo de IOPS. Para o Aurora, é possível alternar para uma classe da instância que tenha configuração de armazenamento I/O-Optimized. Consulte Planning I/O in Aurora para obter orientação.

Intenção: este alarme é usado para detectar alta latência de gravação. Embora, geralmente, os discos de banco de dados tenham baixa latência de leitura e de gravação, eles podem enfrentar problemas que causam operações com alta latência. Monitorar isso garantirá que a latência do disco seja tão baixa quanto o esperado.

Estatística: p90

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme depende muito do seu caso de uso. Latências de gravação superiores a 20 milissegundos são provavelmente motivo para uma investigação. Também é possível definir um limite mais alto caso a aplicação puossa ter uma latência mais alta para as operações de gravação. Avalie a criticidade e os requisitos para a latência de gravação e analise o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

DBLoad

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar a alta carga do banco de dados. Se o número de processos exceder o número de vCPUs, os processos começarão a ser colocados em fila. Quando o enfileiramento aumenta, a performance é impactada. Se a carga do banco de dados estiver frequentemente acima da vCPU máxima e o estado de espera primário for a CPU, ela estará sobrecarregada. Nesse caso, é possível monitorar CPUUtilization, DBLoadCPU e as tarefas enfileiradas no Insights de Performance ou no Monitoramento Aprimorado. Talvez você deseje realizar o controle de utilização das conexões para a instância, ajustar quaisquer consultas SQL com uma alta carga de CPU ou considerar uma classe da instância maior. As instâncias altas e consistentes de qualquer estado de espera indicam que pode haver problemas de gargalos ou de contenção de recursos que você deve resolver.

Intenção: este alarme é usado para detectar uma alta carga do banco de dados. A alta carga do banco de dados pode causar problemas de performance na instância de banco de dados. Esse alarme não é aplicável para instâncias de banco de dados com tecnologia sem servidor.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o valor máximo de vCPU é determinado pelo número de núcleos de vCPU (CPU virtual) da instância de banco de dados. Dependendo da vCPU máxima, valores diferentes para o limite podem ser apropriados. Preferencialmente, a carga do banco de dados não deve ultrapassar a linha da vCPU.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

AuroraVolumeBytesLeftTotal

Dimensões: DBClusterIdentifier

Descrição do alarme: este alarme ajuda a monitorar o baixo volume total restante. Quando o volume total restante atinge o limite de tamanho, o cluster relata um erro de falta de espaço. O armazenamento do Aurora é escalado automaticamente com os dados no volume do cluster e é ampliado até 128 TiB ou 64 TiB, dependendo da versão do mecanismo de banco de dados. Considere reduzir o armazenamento ao descartar as tabelas e os bancos de dados que não são mais necessários. Para obter mais informações, consulte a escalabilidade de armazenamento.

Intenção: este alarme é usado para detectar o quão próximo o cluster do Aurora está do limite de tamanho para o volume. Esse alarme pode evitar um erro de falta de espaço que ocorre quando o cluster fica sem espaço. Ele é recomendado somente para o Aurora MySQL.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: você deve calcular de 10% a 20% do limite de tamanho real com base na velocidade e na tendência de aumento de uso do volume e, em seguida, usar esse resultado como o valor limite para tomar medidas proativas antes que o volume atinja o limite.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: LESS_THAN_THRESHOLD

AuroraBinlogReplicaLag

Dimensões: DBClusterIdentifier, Role=WRITER

Descrição do alarme: este alarme ajuda a monitorar o estado de erro da replicação da instância do gravador do Aurora. Para ter mais informações, consulte Como replicar clusters de bancos de dados Amazon Aurora MySQL entre regiões da AWS. Para obter a solução de problemas, consulte Problemas de replicação no Aurora MySQL.

Intenção: este alarme é usado para detectar se a instância do gravador está em um estado de erro e não pode replicar a origem. Ele é recomendado somente para o Aurora MySQL.

Estatística: média

Limite recomendado: -1,0

Justificativa do limite: recomendamos usar -1 como o valor limite porque o Aurora MySQL publicará esse valor se a réplica estiver em um estado de erro.

Período: 60

Pontos de dados para o alarme: 2

Períodos de avaliação: 2

Operador de comparação: LESS_THAN_OR_EQUAL_TO_THRESHOLD

BlockedTransactions

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar uma alta contagem de transações bloqueadas em uma instância de banco de dados do Aurora. As transações bloqueadas podem terminar em uma reversão ou uma confirmação. A alta simultaneidade, a ociosidade nas transações ou as transações de longa execução podem ocasionar transações bloqueadas. Para obter a solução de problemas, consulte a documentação do Aurora MySQL.

Intenção: este alarme é usado para detectar uma alta contagem de transações bloqueadas em uma instância de banco de dados do Aurora com a finalidade de evitar as reversões de transações e a degradação da performance.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: você deve calcular 5% de todas as transações da sua instância usando a métrica ActiveTransactions e usar esse resultado como o valor limite. Também é possível avaliar a criticidade e os requisitos para as transações bloqueadas e analisar o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

BufferCacheHitRatio

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar uma proporção de ocorrências do cache que esteja baixa e consistente para o cluster do Aurora. Uma alta de acertos baixa indica que as consultas nessa instância de banco de dados estão acessando o disco com maior frequência. Para solucionar problemas, investigue a workload para visualizar quais consultas estão causando esse comportamento e consulte o documento de recomendações de RAM para a instância de banco de dados.

Intenção: este alarme é usado para detectar uma proporção de ocorrências do cache que esteja baixa e consistente a fim de evitar que se mantenha uma diminuição da performance na instância do Aurora.

Estatística: média

Limite recomendado: 80,0

Justificativa do limite: é possível definir o limite para a proporção de ocorrências do cache em buffer como 80%. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload.

Período: 60

Pontos de dados para o alarme: 10

Períodos de avaliação: 10

Operador de comparação: LESS_THAN_THRESHOLD

EngineUptime

Dimensões: DBClusterIdentifier, Role=WRITER

Descrição do alarme: este alarme ajuda a monitorar o baixo tempo de inatividade da instância de banco de dados do gravador. A instância de banco de dados do gravador pode se tornar inativa devido a uma reinicialização, uma manutenção, uma atualização ou um failover. Quando o tempo de atividade atinge zero devido a um failover no cluster, e o cluster tem uma ou mais réplicas do Aurora, uma réplica do Aurora é promovida como a instância primária do gravador durante um evento de falha. Para aumentar a disponibilidade do cluster de banco de dados, considere criar uma ou mais réplicas do Aurora em duas ou mais zonas de disponibilidade diferentes. Para obter mais informações, verifique os fatores que influenciam o tempo de inatividade do Aurora.

Intenção: este alarme é usado para detectar se a instância de banco de dados do gravador do Aurora está com um tempo de inatividade. Isso pode evitar falhas de execução prolongada na instância do gravador que ocorrem devido a uma falha ou a um failover.

Estatística: média

Limite recomendado: 0,0

Justificativa do limite: um evento de falha resulta em uma breve interrupção durante a qual as operações de leitura e de gravação falham com uma exceção. No entanto, o serviço é restaurado normalmente em menos de 60 segundos e muitas vezes em menos de 30 segundos.

Período: 60

Pontos de dados para o alarme: 2

Períodos de avaliação: 2

Operador de comparação: LESS_THAN_OR_EQUAL_TO_THRESHOLD

RollbackSegmentHistoryListLength

Dimensões: DBInstanceIdentifier

Descrição do alarme: este alarme ajuda a monitorar um tamanho consistente e amplo para o histórico do segmento de reversão de uma instância do Aurora. Um tamanho amplo para a lista de histórico do InnoDB indica que um grande número de versões antigas de linhas, consultas e desligamentos de banco de dados tornaram-se mais lentos. Para obter mais informações e a solução de problemas, consulte a documentação O tamanho da lista de histórico do InnoDB aumentou significativamente.

Intenção: este alarme é usado para detectar um tamanho amplo e consistente para o histórico do segmento de reversão. Isso pode ajudar a evitar manter a degradação da performance e o alto uso da CPU na instância do Aurora. Ele é recomendado somente para o Aurora MySQL.

Estatística: média

Limite recomendado: 1.000.000,0

Justificativa do limite: definir este limite para um milhão deverá fornecer tempo hábil para que você investigue o problema. No entanto, você pode ajustar esse valor com base no seu nível de performance aceitável e nas características da workload.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

StorageNetworkThroughput

Dimensões: DBClusterIdentifier, Role=WRITER

Descrição do alarme: este alarme ajuda a monitorar o alto throughput da rede de armazenamento. Se o throughput da rede de armazenamento ultrapassar a largura de banda da rede total da instância do EC2, ele poderá ocasionar uma alta latência de leitura e de gravação, o que pode causar degradação da performance. É possível verificar o tipo de instância do EC2 no Console da AWS. Para solucionar problemas, verifique quaisquer alterações nas latências de gravação e de leitura e avalie se você também acionou um alarme nessa métrica. Se for esse o caso, avalie o padrão de workload durante os horários em que o alarme foi acionado. Isso pode ajudar você a identificar se é possível otimizar a workload para reduzir a quantidade total de tráfego de rede. Se isso não for possível, talvez seja necessário considerar escalar a instância.

Intenção: este alarme é usado para detectar o alto throughput da rede de armazenamento. A detecção de alto throughput pode evitar as quedas de pacotes de rede e a degradação da performance.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: você deve calcular cerca de 80% a 90% da largura de banda da rede total do tipo de instância do EC2 e, em seguida, usar esse resultado como o valor limite para tomar medidas proativas antes que os pacotes de rede sejam afetados. Também é possível avaliar a criticidade e os requisitos para o throughput da rede de armazenamento e analisar o comportamento histórico dessa métrica para determinar níveis de limite razoáveis.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon Route 53 Public Data Plane

HealthCheckStatus

Dimensões: HealthCheckId

Descrição do alarme: esse alarme ajuda a detectar endpoints não íntegros de acordo com os verificadores de integridade. Para entender o motivo de uma falha que resulta em status de não integridade, use a guia Verificadores de integridade no console de verificação de integridade do Route 53 para visualizar o status de cada região, bem como a última falha da verificação de integridade. A guia de status também exibe o motivo pelo qual o endpoint é relatado como não íntegro. Consulte as etapas de solução de problemas.

Intenção: esse alarme usa os verificadores de integridade do Route 53 para detectar endpoints não íntegros.

Estatística: média

Limite recomendado: 1,0

Justificativa do limite: o status do endpoint é relatado como 1 quando ele está íntegro. Qualquer valor inferior a 1 indica não integridade.

Período: 60

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: LESS_THAN_THRESHOLD

Amazon S3

4xxErrors

Dimensões: BucketName, FilterId

Descrição do alarme: esse alarme nos ajuda a informar o número total de códigos de status de erro 4xx que são criados em resposta a solicitações de clientes. Os códigos de erro 403 podem indicar uma política do IAM incorreta e os códigos de erro 404 podem indicar uma aplicação cliente com comportamento incorreto, por exemplo. Habilitar o registro em log de acesso ao servidor do S3 ajudará você a identificar a origem do problema usando os campos Status HTTP e Código de erro. Para entender mais sobre o código de erro, consulte Respostas de erro.

Intenção: esse alarme é usado para criar uma linha de base para as taxas de erro 4xx típicas, de modo que você possa analisar qualquer anormalidade que possa indicar um problema de configuração.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: o limite recomendado é detectar se mais de 5% do total de solicitações estão recebendo erros 4XX. Os erros 4XX que ocorrem com frequência devem receber um alarme. Entretanto, a definição de um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível. Você também pode ajustar o limite de acordo com a carga das solicitações, levando em conta um nível aceitável de erros 4XX. Você também pode analisar dados históricos para encontrar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

5xxErrors

Dimensões: BucketName, FilterId

Descrição do alarme: esse alarme ajuda você a detectar um grande número de erros no lado do servidor. Esses erros indicam que um cliente fez uma solicitação que o servidor não conseguiu concluir. Isso pode ajudar você a correlacionar o problema que sua aplicação está enfrentando por causa do S3. Para obter mais informações para ajudar você a tratar ou reduzir erros de forma eficiente, consulte Optimizing performance design patterns. Os erros também podem ser causados por um problema com o S3. Verifique o painel de integridade do serviço da AWS para saber o status do Amazon S3 em sua região.

Intenção: esse alarme pode ajudar a detectar se a aplicação está apresentando problemas devido a erros 5xx.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: recomendamos definir o limite para detectar se mais de 5% do total de solicitações estão recebendo o 5XXError. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para ver qual é a taxa de erro aceitável para a workload da aplicação e ajustar o limite adequadamente.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

OperationsFailedReplication

Dimensões: SourceBucket, DestinationBucket, RuleId

Descrição do alarme: esse alarme ajuda a entender uma falha de replicação. Essa métrica rastreia o status de novos objetos replicados usando o S3 CRR ou S3 SRR e também rastreia os objetos existentes replicados usando a replicação em lote do S3. Consulte Solução de problemas de replicação para obter mais detalhes.

Intenção: esse alarme é usado para detectar se houve falha na operação de replicação.

Estatística: máxima

Limite recomendado: 0,0

Justificativa do limite: essa métrica emite um valor de 0 para operações bem-sucedidas e nenhum valor quando não há operações de replicação realizadas para o minuto. Quando a métrica emite um valor maior que 0, a operação de replicação não é bem-sucedida.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

S3ObjectLambda

4xxErrors

Dimensões: AccessPointName, DataSourceARN

Descrição do alarme: esse alarme nos ajuda a informar o número total de códigos de status de erro 4xx que são criados em resposta a solicitações de clientes. Habilitar o registro em log de acesso ao servidor do S3 ajudará você a identificar a origem do problema usando os campos Status HTTP e Código de erro.

Intenção: esse alarme é usado para criar uma linha de base para as taxas de erro 4xx típicas, de modo que você possa analisar qualquer anormalidade que possa indicar um problema de configuração.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: recomendamos definir o limite para detectar se mais de 5% do total de solicitações estão recebendo o 4XXError. Os erros 4XX que ocorrem com frequência devem receber um alarme. Entretanto, a definição de um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível. Você também pode ajustar o limite de acordo com a carga das solicitações, levando em conta um nível aceitável de erros 4XX. Você também pode analisar dados históricos para encontrar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

5xxErrors

Dimensões: AccessPointName, DataSourceARN

Descrição do alarme: esse alarme ajuda a detectar um grande número de erros no lado do servidor. Esses erros indicam que um cliente fez uma solicitação que o servidor não conseguiu concluir. Esses erros podem ser causados por um problema com o S3. Verifique o painel de integridade do serviço da AWS para saber o status do Amazon S3 em sua região. Isso pode ajudar você a correlacionar o problema que sua aplicação está enfrentando por causa do S3. Para obter informações que o ajudem a tratar ou reduzir esses erros com eficiência, consulte Optimizing performance design patterns.

Intenção: esse alarme pode ajudar a detectar se a aplicação está apresentando problemas devido a erros 5xx.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: recomendamos definir o limite para detectar se mais de 5% do total de solicitações estão recebendo erros 5XX. No entanto, você pode ajustar o limite para se adequar ao tráfego das solicitações, bem como às taxas de erro aceitáveis. Você também pode analisar dados históricos para ver qual é a taxa de erro aceitável para a workload da aplicação e ajustar o limite adequadamente.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

LambdaResponse4xx

Dimensões: AccessPointName, DataSourceARN

Descrição do alarme: esse alarme ajuda você a detectar e diagnosticar falhas (500s) em chamadas para o S3 Object Lambda. Esses erros podem ser causados por erros ou configurações incorretas na função do Lambda responsável por responder às suas solicitações. Investigar os fluxos de logs do CloudWatch da função do Lambda associada ao ponto de acesso do Object Lambda pode ajudar você a identificar a origem do problema com base na resposta do S3 Object Lambda.

Intenção: esse alarme é usado para detectar erros de cliente 4xx para chamadas WriteGetObjectResponse.

Estatística: média

Limite recomendado: 0,05

Justificativa do limite: recomendamos definir o limite para detectar se mais de 5% do total de solicitações estão recebendo o 4XXError. Os erros 4XX que ocorrem com frequência devem receber um alarme. Entretanto, a definição de um valor muito baixo para o limite pode fazer com que o alarme seja muito sensível. Você também pode ajustar o limite de acordo com a carga das solicitações, levando em conta um nível aceitável de erros 4XX. Você também pode analisar dados históricos para encontrar a taxa de erro aceitável para a workload da aplicação e, em seguida, ajustar o limite adequadamente.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon SNS

NumberOfMessagesPublished

Dimensões: TopicName

Descrição do alarme: esse alarme pode detectar quando o número de mensagens do SNS publicadas é muito baixo. Para solucionar problemas, verifique por que os publicadores estão enviando menos tráfego.

Intenção: esse alarme ajuda você a monitorar e detectar proativamente quedas significativas na publicação de notificações. Isso ajuda você a identificar possíveis problemas com a aplicação ou com os processos comerciais, de modo que você possa tomar as medidas adequadas para manter o fluxo esperado de notificações. Você deve criar esse alarme se você espera que seu sistema tenha um tráfego mínimo a ser atendido.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: o número de mensagens publicadas deve estar de acordo com o número esperado de mensagens publicadas para sua aplicação. Você também pode analisar os dados históricos, as tendências e o tráfego para encontrar o limite correto.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: LESS_THAN_THRESHOLD

NumberOfNotificationsDelivered

Dimensões: TopicName

Descrição do alarme: esse alarme pode detectar quando o número de mensagens do SNS entregues é muito baixo. Isso pode ocorrer devido ao cancelamento não intencional da assinatura de um endpoint ou devido a um evento do SNS que causa atraso nas mensagens.

Intenção: esse alarme ajuda você a detectar uma queda no volume de mensagens entregues. Você deve criar esse alarme se você espera que seu sistema tenha um tráfego mínimo a ser atendido.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: o número de mensagens entregues deve estar de acordo com o número esperado de mensagens produzidas e o número de consumidores. Você também pode analisar os dados históricos, as tendências e o tráfego para encontrar o limite correto.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: LESS_THAN_THRESHOLD

NumberOfNotificationsFailed

Dimensões: TopicName

Descrição do alarme: esse alarme pode detectar quando o número de mensagens do SNS com falha é muito alto. Para solucionar problemas de notificações com falha, ative o registro em log no CloudWatch Logs. A verificação dos logs pode ajudar a descobrir quais assinantes estão apresentando falhas, bem como os códigos de status que estão retornando.

Intenção: esse alarme ajuda você a encontrar proativamente problemas com a entrega de notificações e a tomar as medidas adequadas para resolvê-los.

Estatística: soma

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme depende muito do impacto das notificações com falha. Analise os SLAs fornecidos aos seus usuários finais, a tolerância a falhas e a importância das notificações, e analise os dados históricos, e então selecione um limite adequadamente. O número de notificações com falha deve ser 0 para tópicos que tenham apenas assinaturas do SQS, Lambda ou Firehose.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidAttributes

Dimensões: TopicName

Descrição do alarme: esse alarme ajuda a monitorar e resolver possíveis problemas com o publicador ou com os assinantes. Verifique se um publicador está publicando mensagens com atributos inválidos ou se um filtro inadequado foi aplicado a um assinante. Você também pode analisar o CloudWatch Logs para ajudar a encontrar a causa-raiz do problema.

Intenção: o alarme é usado para detectar se as mensagens publicadas não são válidas ou se foram aplicados filtros inadequados a um assinante.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: atributos inválidos são quase sempre um erro do publicador. Recomendamos definir o limite como 0 porque atributos inválidos não são esperados em um sistema íntegro.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

NumberOfNotificationsFilteredOut-InvalidMessageBody

Dimensões: TopicName

Descrição do alarme: esse alarme ajuda a monitorar e resolver possíveis problemas com o publicador ou com os assinantes. Verifique se um publicador está publicando mensagens com corpos de mensagem inválidos ou se um filtro inadequado foi aplicado a um assinante. Você também pode analisar o CloudWatch Logs para ajudar a encontrar a causa-raiz do problema.

Intenção: o alarme é usado para detectar se as mensagens publicadas não são válidas ou se foram aplicados filtros inadequados a um assinante.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: corpos de mensagem inválidos são quase sempre um erro do publicador. Recomendamos definir o limite como 0 porque corpos de mensagens inválidos não são esperados em um sistema íntegro.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

NumberOfNotificationsRedrivenToDlq

Dimensões: TopicName

Descrição do alarme: esse alarme ajuda a monitorar o número de mensagens que são movidas para uma fila de mensagens não entregues.

Intenção: o alarme é usado para detectar mensagens que foram movidas para uma fila de mensagens não entregues. Recomendamos que você crie esse alarme quando o SNS estiver acoplado ao SQS, Lambda ou Firehose.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: em um sistema íntegro de qualquer tipo de assinante, as mensagens não devem ser movidas para a fila de mensagens não entregues. Recomendamos que você receba uma notificação caso alguma mensagem caia na fila para que possa identificar e resolver a causa-raiz e, possivelmente, redirecionar as mensagens na fila de mensagens não entregues para evitar a perda de dados.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

NumberOfNotificationsFailedToRedriveToDlq

Dimensões: TopicName

Descrição do alarme: esse alarme ajuda a monitorar as mensagens que não puderam ser movidas para uma fila de mensagens não entregues. Verifique se a fila de mensagens não entregues existe e se está configurada corretamente. Além disso, verifique se o SNS tem permissões para acessar a fila de mensagens não entregues. Consulte a documentação da fila de mensagens não entregues para saber mais.

Intenção: o alarme é usado para detectar mensagens que não puderam ser movidas para uma fila de mensagens não entregues.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: quase sempre é um erro se as mensagens não puderem ser movidas para a fila de mensagens não entregues. A recomendação para o limite é 0, o que significa que todas as mensagens que falharem no processamento deverão ser capazes de alcançar a fila de mensagens não entregues quando a fila tiver sido configurada.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

SMSMonthToDateSpentUSD

Dimensões: TopicName

Descrição do alarme: o alarme ajuda a monitorar se você tem uma cota suficiente em sua conta para que o SNS possa entregar mensagens. Se você atingir sua cota, o SNS não poderá enviar mensagens SMS. Para obter informações sobre como definir sua cota mensal de gastos com SMS ou sobre como solicitar um aumento da cota de gastos com a AWS, consulte Definição das preferências de mensagens SMS.

Intenção: esse alarme é usado para detectar se você tem uma cota suficiente em sua conta para que as mensagens SMS sejam entregues com êxito.

Estatística: máxima

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite de acordo com a cota (limite de gastos da conta) da conta. Escolha um limite que informe a você com antecedência suficiente que você está atingindo o limite da cota para que você tenha tempo de solicitar um aumento.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

SMSSuccessRate

Dimensões: TopicName

Descrição do alarme: esse alarme ajuda a monitorar a taxa de falhas nas entregas de mensagens SMS. Você pode configurar o Cloudwatch Logs para entender a natureza da falha e tomar medidas com base nisso.

Intenção: esse alarme é usado para detectar falhas na entrega de mensagens SMS.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: defina o limite do alarme de acordo com sua tolerância para falhas na entrega de mensagens SMS.

Período: 60

Pontos de dados para o alarme: 5

Períodos de avaliação: 5

Operador de comparação: GREATER_THAN_THRESHOLD

Amazon SQS

ApproximateAgeOfOldestMessage

Dimensões: QueueName

Descrição do alarme: esse alarme observa a idade da mensagem mais antiga na fila. Você pode usar esse alarme para monitorar se os seus consumidores estão processando mensagens do SQS na velocidade desejada. Considere a possibilidade de aumentar o número de consumidores ou o throughput dos consumidores para reduzir a idade das mensagens. Essa métrica pode ser usada em combinação com ApproximateNumberOfMessagesVisible para determinar o tamanho do backlog da fila e a rapidez com que as mensagens estão sendo processadas. Para evitar que as mensagens sejam excluídas antes de serem processadas, considere a possibilidade de configurar a fila de mensagens não entregues para deixar de lado as possíveis mensagens “poison pill”.

Intenção: esse alarme é usado para detectar se a idade da mensagem mais antiga na fila QueueName é muito alta. Uma idade maior pode ser uma indicação de que as mensagens não estão sendo processadas com rapidez suficiente ou de que há algumas mensagens “poison-pill” que estão presas na fila e não podem ser processadas.

Estatística: máxima

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme depende muito do tempo esperado de processamento da mensagem. Você pode usar dados históricos para calcular o tempo médio de processamento de mensagens e, em seguida, definir o limite como 50% maior do que o tempo máximo esperado de processamento de mensagens do SQS pelos consumidores da fila.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesNotVisible

Dimensões: QueueName

Descrição do alarme: esse alarme ajuda a detectar um número alto de mensagens em andamento com relação ao QueueName. Para solucionar problemas, verifique message backlog decreasing.

Intenção: esse alarme é usado para detectar um número alto de mensagens em andamento na fila. Se os consumidores não excluírem as mensagens dentro do período de tempo limite de visibilidade, quando a fila for pesquisada, as mensagens reaparecerão na fila. Para filas FIFO, pode haver um máximo de 20 mil mensagens em andamento. Se você atingir essa cota, o SQS não retornará nenhuma mensagem de erro. Uma fila FIFO examina as primeiras 20.000 mensagens para determinar os grupos de mensagens disponíveis. Isso significa que, se houver um acúmulo de mensagens em um único grupo de mensagens, não será possível consumir mensagens de outros grupos de mensagens que foram enviadas para a fila posteriormente até que as mensagens do backlog sejam processadas com êxito.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: o valor limite recomendado para esse alarme é altamente dependente do número esperado de mensagens em andamento. Você pode usar dados históricos para calcular o número máximo esperado de mensagens em andamento e definir o limite para 50% acima desse valor. Se os consumidores da fila estiverem processando, mas não excluindo mensagens da fila, esse número aumentará repentinamente.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

ApproximateNumberOfMessagesVisible

Dimensões: QueueName

Descrição do alarme: esse alarme observa se o backlog da fila de mensagens é maior do que o esperado, indicando que os consumidores estão muito lentos ou que não há consumidores suficientes. Considere aumentar a contagem de consumidores ou acelerar os consumidores, se esse alarme entrar no estado ALARME.

Intenção: esse alarme é usado para detectar se a contagem de mensagens da fila ativa está muito alta e se os consumidores estão demorando para processar as mensagens ou se não há consumidores suficientes para processá-las.

Estatística: média

Limite recomendado: depende da sua situação

Justificativa do limite: um número inesperadamente alto de mensagens visíveis indica que as mensagens não estão sendo processadas por um consumidor na taxa esperada. Você deve considerar os dados históricos ao definir esse limite.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: GREATER_THAN_OR_EQUAL_TO_THRESHOLD

NumberOfMessagesSent

Dimensões: QueueName

Descrição do alarme: esse alarme ajuda a detectar se não há mensagens sendo enviadas de um produtor com relação ao QueueName. Para solucionar problemas, verifique o motivo pelo qual o produtor não está enviando mensagens.

Intenção: esse alarme é usado para detectar quando um produtor para de enviar mensagens.

Estatística: soma

Limite recomendado: 0,0

Justificativa do limite: se o número de mensagens enviadas for 0, o produtor não está enviando nenhuma mensagem. Se essa fila tiver um TPS baixo, aumente o número de EvaluationPeriods adequadamente.

Período: 60

Pontos de dados para o alarme: 15

Períodos de avaliação: 15

Operador de comparação: LESS_THAN_OR_EQUAL_TO_THRESHOLD

AWS VPN

TunnelState

Dimensões: VpnId

Descrição do alarme: esse alarme ajuda você a entender se o estado de um ou mais túneis é INATIVO. Para solucionar problemas, consulte VPN tunnel troubleshooting.

Intenção: esse alarme é usado para detectar se pelo menos um túnel está no estado INATIVO para essa VPN para que você possa solucionar o problema da VPN afetada. Esse alarme sempre estará no estado ALARME para redes que tenham apenas um único túnel configurado.

Estatística: mínima

Limite recomendado: 1,0

Justificativa do limite: um valor menor que 1 indica que pelo menos um túnel está no estado INATIVO.

Período: 300

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: LESS_THAN_THRESHOLD

TunnelState

Dimensões: TunnelIpAddress

Descrição do alarme: esse alarme ajuda você a entender se o estado desse túnel é INATIVO. Para solucionar problemas, consulte VPN tunnel troubleshooting.

Intenção: esse alarme é usado para detectar se o túnel está no estado INATIVO para que você possa solucionar o problema da VPN afetada. Esse alarme sempre estará no estado ALARME para redes que tenham apenas um único túnel configurado.

Estatística: mínima

Limite recomendado: 1,0

Justificativa do limite: um valor menor que 1 indica que o túnel está no estado INATIVO.

Período: 300

Pontos de dados para o alarme: 3

Períodos de avaliação: 3

Operador de comparação: LESS_THAN_THRESHOLD