top of page
Foto do escritorNathan Hanks

Aumente o engajamento do aplicativo com AWS CloudWatch Metrics e Powertools para AWS

AWS CloudWatch e Powertools
AWS CloudWatch e Powertools

Métricas personalizadas do CloudWatch, frequentemente utilizadas como indicadores-chave de desempenho (KPIs), possuem aplicações versáteis além de seu uso convencional. O Powertools for AWS Lambda simplifica o processo de escrever essas métricas, desbloqueando casos de uso inovadores.

Este artigo orientará você na personalização da observabilidade integrando métricas do CloudWatch em notificações push móveis, uma estratégia que melhora significativamente o engajamento do aplicativo móvel. Se você é um engenheiro de dados procurando instrumentar um pipeline de ingestão ou um desenvolvedor de aplicativos que visa entregar notificações de métricas específicas do usuário, esta publicação oferece insights valiosos personalizados para você.

 

Introdução do escritor convidado

Este post foi escrito por Nathan Hanks, um Managing Director na Protiviti na prática de Tecnologia Emergente. Nathan está envolvido em desenvolvimento de software há mais de 25 anos, abrangendo TI corporativa como empreendedor e consultor.

Nathan pode ser contatado no LinkedIn .

 

Índice

 

Histórico - O SmartHunter

Antes de discutirmos as métricas do CloudWatch, deixe-me fornecer algum contexto sobre como cheguei ao meu uso das métricas do CloudWatch. Em resumo, escrevi um aplicativo móvel, The SmartHunter, que usa IA para ajudar os caçadores a serem o mais proficientes possível quando decidem sair para uma caçada. Para este aplicativo, os usuários carregam imagens de suas várias câmeras de trilha, e o serviço de backend da nuvem usa IA para ajudá-los a entender onde e quando devem planejar suas expedições. Então, quando os usuários carregam essas imagens (geralmente vários milhares de uma vez), um pipeline de ingestão (composto de uma série de funções lambda) processa essas imagens. Além do processamento principal dessas imagens, eu queria fornecer observabilidade aos usuários do aplicativo, dando a eles insights sobre quantas imagens foram processadas e quais informações foram coletadas das imagens. Abaixo está o aplicativo, mostrando a capacidade de revisar fotos.

Exemplo de aplicativo
Exemplo de aplicativo

Eu sou um usuário ávido de Powertools para AWS Lambda e estou usando métricas para meus propósitos - observando o sistema e me alertando sobre como os processos do sistema estão sendo executados. (Se você não estiver familiarizado com o Powertools, ele é essencialmente um conjunto incrível de ferramentas que encapsula as melhores práticas e padrões para a construção de aplicativos baseados em Lambda.) No entanto, eu não queria fornecer ou expor um painel do CloudWatch para os usuários do meu aplicativo. Mas eu queria encontrar uma maneira de expor essas métricas, e acredito que as notificações push ajudam a impulsionar o engajamento com seu aplicativo. Então, comecei a descobrir como eu poderia utilizar essas métricas e expô-las aos meus usuários por meio do aplicativo móvel.

 

Métricas do AWS CloudWatch para o resgate

Se você é novo no CloudWatch Metrics, veja esta ótima série de blogs sobre observabilidade e métricas aqui . Para meu aplicativo, há três métricas principais com as quais os usuários se importam quando carregam imagens:

  • Quantas imagens foram carregadas?

  • Quantos foram processados com sucesso?

  • Que espécies foram identificadas nessas imagens?

Como desenvolvedor, eu posso me importar com esses números no agregado para saber como o sistema está funcionando. No entanto, um usuário individual só se importa com métricas sobre suas imagens. É aí que entra uma dimensão. Uma dimensão é simplesmente metadados anexados a uma métrica que permite que você "fatie e corte" a métrica. No meu caso de uso, atribuo uma dimensão de "ID do rancho" a cada métrica - este é simplesmente um identificador para dizer que esta métrica se aplica ao rancho desta pessoa (um local em um mapa). Como mencionado anteriormente, o Powertools torna isso muito fácil - abaixo está um trecho de código de uma das minhas funções Lambda:


A chave aqui é a dimensão, linha 12 - como você verá mais tarde, isso me permite consultar métricas marcadas com essa dimensão, o que fornece a personalização no nível do usuário. Neste caso, estou criando uma métrica chamada “ImageIngested”, que é o total de imagens ingeridas para essa operação para esse usuário (conforme indicado pela dimensão).

