Este post foca em observabilidade, mas desta vez da perspectiva do domínio de negócios: Métricas e KPIs de negócios. Usaremos métricas AWS Custom CloudWatch.
O que torna um manipulador AWS Lambda resiliente, rastreável e fácil de manter? Como você escreve tal 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.
A Parte 1 se concentra no registro.
A Parte 2 se concentra na Observabilidade : monitoramento e rastreamento.
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.
Durante esta série de blogs, 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.
Por que você deve se importar com métricas e KPIs?
“As organizações podem combinar o contexto de negócios com análises e desempenho de aplicativos full stack para entender o impacto comercial em tempo real, melhorar a otimização de conversão, garantir que os lançamentos de software atendam às metas comerciais esperadas e confirmar que a organização está aderindo aos SLAs internos e externos.” — conforme descrito aqui .
Métricas de negócios, como dito acima, podem impulsionar seu negócio em direção ao sucesso.
Métricas consistem em uma chave e um valor; Um valor pode ser um número, porcentagem, taxa ou qualquer outra unidade. Métricas típicas são o número de sessões, usuários, taxa de erro, número de visualizações, etc.
KPIs, indicadores-chave de desempenho, são métricas "especiais" que, em teoria, podem prever o sucesso do seu serviço. KPIs são estrategicamente projetados para dar suporte ao caso de uso do negócio. Eles exigem um profundo entendimento do seu negócio e dos seus usuários e, como tal, exigem uma definição cuidadosa. KPIs servem como um meio de prever o futuro do negócio.
Não cumpra KPIs bem definidos e veja seu serviço fracassar. Tenha sucesso em atingir seus KPIs e seu serviço terá mais chances de sucesso.
Diferentes serviços definem diferentes métricas como KPIs. Um blog pode definir KPIs como visitantes recorrentes, quantidade de assinantes e taxa de rejeição. Essas métricas dizem se o blog está ganhando força e gerando leads de assinantes consistentes.
Outras métricas não KPIs também são benéficas. Essas são métricas que mostram o passado e o presente. Por exemplo, métricas de uso podem fazer você perceber que gastou muito tempo em um recurso com o qual a maioria dos usuários não se importa. Elas podem ajudar você a mudar seu foco para o que importa, e isso, por sua vez, melhora os KPIs e suas chances de sucesso no serviço.
Agora que temos uma compreensão clara do porquê precisamos de métricas de domínio de negócios, vamos discutir o como.
Implementação
Assim como acontece com outras métricas integradas da AWS, queremos monitorá-las no AWS CloudWatch.
Queremos poder criar alarmes e exibir os valores em painéis.
Vamos supor que nosso manipulador de exemplo, 'my_handler,' esteja gerando o KPI — ' valid events count .' Ele incrementa a métrica em 1 para cada evento que passa na validação de entrada. Como o exemplo de manipulador atual ainda não tem validação de entrada (será adicionado na parte 5 da série), todos os eventos de entrada são sempre considerados válidos e contados por essa métrica.
Métricas personalizadas se comportam como quaisquer outras métricas de serviços integrados do AWS CloudWatch.
Tudo o que resta é adicionar o código que envia a métrica e definir as permissões de função adequadas. As permissões necessárias são 'cloudwatch: PutMetricData' , que devem ser adicionadas à sua função AWS Lambda role.
Quanto ao código, o AWS Lambda Powertools tem um utilitário que faz exatamente isso: o utilitário Metrics .
Antes de mergulharmos no exemplo de código, vamos rever alguma terminologia de métricas do AWS CloudWatch.
Um Namespace contém pelo menos uma dimensão. Uma dimensão é composta por uma chave e um valor e contém uma ou mais métricas. Métricas têm uma chave, tipo de unidade e valor.
Existem vários tipos de unidades: contagem, taxa, porcentagem, segundos, bytes, etc.
Namespace ---> [ Dimensões (chave, valor) ] ---> [ Métricas (chave, valor do tipo de unidade) ]
A imagem abaixo descreve a hierarquia de métricas que desejamos definir:
O namespace ' my_product_kpi' contém uma dimensão com uma chave de 'service' e valor de 'my_service'. Esta dimensão contém uma métrica com uma chave ' ValidEvents' do tipo de unidade numérica.
Juntando tudo
Antes de mergulharmos de cabeça no código, gostaria de salientar que uma regra geral é adicionar métricas de KPI de negócios mais tarde durante o desenvolvimento do seu serviço. Requisitos e KPIs ficarão mais aparentes conforme você se aproxima da linha de chegada.
Vamos adicionar a utilidade das métricas aos utilitários do registrador e do rastreador já implementados nos blogs anteriores.
Você pode encontrar todos os exemplos de código neste repositório do GitHub.
Na linha 14, criamos uma instância global do utilitário Metrics. O namespace é definido como ' my_product_kpi .'
E finalmente, a versão completa de ' my_handler.py' :
Na linha 8, importamos o utilitário global metrics. Na linha 16, adicionamos um decorador de métricas, ' log_metrics .' Este decorador valida nossas métricas geradas. Cada métrica tem uma unidade métrica que define um tipo e um valor, e eles devem corresponder (tipos de unidade numérica correspondem a um valor numérico, etc.). O decorador também serializa e envia as métricas para o AWS CloudWatch no final de cada invocação. Na linha 23, adicionamos a métrica ' ValidEvents ' e uma contagem de 1 porque o manipulador obteve um evento válido. É isso! O manipulador agora tem recursos de registro, rastreamento e métricas integrados, e agora você pode monitorar os KPIs de negócios.
Próximo
Isso conclui a terceira parte da série. Junte-se a mim para a próxima parte, onde eu analiso e valido variáveis de ambiente do AWS Lambda.
Agradecimentos especiais para:
Bem Heymink
Comments