Esta postagem do blog se concentra na observabilidade e discute os seguintes tópicos:
Métricas de monitoramento
Rastreamento com AWS-Xray.
Usaremos o Powertools para AWS, CloudWatch e AWS X-Ray.
O que torna um manipulador AWS Lambda resiliente, rastreável e fácil de manter? Como você escreve esse código?
Nesta série de blogs, tentarei responder a essas perguntas compartilhando meu conhecimento e as melhores práticas do AWS Lambda, para que você não cometa os mesmos erros que eu cometi.
Esta série de blogs apresenta progressivamente as melhores práticas e utilitários, adicionando um utilitário por vez.
Parte 1 focada em Registro.
A Parte 3 focou na Observabilidade do Domínio de Negócios .
A Parte 4 focou em Variáveis de Ambiente .
A Parte 5 focou na Validação de Entrada .
A Parte 6 focou em Configuração e Sinalizadores de Recursos.
A Parte 7 focou em como iniciar seu próprio serviço Serverless em dois cliques.
Parte 8 focado nas melhores práticas do AWS CDK .
Fornecerei um projeto Python de modelo de manipulador AWS Lambda funcional e de código aberto.
Este manipulador incorpora as melhores práticas do Serverless e tem todos os recursos necessários para um manipulador adequado e pronto para produção.
Abordarei registro, observabilidade, validação de entrada, sinalizadores de recursos, configuração dinâmica e como usar variáveis de ambiente com segurança.
Embora os exemplos de código sejam escritos em Python, os princípios são válidos para todas as linguagens de programação suportadas pelas funções do AWS Lambda.
Você pode encontrar todos os exemplos neste repositório do GitHub, incluindo o código de implantação do CDK.
Observabilidade
“Em TI e computação em nuvem, observabilidade é a capacidade de medir o estado atual de um sistema com base nos dados que ele gera, como logs, métricas e rastros.” — conforme descrito aqui .
A observabilidade da função AWS Lambda é necessária em dois domínios: técnico e comercial. O domínio técnico observa e monitora métricas de baixo nível, como latência, duração, taxa de erro e uso de memória. O domínio comercial observa os principais indicadores de desempenho (KPIs) definidos pela sua equipe de produto.
Este blog aborda monitoramento e rastreamento como parte do domínio técnico. A Parte 1 da série abordou Logging, e a Parte 3 abordará o domínio empresarial.
Métricas de monitoramento
Ao monitorar seu manipulador AWS Lambda, o AWS CloudWatch é o serviço ideal. Ele coleta métricas de serviço prontas para uso de vários serviços AWS, incluindo AWS Lambda. Além disso, ele fornece visibilidade em nível macro do estado atual de seus manipuladores AWS Lambda e dos serviços com os quais ele se integra.
O AWS CloudWatch mede as métricas do AWS Lambda em três categorias: invocação, desempenho e simultaneidade. Você pode visualizar essas métricas em um painel do AWS CloudWatch e personalizá-lo. Você pode aprender mais sobre elas aqui .
Quais métricas merecem atenção extra?
Esta lista contém métricas de todas as três categorias. Essas métricas podem ajudar você a reduzir suas taxas mensais e até mesmo descobrir problemas antes que eles evoluam para uma falha de produção.
Tempo de execução do AWS Lambda — Esforce-se para ter a menor duração possível. Descubra anomalias e desvios das médias assim que elas começarem a aparecer. Além disso, suas funções têm tempos limite predefinidos. Certifique-se de que seu manipulador não chegue perto do limite, ou você pode estar arriscando o encerramento do seu manipulador.
Uso de memória — Não subprovisione memória Lambda; monitore o uso real de memória e deixe um limite suficiente. Esteja ciente de que aumentar a memória Lambda pode reduzir o tempo de execução total em alguns casos. Veja aqui .
Taxa de erro (exceções não tratadas, timeouts) — Este número deve ser próximo de zero em um ambiente saudável. Use request-id/correlation id para depurar seus erros (conforme mencionado na primeira parte da série). Além disso, preste atenção às mudanças nas taxas médias de erro, pois qualquer anomalia aqui pode indicar um serviço com falha.
Provisione métricas relacionadas à simultaneidade, limitação e porcentagem de uso. Essas métricas fornecem insights sobre seu uso real de simultaneidade de provisionamento. Essas métricas podem evitar desempenho inadequado por subprovisionamento (muita limitação e atingindo o limite máximo de simultaneidade) ou desperdiçar seu dinheiro por superprovisionamento e ter um sistema principalmente ocioso. Você deve sempre ajustar e estar atento para otimizar essas configurações.
Alarmes do AWS CloudWatch
Outro aspecto importante do AWS CloudWatch são os Alarmes. Os alarmes monitoram métricas medidas e disparam quando um limite predefinido é atingido. Os alarmes têm vários estados: 'OK', 'ALARME' e 'DADOS INSUFICIENTES'.
Você deve prestar atenção extra aos alarmes no estado 'ALARM'. Esse estado significa que a métrica medida está fora do limite definido, e mais investigação ou ações imediatas são necessárias para trazer a métrica de volta ao limite saudável.
Os alarmes podem ter ações. Eles podem se integrar a outros serviços da AWS, como AWS SNS e AWS EventBridge. Você pode enviar um SMS, e-mail ou até mesmo acionar uma função do AWS Lambda que altera a configuração ou inicia um pipeline de implantação. Essas integrações significam que você pode criar alarmes complexos.
Uma ação de alarme típica é uma ação que notifica um engenheiro de suporte de “combate a incêndio” de que algo terrível aconteceu ou está prestes a acontecer, e que ele deve tomar a iniciativa e salvar o dia.
Regra de ouro
Seria melhor definir alarmes para seu manipulador sobre as métricas que mencionei no blog. Defina limites e limites adequados. Aprenda os limites de tempo de execução aceitos e determine como seu serviço saudável se comporta. Deve ser uma combinação de uso antecipado, experiência mínima aceitável do cliente e custo.
Não pare nas métricas do AWS Lambda. O AWS CloudWatch monitora muitos serviços da AWS que se integram ao AWS Lambda. Os serviços incluem AWS SQS, API Gateway, SNS, EventBridge e muito mais. Juntos, eles contam a história completa do seu ambiente de produção.
Leia mais sobre alarmes aqui .
No geral, o AWS CloudWatch é um excelente serviço de monitoramento. Ele tem muitos utilitários avançados, como Lambda insights, detecção de anomalias, etc. Alguns podem ser mais úteis para você do que outros. Eu recomendo que você pesquise e determine quais recursos lhe dão mais valor, pois é impossível cobrir todos eles neste blog.
No entanto, tenha em mente que serviços de terceiros, como o DataDog , fornecem recursos semelhantes ou extras e se integram bem com o AWS CloudWatch. Pesquise o que os concorrentes oferecem. Eles podem atender melhor às suas necessidades.
Rastreamento
O AWS CloudWatch monitora o AWS Lambda no nível macro . No entanto, isso não é suficiente. E quanto ao nível micro ? Como você pode se aventurar nas entranhas do seu manipulador AWS Lambda e identificar gargalos e problemas de desempenho?
Vamos supor que um alarme do AWS CloudWatch que monitora a duração do seu manipulador tenha entrado no estado 'ALARM'. Como você o depura?
O utilitário rastreador AWS X-Ray e AWS Lambda Powertools vem para o resgate.
Raio X da AWS
“Com o X-Ray, você pode entender como seu aplicativo e seus serviços subjacentes estão se saindo para identificar e solucionar a causa raiz de problemas de desempenho e erros. O X-Ray fornece uma visão de ponta a ponta das solicitações conforme elas viajam pelo seu aplicativo e mostra um mapa dos componentes subjacentes do seu aplicativo.” — Documentação da AWS
Visualizador de linha do tempo
O utilitário mais útil no AWS X-Ray, na minha opinião, é o Timeline viewer . Ele permite que você visualize uma única invocação de função do AWS Lambda e analise seu funcionamento interno e desempenho. Cada função interna ou chamada HTTP é rastreada e apresentada em uma tabela fácil de ler.
O AWS X-Ray permite pesquisar rastreamentos de invocação única do AWS Lambda por nome de serviço, ID de solicitação e outros parâmetros.
Encontrar seu gargalo de desempenho nunca foi tão fácil!
Combinando Traços
Outro recurso valioso da visualização da linha do tempo é exibir rastros conectados em uma única visualização da linha do tempo. Se seu manipulador AWS Lambda enviar uma solicitação HTTP para outro manipulador AWS Lambda rastreado, o rastreamento de invocação específico do outro manipulador também aparecerá na mesma página. Ambas as tabelas são apresentadas em uma única página. Tão conveniente!
Este recurso é perfeito para otimização de desempenho e caça de “milissegundos” para ajudar você a levar seu código ao máximo. Ele facilita o processo de depuração de localizar a chamada de serviço problemática que aumenta a duração geral.
Mapa de serviços
Por fim, o Service Map é outro recurso útil. Os rastros não mentem. Os rastros expõem conexões de serviço que você não sabia que existiam ou eram difíceis de compreender olhando o código. O Service map visualiza um fluxo de solicitação entre serviços em um gráfico em vez de uma tabela, como o visualizador TimeLine.
Veja informações mais detalhadas aqui .
OK, onde eu me inscrevo?
Vamos tornar nosso manipulador AWS Lambda rastreável no AWS X-Ray e no AWS CloudWatch Service Map. Podemos fazer isso adicionando o utilitário tracer do AWS Powertools. O AWS Lambda Powertools fornece um wrapper fino do AWS X-Ray SDK por meio do uso de decoradores. Para começar a usar o AWS X-Ray, você precisa fazer duas coisas:
Defina um objeto rastreador global e decore o manipulador e quaisquer funções internas.
Conceda permissões à função do AWS Lambda para enviar dados ao AWS X-Ray conforme descrito aqui .
Vamos adicionar o utilitário tracer no código do manipulador do AWS Lambda apresentado no primeiro blog . O manipulador tinha funcionalidade de logger. As instâncias globais das classes do AWS Lambda Powertools (logger e tracing) serão definidas no arquivo “ utils/infra.py” . Essas instâncias globais são definidas em uma pasta de utilitários compartilhada para que possam ser reutilizadas por todas as camadas de serviço e arquivos no AWS Lambda. Elas também podem ser compartilhadas por vários manipuladores quando seu serviço se expande e novos manipuladores são adicionados à pasta “ handlers” .
Na linha 10, criamos uma instância do rastreador global com um nome de serviço exato.
O manipulador reside na pasta “ handlers” em um arquivo chamado “ my_handler.py”:
Na linha 6, importamos o rastreador da pasta utility.
Na linha 14, decoramos o manipulador, então os rastros são capturados na invocação do manipulador e enviados para o AWS X-Ray no final. Pela minha experiência, é melhor definir “capture_response” como False se o seu manipulador pode retornar dados com informações de identificação pessoal ( PII) ou objetos de resposta grandes. Clique aqui para mais detalhes.
Na linha 9, adicionamos o rastreamento da função interna “inner_function_example”. Isso torna a função interna rastreável e expõe seu tempo de execução específico no AWS X-Ray. Você deve usar esse decorador para rastrear quaisquer funções não triviais que possam ter problemas de desempenho - se ele enviar uma solicitação HTTP para um serviço externo, usar o AWS SDK ou fizer cálculos complexos, decore-o.
Você pode encontrar todos os exemplos de código neste repositório do GitHub.
Uma última coisa — Anotações do Tracer
Você pode definir anotações personalizadas para ajudar a encontrar rastros de forma mais rápida e fácil no AWS X-Ray. Por exemplo, você pode encontrar rastros por ID do cliente. Você pode aprender mais sobre isso aqui .
No entanto, embora esse mecanismo seja excelente para tornar os rastros mais fáceis de encontrar, ele não é um substituto do logger. Não adicione muitos metadados por meio do mecanismo de anotação; registre-os em vez disso.
Regra de ouro
Reduza os custos de rastreamento. Os custos de rastreamento do AWS X-Ray podem aumentar. O alarme e os monitores do AWS CloudWatch informarão se o desempenho do seu manipulador do AWS Lambda estiver degradando. Sugiro que você desabilite o rastreador por padrão e o habilite somente (por meio de uma variável de ambiente ou explicitamente) ao fazer testes de benchmark ou ao tentar depurar um problema de desempenho que NÃO pode ser resolvido examinando logs.
Realize avaliações de desempenho sempre que possível, considerando as implicações de custo.
Melhorar o tempo de execução e a latência não é trivial — Embora este tópico mereça uma postagem de blog separada, aqui estão algumas dicas rápidas para melhorar ambos os parâmetros: habilitar a simultaneidade provisionada (remover inicializações a frio), aumentar o tamanho da memória e executar seus AWS Lambdas em processadores Graviton. Clique aqui para mais detalhes.
É essencial ter em mente que usar o utilitário de rastreamento do AWS Powertools não o restringe a usar somente o AWS X-Ray. Muitas soluções de rastreamento de terceiros oferecem integração com o AWS X-Ray (consulte a documentação do DataDog). Faça sua pesquisa, encontre a ferramenta que funciona melhor para você e que fornece a melhor experiência geral de observabilidade.
Próximo
Isso conclui a segunda parte da série. Junte-se a mim para a próxima parte, onde implemento métricas de domínio de negócios.
Um agradecimento especial para:
Bem Heymink