# 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.