# Monitorar arquivos de log do Amazon Aurora Cada mecanismo de banco de dados do RDS gera logs que você pode acessar para auditoria e solução de problemas. O tipo dos logs depende do mecanismo do banco de dados. É possível acessar os logs de banco de dados para instâncias de banco de dados usando o Console de gerenciamento da AWS, a AWS Command Line Interface (AWS CLI) ou a API do Amazon RDS. Você não pode visualizar, nem monitorar, nem baixar logs de transações. **nota** Em alguns casos, os logs contêm dados ocultos. Portanto, o Console de gerenciamento da AWS pode mostrar o conteúdo em um arquivo de log, mas o arquivo de log pode estar vazio quando você o baixa. **Topics** + [ # Como visualizar e listar arquivos de log do banco de dados ](USER_LogAccess.Procedural.Viewing.md) + [ # Como baixar um arquivo de log de banco de dados ](USER_LogAccess.Procedural.Downloading.md) + [ # Como observar um arquivo de log de banco de dados ](USER_LogAccess.Procedural.Watching.md) + [ # Publicação de logs de banco de dados no Amazon CloudWatch Logs ](USER_LogAccess.Procedural.UploadtoCloudWatch.md) + [ # Leitura do conteúdo de arquivos de log usando REST ](DownloadCompleteDBLogFile.md) + [ # Arquivos de log do banco de dados AuroraMySQL ](USER_LogAccess.Concepts.MySQL.md) + [ # Arquivos de log do banco de dados Aurora PostgreSQL ](USER_LogAccess.Concepts.PostgreSQL.md) # Como visualizar e listar arquivos de log do banco de dados É possível visualizar arquivos de log de banco de dados do mecanismo de banco de dados do Amazon Aurora usando o Console de gerenciamento da AWS. Você pode listar quais arquivos de log estão disponíveis para download ou monitoramento usando a AWS CLI ou a API do Amazon RDS. **nota** Não é possível visualizar os arquivos de log dos clusters de banco de dados do Aurora Serverless v1 no console do RDS. No entanto, você pode visualizá-los no console do Amazon CloudWatch em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). ## Console **Para visualizar um arquivo de log de banco de dados** 1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Escolha o nome da instância de banco de dados que contém o arquivo de log que você deseja visualizar. 1. Escolha a guia **Logs & events (Logs e eventos)**. 1. Role para baixo até a seção **Logs**. 1. (Opcional) Insira um termo de pesquisa para filtrar seus resultados. O exemplo a seguir lista os logs filtrados pelo texto **error**. ![\[Listar logs de banco de dados\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/ListEventsAMS.png) 1. Escolha o log que você deseja visualizar e, depois, **View** (Visualizar). ## AWS CLI Para listar os arquivos de log do banco de dados disponíveis para uma instância de banco de dados, use o comando [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html) da `describe-db-log-files`. O exemplo a seguir retorna uma lista de arquivos de log para uma instância de banco de dados chamada `my-db-instance`. **Example** ``` 1. aws rds describe-db-log-files --db-instance-identifier my-db-instance ``` ## API do RDS Para listar os arquivos de log disponíveis do banco de dados para uma instância de banco de dados, use a ação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) da API do Amazon RDS. # Como baixar um arquivo de log de banco de dados É possível usar o Console de gerenciamento da AWS, a AWS CLI ou a API para baixar um arquivo de log de banco de dados. ## Console **Para baixar um arquivo de log de banco de dados** 1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Escolha o nome da instância de banco de dados que contém o arquivo de log que você deseja visualizar. 1. Escolha a guia **Logs & events (Logs e eventos)**. 1. Role para baixo até a seção **Logs**. 1. Na seção **Logs**, escolha o botão próximo ao log do qual você deseja baixar e escolha **Download**. 1. Abra o menu de contexto (clique com o botão direito do mouse) para o link fornecido e escolha **Save Link As (Salvar link como)**. Informe o local onde você deseja salvar o arquivo de log e escolha **Save (Salvar)**. ![\[como visualizar arquivos de log\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/log_download2.png) ## AWS CLI Para baixar um arquivo de log de banco de dados, use o comando [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html) da `download-db-log-file-portion`. Por padrão, esse comando baixa apenas da parte mais recente de um arquivo de log. No entanto, baixe um arquivo inteiro especificando o parâmetro `--starting-token 0`. O exemplo a seguir mostra como baixar o conteúdo inteiro de um arquivo de log denominado *log/ERROR.4* e armazená-lo em um arquivo local denominado *errorlog.txt*. **Example** Para Linux, macOS ou Unix: ``` 1. aws rds download-db-log-file-portion \ 2. --db-instance-identifier myexampledb \ 3. --starting-token 0 --output text \ 4. --log-file-name log/ERROR.4 > errorlog.txt ``` Para Windows: ``` 1. aws rds download-db-log-file-portion ^ 2. --db-instance-identifier myexampledb ^ 3. --starting-token 0 --output text ^ 4. --log-file-name log/ERROR.4 > errorlog.txt ``` ## API do RDS Para baixar um arquivo de log de banco de dados, use a ação [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html) da API do Amazon RDS. # Como observar um arquivo de log de banco de dados Observar um arquivo de log do banco de dados é equivalente a seguir o arquivo em um sistema UNIX ou Linux. É possível monitorar um arquivo de log usando o Console de gerenciamento da AWS. O RDS atualiza o final do log a cada 5 segundos. **Para observar um arquivo de log de banco de dados** 1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Escolha o nome da instância de banco de dados que contém o arquivo de log que você deseja visualizar. 1. Escolha a guia **Logs & events (Logs e eventos)**. ![\[Escolha a guia Logs & events (Logs e eventos)\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_logsEvents.png) 1. Na seção **Logs**, escolha um arquivo de log e **Watch (Observar)**. ![\[Escolha um log\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch.png) O RDS mostra o final do log, como no exemplo do MySQL a seguir. ![\[Final de um arquivo de log\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch_content.png) # Publicação de logs de banco de dados no Amazon CloudWatch Logs Em um banco de dados local, os registros do banco de dados residem no sistema de arquivos. O Amazon RDS não fornece acesso ao host para os logs de banco de dados no sistema de arquivos de seu cluster de banco de dados. Por esse motivo, o Amazon RDS permite exportar logs de banco de dados para o [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). Com o CloudWatch Logs, você pode realizar análise em tempo real de dados de log. Você também pode armazenar os dados em um armazenamento resiliente e gerenciar os dados com o agente do CloudWatch Logs. **Topics** + [ ## Visão geral da integração do RDS com o CloudWatch Logs ](#rds-integration-cw-logs) + [ ## Decidir quais logs publicar no CloudWatch Logs ](#engine-specific-logs) + [ ## Especificar logs para publicar no CloudWatch Logs ](#integrating_cloudwatchlogs.configure) + [ ## Pesquisar e filtrar logs no CloudWatch Logs ](#accessing-logs-in-cloudwatch) ## Visão geral da integração do RDS com o CloudWatch Logs No CloudWatch Logs, um *fluxo de logs* é uma sequência de eventos de logs que compartilham a mesma origem. Cada origem separada de logs no CloudWatch Logs compõe um fluxo de logs separado. Um *grupo de logs* é um grupo de fluxos de log que compartilham as mesmas configurações de retenção, monitoramento e controle de acesso. O Amazon Aurora transmite continuamente os registros de logs de seu cluster de banco de dados para um grupo de logs. Por exemplo, suponhamos que você tem um grupo de logs `/aws/rds/cluster/cluster_name/log_type` para cada tipo de log que publica. Esse grupo de logs está na mesma região da AWS que a instância de banco de dados que gera o log. A AWS retém os dados de log publicados no CloudWatch Logs por um período indefinido, a menos que você especifique um período de retenção. Para obter mais informações, consulte [Alterar a retenção de dados de log no CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention). ## Decidir quais logs publicar no CloudWatch Logs Cada mecanismo de banco de dados do RDS oferece suporte ao seu próprio conjunto de logs. Para saber mais sobre as opções do seu mecanismo de banco de dados, consulte os seguintes tópicos: + [Publicar logs do Amazon Aurora MySQL no Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md) + [Publicar logs do Aurora PostgreSQL no Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md) ## Especificar logs para publicar no CloudWatch Logs Você especifica quais logs deseja publicar no console. Verifique se você tem um perfil vinculado ao serviço no AWS Identity and Access Management (IAM). Para obter mais informações sobre funções vinculadas ao serviço, consulte [Usar funções vinculadas ao serviço do Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md). **Como especificar os logs que deseja publicar** 1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Realize um dos procedimentos a seguir: + Selecione **Criar banco de dados**. + Escolha um banco de dados da lista e selecione **Modify** (Modificar). 1. Em **Logs exports** (Exportações de logs), escolha os logs para publicar. O exemplo a seguir especifica o log de auditoria, os logs de erros, o log geral, o log da instância, o log de erros de autenticação de banco de dados do IAM e o log de consultas lentas de um cluster de banco de dados do Aurora MySQL. ## Pesquisar e filtrar logs no CloudWatch Logs Você pode procurar entradas de log que atendam a critérios especificados usando o console do CloudWatch Logs. Você pode acessar os logs por meio do console do RDS, que leva você ao console do CloudWatch Logs, ou diretamente do console do CloudWatch Logs. **Como pesquisar logs do RDS usando o console do RDS** 1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, escolha **Databases (Bancos de dados)**. 1. Escolha um cluster de banco de dados ou uma instância de banco de dados. 1. Escolher **configuração**. 1. Em **Published logs** (Logs publicados), escolha o log de banco de dados que deseja exibir. **Como pesquisar logs do RDS usando o console do CloudWatch Logs** 1. Abra o console do CloudWatch em [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. No painel de navegação, escolha **Grupos de logs**. 1. Na caixa de filtro, insira **/aws/rds**. 1. Em **Grupos de logs**, escolha o nome do grupo de logs que contém o fluxo de log a ser pesquisado. 1. Em **Fluxos de log**, escolha o nome do fluxo de log para pesquisa. 1. Em **Eventos de log**, insira a sintaxe do filtro a ser usada. Para obter mais informações, consulte [Pesquisar e filtrar dados de logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) no *Guia do usuário do Amazon CloudWatch Logs*. Para acessar um tutorial de blog explicando como monitorar logs do RDS, consulte [Criar monitoramento de banco de dados proativo para o Amazon RDS com o Amazon CloudWatch Logs, o AWS Lambda e o Amazon SNS](https://aws.amazon.com/blogs/database/build-proactive-database-monitoring-for-amazon-rds-with-amazon-cloudwatch-logs-aws-lambda-and-amazon-sns/). # Leitura do conteúdo de arquivos de log usando REST O Amazon RDS fornece um endpoint REST que permite acesso aos arquivos de log de instâncias de banco de dados. Isso é útil para gravar uma aplicação para transmitir o conteúdo do arquivo de log do Amazon RDS. A sintaxe é: ``` GET /v13/downloadCompleteLogFile/DBInstanceIdentifier/LogFileName HTTP/1.1 Content-type: application/json host: rds.region.amazonaws.com ``` Os seguintes parâmetros são obrigatórios: + `DBInstanceIdentifier`: o nome da instância de banco de dados que contém o arquivo de log do qual você deseja baixar. + `LogFileName`: o nome do arquivo de log que será baixado. A resposta contém o conteúdo do arquivo de log solicitado, como um fluxo. O exemplo a seguir baixa o arquivo de log chamado *log/ERROR.6* para a instância de banco de dados chamada *sample-sql* na região *us-west-2*. ``` GET /v13/downloadCompleteLogFile/sample-sql/log/ERROR.6 HTTP/1.1 host: rds.us-west-2.amazonaws.com X-Amz-Security-Token: AQoDYXdzEIH//////////wEa0AIXLhngC5zp9CyB1R6abwKrXHVR5efnAVN3XvR7IwqKYalFSn6UyJuEFTft9nObglx4QJ+GXV9cpACkETq= X-Amz-Date: 20140903T233749Z X-Amz-Algorithm: AWS4-HMAC-SHA256 X-Amz-Credential: AKIADQKE4SARGYLE/20140903/us-west-2/rds/aws4_request X-Amz-SignedHeaders: host X-Amz-Content-SHA256: e3b0c44298fc1c229afbf4c8996fb92427ae41e4649b934de495991b7852b855 X-Amz-Expires: 86400 X-Amz-Signature: 353a4f14b3f250142d9afc34f9f9948154d46ce7d4ec091d0cdabbcf8b40c558 ``` Se você especificar uma instância de banco de dados não existente, a resposta consistirá no erro a seguir: + `DBInstanceNotFound`: `DBInstanceIdentifier` não se refere a uma instância de banco de dados existente. (Código de status HTTP: 404) # Arquivos de log do banco de dados AuroraMySQL Você pode monitorar os logs do Aurora MySQL diretamente por meio do console do Amazon RDS, da API do Amazon RDS, da AWS CLI ou dos SDKs da AWS. Você também pode acessar os logs do MySQL direcionando os logs para uma tabela de banco de dados no banco de dados primário e consultando essa tabela. Você pode usar o utilitário mysqlbinlog para baixar um log de binários. Para mais informações sobre a visualização, o download e os logs de bancos de dados baseados no monitoramento de arquivos, consulte [Monitorar arquivos de log do Amazon Aurora](USER_LogAccess.md). **Topics** + [ # Visão geral dos logs de banco de dados do Aurora MySQL ](USER_LogAccess.MySQL.LogFileSize.md) + [ # Enviar a saída de log do AuroraMySQL para tabelas ](Appendix.MySQL.CommonDBATasks.Logs.md) + [ # Configurar o registro em log binário do Aurora MySQL para bancos de dados single-AZ ](USER_LogAccess.MySQL.BinaryFormat.md) + [ # Acessar logs binários do MySQL ](USER_LogAccess.MySQL.Binarylog.md) # Visão geral dos logs de banco de dados do Aurora MySQL Você pode monitorar os seguintes tipos de arquivos de log do Aurora MySQL: + Log de erros + Log de consultas lentas + Log geral + Log de auditoria + Log de instância + Log de erros de autenticação de banco de dados do IAM O log de erros do Aurora MySQL é gerado por padrão. Você pode gerar a consulta lenta e os logs gerais definindo parâmetros no seu grupo de parâmetros do banco de dados. **Topics** + [ ## Logs de erro do Aurora MySQL ](#USER_LogAccess.MySQL.Errorlog) + [ ## Logs gerais e de consultas lentas do Aurora MySQL ](#USER_LogAccess.MySQL.Generallog) + [ ## Log de auditoria do Aurora MySQL ](#ams-audit-log) + [ ## Log de instâncias do Aurora MySQL ](#ams-instance-log) + [ ## Alternância e retenção de logs do Aurora MySQL ](#USER_LogAccess.AMS.LogFileSize.retention) + [ ## Publicar logs do Aurora MySQL no Amazon CloudWatch Logs ](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs) ## Logs de erro do Aurora MySQL O Aurora MySQL grava erros no arquivo `mysql-error.log`. Cada arquivo de log tem a hora em que foi gerado (em UTC) anexada ao seu nome. Os arquivos de log também possuem um carimbo de data/hora que ajuda você a determinar quando as entradas de log foram gravadas. O Aurora MySQL grava no log de erros apenas na inicialização, no desligamento e quando encontra erros. Uma instância de banco de dados pode passar horas ou dias sem novas entradas gravadas no log de erros. Se você não vir nenhuma entrada recente, é porque o servidor não encontrou nenhum erro que tenha gerado uma entrada de log. Por padrão, os logs de erros são filtrados para que apenas eventos inesperados, como erros, sejam exibidos. No entanto, os logs de erros também contêm algumas informações adicionais do banco de dados, por exemplo, o andamento da consulta, que não são mostradas. Portanto, mesmo sem erros reais, o tamanho dos logs de erros pode aumentar devido às atividades em andamento do banco de dados. Embora você possa ver determinado tamanho em bytes ou quilobytes para os logs de erros no Console de gerenciamento da AWS, eles poderão ter 0 byte quando você fizer download deles. O Aurora MySQL grava o `mysql-error.log` no disco a cada cinco minutos. Ele acrescenta o conteúdo do log ao `mysql-error-running.log`. O Aurora MySQL alterna o arquivo `mysql-error-running.log` de hora em hora. **nota** Observe que o período de retenção é diferente entre o Amazon RDS e o Aurora. ## Logs gerais e de consultas lentas do Aurora MySQL É possível gravar o log de consultas lentas e o log geral do Aurora MySQL em um arquivo ou em uma tabela de banco de dados. Para isso, defina parâmetros em seu grupo de parâmetros de banco de dados. Para obter informações sobre como criar e modificar um grupo de parâmetros de banco de dados, consulte [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). Você deve definir esses parâmetros antes de visualizar o log de consultas lentas ou o log geral no console do Amazon RDS ou usando a API do Amazon RDS, a CLI do Amazon RDS ou os SDKs da AWS. Você pode controlar o registro em log do Aurora MySQL usando os parâmetros nesta lista: + `slow_query_log`: para criar o log de consultas lentas, defina como 1. O padrão é 0. + `general_log`: para criar o log geral, defina como 1. O padrão é 0. + `long_query_time`: para evitar que as consultas de execução rápida sejam registradas no log de consultas lentas, especifique um valor para o tempo de execução de consultas mais curto a ser registrado, em segundos. O padrão é 10 segundos; o mínimo é 0. Se log\$1output = FILE, você poderá especificar um valor de ponto flutuante com resolução por microssegundo. Se log\$1output = TABLE, você deverá especificar um valor inteiro com a segunda resolução. Apenas as consultas cujo tempo de execução excede o valor `long_query_time` são registradas em log. Por exemplo, definir `long_query_time` como 0.1 impede que qualquer consulta que seja executada por menos de 100 milissegundos seja registrada. + `log_queries_not_using_indexes`: para registrar todas as consultas que não usam um índice no log de consultas lentas, defina como 1. As consultas que não usam um índice são registradas, mesmo que seu tempo de execução seja inferior ao valor do parâmetro `long_query_time`. O padrão é 0. + `log_output option`: você pode especificar uma das seguintes opções para o parâmetro `log_output`. + **TABLE** : grava consultas gerais na tabela `mysql.general_log` e consultas lentas na tabela `mysql.slow_log`. + **FILE**: grave logs de consultas gerais e lentas no sistema de arquivos. + **NONE**: desabilite o registro em log. Em relação ao Aurora MySQL versões 2 e 3, o padrão de `log_output` é `FILE`. Para que dados de consulta lenta apareçam no Amazon CloudWatch Logs, as seguintes condições devem ser atendidas: + O CloudWatch Logs deve ser configurado para incluir logs de consultas lentas. + `slow_query_log` deve estar habilitado. + `log_output` deve ser definido como `FILE`. + A consulta deve demorar mais do que o tempo configurado para `long_query_time`. Para obter mais informações sobre os log de consultas gerais e de consultas lentas, acesse os seguintes tópicos na documentação do MySQL: + [O log de consultas lentas](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) + [O log de consultas gerais](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) ## Log de auditoria do Aurora MySQL O registro em log de auditoria do Aurora MySQL é chamado de Auditoria avançada. Para ativar a Auditoria avançada, defina determinados parâmetros de cluster de banco de dados. Para obter mais informações, consulte [Como utilizar a auditoria avançada em um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Auditing.md). ## Log de instâncias do Aurora MySQL O Aurora cria um arquivo de log separado para instâncias de banco de dados que têm a pausa automática habilitada. Esse arquivo instance.log registra todos os motivos pelos quais essas não foi possível pausar as instâncias de banco de dados quando esperado. Para ter mais informações sobre o comportamento do arquivo de log da instância e o recurso de pausa automática do Aurora, consulte [Monitorar a atividade de pausa e retomada do Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log). ## Alternância e retenção de logs do Aurora MySQL Quando o registro em log está ativado, o Amazon Aurora alterna ou exclui os arquivos de log em intervalos regulares. Essa medida é uma precaução para reduzir a possibilidade de um arquivo de log grande bloquear o uso do banco de dados ou afetar o desempenho. O Aurora MySQL lida com a alternância e a exclusão da seguinte forma: + Os tamanhos dos arquivos de log de erros do Aurora MySQL são limitados a 15% do armazenamento local para uma instância de banco de dados. Para manter esse limite, os logs são alternados automaticamente a cada hora. O Aurora MySQL remove logs após 30 dias ou quando 15% do espaço em disco são atingidos. Se o tamanho do arquivo de log combinado exceder o limite após a remoção dos arquivos de log antigos, os arquivos de log mais antigos serão excluídos até o tamanho do arquivo de log deixar de exceder esse limite. + O Aurora MySQL removerá os logs de auditoria, gerais e de consulta lenta após 24 horas ou quando 15% do armazenamento tiver sido usado. + Quando o registro em log `FILE` está ativado, os arquivos de log geral e de consulta lenta são examinados a cada hora, e os arquivos de log com mais de 24 horas são excluídos. Em alguns casos, o tamanho do arquivo de log combinado restante após a exclusão pode exceder o limite de 15% do espaço local da instância de um banco de dados. Nesses casos, os arquivos de log mais antigos serão excluídos até que o tamanho do arquivo de log não exceda o limite. + Quando o registro em log de `TABLE` está ativado, as tabelas de log não são alternadas nem excluídas. As tabelas de log são truncadas quando o tamanho de todos os logs combinados é grande demais. Você pode assinar a categoria de evento `low storage` para ser notificado quando for necessário alternar ou excluir manualmente tabelas de logs para liberar espaço. Para obter mais informações, consulte [Trabalhar com a notificação de eventos do Amazon RDS](USER_Events.md). Você pode alternar a tabela `mysql.general_log` chamando o procedimento `mysql.rds_rotate_general_log`. Você pode rotacionar a tabela `mysql.slow_log` chamando o procedimento `mysql.rds_rotate_slow_log`. Quando você alterna as tabelas de logs manualmente, a tabela de logs atual é copiada em uma tabela de logs de backup, e as entradas na tabela de logs atual são removidas. Se a tabela de log de backup já existir, então ela será excluída antes que a tabela de log atual seja copiada ao backup. Você pode consultar a tabela de log de backup, se necessário. A tabela de log de backup para a tabela `mysql.general_log` é denominada `mysql.general_log_backup`. A tabela de log de backup para a tabela `mysql.slow_log` é denominada `mysql.slow_log_backup`. + Os logs de auditoria do Aurora MySQL são alternados quando o tamanho do arquivo atinge 100 MB e são removidos após 24 horas. + O Amazon RDS alterna os arquivos de log de erros de autenticação de banco de dados do IAM maiores que 10 MB. O Amazon RDS remove os arquivos de log de erros de autenticação de banco de dados do IAM com mais de cinco dias ou maiores que 100 MB. Para trabalhar com os logs no console do Amazon RDS, na API do Amazon RDS, na CLI do Amazon RDS ou nos SDKs da AWS, defina o parâmetro `log_output` como FILE. Como o log de erros do Aurora MySQL, esses arquivos de log são alternados por hora. Os arquivos de log que foram gerados durante as 24 horas anteriores são retidos. Observe que o período de retenção é diferente entre o Amazon RDS e o Aurora. ## Publicar logs do Aurora MySQL no Amazon CloudWatch Logs É possível configurar seu cluster de bancos de dados Aurora MySQL para publicar dados de log em um grupo no Amazon CloudWatch Logs. Com o CloudWatch Logs, você pode executar análise em tempo real de dados de log e usar o CloudWatch para criar alarmes e visualizar métricas. Você pode usar o CloudWatch Logs para armazenar seus registros de log em armazenamento resiliente. Para obter mais informações, consulte [Publicar logs do Amazon Aurora MySQL no Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). # Enviar a saída de log do AuroraMySQL para tabelas Você pode direcionar os logs de consultas gerais e lentas para tabelas na instância de banco de dados, criando um grupo de parâmetros de banco de dados e definindo o parâmetro do servidor `log_output` como `TABLE`. As consultas gerais são registradas na tabela `mysql.general_log` e as consultas lentas são registradas na tabela `mysql.slow_log`. Você pode consultar as tabelas para acessar as informações do log. Habilitar esse registro aumenta a quantidade de dados gravados no banco de dados, o que pode degradar a performance. O log geral e os logs de consultas lentas estão desabilitados por padrão. Para habilitar o registro em log de tabelas, você também deve definir os parâmetros de servidor `general_log` e `slow_query_log` como `1`. As tabelas de log continuarão crescendo até que as respectivas atividades de log sejam desativadas com a redefinição do parâmetro apropriado como `0`. Uma grande quantidade de dados geralmente se acumula ao longo do tempo, o que pode consumir uma porcentagem considerável do espaço de armazenamento alocado. O Amazon Aurora não permite truncar tabelas de log, mas é possível mover o conteúdo delas. Rotacionar uma tabela salva seu conteúdo em uma tabela de backup e, em seguida, cria uma nova tabela de log vazia. Você pode rotacionar manualmente as tabelas de log com os seguintes procedimentos de linha de comando, em que o prompt de comando é indicado por `PROMPT>`: ``` PROMPT> CALL mysql.rds_rotate_slow_log; PROMPT> CALL mysql.rds_rotate_general_log; ``` Para remover completamente os dados antigos e recuperar o espaço em disco, chame o procedimento apropriado duas vezes sucessivamente. # Configurar o registro em log binário do Aurora MySQL para bancos de dados single-AZ O *log binário* é um conjunto de arquivos de log que contêm informações sobre modificações de dados feitas em uma instância do servidor Aurora MySQL. O log binário contém informações como as seguintes: + Eventos que descrevem alterações no banco de dados, como criação de tabela ou modificações de linha + Informações sobre a duração de cada instrução que atualizou dados + Eventos para declarações que poderiam ter dados atualizados, mas não foram O log binário registra instruções que são enviadas durante a replicação. Também é necessário para algumas operações de recuperação. Para obter mais informações, consulte [The Binary Log](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) na documentação do MySQL. Os logs binários só podem ser acessados pela instância de banco de dados primária, não pelas réplicas. O MySQL no Amazon Aurora é compatível com os formatos de registro em log binário *baseados em linha*, *baseados em instrução* e *mistos*. Recomendamos misto, a menos que você precise de um formato específico de log binário. Para obter detalhes sobre os diferentes formatos de logs binários do Aurora MySQL, consulte [Formatos de registro em log binário](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html) na documentação do MySQL. Se você pretende usar replicação, o formato do registro em log binário é importante porque determina o registro de alterações feitas nos dados salvas na origem e enviadas para os destinos de replicação. Para obter informações sobre as vantagens e as desvantagens de formatos de registro em logs binários para replicação, consulte [Vantagens e desvantagens da replicação baseada em instrução e baseada em linha](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) na documentação do MySQL. **Importante** Com o MySQL 8.0.34, o MySQL descontinuou o parâmetro `binlog_format`. Em versões posteriores do MySQL, o MySQL pretende remover o parâmetro e oferecer suporte somente à replicação baseada em linhas. Como resultado, recomendamos o uso de registro baseado em linhas para novas configurações de replicação do MySQL. Para obter mais informações, consulte [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) na documentação do MySQL. As versões 8.0 e 8.4 do MySQL aceitam o parâmetro `binlog_format`. Ao usar esse parâmetro, o MySQL emite um aviso de descontinuação. Em uma futura versão principal, o MySQL removerá o parâmetro `binlog_format`. A replicação baseada em instrução pode causar inconsistências entre o cluster de banco de dados de origem e uma réplica de leitura. Para obter mais informações, consulte [Determinação de instruções seguras e inseguras no registro de logs binários](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html). na documentação do MySQL. Habilitar o registro em log binário aumenta o número de operações de E/S do disco de gravação no cluster de banco de dados. Você pode monitorar o uso de IOPS com a métrica ```VolumeWriteIOPs` do CloudWatch. **Para definir o formato de registro em log binário do MySQL** 1. Abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. No painel de navegação, selecione **Parameter groups**. 1. Selecione o grupo de parâmetros do cluster de banco de dados associado ao cluster de banco de dados que você deseja modificar. Não é possível modificar um grupo de parâmetros padrão. Se o cluster de banco de dados estiver usando um grupo de parâmetros padrão, crie outro grupo de parâmetros e o associe ao cluster de banco de dados. Para ter mais informações sobre grupos de parâmetros, consulte [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). 1. Em **Ações**, selecione **Editar**. 1. Defina o parâmetro `binlog_format` como o formato de registro em log binário de sua escolha (`ROW`, `STATEMENT` ou `MIXED`). Você também pode usar o valor `OFF` para desativar o registro em log binário. **nota** Definir `binlog_format` como `OFF` no grupo de parâmetros do cluster de banco de dados desativa a variável de sessão `log_bin`. Isso desabilita o registro em log binário no cluster de banco de dados do Aurora MySQL que, por sua vez, redefine a variável de sessão `binlog_format` como o valor padrão de `ROW` no banco de dados. 1. Escolha **Salvar alterações** para salvar as atualizações no grupo de parâmetros do cluster de banco de dados. Depois de realizar essas etapas, você deve reinicializar a instância do gravador no cluster de banco de dados para que suas alterações sejam aplicadas. No Aurora MySQL versão 2.09 e anteriores, quando você reinicializa a instância do gravador, todas as instâncias do leitor no cluster de banco de dados também são reinicializadas. No Aurora MySQL versão 2.10 e posteriores, você deve reinicializar todas as instâncias do leitor manualmente. Para obter mais informações, consulte [Reinicializar um cluster de banco de dados do Amazon Aurora ou instância de banco de dados do Amazon Aurora](USER_RebootCluster.md). **Importante** Alterar um grupo de parâmetros de cluster de banco de dados afeta todos os clusters de banco de dados que usam esse grupo de parâmetros. Se você quiser especificar diferentes formatos do registro em log binário para diferentes clusters de bancos de dados Aurora MySQL em uma região da AWS, os clusters de banco de dados deverão usar diferentes grupos de parâmetros de cluster de banco de dados. Esses grupos de parâmetros identificam diferentes formatos de log. Atribua o grupo de parâmetros de cluster de banco de dados apropriado a cada cluster de banco de dados. Para ter mais informações sobre parâmetros do Aurora MySQL, consulte [Parâmetros de configuração do Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md). # Acessar logs binários do MySQL É possível usar o utilitário mysqlbinlog para baixar ou transmitir os logs binários de instâncias do RDS para instâncias de banco de dados do MySQL. O log binário é baixado para o computador local, onde você pode realizar ações como reproduzir o log usando o utilitário mysql. Para ter mais informações sobre como usar o utilitário mysqlbinlog, acesse [Usar mysqlbinlog para fazer backup de arquivos de log binários](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) na documentação do MySQL. Para executar o utilitário mysqlbinlog em uma instância do Amazon RDS, use as seguintes opções: + `--read-from-remote-server` – obrigatório. + `--host`: o nome DNS do endpoint da instância. + `--port`: a porta usada pela instância. + `--user`: um usuário do MySQL ao qual foi concedida a permissão `REPLICATION SLAVE`. + `--password`: a senha do usuário do MySQL ou omita um valor de senha de forma que o utilitário solicite uma senha. + `--raw`: baixe o arquivo em formato binário. + `--result-file`: o arquivo local para receber a saída bruta. + `--stop-never`: transmita os arquivos de log binários. + `--verbose`: ao usar o formato de log binário `ROW`, inclua essa opção para ver os eventos de linha como instruções pseudo-SQL. Para ter mais informações sobre a opção `--verbose`, consulte [Exibição de evento da linha mysqlbinlog](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) na documentação do MySQL. + Especifique os nomes de um ou mais arquivos de log binários. Para obter uma lista dos logs disponíveis, use o comando SQL `SHOW BINARY LOGS`. Para ter mais informações sobre as opções de mysqlbinlog, consulte [mysqlbinlog: utilitário para processar arquivos de log binários](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) na documentação do MySQL. Os exemplos a seguir mostram como usar o utilitário mysqlbinlog. Para Linux, macOS ou Unix: ``` mysqlbinlog \ --read-from-remote-server \ --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \ --port=3306 \ --user ReplUser \ --password \ --raw \ --verbose \ --result-file=/tmp/ \ binlog.00098 ``` Para Windows: ``` mysqlbinlog ^ --read-from-remote-server ^ --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com ^ --port=3306 ^ --user ReplUser ^ --password ^ --raw ^ --verbose ^ --result-file=/tmp/ ^ binlog.00098 ``` Os logs binários devem permanecer disponíveis na instância de banco de dados para que o utilitário mysqlbinlog possa acessá-los. Para garantir a disponibilidade deles, use o procedimento armazenado [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e especifique um período com tempo suficiente para você baixar os logs. Se essa configuração não for definida, o Amazon RDS purgará os logs binários o mais rápido possível, causando lacunas nos logs binários que o utilitário mysqlbinlog recupera. O exemplo a seguir define o período de retenção como 1 dia. ``` call mysql.rds_set_configuration('binlog retention hours', 24); ``` Para exibir a configuração atual, use o procedimento armazenado [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration). ``` call mysql.rds_show_configuration; ``` # Arquivos de log do banco de dados Aurora PostgreSQL Você pode monitorar os seguintes tipos de arquivo de log do Aurora PostgreSQL: + Log do PostgreSQL + Log de instância + Log de erros de autenticação de banco de dados do IAM **nota** Para habilitar os logs de erro de autenticação de banco de dados do IAM, você deve primeiro habilitar a autenticação de banco de dados do IAM para o cluster de banco de dados do Aurora PostgreSQL. Para ter mais informações sobre a autenticação de banco de dados do IAM, consulte [Habilitar e desabilitar a autenticação de banco de dados do IAM](UsingWithRDS.IAMDBAuth.Enabling.md). O Aurora PostgreSQL registra as atividades do banco de dados no arquivo de log padrão do PostgreSQL. Para uma instância de banco de dados PostgreSQL on-premises, essas mensagens são armazenadas localmente em `log/postgresql.log`. Para um cluster de banco de dados do Aurora PostgreSQL, o arquivo de log está disponível no cluster do Aurora. Esses logs também podem ser acessados por meio do Console de gerenciamento da AWS, onde você pode visualizá-los ou baixá-los. O nível de registro em log padrão captura falhas de login, erros fatais do servidor, deadlocks e falhas de consulta. Para ter mais informações sobre a visualização, o download e os logs de banco de dados baseados no monitoramento de arquivos, consulte [Monitorar arquivos de log do Amazon Aurora](USER_LogAccess.md). Para saber mais sobre logs do PostgreSQL, consulte [Working with Amazon RDS and Aurora PostgreSQL logs: Part 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) (Trabalhar com o Amazon RDS e logs do Aurora PostgreSQL: parte 1) e [Working with RDS and Aurora PostgreSQL logs: Part 2](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/) (Trabalhar com o Amazon RDS e logs do Aurora PostgreSQL: parte 2). Além dos logs padrão do PostgreSQL abordados neste tópico, o Aurora PostgreSQL também é compatível com a extensão Audit do PostgreSQL (`pgAudit`). A maioria dos setores regulamentados e agências governamentais precisa manter um log de auditoria ou uma trilha de auditoria das alterações feitas nos dados para cumprir os requisitos legais. Para obter informações sobre a instalação e o uso de pgAudit, consulte [Usar pgAudit para registrar a atividade do banco de dados](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md). O Aurora cria um arquivo de log separado para instâncias de banco de dados que têm a pausa automática habilitada. Esse arquivo instance.log registra todos os motivos pelos quais essas não foi possível pausar as instâncias de banco de dados quando esperado. Para ter mais informações sobre o comportamento do arquivo de log da instância e o recurso de pausa automática do Aurora, consulte [Monitorar a atividade de pausa e retomada do Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log). **Topics** + [ # Parâmetros para registro em log no Aurora PostgreSQL ](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md) + [ # Ativar o registro em log de consultas para o cluster de banco de dados do Aurora PostgreSQL ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md) # Parâmetros para registro em log no Aurora PostgreSQL É possível personalizar o comportamento do registro em log do cluster de banco de dados do Aurora PostgreSQL modificando vários parâmetros. Na tabela a seguir, você encontra os parâmetros que afetam por quanto tempo os logs são armazenados, quando alternar o log e se ele deve ser gerado no formato CSV (valor separado por vírgula). Você também pode encontrar a saída de texto enviada para STDERR, entre outras configurações. Para alterar as configurações dos parâmetros que podem ser modificados, use um grupo de parâmetros de cluster de banco de dados para o cluster de banco de dados do Aurora PostgreSQL. Para ter mais informações, consulte [Grupos de parâmetros para Amazon Aurora](USER_WorkingWithParamGroups.md). | Parâmetro | Padrão | Descrição | | --- | --- | --- | | log\$1destination | stderr | Define o formato de saída para o log. O padrão é `stderr`, mas você também pode especificar valores separados por vírgula (CSV) adicionando `csvlog` à configuração. Para obter mais informações, consulte [Definir o destino dos logs (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format). | | log\$1filename | postgresql.log.%Y-%m-%d-%H%M | Especifica o padrão para o nome do arquivo de log. Além do padrão, esse parâmetro é compatível com `postgresql.log.%Y-%m-%d` e `postgresql.log.%Y-%m-%d-%H` para o padrão de nome de arquivo. Para o Aurora PostgreSQL versão 17.4 e posterior, não é possível modificar esse parâmetro. | | log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Define o prefixo para cada linha de log que é gravada em `stderr`, para anotar a hora (%t), o host remoto (%r), o usuário (%u), o banco de dados (%d) e o ID do processo (%p). | | log\$1rotation\$1age | 60 | Minutos após os quais o arquivo de log é alternado automaticamente. É possível alterar esse valor no intervalo de 1 a e 1.440 minutos. Para obter mais informações, consulte [Configurar a alternância do arquivo de log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). | | log\$1rotation\$1size | – | O tamanho (kB) no qual o log é alternado automaticamente. É possível alterar esse valor no intervalo de 50.000 a 1.000.000 de quilobytes. Para saber mais, consulte [Configurar a alternância do arquivo de log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). | | rds.log\$1retention\$1period | 4320 | Os logs do PostgreSQL mais antigos que o número especificado de minutos são excluídos. O valor padrão de 4.320 minutos exclui os arquivos de log após três dias. Para ter mais informações, consulte [Definir o período de retenção de log](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). | Para identificar problemas de aplicações, você pode procurar falhas de consulta, falhas de login, deadlocks e erros fatais de servidor no log. Por exemplo, suponha que você converta uma aplicação herdada do Oracle no Aurora PostgreSQL, mas nem todas as consultas foram convertidas corretamente. Essas consultas formatadas incorretamente geram mensagens de erro nos logs, que você pode usar para identificar problemas. Para ter mais informações sobre o registro em log de consultas, consulte [Ativar o registro em log de consultas para o cluster de banco de dados do Aurora PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md). Nos tópicos a seguir, você encontrará informações sobre como definir vários parâmetros que controlam os detalhes básicos de seus logs do PostgreSQL. **Topics** + [ ## Definir o período de retenção de log ](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period) + [ ## Configurar a alternância do arquivo de log ](#USER_LogAccess.Concepts.PostgreSQL.log_rotation) + [ ## Definir o destino dos logs (`stderr`, `csvlog`) ](#USER_LogAccess.Concepts.PostgreSQL.Log_Format) + [ ## Noções básicas sobre o parâmetro log\$1line\$1prefix ](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix) ## Definir o período de retenção de log O parâmetro `rds.log_retention_period` especifica por quanto tempo seu cluster de banco de dados do Aurora PostgreSQL mantém seus arquivos de log. A configuração padrão é de três dias (4.320 minutos), mas você pode definir esse valor de um dia (1.440 minutos) a sete dias (10.080 minutos). O cluster de banco de dados do Aurora PostgreSQL deve ter armazenamento suficiente para armazenar os arquivos de log durante o período. Recomendamos que você publique habitualmente seus logs no Amazon CloudWatch Logs para que possa visualizar e analisar os dados do sistema muito tempo depois que os logs tiverem sido removidos do cluster de banco de dados do Aurora PostgreSQL. Para ter mais informações, consulte [Publicar logs do Aurora PostgreSQL no Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md). Depois que você configura a publicação do CloudWatch, o Aurora não exclui um log enquanto ele não for publicado no CloudWatch Logs. O Amazon Aurora compacta logs do PostgreSQL mais antigos quando o armazenamento para a instância de banco de dados atinge um limite. O Aurora compacta os arquivos usando o utilitário de compactação gzip. Para ter mais informações, consulte o site do [gzip](https://www.gzip.org). Quando a instância de banco de dados estiver com pouco espaço de armazenamento e todos os logs disponíveis estiverem compactados, você receberá um aviso como o seguinte: ``` Warning: local storage for PostgreSQL log files is critically low for this Aurora PostgreSQL instance, and could lead to a database outage. ``` Se não houver armazenamento suficiente, o Aurora poderá excluir os logs compactados do PostgreSQL antes do final do período de retenção especificado. Se isso ocorrer, será exibida uma mensagem semelhante à seguinte: ``` The oldest PostgreSQL log files were deleted due to local storage constraints. ``` ## Configurar a alternância do arquivo de log Por padrão, o Aurora cria arquivos de log a cada hora. O tempo é controlado pelo parâmetro `log_rotation_age`. Esse parâmetro tem um valor padrão de 60 (minutos), mas você pode definir qualquer valor entre 1 minuto e 24 horas (1.440 minutos). Quando chegar o momento da alternância, será criado um novo arquivo de log distinto. O arquivo é nomeado de acordo com o padrão especificado pelo parâmetro `log_filename`. Também é possível alternar os arquivos de log de acordo com o tamanho, conforme especificado no parâmetro `log_rotation_size`. Esse parâmetro especifica que o log deva ser alternado quando atingir o tamanho determinado (em kilobytes). O valor padrão `log_rotation_size` é 100 mil kB (kilobytes) para um cluster de banco de dados do Aurora PostgreSQL, mas é possível definir esse valor entre 50 mil e 1 milhão de kilobytes. Os nomes dos arquivos de log são baseados no padrão de nome do arquivo do parâmetro `log_filename`. As configurações disponíveis para esse parâmetro são as seguintes: + `postgresql.log.%Y-%m-%d`: formato padrão do nome do arquivo de log. Inclui o ano, o mês e a data no nome do arquivo de log. + `postgresql.log.%Y-%m-%d-%H`: inclui a hora no formato do nome do arquivo de log. + `postgresql.log.%Y-%m-%d-%H%M`: inclui hora:minuto no formato do nome do arquivo de log. Se você definir o parâmetro `log_rotation_age` como menos de 60 minutos, defina o parâmetro `log_filename` como o formato em minutos. Para ter mais informações, consulte [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE) e [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE) na documentação do PostgreSQL. ## Definir o destino dos logs (`stderr`, `csvlog`) Por padrão, o Aurora PostgreSQL gera logs no formato de erro padrão (stderr). Esse formato é a configuração padrão do parâmetro `log_destination`. Cada mensagem é prefixada usando o padrão especificado no parâmetro `log_line_prefix`. Para ter mais informações, consulte [Noções básicas sobre o parâmetro log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix). O Aurora PostgreSQL também pode gerar os registros no formato `csvlog`. O `csvlog` é útil para analisar os dados de log como dados de valores separados por vírgula (CSV). Por exemplo, digamos que você use a extensão `log_fdw` para trabalhar com seus logs como tabelas externas. A tabela externa criada nos arquivos de log do `stderr` contém uma única coluna com dados de eventos de log. Ao adicionar `csvlog` ao parâmetro `log_destination`, você obtém o arquivo de log no formato CSV com demarcações para as várias colunas da tabela externa. Agora você pode classificar e analisar os logs com maior facilidade. Se você especificar `csvlog` para esse parâmetro, lembre-se de que os arquivos `stderr` e `csvlog` são gerados. Monitore o armazenamento consumido pelos logs, levando em consideração o `rds.log_retention_period` e outras configurações que afetam o armazenamento e a rotatividade dos logs. O uso de `stderr` e `csvlog` mais do que dobra o armazenamento consumido pelos logs. Se você adicionar `csvlog` a `log_destination` e quiser reverter para o `stderr`, precisará redefinir o parâmetro. Para fazer isso, use o console do Amazon RDS e, depois, abra o grupo de parâmetros do cluster de banco de dados para sua instância. Selecione o parâmetro `log_destination`, **Edit parameter** (Editar parâmetro) e depois **Reset** (Redefinir). Para ter mais informações sobre como configurar o registro em log, consulte [Trabalhar com logs do Amazon RDS e do Aurora PostgreSQL: parte 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/). ## Noções básicas sobre o parâmetro log\$1line\$1prefix O formato de log `stderr` prefixa cada mensagem de log com os detalhes especificados pelo parâmetro `log_line_prefix`. O valor padrão é: ``` %t:%r:%u@%d:[%p]:t ``` A partir do Aurora PostgreSQL versão 16, você também pode escolher: ``` %m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a ``` Cada entrada de log enviada para stderr inclui as seguintes informações com base no valor selecionado: + `%t`: hora da entrada do log sem milissegundos. + `%m`: hora da entrada do log com milissegundos. + `%r`: endereço do host remoto. + `%u@%d`: nome de usuário no nome do banco de dados. + `[%p]`: ID do processo, se disponível. + `%l`: número da linha de log por sessão. + `%e`: código de erro SQL. + `%s`: data e hora de início do processo. + `%v`: ID da transação virtual. + `%x`: ID da transação. + `%c`: ID da sessão. + `%q`: terminador não relacionado à sessão. + `%a`: nome da aplicação. # Ativar o registro em log de consultas para o cluster de banco de dados do Aurora PostgreSQL Você pode coletar informações mais detalhadas sobre suas atividades de banco de dados, inclusive consultas, consultas à espera de bloqueios, pontos de verificação e muitos outros detalhes definindo alguns dos parâmetros listados na tabela a seguir. Este tópico se concentra no registro em log de consultas. | Parâmetro | Padrão | Descrição | | --- | --- | --- | | log\$1connections | – | Registra cada conexão bem-sucedida. Para saber como usar esse parâmetro com `log_disconnections` para detectar a interrupção da conexão, consulte [Gerenciar a rotatividade de conexão do Aurora PostgreSQL com agrupamento](AuroraPostgreSQL.BestPractices.connection_pooling.md). | | log\$1disconnections | – | Registra o final de cada sessão e sua duração. Para saber como usar esse parâmetro com `log_connections` para detectar a interrupção da conexão, consulte [Gerenciar a rotatividade de conexão do Aurora PostgreSQL com agrupamento](AuroraPostgreSQL.BestPractices.connection_pooling.md). | | log\$1checkpoints | – | Não aplicável ao Aurora PostgreSQL | | log\$1lock\$1waits | – | Registra esperas de bloqueio longas. Por padrão, esse parâmetro não está definido. | | log\$1min\$1duration\$1sample | – | (ms) Define o tempo de execução mínimo acima do qual uma amostra de declarações será registrada. O tamanho da amostra é definido usando o parâmetro log\$1statement\$1sample\$1rate. | | log\$1min\$1duration\$1statement | – | Todas as instruções SQL executadas pelo menos por um período especificado ou mais é registrada. Por padrão, esse parâmetro não está definido. Ativar esse parâmetro pode ajudar a encontrar consultas não otimizadas. | | log\$1statement | – | Define o tipo de instruções registradas. Por padrão, esse parâmetro não está definido, mas você pode alterá-lo para `all`, `ddl` ou `mod` para especificar os tipos de declaração SQL que você deseja registrar. Se você especificar algo diferente de `none` para esse parâmetro, você também deve tomar medidas adicionais para evitar a exposição de senhas nos arquivos de log. Para ter mais informações, consulte [Reduzir o risco de exposição de senhas ao usar o registro em log de consultasReduzir o risco de exposição de senhas](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). | | log\$1statement\$1sample\$1rate | – | A porcentagem de declarações que excedem o tempo especificado em `log_min_duration_sample` para serem registradas, expressa como um valor de ponto flutuante entre 0,0 e 1,0. | | log\$1statement\$1stats | – | Grava estatísticas de desempenho cumulativas no log do servidor. | ## Usar o registro em log para encontrar consultas de baixa performance Você pode registrar consultas e declarações SQL para ajudar a encontrar consultas com a performance lenta. Você ativa esse recurso modificando as configurações dos parâmetros `log_statement` e `log_min_duration` conforme descrito nesta seção. Antes de ativar o registro em log de consultas para seu cluster de banco de dados do Aurora PostgreSQL, você deve estar ciente da possível exposição de senhas nos logs e de como reduzir os riscos. Para ter mais informações, consulte [Reduzir o risco de exposição de senhas ao usar o registro em log de consultasReduzir o risco de exposição de senhas](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). A seguir, você encontrará informações de referência sobre os parâmetros `log_statement` e `log_min_duration`.log\$1statement Esse parâmetro especifica o tipo de declarações SQL que devem ser enviadas ao log. O valor padrão é `none`. Se você alterar esse parâmetro para `all`, `ddl` ou `mod`, realize algumas das ações recomendadas para reduzir o risco de expor senhas nos logs. Para ter mais informações, consulte [Reduzir o risco de exposição de senhas ao usar o registro em log de consultasReduzir o risco de exposição de senhas](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). **todas** Registra todas as declarações. Essa configuração é recomendada para fins de depuração. **ddl** Registra todas as declarações de linguagem de definição de dados (DDL), como CREATE, ALTER, DROP etc. **mod** Registra todas as declarações DDL e declarações de linguagem de manipulação de dados (INSERT, UPDATE e DELETE) que modificam os dados. **nenhuma** Nenhuma declaração SQL é registrada. Recomendamos essa configuração para evitar o risco de expor senhas nos logs.log\$1min\$1duration\$1statement Todas as instruções SQL executadas pelo menos por um período especificado ou mais é registrada. Por padrão, esse parâmetro não está definido. Ativar esse parâmetro pode ajudar a encontrar consultas não otimizadas. **–1–2147483647** O número de milissegundos (ms) de tempo de execução durante o qual uma declaração é registrada. **Como configurar o registro em log de consultas** Essas etapas pressupõem que o cluster de banco de dados do Aurora PostgreSQL use um grupo de parâmetros de cluster de banco de dados personalizado. 1. Defina o parâmetro `log_statement` como `all`. O exemplo a seguir mostra a informação gravada no arquivo `postgresql.log`com essa configuração de parâmetro. ``` 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: statement: SELECT feedback, s.sentiment,s.confidence FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s ORDER BY s.confidence DESC; 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: QUERY STATISTICS 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:DETAIL: ! system usage stats: ! 0.017355 s user, 0.000000 s system, 0.168593 s elapsed ! [0.025146 s user, 0.000000 s system total] ! 36644 kB max resident size ! 0/8 [0/8] filesystem blocks in/out ! 0/733 [0/1364] page faults/reclaims, 0 [0] swaps ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent ! 19/0 [27/0] voluntary/involuntary context switches 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: SELECT feedback, s.sentiment,s.confidence FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s ORDER BY s.confidence DESC; 2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:ERROR: syntax error at or near "ORDER" at character 1 2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: ORDER BY s.confidence DESC; ----------------------- END OF LOG ---------------------- ``` 1. Defina o parâmetro `log_min_duration_statement`. O exemplo a seguir mostra a informação gravada no arquivo `postgresql.log` quando o parâmetro estiver definido como `1`. As consultas que excedem a duração especificada no parâmetro `log_min_duration_statement` são registradas. Por exemplo: Você pode visualizar o arquivo de log de seu cluster de banco de dados do Aurora PostgreSQL no console do Amazon RDS. ``` 2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: statement: DROP table comments; 2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: duration: 167.754 ms 2022-10-05 19:08:07 UTC::@:[355]:LOG: checkpoint starting: time 2022-10-05 19:08:08 UTC::@:[355]:LOG: checkpoint complete: wrote 11 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.013 s, sync=0.006 s, total=1.033 s; sync files=8, longest=0.004 s, average=0.001 s; distance=131028 kB, estimate=131028 kB ----------------------- END OF LOG ---------------------- ``` ### Reduzir o risco de exposição de senhas ao usar o registro em log de consultas Recomendamos manter `log_statement` definido como `none` para evitar a exposição de senhas. Se você definir `log_statement` como `all`, `ddl` ou`mod`, recomendamos que você siga uma ou mais destas etapas. + Para o cliente, criptografe informações confidenciais. Para ter mais informações consulte [Encryption Options](https://www.postgresql.org/docs/current/encryption-options.html) (Opções de criptografia) na documentação do PostgreSQL. Use as opções `ENCRYPTED` (e `UNENCRYPTED`) das declarações `CREATE` e `ALTER`. Para ter mais informações, consulte [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) na documentação do PostgreSQL. + Para seu cluster de banco de dados do Aurora PostgreSQL, configure e use a extensão de auditoria do PostgreSQL (pgAudit). Essa extensão remove informações confidenciais das declarações CREATE e ALTER enviadas ao log. Para ter mais informações, consulte [Usar pgAudit para registrar a atividade do banco de dados](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md). + Restringir o acesso aos logs CloudWatch. + Use mecanismos de autenticação mais fortes, como IAM.