O Elastic Observability monitora métricas de serviços da AWS em apenas alguns minutos? É isso mesmo?

A transição para aplicações distribuídas está em pleno andamento, impulsionada principalmente pela nossa necessidade de estarmos “sempre conectados” como consumidores e empresas em ritmo acelerado. Essa necessidade está levando as implantações a ter requisitos mais complexos, além da capacidade de serem globalmente diversificadas e inovarem rapidamente.

A nuvem está se tornando a opção de implantação de fato para as aplicações atuais. Muitas implantações na nuvem optam por hospedar suas aplicações na AWS devido ao conjunto globalmente diversificado de regiões que ela cobre e à infinidade de serviços (para desenvolvimento e inovação mais rápidos) disponíveis, bem como para reduzir os custos operacionais e de capital. Na AWS, as equipes de desenvolvimento estão encontrando valor adicional na migração para o Kubernetes no Amazon EKS, testando as mais recentes opções sem servidor e aprimorando as aplicações tradicionais em camadas com serviços melhores.

O Elastic Observability oferece 30 integrações prontas para uso para serviços da AWS, e outras ainda serão lançadas.

Uma rápida revisão destacando algumas das integrações e funcionalidades pode ser encontrada em um post anterior:

• Elastic and AWS: Seamlessly ingest logs and metrics into a unified platform with ready-to-use integrations (Elastic e AWS: ingestão perfeita de logs e métricas em uma plataforma unificada com integrações prontas para uso).

Outros posts sobre as principais integrações de serviços da AWS no Elastic:

• APM (metrics, traces and logs) for serverless functions on AWS Lambda with Elastic (APM (métricas, traces e logs) para funções sem servidor no AWS Lambda com a Elastic)
• Log ingestion from AWS Services into Elastic via serverless forwarder on Lambda (Ingestão de log de serviços da AWS no Elastic por meio do encaminhador sem servidor no Lambda)
• Nova integração do Elastic e do Amazon S3 Storage Lens: simplifique o gerenciamento, controle custos e reduza riscos
• Elastic Cloud com AWS FireLens: gere insights com rapidez usando a ingestão de dados sem agente

Uma lista completa de integrações da AWS pode ser encontrada na documentação online da Elastic:

• Lista completa de integrações da AWS

Além das nossas integrações nativas da AWS, o Elastic Observability agrega não apenas logs, mas também métricas para serviços e aplicações da AWS executadas em serviços de computação da AWS (EC2, Lambda, EKS/ECS/Fargate). Todos esses dados podem ser analisados de forma visual e mais intuitiva usando as funcionalidades avançadas de machine learning da Elastic, que ajudam a detectar problemas de desempenho e revelar as causas raiz antes que os usuários finais sejam afetados.

Para obter mais detalhes sobre como o Elastic Observability fornece funcionalidades de monitoramento de performance de aplicação (APM) como mapas de serviço, tracing, dependências e correlações de métricas baseadas em ML:

• Correlações de APM no Elastic Observability: identificação automática das prováveis causas de lentidão ou falha nas transações
• Elastic and AWS: Get the most value from your data sets (Elastic e AWS: extraia o máximo de valor dos seus conjuntos de dados)

É isso mesmo: a Elastic oferece ingestão, agregação e análise de métricas para serviços e aplicações da AWS em serviços de computação da AWS (EC2, Lambda, EKS/ECS/Fargate). A Elastic é mais do que logs: ela oferece uma solução unificada de observabilidade para ambientes da AWS.

Neste post, analisarei como o Elastic Observability pode monitorar métricas de uma aplicação simples da AWS em execução em serviços da AWS que incluem:

• AWS EC2
• AWS ELB
• AWS RDS (AuroraDB)
• Gateways NAT da AWS

Como você verá, uma vez instalada a integração, as métricas chegarão instantaneamente, e você poderá começar a analisá-las imediatamente.

O que está implantado:

• 1 VPC com 6 sub-redes
• 2 AZs
• 2 servidores web por AZ
• 2 servidores de aplicação por AZ
• 1 balanceador de carga de aplicação externo
• 1 balanceador de carga de aplicação interno
• 2 gateways NAT para gerenciar o tráfego para a camada de aplicação
• 1 gateway de internet
• 1 RDS Aurora DB com uma réplica de leitura

No final do post, também forneceremos um roteiro do Playwright a ser implementado para carregar esse app. Isso ajudará a impulsionar as métricas para “iluminar” os dashboards.

Navegue até a integração da AWS na Elastic.