E, finalmente, a Linha 13 é o que cria a métrica e a grava no CloudWatch. Neste caso, a unidade da métrica é “Count”, mas observe que MetricUnit é uma enumeração e pode incluir unidades como “seconds”. O Powertools torna esta linha de código muito mais simples, mais legível e, em última análise, mais sustentável do que se você usasse boto3 .

 

Visão geral de alto nível da solução

Agora que criamos as métricas, vamos rever o processo que impulsiona a criação das métricas e como essas métricas são entregues aos usuários. Abaixo está uma arquitetura de alto nível mostrando como as métricas são criadas, persistidas por CloudWatch Metric Streams e, em seguida, consultados posteriormente para enviar notificações push aos usuários.


Visão geral de alto nível da solução
Visão geral de alto nível da solução

Vamos analisar isso:

Etapa 1: A “função Ingest” adiciona a métrica utilizando o Powertools. E, conforme descrito anteriormente, cada métrica é contextualizada para o usuário adicionando uma dimensão à métrica que é específica para aquele usuário/inquilino, especificamente seu identificador de rancho (ranchid). Abaixo está a notificação push mostrando duas métricas, o número de imagens carregadas e quantas eram imagens válidas.


Notificação móvel do usuário
Notificação móvel do usuário

Etapa 2: o CloudWatch tem um serviço, o CloudWatch Metric Stream , que pode enviar métricas para vários destinos, um dos quais é o Kinesis Firehose.


Etapa 3: o Kinesis Firehose entrega os dados métricos ao S3.


Etapa 4: Um Glue Crawler pode ser configurado para indexar e catalogar os dados métricos (agora no S3) como uma tabela no Glue Catalog. Isso permite que você consulte esses dados de uma função lambda utilizando o Athena. Na verdade, gosto de pensar nisso como um "lago de métricas", porque tenho todas as minhas métricas disponíveis como tabelas em um banco de dados Glue e posso consultar com SQL. Isso permite casos de uso em que posso voltar e analisar a atividade de um cliente ao longo do tempo, o que pode ser usado para conduzir outras campanhas do Amazon Pinpoint .


Etapa 5: Assim que o processo de ingestão noturna for concluído, outra função lambda é executada, consultando a Glue Table, usando o Athena. Essa consulta recupera as métricas mais recentes (as últimas 24 horas) e as divide pela dimensão (ranchid). Isso agora retorna um conjunto de resultados de métricas por dimensão, que pode ser usado para enviar as métricas para cada usuário.


Etapa 6: Após a consulta Athena, a “Função de consulta” envia as notificações push via Pinpoint. A notificação push é um “link profundo” que os leva para a seção relevante do aplicativo, onde eles podem revisar as imagens que carregaram e a qualidade do modelo de reconhecimento de imagem.

 

Retrospectiva: Valeu a pena divulgar métricas aos usuários dessa maneira?

Provavelmente vale a pena discutir por que escolhi utilizar as métricas do CloudWatch dessa forma e o que vejo como prós e contras dessa implementação. Como dito anteriormente, eu queria impulsionar o engajamento com meu aplicativo, e todos sabem que as notificações push são uma ótima ferramenta para fazer isso. Em seguida, eu queria fornecer observabilidade aos usuários desses processos que são essenciais para que eles tenham sucesso com o aplicativo. O CloudWatch Metrics e a implementação de fluxos de métricas pareciam intuitivos para mim porque capturariam todas as estatísticas sobre quando o evento aconteceu, como parte do processo de criação da métrica. Também gostei que as métricas fossem persistidas para que eu pudesse fazer uma análise mais sofisticada posteriormente, conforme a necessidade surgisse.

Os contras da abordagem escolhida é que agora incorri em alguns outros custos, a saber, custos do Glue Crawler, Lambda e Pinpoint, além dos custos do CloudWatch Metric que já estou incorrendo. No final, porém, o valor de ter notificações push e o potencial maior engajamento do cliente superam os contras.

 

Resumo

Espero que este post demonstre como você pode melhorar o engajamento do aplicativo por meio das métricas do CloudWatch. O que isso faz é permitir que você envie métricas para seus clientes/usuários e, assim, impulsione o engajamento com sua plataforma, dando a eles insights profundos sobre os processos em que eles estão carregando milhares de imagens para seu aplicativo. Espero que este post também mostre como é fácil usar métricas ao usar o Powertools. Aproveito todas as oportunidades que posso para dizer às pessoas o quão incrível o Powertools é.

bottom of page