Um simples alarme de integridade aprimorada para um ambiente Beanstalk com “.ebextensions”
Desenvolvimento de software é, geralmente, atrelado a ideia de codificação quando desenvolvedores tentam defini-lo. Porém, é um processo que engloba desde a concepção até a manutenção do software. Claro que codificação é o que dá a “vida” ao software, mas é a sua manutenção que o faz realmente se destacar perante outros softwares, concorrentes ou não.
Quando falamos manutenção queremos dizer que a aplicação estará sempre em execução com suas funcionalidades operando de forma esperada. Para isso, conhecimento na linguagem de programação escolhida para o projeto e em infraestrutura são essenciais, visto que conseguir executar na “minha máquina” é diferente de conseguir executar em um servidor/nuvem, por mais dificil que seja ler isso, infelizmente é a verdade.
Existem diversas coisas que podemos fazer para auxiliar na manutenção de uma aplicação e uma delas é a verificação de integridade (health check). Verificação de integridade é uma requisição periódica enviada para a aplicação para verificar seu status, de modo que a resposta determina se ela está saudável ou não. Serviços em nuvem como AWS, Azure e Google Cloud utilizam a verificação de integridade como uma medida padrão de status de uma app. Com isso, podemos começar a falar sobre o nosso alarme de integridade aprimorada na AWS.
Alarme de integridade aprimorada?
“Os relatórios de integridade aprimorada são um recurso que pode ser habilitado no ambiente para permitir que o AWS Elastic Beanstalk obtenha informações adicionais sobre os recursos no ambiente”.
Esse recurso ajuda na identificação de problemas que possam causar indisponibilidade da aplicação como, por exemplo, uma instância EC2 com uso excessivo de cpu ou memória. Para usá-lo é necessário ter uma plataforma Elastic Beanstalk versão 2 ou mais recente (nesse exemplo, nosso ambiente utiliza o Amazon Linux 2).
O status fornecido por esse relatório de integridade aprimorada pode ser publicado como uma métrica customizada para ser utilizada no CloudWatch, um serviço de monitoramento e observação que fornece dados e insights para monitorar aplicações. Com isso, podemos criar um alarme de métrica no CloudWatch que “realiza uma ou mais ações com base no valor da métrica ou na expressão relativa a um limite em alguns períodos”.
Opa, isso é interessante, mas como que eu crio um desse para o meu ambiente?
Primeiro, a versão da plataforma do seu ambiente deve ser 2 ou mais recente. Depois, deve-se verificar se seu ambiente possui relatório de integridade aprimorada habilitado acessando seu ambiente e indo no menu “Configuração” > “Monitoria” > “Relatório de integridade” e marcando “Aprimorada”.
E então…
Basta copiar/colar o arquivo “.config” abaixo dentro da pasta “.ebextensions” do seu projeto e incorporá-lo ao “Source Bundle” quando fizer uma nova implantação da aplicação.
Entendendo o arquivo:
A política de escalonamento “AWSEBAutoScalingScaleDownPolicy” representa uma das duas políticas criadas automaticamente durante a criação do ambiente. No nosso exemplo, o ambiente tem apenas uma instância por vez e a “capacidade desejada” e “capacidade mínima” estão configuradas no grupo Auto Scaling com valor 1 (valor padrão para qualquer ambiente Elastic Beanstalk depois de sua criação). Isso significa que, quando tomada a ação de escalonar para menos, a instância com problema será removida e outra será colocada para manter o ambiente vivo e funcionando, tudo operado automaticamente pelo grupo Auto Scaling.
O nome da métrica para esse alarme de integridade aprimorada é “EnvironmentHealth” e ele só está disponível em plataformas 2.0 ou mais novas, requerimento previamente destacado, sem nenhum custo adicional! O status do ambiente pode ser mapeado para os seguintes valores:
- OK = 0
- Info = 1
- Unknown = 5
- No data = 10
- Warning = 15
- Degraded = 20
- Severe = 25
Dessa lista, os últimos 3 status são os que, de fato, representam que o ambiente em execução está impactado de alguma forma. Podemos ver, detalhadamente, a(s) causa(s) dessa(s) falha(s) clicando no botão “Causas”. Por conta disso, escolhemos “ComparisonOperator” como “GreaterThanThreshold” e o valor “10”, que cobre exatamente esses 3 status.
O alarme pode ser lido assim: ele é disparado depois de ficar um período “Period” de “180” segundos (deve ser múltiplo de 60) com uma média “Average” maior que “GreaterThanThreshold” “10”, o que acionará uma ação “AlarmAction” de escalonar menos uma instância.
Vendo o alarme
Ao acessar o serviço CloudWatch, podemos ver os alarmes criados dentro do menu “Alarmes”. Logo após a sua criação, o alarme entra no estado “Dados insuficientes”, em seguida “Em alarme” e, por último, “OK”.
Ao clicar no nome do nosso alarme, acessaremos a sua tela de preview, na qual vemos um gráfico com uma linha azul e uma linha vermelha. O comportamento esperado é que nossa app esteja executando sem problemas, o que representa o alarme no estado “OK”, que se traduz no gráfico com a linha azul estando abaixo da linha vermelha (nosso valor de limite).
Quando o alarme entrar no estado “Em alarme”, significa que a linha azul estará acima da vermelha. Se isso permanecer por mais de 3 minutos (180 segundos), a ação de escalonar para menos será realizada e a implantação de uma nova instância irá ocorrer, o que, posteriormente, fará o alarme voltar para o estado “OK”.
É isso! Parece um recurso simples, porém a longo prazo ele se mostra ser muito, muito útil.
Conclusão
Um alarme de métrica é uma ferramenta poderosa que nos ajuda a monitorar nosso ambiente Elastic Beanstalk de maneira automática, nos livrando daquela preocupação constante de “vamos verificar se está tudo bem com nossa app?”.
Existe um mundo de métricas que são publicadas pelos serviços da AWS que podem ser usadas para criar uma combinação de alarmes que possa melhor atender as necessidades dos mais diversos projetos de software. Isso realmente permite que nós desenvolvedores possamos alocar mais o nosso tempo para criar mais e melhores soluções em nosso dia-a-dia de trabalho.