Selecione a integração Add AWS.

É aqui que você adicionará suas credenciais, e elas serão armazenadas como uma política no Elastic. Essa política será usada como parte da instalação do agente na próxima etapa.

Como você pode ver, a integração geral da AWS da Elastic coletará uma quantidade significativa de dados de 30 serviços da AWS. Se não quiser instalar essa integração geral da AWS da Elastic, você poderá selecionar integrações individuais para instalar.

Selecione o nome da política que você criou na última etapa.

Siga a etapa 3 nas instruções da janela Add agent (Adicionar agente). Isso exigirá que você:

1. Abra uma instância do EC2

• t2.medium é o mínimo
• Linux — você escolhe qual
• Certifique-se de permitir a reserva aberta na instância do EC2 ao iniciá-la

2. Faça login na instância e execute os comandos na guia Linux Tar (veja um exemplo abaixo)

Aqui está um roteiro simples que você também pode executar usando o Playwright para adicionar tráfego ao site da aplicação de três camadas da AWS:

Esse roteiro iniciará três navegadores, mas você pode limitar essa carga a um navegador no arquivo playwright.config.ts.

Para este exercício, executamos esse tráfego por aproximadamente cinco horas com intervalo de cinco minutos durante o teste do site.

Vamos ver o que surge!

Todos esses dashboards estão prontos para uso e, para todas as imagens a seguir, restringimos as visualizações apenas aos itens relevantes do nosso app.

Em todos os dashboards, limitamos o período de execução do gerador de tráfego.

Depois de filtrarmos nossas quatro instâncias do EC2 (dois servidores web e dois servidores de aplicação), podemos ver o seguinte:

1. Todas as quatro instâncias estão funcionando sem falhas nas verificações de status.

2. Vemos a utilização média da CPU ao longo do período, e nada parece anormal.

3. Vemos os bytes da rede entrando e saindo, agregando-se ao longo do tempo à medida que o banco de dados é carregado com linhas.

Embora este exercício mostre uma pequena parte das métricas que podem ser visualizadas, há mais disponíveis no AWS EC2. As métricas listadas na documentação da AWS estão todas disponíveis, incluindo as dimensões para ajudar a restringir a busca de instâncias específicas etc.

Para o dashboard do ELB, filtramos nossos dois balanceadores de carga (balanceador de carga da web externo e balanceador de carga de aplicação interno).

Com o dashboard pronto para uso, você pode ver métricas específicas do ELB da aplicação. Uma boa parte das métricas específicas do ELB da aplicação listadas na documentação da AWS estão disponíveis para adicionar gráficos.

Para nossos dois balanceadores de carga, podemos ver o seguinte:

1. Ambos os hosts (instâncias do EC2 conectadas aos ELBs) estão íntegros.

2. As unidades de capacidade do balanceador de carga (quanto você está usando) e as contagens de solicitações aumentaram conforme o esperado durante o período de geração de tráfego.

3. Optamos por mostrar as contagens de 4XX e 2XX. Os 4XX ajudarão a identificar problemas com a aplicação ou a conectividade com os servidores de aplicação.

Para o AuroraDB, que é implantado no RDS, filtramos apenas as instâncias primárias e secundárias do Aurora no dashboard.

Assim como acontece com o EC2 e o ELB, a maioria das métricas de RDS do Cloudwatch também estão disponíveis para criar novos gráficos e tabelas. Neste dashboard, restringimos tudo para mostrar o seguinte:

1. Taxa de transferência de Insert e taxa de transferência de Select

2. Latência de gravação

3. Uso da CPU

4. Número geral de conexões durante o período

Filtramos para observar apenas nossas duas instâncias NAT que estão voltadas para os servidores de aplicação. Tal como acontece com os outros dashboards, há outras métricas disponíveis para construir gráficos e tabelas conforme necessário.

Para o dashboard de NAT, podemos ver o seguinte:

1. Os gateways NAT estão indo bem porque não há queda de pacotes

2. Um número esperado de conexões ativas do servidor web

3. Conjunto bastante normal de métricas para entrada e saída de bytes

Parabéns, você começou a monitorar métricas dos principais serviços da AWS para a sua aplicação!

2. Você pode instalar o encaminhador de logs do Lambda. Essa opção extrairá logs de vários locais. Veja o diagrama da arquitetura abaixo.

Uma análise dessa opção também pode ser encontrada no post do blog a seguir.

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste post permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis atualmente poderão não ser entregues dentro do prazo previsto ou nem chegar a ser entregues.