

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Eventos, logs e trilhas de auditoria
<a name="events-logs-audit"></a>

Monitorar [métricas de instâncias de banco de dados](db-instance-monitoring.md) e [métricas do sistema operacional](os-monitoring.md), analisar as tendências e comparar as métricas com valores de linha de base e gerar alertas quando os valores ultrapassam os limites definidos são práticas recomendadas e necessárias que ajudam você a alcançar e manter a confiabilidade, a disponibilidade, a performance e a segurança de suas instâncias de banco de dados do Amazon RDS. No entanto, uma solução completa também deve monitorar eventos de banco de dados, arquivos de logs e trilhas de auditoria dos bancos de dados MySQL e MariaDB.

**Seções**
+ [eventos do Amazon RDS](rds-events.md)
+ [Logs de banco de dados](database-logs.md)
+ [Trilhas de auditoria](audit-trails.md)

# eventos do Amazon RDS
<a name="rds-events"></a>

Um *evento do* *Amazon RDS* indica uma alteração no ambiente do Amazon RDS. Por exemplo, quando o status da instância de banco de dados muda de *Starting* para *Available*, o Amazon RDS gera o evento `RDS-EVENT-0088 The DB instance has been started`. O Amazon RDS entrega eventos ao Amazon EventBridge quase em tempo real. Você pode acessar eventos por meio do console do Amazon RDS, do comando [describe-events](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/describe-events.html) da AWS CLI ou da operação da API [DescribeEvents](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEvents.html) do Amazon RDS. A ilustração de tela a seguir mostra eventos e logs exibidos no console do Amazon RDS.

