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
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.
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 .'
Regra de ouro
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 .
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 .
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.
Registre um erro sempre que uma exceção for capturada. Adicione o máximo de detalhes possível sem expor PII.
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.
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).
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.
Não exagere.
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:
Koby Aharon
Yaara Gradovitch
e Mauro Rois.