Apresentando novas métricas de mapeamento de origem de eventos (ESM) para o AWS Lambda

Este blog foi escrito por Tarun Rai Madan, gerente de produto principal — Serverless, e Rajesh Kumar Pandey, engenheiro de software principal de Serverless.

Hoje, a AWS está anunciando novas métricas opcionais do Amazon CloudWatch para mapeamentos de fontes de eventos do AWS Lambda que assinam fontes de eventos do Amazon Simple Queue Service (Amazon SQS), Amazon Kinesis e Amazon DynamoDB. Essas métricas incluem PolledEventCount, InvokeDeventCount, FilteredOutEventCount, FailedInvokeEventCount, DeletedEventCount, DroppedEventCount e OnFailureDestinationDeliveredEventCount. As novas métricas permitem que os clientes monitorem o estado de processamento dos eventos lidos pelos mapeamentos de origem de eventos (Event Source Mapping – ESMs) e os ajudam a diagnosticar problemas de processamento.

Anteriormente, os clientes achavam difícil monitorar o estado de processamento dos eventos lidos por um ESM. Um ESM é um recurso que pesquisa eventos de uma fonte e invoca uma função Lambda. Com as novas métricas para ESMs, você pode contar eventos por estado de processamento, o que inclui eventos que foram pesquisados, invocados, filtrados, excluídos, descartados, falhados ou enviados para um destino em caso de falha.

Visão geral

Os clientes que criam aplicativos modernos orientados a eventos usam serviços como SQS, Kinesis e DynamoDB como elementos fundamentais para o desenvolvimento de arquiteturas desacopladas e usam uma função Lambda como consumidor para se beneficiar de sua simplicidade, escalabilidade automática e economia. Para assinar uma fonte de eventos, os clientes configuram um Lambda Event Source Mapping (ESM). Um ESM é um recurso Lambda totalmente gerenciado que executa uma pesquisa de eventos, processa (por exemplo, filtros e lotes) e entrega os eventos a uma função do Lambda. Devido aos processamentos que ocorrem em um ESM, por exemplo, filtragem, agrupamento em lotes e entrega para destinos em caso de falha, os eventos podem terminar em vários estados. Como resultado, alguns eventos pesquisados podem não invocar uma função do Lambda. Anteriormente, a contagem de eventos pesquisados, filtrados, invocados, excluídos ou descartados não era visível para os clientes. Isso tornou difícil para os clientes diagnosticar problemas de processamento com seu ESM, resultantes de permissões defeituosas, configuração incorreta ou erros de função.

O que há de novo

Com o anúncio de hoje, os clientes podem optar pelas métricas do CloudWatch para monitorar o estado de processamento de eventos que são lidos por um ESM configurado com SQS, Kinesis e DynamoDB como fontes de eventos.

A métrica PolledEventCount conta o número de eventos lidos por um ESM a partir da origem do evento.

A métrica InvokedEventCount conta o número de eventos que invocaram sua função do Lambda. Para um evento que apresenta erros de função, essa métrica pode aumentar a contagem várias vezes para o mesmo evento pesquisado, devido a novas tentativas.

A métrica FilteredOutEventCount conta o número de eventos filtrados pelo seu ESM, com base nos critérios de filtro definidos por você.

A métrica FailedInvokeEventCount conta o número de eventos que tentaram invocar uma função Lambda, mas encontraram falha parcial ou total.

A métrica DeletedEventCount conta os eventos que foram excluídos da fila SQS pelo Lambda após o processamento bem-sucedido.

A métrica DroppedEventCount conta o número de eventos descartados devido à expiração do evento ou ao esgotamento das tentativas de repetição, para ESMs do Kinesis e do DynamoDB configurados com MaximumRecordageInSeconds ou MaximumRetryAttempts.

A métrica onFailureDestinationDeliveredEventCount conta os eventos enviados para um destino em caso de falha ao atingir o MaximumRecordageInSeconds ou o MaximumRetryAttempts, para ESMs configurados com DestinationConfig.

Como usar as novas métricas do ESM

