Amazon Cloudwatch — A sala de controle
Muito mais que somente métricas e Dashboards.
No ecossistema digital atual, uma das maneiras pelas quais as empresas podem garantir que seus sites e aplicativos estejam sempre disponíveis, confiáveis e escaláveis é através do uso de hospedagem na nuvem. Ao invés de executar o software em um servidor local ou em um data center alugado, muitas empresas agora utilizam instâncias virtuais de provedores como o Amazon Web Services(AWS).
Para os administradores que costumam trabalhar com servidores físicos, essa mudança para a nuvem pode ser um pouco perturbadora. Isso ocorre muito devido a percepção de perda de controle. Para superar isso a AWS fornece ferramentas versáteis, que quando utilizadas de modo correto, superam as expectativas até dos mais céticos administradores. No post de hoje, vamos falar de uma dessas ferramentas: Amazon Cloudwatch.
O objetivo deste post é mostrar as diversas empregabilidades que esta ferramenta propõe, provando ser uma verdadeira “sala de controle” de suas aplicações na nuvem.
O que é?
O Amazon CloudWatch permite que desenvolvedores, arquitetos de sistemas e administradores monitorem suas aplicações AWS na nuvem, em tempo quase real. O CloudWatch é configurado para automaticamente fornecer métricas do número de requisições, latência e uso da CPU. Além disso, os usuários podem enviar seus próprios logs e métricas personalizadas para o Cloudwatch monitorar. Existe também a possibilidade de criar alarmes personalizados, permitindo a notificação quase em tempo real quando frases ou métricas específicas aparecem nos logs ou quando ocorrem determinados eventos, como por exemplo pouco espaço em disco.
Então, conforme é possível perceber, o CloudWatch combina um extenso conjunto de funcionalidades que são divididas em três serviços dedicados: Metrics, Logs e Events. Vamos falar com pouco mais sobre cada um deles.
Metrics
Uma métrica representa uma série cronológica de informações como: utilização de CPU, uso da rede ou custos da AWS. Uma métrica armazena dados numéricos em conjunto com o registro da hora. A maioria dos serviços AWS envia os dados para o CloudWatch, onde os mesmos são persistidos a cada minuto. Assim, é possível recuperar dados minuto a minuto, ou também recuperar estatísticas, como por exemplo a soma dos últimos 10 minutos, a média de 1 dia e assim por diante.
O CloudWatch Management Console fornece uma maneira gráfica de representar as métricas. A Figura 1 a seguir mostra um exemplo.
Além dos muitos serviços AWS que enviam dados para o CloudWatch, também é possível enviar dados personalizados para serem armazenados e assim criar métricas personalizadas. Uma métrica personalizada é semelhante às métricas dos serviços AWS, a única diferença é que são os dados enviados por você ( por exemplo, usando o SDK ou a AWS CLI).
No primeiros 15 dias, o CloudWatch mantém os dados minuto a minuto. Nos próximos 48 dias, mantém uma resolução de 5 minutos. Nos próximos 392 dias, o CloudWatch mantêm uma resolução de 1 hora. Depois disso ( somando um total de 445 dias) os dados são apagados.
Analisar gráficos é com certeza útil para identificar padrões e encontrar problemas, mas também é possível automatizar este processo.
Alarms
No CloudWatch, um alarme serve para observar uma métrica. Assim que a métrica — ou estatística da métrica — atinge um limite especifico, o alarme dispara uma ação. Uma das ações mais comuns é enviar uma mensagem para um tópico SNS. Sendo possível se inscrever no tópico para receber notificações por e-mail sempre que o alarme for disparado. Também é possível criar uma ação para escalar o seu sistema reagindo a escassez de recursos ou até executar lógicas mais sofisticadas utilizando Lambda functions. A Figura 2 ilustra uma alarme básico.
Ao definir um alarme, também é possível definir regras mais sofisticadas do que apenas um limite. Por exemplo, é possível especificar que o limite deve ser alcançado várias vezes seguidas para o alarme ser disparado. Outra possibilidade é disparar uma ação quando não houver dados para ser analisados. Esta funcionalidade é útil para os casos de métricas personalizadas. Imagine uma máquina que envia uma métrica personalizada, caso esta máquina pare de funcionar, a métrica não será mais enviada, o que deve ser tratado como um erro e disparar um alarme.
Vamos falar um pouco mais sobre os gráficos. Os seres humanos são bons em encontrar padrões em dados. Então, vamos explorar melhores maneiras de visualizar métricas.
Dashboard
Após começar a usar o CloudWatch, de inicio já é perceptível, são inúmeras as possibilidades de métricas para utilizar. Porém somente algumas delas irão ser interessante para você. Então, que tal manter as métricas mais importantes em um único lugar? E tem mais, este lugar especifico pode ser compartilhado com toda a equipe. Isso trará para sua equipe mais visibilidade da infraestrutura em execução, que serve como motivação para se sentir responsável. E isso é muito natural, criando a cultura de monitoramento e colocando este “poder” nas ferramentas da equipe, a responsabilidade vem como bônus.
“Com grandes poderes, vêm grandes responsabilidades”, Stan Lee. Tio Ben
No CloudWatch, um quadro dashboard possui 24 espaços onde é possível configurar quais métricas exibir. As possibilidades de exibição são muitas, entre as opções é possível citar: a possibilidade de exibir o último valor de determinada métrica, gráficos de linha simples com múltiplas métricas e gráficos de área empilhada com múltiplas métricas. Todas as métricas são exibidas no mesmo intervalo de tempo. A Figura 3 um exemplo de dashboard:
Logs
O CloudWatch Logs é o lugar onde todos os logs são armazenados e indexados. Através do CloudWatch Logs Agent é possível fazer stream do conteúdo dos seus arquivos de logs das instâncias EC2 diretamente para o CloudWatch Logs. Quando configuramos um Log, iremos primeiro criar um Group, e dentro de cada é possível ter vários Log streams, que é onde ficará o conteúdo dos logs. Dentro de cada Group é possível definir o período de retenção, quando o limite é atingido os logs são excluídos.
Sobre a pesquisa de logs, é possível pesquisar por textos completos, mas também existe a possibilidade de consultas estruturadas para o caso de buscar mais complexas.
Pensando no monitoramento, não seria legal se você pudesse observar seus logs automaticamente e receber um alarme caso algo estranho acontecesse?
Metric Filter
É possível definir um Metric Filter criando um filtro de consulta —por texto ou com consulta estruturadas. Cada linha correspondente ao resultado desta consulta é contabilizada em uma métrica. Já viu onde podemos chegar né? Pois é, usando isto em conjunto com os alarmes, podemos criar alarmes bem uteis para os casos específicos de nossas aplicações.
Subscription Filter
Algumas vezes os Metric Filters não são poderosos o suficiente. Se você precisar executar uma lógica mais sofisticada, você pode usar o Subscription filter, que é basicamente se inscrever a um Log Group. Desta maneira, para cada registro da consulta será possível:
- Invocar uma Lambda function.
- Gravar o registro no Kinesis stream. É possível analisar os dados usando o Kinesis Cliente Library ou com ferramentas de Big Data, como por exemplo o Spark. Já falei de Kinesis em um post anterior.
- Gravar o registro no Kinesis Firehose. O Firehose pode entregar para S3 ou ElasticSearch, sendo assim possível usar diferentes ferramentas para analisar os dados.
Events
A infraestrutura da AWS está sempre mudando. Recursos não adicionados e removidos a todo momento. O CloudWatch Events fornece uma maneira de reagir a tais mudanças. Ele fornece um fluxo de eventos da sua conta, onde muitos serviços da AWS publicam eventos. Por exemplo, o serviço EC2 publica um evento quando o estado de uma instância muda( por exemplo, de “running” para “terminated”), o Management Console publica um evento a cada Login efetuado, e muito mais.
Assim como é possível criar métricas personalizadas, também existe a possibilidade de criar eventos personalizados. O PutEvents permite enviar eventos para CloudWatch Events. Este exemplo mostra um caso de uso onde é utilizado para monitorar a saúde de uma aplicação.
Rule
O CloudWatch Event Rule é similar a um alarme. O Rule define quais tipos de eventos são de interesse e qual a ação deve ser disparada quando ocorre o evento. Assim como o alarme, entre as possíveis ações estão: o envio de mensagem para um tópico SNS e o disparo de uma Lambda Function para os casos de logicas mais elaboradas.
Conclusão
Antes de estudar sobre Amazon CloudWatch — quando só “ouvia falar” — eu achava que era uma simples ferramenta para exibição de gráficos, Dashboards e etc. Quando comecei a ler sobre descobri que era muito mais que isso. E esta foi a principal razão de eu escrever este post. Assim como o título propõe, o CloudWatch é uma verdadeira sala de controle para as aplicações. Como podemos perceber, a ferramenta vai muito além da criação de Dashboards, permitindo diversos meios de reagir na detecção de anomalias nos dados(métricas, logs ou eventos). E em conjunto com os demais serviços da AWS( Lambda functions, Kinesis, SNS, entre outros) é possível criar soluções mais complexas, permitindo muita flexibilidade. Para aqueles que utilizam soluções AWS, acredito ser um ótimo candidato no momento de levantar as possíveis ferramentas de monitoramento.
Se quiser trocar uma ideia ou entrar em contato comigo, pode me achar no Twitter (@e_ferreirasouza) ou Linkedin.
Grande abraço e até a próxima!
