# Monitoramento, depuração e solução de problemas das funções do Lambda
O AWS Lambda pode ser integrado a outros Serviços da AWS para ajudar você a monitorar e solucionar problemas de suas funções do Lambda. O Lambda monitora automaticamente as funções do Lambda em seu nome e gera relatórios sobre métricas por meio do Amazon CloudWatch. Para ajudar você a monitorar seu código quando ele estiver sendo executado, o Lambda rastreia automaticamente o número de solicitações, a duração de chamadas por solicitação e o número de solicitações que resultam em erro.
Você pode usar outros Serviços da AWS para solucionar problemas de suas funções do Lambda. Esta seção descreve como usar esses Serviços da AWS para monitorar, rastrear, depurar e solucionar problemas de suas aplicações e funções do Lambda. Para obter detalhes sobre o registro em log de funções e erros em cada runtime, consulte as seções individuais de runtime.
**Topics**
+ [Preços](#monitoring-console-metrics-pricing)
+ [Uso de métricas do CloudWatch com o Lambda](monitoring-metrics.md)
+ [Trabalhar com logs de função do Lambda](monitoring-logs.md)
+ [Registrar chamadas à API do AWS Lambda usando o AWS CloudTrail](logging-using-cloudtrail.md)
+ [Visualizar as invocações da função do Lambda usando o AWS X-Ray](services-xray.md)
+ [Monitorar a performance de funções com o Lambda Insights do Amazon CloudWatch](monitoring-insights.md)
+ [Monitorar aplicações do Lambda](applications-console-monitoring.md)
+ [Monitoramento da performance de aplicações com o Amazon CloudWatch Application Signals](monitoring-application-signals.md)
+ [Depure remotamente as funções do Lambda com o Visual Studio Code](debugging.md)
## Preços
O CloudWatch tem um nível gratuito vitalício. Além do limite do nível gratuito, o CloudWatch cobra por métricas, painéis, alarmes, logs e insights. Para obter mais informações, consulte [Preço do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
# Uso de métricas do CloudWatch com o Lambda
Quando a função do AWS Lambda termina o processamento de um evento, o Lambda automaticamente envia métricas sobre a invocação para o Amazon CloudWatch. Você não precisa conceder nenhuma permissão adicional ao seu perfil de execução para receber métricas de função, e não há cobrança adicional por essas métricas.
Há muitos tipos de métricas associadas às funções do Lambda. Isso inclui métricas de invocação, métricas de performance, métricas de simultaneidade, métricas de invocação assíncrona e métricas de mapeamento da origem de eventos. Para ter mais informações, consulte [Tipos de métricas para funções do Lambda](monitoring-metrics-types.md).
No console do CloudWatch, você pode [exibir essas métricas](monitoring-metrics-view.md) e criar gráficos e painéis com elas. Também é possível definir alarmes para responder a alterações na utilização, na performance ou nas taxas de erro. O Lambda envia dados de métricas ao CloudWatch em intervalos de um minuto. Para obter um insight mais imediato de sua função do Lambda, você pode criar [métricas personalizadas em alta resolução](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html). Aplicam-se cobranças para métricas personalizadas e alarmes do CloudWatch. Para obter mais informações, consulte [Preços do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
# Exibição de métricas de funções do Lambda
Use o console do CloudWatch para exibir métricas das suas funções do Lambda. No console, você pode filtrar e classificar as métricas de funções por nome, alias, versão ou UUID do mapeamento da origem do evento.
**Para exibir métricas no console do CloudWatch**
1. Abra a [página Metrics](https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~();namespace=~'AWS*2fLambda) (Métricas) (namespace `AWS/Lambda`) no console do CloudWatch.
1. Na guia **Procurar**, em **Métricas**, escolha qualquer uma das seguintes dimensões:
+ **Por nome da função** (`FunctionName`): visualize métricas agregadas para todas as versões e aliases de uma função.
+ **Por recurso** (`Resource`): visualize métricas para uma versão ou um alias de uma função.
+ **Por versão executada** (`ExecutedVersion`): visualize métricas para uma combinação de alias e versão. Use a dimensão `ExecutedVersion` para comparar taxas de erro para duas versões de uma função que são ambas destinos de um [alias ponderado](configuration-aliases.md).
+ **Por UUID do mapeamento da origem de eventos** (`EventSourceMappingUUID`): visualize métricas para um mapeamento da origem de eventos.
+ **Em todas as funções** (nenhum): visualize métricas agregadas para todas as funções na Região da AWS atual.
1. Escolha a métrica. A métrica deve aparecer automaticamente no gráfico visual, bem como na guia **Métricas em gráficos**.
Por padrão, os gráficos usam a estatística `Sum` para todas as métricas. Para escolher uma estatística diferente e personalizar o gráfico, use as opções na guia **Graphed metrics (Métricas no gráfico)**.
**nota**
O timestamp em uma métrica reflete quando a função foi invocada. Dependendo da duração da invocação, isso pode representar vários minutos até a métrica ser emitida. Se, por exemplo, a função tiver um tempo limite de dez minutos, para obter métricas precisas, procure mais de dez minutos no passado.
Para obter mais informações sobre o CloudWatch, consulte o [Guia do usuário do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
# Tipos de métricas para funções do Lambda
Esta seção descreve os tipos de métricas do Lambda disponíveis no console do CloudWatch.
**Topics**
+ [Métricas de invocação](#invocation-metrics)
+ [Métricas de implantação](#deployment-metrics)
+ [Métricas de performance](#performance-metrics)
+ [Métricas de simultaneidade](#concurrency-metrics)
+ [Métricas de invocação assíncrona](#async-invocation-metrics)
+ [Métricas de mapeamento da origem do evento](#event-source-mapping-metrics)
## Métricas de invocação
As métricas de invocação são indicadores binários do resultado de uma invocação da função do Lambda. Confira essas métricas com a estatística `Sum`. Por exemplo, se a função retornar um erro, o Lambda enviará a métrica `Errors` com um valor de 1. Para obter uma contagem do número de erros de função que ocorrem a cada minuto, visualize o `Sum` da métrica `Errors` com o período de 1 minuto.
+ `Invocations`: o número de vezes em que o código da sua função foi chamado, incluindo invocações bem-sucedidas e invocações que resultem em um erro de função. As invocações não serão registradas se a solicitação de invocação tiver controle de utilização ou se resultar em erro de invocação. O valor de `Invocations` é igual ao número de solicitações faturadas.
+ `Errors`: o número de invocações que resultam em um erro de função. Os erros de função incluem exceções emitidas pelo código e exceções emitidas pelo runtime do Lambda. O runtime retorna um erro para problemas como tempos limite e erros de configuração. Para calcular a taxa de erro, divida o valor de `Errors` pelo valor de `Invocations`. Observe que o timestamp em uma métrica de erro reflete quando a função foi chamada, não quando o erro ocorreu.
+ `DeadLetterErrors`: para a [invocação assíncrona](invocation-async.md), o número de vezes em que o Lambda tenta enviar um evento para uma fila de mensagens não entregues (DLQ), mas falha. Os erros de mensagens não entregues podem ocorrer devido a recursos configurados incorretamente ou limites de tamanho.
+ `DestinationDeliveryFailures`: para invocação assíncrona e [mapeamentos da origem do evento](https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html) compatíveis, o número de vezes em que o Lambda tenta enviar um evento a um [destino](invocation-async-retain-records.md#invocation-async-destinations), mas falha. Para mapeamentos da origem do evento, o Lambda oferece suporte a origens de fluxo (DynamoDB e Kinesis). Os erros de entrega podem ocorrer devido a erros de permissão, recursos configurados incorretamente ou limites de tamanho. Os erros também podem acontecer se o destino que você configurou incluir um tipo incompatível, como uma fila do Amazon SQS FIFO ou um tópico do Amazon SNS FIFO.
+ `Throttles`: o número de solicitações de invocação que são limitadas. Quando todas as instâncias da função estão processando solicitações e nenhuma simultaneidade está disponível para aumento de escala vertical, o Lambda rejeita solicitações adicionais com um erro `TooManyRequestsException`. As solicitações limitadas e outros erros de invocação não contam como `Invocations` ou `Errors`.
**nota**
Com as [Instâncias gerenciadas do Lambda](lambda-managed-instances.md), o Lambda fornece métricas granulares de aceleração que identificam a restrição específica que causa a aceleração. Quando ocorre um controle de utilização no ambiente de execução, exatamente uma das seguintes submétricas é emitida com o valor 1, enquanto as três restantes são emitidas com o valor 0. A métrica `Throttles` é sempre emitida junto com essas submétricas.
`CPUThrottles`: invocações limitadas devido à exaustão da CPU no ambiente de execução.
`MemoryThrottles`: invocações limitadas devido à exaustão da memória no ambiente de execução.
`DiskThrottles`: invocações limitadas devido à exaustão do disco no ambiente de execução.
`ConcurrencyThrottles`: invocações limitadas quando o limite de simultaneidade do ambiente de execução é atingido.
+ `OversizedRecordCount`: para origens de eventos do Amazon DocumentDB, o número de eventos que sua função recebe do stream de alterações com mais de 6 MB de tamanho. O Lambda descarta a mensagem e emite essa métrica.
+ `ProvisionedConcurrencyInvocations`: o número de vezes em que o código da sua função é invocado em [simultaneidade provisionada](provisioned-concurrency.md).
+ `ProvisionedConcurrencySpilloverInvocations`: o número de vezes em que o código da sua função é invocado usando a simultaneidade padrão quando toda a simultaneidade provisionada está em uso.
+ `RecursiveInvocationsDropped`: o número de vezes em que o Lambda interrompeu a invocação da função porque detectou que ela faz parte de um loop recursivo infinito. A detecção de loop recursivo monitora quantas vezes uma função é invocada como parte de uma cadeia de solicitações rastreando os metadados adicionados pelos AWS SDKs compatíveis. Por padrão, se a função for invocada aproximadamente 16 vezes como parte de uma cadeia de solicitações, o Lambda descartará a próxima invocação. Se você desativar a detecção de loop recursivo, essa métrica não será emitida. Para ter mais informações sobre esse recurso, consulte [Usar a detecção de loop recursivo do Lambda para evitar loops infinitos](invocation-recursion.md).
## Métricas de implantação
As métricas de implantação fornecem informações sobre eventos de implantação da função do Lambda e processos de validação relacionados.
+ `SignatureValidationErrors`: o número de vezes que uma implantação de pacote de código ocorreu com falhas de validação de assinatura quando a política de configuração de assinatura de código está definida como `Warn`. Essa métrica é emitida quando as verificações de expiração, incompatibilidade ou revogação falham, mas a implantação ainda é permitida devido à configuração da política de `Warn`. Para obter mais informações sobre assinatura de código, consulte [Usar a assinatura de código para verificar integridade de código com o Lambda](configuration-codesigning.md).
## Métricas de performance
As métricas de performance fornecem detalhes de performance sobre uma única invocação de função. Por exemplo, a métrica `Duration` indica a quantidade de tempo, em milissegundos, que a função gasta processando um evento. Para ter uma ideia da velocidade de processamento de eventos da função, visualize essas métricas com a estatística `Average` ou `Max`.
+ `Duration`: quantidade de tempo que o código da função gasta processando um evento. A duração faturada de uma invocação é o valor da `Duration` arredondado para o milissegundo mais próximo. A `Duration` não inclui o tempo de inícialização a frio.
+ `PostRuntimeExtensionsDuration`: a quantidade cumulativa de tempo que o runtime gasta executando o código para extensões após a conclusão do código de função.
+ `IteratorAge`: para origens de eventos do DynamoDB, Kinesis e Amazon DocumentDB, a data do último registro no evento em milissegundos. Essa métrica mede o tempo transcorrido entre quando um stream recebe o registro e quando o mapeamento da origem do evento envia o evento à função.
+ `OffsetLag`: para origens de eventos do Apache Kafka autogerenciado e do Amazon Managed Streaming for Apache Kafka (Amazon MSK), a diferença de deslocamento entre o último registro gravado em um tópico e o último registro que o grupo de consumidores da sua função processou. Embora um tópico do Kafka possa ter várias partições, essa métrica mensura o atraso de deslocamento no nível do tópico.
`Duration` também é compatível com estatísticas de percentil (`p`). Use os percentis para excluir valores discrepantes que distorcem estatísticas `Average` e `Maximum`. Por exemplo, a estatística `p95` mostra a duração máxima de 95% das invocações, excluindo as 5% mais lentas. Para obter mais informações, consulte [Percentis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Percentiles) no *Guia do usuário do Amazon CloudWatch*.
## Métricas de simultaneidade
O Lambda relata métricas de simultaneidade como uma contagem agregada do número de instâncias que estão processando eventos em uma função, uma versão, um alias ou uma Região da AWS. Para ver se você está próximo de atingir os [limites de simultaneidade](lambda-concurrency.md#concurrency-quotas), visualize essas métricas com a estatística `Max`.
+ `ConcurrentExecutions`: o número de instâncias da função que estão processando eventos. Se esse número atingir a [cota de execuções simultâneas](gettingstarted-limits.md#compute-and-storage) para a região ou o limite de [simultaneidade reservada](configuration-concurrency.md) na função, o Lambda controlará a utilização de solicitações de invocação adicionais.
+ `ProvisionedConcurrentExecutions`: o número de instâncias da função que estão processando eventos usando a [simultaneidade provisionada](provisioned-concurrency.md). Para cada invocação de um alias ou versão com simultaneidade provisionada, o Lambda emite a contagem atual. Se sua função estiver inativa ou não estiver recebendo solicitações, o Lambda não emitirá essa métrica.
+ `ProvisionedConcurrencyUtilization`: para uma versão ou um alias, o valor de `ProvisionedConcurrentExecutions` dividido pela quantidade total de simultaneidade provisionada configurada. Por exemplo, se você configurar uma simultaneidade provisionada de 10 para sua função e seu `ProvisionedConcurrentExecutions` for 7, seu `ProvisionedConcurrencyUtilization` será 0,7.
Se sua função estiver inativa ou não estiver recebendo solicitações, o Lambda não emitirá essa métrica porque ela se baseia em `ProvisionedConcurrentExecutions`. Lembre-se disso se você usa `ProvisionedConcurrencyUtilization` como base para os alarmes do CloudWatch.
+ `UnreservedConcurrentExecutions`: para uma região, o número de eventos que estão sendo processados por funções que não tenham simultaneidade reservada.
+ `ClaimedAccountConcurrency`: para uma região, quantidade de simultaneidade que não está disponível para invocações sob demanda. `ClaimedAccountConcurrency` é igual a `UnreservedConcurrentExecutions` mais a quantidade de simultaneidade alocada (ou seja, a simultaneidade total reservada mais a simultaneidade total provisionada). Para obter mais informações, consulte [Trabalhar com a métrica `ClaimedAccountConcurrency`](monitoring-concurrency.md#claimed-account-concurrency).
## Métricas de invocação assíncrona
As métricas de invocação assíncrona fornecem detalhes sobre invocações assíncronas de fontes de eventos e invocações diretas. Você pode definir limites e alarmes para notificá-lo sobre determinadas alterações. Por exemplo, quando há um aumento indesejado no número de eventos enfileirados para processamento (`AsyncEventsReceived`). Ou quando um evento está esperando há muito tempo para ser processado (`AsyncEventAge`).
+ `AsyncEventsReceived`: o número de eventos que o Lambda enfileira com sucesso para processamento. Esta métrica fornece informações sobre o número de eventos que uma função do Lambda recebe. Monitore essa métrica e defina alarmes de limites para verificar problemas. Por exemplo, para detectar um número indesejável de eventos enviados ao Lambda e diagnosticar rapidamente problemas resultantes de configurações incorretas de gatilhos ou funções. As incompatibilidades entre os `AsyncEventsReceived` e as `Invocations` podem indicar uma disparidade no processamento, a eliminação de eventos ou um possível backlog na fila.
+ `AsyncEventAge`: o tempo entre o momento em que o Lambda enfileira com sucesso o evento e o momento em que a função é invocada. O valor dessa métrica aumenta quando os eventos estão sendo repetidos devido a falhas de invocação ou no controle de utilização. Monitore esta métrica e defina alarmes para limites em estatísticas diferentes para quando ocorrer um acúmulo de fila. Para solucionar um aumento nessa métrica, examine a métrica `Errors` para identificar erros de função e a métrica `Throttles` para identificar problemas de simultaneidade.
+ `AsyncEventsDropped`: o número de eventos que são eliminados sem executar a função com êxito. Se você configurar uma fila de mensagens não entregues (DLQ) ou um destino `OnFailure`, os eventos serão enviados para lá antes de serem descartados. Os eventos são encerrados por vários motivos. Por exemplo, os eventos podem exceder a idade máxima do evento, esgotar o máximo de tentativas ou a simultaneidade reservada pode ser definida como 0. Para entender por que os eventos são encerrados, confira a métrica `Errors` para identificar erros de função e a métrica `Throttles` para identificar problemas de simultaneidade.
## Métricas de mapeamento da origem do evento
As métricas de mapeamento da origem de eventos fornecem informações sobre o comportamento de processamento do seu mapeamento da origem de eventos.
Atualmente, as métricas de mapeamento da origem do evento estão disponíveis para origens de eventos do Amazon SQS, Kinesis, DynamoDB, Amazon MSK e Apache Kafka autogerenciado.
Para fazer o mapeamento da origem do evento com a configuração de métricas, você também pode verificar todas as métricas relacionadas ao ESM na guia **Monitor** da página Console **Lambda** > **Recursos adicionais** > **mapeamentos da origem do evento** agora.
**Para habilitar as métricas ou um mapeamento da origem do evento (console)**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha a função para a qual você deseja habilitar métricas.
1. Escolha **Configuração** e, em seguida, escolha **Acionadores**.
1. Escolha o mapeamento da origem do evento para o qual você deseja habilitar as métricas e, em seguida, escolha **Editar**.
1. Em **Configuração do mapeamento da origem do evento**, escolha **Ativar métricas** ou selecione na lista suspensa **Métricas**.
1. Escolha **Salvar**.
Como alternativa, você pode habilitar as métricas para o mapeamento da origem do evento de forma programática usando o objeto [EventSourceMappingMetricsConfig](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingMetricsConfig.html) em [EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html). Por exemplo, o comando da CLI [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) a seguir habilita as métricas para um mapeamento da origem de eventos:
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--metrics-config Metrics=EventCount
```
Há três grupos de métricas: `EventCount`, `ErrorCount` e `KafkaMetrics`, e cada grupo tem várias métricas. Nem toda métrica está disponível para cada origem de evento. A tabela a seguir resume as métricas compatíveis para cada tipo de origem de evento.
Você deve optar pelo grupo de métricas para receber métricas relacionadas. Por exemplo, defina EventCount na configuração de métricas para ter: (`PolledEventCount`, `FilteredOutEventCount`, `InvokedEventCount`, `FailedInvokeEventCount`, `DroppedEventCount`, `OnFailureDestinationDeliveredEventCount` e `DeletedEventCount`).
| Métrica do mapeamento da origem de eventos | Grupo de métricas | Amazon SQS | Fluxos do Kinesis e do DynamoDB | Amazon MSK e Apache Kafka autogerenciado |
| --- | --- | --- | --- | --- |
| `PolledEventCount` | `EventCount` | Sim | Sim | Sim |
| `FilteredOutEventCount` | `EventCount` | Sim | Sim | Sim |
| `InvokedEventCount` | `EventCount` | Sim | Sim | Sim |
| `FailedInvokeEventCount` | `EventCount` | Sim | Sim | Sim |
| `DroppedEventCount` | `EventCount` | Não | Sim | Sim |
| `OnFailureDestinationDeliveredEventCount` | `EventCount` | Não | Sim | Sim |
| `DeletedEventCount` | `EventCount` | Sim | Não | Não |
| `CommittedEventCount` | `EventCount` | Não | Não | Sim |
| `PollingErrorCount` | `ErrorCount` | Não | Não | Sim |
| `InvokeErrorCount` | `ErrorCount` | Não | Não | Sim |
| `OnFailureDestinationDeliveryErrorCount` | `ErrorCount` | Não | Não | Sim |
| `SchemaRegistryErrorCount` | `ErrorCount` | Não | Não | Sim |
| `CommitErrorCount` | `ErrorCount` | Não | Não | Sim |
| `MaxOffsetLag` | `KafkaMetrics` | Não | Não | Sim |
| `SumOffsetLag` | `KafkaMetrics` | Não | Não | Sim |
Além disso, se o mapeamento da origem de eventos estiver no [modo provisionado](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), o Lambda fornecerá a seguinte métrica:
+ `ProvisionedPollers`: para mapeamentos de origem de eventos no modo provisionado, o número de pesquisadores de eventos que estão sendo executados ativamente. Confira essa métrica usando a matemática `MAX`.
+ (Somente origens de evento do Amazon MSK e Apache Kafka autogerenciado)`EventPollerUnit`: para mapeamentos de origem de eventos no modo provisionado, o número de unidades de agentes de sondagem de eventos que estão sendo executados ativamente. Confira essa métrica usando a matemática `SUM`.
+ (Origens de eventos do Amazon MSK e Apache Kafka autogerenciado) `EventPollerThroughputInBytes`: para mapeamentos de origens de eventos no modo provisionado, o tamanho total do registro dos agentes de sondagem de eventos consultados na origem do evento. Pode informar o throughput atual da pesquisa. Confira essa métrica usando a matemática `SUM`.
Aqui estão mais detalhes sobre cada métrica:
+ `PolledEventCount`: o número de eventos que o Lambda lê com sucesso na origem do evento. Se o Lambda pesquisar eventos, mas receber uma pesquisa vazia (sem novos registros), o Lambda emitirá um valor de 0 para essa métrica. Use essa métrica para detectar se o mapeamento da origem do evento está pesquisando corretamente novos eventos.
+ `FilteredOutEventCount`: para o mapeamento da origem do evento com um [critério de filtro](invocation-eventfiltering.md), o número de eventos filtrados por esse critério de filtro. Use essa métrica para detectar se o mapeamento da origem do evento está filtrando os eventos corretamente. Para eventos que correspondem aos critérios do filtro, o Lambda emite uma métrica de 0.
+ `InvokedEventCount`: o número de eventos que invocaram sua função do Lambda. Use essa métrica para verificar se os eventos estão invocando sua função corretamente. Se um evento resultar em um erro de função ou de controle de utilização, `InvokedEventCount` pode contar várias vezes para o mesmo evento pesquisado devido a novas tentativas automáticas.
**Atenção**
Os mapeamentos da origem do evento do Lambda processam cada evento ao menos uma vez, podendo haver o processamento duplicado de registros. Por esse motivo, os eventos podem ser contados várias vezes em métricas que envolvem contagens de eventos.
+ `FailedInvokeEventCount`: o número de eventos com os quais o Lambda tentou invocar sua função, mas falhou. As invocações podem falhar por motivos como problemas de configuração de rede, permissões incorretas ou a exclusão de uma versão, alias ou função do Lambda. Se o mapeamento da origem do evento tiver [respostas parciais em lote](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) habilitadas, `FailedInvokeEventCount` inclui qualquer evento com um valor não vazio para `BatchItemFailures` na resposta.
**nota**
O carimbo de data/hora da métrica `FailedInvokeEventCount`representa o fim da invocação da função. Esse comportamento difere de outras métricas de erro de invocação do Lambda, que são registradas com um carimbo de data/hora no início da invocação da função.
+ `DroppedEventCount`: o número de eventos que o Lambda eliminou devido à exaustão por expiração ou por nova tentativa. Especificamente, esse é o número de registros que excedem seus valores configurados para `MaximumRecordAgeInSeconds` ou `MaximumRetryAttempts`. É importante ressaltar que isso não inclui o número de registros que expiram por excederem as configurações de retenção da origem do evento. Os eventos descartados também excluem os eventos que você envia para um [destino em caso de falha](invocation-async-retain-records.md). Use essa métrica para detectar um backlog crescente de eventos.
+ `OnFailureDestinationDeliveredEventCount`: para mapeamentos de origem de eventos com um [destino em caso de falha](invocation-async-retain-records.md) configurado, o número de eventos enviados para esse destino. Use essa métrica para monitorar erros de função relacionados a invocações dessa origem de eventos. Se a entrega para o destino falhar, o Lambda trata as métricas da seguinte forma:
+ O Lambda não emite a métrica `OnFailureDestinationDeliveredEventCount`.
+ Para a métrica `DestinationDeliveryFailures`, o Lambda emite o valor 1.
+ Para a métrica `DroppedEventCount`, o Lambda emite um número igual ao número de eventos que falharam na entrega.
+ `DeletedEventCount`: o número de eventos que o Lambda exclui com sucesso após o processamento. Se o Lambda tentar excluir um evento, mas falhar, o Lambda vai emitir uma métrica de 0. Use essa métrica para garantir que os eventos processados com sucesso sejam excluídos da sua origem de eventos.
+ `CommittedEventCount`: o número de eventos que o Lambda confirma com sucesso após o processamento. É uma soma dos deltas do último deslocamento confirmado e do atual de cada partição no mapeamento da origem do evento do Kafka.
+ `PollingErrorCount`: o número de erros em que o Lambda não conseguiu pesquisar solicitações da origem do evento. O Lambda só emite esses dados métricos quando ocorre um erro.
+ `InvokeErrorCount`: o número de erros em que o Lambda não conseguiu invocar sua função. Observe que a invocação é composta por registros em lote. O número está no nível do lote, não no nível da contagem de registros. O Lambda só emite esses dados métricos quando ocorre um erro.
+ `SchemaRegistryErrorCount`: o número de erros em que o Lambda não conseguiu buscar o esquema ou desserializar com o esquema. O Lambda só emite esses dados métricos quando ocorre um erro.
+ `CommitErrorCount`: o número de erros em que o Lambda não conseguiu fazer a confirmação no cluster Kafka. O Lambda só emite esses dados métricos quando ocorre um erro.
+ `MaxOffsetLag`: o máximo de atrasos de deslocamento (diferença entre os deslocamentos mais recentes e confirmados) em todas as partições no mapeamento da origem do evento.
+ `SumOffsetLag`: a soma dos atrasos do deslocamento em todas as partições no mapeamento da origem do evento.
Se o mapeamento da origem de eventos estiver desabilitado, você não receberá métricas de mapeamento da origem de eventos. Você também pode observar a ausência de métricas se o CloudWatch ou o Lambda estiver com disponibilidade reduzida.
# Trabalhar com logs de função do Lambda
Para ajudar a solucionar falhas, o AWS Lambda monitora automaticamente as funções do Lambda em seu nome. É possível visualizar os logs de funções do Lambda usando o console do Lambda, o console do CloudWatch, a AWS Command Line Interface (AWS CLI) ou a API do CloudWatch. Também é possível configurar o Lambda para enviar logs para o Amazon S3 e o Firehose.
Desde que o [perfil de execução](lambda-intro-execution-role.md) da função tenha as permissões necessárias, o Lambda captura logs de todas as solicitações tratadas pela função e os envia para o Amazon CloudWatch Logs, que é o destino padrão. Também é possível usar o console do Lambda para configurar o Amazon S3 ou o Firehose como destinos de registro em log.
+ O **CloudWatch Logs** é o destino padrão de registro em log para as funções do Lambda. O CloudWatch Logs fornece recursos de visualização e análise de logs em tempo real, com possibilidade de criar métricas e alarmes com base nos dados de log.
+ O **Amazon S3** é econômico para armazenamento de longo prazo, e serviços como o Athena podem ser usados para analisar os logs. A latência geralmente é maior.
+ O **Firehose** oferece streaming de logs gerenciado para vários destinos. Se você precisar enviar logs para outros serviços da AWS(por exemplo, OpenSearch Service ou Redshift Data API) ou para plataformas de terceiros (como Datadog, New Relic ou Splunk), o Firehose simplificará esse processo fornecendo integrações pré-compiladas. Também é possível fazer streaming para endpoints HTTP personalizados sem configurar infraestrutura adicional.
## Escolher um destino de serviço para o qual enviar os logs
Considere os seguintes fatores-chave ao escolher um serviço como destino para logs de função:
+ **O gerenciamento de custos varia de acordo com o serviço.** Normalmente, o Amazon S3 fornece a opção mais econômica para armazenamento de longo prazo, enquanto o CloudWatch Logs permite que você visualize e processe os logs, e configure alertas em tempo real. Os custos do Firehose incluem o serviço de streaming e o custo associado com o destino para o qual você o configura para transmitir.
+ **Os recursos de análise diferem entre os serviços.** O CloudWatch Logs é o melhor em monitoramento em tempo real e se integra nativamente com outros recursos do CloudWatch, como o Logs Insights e o Live Tail. O Amazon S3 funciona bem com ferramentas de análise como o Athena e pode se integrar a vários serviços, embora isso possa exigir configuração adicional. O Firehose simplifica o streaming direto para serviços específicos da AWS (como OpenSearch Service e Redshift Data API) e plataformas de terceiros compatíveis (como Datadog e Splunk) fornecendo integrações pré-compiladas, podendo reduzir o trabalho de configuração.
+ **A configuração e a facilidade de uso variam de acordo com o serviço.** O CloudWatch Logs é o destino padrão de logs. Ele funciona imediatamente, sem configuração adicional, e proporciona fácil visualização e análise dos logs por meio do console do CloudWatch. Se precisar enviar logs para o Amazon S3, você precisará fazer algumas configurações iniciais no console do Lambda e configurar permissões de bucket. Se você precisar enviar os logs diretamente para serviços como o OpenSearch Service ou plataformas de analytics de terceiros, o Firehose pode simplificar esse processo.
## Configurar destinos de logs
O AWS Lambda é compatível com vários destinos para logs de funções. Este guia explica os destinos de registro em log disponíveis e ajuda você a escolher a opção certa para suas necessidades. Qualquer que seja o destino escolhido, o Lambda oferece opções para controlar o formato, a filtragem e a entrega dos logs.
O Lambda é compatível com os formatos JSON e texto simples para os logs da função. Os logs estruturados JSON oferecem capacidade de pesquisa aprimorada e permitem análise automatizada, enquanto os logs em texto simples oferecem simplicidade e custos de armazenamento potencialmente menores. É possível controlar quais logs o Lambda envia para o destino escolhido configurando níveis de log para os logs do sistema e da aplicação. A filtragem ajuda a gerenciar os custos de armazenamento e facilita a localização das entradas de log relevantes durante a depuração.
Para obter instruções de configuração detalhadas para cada destino, consulte as seguintes seções:
+ [Enviar logs de função do Lambda para o CloudWatch Logs](monitoring-cloudwatchlogs.md)
+ [Enviar logs de função do Lambda para o Firehose](logging-with-firehose.md)
+ [Enviar logs de função do Lambda para o Amazon S3](logging-with-s3.md)
## Configurar controles avançados de registro em log para funções do Lambda
Para dar a você mais controle sobre como os logs de função são capturados, processados e consumidos, o Lambda oferece as seguintes opções de configuração de registro em log:
+ **Formato de logs**: selecione entre texto simples e formato JSON estruturado para os logs da função.
+ **Nível de log**: para logs estruturados JSON, escolha o nível de detalhes dos logs enviados pelo Lambda para o CloudWatch, como `FATAL`, `ERROR`, `WARN`, `INFO`, `DEBUG` e `TRACE`.
+ **Grupo de logs**: escolha o grupo de logs do CloudWatch para o qual a função envia os logs.
Para saber mais sobre a configuração de controles avançados de registro em log, consulte as seguintes seções:
+ [Configurar logs em formato de texto simples e JSON](monitoring-cloudwatchlogs-logformat.md)
+ [Filtragem em nível de log](monitoring-cloudwatchlogs-log-level.md)
+ [Configurar grupos de logs do CloudWatch](monitoring-cloudwatchlogs-loggroups.md)
# Configurar logs em formato de texto simples e JSON
Capturar as saídas de log como pares de valores-chave JSON facilita a pesquisa e a filtragem ao depurar suas funções. Com os logs em formato JSON, você também pode adicionar tags e informações contextuais aos logs. Esse recurso ajuda a realizar análises automatizadas de grandes volumes de dados de log. A menos que o fluxo de trabalho de desenvolvimento dependa de ferramentas existentes que consumam logs do Lambda em texto simples, recomendamos que você selecione JSON para o formato de log.
**Instâncias gerenciadas do Lambda**
As instâncias gerenciadas do Lambda oferecem suporte somente ao formato de log de JSON. Quando você cria uma função de instâncias gerenciadas, o Lambda configura automaticamente o formato de log para JSON e não é possível alterá-lo para texto sem formatação. Para obter mais informações sobre instâncias gerenciadas, consulte [Instâncias gerenciadas do Lambda](lambda-managed-instances.md).
Para todos os runtimes gerenciados pelo Lambda, você pode escolher se os logs do sistema da função são enviados para o CloudWatch Logs em texto simples não estruturado ou no formato JSON. Os logs do sistema são os logs que o Lambda gera e, às vezes, são conhecidos como logs de eventos da plataforma.
Para [runtimes compatíveis](#monitoring-cloudwatchlogs-logformat-supported), quando você usa um dos métodos de registro em log integrado compatível, o Lambda também pode gerar os logs de aplicações da função (os logs gerados pelo código da função) no formato JSON estruturado. Quando você configura o formato de log da função para esses runtimes, a configuração escolhida se aplica aos logs do sistema e de aplicações.
Para runtimes compatíveis, se a função usar uma biblioteca ou um método de registro em log compatível, você não precisa fazer nenhuma alteração no código existente para que o Lambda capture registros em JSON estruturado.
**nota**
O uso de log no formato JSON adiciona metadados e codifica mensagens de log como objetos JSON contendo uma série de pares de valores-chave. Por causa disso, o tamanho das mensagens de log da função pode aumentar.
## Runtimes e métodos de registro em log compatíveis
Atualmente, o Lambda é compatível com a opção de gerar logs de aplicações em JSON estruturado para os runtimes a seguir.
| Linguagem | Versões compatíveis |
| --- | --- |
| Java | Todos os runtimes do Java, exceto Java 8 no Amazon Linux 1 |
| .NET | .NET 8 e versões posteriores |
| Node.js | Node.js 16 e posterior |
| Python | Python 3.8 e posterior |
| Rust | n/a |
Para que o Lambda envie os logs de aplicações da função para o CloudWatch no formato JSON estruturado, sua função precisa usar as seguintes ferramentas de registro em log integradas para gerar logs:
+ **Java**: o logger `LambdaLogger` ou Log4j2. Para obter mais informações, consulte [Registrar em log e monitorar funções do Lambda em Java](java-logging.md).
+ **.NET**: a instância `ILambdaLogger` no objeto de contexto. Para obter mais informações, consulte [Registrar em log e monitorar funções do Lambda em C\$1](csharp-logging.md).
+ **Node.js**: os métodos do console `console.trace`, `console.debug`, `console.log`, `console.info`, `console.error` e `console.warn`. Para obter mais informações, consulte [Registrar em log e monitorar funções do Lambda em Node.js](nodejs-logging.md).
+ **Python**: a biblioteca de `logging` padrão do Python Para obter mais informações, consulte [Registrar em log e monitorar funções do Lambda em Python](python-logging.md).
+ **Rust**: a caixa `tracing`. Para obter mais informações, consulte [Registrar em log e monitorar as funções do Lambda em Rust](rust-logging.md).
Para outros runtimes gerenciados do Lambda, ele atualmente só tem compatibilidade nativa com a captura de logs do sistema no formato JSON estruturado. No entanto, você ainda pode capturar logs de aplicações no formato JSON estruturado em qualquer runtime usando ferramentas de registro em log, como o Powertools para AWS Lambda, que gera logs no formato JSON.
## Formatos de log padrão
Atualmente, o formato de log padrão para todos os runtimes do Lambda é texto simples. Para instâncias gerenciadas do Lambda, o formato do log é sempre JSON e não pode ser alterado.
Se você já usa bibliotecas de registro em log, como o Powertools para AWS Lambda, para gerar logs de funções no formato JSON estruturado, não precisará alterar o código se selecionar log no formato JSON. O Lambda não codifica duas vezes nenhum log que já esteja codificado em JSON. Então, os logs de aplicações da função continuarão sendo capturados como antes.
## Formato JSON para logs do sistema
Quando você configura o formato de log da função como JSON, cada item de log do sistema (evento de plataforma) é capturado como um objeto JSON que contém pares de valores-chave com as seguintes chaves:
+ `"time"`: o horário em que a mensagem de log foi gerada.
+ `"type"`: o tipo de evento que está sendo registrado em log
+ `"record"`: o conteúdo do log gerado
O formato do valor `"record"` varia de acordo com o tipo de evento que está sendo registrado em log. Para obter mais informações, consulte [Tipos de objeto `Event` da API de telemetria](telemetry-schema-reference.md#telemetry-api-events). Para obter mais informações sobre os níveis de log atribuídos aos eventos de log do sistema, consulte [Mapeamento de eventos no nível de log do sistema](monitoring-cloudwatchlogs-log-level.md#monitoring-cloudwatchlogs-log-level-mapping).
Para comparação, os dois exemplos a seguir mostram a mesma saída de log nos formatos de texto simples e JSON estruturado. Observe que, na maioria dos casos, os eventos de log do sistema contêm mais informações quando enviados no formato JSON do que quando enviados em texto simples.
**Example texto simples:**
```
2024-03-13 18:56:24.046000 fbe8c1 INIT_START Runtime Version: python:3.12.v18 Runtime Version ARN: arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0
```
**Example JSON estruturado:**
```
{
"time": "2024-03-13T18:56:24.046Z",
"type": "platform.initStart",
"record": {
"initializationType": "on-demand",
"phase": "init",
"runtimeVersion": "python:3.12.v18",
"runtimeVersionArn": "arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0"
}
}
```
**nota**
[Acessar dados de telemetria em tempo real para extensões usando a API Telemetria](telemetry-api.md) sempre emite eventos de plataforma, como `START` e `REPORT` no formato JSON. Configurar o formato dos logs do sistema enviados pelo Lambda para o CloudWatch não afeta o comportamento da API de Telemetria do Lambda.
## Formato JSON para logs de aplicações
Quando você configura o formato de log da função como JSON, as saídas de logs de aplicações gravadas usando bibliotecas e métodos de registro em log compatíveis são capturadas como um objeto JSON que contém pares de valores de chave com as chaves a seguir.
+ `"timestamp"`: o horário em que a mensagem de log foi gerada.
+ `"level"`: o nível de log atribuído à mensagem.
+ `"message"`: o conteúdo da mensagem de log.
+ `"requestId"` (Python, .NET e Node.js) ou `"AWSrequestId"` (Java): o ID de solicitação exclusivo para a invocação da função
Dependendo do runtime e do método de registro em log que a função usa, esse objeto JSON também pode conter pares de chaves adicionais. Por exemplo, em Node.js, se a função usa métodos do `console` para registrar em log objetos de erro usando vários argumentos, o objeto JSON conterá pares adicionais de valores de chave com as chaves `errorMessage`, `errorType` e `stackTrace`. Para saber mais sobre logs formatados em JSON em diferentes runtimes do Lambda, consulte [Registrar em log e monitorar funções do Lambda em Python](python-logging.md), [Registrar em log e monitorar funções do Lambda em Node.js](nodejs-logging.md) e [Registrar em log e monitorar funções do Lambda em Java](java-logging.md).
**nota**
A chave usada pelo Lambda para o valor do carimbo de data/hora é diferente para logs do sistema e de aplicações. Para logs do sistema, o Lambda usa a chave `"time"` para manter a consistência com a API de telemetria. Para logs de aplicações, o Lambda segue as convenções dos runtimes compatíveis e usa `"timestamp"`.
Para comparação, os dois exemplos a seguir mostram a mesma saída de log nos formatos de texto simples e JSON estruturado.
**Example texto simples:**
```
2024-10-27T19:17:45.586Z 79b4f56e-95b1-4643-9700-2807f4e68189 INFO some log message
```
**Example JSON estruturado:**
```
{
"timestamp":"2024-10-27T19:17:45.586Z",
"level":"INFO",
"message":"some log message",
"requestId":"79b4f56e-95b1-4643-9700-2807f4e68189"
}
```
## Configurar o formato de log da função
Para configurar o formato de log da função, você pode usar o console do Lambda ou a AWS Command Line Interface (AWS CLI). Também é possível configurar o formato de log de uma função usando os comandos [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) e [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) da API do Lambda, o recurso [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) do AWS Serverless Application Model (AWS SAM) e o recurso [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html) do CloudFormation.
Alterar o formato de log da função não afeta os logs existentes armazenados no CloudWatch Logs. Somente os novos logs usarão o formato atualizado.
Se você alterar o formato de log da função para JSON e não definir o nível do log, o Lambda definirá automaticamente o nível do log da aplicação e do sistema da função como INFO. Isso significa que o Lambda só envia saídas de log de nível WARN e inferiores para o CloudWatch Logs. Para saber mais sobre a filtragem em nível de log da aplicação e do sistema, consulte [Filtragem em nível de log](monitoring-cloudwatchlogs-log-level.md)
**nota**
Em runtimes do Python, quando o formato de log da função é definido como texto sem formatação, a configuração padrão de nível de log é WARN. Isso significa que o Lambda só envia saídas de log de nível WARN e inferior para o CloudWatch Logs. Alterar o formato de log da função para JSON altera esse comportamento padrão. Para saber mais sobre registro em log no Python, consulte [Registrar em log e monitorar funções do Lambda em Python](python-logging.md).
Para funções do Node.js que emitem logs de formato de métricas incorporadas (EMF), alterar o formato de log da função para JSON pode fazer com que o CloudWatch não consiga reconhecer as métricas.
**Importante**
Se a função usa o Powertools para AWS Lambda (TypeScript) ou bibliotecas cliente EMF de código aberto para emitir logs em EMF, atualize as bibliotecas do [Powertools](https://github.com/aws-powertools/powertools-lambda-typescript) e [EMF](https://www.npmjs.com/package/aws-embedded-metrics) para as versões mais recentes a fim de garantir que o CloudWatch possa continuar analisando os logs corretamente. Se você mudar para logs em formato JSON, também recomendamos que você realize testes para garantir a compatibilidade com as métricas incorporadas da sua função. Para obter mais informações sobre as funções do node.js que emitem logs em EMF, consulte [Usar bibliotecas cliente com logs de formato de métricas incorporadas (EMF) em JSON estruturado](nodejs-logging.md#nodejs-logging-advanced-emf).
**Configurar o formato em log da função (console)**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha uma função.
1. Na página de configuração da função, escolha **Ferramentas de monitoramento e operações**.
1. No painel **Configuração de registro em log**, escolha **Editar**.
1. Em **Conteúdo do log**, em **Formato do log**, selecione **Texto** ou **JSON**.
1. Escolha **Salvar**.
**Alterar o formato de log de uma função existente (AWS CLI)**
+ Para alterar o formato de log de uma função existente, use o comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html). Defina a opção `LogFormat` em `LoggingConfig` como `JSON` ou `Text`.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON
```
**Definir o formato do log ao criar uma função (AWS CLI)**
+ Para configurar o formato do log ao criar uma nova função, use a opção `--logging-config` no comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Defina `LogFormat` como `JSON` ou `Text`. O exemplo de comando a seguir cria uma função Node.js que gera logs em JSON estruturado.
Se você não especificar um formato de log ao criar uma função, o Lambda usará o formato de log padrão para a versão de runtime selecionada. Para obter informações sobre o formato do log, consulte [Formatos de log padrão](#monitoring-cloudwatchlogs-format-default).
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON
```
# Filtragem em nível de log
O Lambda pode filtrar os logs da função para que somente logs de um determinado nível de detalhes, ou de um nível inferior, sejam enviados para o CloudWatch Logs. É possível configurar a filtragem em nível de logs separadamente para os logs do sistema da função (logs gerados pelo Lambda) e os logs de aplicações (logs gerados pelo código da função).
Para [Runtimes e métodos de registro em log compatíveis](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-logformat-supported), você não precisa fazer nenhuma alteração no código da função do Lambda para filtrar logs de aplicações da função.
Para todos os outros runtimes e métodos de registro em log, o código da função deve gerar eventos de log para `stdout` ou `stderr` como objetos formatados em JSON que contenham um par de valores-chave com a chave `"level"`. Por exemplo, o Lambda interpreta a saída a seguir `stdout` como um log de nível DEBUG.
```
print('{"level": "debug", "msg": "my debug log", "timestamp": "2024-11-02T16:51:31.587199Z"}')
```
Se o campo de valor `"level"` for inválido ou estiver ausente, o Lambda atribuirá à saída do log o nível INFO. Para que o Lambda use o campo de carimbo de data/hora, você precisa especificar a hora em um formato [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) válido de carimbo de data/hora. Se você não fornecer um carimbo de data/hora válido, o Lambda atribuirá ao log o nível INFO e adicionará um carimbo de data/hora.
Ao denominar a chave de carimbo de data/hora, siga as convenções do runtime que estiver usando. O Lambda é compatível com as convenções de nomenclatura mais comuns usadas pelos runtimes gerenciados.
**nota**
Para usar a filtragem em nível de log, sua função precisar estar configurada para usar logs em formato JSON. O formato de log padrão para todos os runtimes gerenciados pelo Lambda atualmente é texto simples. Para saber como configurar logs em formato JSON para a função, consulte [Configurar o formato de log da função](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-set-format).
Para logs de aplicações (logs gerados pelo código da função), você pode escolher entre os níveis de log a seguir.
| Nível de log | Uso padrão |
| --- | --- |
| TRACE (mais detalhes) | As informações mais detalhadas usadas para rastrear o caminho da execução do código |
| DEBUG | Informações detalhadas para depuração do sistema |
| INFORMAÇÕES | Mensagens que registram a operação normal da função |
| WARN | Mensagens sobre possíveis erros que podem levar a um comportamento inesperado se não forem corrigidos |
| ERRO | Mensagens sobre problemas que impedem que o código funcione conforme o esperado |
| FATAL (menos detalhes) | Mensagens sobre erros graves que fazem a aplicação parar de funcionar |
Quando você seleciona um nível de log, o Lambda envia logs desse nível, e de níveis inferiores, para o CloudWatch Logs. Por exemplo, se você definir o nível de log de aplicações de uma função como WARN, o Lambda não enviará saídas de log nos níveis INFO e DEBUG. O nível padrão de logs de aplicações para a filtragem de logs é INFO.
Quando o Lambda filtra os logs de aplicações da função, as mensagens de log sem nível receberão o nível INFO.
Para logs do sistema (logs gerados pelo serviço Lambda), você pode escolher entre os níveis de log a seguir.
| Nível de log | Usage |
| --- | --- |
| DEBUG (mais detalhes) | Informações detalhadas para depuração do sistema |
| INFORMAÇÕES | Mensagens que registram a operação normal da função |
| WARN (menos detalhes) | Mensagens sobre possíveis erros que podem levar a um comportamento inesperado se não forem corrigidos |
Quando você seleciona um nível de log, o Lambda envia logs desse nível, e de níveis inferiores. Por exemplo, se você definir o nível de log do sistema de uma função como INFO, o Lambda não enviará saídas de log no nível DEBUG.
Por padrão, o Lambda define o nível de log do sistema como INFO. Com essa configuração, o Lambda envia automaticamente as mensagens de log `"start"` e `"report"` para o CloudWatch. Para receber logs do sistema mais ou menos detalhados, altere o nível de log para DEBUG ou WARN. Para ver uma lista dos níveis de log para os quais o Lambda mapeia diferentes eventos de log do sistema, consulte [Mapeamento de eventos no nível de log do sistema](#monitoring-cloudwatchlogs-log-level-mapping).
## Configurar a filtragem em nível de log
Para configurar a filtragem em nível de log de aplicações e do sistema para a função, você pode usar o console do Lambda ou a AWS Command Line Interface (AWS CLI). Também é possível configurar o nível de log de uma função usando os comandos [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) e [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) da API do Lambda, o recurso [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) do AWS Serverless Application Model (AWS SAM) e o recurso [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html) do CloudFormation.
Observe que, se você definir o nível de log da função no código, essa definição terá precedência sobre qualquer outra configuração de nível de log que você definir. Por exemplo, se você usar o método `logging` `setLevel()` do Python para definir o nível de registro em log da sua função como INFO, essa definição terá precedência sobre uma configuração de WARN que você definir usando o console do Lambda.
**Configurar o nível de log de aplicações ou do sistema de uma função existente (console)**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha uma função.
1. Na página de configuração da função, escolha **Ferramentas de monitoramento e operações**.
1. No painel **Configuração de registro em log**, escolha **Editar**.
1. Em **Conteúdo do log**, em **Formato do log**, certifique-se de que a opção **JSON** esteja selecionada.
1. Use os botões de opção para selecionar o **Nível de log da aplicação** e o **Nível de log do sistema** desejados para a função.
1. Escolha **Salvar**.
**Configurar o nível de logs de aplicações ou do sistema de uma função existente (AWS CLI)**
+ Para alterar o nível de logs de aplicações ou do sistema de uma função existente, use o comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html). Use `--logging-config` para definir `SystemLogLevel` como um destes: `DEBUG`, `INFO` ou `WARN`. Defina `ApplicationLogLevel` como `DEBUG`, `INFO`, `WARN`, `ERROR` ou `FATAL`.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
**Configurar a filtragem em nível de log ao criar uma função**
+ Para configurar a filtragem em nível de log ao criar uma função, use `--logging-config` para definir as chaves `SystemLogLevel` e `ApplicationLogLevel` no comando [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Defina `SystemLogLevel` como `DEBUG`, `INFO` ou `WARN`. Defina `ApplicationLogLevel` como `DEBUG`, `INFO`, `WARN`, `ERROR` ou `FATAL`.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
## Mapeamento de eventos no nível de log do sistema
Para eventos de log no nível do sistema gerados pelo Lambda, a tabela a seguir define o nível de log atribuído a cada evento. Para saber mais sobre os eventos listados na tabela, consulte [Referência de esquema para `Event` da API de Telemetria do Lambda](telemetry-schema-reference.md).
| Nome do evento | Condição | Nível de log atribuído |
| --- | --- | --- |
| initStart | runtimeVersion está definida | INFORMAÇÕES |
| initStart | runtimeVersion não está definida | DEBUG |
| initRuntimeDone | status=success | DEBUG |
| initRuntimeDone | status\$1=success | WARN |
| initReport | initializationType\$1=on-demand | INFORMAÇÕES |
| initReport | initializationType=on-demand | DEBUG |
| initReport | status\$1=success | WARN |
| restoreStart | runtimeVersion está definida | INFORMAÇÕES |
| restoreStart | runtimeVersion não está definida | DEBUG |
| restoreRuntimeDone | status=success | DEBUG |
| restoreRuntimeDone | status\$1=success | WARN |
| restoreReport | status=success | INFORMAÇÕES |
| restoreReport | status\$1=success | WARN |
| rápido | - | INFORMAÇÕES |
| runtimeDone | status=success | DEBUG |
| runtimeDone | status\$1=success | WARN |
| relatório | status=success | INFORMAÇÕES |
| relatório | status\$1=success | WARN |
| extensão | state=success | INFORMAÇÕES |
| extensão | state\$1=success | WARN |
| logSubscription | - | INFORMAÇÕES |
| telemetrySubscription | - | INFORMAÇÕES |
| logsDropped | - | WARN |
**nota**
[Acessar dados de telemetria em tempo real para extensões usando a API Telemetria](telemetry-api.md) sempre emite o conjunto completo de eventos da plataforma. Configurar o nível dos logs do sistema enviados pelo Lambda para o CloudWatch não afeta o comportamento da API de Telemetria do Lambda.
## Filtragem em nível de log de aplicações com runtimes personalizados
Quando você configura a filtragem em nível de log de aplicações para a função, o Lambda define o nível de log de aplicações em segundo plano no runtime usando a variável de ambiente `AWS_LAMBDA_LOG_LEVEL`. O Lambda também define o formato de log da função usando a variável de ambiente `AWS_LAMBDA_LOG_FORMAT`. É possível usar essas variáveis para integrar os controles avançados de registro em log do Lambda em um [runtime personalizado](runtimes-custom.md).
Para definir as configurações de registro em log de uma função usando um runtime personalizado com o console, a AWS CLI e as APIs do Lambda, configure o runtime personalizado para verificar o valor dessas variáveis de ambiente. Depois disso, você pode configurar os loggers do runtime de acordo com o formato e os níveis de log selecionados.
# Enviar logs de função do Lambda para o CloudWatch Logs
Por padrão, o Lambda captura automaticamente os logs de todas as invocações de função e os envia para o CloudWatch Logs, desde que o perfil de execução da função tenha as permissões necessárias. Por padrão, esses logs são armazenados em um grupo de logs denominado /aws/lambda/**. Para aprimorar a depuração, você pode inserir instruções personalizadas de registro em log no código que o Lambda integrará perfeitamente ao CloudWatch Logs. Se necessário, você pode configurar a função para enviar logs para outro grupo usando o console do Lambda, a AWS CLI ou a API do Lambda. Para saber mais, consulte [Configurar grupos de logs do CloudWatch](monitoring-cloudwatchlogs-loggroups.md).
Você pode visualizar os logs de funções do Lambda usando o console do Lambda, o console do CloudWatch, a AWS Command Line Interface (AWS CLI) ou a API do CloudWatch. Para obter mais informações, consulte [Visualização dos logs do CloudWatch para funções do Lambda](monitoring-cloudwatchlogs-view.md).
**nota**
Pode levar de 5 a 10 minutos para que os logs apareçam após uma invocação de função.
## Permissões obrigatórias do IAM
O [perfil de execução](lambda-intro-execution-role.md) precisa de permissão para carregar logs no CloudWatch Logs:
+ `logs:CreateLogGroup`
+ `logs:CreateLogStream`
+ `logs:PutLogEvents`
Para saber mais, consulte [Usar políticas baseadas em identidade (políticas do IAM) para o CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html) no *Guia do usuário do Amazon CloudWatch*.
Você pode adicionar essas permissões do CloudWatch Logs usando uma política gerenciada da AWS `AWSLambdaBasicExecutionRole` fornecida pelo Lambda. Para adicionar essa política à sua função, execute o seguinte comando:
```
aws iam attach-role-policy --role-name your-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
Para obter mais informações, consulte [Trabalhar com políticas gerenciadas pela AWS no perfil de execução](permissions-managed-policies.md).
## Preços
Não há nenhuma cobrança adicional para usar os logs do Lambda, porém, a cobrança padrão do CloudWatch Logs é aplicável. Para obter mais informações, consulte [Preço do CloudWatch.](https://aws.amazon.com/cloudwatch/pricing/)
# Configurar grupos de logs do CloudWatch
Por padrão, o CloudWatch cria automaticamente um grupo de logs denominado `/aws/lambda/` para a função quando ela é invocada pela primeira vez. Para configurar a função para enviar logs a um grupo de logs existente ou para criar um novo grupo de logs para a função, você pode usar a AWS CLI ou o console do Lambda. Também é possível configurar grupos de logs personalizados usando os comandos [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) e [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) da API do Lambda e o recurso do AWS Serverless Application Model (AWS SAM) [AWS::Serverless::Function]().
É possível configurar várias funções do Lambda para enviar logs ao mesmo grupo de logs do CloudWatch. Por exemplo, é possível usar um único grupo de logs para armazenar os logs de todas as funções do Lambda que fizerem parte de uma aplicação específica. Quando você usa um grupo de logs personalizado para uma função do Lambda, os fluxos de log criados pelo Lambda incluem o nome e a versão da função. Isso garante que o mapeamento entre mensagens de log e funções seja preservado, mesmo se você usar o mesmo grupo de logs para várias funções.
O formato de nomenclatura de fluxos de logs para grupos de logs personalizados segue esta convenção:
```
YYYY/MM/DD/[][]
```
Observe que, ao configurar um grupo de logs personalizado, o nome selecionado para o grupo de logs deve seguir as [regras de nomenclatura do CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html). Além disso, nomes de grupos de logs personalizados não devem começar com a string `aws/`. Se você criar um grupo de logs personalizado começando com `aws/`, o Lambda não conseguirá criar o grupo de logs. Como resultado, os logs da função não serão enviados para o CloudWatch.
**Alterar o grupo de logs de uma função (console)**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha uma função.
1. Na página de configuração da função, escolha **Ferramentas de monitoramento e operações**.
1. No painel **Configuração de registro em log**, escolha **Editar**.
1. No painel **Grupo de logs** do **grupo de logs do CloudWatch**, escolha **Personalizado**.
1. Em **Grupo de logs personalizado**, insira o nome do grupo de logs do CloudWatch para o qual você deseja que sua função envie logs. Se você inserir o nome de um grupo de logs existente, sua função usará esse grupo. Se não existir nenhum grupo de logs com o nome inserido, o Lambda criará um novo grupo de logs para a função com esse nome.
**Alterar o grupo de logs de uma função (AWS CLI)**
+ Para alterar o grupo de logs de uma função existente, use o comando [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html).
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogGroup=myLogGroup
```
**Especificar um grupo de logs personalizado ao criar uma função (AWS CLI)**
+ Para especificar um grupo de logs personalizado ao criar uma nova função do Lambda usando a AWS CLI, use a opção `--logging-config`. O comando de exemplo a seguir cria uma função do Lambda para Node.js que envia logs para um grupo de logs denominado `myLogGroup`.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogGroup=myLogGroup
```
## Permissões da função de execução
Para que sua função envie logs para o CloudWatch Logs, ela precisa ter a permissão [logs:PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html). Quando você configura o grupo de logs da sua função usando o console do Lambda, o Lambda adiciona essa permissão ao perfil de acordo com as seguintes condições:
+ O destino do serviço está definido como o CloudWatch Logs
+ O perfil de execução da função não tem permissões para carregar logs no CloudWatch Logs (o destino padrão)
**nota**
O Lambda não adiciona nenhuma permissão de Put para destinos de log do Amazon S3 ou Firehose.
Quando o Lambda adiciona essa permissão, ele dá à função permissão para enviar logs para qualquer grupo de logs do CloudWatch Logs.
Para evitar que o Lambda atualize automaticamente o perfil de execução da função e o edite manualmente, expanda **Permissões** e desmarque **Adicionar permissões necessárias**.
Quando você configura o grupo de logs da função usando a AWS CLI, o Lambda não adiciona automaticamente a permissão `logs:PutLogEvents`. Adicione a permissão ao perfil de execução da função, caso isso ainda não tenha sido feito. Essa permissão está incluída na política gerenciada [AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole$jsonEditor).
## Registro em log do CloudWatch para instâncias gerenciadas do Lambda
Ao usar [instâncias gerenciadas do Lambda](lambda-managed-instances.md), há outras considerações sobre o envio de logs ao CloudWatch Logs:
### Requisitos de rede de VPC
As instâncias gerenciadas do Lambda são executadas em instâncias do EC2 de propriedade do cliente em sua VPC. Para enviar logs para o CloudWatch Logs e rastreamentos para o X-Ray, você deve garantir que essas APIs da AWS sejam roteáveis a partir da sua VPC. Você tem várias opções:
+ **AWS PrivateLink (recomendado)**: use o [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) para criar endpoints da VPC para serviços do CloudWatch e do X-Ray. Isso permite que suas instâncias acessem esses serviços de forma privada, sem a necessidade de um gateway da Internet ou gateway de NAT. Para obter mais informações, consulte [Uso do CloudWatch Logs com endpoints da VPC de interface](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html).
+ **Gateway de NAT**: configure um gateway de NAT para permitir o acesso de saída à Internet a partir de suas sub-redes privadas.
+ **Gateway da Internet**: para sub-redes públicas, certifique-se de que sua VPC tenha um gateway da Internet configurado.
Se as APIs do CloudWatch Logs ou do X-Ray não forem roteáveis a partir da sua VPC, seus logs e rastreamentos de funções não serão entregues.
### Invocações simultâneas e atribuição de logs
Os ambientes de execução das instâncias gerenciadas do Lambda podem processar várias invocações simultaneamente. Quando várias invocações são executadas simultaneamente, suas entradas de log são intercaladas no mesmo fluxo de log. Para filtrar e analisar com eficácia os logs de invocações simultâneas, é necessário garantir que cada entrada de log inclua o ID da solicitação da AWS.
Recomendamos uma das abordagens a seguir:
+ **Use loggers de runtime padrão do Lambda (recomendado)**: as bibliotecas de registro em log padrão fornecidas pelos runtimes gerenciados do Lambda incluem automaticamente o ID da solicitação em cada entrada de log.
+ **Implemente logs JSON estruturados**: se você estiver criando um [runtime personalizado](runtimes-custom.md) ou precisar de um registro em log personalizado, implemente logs em formato JSON que incluam o ID da solicitação em cada entrada. As instâncias gerenciadas do Lambda oferecem suporte somente ao formato de log de JSON. Inclua o campo `requestId` em seus logs de JSON para habilitar a filtragem por invocação:
```
{
"timestamp": "2025-01-15T10:30:00.000Z",
"level": "INFO",
"requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"message": "Processing request"
}
```
Com a atribuição do ID da solicitação, é possível filtrar as entradas de log do CloudWatch Logs para uma invocação específica usando consultas do CloudWatch Logs Insights. Por exemplo:
```
fields @timestamp, @message
| filter requestId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
| sort @timestamp asc
```
Para obter mais informações sobre os requisitos de log das instâncias gerenciadas do Lambda, consulte [Noções básicas sobre o ambiente de execução das instâncias gerenciadas do Lambda](lambda-managed-instances-execution-environment.md).
# Visualização dos logs do CloudWatch para funções do Lambda
É possível visualizar os logs do Amazon CloudWatch para sua função do Lambda usando o console do Lambda, o console do CloudWatch ou a AWS Command Line Interface (AWS CLI). Siga as instruções das próximas seções para acessar os logs da sua função.
## Transmissão de logs da função com o CloudWatch Logs Live Tail
O Amazon CloudWatch Logs Live Tail ajuda você a solucionar rapidamente problemas em suas funções ao exibir uma lista em tempo real de novos eventos de log diretamente no console do Lambda. É possível visualizar e filtrar logs ingeridos de suas funções do Lambda em tempo real, o que ajuda a detectar e a resolver problemas rapidamente.
**nota**
As sessões Live Tail acumulam custos por tempo de uso da sessão, por minuto. Para obter mais informações sobre a definição de preço, consulte [Preços do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
### Comparação entre Live Tail e --log-type Tail
Existem várias diferenças entre o CloudWatch Logs Live Tail e a opção [LogType: Tail](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-LogType) na API do Lambda (`--log-type Tail` na AWS CLI):
+ O `--log-type Tail` retorna somente os primeiros 4 KB dos logs de invocação. O Live Tail não tem esse limite e pode receber até 500 eventos de log por segundo.
+ O `--log-type Tail` captura e envia os logs com a resposta, o que pode impactar a latência de resposta da função. O Live Tail não afeta a latência de resposta da função.
+ O `--log-type Tail` fornece suporte apenas invocações síncronas. O Live Tail funciona para invocações síncronas e assíncronas.
**nota**
As [instâncias gerenciadas do Lambda](lambda-managed-instances.md) não oferecem suporte à opção `--log-type Tail`. Use o CloudWatch Logs Live Tail ou consulte o CloudWatch Logs diretamente para visualizar os logs das funções de instâncias gerenciadas.
### Permissões
As seguintes permissões são necessárias para iniciar e interromper as sessões do CloudWatch Logs Live Tail:
+ `logs:DescribeLogGroups`
+ `logs:StartLiveTail`
+ `logs:StopLiveTail`
### Inicialização de uma sessão do Live Tail no console do Lambda
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha o nome da função.
1. Selecione a guia **Testar**.
1. No painel **Evento de teste**, escolha **CloudWatch Logs Live Tail**.
1. Em **Selecionar o grupo de logs**, o grupo de logs da função é selecionado por padrão. É possível selecionar até cinco grupos de logs ao mesmo tempo.
1. (Opcional) Para exibir apenas eventos de log que contenham determinadas palavras ou outras strings, insira a palavra ou string na caixa de texto **Adicionar padrões de filtro**. Os filtros diferenciam maiúsculas de minúsculas. É possível incluir múltiplos termos e operadores de padrão neste campo, incluindo expressões regulares (regex). Para obter mais informações sobre a sintaxe de padrões, consulte [Filter pattern syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) no *Guia do usuário do Amazon CloudWatch Logs*.
1. Escolha **Iniciar**. Os eventos de log correspondentes começam a aparecer na janela.
1. Para interromper a sessão Live Tail, escolha **Parar**.
**nota**
A sessão do Live Tail é encerrada automaticamente após 15 minutos de inatividade ou quando a sessão do console do Lambda expira.
## Acesse os logs da função usando o console.
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Selecione uma função.
1. Escolha a guia **Monitor** (Monitorar).
1. Escolha **Visualizar logs do CloudWatch** para abrir o console do CloudWatch.
1. Role para baixo e selecione o **Fluxo de logs** para as invocações da função que você deseja verificar.
![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/log-stream.png)
Cada instância de uma função do Lambda tem um fluxo de logs dedicado. Se uma função for escalada, cada instância simultânea terá seu próprio fluxo de logs. Cada vez que um novo ambiente de execução é criado em resposta a uma invocação, isso gera um novo fluxo de registro. A convenção de nomenclatura para fluxos de logs é:
```
YYYY/MM/DD[Function version][Execution environment GUID]
```
Um único ambiente de execução grava no mesmo fluxo de logs durante sua vida útil. O fluxo de logs contém mensagens desse ambiente de execução, bem como qualquer saída do código da sua função do Lambda. Cada mensagem tem um registro de data e hora, incluindo logs personalizados. Mesmo que sua função não registre nenhuma saída do seu código em log, há três instruções de log mínimas geradas por invocação (START, END e REPORT):
![\[monitoramento e observabilidade figura 3\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/monitoring-observability-figure-3.png)
Esses logs mostram:
+ **RequestId**: um ID exclusivo gerado por solicitação. Se a função do Lambda tentar novamente uma solicitação, esse ID não será alterado e aparecerá nos logs de cada nova tentativa subsequente.
+ **Início/Término₢**: marcam uma única invocação, de modo que cada linha de log entre eles pertence à mesma invocação.
+ **Duração**: o tempo total da invocação da função do manipulador, excluindo o código `INIT`.
+ **Duração faturada**: aplica a lógica de arredondamento para fins de cobrança.
+ **Tamanho da memória**: a quantidade de memória alocada para a função.
+ **Memória máxima usada**: o valor máximo de memória usada durante a invocação.
+ **Duração da inicialização**: o tempo gasto para executar a seção `INIT` do código, fora do manipulador principal.
## Acesso aos logs com a AWS CLI
O AWS CLI é uma ferramenta de código aberto que permite interagir com os serviços do AWS usando comandos no shell da linha de comando. Para concluir as etapas desta seção, você deve ter a [versão 2 da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
É possível usar a [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) para recuperar logs de uma invocação usando a opção de comando `--log-type`. A resposta contém um campo `LogResult` com até 4 KB de logs codificados em base64 obtidos da invocação.
**Example recuperar um ID de log**
O exemplo a seguir mostra como recuperar um *ID de log* do campo `LogResult` para uma função chamada `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail
```
A seguinte saída deverá ser mostrada:
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example decodificar os logs**
No mesmo prompt de comando, use o utilitário `base64` para decodificar os logs. O exemplo a seguir mostra como recuperar logs codificados em base64 de `my-function`.
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
A opção **cli-binary-format** será necessária se você estiver usando a AWS CLI versão 2. Para que essa seja a configuração padrão, execute `aws configure set cli-binary-format raw-in-base64-out`. Para obter mais informações, consulte [A AWS CLI comporta opções de linha de comando globais](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) no *Guia do usuário da AWS Command Line Interface versão 2*.
A seguinte saída deverá ser mostrada:
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
O utilitário `base64` está disponível no Linux, macOS e [Ubuntu no Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Os usuários do macOS precisam usar `base64 -D`.
**Example get-logs.sh script**
No mesmo prompt de comando, use o script a seguir para fazer download dos últimos cinco eventos de log. O script usa `sed` para remover as aspas do arquivo de saída e fica inativo por 15 segundos para que os logs tenham tempo de ficar disponíveis. A saída inclui a resposta do Lambda, e a saída do comando `get-log-events`.
Copie o conteúdo do exemplo de código a seguir e salve no diretório de seu projeto do Lambda como `get-logs.sh`.
A opção **cli-binary-format** será necessária se você estiver usando a AWS CLI versão 2. Para que essa seja a configuração padrão, execute `aws configure set cli-binary-format raw-in-base64-out`. Para obter mais informações, consulte [A AWS CLI comporta opções de linha de comando globais](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) no *Guia do usuário da AWS Command Line Interface versão 2*.
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example macOS e Linux (somente)**
No mesmo prompt de comando, os usuários do macOS e do Linux podem precisar executar o comando a seguir para garantir que o script seja executável.
```
chmod -R 755 get-logs.sh
```
**Example recuperar os últimos cinco eventos de log**
No mesmo prompt de comando, execute o script a seguir para obter os últimos cinco eventos de log.
```
./get-logs.sh
```
A seguinte saída deverá ser mostrada:
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## Análise de logs e registro estruturado em logs
Com o CloudWatch Logs Insights, você pode pesquisar e analisar dados de log usando uma [sintaxe de consulta](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) especializada. Ele realiza consultas em vários grupos de logs e fornece uma filtragem poderosa usando a correspondência de padrões [glob](https://en.wikipedia.org/wiki/Glob_(programming)) e [expressões regulares](https://en.wikipedia.org/wiki/Regular_expression).
É possível aproveitar esses recursos implementando o registro estruturado em suas funções do Lambda. O registro estruturado organiza seus logs em um formato predefinido, facilitando assim a consulta. O uso de níveis de logs é uma primeira etapa importante na geração de logs fáceis de filtrar que separam mensagens informativas de avisos ou erros. Por exemplo, considere o código em Node.js a seguir:
```
exports.handler = async (event) => {
console.log("console.log - Application is fine")
console.info("console.info - This is the same as console.log")
console.warn("console.warn - Application provides a warning")
console.error("console.error - An error occurred")
}
```
O arquivo de log resultante do CloudWatch contém um campo separado que especifica o nível do log:
![\[monitoramento e observabilidade figura 10\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/monitoring-observability-figure-10.png)
Uma consulta do CloudWatch Logs Insights pode então filtrar por nível de log. Por exemplo, para consultar somente erros, é possível utilizar a consulta a seguir:
```
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
```
### Registro de log estruturado em JSON
O JSON é comumente usado para fornecer estrutura para logs de aplicações. No exemplo a seguir, os logs foram convertidos em JSON de forma a gerar três valores distintos:
![\[monitoramento e observabilidade figura 11\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/monitoring-observability-figure-11.png)
O recurso CloudWatch Logs Insights descobre automaticamente valores na saída JSON e analisa as mensagens como campos, sem a necessidade de uma expressão regular ou glob personalizado. Usando os logs estruturados em JSON, a consulta a seguir encontra invocações em que o arquivo carregado era maior que 1 MB, o tempo de upload era superior a 1 segundo e a invocação não era uma inicialização a frio:
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
```
Essa consulta pode produzir o seguinte resultado:
![\[monitoramento e observabilidade figura 12\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/monitoring-observability-figure-12.png)
Os campos descobertos em JSON são preenchidos automaticamente no menu *Campos descobertos* no lado direito. Os campos padrão emitidos pelo serviço Lambda são prefixados com “@” e você pode consultar esses campos da mesma forma. Os logs do Lambda sempre incluem os campos @timestamp, @logStream, @message, @requestId, @duration, @billedDuration, @type, @maxMemoryUsed, @memorySize. Se o X-Ray estiver habilitado para uma função, os logs também incluirão @xrayTraceId e @xraySegmentId.
Quando uma fonte de eventos da AWS, como o Amazon S3, o Amazon SQS ou o Amazon EventBridge, invoca sua função, o evento inteiro é fornecido à função como uma entrada de objeto JSON. Ao registrar esse evento na primeira linha da função, você pode consultar qualquer um dos campos aninhados usando o CloudWatch Logs Insights.
### Consultas úteis do Insights
A tabela a seguir mostra exemplos de consultas do Insights que podem ser úteis para monitorar funções do Lambda.
| Descrição | Exemplo de consulta e sintaxe do |
| --- | --- |
| Os últimos 100 erros |
```
fields Timestamp, LogLevel, Message
\| filter LogLevel == "ERR"
\| sort @timestamp desc
\| limit 100
``` |
| As 100 invocações mais faturadas |
```
filter @type = "REPORT"
\| fields @requestId, @billedDuration
\| sort by @billedDuration desc
\| limit 100
``` |
| Porcentagem de inicializações a frio no total de invocações |
```
filter @type = "REPORT"
\| stats sum(strcontains(@message, "Init Duration"))/count(*) * 100 as
coldStartPct, avg(@duration)
by bin(5m)
``` |
| Relatório percentual da duração do Lambda |
```
filter @type = "REPORT"
\| stats
avg(@billedDuration) as Average,
percentile(@billedDuration, 99) as NinetyNinth,
percentile(@billedDuration, 95) as NinetyFifth,
percentile(@billedDuration, 90) as Ninetieth
by bin(30m)
``` |
| Relatório percentual do uso de memória do Lambda |
```
filter @type="REPORT"
\| stats avg(@maxMemoryUsed/1024/1024) as mean_MemoryUsed,
min(@maxMemoryUsed/1024/1024) as min_MemoryUsed,
max(@maxMemoryUsed/1024/1024) as max_MemoryUsed,
percentile(@maxMemoryUsed/1024/1024, 95) as Percentile95
``` |
| Invocações que usam 100% da memória atribuída |
```
filter @type = "REPORT" and @maxMemoryUsed=@memorySize
\| stats
count_distinct(@requestId)
by bin(30m)
``` |
| Memória média usada em todas as invocações |
```
avgMemoryUsedPERC,
avg(@billedDuration) as avgDurationMS
by bin(5m)
``` |
| Visualização das estatísticas de memória |
```
filter @type = "REPORT"
\| stats
max(@maxMemoryUsed / 1024 / 1024) as maxMemMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemMB,
min(@maxMemoryUsed / 1024 / 1024) as minMemMB,
(avg(@maxMemoryUsed / 1024 / 1024) / max(@memorySize / 1024 / 1024)) * 100 as avgMemUsedPct,
avg(@billedDuration) as avgDurationMS
by bin(30m)
``` |
| Invocações em que o Lambda foi encerrado |
```
filter @message like /Process exited/
\| stats count() by bin(30m)
``` |
| Invocações que atingiram o tempo limite |
```
filter @message like /Task timed out/
\| stats count() by bin(30m)
``` |
| Relatório de latência |
```
filter @type = "REPORT"
\| stats avg(@duration), max(@duration), min(@duration)
by bin(5m)
``` |
| Memória superprovisionada |
```
filter @type = "REPORT"
\| stats max(@memorySize / 1024 / 1024) as provisonedMemMB,
min(@maxMemoryUsed / 1024 / 1024) as smallestMemReqMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemUsedMB,
max(@maxMemoryUsed / 1024 / 1024) as maxMemUsedMB,
provisonedMemMB - maxMemUsedMB as overProvisionedMB
``` |
## Exibição de logs e painéis
Para qualquer consulta do CloudWatch Logs Insights, é possível exportar os resultados para o formato de markdown ou CSV. Em alguns casos, talvez seja mais útil criar [visualizações a partir de consultas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Visualizing-Log-Data.html), desde que haja pelo menos uma função de agregação. A função `stats` permite definir agregações e agrupamentos.
O exemplo anterior de *logInsightsJSON* filtrou o tamanho e o tempo de upload e excluiu as primeiras invocações. Isso resultou em uma tabela de dados. Para monitorar um sistema de produção, pode ser mais útil visualizar os tamanhos mínimo, máximo e médio dos arquivos para encontrar valores discrepantes. Para fazer isso, aplique a função de estatísticas com os agregados necessários e agrupe em um valor de tempo, como a cada minuto:
Por exemplo, considere a seguinte consulta. Este é o mesmo exemplo de consulta da seção [Registro de log estruturado em JSON](#querying-logs-json), mas com funções adicionais de agregação:
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
| stats min(uploadedBytes), avg(uploadedBytes), max(uploadedBytes) by bin (1m)
```
Incluímos esses agregados porque pode ser mais útil visualizar os tamanhos mínimo, máximo e médio dos arquivos a fim de encontrar valores atípicos. É possível ver os resultados na guia **Visualização**:
![\[monitoramento e observabilidade figura 14\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/monitoring-observability-figure-14.png)
Depois de concluir a criação da visualização, você pode, opcionalmente, adicionar o gráfico a um painel do CloudWatch. Para fazer isso, escolha **Adicionar ao painel** acima da visualização. Isso adiciona a consulta como um widget e permite selecionar intervalos de atualização automática, facilitando o monitoramento contínuo dos resultados:
![\[monitoramento e observabilidade figura 15\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/monitoring-observability-figure-15.png)
# Enviar logs de função do Lambda para o Firehose
Agora, o console do Lambda oferece a opção de enviar os logs de função para o Firehose. Isso permite a transmissão em tempo real dos logs para vários destinos compatíveis com o Firehose, incluindo ferramentas de analytics de terceiros e endpoints personalizados.
**nota**
Você pode configurar logs da função do Lambda para serem enviados ao Firehose usando o console do Lambda, a AWS CLI, o AWS CloudFormation e todos os SDKs da AWS.
## Preços
Para obter detalhes sobre os preços, consulte [Definição de preço do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Permissões exigidas para um destino de log no Firehose
Ao usar o console do Lambda para configurar o Firehose como o destino de log da função, você precisa:
1. Das [permissões do IAM exigidas](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) para usar o CloudWatch Logs com o Lambda.
1. Para [configurar filtros de assinatura com o Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#FirehoseExample). Esse filtro define quais eventos de log são entregues ao fluxo do Firehose.
## Enviar logs de função do Lambda para o Firehose
É possível enviar os logs de função diretamente no console do Lambda para o Firehose após criar uma nova função. Para fazer isso, conclua estas etapas:
1. Faça login no AWS Management Console e abra o console do Lambda.
1. Escolha o nome da função.
1. Escolha a guia **Configuração**.
1. Escolha a guia **Ferramentas de monitoramento e operações**.
1. Na seção "Configuração de registro em log", escolha **Editar**.
1. Na seção "Conteúdo de logs", selecione um formato de log.
1. Na seção "Destino de logs", conclua as seguintes etapas:
1. Selecione um serviço de destino.
1. Escolha **Criar um novo grupo de logs** ou use um **Grupo de logs existente**.
**nota**
Se for escolher um grupo de logs existente como um destino do Firehose, certifique-se de que o grupo de logs escolhido seja um grupo de logs do tipo `Delivery`.
1. Escolha um fluxo do Firehose.
1. O grupo de logs `Delivery` do CloudWatch será exibido.
1. Escolha **Salvar**.
**nota**
Se o perfil do IAM fornecido no console não tiver a permissão necessária, a configuração do destino falhará. Para corrigir isso, consulte Required permissions for Firehose log destination para fornecer as permissões necessárias.
## Registro em log entre contas
É possível configurar o Lambda para enviar logs para o fluxo de entrega do Firehose em uma outra conta da AWS. Isso requer a configuração de um destino e de permissões apropriadas em ambas as contas.
Para obter instruções detalhadas sobre a configuração do registro em log entre contas, incluindo os perfis do IAM e as políticas necessárias, consulte [Setting up a new cross-account subscription](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) na documentação do CloudWatch Logs.
# Enviar logs de função do Lambda para o Amazon S3
Você pode configurar a função do Lambda para enviar logs diretamente para o Amazon S3 usando o console do Lambda. Esse atributo fornece uma solução econômica para armazenamento de logs de longo prazo e habilita opções de análise avançadas usando serviços como o Athena.
**nota**
Você pode configurar os logs de função do Lambda para serem enviados ao Amazon S3 usando o console do Lambda, a AWS CLI, o AWS CloudFormation e todos os SDKs da AWS.
## Preços
Para obter detalhes sobre os preços, consulte [Definição de preço do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Permissões exigidas para o destino de log do Amazon S3
Ao usar o console do Lambda para configurar o Amazon S3 como o destino de log da função, você precisa:
1. Das [permissões do IAM exigidas](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) para usar o CloudWatch Logs com o Lambda.
1. Para [Configurar um filtro de assinaturas do CloudWatch Logs para enviar os logs de função do Lambda para o Amazon S3](#using-cwl-subscription-filter-lambda-s3). Esse filtro define quais eventos de log são entregues ao bucket to Amazon S3.
## Configurar um filtro de assinaturas do CloudWatch Logs para enviar os logs de função do Lambda para o Amazon S3
Para enviar logs do CloudWatch Logs para o Amazon S3, você precisa criar um filtro de assinatura. Esse filtro define quais eventos de log são entregues ao bucket to Amazon S3. O bucket to Amazon S3 deve ser usado na mesma região do grupo de logs.
### Para criar um filtro de assinatura para o Amazon S3
1. Crie um bucket do Amazon Simple Storage Service (Amazon S3). Recomendamos utilizar um bucket criado especificamente para o CloudWatch Logs. No entanto, se você desejar usar um bucket existente, vá para a etapa 2.
Execute o comando a seguir, substituindo o espaço reservado Region (Região) pela região que você deseja usar:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
**nota**
`amzn-s3-demo-bucket2` é um exemplo de nome de bucket do Amazon S3. Ele é *reservado*. Para esse procedimento funcionar, é necessário substituí-lo pelo nome exclusivo do bucket do Amazon S3.
A seguir está um exemplo de saída:
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Crie o perfil do IAM que concede ao CloudWatch Logs permissão para colocar dados no bucket do Amazon S3. Essa política inclui uma chave de contexto de condição global aws:SourceArn para ajudar a evitar o problema de segurança "confused deputy". Para obter mais informações sobre a [prevenção de confused-deputy](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions-confused-deputy.html).
1. Use um editor de texto para criar uma política de confiança em um arquivo `~/TrustPolicyForCWL.json`, da seguinte maneira:
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
},
"Action": "sts:AssumeRole"
}
}
```
1. Use o comando create-role para criar a função do IAM especificando o arquivo de política de confiança. Observe o valor de Role.Arn retornado, pois você precisará dele em uma etapa posterior:
```
aws iam create-role \
--role-name CWLtoS3Role \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoS3Role"
}
}
```
1. Crie uma política de permissões para definir quais ações o CloudWatch Logs poderá executar em sua conta. Primeiro, use um editor de texto para criar uma política de permissões em um arquivo `~/PermissionsForCWL.json`:
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket2/*"]
}
]
}
```
Associe a política de permissões ao perfil usando o comando `put-role-policy`:
```
aws iam put-role-policy --role-name CWLtoS3Role --policy-name Permissions-Policy-For-S3 --policy-document file://~/PermissionsForCWL.json
```
1. Crie um novo grupo de logs `Delivery` ou use um grupo de logs `Delivery` existente.
```
aws logs create-log-group --log-group-name my-logs --log-group-class DELIVERY --region REGION_NAME
```
1. `PutSubscriptionFilter` para configurar destino
```
aws logs put-subscription-filter
--log-group-name my-logs
--filter-name my-lambda-delivery
--filter-pattern ""
--destination-arn arn:aws:s3:::amzn-s3-demo-bucket2
--role-arn arn:aws:iam::123456789012:role/CWLtoS3Role
--region REGION_NAME
```
## Enviar logs de função do Lambda para o Amazon S3
No console do Lambda, você pode enviar os logs de função diretamente para o Amazon S3 após criar uma nova função. Para fazer isso, conclua estas etapas:
1. Faça login no AWS Management Console e abra o console do Lambda.
1. Escolha o nome da função.
1. Escolha a guia **Configuração**.
1. Escolha a guia **Ferramentas de monitoramento e operações**.
1. Na seção "Configuração de registro em log", escolha **Editar**.
1. Na seção "Conteúdo de logs", selecione um formato de log.
1. Na seção "Destino de logs", conclua as seguintes etapas:
1. Selecione um serviço de destino.
1. Escolha **Criar um novo grupo de logs** ou use um **Grupo de logs existente**.
**nota**
Se for escolher um grupo de logs existente para um destino do Amazon S3, confirme se o grupo de logs escolhido é do tipo `Delivery`.
1. Escolha um bucket do Amazon S3 para ser o destino dos logs de função.
1. O grupo de logs `Delivery` do CloudWatch será exibido.
1. Escolha **Salvar**.
**nota**
Se o perfil do IAM fornecido no console não tiver as permissões exigidas, a configuração de destino falhará. Para corrigir isso, consulte [Permissões exigidas para o destino de log do Amazon S3](#logging-s3-permissions).
## Registro em log entre contas
Você pode configurar o Lambda para enviar logs para um bucket do Amazon S3 em outra conta da AWS. Isso requer a configuração de um destino e de permissões apropriadas em ambas as contas.
Para obter instruções detalhadas sobre a configuração do registro em log entre contas, incluindo os perfis do IAM e as políticas necessárias, consulte [Setting up a new cross-account subscription](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) na documentação do CloudWatch Logs.
# Registrar chamadas à API do AWS Lambda usando o AWS CloudTrail
O AWS Lambda é integrado ao [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), um serviço que fornece um registro das ações realizadas por um usuário, um perfil ou um AWS service (Serviço da AWS). O CloudTrail captura chamadas de API do Lambda como eventos. As chamadas capturadas incluem as chamadas de código do console do Lambda e as chamadas para as operações da API do Lambda. Ao fazer uso das informações coletadas pelo CloudTrail, é possível determinar a solicitação feita ao Lambda, o endereço IP no qual a solicitação foi feita, quando a solicitação foi feita e detalhes adicionais.
Cada entrada de log ou evento contém informações sobre quem gerou a solicitação. As informações de identidade ajudam a determinar o seguinte:
+ Se a solicitação foi feita com credenciais de usuário raiz ou credenciais de usuário.
+ Se a solicitação foi feita em nome de um usuário do Centro de Identidade do IAM.
+ Se a solicitação foi feita com credenciais de segurança temporárias de um perfil ou de um usuário federado.
+ Se a solicitação foi feita por outro AWS service (Serviço da AWS).
Quando a Conta da AWS é criada, o CloudTrail torna-se ativo nela e você tem acesso automático ao **Histórico de eventos** do CloudTrail. O **Histórico de eventos** do CloudTrail fornece um registro visualizável, pesquisável, baixável e imutável dos últimos 90 dias de eventos de gerenciamento gravados em uma Região da AWS. Para obter mais informações, consulte [Trabalhar com histórico de eventos do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) no *Guia do usuário do AWS CloudTrail*. Não há cobranças do CloudTrail pela visualização do **Histórico de eventos**.
Para obter um registro contínuo de eventos em sua Conta da AWS nos últimos 90 dias, crie uma trilha ou um armazenamento de dados de eventos do [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html).
**Trilhas do CloudTrail**
Uma *trilha* permite que o CloudTrail entregue arquivos de log a um bucket do Amazon S3. As trilhas criadas usando o Console de gerenciamento da AWS são de várias regiões. Só é possível criar uma trilha de região única ou de várias regiões usando a AWS CLI. Criar uma trilha de várias regiões é uma prática recomendada, pois você captura atividades em todas as Regiões da AWS da conta. Ao criar uma trilha de região única, é possível visualizar somente os eventos registrados na Região da AWS da trilha. Para obter mais informações sobre trilhas, consulte [Criar uma trilha para a Conta da AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) e [Criar uma trilha para uma organização](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) no *Guia do usuário do AWS CloudTrail*.
Uma cópia dos eventos de gerenciamento em andamento pode ser entregue no bucket do Amazon S3 sem nenhum custo via CloudTrail com a criação de uma trilha; no entanto, há cobranças de armazenamento do Amazon S3. Para obter mais informações sobre os preços do CloudTrail, consulte [Preços do AWS CloudTrail](https://aws.amazon.com/cloudtrail/pricing/). Para receber informações sobre a definição de preços do Amazon S3, consulte [Definição de preços do Amazon S3](https://aws.amazon.com/s3/pricing/).
**Armazenamentos de dados de eventos do CloudTrail Lake**
O *CloudTrail Lake* permite executar consultas baseadas em SQL nos eventos. O CloudTrail Lake converte eventos existentes em formato JSON baseado em linhas para o formato [Apache ORC](https://orc.apache.org/). O ORC é um formato colunar de armazenamento otimizado para recuperação rápida de dados. Os eventos são agregados em *armazenamentos de dados de eventos*, que são coleções imutáveis de eventos baseados nos critérios selecionados com a aplicação de [seletores de eventos avançados](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors). Os seletores que aplicados a um armazenamento de dados de eventos controlam quais eventos persistem e estão disponíveis para consulta. Para obter mais informações sobre o CloudTrail Lake, consulte [Trabalhar com o AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html), no *Guia do usuário do AWS CloudTrail*.
Os armazenamentos de dados de eventos e consultas do CloudTrail Lake incorrem em custos. Ao criar um armazenamento de dados de eventos, você escolhe a [opção de preço](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option) que deseja usar para ele. A opção de preço determina o custo para a ingestão e para o armazenamento de eventos, e o período de retenção padrão e máximo para o armazenamento de dados de eventos. Para saber mais sobre os preços do CloudTrail, consulte [Preços do AWS CloudTrail](https://aws.amazon.com/cloudtrail/pricing/).
## Eventos de dados do Lambda no CloudTrail
Os [Eventos de dados](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events) fornecem informações sobre as operações de recursos realizadas em um recurso (por exemplo, leitura ou gravação em um objeto do Amazon S3). Também são conhecidas como operações de plano de dados. Os eventos de dados costumam ser atividades de alto volume. **Por padrão, o CloudTrail não registra em log a maioria dos eventos de dados, e o Histórico de eventos** do CloudTrail não os registra.
Um evento de dados do CloudTrail que é registrado em log por padrão para serviços compatíveis é `LambdaESMDisabled`. Para saber mais sobre o uso desse evento para ajudar a solucionar problemas de mapeamentos das origens dos eventos do Lambda, consulte [Usar o CloudTrail para solucionar problemas de origens de eventos do Lambda desabilitadas](#cloudtrail-ESM-troubleshooting).
Há cobranças adicionais para eventos de dados. Para saber mais sobre os preços do CloudTrail, consulte [Preços do AWS CloudTrail](https://aws.amazon.com/cloudtrail/pricing/).
É possível registrar em log eventos de dados para o tipo de recurso `AWS::Lambda::Function` usando o console do CloudTrail, a AWS CLI ou operações da API do CloudTrail. Para obter mais informações sobre como registrar eventos de dados em log, consulte [Registrar eventos de dados com o Console de gerenciamento da AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) e [Registrar eventos de dados com a AWS Command Line Interface](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI) no *Guia do usuário do AWS CloudTrail*.
A tabela a seguir lista o tipo de recurso do Lambda para o qual você pode registrar eventos de dados em log. A coluna **Tipo de evento de dados (console)** mostra o valor a ser escolhido na lista **Tipo de evento de dados** no console do CloudTrail. A coluna do valor **resources.type** mostra o valor de `resources.type` que você especificaria ao configurar seletores de eventos avançados usando a AWS CLI ou as APIs do CloudTrail. A coluna **APIs de dados registradas no CloudTrail** mostra as chamadas de API registradas no CloudTrail para o tipo de recurso.
| Tipo de evento de dados (console) | valor resources.type | APIs de dados registradas no CloudTrail |
| --- | --- | --- |
| Lambda | AWS::Lambda::Function | [Invocar](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) |
É possível configurar seletores de eventos avançados para filtrar os campos `eventName`, `readOnly` e `resources.ARN` para registrar em log somente os eventos que são importantes para você. O exemplo a seguir é a visualização JSON de uma configuração de evento de dados que registra eventos somente para uma função específica. Para obter mais informações sobre esses campos, consulte [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) na *Referência de API do AWS CloudTrail*.
```
[
{
"name": "function-invokes",
"fieldSelectors": [
{
"field": "eventCategory",
"equals": [
"Data"
]
},
{
"field": "resources.type",
"equals": [
"AWS::Lambda::Function"
]
},
{
"field": "resources.ARN",
"equals": [
"arn:aws:lambda:us-east-1:111122223333:function:hello-world"
]
}
]
}
]
```
## Eventos de gerenciamento do Lambda no CloudTrail
Os [Eventos de gerenciamento](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events) fornecem informações sobre operações de gerenciamento executadas em recursos na sua Conta da AWS. Elas também são conhecidas como operações de ambiente de gerenciamento. Por padrão, o CloudTrail registra eventos de gerenciamento em logs.
O Lambda oferece suporte ao registro das seguintes ações como eventos de gerenciamento nos arquivos de log do CloudTrail.
**nota**
No arquivo de log do CloudTrail, o `eventName` pode incluir informações como data e versão, mas ainda está se referindo à mesma ação de API. Por exemplo, a ação `GetFunction` aparece como `GetFunction20150331v2`. A lista a seguir especifica quando o nome do evento é diferente do nome da ação da API.
+ [AddLayerVersionPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)
+ [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) (nome do evento: `AddPermission20150331v2`)
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html) (nome do evento: `CreateAlias20150331`)
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) (nome do evento: `CreateEventSourceMapping20150331`)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) (nome do evento: `CreateFunction20150331`)
(Os parâmetros `Environment` e `ZipFile` são omitidos dos logs do CloudTrail para `CreateFunction`.)
+ [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html) (nome do evento: `DeleteAlias20150331`)
+ [DeleteCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteCodeSigningConfig.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html) (nome do evento: `DeleteEventSourceMapping20150331`)
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html) (nome do evento: `DeleteFunction20150331`)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html) (nome do evento: `DeleteFunctionConcurrency20171031`)
+ [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html) (nome do evento: `GetAlias20150331`)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetLayerVersionPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetLayerVersionPolicy.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)
+ [ListFunctionUrlConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionUrlConfigs.html)
+ [PublishLayerVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html) (nome do evento: `PublishLayerVersion20181031`)
(O parâmetro `ZipFile` é omitido dos logs do CloudTrail para `PublishLayerVersion`.)
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) (nome do evento: `PublishVersion20150331`)
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html) (nome do evento: `PutFunctionConcurrency20171031`)
+ [PutFunctionCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionCodeSigningConfig.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html)
+ [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html) (nome do evento: `RemovePermission20150331v2`)
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) (nome do evento: `TagResource20170331v2`)
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) (nome do evento: `UntagResource20170331v2`)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html) (nome do evento: `UpdateAlias20150331`)
+ [UpdateCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateCodeSigningConfig.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) (nome do evento: `UpdateEventSourceMapping20150331`)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) (nome do evento: `UpdateFunctionCode20150331v2`)
(O parâmetro `ZipFile` é omitido dos logs do CloudTrail para `UpdateFunctionCode`.)
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) (nome do evento: `UpdateFunctionConfiguration20150331v2`)
(O parâmetro `Environment` é omitido dos logs do CloudTrail para `UpdateFunctionConfiguration`.)
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
+ [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html)
## Usar o CloudTrail para solucionar problemas de origens de eventos do Lambda desabilitadas
Quando você altera o estado de um mapeamento da origem do evento usando a ação de API [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html), a chamada de API é registrada em log como um evento de gerenciamento do CloudTrail. Os mapeamentos de origens de eventos também podem passar diretamente para o estado `Disabled` devido a erros.
Para os seguintes serviços, o Lambda publica o evento de dados `LambdaESMDisabled` no CloudTrail quando a origem dos eventos passa para o estado Desativado:
+ Amazon Simple Queue Service (Amazon SQS)
+ Amazon DynamoDB
+ Amazon Kinesis
O Lambda não é compatível com esse evento para nenhum outro tipo de mapeamento da origem do evento.
Para receber alertas quando os mapeamentos das origens dos eventos dos serviços compatíveis passarem para o estado `Disabled`, configure um alarme no Amazon CloudWatch usando o evento `LambdaESMDisabled` do CloudTrail. Para obter mais informações sobre a configuração de um alarme do CloudWatch, consulte [Creating CloudWatch alarms for CloudTrail events: examples](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html).
A entidade `serviceEventDetails` na mensagem do evento `LambdaESMDisabled` contém um dos códigos de erro a seguir.
**`RESOURCE_NOT_FOUND`**
O recurso especificado na solicitação não existe.
**`FUNCTION_NOT_FOUND`**
A função anexada à fonte de evento não existe.
**`REGION_NAME_NOT_VALID`**
O nome de uma região fornecido para a função ou para a fonte de evento é inválido.
**`AUTHORIZATION_ERROR`**
As permissões não foram definidas ou estão configuradas incorretamente.
**`FUNCTION_IN_FAILED_STATE`**
O código da função não compila, encontrou uma exceção irrecuperável ou ocorreu uma implantação incorreta.
## Exemplos de eventos do Lambda
Um evento representa uma única solicitação de qualquer origem e inclui informações sobre a operação solicitada, a data e a hora da operação da API, os parâmetros de solicitação etc. Os arquivos de log do CloudTrail não são um rastreamento de pilha ordenada de chamadas de API pública, portanto não são exibidos em uma ordem específica.
O exemplo a seguir mostra entradas de log do CloudTrail que demonstram as ações `GetFunction` e `DeleteFunction`.
**nota**
O `eventName` pode incluir informações como data e versão, como `"GetFunction20150331"`, mas ainda está se referindo à mesma API pública.
```
{
"Records": [
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:03:36Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "GetFunction",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::111122223333:user/myUserName is not authorized to perform: lambda:GetFunction on resource: arn:aws:lambda:us-west-2:111122223333:function:other-acct-function",
"requestParameters": null,
"responseElements": null,
"requestID": "7aebcd0f-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "e92a3e85-8ecd-4d23-8074-843aabfe89bf",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
},
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:04:42Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "DeleteFunction20150331",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"requestParameters": {
"functionName": "basic-node-task"
},
"responseElements": null,
"requestID": "a2198ecc-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "20b84ce5-730f-482e-b2b2-e8fcc87ceb22",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
]
}
```
Para obter informações sobre o conteúdo dos registros do CloudTrail, consulte [Conteúdo dos registros do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html) no *Guia do usuário do AWS CloudTrail*.
# Visualizar as invocações da função do Lambda usando o AWS X-Ray
Você pode usar o AWS X-Ray para visualizar os componentes do aplicativo, identificar gargalos de performance e solucionar problemas de solicitações que resultaram em um erro. Suas funções do Lambda enviam dados de rastreamento para o X-Ray, e o X-Ray processa os dados para gerar um mapa de serviço e resumos de rastreamento pesquisáveis.
O Lambda aceita dois modos de rastreamento para o X-Ray: `Active` e `PassThrough`. Com o rastreamento `Active`, o Lambda cria automaticamente segmentos de rastreamento para invocações de funções e os envia para o X-Ray. O modo `PassThrough`, por outro lado, simplesmente propaga o contexto de rastreamento para os serviços subsequentes. Se você tiver habilitado o rastreamento `Active` para a função, o Lambda enviará automaticamente rastreamentos para o X-Ray para solicitações amostradas. Normalmente, um serviço antecedente, como o Amazon API Gateway, ou uma aplicação hospedada no Amazon EC2 que é instrumentada com o SDK do X-Ray, decide se as solicitações recebidas devem ser rastreadas, depois adiciona essa decisão de amostragem como um cabeçalho de rastreamento. O Lambda usa esse cabeçalho para decidir enviar ou não rastreamentos. Os rastreamentos de produtores de mensagens upstream, como o Amazon SQS, são vinculados automaticamente aos rastreamentos de funções do Lambda downstream, o que cria uma visão completa de toda a aplicação. Para obter mais informações, consulte [Tracing event-driven applications](https://docs.aws.amazon.com//xray/latest/devguide/xray-tracelinking.html) (Rastreamento de aplicações orientadas a eventos) no *Guia do desenvolvedor do AWS X-Ray*.
**nota**
Atualmente, o rastreamento do X-Ray não oferece suporte a funções do Lambda com o Amazon Managed Streaming for Apache Kafka (Amazon MSK), Apache Kafka autogerenciado, Amazon MQ com ActiveMQ e RabbitMQ ou mapeamentos da origem do evento do Amazon DocumentDB.
Para alternar o rastreamento ativo na sua função do Lambda usando o console, siga as etapas abaixo:
**Para ativar o rastreamento ativo**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha uma função.
1. Escolha **Configuration** (Configuração) e depois **Monitoring and operations tools** (Ferramentas de monitoramento e operações).
1. Em **Ferramentas de monitoramento adicionais**, selecione **Editar**.
1. Em **CloudWatch Application Signals e AWS X-Ray**, escolha **Habilitar** para **Rastreamentos do serviço Lambda**.
1. Escolha **Salvar**.
Sua função precisa de permissão para carregar dados de rastreamento no X-Ray. Quando você ativa o rastreamento ativo no console do Lambda, o Lambda adiciona as permissões necessárias à [função de execução](lambda-intro-execution-role.md) da função. Caso contrário, adicione a política [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess) à função de execução.
O X-Ray não rastreia todas as solicitações para sua aplicação. O X-Ray aplica um algoritmo de amostragem para garantir que o rastreamento seja eficiente, enquanto ainda fornece uma amostra representativa das solicitações. A taxa de amostragem é uma solicitação por segundo e 5% de solicitações adicionais. Você não pode configurar a taxa de amostragem do X-Ray para suas funções.
## Noções básicas sobre rastreamentos do X-Ray
No X-Ray, um *rastreamento* registra informações sobre uma solicitação que é processada por um ou mais *serviços*. O Lambda registra dois segmentos por rastreamento, o que cria dois nós no gráfico de serviços. A imagem a seguir destaca esses dois nós:
![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/xray-servicemap-function.png)
O primeiro nó à esquerda representa o serviço do Lambda, que recebe a solicitação de invocação. O segundo nó representa a sua função do Lambda específica.
O segmento registrado para o serviço Lambda, `AWS::Lambda`, abrange todas as etapas necessárias para preparar o ambiente de execução do Lambda. Isso inclui agendar o microVM, criar ou descongelar um ambiente de execução com os recursos que você configurou e baixar o código e todas as camadas da função .
O segmento `AWS::Lambda::Function` é para o trabalho realizado pela função.
**nota**
A AWS atualmente está implementando alterações no serviço Lambda. Devido a essas alterações, você pode ver pequenas diferenças entre a estrutura e o conteúdo das mensagens de log do sistema e os segmentos de rastreamento emitidos por diferentes funções do Lambda na sua Conta da AWS.
Essa alteração afeta os subsegmentos do segmento da função. Os parágrafos a seguir descrevem o formato antigo e formato novo desses subsegmentos.
Essas alterações serão implementadas durante as próximas semanas, e todas as funções em todas as Regiões da AWS, exceto nas regiões China e GovCloud, passarão a usar o novo formato de mensagens de log e segmentos de rastreamento.
**Estrutura de segmentos do Lambda AWS X-Ray no estilo antigo**
A estrutura do X-Ray no estilo antigo para o segmento `AWS::Lambda` é assim:
![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/V2_sandbox_images/v1_XRay_structure.png)
Nesse formato, o segmento da função tem subsegmentos para `Initialization`, `Invocation` e `Overhead`. Somente para [Lambda SnapStart](snapstart.md), existe também um subsegmento `Restore` (não mostrado nesse diagrama).
O subsegmento `Initialization` representa a fase inicial do ciclo de vida do ambiente de execução do Lambda. Durante essa fase, Lambda inicializa as extensões, inicializa o runtime e executa o código de inicialização da função.
O subsegmento `Invocation` representa a fase de chamada em que o Lambda chama o manipulador de função. Isso começa com o registro do runtime e da extensão e termina quando o runtime está pronto para enviar a resposta.
(Lambda SnapStart apenas) O subsegmento `Restore` mostra o tempo necessário para o Lambda restaurar um snapshot, carregar o runtime e executar todos os [hooks de runtime](snapstart-runtime-hooks.md) after-restore. O processo de restauração de snapshots pode incluir o tempo gasto em atividades fora da MicroVM. Esse tempo é relatado no subsegmento `Restore`. Você não é cobrado pelo tempo gasto fora da microVM para restaurar um snapshot.
O subsegmento `Overhead` representa a fase que ocorre entre o momento em que o runtime envia a resposta e o sinal para a próxima chamada. Durante esse período, o runtime termina todas as tarefas relacionadas a uma chamada e se prepara para congelar o sandbox.
**Importante**
Você pode usar o SDK do X-Ray para estender o subsegmento `Invocation` com subsegmentos adicionais para anotações, metadados e chamadas downstream. Não é possível acessar o segmento de função diretamente nem registrar trabalhos feitos fora do escopo de chamada do manipulador.
Para obter mais informações sobre as fases do ambiente de execução do Lambda, consulte [Noções básicas sobre o ciclo de vida do ambiente de execução do Lambda](lambda-runtime-environment.md).
Um exemplo de rastreamento usando a estrutura de X-Ray no estilo antigo é mostrado no diagrama a seguir.
![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Observe os dois segmentos do exemplo. Ambos têm o nome **my-function**, mas um tem a origem `AWS::Lambda` e o outro, a origem `AWS::Lambda::Function`. Se o segmento `AWS::Lambda` mostrar um erro, o serviço Lambda teve um problema. Se o segmento `AWS::Lambda::Function` mostrar um erro, sua função teve um problema.
**nota**
Ocasionalmente, é possível notar um grande intervalo entre as fases de inicialização e de invocação da função em seus rastreamentos do X-Ray. Para as funções que usam a [simultaneidade provisionada](provisioned-concurrency.md), isso ocorre pelo Lambda inicializar as instâncias de função com bastante antecedência à invocação. Para as funções que usam a [simultaneidade não reservada (sob demanda)](lambda-concurrency.md), o Lambda pode inicializar proativamente uma instância de função, mesmo que não haja invocação. Visualmente, ambos os casos apresentam um intervalo de tempo entre as fases de inicialização e de invocação.
**Estrutura de segmentos AWS X-Ray do Lambda no estilo novo**
A estrutura do X-Ray no estilo novo para o segmento `AWS::Lambda` é assim:
![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/V2_sandbox_images/v2_XRay_structure.png)
Nesse novo formato, o subsegmento `Init` representa a fase de inicialização do ciclo de vida do ambiente de execução do Lambda.
Não há segmento de invocação no novo formato. Em vez disso, os subsegmentos dos clientes são anexados diretamente ao segmento `AWS::Lambda::Function`. Esse segmento contém as seguintes métricas como anotações:
+ `aws.responseLatency`: o tempo necessário para a função ser executada
+ `aws.responseDuration`: o tempo necessário para transferir a resposta para o cliente
+ `aws.runtimeOverhead`: o tempo adicional de que o runtime precisou para ser concluído
+ `aws.extensionOverhead`: o tempo adicional de que as extensões precisaram para serem concluídas
Um exemplo de rastreamento usando a estrutura de X-Ray no estilo novo é mostrado no diagrama a seguir.
![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v2.png)
Observe os dois segmentos do exemplo. Ambos têm o nome **my-function**, mas um tem a origem `AWS::Lambda` e o outro, a origem `AWS::Lambda::Function`. Se o segmento `AWS::Lambda` mostrar um erro, o serviço Lambda teve um problema. Se o segmento `AWS::Lambda::Function` mostrar um erro, sua função teve um problema.
Consulte os tópicos a seguir para obter uma introdução específica de uma linguagem ao rastreamento no Lambda:
+ [Instrumentação do código Node.js no AWS Lambda](nodejs-tracing.md)
+ [Instrumentação do código Python no AWS Lambda](python-tracing.md)
+ [Instrumentar o código Ruby no AWS Lambda](ruby-tracing.md)
+ [Instrumentação do código Java no AWS Lambda](java-tracing.md)
+ [Instrumentação do código Go no AWS Lambda](golang-tracing.md)
+ [Instrumentar o código C \$1 no AWS Lambda](csharp-tracing.md)
Para obter uma lista completa de serviços que oferecem suporte à instrumentação ativa, consulte [Serviços da AWS compatíveis](https://docs.aws.amazon.com/xray/latest/devguide/xray-usage.html#xray-usage-codechanges) no Guia do desenvolvedor do AWS X-Ray.
## Comportamento de rastreamento padrão do Lambda
Se você não tiver ativado o rastreamento `Active`, o Lambda usará o modo de rastreamento `PassThrough` por padrão.
No modo `PassThrough`, o Lambda encaminha o cabeçalho de rastreamento do X-Ray para os serviços subsequentes, mas não envia os rastreamentos automaticamente. Isso ocorre mesmo que o cabeçalho de rastreamento contenha uma decisão de amostrar a solicitação. Se o serviço antecedente não fornecer um cabeçalho de rastreamento do X-Ray, o Lambda gerará um cabeçalho e tomará a decisão de não fazer a amostragem. Porém, você pode enviar seus próprios rastreamentos chamando bibliotecas de rastreamento no código da função.
**nota**
Anteriormente, o Lambda enviava rastreamentos automaticamente quando os serviços antecedentes, como o Amazon API Gateway, adicionavam um cabeçalho de rastreamento. Não enviando rastreamentos automaticamente, o Lambda dá a você o controle para rastrear as funções que considerar importantes para si. Se a solução depender desse comportamento de rastreamento passivo, alterne para o rastreamento `Active`.
## Permissões da função de execução
O Lambda precisa das permissões a seguir para enviar dados de rastreamento para o X-Ray. Adicione-as à [função de execução](lambda-intro-execution-role.md) da sua função.
+ [xray:PutTraceSegments](https://docs.aws.amazon.com/xray/latest/api/API_PutTraceSegments.html)
+ [xray:PutTelemetryRecords](https://docs.aws.amazon.com/xray/latest/api/API_PutTelemetryRecords.html)
Essas permissões estão incluídas na política gerenciada [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess).
## Habilitar o rastreamento `Active` com a API do Lambda
Para gerenciar a configuração de rastreamento com a AWS CLI ou com o AWS SDK, use as seguintes operações de API:
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
O exemplo de comando da AWS CLI a seguir habilita o rastreamento ativo em uma função chamada **my-function**.
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
O modo de rastreamento faz parte da configuração específica da versão quando você publica uma versão da função. Não é possível alterar o modo de rastreamento em uma versão publicada.
## Habilitar o rastreamento `Active` com o CloudFormation
Para ativar o rastreamento ativo em um recurso `AWS::Lambda::Function` em um modelo do CloudFormation, use a propriedade `TracingConfig`.
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml): configuração de rastreamento**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Para um recurso do AWS Serverless Application Model (AWS SAM) `AWS::Serverless::Function`, use a propriedade `Tracing`.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml): configuração de rastreamento**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
# Monitorar a performance de funções com o Lambda Insights do Amazon CloudWatch
O Lambda Insights do Amazon CloudWatch coleta e agrega métricas e logs de performance do tempo de execução da função do Lambda para as aplicações sem servidor. Esta página descreve como ativar e usar o Lambda Insights para diagnosticar problemas em suas funções do Lambda.
**Topics**
+ [Como o Lambda Insights monitora aplicações sem servidor](#monitoring-insights-how)
+ [Preços](#monitoring-insights-pricing)
+ [Tempos de execução compatíveis](#monitoring-insights-runtimes)
+ [Ativar o Lambda Insights no console do Lambda](#monitoring-insights-enabling-console)
+ [Ativação do Lambda Insights por programação](#monitoring-insights-enabling-programmatically)
+ [Usando o painel do Lambda Insights](#monitoring-insights-multifunction)
+ [Exemplo de fluxo de trabalho para detectar anomalias de função](#monitoring-insights-anomalies)
+ [Exemplo de fluxo de trabalho usando consultas para solucionar problemas de uma função](#monitoring-insights-queries)
+ [Próximas etapas](#monitoring-console-next-up)
## Como o Lambda Insights monitora aplicações sem servidor
O Lambda Insights do CloudWatch Lambda é uma solução de monitoramento e solução de problemas para aplicações sem servidor em execução no AWS Lambda. A solução coleta, agrega e resume métricas no nível do sistema, incluindo tempo da CPU, memória, disco e uso da rede. Ele também coleta, agrega e resume informações de diagnóstico, como inicializações a frio e desligamentos do operador do Lambda para ajudar a isolar problemas com as funções do Lambda e resolvê-los rapidamente.
Lambda Insights usa um novo CloudWatch Lambda Insights[extensão](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html), que é fornecido como um[Lambda](chapter-layers.md). Quando você habilita essa extensão em uma função do Lambda para um runtime compatível, ela coleta métricas no nível do sistema e emite um único evento de log de performance para cada invocação dessa função do Lambda. O CloudWatch usa formatação métrica incorporada para extrair métricas dos eventos de log. Para obter mais informações, consulte [Usar extensões do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html).
A camada do Lambda Insights estende `CreateLogStream` e `PutLogEvents` para o grupo de logs `/aws/lambda-insights/`.
## Preços
Quando você habilita o Lambda Insights para sua função do Lambda, o Lambda Insights relata 8 métricas por função e cada invocação de função envia cerca de 1 KB de dados de log para o CloudWatch. Você paga apenas pelas métricas e logs relatados para sua função pelo Lambda Insights. Não há tarifas mínimas nem políticas de uso obrigatório do serviço. Você não paga pelo Lambda Insights se a função não for invocada. Para obter um exemplo de preço, consulte [Preço do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
## Tempos de execução compatíveis
Você pode usar o Lambda Insights com qualquer um dos tempos de execução que oferecem suporte para [extensões do Lambda](runtimes-extensions-api.md).
## Ativar o Lambda Insights no console do Lambda
É possível habilitar o monitoramento aprimorado do Lambda Insights em funções do Lambda novas e existentes. Quando você ativa o Lambda Insights em uma função no console do Lambda para um runtime compatível, o Lambda adiciona a [extensão](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) do Lambda Insights à sua função como uma camada e verifica ou tenta associar a política [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) à [função de execução](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) da função.
**Para habilitar o Lambda Insights no console do Lambda**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha a função.
1. Escolha a guia **Configuração**.
1. No menu à esquerda, escolha **Ferramentas de monitoramento e operações**.
1. No painel **Ferramentas de monitoramento adicionais**, selecione **Editar**.
1. Em **Lambda Insights do CloudWatch**, ative o **Monitoramento avançado**.
1. Escolha **Salvar**.
## Ativação do Lambda Insights por programação
Também é possível habilitar o Lambda Insights usando a AWS Command Line Interface (AWS CLI), a CLI do AWS Serverless Application Model (SAM), o CloudFormation ou o AWS Cloud Development Kit (AWS CDK). Quando você habilita o Lambda Insights programaticamente em uma função para um runtime compatível, o CloudWatch associa a política [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) à [função de execução](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) da sua função.
Para obter mais informações, consulte [Conceitos básicos do Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-Getting-Started.html) no *Manual do usuário do Amazon CloudWatch*.
## Usando o painel do Lambda Insights
O painel do Lambda Insights tem duas exibições no console do CloudWatch: a visão geral de várias funções e a exibição de função única. A visão geral de várias funções agrega as métricas de tempo de execução para as funções do Lambda na conta e na região atual da AWS. A visualização de função única mostra as métricas de tempo de execução disponíveis para uma única função do Lambda.
É possível usar a visão geral multifuncional do painel do Lambda Insights no console do CloudWatch para identificar funções do Lambda usadas em excesso e subutilizadas. É possível usar a visualização de função única do painel do Lambda Insights no console do CloudWatch para solucionar problemas de solicitações individuais.
**Como visualizar as métricas de tempo de execução de todas as funções**
1. Abra a página [Multi-funcion](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) (Várias funções) no console do CloudWatch.
1. Escolha entre os intervalos de tempo predefinidos ou escolha um intervalo de tempo personalizado.
1. (Opcional) Selecione **Add to dashboard** (Adicionar ao painel) para adicionar os widgets ao painel do CloudWatch.
![\[A visão geral de várias funções no painel do Lambda Insights.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/lambdainsights-multifunction-view.png)
**Como visualizar as métricas de tempo de execução de uma única função**
1. Abra a página [Single-funcion](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions) (Função única) no console do CloudWatch.
1. Escolha entre os intervalos de tempo predefinidos ou escolha um intervalo de tempo personalizado.
1. (Opcional) Selecione **Add to dashboard** (Adicionar ao painel) para adicionar os widgets ao painel do CloudWatch.
![\[A visualização de função única no painel Lambda Insights.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/lambainsights-singlefunction-view.png)
Para obter mais informações, consulte [Criar e trabalhar com widgets em painéis do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html).
## Exemplo de fluxo de trabalho para detectar anomalias de função
É possível usar a visão geral de várias funções no painel Lambda Insights para identificar e detectar anomalias de memória computacional com a função. Por exemplo, se a visão geral de várias funções indicar que uma função está usando uma grande quantidade de memória, você poderá visualizar métricas detalhadas de utilização da memória no painel **Memory Usage (Uso de memória)**. Depois, você pode acessar o painel de métricas para habilitar a detecção de anomalias ou criar um alarme.
**Como habilitar a detecção de anomalias para uma função**
1. Abra a página [Multi-funcion](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) (Várias funções) no console do CloudWatch.
1. Em **Function summary (Resumo da função)**, escolha o nome da função.
A visualização de função única é aberta com as métricas de tempo de execução da função.
![\[O painel de resumo da função no painel Lambda Insights.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/lambdainsights-function-summary.png)
1. No painel **Memory Usage (Uso de memória)**, selecione os três pontos na vertical e selecione **View in metrics (Visualizar nas métricas)** para abrir o painel **Metrics (Métricas)**.
![\[O menu no painel Memory Usage (Uso de memória).\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/lambdainsights-memory-usage.png)
1. Na guia **Graphed metrics (Métricas em gráficos)**, na coluna **Actions (Ações)**, selecione o primeiro ícone para habilitar a detecção de anomalias da função.
![\[A guia Graphed metrics (Métricas em gráficos) do painel Memory Usage (Uso de memória).\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/lambdainsights-graphed-metrics.png)
Para obter mais informações, consulte [Usar a detecção de anomalias do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html).
## Exemplo de fluxo de trabalho usando consultas para solucionar problemas de uma função
É possível usar a visualização de função única no painel Lambda Insights para identificar a causa raiz de um pico na duração da função. Por exemplo, se a visão geral de várias funções indicar um grande aumento na duração da função, você poderá pausar ou escolher cada função no painel **Duration (Duração)** para determinar qual função está causando o aumento. Depois, você pode acessar a visualização de função única e revisar os **Application logs (Logs de aplicações)** para determinar a causa raiz.
**Como executar consultas em uma função**
1. Abra a página [Multi-funcion](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) (Várias funções) no console do CloudWatch.
1. No painel **Duration (Duração)**, selecione a função para filtrar as métricas de duração.
![\[Uma função selecionada no painel Duration (Duração).\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/lambdainsights-choose-function.png)
1. Abra a página [Função única](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions).
1. Selecione a lista suspensa **Filter metrics by function name (Filtrar métricas por nome da função)** e selecione a função.
1. Para visualizar os **Most recent 1000 application logs (1000 logs de aplicações mais recentes)**, selecione a guia **Application logs (Logs de aplicações)**.
1. Revise o **Timestamp (Time stamp)** e a **Message (Mensagem)** para identificar a solicitação de invocação que você deseja solucionar.
![\[Os Most recent 1000 application logs (1000 logs de aplicações mais recentes).\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/lambdainsights-application-logs.png)
1. Para mostrar as **Most recent 1000 invocations (1000 invocações mais recentes)**, selecione a guia **Invocations (Invocações)**.
1. Selecione o **Timestamp (Time stamp)** ou a **Message (Mensagem)** para a solicitação de invocação que você deseja solucionar.
![\[Seleção de uma solicitação de invocação recente.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/lambdainsights-invocations-function-select.png)
1. Selecione a lista suspensa **View logs (Visualizar logs)** e, depois, selecione **View performance logs (Visualizar logs de performance)**.
Uma consulta gerada automaticamente para a função é aberta no painel do **Logs Insights**.
1. Selecione **Run query (Executar consulta)** para gerar uma mensagem **Logs** para a solicitação de invocação.
![\[Consulta da função selecionada no painel Logs Insights.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/lambdainsights-query.png)
## Próximas etapas
+ Saiba como criar um painel do CloudWatch Logs no[Criar um painel](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)no*Guia do usuário do Amazon CloudWatch*.
+ Saiba como adicionar consultas a um painel do CloudWatch Logs em [Adicionar consulta ao painel ou exportar resultados de consulta](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) no *Manual do usuário do Amazon CloudWatch*.
# Monitorar aplicações do Lambda
A seção **Aplicações** do console do Lambda inclui uma guia **Monitoramento** onde você pode ver um painel do Amazon CloudWatch com as métricas agregadas dos recursos da sua aplicação.
**Para monitorar uma aplicação do Lambda**
1. Abra a [página Applications](https://console.aws.amazon.com/lambda/home#/applications) (Aplicações) do console do Lambda.
1. Escolha **Monitoramento**.
1. Para ver mais detalhes sobre as métricas em qualquer gráfico, escolha **Visualizar em métricas** no menu suspenso.
![\[Um widget de monitoramento.\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/applications-monitoring-widget.png)
O gráfico é exibido em uma nova guia, com as métricas relevantes listadas abaixo do gráfico. Personalize a exibição desse gráfico, alterando as métricas e os recursos mostrados, a estatística, o período e outros fatores para obter uma compreensão melhor da situação atual.
Por padrão, o console do Lambda mostra um painel básico. Você pode personalizar essa página adicionando um ou mais painéis do Amazon CloudWatch ao seu modelo de aplicação com o tipo de recurso [AWS::CloudWatch::Dashboard](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-dashboard.html). Quando seu template inclui um ou mais painéis, a página mostra seus painéis em vez do painel padrão. Você pode alternar entre painéis com o menu suspenso no canto superior direito da página. O exemplo a seguir cria um painel com um único widget que representa graficamente o número de invocações de uma função denominada `my-function`.
**Example modelo de painel de função**
```
Resources:
MyDashboard:
Type: AWS::CloudWatch::Dashboard
Properties:
DashboardName: my-dashboard
DashboardBody: |
{
"widgets": [
{
"type": "metric",
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/Lambda",
"Invocations",
"FunctionName",
"my-function",
{
"stat": "Sum",
"label": "MyFunction"
}
],
[
{
"expression": "SUM(METRICS())",
"label": "Total Invocations"
}
]
],
"region": "us-east-1",
"title": "Invocations",
"view": "timeSeries",
"stacked": false
}
}
]
}
```
Para obter mais informações sobre como criar painéis e widgets do CloudWatch, consulte [Estrutura e sintaxe do corpo do painel](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html) na *Referência de API do Amazon CloudWatch*.
# Monitoramento da performance de aplicações com o Amazon CloudWatch Application Signals
O Amazon CloudWatch Application Signals é uma solução de monitoramento de performance de aplicações (APM) que permite aos desenvolvedores e operadores monitorar a integridade e a performance de suas aplicações com tecnologia sem servidor criadas por meio do Lambda. Você pode habilitar o Application Signals com um clique no console do Lambda e não precisa adicionar nenhum código de instrumentação nem dependências externas à sua função do Lambda. Depois de habilitar o Application Signals, você pode exibir todas as métricas e rastreamentos coletados no console do CloudWatch. Esta página descreve como habilitar e exibir os dados de telemetria do Application Signals para suas aplicações.
**Topics**
+ [Como o Application Signals se integra ao Lambda](#monitoring-application-signals-how)
+ [Preços](#monitoring-application-signals-pricing)
+ [Tempos de execução compatíveis](#monitoring-application-signals-runtimes)
+ [Habilitação do Application Signals no console do Lambda](#monitoring-application-signals-console)
+ [Uso do painel do Application Signals](#monitoring-application-signals-dashboard)
## Como o Application Signals se integra ao Lambda
O Application Signals instrumenta automaticamente suas funções do Lambda usando bibliotecas aprimoradas do [AWS Distro para OpenTelemetry (ADOT)](https://aws-otel.github.io/), fornecidas por meio de uma [camada do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html). O Application Signals lê os dados coletados pela camada e gera painéis com as principais métricas de performance para suas aplicações.
Você pode anexar essa camada com um clique [habilitando o Application Signals](#monitoring-application-signals-console) no console do Lambda. Quando você habilita o Application Signals pelo console, o Lambda executa as seguintes ações em seu nome:
+ Atualiza o perfil de execução da função para incluir a `CloudWatchLambdaApplicationSignalsExecutionRolePolicy`. [ Esta política](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.html) fornece acesso de gravação ao AWS X-Ray e aos grupos de log do CloudWatch usados para o Application Signals.
+ Adiciona uma camada à sua função que instrumenta automaticamente a função para capturar dados de telemetria, como solicitações, disponibilidade, latência, erros e falhas. Para garantir que o Application Signals funcione corretamente, remova qualquer código de instrumentação do SDK do X-Ray existente da sua função. O código de instrumentação personalizado do SDK do X-Ray pode interferir na instrumentação fornecida pela camada.
+ Adiciona a variável de ambiente `AWS_LAMBDA_EXEC_WRAPPER` à função e define seu valor como `/opt/otel-instrument`. Essa variável de ambiente modifica o comportamento de startup da função para utilizar a camada do Application Signals e é necessária para garantir uma instrumentação adequada. Se essa variável de ambiente já existir, verifique se ela está definida com o valor necessário.
## Preços
O uso do Application Signals para suas funções do Lambda incorre em custos. Para obter informações sobre preço, consulte [Preços do Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
## Tempos de execução compatíveis
A integração do Application Signals com o Lambda funciona com os seguintes runtimes:
+ .NET 8
+ Java 11
+ Java 17
+ Java 21
+ Python 3.10
+ Python 3.11
+ Python 3.12
+ Python 3.13
+ Node.js 18.x
+ Node.js 20.x
+ Node.js 22.x
## Habilitação do Application Signals no console do Lambda
Você pode habilitar o Application Signals em qualquer função do Lambda existente usando um [runtime compatível](#monitoring-application-signals-runtimes). As etapas a seguir descrevem como habilitar o Application Signals com um clique no console do Lambda.
**Para habilitar o Application Signals no console do Lambda**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha a função.
1. Escolha a guia **Configuração**.
1. No menu à esquerda, escolha **Ferramentas de monitoramento e operações**.
1. No painel **Ferramentas de monitoramento adicionais**, selecione **Editar**.
1. Em **CloudWatch Application Signals e AWS X-Ray**, em **Application Signals**, escolha **Habilitar**.
1. Escolha **Salvar**.
Se esta é a primeira vez que habilita o Application Signals para sua função, você também deverá fazer uma configuração única de descoberta de serviços para o Application Signals no console do CloudWatch. Depois de concluir essa configuração única de descoberta de serviços, o Application Signals descobre automaticamente todas as funções adicionais do Lambda para as quais você habilitar o Application Signals, em todas as regiões.
**nota**
Depois de invocar sua função atualizada, pode levar até dez minutos para que os dados do serviço comecem a aparecer no painel do Application Signals no console do CloudWatch.
## Uso do painel do Application Signals
Depois de habilitar o Application Signals para sua função, você pode exibir as métricas da sua aplicação no console do CloudWatch. Você pode conferir rapidamente o painel do Application Signals associado no console do Lambda seguindo estas etapas:
**Para exibir o painel do Application Signals para sua função**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home#/functions) do console do Lambda.
1. Escolha a função.
1. Escolha a guia **Monitor** (Monitorar).
1. Escolha o botão **Visualizar o Application Signals**. Isso leva você diretamente à visão geral do Application Signals do seu serviço no console do CloudWatch.
Por exemplo, a captura de tela a seguir mostra métricas de latência, número de solicitações, disponibilidade, taxa de falhas e taxa de erros de uma função em uma janela de dez minutos.
![\[\]](http://docs.aws.amazon.com/pt_br/lambda/latest/dg/images/monitoring-application-signals-dashboard.png)
Para aproveitar ao máximo a integração com o Application Signals, você pode criar objetivos de nível de serviço (SLOs) para sua aplicação. Por exemplo, você pode criar SLOs de latência, para garantir que sua aplicação responda rapidamente às solicitações de usuários, e SLOs de disponibilidade, para monitorar o tempo de atividade. Os SLOs podem ajudar você a detectar a degradação de performance ou interrupções antes que elas afetem os usuários. Para obter mais informações, consulte [Objetivos de nível de serviço (SLOs)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html) no Guia do usuário do Amazon CloudWatch.
# Depure remotamente as funções do Lambda com o Visual Studio Code
Com o atributo de depuração remota no [AWS Toolkit for Visual Studio Code](https://aws.amazon.com/visualstudiocode/), você pode depurar suas funções do Lambda em execução diretamente na nuvem da AWS. Isso é útil ao investigar problemas que são difíceis de replicar localmente ou diagnosticar somente com logs.
Com a depuração remota, você pode:
+ Definir pontos de interrupção no código da função do Lambda.
+ Analisar a execução do código em tempo real.
+ Inspecionar as variáveis e o estado durante o runtime.
+ Depure as funções do Lambda implantadas para a AWS, incluindo aquelas em VPCs ou com permissões específicas do IAM.
## Tempos de execução compatíveis
A depuração remota é compatível com os seguintes tempos de execução:
+ Python (AL2023)
+ Java
+ JavaScript/Node.js (AL2023)
**nota**
A depuração remota é compatível com arquiteturas x86\$164 e arm64.
## Segurança e depuração remota
A depuração remota opera dentro dos limites de segurança existentes do Lambda. Os usuários podem anexar camadas a uma função usando a permissão `UpdateFunctionConfiguration`, que já tem a capacidade de acessar as variáveis e a configuração do ambiente da função. A depuração remota não se estende além dessas permissões existentes. Em vez disso, ela adiciona controles de segurança extras por meio de tunelamento seguro e gerenciamento automático de sessões. Além disso, a depuração remota é um atributo totalmente controlado pelo cliente que requer permissões e ações explícitas:
+ **Criação de túnel seguro de IoT**: o AWS Toolkit deve criar um túnel seguro de IoT, que só ocorre com a permissão explícita do usuário usando o `iot:OpenTunnel`.
+ **Anexo da camada de depuração e gerenciamento de tokens**: o processo de depuração mantém a segurança por meio desses controles:
+ A camada de depuração deve ser anexada à função do Lambda e esse processo requer as seguintes permissões: `lambda:UpdateFunctionConfiguration` e `lambda:GetLayerVersion`.
+ Um token de segurança (gerado via `iot:OpenTunnel`) deve ser atualizado na variável de ambiente da função antes de cada sessão de depuração, o que também exige `lambda:UpdateFunctionConfiguration`.
+ Por segurança, esse token é rotacionado automaticaplamente e a camada de depuração é removida automaticamente no final de cada sessão de depuração e não pode ser reutilizada.
**nota**
A depuração remota é compatível com arquiteturas x86\$164 e arm64.
## Pré-requisitos
Antes de iniciar a depuração remota, certifique-se de ter o seguinte:
1. Uma função do Lambda implantada em sua conta AWS.
1. AWS Toolkit for Visual Studio Code: Para obter as instruções de instalação, consulte [Como configurar o AWS Toolkit for Visual Studio Code](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/setup-toolkit.html).
1. A versão do AWS Toolkit que você instalou é a **3.69.0** ou mais recente.
1. Credenciais da AWS configuradas no AWS Toolkit for Visual Studio Code. Para obter mais informações, consulte [Autenticação e controle de acesso](foundation-iac-local-development.md#lambda-functions-vscode-authentication-and-access-control).
## Depure remotamente as funções do Lambda
Siga estas etapas para iniciar uma sessão de depuração remota:
1. Abra o AWS Explorer no VS Code selecionando o ícone da AWSna barra lateral esquerda.
1. Expanda a seção Lambda para ver suas funções.
1. Clique com o botão direito do mouse na função que você deseja depurar.
1. No menu de contexto, selecione **Invocar remotamente**.
1. Na janela de invocação que se abre, marque a caixa **Habilitar depuração**.
1. Clique em **Invocar** para iniciar a sessão de depuração remota.
**nota**
As funções do Lambda têm um limite combinado de 250 MB para o código da função e todas as camadas anexadas. A camada de depuração remota adiciona aproximadamente 40 MB ao tamanho da sua função.
Uma sessão de depuração remota termina quando você:
+ Escolhe **Remover Configuração de Depuração** na tela de configuração de invocação remota.
+ Seleciona o ícone de desconexão nos controles de depuração do VS Code.
+ Seleciona o arquivo do manipulador no editor do VS Code.
**nota**
A camada de depuração é removida automaticamente após 60 segundos de inatividade após sua última invocação.
## Desabilite a depuração remota
Há três maneiras de desabilitar esse atributo:
+ **Negar atualizações da função**: defina `lambda:UpdateFunctionConfiguration` como `deny`.
+ **Restrinja as permissões de IoT** negue permissões relacionadas à IoT
+ **Bloquear camadas de depuração**: negue `lambda:GetLayerVersion` para os seguintes ARNs:
+ `arn:aws:lambda:*:*:layer:LDKLayerX86:*`
+ `arn:aws:lambda:*:*:layer:LDKLayerArm64:*`
**nota**
A desabilitação desse atributo impede que a camada de depuração seja adicionada durante as atualizações de configuração da função.
## Mais informações
Para obter mais informações sobre o uso do Lambda no VS Code, consulte [Como desenvolver funções do Lambda localmente com o VS Code](foundation-iac-local-development.md).
Para obter instruções detalhadas sobre solução de problemas, casos de uso avançados e disponibilidade regional, consulte [Depuração remota de funções do Lambda](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) no Guia do usuário do AWS Toolkit for Visual Studio Code.