Quais alertas você deve ter em aplicações Serverless?
Tags: ptbr, serverless, aws, webdev
Published: 2020-09-13 02:54:28

![Alertas em aplicações Serverless](https://res.cloudinary.com/lumigo-production/w_683,h_551,c_fit/fl_lossy,f_auto/wp-website/2020/08/serverless-alerts.png)

Uma métrica chave para medir o quão bem você lida com as interrupções do sistema é o tempo médio de recuperação ou MTTR (Mean Time To Recovery). É basicamente o tempo que você leva para restaurar as condições de funcionamento do sistema. Quanto mais curto o MTTR, mais rápido os problemas são resolvidos e menos impacto os usuários experimentariam e, com sorte, é mais provável que continuem a usar seu produto!

E o primeiro passo para resolver qualquer problema é saber que você tem um problema. O Tempo Médio de Descoberta (MTTD - The Mean Time to Discovery) mede a rapidez com que você detecta problemas, e você precisa de alertas para isso - muitos alertas.

Exatamente quais alertas que você precisa depende do seu aplicativo e das métricas que você está coletando. Serviços gerenciados como Lambda, SNS e SQS relatam importantes métricas do sistema para o CloudWatch por padrão. Portanto, dependendo dos serviços que você utiliza em sua arquitetura, existem alguns alertas comuns que você deve ter. E aqui estão alguns alertas que sempre procuro ter.

## AWS Lambda (Alertas Regionais)

Você deve ter notado as métricas regionais (eu sei, o painel diz `Account-level`, embora sua própria descrição diga que está “na região AWS”) na página do painel Lambda.

![Alertas regionais da AWS Lambda](https://res.cloudinary.com/lumigo-production/w_700,h_380,c_fit/fl_lossy,f_auto/wp-website/2020/08/Lambda-regional-alerts.png)

### Alerta regional de Concorrência

A métrica regional `ConcurrentExecutions`, é uma métrica importante para ter um alerta. Defina o limite de alerta para ~80% do seu limite de concorrência regional atual (que começa em 1000 para a maioria das regiões).

![Alerta de concorrência regional AW Lambda](https://res.cloudinary.com/lumigo-production/w_700,h_108,c_fit/fl_lossy,f_auto/wp-website/2020/08/regional-concurrency-alert.png)

Dessa forma, você será alertado quando o uso do Lambda estiver se aproximando do limite atual para que possa solicitar um aumento de limite antes que as funções sejam *throttled*.

### Alerta regional de *throttling*

Você também pode adicionar alertas regionais a métricas `Throttles`. Mas isso depende se você está usando ou não `Reserved Concurrency`. `Reserved Concurrency` é a quantidade de concorrência que uma função pode usar e o excesso de invocações mostra que *throttling* está fazendo seu trabalho. Mas esses *throttlings* também podem acionar seu alerta com falsos positivos.

## AWS Lambda (Alertas por função)

_(Observação: dependendo do acionador da função, alguns desses alertas podem não ser aplicáveis.)_

### Alerta de taxa de erro

Use a métrica matemática do CloudWatch para calcular a taxa de erro de uma função - ou seja `100 * Errors / MAX([Errors, Invocations])`. Alinhe o limite de alerta com seus acordos de nível de serviço (SLAs). Por exemplo, se seu SLA afirma que 99% das solicitações devem ser bem-sucedidas, defina o alerta de taxa de erro para 1%.

### Alerta de throttle

A menos que você esteja usando `Reserved Concurrency`, provavelmente não deve esperar que as invocações de funções sejam *throttled*. Portanto, você deve ter um alerta contra a métrica `Throttles`.

### Alerta `DeadLetterErrors`

Para funções assíncronas com uma fila de devoluções (DLQ - dead letter queue), você deve configurar um alerta em relação a métrica `DeadLetterErrors`. Isso informa quando o serviço Lambda não é capaz de encaminhar eventos com falha para o DLQ configurado.

### Alerta `DestinationDeliveryFailures`

Semelhante ao anterior, para funções com Destinos Lambda (Lambda Destinations), você deve configurar um alerta em relação a métrica `DestinationDeliveryFailures`. Isso informa quando o serviço Lambda não pode encaminhar eventos para o destino configurado.

### Alerta `IteratorAge`

Para funções acionadas por streams do Kinesis ou DynamoDB, a métrica `IteratorAge` informa a idade das mensagens que eles recebem. Quando essa métrica começa a aumentar, é um indicador de que a função não está acompanhando a taxa de novas mensagens e está ficando para trás. O pior cenário é que você terá perda de dados, já que os dados nos fluxos são mantidos por apenas 24 horas por padrão. É por isso que você deve configurar um alerta em relação à `IteratorAge`métrica para que possa detectar e retificar a situação antes que piore.

## Como Lumigo pode ajudar

Mesmo que você saiba quais alertas você deve ter, ainda assim é necessário muito esforço para configurá-los. É aqui que ferramentas de terceiros, como o Lumigo, também podem agregar muito valor. Por exemplo, o Lumigo permite uma série de alertas integrados (usando padrões sensíveis e reconhecidos pelo setor) para funções rastreadas automaticamente para que você não precise configurá-las manualmente. Mas você ainda tem a opção de desabilitar alertas para funções individuais, caso deseje.

Aqui estão alguns dos alertas que a Lumigo oferece:

-   **Predições (Predictions)** - quando as funções Lambda estão perigosamente perto dos seus limites de recursos (memória / duração / simultaneidade, etc.)
-   **Atividade anormal detectada** - invocações (aumento / diminuição), erros, custo, etc. Veja abaixo um exemplo.
-   Relatório sob demanda de recursos configurados incorretamente (DLQs ausentes, modo de taxa de transferência do DynamoDB incorreto, etc.)
-   **Limite excedido** - memória, erros, inicializações a frio, etc.
-   Falha de tempo de execução do Lambda
    

![](https://res.cloudinary.com/lumigo-production/w_496,h_142,c_fit/fl_lossy,f_auto/wp-website/2020/08/image-1.png)

Além disso, a Lumigo se integra a várias plataformas de mensagens populares para que você seja alertado por meio do seu canal favorito.

![](https://res.cloudinary.com/lumigo-production/w_1024,h_556,c_fit/fl_lossy,f_auto/wp-website/2020/08/Screenshot-2020-08-17-at-22.28.28.png)

Ah, e a **Lumigo** **não cobra extra para alertas** . Você paga apenas pelos rastreamentos que é enviado para o Lumigo, e ela tem um nível gratuito para até 150.000 invocações rastreadas por mês. Você pode se inscrever para uma conta [Lumigo gratuita aqui](https://platform.lumigo.io/signup) .

## API Gateway

Por padrão, o API Gateway agrega métricas para todos os seus endereços. Por exemplo, você terá uma métrica `5xxError` para toda a API, portanto, quando houver um pico nos erros 5xx, você não terá ideia de qual endereço era o problema.

Você precisa configurar `Enable Detailed CloudWatch Metrics` nas configurações de estágio (*stages*) de suas APIs para dizer ao API Gateway para gerar métricas ao nível de métodos. Isso aumenta o custo do CloudWatch, mas sem eles, você terá dificuldade em depurar problemas que acontecem em produção.

![alertas api gateway cloudwatch](https://res.cloudinary.com/lumigo-production/w_700,h_318,c_fit/fl_lossy,f_auto/wp-website/2020/08/api-gateway-cloudwatch-alerts.png)

Depois de ter as métricas definidas por método à mão, você pode configurar alertas para métodos individuais.

## Alerta de latência p90 / p95 / p99

Quando se trata de monitorar a latência, nunca use a Média. “Média” é apenas um valor estatístico, [por si só, é quase sem sentido](https://www.autodeskresearch.com/publications/samestats) . Até que plotemos a distribuição de latência, não entenderemos realmente como nossos usuários estão experimentando nosso sistema. Por exemplo, todos esses gráficos produzem a mesma média, mas têm uma distribuição muito diferente de como nossos usuários experimentaram o sistema.

![A média não faz sentido para a experiência do usuário](https://res.cloudinary.com/lumigo-production/w_827,h_332,c_fit/fl_lossy,f_auto/wp-website/2020/08/p90p95p99-Latency-alert.gif)

Sério, sempre use percentis (*percentiles*).

Portanto, ao configurar alertas de latência para métodos individuais, tenha duas coisas em mente:

-   Use a métrica `Latency` ao invés de `IntegrationLatency`. `IntegrationLatency` mede o tempo de resposta do alvo da integração (por exemplo, Lambda), mas não inclui nenhuma sobrecarga que o API Gateway adiciona. Ao medir a latência da API, você deve medir a latência o mais próximo possível do cliente.
-   Use o 90º, 95º ou 99º percentils. Ou talvez use todos os 3, mas defina níveis de limite diferentes para eles. Por exemplo, latência p90 em 1 segundo, latência p95 em 2 segundos e latência p99 em 5 segundos.

## Alertas de taxa 4xx / 5xx

Ao usar a estatística média para as métrica API Gateway `4XXError` e `5XXError`, você obtém a taxa de erro correspondente. Configure alertas nessas métricas para alertá-lo de errors inesperados.

## SQS

Ao trabalhar com SQS, você deve configurar alertas na métrica `ApproximateAgeOfOldestMessage` para uma fila SQS. Ele informa a idade da mensagem mais antiga na fila. Quando essa métrica aumenta, significa que a função SQS não é capaz de acompanhar a taxa de novas mensagens.

## Step Functions

Existem várias métricas sobre as quais você deve criar alertas:

-   `ExecutionThrottled`
-   `ExecutionsAborted`
-   `ExecutionsFailed`
-   `ExecutionsTimedOut`

Eles representam as várias maneiras pelas quais as execuções da máquina de estado falhariam. E como as Step Functions costumam ser usadas para modelar fluxos de trabalho essenciais para os negócios, normalmente eu definiria o limite de alerta para 1.

## Eu posso codificar tudo isso?

Sim você pode!

Aqui na Lumigo, publicamos um projeto de código aberto chamado [cloudwatch-alarms-macro](https://github.com/lumigo/SAR-cloudwatch-alarms-macro) para fazer exatamente isso. É uma macro que permite definir os padrões da organização para alerta de limites e gerar alertas para recursos que você tem em sua stack CloudFormation.

A maneira mais rápida de começar é implantar a macro em sua conta da AWS por meio do [Serverless Application Repository aqui](https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:374852340823:applications~cloudwatch-alarms-macro). Depois disso, você pode seguir os exemplos para configurar seus limites padrões e substituir em sua stack.

Obtenha uma conta Lumigo gratuita e configure alertas instantaneamente: [Inscreva-se no Lumigo](https://platform.lumigo.io/signup).

# Créditos

- [What alerts should you have for serverless applications?](https://lumigo.io/blog/what-alerts-should-you-have-for-serverless-applications/), escrito originalmente por [Yan Cui](https://twitter.com/theburningmonk).