Depois que um ESM é criado e atinge o estado ativado, ele pesquisa continuamente a fonte do evento em busca de novos ocorrências. Você pode monitorar a métrica PolledEventCount para detectar problemas com a pesquisa devido à fonte de eventos mal configurada ou excluída, função de execução da função Lambda mal configurada ou excluída, permissões incorretas ou restrições da fonte do evento. Essa métrica geralmente aumenta quando há um aumento no tráfego na origem do evento. Você pode observar a métrica InvokedEventCount para detectar problemas com a função Lambda e se os eventos estão invocando corretamente sua função Lambda. No caso de erros da função Lambda, invokedEventCount pode ser maior do que PolledEventCount devido a novas tentativas. Essa métrica também aumentaria quando houvesse um aumento nos eventos processados por um ESM. Para ESMs com critérios de filtro configurados, você pode monitorar o FilteredOutEventCount para contar eventos que não foram enviados para uma função do Lambda porque foram filtrados de acordo com os critérios de filtro definidos.

Você pode monitorar a métrica FailedInvokeEventCount para observar o número de eventos que falharam no processamento quando o serviço Lambda tentou invocar sua função. As invocações podem falhar devido a problemas de configuração de rede, permissões incorretas, versão ou alias do Lambda excluídos. Se o mapeamento da origem do evento tiver respostas parciais em lote ativadas, essa métrica incluirá qualquer evento com um BatchItemFailures não vazio na resposta. Se todos os eventos em um lote forem processados com sucesso pela sua função do Lambda, o serviço Lambda emitirá um valor 0 para essa métrica. Você pode usar a métrica DeletedEventCount para garantir que os eventos processados tenham sido excluídos com sucesso da sua fila do SQS após serem processados pela função Lambda. Você pode usar a métrica DroppedEventCount para identificar problemas com registros de mensagens pendentes ou regras de expiração de eventos configuradas incorretamente. Você pode usar a métrica OnFailureDestinationDeliveredEventCount para monitorar problemas como eventos com falha causados por erros de invocação da função Lambda.

A classificação das métricas disponíveis do Lambda ESM por fonte do evento é apresentada abaixo:

Ativando e testando as novas métricas do ESM

Você pode habilitar as novas métricas do ESM usando o console do AWS Lambda, a interface da linha de comando (CLI) da AWS, a API do Lambda ESM, o AWS SDK, o AWS CloudFormation e o AWS Serverless Application Model (SAM). As métricas serão publicadas no namespace AWS/Lambda e na dimensão EventSourceMappinGuuid no console do CloudWatch. Para saber mais, consulte as métricas do CloudWatch para AWS Lambda.

Usando o AWS CLI

Para ativar as novas métricas usando o AWS CLI, use o parâmetro —metrics-config.

aws lambda create-event-source-mapping \
    --region <region-name> \
    --function-name <function-name> \
    --event-source-arn <event-source-arn> \
    --metrics-config '{"Metrics": ["EventCount"]}'

Usando o console AWS Lambda

Para ativar as novas métricas usando o console do AWS Lambda, clique em “Ativar métricas” ao adicionar o gatilho para sua função.

Figura 1: Habilitando as métricas do ESM no console da AWS

Um cenário típico em que as novas métricas do ESM podem ajudar a melhorar a observabilidade é um ESM que usa filtragem de eventos. Para testar as métricas do ESM, você pode implantar um aplicativo Lambda de amostra com o Kinesis como fonte de eventos usando esse padrão Serverless, que usa a filtragem de eventos com determinados critérios para controlar quais eventos são enviados para o Lambda. Use esse padrão para os dois cenários de exemplo; siga as diretrizes de configuração desse padrão e continue com os testes dos cenários. A execução desse projeto de exemplo em sua conta pode gerar cobranças. Veja os preços do AWS Lambda e os preços do Amazon Kinesis.

Figura 2: Configurando a função Lambda com a fonte de eventos do Kinesis

Exemplo de cenário 1: métricas do ESM com filtragem de eventos configurada

O diagrama a seguir mostra os resultados do cenário de teste com o Kinesis ESM, em que o total de eventos pesquisados, eventos filtrados, eventos invocados e eventos com falha são representados por PolledEventCount, FilteredOutEventCount, InvokedEventCount e FailedInvokeEventCount.

