top of page
Foto do escritorRan Isenberg

AWS Lambda Cookbook — Parte 1 — Melhores práticas de registro com CloudWatch Logs e Powertools para AWS


livro de receitas
Foto de RODNAE Productions de Pexels

Esta postagem é a primeira da série e se concentra nas melhores práticas de registro para funções do Lambda usando o AWS CloudWatch e o Powertools para AWS.


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.

Fornecerei um projeto Python de modelo de manipulador AWS Lambda funcional e de código aberto.

Você pode encontrar todos os exemplos neste repositório do GitHub, incluindo o código de implantação do CDK.


Este manipulador incorpora as melhores práticas do Serverless e tem todos os recursos para um manipulador adequado e pronto para produção. Abordarei questões como registro, rastreamento, 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 qualquer linguagem de programação de manipulador AWS Lambda suportada.

A maioria dos exemplos de código aqui são do excelente repositório AWS Lambda Powertools . Eu escrevi vários dos utilitários mencionados nesta série de blogs e doei 2 deles, oparser e o feature flags , para o AWS Lambda Powertools.

  • Esta série de blogs apresenta progressivamente as melhores práticas e utilitários, adicionando um utilitário por vez.

  • A Parte 2 focou na Observabilidade: monitoramento e rastreamento.

  • 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 .


O ponto de partida

Um manipulador lambda my_handler recebe uma entrada de um evento de dicionário e um objeto de contexto lambda. Ele retorna uma resposta JSON. Escrito abaixo está o manipulador básico do AWS Lambda visto em muitos exemplos de código AWS.

 

O madeireiro

Registrador
Foto de Khari Hayden de Pexels

O primeiro utilitário pode ser o mais direto de todos. Normalmente, o primeiro instinto é usar a função print interna do Python como sua solução de registro. No entanto, você não deve. O Python tem uma biblioteca de registro interna. Uma classe logger fornece uma API simples que adiciona visibilidade e depura informações ao seu serviço AWS Lambda.

Dito isso, recomendo fortemente que você use a implementação do logger do AWS Lambda Powertools . É um wrapper da biblioteca de logging do Python que fornece recursos extras, como configuração de saída JSON (e muito mais).

Por que o formato de saída JSON é importante?

Por padrão, todos os logs do AWS Lambda são enviados para o AWS CloudWatch (assumindo que você forneça ao seu AWS Lambda as permissões necessárias). Armazenar os logs em um só lugar é excelente. No entanto, a depuração eficiente requer recursos de pesquisa de texto livre.

Serviços da AWS como o AWS CloudWatch Logs Insights indexam seus logs e fornecem uma pesquisa de texto livre fácil. Serviços de terceiros podem fazer isso; DataDog e Logz.io vêm à mente. Esses serviços facilitam a experiência de depuração e ajudam você a encontrar os problemas mais rapidamente.

No entanto, você só pode aproveitar todo o poder desses mecanismos de busca quando usa documentos estruturados em JSON (em vez de strings de linha única).

Vamos revisar o exemplo abaixo, onde a mesma mensagem de log é escrita nos formatos string e JSON.

Documentos baseados em JSON permitem que você mantenha dados de uma maneira mais estruturada e organizada, pesquise por itens de hierarquia interna ( event_list[0] ou user_data.company ) e tenha tipos de dados não string ( int, bool, dict, list ). Isso, por sua vez, permite que você crie painéis e métricas calculadas que fornecem melhor visibilidade e insights sobre o estado atual do seu manipulador AWS Lambda.

Interface do usuário do AWS CloudWatch Insights
Interface de usuário do AWS Cloudwatch Insights. retirado de https://aws.amazon.com/blogs/opensource/simplifying-serverless-best-practices-with-lambda-powertools/

Juntando tudo

O exemplo abaixo demonstra como usar o registrador AWS Lambda Powertools:

Na linha 8, criamos o logger.

Na linha 12, definimos o AWS request_id como o correlation id , que será adicionado a qualquer log seguinte daquele ponto automaticamente. O id de correlação permite que você encontre todos os logs correspondentes a uma única solicitação em vários serviços e execuções, desde que os serviços ao longo do caminho o registrem e o passem da mesma maneira. Ele facilita drasticamente o processo de depuração para uma única solicitação.

ID da solicitação AWS é um identificador exclusivo que permitirá que você identifique uma execução lambda específica dentre as muitas execuções do seu AWS Lambda. O AWS CloudWatch gravará todos os logs de execução no mesmo grupo de logs do AWS Cloudwatch, portanto, ter um identificador exclusivo é obrigatório. Você pode ler mais sobre isso aqui .


A linha 13 imprime um log JSON com um nível de depuração, e o campo de mensagem é igual a ' meu manipulador é chamado .'

Você pode ler mais sobre o registrador aqui e aqui .

 

Regra de ouro

regra de ouro
Foto de Joshua Miranda de Pexels
  1. Não, repito, NÃO registre o conteúdo do parâmetro do evento ou qualquer outra entrada que seu AWS Lambda receba como um todo. Você pode estar registrando PII — ”Informações Pessoais Identificáveis” (número de ID, número de telefone, etc.). Você pode estar violando regulamentações como o GDPR sem nem saber. É por isso que é essencial registrar apenas parâmetros nos quais você confia que não têm dados PII ou removê-los do PII antes de registrá-los. Você pode ler mais sobre isso aqui .

  2. Mantenha sua mensagem de log estática. Essa é a mensagem que você provavelmente irá procurar. Quando você adiciona dinâmico (valor de variáveis) à mensagem de log, torna-se impossível saber o que procurar no AWS Cloudwatch Logs Insights. Registre os valores das variáveis na seção extra do logger. Neste exemplo, “Coletando pagamento” é uma declaração genérica, enquanto os dados dinâmicos são impressos no campo de dicionário extra. Veja mais exemplos aqui .

  3. Registre no início e no fim de qualquer função. Quanto mais registros você tiver, mais fácil será entender a causa raiz de um erro.

  4. Registre um erro sempre que uma exceção for capturada. Adicione o máximo de detalhes possível sem expor PII.

  5. Seja específico com a mensagem de log. Você precisa ser capaz de entender a mensagem e o contexto por si só, sem ter que ler 20 outros logs antes daquele log.

  6. Certifique-se de sempre usar as mesmas chaves na seção extra do registrador para facilitar a pesquisa (escolha “id” ou “ID” e seja consistente).

  7. Refatorar . Se você encontrar um problema que não consegue entender apenas olhando os logs, refatore. Adicione logs ou torne os logs atuais mais significativos. Os logs são inestimáveis para a prontidão da produção. Faça cada log valer a pena; caso contrário, você gastará mais tempo depurando e, ainda mais, tempo refatorando os logs novamente.

  8. Não exagere.


Uma mensagem estática com variáveis na seção extra. de https://awslabs.github.io/aws-lambda-powertools-python/latest/core/logger/#extra-parameter


Próximo

Isso conclui a primeira parte da série. Junte-se a mim para a próxima parte , onde eu abordo o rastreamento do AWS Lambda.


Um agradecimento especial para:


bottom of page