![\[Alarmes, eventos e logs exibidos no console do Amazon RDS\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/alarms-events-logs-rds-console.png)


O Amazon RDS emite diferentes tipos de eventos, incluindo eventos de instância de banco de dados, eventos de grupos de parâmetros de banco de dados, eventos de grupos de segurança de banco de dados, eventos de snapshots de banco de dados, eventos de proxy do RDS e eventos de implantação azul/verde. As informações incluem:
+ Nome da origem e tipo de origem; por exemplo: `"SourceIdentifier": "database-1", "SourceType": "db-instance"`
+ Data e hora do evento; por exemplo: `"Date": "2022-12-01T09:20:28.595000+00:00"`
+ Mensagem associada ao evento; por exemplo: `"Message": "Finished updating DB parameter group"`
+ Categoria do evento; por exemplo: `"EventCategories": ["configuration change"]`

Para uma referência completa, consulte [Categorias de eventos e mensagens de eventos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html) na documentação do Amazon RDS.

Recomendamos que você monitore os eventos do Amazon RDS, pois eles indicam mudanças de status na disponibilidade de instâncias de banco de dados, alterações de configuração, mudanças de status de réplica de leitura, eventos de backup e recuperação, ações de failover, eventos de falha, modificações em grupos de segurança e muitas outras notificações. Por exemplo, se você configurou uma instância de banco de dados de réplica de leitura para fornecer performance e durabilidade aprimorados para seu banco de dados, recomendamos que você monitore os eventos do Amazon RDS da categoria de eventos de *réplica de leitura* associada às instâncias de banco de dados. Isso ocorre porque eventos como `RDS-EVENT-0057 Replication on the read replica was terminated` indicam que sua réplica de leitura não está mais sincronizada com a instância de banco de dados primária. Uma notificação à equipe responsável de que tal evento ocorreu pode ajudar a mitigar o problema em tempo hábil. O Amazon EventBridge e os Serviços da AWS adicionais, como o AWS Lambda, o Amazon Simple Queue Service (Amazon SQS) e o Amazon Simple Notiﬁcation Service (Amazon SNS), podem ajudar você a automatizar respostas a eventos do sistema, como problemas de disponibilidade de banco de dados ou alterações de recursos.

No console do Amazon RDS, você pode recuperar eventos das últimas 24 horas. Se você usar a AWS CLI ou a API do Amazon RDS para visualizar eventos, poderá recuperar eventos dos últimos 14 dias usando o comando **describe-events** conforme a seguir.

```
$ aws rds describe-events --source-identifier database-1 --source-type db-instance
{
    "Events": [
        {
            "SourceIdentifier": "database-1",
            "SourceType": "db-instance",
            "Message": "CloudWatch Logs Export enabled for logs [audit, error, general, slowquery]",
            "EventCategories": [],
            "Date": "2022-12-01T09:20:28.595000+00:00",
            "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1"
        },
        {
            "SourceIdentifier": "database-1",
            "SourceType": "db-instance",
            "Message": "Finished updating DB parameter group",
            "EventCategories": [
                "configuration change"
            ],
            "Date": "2022-12-01T09:22:40.413000+00:00",
            "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1"
        }
    ]
}
```

Se você quiser armazenar eventos no longo prazo, até o período de expiração especificado ou permanentemente, é possível usar o [CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) para registrar as informações sobre os eventos que foram gerados pelo Amazon RDS. Para implementar essa solução, você pode usar um tópico do Amazon SNS para receber notificações de eventos do Amazon RDS e, em seguida, chamar uma função do Lambda para registrar o evento no CloudWatch Logs.

1. Crie uma função do Lambda que será chamada no evento e registre as informações do evento no CloudWatch Logs. O CloudWatch Logs é integrado ao Lambda e fornece uma maneira conveniente de registrar informações de eventos de logs, usando a função **imprimir** para `stdout`.

1. Crie um tópico do SNS com uma assinatura para uma função do Lambda (defina o **Protocolo** como Lambda) e defina o **Endpoint** como o nome do recurso da Amazon (ARN) da função do Lambda que você criou na etapa anterior.

1. Configure seu tópico do SNS para receber notificações de eventos do Amazon RDS. Para obter instruções detalhadas, consulte o [artigo do AWS re:Post](https://repost.aws/knowledge-center/sns-topics-rds-notifications) sobre como fazer com que seu tópico do Amazon SNS receba notificações do Amazon RDS.

1. No console do Amazon RDS, crie uma nova assinatura de evento. Defina **Destino** como ARN e selecione o tópico do SNS que você criou anteriormente. Defina o **Tipo de origem** e as **Categorias de eventos a serem incluídas** de acordo com seus requisitos. Para obter mais informações, consulte [Inscrever-se em notificações de eventos do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html) na documentação do Amazon RDS.

# Logs de banco de dados
<a name="database-logs"></a>

Os bancos de dados MySQL e MariaDB geram logs que você pode acessar para auditoria e solução de problemas. Esses logs são:
+ [Auditoria](https://mariadb.com/kb/en/mariadb-audit-plugin-log-format/): a trilha de auditoria é um conjunto de registros que documentam a atividade do servidor. Para cada sessão do cliente, ele registra quem se conectou ao servidor (nome de usuário e host), quais consultas foram executadas, quais tabelas foram acessadas e quais variáveis do servidor foram alteradas.
+ [Erro](https://dev.mysql.com/doc/refman/8.0/en/error-log.html): este log contém os horários de inicialização e desligamento do servidor (`mysqld`) e mensagens de diagnóstico, como erros, avisos e observações que ocorrem durante a inicialização e o desligamento do servidor e enquanto o servidor está em execução.
+ [Geral](https://dev.mysql.com/doc/refman/8.0/en/query-log.html): este log registra a atividade de `mysqld`, incluindo a atividade de conexão e desconexão de cada cliente e as consultas SQL recebidas dos clientes. O log geral de consultas pode ser muito útil quando você suspeita de um erro e quer saber exatamente o que o cliente enviou para o `mysqld`.
+ [Consulta lenta](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html): este log fornece um registro das consultas SQL que demoraram muito para serem executadas.

Como prática recomendada, você deve [publicar logs de banco de dados do Amazon RDS no Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.UploadtoCloudWatch.html). Com o CloudWatch Logs, é possível executar uma análise em tempo real dos dados em log, armazenar os dados em um armazenamento de alta durabilidade e gerenciar os dados com o agente do CloudWatch Logs. Você pode [acessar e monitorar os logs do seu banco de dados](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Procedural.Watching.html) no console do Amazon RDS. Você também pode usar o CloudWatch Logs Insights para pesquisar e analisar dados de log de forma interativa no CloudWatch Logs. O exemplo a seguir ilustra uma consulta no log de auditoria que verifica quantas vezes os eventos `CONNECT` aparecem no log, quem se conectou e de qual cliente (endereço IP) eles se conectaram. O trecho do log de auditoria seria o seguinte:

```
20221201 14:07:05,ip-10-22-1-51,rdsadmin,localhost,821,0,CONNECT,,,0,SOCKET
20221201 14:07:05,ip-10-22-1-51,rdsadmin,localhost,821,0,DISCONNECT,,,0,SOCKET
20221201 14:12:20,ip-10-22-1-51,rdsadmin,localhost,822,0,CONNECT,,,0,SOCKET
20221201 14:12:20,ip-10-22-1-51,rdsadmin,localhost,822,0,DISCONNECT,,,0,SOCKET
20221201 14:17:35,ip-10-22-1-51,rdsadmin,localhost,823,0,CONNECT,,,0,SOCKET
20221201 14:17:35,ip-10-22-1-51,rdsadmin,localhost,823,0,DISCONNECT,,,0,SOCKET
20221201 14:22:50,ip-10-22-1-51,rdsadmin,localhost,824,0,CONNECT,,,0,SOCKET
20221201 14:22:50,ip-10-22-1-51,rdsadmin,localhost,824,0,DISCONNECT,,,0,SOCKET
```

O exemplo de consulta do Log Insights mostra que `rdsadmin` se conectou ao banco de dados no `localhost` a cada cinco minutos, totalizando 22 vezes, conforme mostrado na ilustração a seguir. Esses resultados indicam que a atividade se originou de processos internos do Amazon RDS, como o próprio sistema de monitoramento.

![\[Relatório do Log Insights\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/log-insights.png)


Os eventos de logs frequentemente incluem mensagens importantes que você deseja contabilizar, como avisos ou erros sobre operações associadas às instâncias de banco de dados MySQL e MariaDB. Por exemplo, se uma operação falhar, um erro poderá ocorrer e ser registrado no arquivo de logs de erros da seguinte forma: `ERROR 1114 (HY000): The table zip_codes is full`. É possível monitorar essas entradas para entender a tendência dos erros. Você pode [criar métricas personalizadas do CloudWatch dos logs do Amazon RDS usando filtros](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CreateMetricFilterProcedure.html) para permitir o monitoramento automático dos logs do banco de dados do Amazon RDS para monitorar um log específico de padrões específicos e gerar um alarme se houver violações do comportamento esperado. [Por exemplo](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CountOccurrencesExample.html), crie um filtro de métrica para o grupo de logs `/aws/rds/instance/database-1/error` que monitore o log de erros e busque o [padrão específico](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html), como `ERROR`. Defina o **Padrão de filtro** como `ERROR` e o **Valor da métrica** como `1`. O filtro detectará cada registro de log que tenha a palavra-chave `ERROR` e incrementará a contagem em 1 para cada evento de log que contenha “ERROR”. Depois de criar o filtro, você pode definir um alarme para notificar você caso sejam detectados erros no log de erros do MySQL ou do MariaDB.

Para saber mais sobre como monitorar o log de consultas lentas e o log de erros criando um painel do CloudWatch e usando o CloudWatch Logs Insights, consulte a publicação no blog [Creating an Amazon CloudWatch dashboard to monitor Amazon RDS and Amazon Aurora MySQL.](https://aws.amazon.com/blogs/database/creating-an-amazon-cloudwatch-dashboard-to-monitor-amazon-rds-and-amazon-aurora-mysql/)

# Trilhas de auditoria
<a name="audit-trails"></a>

A trilha de auditoria (ou log de auditoria) fornece um registro cronológico relevante para a segurança dos eventos em sua Conta da AWS. Inclui eventos do Amazon RDS, que fornecem evidências documentais da sequência de atividades que afetaram seu banco de dados ou seu ambiente de nuvem. No Amazon RDS para MySQL ou MariaDB, o uso da trilha de auditoria envolve:
+ Monitoramento do log de auditoria da instância de banco de dados
+ Monitoramento de chamadas da API do Amazon RDS no AWS CloudTrail

Para uma instância de banco de dados Amazon RDS, os objetivos da auditoria geralmente incluem:
+ Possibilitar a responsabilização pelo seguinte:
  + Modificações realizadas no parâmetro ou na configuração de segurança
  + Ações executadas em um esquema, tabela ou linha de banco de dados, ou ações que afetam um conteúdo específico
+ Detecção e investigação de intrusões
+ Detecção e investigação de atividades suspeitas
+ Detecção de problemas de autorização, por exemplo, para identificar abusos de direitos de acesso por usuários regulares ou privilegiados

A trilha de auditoria do banco de dados tenta responder a estas perguntas frequentes: *Quem visualizou ou modificou dados sensíveis em seu banco de dados? Quando isso ocorreu? De onde um usuário específico acessou os dados? Os usuários privilegiados abusaram de seus direitos de acesso ilimitado?*

Tanto o MySQL quanto o MariaDB implementam o recurso de trilha de auditoria de instâncias de banco de dados usando o plug-in de auditoria do MariaDB. Esse plug-in registra a atividade do banco de dados, como usuários que fazem login no banco de dados, as consultas que são executadas no banco de dados e muito mais. O registro da atividade do banco de dados é armazenado em um arquivo de log. Para acessar o log de auditoria, a instância de banco de dados deve usar um grupo de opções personalizado com a opção `MARIADB_AUDIT_PLUGIN`. Para obter mais informações, consulte [Suporte ao plug-in de auditoria do MariaDB para MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) na documentação do Amazon RDS. Os registros no log de auditoria são armazenados em um formato específico, conforme definido pelo plug-in. Você pode encontrar mais detalhes sobre o formato do log de auditoria na [documentação do MariaDB Server](https://mariadb.com/kb/en/mariadb-audit-plugin-log-format/).

A trilha de auditoria da Nuvem AWS para sua conta da AWS é fornecida pelo serviço do [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). O CloudTrail captura as chamadas de API para o Amazon RDS como eventos. Todas as ações do Amazon RDS são registradas em log. O CloudTrail fornece um registro de ações executadas no Amazon RDS por um usuário, um perfil ou outro serviço da AWS. Os eventos incluem ações executadas no Console de Gerenciamento da AWS, na AWS CLI e nos SDKs e APIs da AWS.

## Exemplo
<a name="example"></a>

Em um cenário de auditoria comum, talvez seja necessário combinar trilhas do AWS CloudTrail com o log de auditoria do banco de dados e o monitoramento de eventos do Amazon RDS. Por exemplo, você pode ter um cenário em que os parâmetros do banco de dados da sua instância de banco de dados do Amazon RDS (por exemplo,`database-1`) tenham sido modificados e sua tarefa seja identificar quem fez a modificação, o que foi alterado e quando ocorreu a alteração.

Para realizar a tarefa, siga estas etapas:

1. Liste os eventos do Amazon RDS que ocorreram com a instância `database-1` do banco de dados e determine se há um evento na categoria `configuration change` que contém a mensagem `Finished updating DB parameter group`.

   ```
   $ aws rds describe-events --source-identifier database-1 --source-type db-instance
   {
       "Events": [
           {
               "SourceIdentifier": "database-1",
               "SourceType": "db-instance",
               "Message": "Finished updating DB parameter group",
               "EventCategories": [
                   "configuration change"
               ],
               "Date": "2022-12-01T09:22:40.413000+00:00",
               "SourceArn": "arn:aws:rds:eu-west-3:111122223333:db:database-1"
           }
       ]
   }
   ```

1. Identifique qual grupo de parâmetros de banco de dados a instância de banco de dados está usando:

   ```
   $ aws rds describe-db-instances --db-instance-identifier database-1 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups]'
   [
       [
           "database-1",
           "mariadb",
           [
               {
                   "DBParameterGroupName": "mariadb10-6-test",
                   "ParameterApplyStatus": "pending-reboot"
               }
           ]
       ]
   ]
   ```

1. [Use a AWS CLI para pesquisar eventos do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-cli.html) na região em que `database-1` está implantado, no período próximo ao evento do Amazon RDS descoberto na etapa 1, e onde `EventName=ModifyDBParameterGroup`.

   ```
   $ aws cloudtrail --region eu-west-3 lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ModifyDBParameterGroup --start-time "2022-12-01, 09:00 AM" --end-time "2022-12-01, 09:30 AM"    
   
   {
       "eventVersion": "1.08",
       "userIdentity": {
           "accountId": "111122223333",
           "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
           "sessionContext": {
               "sessionIssuer": {
                   "type": "Role",
                   "principalId": "AIDACKCEVSQ6C2EXAMPLE",
                   "arn": "arn:aws:iam::111122223333:role/Role1",
                   "accountId": "111122223333",
                   "userName": "User1"
               }
           }
       },
       "eventTime": "2022-12-01T09:18:19Z",
       "eventSource": "rds.amazonaws.com",
       "eventName": "ModifyDBParameterGroup",
       "awsRegion": "eu-west-3",
       "sourceIPAddress": "AWS Internal",
       "userAgent": "AWS Internal",
       "requestParameters": {
           "parameters": [
               {
                   "isModifiable": false,
                   "applyMethod": "pending-reboot",
                   "parameterName": "innodb_log_buffer_size",
                   "parameterValue": "8388612"
               },
               {
                   "isModifiable": false,
                   "applyMethod": "pending-reboot",
                   "parameterName": "innodb_write_io_threads",
                   "parameterValue": "8"
               }
           ],
           "dBParameterGroupName": "mariadb10-6-test"
       },
       "responseElements": {
           "dBParameterGroupName": "mariadb10-6-test"
       },
       "requestID": "fdf19353-de72-4d3d-bf29-751f375b6378",
       "eventID": "0bba7484-0e46-4e71-93a8-bd01ca8386fe",
       "eventType": "AwsApiCall",
       "managementEvent": true,
       "recipientAccountId": "111122223333",
       "eventCategory": "Management",
       "sessionCredentialFromConsole": "true"
   }
   ```

O evento do CloudTrail revela que o `User1`, com o perfil `Role1` da conta 111122223333 da AWS, modificou o grupo de parâmetros `mariadb10-6-test` do banco de dados, que foi usado pela instância `database-1` do banco de dados em `2022-12-01 at 09:18:19 h`. Dois parâmetros foram modificados e configurados com os seguintes valores:
+ `innodb_log_buffer_size = 8388612`
+ `innodb_write_io_threads = 8`

## Recursos adicionais do CloudTrail e do CloudWatch Logs
<a name="additional-features"></a>

É possível resolver problemas operacionais e incidentes de segurança dos últimos 90 dias no console do CloudTrail visualizando o **Histórico de eventos**. Para estender o período de retenção e aproveitar os recursos adicionais de consulta, você pode usar o [AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html). Com o AWS CloudTrail Lake, você pode manter os dados de eventos em um armazenamento de dados de eventos por até sete anos. Além disso, o serviço é compatível com consultas SQL complexas que oferecem uma visão mais profunda e personalizável dos eventos do que as visualizações fornecidas por pesquisas simples de chave/valor no **Histórico de eventos**.

Para monitorar suas trilhas de auditoria, definir alarmes e receber notificações quando uma atividade específica ocorrer, você precisa [configurar o CloudTrail para enviar seus registros de trilha para o CloudWatch Logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html). Depois que os registros da trilha forem armazenados como CloudWatch Logs, você poderá definir filtros de métricas para avaliar os eventos de logs de acordo com termos, frases ou valores e atribuir métricas aos filtros de métricas. Além disso, você pode criar alarmes do CloudWatch que são gerados de acordo com os limites e os períodos que você especificar. Por exemplo, você pode configurar alarmes que enviam notificações às equipes responsáveis para que elas possam tomar as medidas apropriadas. Você também pode configurar o CloudWatch para realizar uma ação automaticamente em resposta a um alarme.