Figura 3: Métricas de ESM para o cenário 1

Exemplo de cenário 2: métricas do ESM com filtragem de eventos e destino em caso de falha configurados

Outro cenário comum é quando você deseja ter visibilidade sobre o número de eventos entregues à função Lambda, eventos filtrados e, além disso, a contagem de eventos roteados para o destino em caso de falha em caso de falha. Para testar esse cenário, siga uma configuração semelhante à do cenário 1. Crie ou atualize o ESM com um destino em caso de falha e defina maximumRetryCount como 1, conforme mostrado abaixo.

aws lambda update-event-source-mapping \
    --uuid <event-source-mapping-uuid> \
    --maximum-retry-attempts 1 \
    --filter-criteria '{"Filters": [{"Pattern": "{\"data\": { \"tire_pressure\": [ { \"numeric\": [ \"<\", 32 ] } ] } }"}]}' \
    --destination-config '{"OnFailure": {"Destination": "<your_SQS_queue_ARN>"}}' \
    --function-name <lambda-function-name>

Publique um exemplo de carga que corresponda aos critérios de filtro definidos acima. Também gere dados de exemplo com diferentes “tire_pressure” < 32 para corresponder ao evento e invocar a função Lambda.

Dados da amostra:

{
    "time": "2021-11-09 13:32:04",
    "fleet_id": "fleet-452",
    "vehicle_id": "a42bb15c-43eb-11ec-81d3-0242ac130003",
    "lat": 47.616226213162406,
    "lon": -122.33989110734133,
    "speed": 43,
    "odometer": 43519,
    "tire_pressure": [41, 40, 31, 41],
    "weather_temp": 76,
    "weather_pressure": 1013,
    "weather_humidity": 66,
    "weather_wind_speed": 8,
    "weather_wind_dir": "ne"
}

Depois de publicar esses registros no stream, você poderá ver as métricas do CloudWatch no namespace AWS/Lambda com a dimensão EventSourceMappinGuid, conforme mostrado abaixo. Observe que, se um evento apresentar um erro de função, invokedEventCount poderá aumentar várias vezes para o mesmo evento pesquisado devido a novas tentativas automáticas.

Figura 4: Métricas de ESM para o cenário 2

Disponível agora

As novas métricas do ESM geralmente estão disponíveis em todas as regiões comerciais nas quais o serviço Lambda está disponível. O suporte também está disponível por meio de parceiros do AWS Lambda, como Datadog, Elastic e Lumigo. O serviço Lambda envia essas novas métricas para o CloudWatch sem nenhum custo adicional para você. No entanto, cobranças se aplicam às métricas do CloudWatch de acordo com os preços padrão do CloudWatch para essas métricas opcionais, além dos preços do AWS Lambda  e da fonte do evento.

Conclusão

Com essas novas métricas do CloudWatch, você pode obter visibilidade do estado de processamento de seus eventos que são pesquisados pelo Lambda Event Source Mapping (ESM) para aplicativos baseados em filas ou fluxos. O blog explica as novas métricas PolledEventCount, InvokeDeventCount, FilteredOutEventCount, FailedInvokeEventCount, DeletedEventCount, DroppedEventCount e OnFailureDestinationDeliveredEventCount e como usá-las para solucionar problemas de processamento de eventos para funções Lambda. Essas métricas ajudam você a rastrear as solicitações de invocação enviadas ao Lambda por meio de um ESM, monitorar quaisquer atrasos ou problemas no processamento e tomar ações corretivas, se necessário. Para saber mais sobre essas métricas, visite o guia do desenvolvedor do Lambda.

Para obter mais recursos de aprendizado sem servidor, visite Serverless Land.

Este blog é uma tradução do conteúdo original em inglês (link aqui).

Biografia do autor

Tarun Rai Madané um Principal Solution Architect na Amazon Web Services (AWS).

Biografia do tradutor

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem.

Biografia do Revisor

Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiencia, com ampla experiencia em arquitetura cloud, engenharia e design de software. Atualmente está habilitando empresas do ramo de ISV (Independent Software Vendors) simplificando a operação na nuvem e otimizando os custos em cloud. Sua area de interesse são tecnologias serverless.