Nesta série de duas postagens, você aprenderá a monitorar serviços sem servidor com o CloudWatch criando painéis, widgets e alarmes com o AWS CDK.
Nesta postagem, a segunda parte da série, usaremos o AWS CDK para monitorar um serviço serverless de exemplo com painéis do CloudWatch de acordo com os princípios apresentados na primeira postagem da série.
No primeiro post , você aprenderá o que significa monitorar um serviço serverless, por que isso é essencial e como criar dashboards do CloudWatch para monitorar seu serviço serverless com widgets. Os widgets exibem informações de logs do CloudWatch, métricas, métricas personalizadas e definem alarmes do CloudWatch como parte de uma abordagem proativa.
Índice
Introdução
Utilizar os painéis do AWS CloudWatch permite o monitoramento centralizado do API Gateway, funções Lambda e DynamoDB, fornecendo insights em tempo real sobre seu desempenho e integridade operacional. Ao agregar métricas, logs e alarmes, o CloudWatch facilita o diagnóstico e a análise rápidos de problemas em seus aplicativos sem servidor. Além disso, a configuração de alarmes garante reação imediata a atividades anômalas.
Nesta postagem, escreveremos um código CDK que cria painéis do CloudWatch que monitoram logs e métricas e criam alarmes para um serviço sem servidor de exemplo.
Construiremos um painel que monitora um serviço sem servidor de exemplo, o serviço "pedidos".
Esses são os recursos que construiremos com o AWS CDK.
Exemplo de arquitetura de serviço sem servidor
O serviço 'pedidos' permite que os usuários encomendem produtos.
Vamos construir um painel de monitoramento para este serviço que implemente os conceitos apresentados na primeira parte da série .
Nosso objetivo é monitorar o gateway da API de serviço, a função Lambda e as tabelas do DynamoDB e garantir que tudo esteja em ordem. Além disso, queremos visualizar as métricas de KPI de serviço.
Construiremos dois dashboards do CloudWatch, um resumo de alto nível e um resumo de baixo nível, cada um servindo a uma persona diferente. Os dashboards exibirão widgets de logs do CloudWatch (logs de erro para nossas funções Lambda) e métricas do CloudWatch de vários recursos.
Além disso, definiremos alarmes do CloudWatch para nos notificar sobre erros e degradações críticas de desempenho.
Se você deseja entender o raciocínio por trás dessa abordagem e por que o monitoramento é essencial, leia a primeira parte desta série.
Você pode encontrar o código e o código de serviço aqui .
* O código faz parte do meu projeto de modelo de livro de receitas do AWS Lambda Handler.
Este repositório fornece um modelo de serviço funcional, implantável, de código aberto e sem servidor com uma função AWS Lambda e código Python AWS CDK com todas as melhores práticas e um pipeline CI/CD completo. Você pode iniciar um serviço sem servidor em 3 cliques!
Código CDK
Usaremos uma biblioteca de código aberto: cdk-monitoring-constructs .
A biblioteca suporta diversas linguagens de programação: Python, TypeScript, Java e C#.
A biblioteca fornece "construções CDK fáceis de usar para monitorar sua infraestrutura AWS com o Amazon CloudWatch ". Ela abstrai a criação do widget CW e a simplifica com suporte pronto para uso para muitos serviços AWS, como API Gateway, Lambda, DynamoDB e muito mais.
A biblioteca utiliza o conceito de classes de fábrica. Você tem classes de fábrica para criar um widget com base em grupo de log ou com base em métricas de CW para um grande número de serviços AWS comumente usados. Você também pode criar alarmes de CW com facilidade e monitorar métricas de CW personalizadas (KPIs). Você pode usar suas classes de fábrica para definir cores personalizadas, tamanhos de fonte, tamanhos, configurações de alarme padrão e muito mais.
Usaremos a biblioteca para monitorar os recursos do serviço 'orders': função Lambda, Api Gateway e DynamoDB com facilidade.
Abaixo está uma construção L3 CDK que constrói todos os recursos de monitoramento. Vamos rever o que ele cria e mergulhar fundo em cada seção.
Analisaremos três funções diferentes que compõem todos os recursos.
'_build_topic' - cria o tópico SNS para que os alarmes enviem detalhes do alarme quando acionados.
'_build_high_level_dashboard' - cria o painel de alto nível.
'_build_low_level_dashboard' - cria o painel de baixo nível.
Como entrada, recebemos o recurso API Gateway, duas tabelas do DynamoDB e uma lista de funções Lambda para monitorar.
Vamos analisar cada uma das funções nas linhas 14-16.
Tópico de Alarmes
Os alarmes do CloudWatch são inúteis, a menos que tenham uma ação quando disparados. Configuramos os alarmes para enviar uma notificação SNS para um novo tópico SNS. A partir daí, você pode usar qualquer assinatura - HTTPS/SMS/E-mail, etc. para notificar suas equipes sobre o alarme.
Nas linhas 24-29, definimos a chave KMS que será usada para criptografar mensagens SNS em repouso .
Nas linhas 30-34, definimos o tópico e usamos a chave que descrevemos anteriormente.
Nas linhas 37-44, definimos uma política de permissões e permitimos que o CloudWatch publique mensagens no tópico. Isso ocorrerá quando um alarme for disparado; o CW enviaria uma mensagem SNS descrevendo o alarme.
Agora que temos o tópico SNS, podemos passá-lo para as seguintes funções usadas ao criar alarmes CW.
Painel de alto nível
Este painel foi criado para ser uma visão geral executiva do serviço.
Métricas totais do API Gateway fornecem informações sobre o desempenho e a taxa de erro do serviço. Elas também incluem um alarme sobre a taxa de erro do API Gateway.
As métricas de KPI também estão incluídas na parte inferior.
Personas que usam este painel: SRE, desenvolvedores e equipes de produtos (KPIs).
Vamos revisar a função '_build_high_level_dashboard' que gera este painel:
Nas linhas 26-34, construímos a fachada do painel. Ela representa um painel em CW. Esta classe contém todos os widgets que criamos e tem várias funções de fábrica que constroem widgets e alarmes.
Você pode substituir as configurações padrão e definir as configurações padrão de fábrica para alarmes, widgets e métricas com suas configurações personalizadas.
Nas linhas 29 a 32, criamos uma fábrica de alarmes e a configuramos para que todos os alarmes produzidos pela fachada tenham uma ação para enviar ao tópico SNS que definimos anteriormente quando acionados.
Na linha 35, adicionamos um cabeçalho ao painel.
Nas linhas 36-39, adicionamos vários widgets que monitoram nosso API Gateway - os quatro principais widgets. Eles são fornecidos prontos para uso como parte da biblioteca. Na linha 38, adicionamos um alarme para um limite de erro para o API Gateway (HTPP 4XX ou 5XX). O alarme usará a ação SNS padrão definida nas linhas anteriores.
Nas linhas 40-51, criamos os widgets inferiores que monitoram a métrica personalizada do CloudWatch no namespace 'orders_kpi' chamado 'ValidCreateOrderEvents'. Podemos adicionar várias métricas a um grupo de widgets (linha 50), mas no serviço 'orders', temos apenas uma.
Painel de baixo nível
Ele visa um mergulho profundo em todos os recursos do serviço. Requer uma compreensão da arquitetura do serviço e suas partes móveis.
O painel fornece as métricas da função Lambda para latência, erros, limitações, simultaneidade provisionada e invocações totais.
Além disso, um widget de logs do CloudWatch mostra apenas logs de 'erro' da função Lambda.
Quanto às tabelas do DynamoDB, temos o banco de dados primário e a tabela de idempotência para uso, latência de operação, erros e limitações.
Personas que usam este painel: desenvolvedores, SREs.
Vamos revisar o código CDK que cria esses widgets:
Nas linhas 36-44, construímos a fachada do painel. Ela representa um painel em CW. Esta classe contém todos os widgets que criamos e tem várias funções de fábrica que constroem widgets e alarmes.
Nas linhas 39-42, criamos uma fábrica de alarmes e a configuramos para que todos os alarmes produzidos pela fachada tenham uma ação para enviar ao tópico SNS que definimos anteriormente quando acionados.
Na linha 45, adicionamos um cabeçalho ao painel.
Nas linhas 46-56, construímos as duas linhas superiores do painel. Duas por função Lambda - neste caso, temos apenas uma função. Usamos a criação de widget integrada para a função Lambda para monitorar todos os aspectos cruciais da função. Nas linhas 47-49, definimos um alarme que monitora a duração p90 da função. Se você quiser saber mais sobre métricas de percentil, confira meu primeiro post .
Nas linhas 51-56, definimos um widget que exibe logs do grupo de logs da função Lambda, mas apenas logs de ERRO.
Nas linhas 58 e 59, usamos o suporte ao widget DynamoDB integrado da biblioteca para monitorar o banco de dados principal e a tabela de idempotência que temos.
Trecho completo do CDK
Aqui está todo o código junto:
Você pode encontrar o código de serviço atualizado aqui .