# Solucionar problemas de mapeamento de origens de eventos no Lambda
<a name="troubleshooting-event-source-mapping"></a>

Problemas no Lambda relacionados a um [mapeamento de origem de evento](invocation-eventsourcemapping.md) podem ser mais complexos, pois envolvem depuração em vários serviços. Além disso, o comportamento da origem do evento pode ser diferente com base na origem do evento exata utilizada. Esta seção lista problemas comuns que envolvem mapeamentos de origens de eventos e fornece orientação sobre como identificá-los e solucioná-los.

**nota**  
Ela usa uma origem de eventos do Amazon SQS como ilustração, mas os princípios se aplicam a outros mapeamentos de origens de eventos que enfileiram mensagens para funções do Lambda.

## Identificação e gerenciamento do controle de utilização
<a name="esm-throttling"></a>

No Lambda, o controle de utilização ocorre quando você atinge o limite de concorrência da sua função ou conta. Considere o exemplo abaixo, em que uma função do Lambda lê mensagens de uma fila do Amazon SQS. Essa função do Lambda simula invocações de 30 segundos e tem um tamanho de lote de 1. Isso significa que ela processa apenas 1 mensagem a cada 30 segundos:

```
const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))

exports.handler = async (event) => {
    await doWork(30000)

}
```

Com um tempo de invocação tão longo, as mensagens começam a chegar na fila com mais rapidez do que são processadas. Se a simultaneidade não reservada da sua conta for 100, o Lambda escalará até 100 execuções simultâneas e, em seguida, ocorrerá o controle de utilização. Você pode conferir esse padrão nas métricas do CloudWatch para a função:

![\[operações de depuração figura 10\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-10.png)


As métricas do CloudWatch para a função não mostram erros, mas o gráfico **Execuções simultâneas** mostra que a simultaneidade máxima de 100 foi atingida. Como resultado, o gráfico **Controle de utilização** mostra o controle de utilização em vigor.

Você pode detectar o controle de utilização com alarmes do CloudWatch e configurando um alarme sempre que a métrica de controle de utilização de uma função for maior que 0. Depois de identificar o problema de controle de utilização, você tem algumas opções de resolução:
+ Solicite um aumento de simultaneidade ao AWS Support nesta região.
+ Identifique problemas de performance na função para aumentar a velocidade de processamento e, portanto, melhorar o throughput.
+ Aumentar o tamanho do lote da função, para que mais mensagens sejam processadas por cada invocação.

## Erros na função de processamento
<a name="esm-processing-function"></a>

Se a função de processamento gerar erros, o Lambda retornará as mensagens para a fila do SQS. O Lambda impede que sua função seja escalada para evitar erros em grande escala. As métricas a seguir do SQS no CloudWatch indicam um problema com o processamento de filas:

![\[operações de depuração figura 11\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-11.png)


Em particular, tanto a idade da mensagem mais antiga quanto o número de mensagens visíveis estão aumentando, enquanto nenhuma mensagem é excluída. A fila continua crescendo, mas as mensagens não estão sendo processadas. As métricas do CloudWatch para a função do Lambda de processamento também indicam que há um problema:

![\[operações de depuração figura 12\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-12.png)


A métrica **Contagem de erros** é diferente de zero e está aumentando, enquanto o valor de **Execuções simultâneas** reduziu e o controle de utilização foi interrompido. Isso mostra que o Lambda parou de escalar sua função devido a erros. Os logs do CloudWatch da função fornecem detalhes do tipo de erro.

Você pode resolver esse problema identificando a função que está causando o erro e, em seguida, localizando e resolvendo o erro. Depois que você corrigir o erro e implantar o novo código da função, as métricas do CloudWatch deverão mostrar a recuperação do processamento:

![\[operações de depuração figura 13\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/debugging-ops-figure-13.png)


Aqui, o valor da métrica **Contagem de erros** cai para zero e o valor da métrica **Taxa de sucesso** retorna a 100%. O Lambda começa a escalar a função novamente, conforme mostrado no gráfico **Execuções simultâneas**.

## Identificação e tratamento de contrapressão
<a name="esm-backpressure"></a>

Se um produtor de eventos gerar consistentemente mensagens para uma fila do SQS mais rápido do que uma função do Lambda é capaz de processá-las, ocorre uma contrapressão. Nesse caso, o monitoramento do SQS deve mostrar a idade da mensagem mais antiga crescendo linearmente, juntamente com o número aproximado de mensagens visíveis. Você pode detectar contrapressão nas filas usando os alarmes do CloudWatch.

As etapas para resolver a contrapressão dependem da sua workload. Se o objetivo principal for aumentar a capacidade de processamento e o throughput por meio da função do Lambda, existem algumas opções:
+ Solicite um aumento de simultaneidade ao AWS Support na região específica.
+ Aumentar o tamanho do lote da função, para que mais mensagens sejam processadas por cada invocação.