# Amazon Aurora ログファイルのモニタリング
すべての RDS データベースエンジンは、監査やトラブルシューティング時にアクセスするログを生成します。ログの種類は、データベースエンジンによって異なります。
AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または Amazon RDS API を使用して、DB インスタンスのデータベースログにアクセスできます。トランザクションログを表示、監視、またはダウンロードすることはできません。
**注記**
場合によっては、ログに非表示のデータが含まれていることがあります。よって、AWS マネジメントコンソール はログファイルのコンテンツを表示することがありますが、ダウンロードする際は、ログファイルは、空欄です。
**Topics**
+ [データベースログファイルの表示とリスト化](USER_LogAccess.Procedural.Viewing.md)
+ [データベースログファイルのダウンロード](USER_LogAccess.Procedural.Downloading.md)
+ [データベースログファイルのモニタリング](USER_LogAccess.Procedural.Watching.md)
+ [Amazon CloudWatch Logs へのデータベースログの発行](USER_LogAccess.Procedural.UploadtoCloudWatch.md)
+ [REST を用いたログファイルの内容の読み取り](DownloadCompleteDBLogFile.md)
+ [Aurora MySQL データベースのログファイル](USER_LogAccess.Concepts.MySQL.md)
+ [Aurora PostgreSQL データベースログファイル](USER_LogAccess.Concepts.PostgreSQL.md)
# データベースログファイルの表示とリスト化
AWS マネジメントコンソール を使用して、Amazon Aurora DB エンジンのデータベースログファイルを表示できます。AWS CLI または Amazon RDS API を使用して、ダウンロードまたはモニタリングできるログファイルを一覧表示できます。
**注記**
RDS コンソールの Aurora Serverless v1 DB クラスタのログファイルは表示できません。ただし、Amazon CloudWatch コンソール [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) で表示できます。
## コンソール
**データベースログファイルを閲覧するには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. 表示するログファイルのある DB インスタンスの名前を選択します。
1. [**ログとイベント**] タブを選択します。
1. [**ログ**] セクションまで下にスクロールします。
1. (オプション) 検索語を入力して、結果をフィルタリングします。
次の例では、テキスト **error** でフィルタリングされたログを一覧表示しています。
![\[DB ログのリスト\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/ListEventsAMS.png)
1. 表示するログを選択してから、**[View]** (表示) を選択します。
## AWS CLI
DB インスタンスで使用できるデータベースログファイルを一覧表示するには、AWS CLI の [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html) コマンドを使用します。
次の例では、DB インスタンス (`my-db-instance`) のログファイルのリストが返ります。
**Example**
```
1. aws rds describe-db-log-files --db-instance-identifier my-db-instance
```
## RDS API
DB インスタンスの使用可能なデータベースログファイルを一覧表示するには、Amazon RDS API の [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html) アクションを使用します。
# データベースログファイルのダウンロード
データベースログファイルをダウンロードするには、AWS マネジメントコンソール、AWS CLI、または API を使用します。
## コンソール
**データベースログファイルをダウンロードするには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. 表示するログファイルのある DB インスタンスの名前を選択します。
1. [**ログとイベント**] タブを選択します。
1. [**ログ**] セクションまで下にスクロールします。
1. [**ログ**] セクションで、ダウンロードするログの横にあるボタンを選択し、[**ダウンロード**] を選択します。
1. 表示されたリンクのコンテキスト (右クリック) メニューを開き、[**名前を付けて保存**] を選択します。ログファイルを保存する場所を入力し、[**保存**] を選択します。
![\[ログファイルを閲覧する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/log_download2.png)
## AWS CLI
データベースログファイルをダウンロードするには、AWS CLI の [https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html](https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html) コマンドを使用します。デフォルトでは、このコマンドによってログファイルの最新部分のみがダウンロードされます。ただし、`--starting-token 0` パラメータを指定して、ファイル全体をダウンロードすることもできます。
以下の例では、ログファイル (*log/ERROR.4*) のすべての内容をダウンロードし、ローカルファイル (*errorlog.txt*) に格納する方法について説明します。
**Example**
Linux、macOS、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
```
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
```
## RDS API
データベースログファイルをダウンロードするには、Amazon RDS API の [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html) アクションを使用します。
# データベースログファイルのモニタリング
データベースログファイルを監視することは、UNIX または Linux システムでファイルをテーリングすることと同じです。AWS マネジメントコンソール を使用すると、ログファイルを監視できます。RDS は 5 秒ごとにログの末尾を更新します。
**データベースログファイルをモニタリングするには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. 表示するログファイルのある DB インスタンスの名前を選択します。
1. [**ログとイベント**] タブを選択します。
![\[[Logs & events] (ログとイベント) タブを選択します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_logsEvents.png)
1. [**ログ**] セクションでログファイルを選択し、[**モニタリング**] を選択します。
![\[[Logs] (ログ) を選択します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch.png)
RDS には、次の MySQL の例のようにログの末尾が表示されます。
![\[ログファイルの末尾\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch_content.png)
# Amazon CloudWatch Logs へのデータベースログの発行
オンプレミスデータベースでは、データベースログはファイルシステムに存在します。Amazon RDS では、DB クラスターのファイルシステム上のデータベースログへのホストアクセスが許可されません。このため、Amazon RDS では、[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) にデータベースログをエクスポートできます。CloudWatch Logs を使用すると、ログデータのリアルタイム分析を実行できます。高い耐久性を持つストレージにデータを保存し、CloudWatch Logs エージェントを使用したデータの管理を実行できます。
**Topics**
+ [RDS と CloudWatch Logs の統合の概要](#rds-integration-cw-logs)
+ [CloudWatch Logs に発行するログの決定](#engine-specific-logs)
+ [CloudWatch Logs に発行するログの指定](#integrating_cloudwatchlogs.configure)
+ [CloudWatch Logs でのログの検索とフィルタリング](#accessing-logs-in-cloudwatch)
## RDS と CloudWatch Logs の統合の概要
CloudWatch Logs では、*ログストリーミング*は、同じ出典を共有する一連のログイベントです。CloudWatch Logs でのログの各ソースで各ログストリームが構成されます。*ロググループ*は、保持、モニタリング、アクセス制御について同じ設定を共有するログストリームのグループです。
Amazon Aurora は、DB クラスターログレコードをロググループに継続的にストリームします。例えば、発行した各タイプのログについて、ロググループ `/aws/rds/cluster/cluster_name/log_type` があることを考えます。このロググループは、ログを生成するデータベースインスタンスと同じ AWS リージョンにあります。
AWS は、CloudWatch Logs に発行されたログデータを、保持期間を指定しない限り、無期限に保持します。詳細については、「[CloudWatch Logs でのログデータ保管期間の変更](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention)」を参照してください。
## CloudWatch Logs に発行するログの決定
各 RDS データベースエンジンは、独自のログセットをサポートします。データベースエンジンのオプションについては、以下のトピックを確認してください。
+ [Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](AuroraMySQL.Integrating.CloudWatch.md)
+ [Amazon CloudWatch Logs への Aurora PostgreSQL ログの発行](AuroraPostgreSQL.CloudWatch.md)
## CloudWatch Logs に発行するログの指定
コンソールで発行するログを指定します。AWS Identity and Access Management (IAM) にサービスリンクロールがあることを確認します。サービスにリンクされたロールの詳細については、「[Amazon Aurora のサービスにリンクされたロールの使用](UsingWithRDS.IAM.ServiceLinkedRoles.md)」を参照してください。
**発行するログを指定するには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. 次のいずれかを実行します。
+ **[データベースの作成]** を選択します。
+ 一覧からデータベースを選択し、**[Modify]** (変更) を選択します。
1. **[Logs exports]** (ログのエクスポート) で、発行するログを選択します。
次の例では、Aurora MySQL DB クラスターの監査ログ、エラーログ、一般ログ、インスタンスログ、IAM データベース認証エラーログ、スロークエリログを指定します。
## CloudWatch Logs でのログの検索とフィルタリング
CloudWatch コンソールを使用して、指定した基準を満たすログエントリを検索することができます。ログには、CloudWatch Logs コンソールにつながる RDS コンソールからアクセスすることも、CloudWatch Logs コンソールから直接アクセスすることもできます。
**RDS コンソールを使用して RDS ログを検索するには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. DB クラスターまたは DB インスタンスを選択します。
1. **[設定]** を選択します。
1. **[Published logs]** (発行されたログ) で、表示するデータベースログを選択します。
**CloudWatch Logs コンソールを使用して RDS ログを検索するには**
1. CloudWatch コンソール ([https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)) を開きます。
1. ナビゲーションペインで、**[Log groups]** (ロググループ) を選択します。
1. フィルタボックスに **/aws/rds** と入力します。
1. [**ロググループ**] で、検索するログストリームを含むロググループの名前を選択します。
1. [**ログストリーム**] で、検索するログストリームの名前を選択します。
1. [**Log Events (ログイベント)**] で、使用するフィルター構文を入力します。
詳細については、*Amazon CloudWatch Logs ユーザーガイド*の「[ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)」を参照してください。RDS ログをモニタリングする方法を説明するブログチュートリアルについては、「[Amazon CloudWatch Logs、AWS Lambda、および Amazon SNS を使用して Amazon RDS のプロアクティブなデータベースモニタリングを構築する](https://aws.amazon.com/blogs/database/build-proactive-database-monitoring-for-amazon-rds-with-amazon-cloudwatch-logs-aws-lambda-and-amazon-sns/)」を参照してください。
# REST を用いたログファイルの内容の読み取り
Amazon RDS では、DB インスタンスのログファイルへのアクセスを許可する REST エンドポイントを使用できます。これは、Amazon RDS ログファイルの内容を取り出すアプリケーションを作成される場合に有用です。
構文は次のとおりです。
```
GET /v13/downloadCompleteLogFile/DBInstanceIdentifier/LogFileName HTTP/1.1
Content-type: application/json
host: rds.region.amazonaws.com
```
以下のパラメータは必須です。
+ `DBInstanceIdentifier`— ダウンロードするログファイルを含む DB インスタンスの名前。
+ `LogFileName`—ダウンロードするログファイルの名前。
このレスポンスには、ストリーミングとしてリクエストされたログファイルの内容が含まれます。
次の例では、*us-west-2* リージョンの *sample-sql* という名前の DB インスタンスの *log/ERROR.6* という名前のログファイルをダウンロードします。
```
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
```
存在しない DB インスタンスを指定した場合、レスポンスは次のエラーになります。
+ `DBInstanceNotFound`—`DBInstanceIdentifier` が既存の DB インスタンスを参照していません。(HTTP ステータスコード: 404)
# Aurora MySQL データベースのログファイル
Aurora MySQL ログは、Amazon RDS コンソール、Amazon RDS API、AWS CLI、または AWS SDK を通じて直接モニタリングできます。また、ログをメインデータベースのデータベーステーブルに書き込み、そのテーブルに対してクエリを実行することで、MySQL ログにアクセスできます。mysqlbinlog ユーティリティを使用して、バイナリログをダウンロードできます。
ファイルベースのデータベースログの表示、ダウンロード、モニタリングの詳細については、「[Amazon Aurora ログファイルのモニタリング](USER_LogAccess.md)」を参照してください。
**Topics**
+ [Aurora MySQL データベースログの概要](USER_LogAccess.MySQL.LogFileSize.md)
+ [テーブルへの Aurora MySQL ログ出力の送信](Appendix.MySQL.CommonDBATasks.Logs.md)
+ [シングル AZ データベースの Aurora MySQL バイナリログの設定](USER_LogAccess.MySQL.BinaryFormat.md)
+ [MySQL バイナリログにアクセスする](USER_LogAccess.MySQL.Binarylog.md)
# Aurora MySQL データベースログの概要
次の種類の Aurora MySQL ログファイルをモニタリングできます。
+ エラーログ
+ スロークエリログ
+ 全般ログ
+ 監査ログ
+ インスタンスログ
+ IAM データベース認証エラーログ
Aurora MySQL のエラーログはデフォルトで生成されます。DB パラメータグループにパラメータを設定することで、低速クエリと一般ログを生成できます。
**Topics**
+ [Aurora MySQL エラーログ](#USER_LogAccess.MySQL.Errorlog)
+ [Aurora MySQL のスロークエリと一般ログ](#USER_LogAccess.MySQL.Generallog)
+ [Aurora MySQL の監査ログ](#ams-audit-log)
+ [Aurora MySQL インスタンスログ](#ams-instance-log)
+ [Aurora MySQL のログのローテーションと保持](#USER_LogAccess.AMS.LogFileSize.retention)
+ [Amazon CloudWatch Logs への Aurora MySQL ログの発行](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs)
## Aurora MySQL エラーログ
Aurora MySQL は `mysql-error.log` ファイルにエラーを書き込みます。各ログファイルには、それぞれ生成された時間 (UTC) がファイル名に付加されます。ログファイルには、タイムスタンプも付加され、ログエントリがいつ書き込まれたかを調べるために役立ちます。
Aurora MySQL では起動時、シャットダウン時、およびエラー検出時にのみ、エラーログへの書き込みが行われます。DB インスタンスでは、新しいエントリがエラーログに書き込まれないまま、数時間または数日が経過することがあります。最近のエントリがない場合、それは、サーバーにログエントリになり得るエラーが発生しなかったためです。
設計上、エラーログはフィルタリングされ、エラーなどの予期しないイベントのみが表示されます。ただし、エラーログには、クエリの進行状況など、表示されない追加のデータベース情報も含まれています。したがって、実際のエラーがなくても、継続的なデータベースアクティビティのためにエラーログのサイズが増加する可能性があります。また、AWS マネジメントコンソール のエラーログには特定のサイズがバイト単位またはキロバイト単位で表示されている場合がありますが、ダウンロードすると 0 バイトになる場合があります。
Aurora MySQL は 5 分ごとに `mysql-error.log` をディスクに書き込みます。ログの内容が `mysql-error-running.log` に追加されます。
Aurora MySQL は `mysql-error-running.log` ファイルを 1 時間ごとにローテーションします。
**注記**
ログの保持期間は、Amazon RDS と Aurora で異なります。
## Aurora MySQL のスロークエリと一般ログ
Aurora MySQL のスロークエリログと一般ログを、ファイルまたはデータベーステーブルに書き込めます。このためには、DB パラメータグループにパラメータを設定します。DB パラメータグループの作成と変更の詳細については、「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。Amazon RDS コンソール、Amazon RDS API、Amazon RDS CLI、または AWS SDK を使用して、スロークエリログまたは一般ログを表示する前に、以下のパラメータを設定する必要があります。
以下のリストに示すパラメータを使用して Aurora MySQL のログ記録を制御できます。
+ `slow_query_log`: スロークエリログを作成するには、1 に設定します。デフォルトは 0 です。
+ `general_log`: 一般ログを作成するには、1 に設定します。デフォルトは 0 です。
+ `long_query_time`: ファストクエリがスロークエリログに記録されないようにするために、ログに記録されるクエリの最短実行時間の値を秒単位で指定します。デフォルトは 10 秒で、最小値は 0 です。log\$1output = FILE の場合は、マイクロ秒の精度になるように、浮動小数点値を指定できます。log\$1output = TABLE の場合は、秒の精度になるように、整数値を指定する必要があります。実行時間が `long_query_time` の値を超えたクエリのみがログに記録されます。例えば、`long_query_time` を 0.1 に設定すると、実行時間が 100 ミリ秒未満のすべてのクエリはログに記録されなくなります。
+ `log_queries_not_using_indexes`: インデックスを使用しないすべてのクエリをスロークエリログに記録するには、1 に設定します。インデックスを使用しないクエリは、その実行時間が `long_query_time` パラメータの値未満であってもログに記録されます。デフォルトは 0 です。
+ `log_output option`: `log_output` パラメータに指定できるオプションは、次のとおりです。
+ **TABLE** - 一般クエリを `mysql.general_log` テーブルに、スロークエリを `mysql.slow_log` テーブルに書き込みます。
+ **FILE** - 一般クエリログとスロークエリログの両方をファイルシステムに書き込みます。
+ **NONE** - ログ記録を無効にします。
Aurora MySQL バージョン 2 および 3 の場合、`log_output` のデフォルトは `FILE` です。
スロークエリデータを Amazon CloudWatch Logs に表示するには、次の条件を満たす必要があります。
+ スロークエリログを含むように CloudWatch Logs を設定する必要があります。
+ `slow_query_log` を有効にする必要があります。
+ `log_output`/ を に設定する必要があります。`FILE`
+ クエリに要する時間が、`long_query_time` に設定された時間よりも長い必要があります。
スロークエリと一般ログの詳細については、MySQL ドキュメントの以下のトピックを参照してください。
+ [スロークエリログ](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html)
+ [一般クエリログ](https://dev.mysql.com/doc/refman/8.0/en/query-log.html)
## Aurora MySQL の監査ログ
Aurora MySQL の監査ログは、高度な監査と呼ばれます。高度な監査を有効にするには、特定の DB クラスターパラメータを設定します。詳細については、「[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md)」を参照してください。
## Aurora MySQL インスタンスログ
Aurora は、自動一時停止が有効になっている DB インスタンスに対して別のログファイルを作成します。この instance.log ファイルは、これらの DB インスタンスが想定どおりに一時停止できなかった理由を記録します。インスタンスログファイルの動作と Aurora の自動一時停止機能の詳細については、「[Aurora Serverless v2 の一時停止と再開アクティビティのモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log)」を参照してください。
## Aurora MySQL のログのローテーションと保持
ログ記録が有効になっている場合、Amazon Aurora は、ログファイルの削除を定期的に実行します。これは、ログファイルが大きくなることでデータベースが使用できなくなったりパフォーマンスに影響する可能性を低く抑えるための予防措置です。Aurora MySQL は、次のようにローテーションと削除を処理します。
+ Aurora MySQL エラーログファイルのサイズは、DB インスタンスのローカルストレージの 15 パーセント以下に制約されます。このしきい値を維持するために、ログは 1 時間ごとに自動的にローテーションされます。Aurora MySQL は 30 日後、またはディスク領域の 15 % が使用されると、ログを削除します。古いログファイルを削除した後、ログファイルの合計サイズがしきい値を超えている場合、ログファイルのサイズがしきい値以下になるまで、最も古いログファイルから順に削除されます。
+ Aurora MySQL は、24 時間後、またはストレージの 15% が消費されると、監査、一般、および低速クエリログを削除します。
+ `FILE` ログ記録が有効になっている場合、一般ログとスロークエリログファイルの検査が 1 時間ごとに実行され、作成後 24 時間を超えた古いログファイルは削除されます。場合によっては、削除後の残りのログファイルの合計サイズが、DB インスタンスのローカル領域のしきい値である 15 % を超えることがあります。この場合、ログファイルのサイズがしきい値以下になるまで、最も古いログファイルから順に削除されます。
+ `TABLE` ログ記録が有効化されている場合、ログテーブルはローテーションまたは削除されません。結合されたすべてのログのサイズが大きすぎると、ログテーブルは切り捨てられます。`low storage` イベントカテゴリにサブスクライブして、ログテーブルが手動でローテーションされたり削除されたりして領域が解放されたときに通知を受け取ることができます。詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
`mysql.general_log` テーブルの手動ローテーションは、`mysql.rds_rotate_general_log` プロシージャを呼び出すことで実行できます。`mysql.slow_log` テーブルのローテーションは、`mysql.rds_rotate_slow_log` プロシージャを呼び出すことで実行できます。
ログテーブルをローテーションすると、現在のログテーブルがバックアップのログテーブルにコピーされ、現在のログテーブル内にあるエントリは削除されます。バックアップのログテーブルが既に存在する場合は、現在のログテーブルをバックアップにコピーする前に、削除されます。バックアップのログテーブルは、必要に応じて照会することができます。`mysql.general_log` テーブルに対するバックアップのログテーブルは、`mysql.general_log_backup` という名前になります。`mysql.slow_log` テーブルに対するバックアップのログテーブルは、`mysql.slow_log_backup` という名前になります。
+ Aurora MySQL 監査ログは、ファイルサイズが 100 MB に達するとローテーションされ、24 時間後に削除されます。
+ Amazon RDS は、10 MB を超える IAM データベース認証エラーログファイルをローテーションします。Amazon RDS は、5 日以上経過しているか、100 MB を超える IAM データベース認証エラーログファイルを削除します。
Amazon RDS コンソール、Amazon RDS API、Amazon RDS CLI、または AWS SDK からログを使用するには、`log_output` パラメータを FILE に設定します。Aurora MySQL エラーログと同様、これらのログファイルは 1 時間ごとにローテーションされます。直前 24 時間以内に生成されたログファイルが保持されます。Amazon RDS と Aurora で保持期間が異なる点に注意してください。
## Amazon CloudWatch Logs への Aurora MySQL ログの発行
Aurora MySQL DB クラスターを設定して、ログデータを Amazon CloudWatch Logs のロググループに発行することができます。CloudWatch Logs を使用すると、ログデータのリアルタイム分析や、CloudWatch を使用したアラームの作成、メトリクスの表示を行うことができます。CloudWatch Logs を使用して、耐久性の高いストレージにログレコードを格納できます。詳しくは、「[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](AuroraMySQL.Integrating.CloudWatch.md)」を参照してください。
# テーブルへの Aurora MySQL ログ出力の送信
DB パラメータグループを作成し、`log_output` サーバーパラメータを `TABLE` に設定することで、DB インスタンス上のテーブルに一般ログとスロークエリログを書き込むことができます。その後、一般クエリは `mysql.general_log` テーブルに記録され、スロークエリは `mysql.slow_log` テーブルに記録されます。それらのテーブルに対してクエリを実行することでログの情報にアクセスできます。このログ記録を有効にすると、データベースに書き込まれるデータの量が増え、パフォーマンスが低下することがあります。
一般ログもスロークエリログもデフォルトで無効になっています。テーブルへのログ記録を有効にするには、`general_log` と `slow_query_log` のサーバーパラメータを `1` に設定する必要があります。
ログテーブルは、それぞれのログ記録アクティビティのパラメータを `0` にリセットしてログ記録をオフにするまで、拡大し続けます。大量のデータが長期にわたって蓄積されることがよくあり、割り当てストレージ領域の大部分を使い果たすことがあります。Amazon Aurora では、ログテーブルを切り詰めることはできませんが、その内容を移動することはできます。テーブルのローテーションにより、その内容がバックアップテーブルに保存され、新しい空のログテーブルが作成されます。以下のコマンドラインプロシージャを使用して、ログテーブルを手動でローテーションされることができます。ここで表示されている `PROMPT>` はコマンドプロンプトです。
```
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
```
以前のデータを完全に削除し、ディスク領域を再利用するには、該当するプロシージャを 2 回連続で呼び出します。
# シングル AZ データベースの Aurora MySQL バイナリログの設定
*バイナリログ*は、Aurora MySQL サーバーインスタンスで行われたデータ変更に関する情報を含む、一連のログファイルです。バイナリログには、以下のような情報が含まれています。
+ テーブルの作成や行の変更など、データベースの変更が記述されたイベント
+ データを更新した各ステートメントの実行時間に関する情報
+ データを更新する可能性があったものの、それが実行されていないステートメントのイベント
バイナリログには、レプリケーション中に送信されるステートメントが記録されます。また、一部のリカバリオペレーションにもバイナリログが必要です。詳細については、MySQL ドキュメントの「[バイナリログ](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)」を参照してください。
バイナリログは、プライマリ DB インスタンスからのみアクセスでき、レプリカからはアクセスできません。
Amazon Aurora の MySQL では、*行ベース*、*ステートメントベース*、および*混合*のバイナリログ形式がサポートされています。特定バイナリログ形式が必要でない場合は、混合形式を使用することをお勧めします。Aurora MySQL の各種バイナリログ形式の詳細については、MySQL ドキュメントの「[Binary logging formats](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html)」を参照してください。
レプリケーションを使用する予定の場合は、バイナリログ記録形式が重要です。ソースに記録されてレプリケーションターゲットに送信されるデータ変更記録が決定されるからです。レプリケーション用のさまざまなバイナリログ記録形式の利点と欠点についての詳細は、MySQL ドキュメントの「[Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html)」を参照してください。
**重要**
MySQL 8.0.34 では、`binlog_format` パラメータが廃止されました。以降の MySQL バージョンでは、このパラメータを削除し、行ベースのレプリケーションのみをサポートする予定です。そのため、新しい MySQL レプリケーション設定には行ベースのログ記録を使用することをお勧めします。詳細については、MySQL ドキュメントの「[binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format)」を参照してください。
MySQL バージョン 8.0 および 8.4 は、パラメータ `binlog_format` を受け入れます。このパラメータを使用すると、MySQL は非推奨警告を発行します。今後のメジャーリリースで、MySQL はパラメータ `binlog_format` を削除します。
ステートメントベースのレプリケーションは、ソース DB クラスターとリードレプリカの間の不整合の原因になります。詳細については、MySQL ドキュメントの「[バイナリログ作成における安全なステートメントと安全でないステートメントの判断](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html)」を参照してください。
バイナリログを有効にすると、DB クラスターへの書き込みディスク I/O 操作の回数が増えます。```VolumeWriteIOPs` CloudWatch メトリクスを使用して、IOPS の使用状況をモニタリングできます。
**MySQL バイナリログ形式を設定するには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[Parameter groups]** (パラメータグループ) を選択します。
1. 変更する DB クラスターに関連付ける DB クラスターのパラメータグループを選択します。
デフォルトのパラメータグループを変更することはできません。DB クラスターがデフォルトのパラメータグループを使用している場合、新しいパラメータグループを作成し DB クラスターと関連付けます。
パラメータグループの詳細については、「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
1. **[アクション]** から **[編集]** を選択します。
1. `binlog_format` パラメータを、選択したバイナリログ形式 (`ROW`、`STATEMENT`、または `MIXED`) に設定します。また、`OFF` の値を使用して、バイナリログ記録をオフにすることもできます。
**注記**
DB クラスターパラメータグループで `binlog_format` を `OFF` に設定すると、`log_bin` セッション変数が無効になります。これにより、Aurora MySQL DB クラスターのバイナリログ記録が無効になり、`binlog_format` セッション変数がデータベースのデフォルト値の `ROW` にリセットされます。
1. [**変更の保存**] を選択して、更新を DB クラスターパラメータグループに保存します。
これらのステップを実行した後、変更を適用するには、DB クラスターのライターインスタンスを再起動する必要があります。Aurora MySQL バージョン 2.09 以前では、ライターインスタンスを再起動すると、DB クラスター内のすべてのリーダーインスタンスも再起動されます。Aurora MySQL バージョン 2.10 以降では、すべてのリーダーインスタンスを手動で再起動する必要があります。詳細については、「[Amazon Aurora DB クラスターまたは Amazon Aurora DB インスタンスの再起動](USER_RebootCluster.md)」を参照してください。
**重要**
DB クラスターパラメータグループを変更すると、そのパラメータグループを使用するすべての DB クラスターに影響を与えます。AWS リージョン内の異なる Aurora MySQL DB クラスターに異なるバイナリログ形式を指定する場合、DB クラスターは異なる DB クラスターパラメータグループを使用する必要があります。これらのパラメータグループは、さまざまなログ形式を識別します。各 DB クラスターに適切な DB クラスターパラメータグループを割り当てます。Aurora MySQL パラメータの詳細については、「[Aurora MySQL 設定パラメータ](AuroraMySQL.Reference.ParameterGroups.md)」を参照してください。
# MySQL バイナリログにアクセスする
mysqlbinlog ユーティリティを使用して、RDS for MySQL DB インスタンスからバイナリログをダウンロードまたはストリーミングできます。バイナリログはローカルコンピュータにダウンロードされ、mysql ユーティリティを使用してログの再生などの操作を実行できます。mysqlbinlog ユーティリティの使用の詳細については、MySQL ドキュメントの「[バイナリログファイルのバックアップのための mysqlbinlog の使用](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html)」を参照してください。
Amazon RDS インスタンスに対して mysqlbinlog ユーティリティを実行するには、以下のオプションを使用します。
+ `--read-from-remote-server` – 必須。
+ `--host` - インスタンスのエンドポイントからの DNS 名。
+ `--port` - インスタンスによって使用されるポート。
+ `--user` – `REPLICATION SLAVE` アクセス許可を付与された MySQL ユーザー。
+ `--password` - MySQL ユーザーのパスワード。パスワード値を省略省略した場合、ユーティリティによってパスワードの入力を求められます。
+ `--raw` — バイナリ形式のファイルをダウンロードします。
+ `--result-file` - raw 出力を受け取るローカルファイル。
+ `--stop-never` — バイナリログファイルをストリーミングします。
+ `--verbose` — `ROW` binlog 形式を使用するとき、このオプションを含めると、行イベントが疑似 SQL ステートメントとして表示されます。`--verbose` オプションの詳細については、MySQL ドキュメントの「[mysqlbinlog row event display](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html)」(mysqlbinlog の行イベントの表示) を参照してください。
+ 1 つ以上のバイナリログファイルの名前を指定します。使用可能なログのリストを取得するには、SQL コマンド `SHOW BINARY LOGS` を使用します。
mysqlbinlog のオプションの詳細については、MySQL ドキュメントの「[mysqlbinlog - バイナリログファイルを処理するためのユーティリティ](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html)」を参照してください。
以下の例では、mysqlbinlog ユーティリティの使用方法を示します。
Linux、macOS、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
```
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
```
mysqlbinlog ユーティリティがバイナリログにアクセスするには、バイナリログが DB インスタンスで利用可能な状態である必要があります。可用性を確保するには、[mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) ストアドプロシージャを使用して、ログをダウンロードできる十分な期間を指定します。この設定を行わないと、Amazon RDS はバイナリログをできるだけ早く消去するため、mysqlbinlog ユーティリティが取得するバイナリログにギャップが生じます。
以下の例では、保持期間を 1 日に設定しています。
```
call mysql.rds_set_configuration('binlog retention hours', 24);
```
現在の設定を表示するには、[mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration) ストアドプロシージャを使用します。
```
call mysql.rds_show_configuration;
```
# Aurora PostgreSQL データベースログファイル
次の種類の Aurora PostgreSQL ログファイルをモニタリングできます。
+ PostgreSQL ログ
+ インスタンスログ
+ IAM データベース認証エラーログ
**注記**
IAM データベース認証エラーログを有効にするには、まず Aurora PostgreSQL DB クラスターの IAM データベース認証を有効にする必要があります。IAM データベース認証の有効化の詳細については、「[IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)」を参照してください。
Aurora PostgreSQL では、データベースアクティビティをデフォルトの PostgreSQL ログファイルに記録します。オンプレミスの PostgreSQL DB インスタンスの場合、これらのメッセージは `log/postgresql.log` にローカルに保存されます。Aurora PostgreSQL DB クラスター、の場合、ログファイルは Aurora クラスター にあります。これらのログには、AWS マネジメントコンソール 経由でアクセスすることもできます。ここでは、ログを表示またはダウンロードできます。デフォルトのロギングレベルは、ログインの失敗、致命的なサーバーエラー、デッドロック、およびクエリエラーをキャプチャします。
ファイルベースのデータベースログの表示、ダウンロード、モニタリングの方法の詳細については、「[Amazon Aurora ログファイルのモニタリング](USER_LogAccess.md)」を参照してください。PostgreSQL ログの詳細については、「[Amazon RDS および Aurora PostgreSQL ログの操作: パート 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/)」および「[Amazon RDS および Aurora PostgreSQL ログの操作: パート 2](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/)」を参照してください。
このトピックで説明した標準の PostgreSQL ログに加えて、Aurora PostgreSQL は PostgreSQL 監査エクステンション (`pgAudit`) もサポートしています。規制対象の業界や政府機関のほとんどは、法的要件に準拠するために、データに加えられた変更の監査ログまたは監査証跡を維持する必要があります。pgAudit のインストールおよび使用の詳細については、「[pgAudit を使用してデータベースのアクティビティを記録する](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)」を参照してください。
Aurora は、自動一時停止が有効になっている DB インスタンスに対して別のログファイルを作成します。この instance.log ファイルは、これらの DB インスタンスが想定どおりに一時停止できなかった理由を記録します。インスタンスログファイルの動作と Aurora の自動一時停止機能の詳細については、「[Aurora Serverless v2 の一時停止と再開アクティビティのモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log)」を参照してください。
**Topics**
+ [Aurora PostgreSQL でのログ記録のパラメータ](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md)
+ [Aurora PostgreSQL DB クラスター のクエリログ記録をオンにする](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md)
# Aurora PostgreSQL でのログ記録のパラメータ
さまざまなパラメータを変更することで、Aurora PostgreSQL DB クラスター のロギング動作をカスタマイズできます。次のテーブルには、ログの保存期間、ログをローテーションするタイミング、ログを CSV (カンマ区切り値) 形式で出力するかどうかなどに影響するパラメータがあります。他の設定の中でも、STDERR に送信されたテキスト出力を確認できます。変更可能なパラメータの設定を変更するには、Aurora PostgreSQL DB クラスターのカスタム DB クラスター パラメータグループを使用します。詳細については、「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
| パラメータ | デフォルト | 説明 |
| --- | --- | --- |
| log\$1destination | stderr | ログの出力形式を設定します。デフォルトは `stderr` ですが、設定に `csvlog` を追加してカンマ区切り値 (CSV) を指定することもできます。詳細については、「[ログの送信先の設定 (`stderr`、`csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format)」を参照してください。 |
| log\$1filename | postgresql.log.%Y-%m-%d-%H%M | ログファイル名のパターンを指定します。デフォルトに加えて、このパラメータはファイル名パターンの `postgresql.log.%Y-%m-%d` と `postgresql.log.%Y-%m-%d-%H` をサポートします。Aurora PostgreSQL バージョン 17.4 以降では、このパラメータを変更することはできません。 |
| log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | 時間 (%t)、リモート ホスト (%r)、ユーザー (%u)、データベース (%d)、およびプロセス ID (%p) を記録するために、`stderr` に書き込まれる各ログ行のプレフィックスを定義します。 |
| log\$1rotation\$1age | 60 | ログファイルが自動的にローテーションされるまでの分数。この値は、1～1,440 分の間で変更できます。詳細については、「[ログファイルのローテーションの設定](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)」を参照してください。 |
| log\$1rotation\$1size | – | ログが自動的にローテーションされるサイズ (kB)。この値は 50,000～1,000,000 キロバイトの範囲で変更できます。詳細については[ログファイルのローテーションの設定](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)を参照してください。 |
| rds.log\$1retention\$1period | 4320 | 指定した時間 (分) より古い PostgreSQL ログは削除されます。デフォルト値の 4,320 分では、3 日後にログファイルが削除されます。詳細については、「[ログの保持期間の設定](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period)」を参照してください。 |
アプリケーションの問題を特定するには、ログでクエリの失敗、ログインの失敗、デッドロック、および致命的なサーバーエラーを探すことができます。例えば、従来のアプリケーションを Oracle から Aurora PostgreSQL に変換したが、一部のクエリは正しく変換されなかったとします。これらの誤った形式のクエリは、ログにエラーメッセージを生成し、ログから問題を特定することができます。クエリログの詳細については、「[Aurora PostgreSQL DB クラスター のクエリログ記録をオンにする](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md)」参照してください。
次のトピックでは、PostgreSQL ログの基本的な詳細を制御するさまざまなパラメータの設定方法について説明します。
**Topics**
+ [ログの保持期間の設定](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period)
+ [ログファイルのローテーションの設定](#USER_LogAccess.Concepts.PostgreSQL.log_rotation)
+ [ログの送信先の設定 (`stderr`、`csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format)
+ [log\$1line\$1prefix パラメータの概要](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)
## ログの保持期間の設定
`rds.log_retention_period` パラメータは、Aurora PostgreSQL DB クラスター がログファイルを保持する期間を指定します。デフォルトの設定は 3 日 (4,320 分) ですが、この値を 1 日 (1,440 分) から 7 日 (10,080 分) までの任意の時間に設定できます。Aurora PostgreSQL DB クラスター に、一定期間ログファイルを保持するのに十分なストレージがあることを確認してください。
ログを定期的に Amazon CloudWatch Logs に公開することをお勧めします。これにより、ログが Aurora PostgreSQL DB クラスターから削除された後も、システムデータを表示して分析できます。詳細については、[Amazon CloudWatch Logs への Aurora PostgreSQL ログの発行](AuroraPostgreSQL.CloudWatch.md)。CloudWatch での公開を設定した後、ログが CloudWatch Logs に公開されるまで、Aurora はログを削除しません。
Amazon Aurora は、DB インスタンスのストレージがしきい値に達すると、古い PostgreSQL ログを圧縮します。Aurora は、gzip 圧縮ユーティリティを使用してファイルを圧縮します。詳細については、[gzip](https://www.gzip.org) のウェブサイトを参照してください。
DB インスタンスのストレージが少なく、使用可能なすべてのログが圧縮されると、次のような警告が表示されます。
```
Warning: local storage for PostgreSQL log files is critically low for
this Aurora PostgreSQL instance, and could lead to a database outage.
```
十分なストレージがない場合、Aurora は指定した保持期間が終了する前に圧縮済みの PostgreSQL ログを削除する可能性があります。その場合は、次のようなメッセージが表示されます。
```
The oldest PostgreSQL log files were deleted due to local storage constraints.
```
## ログファイルのローテーションの設定
Aurora は、デフォルトで 1 時間ごとに新しいログファイルを作成します。このタイミングは、`log_rotation_age` パラメータによって制御されます。このパラメータのデフォルト値は 60 (分) ですが、1 分から 24 時間 (1,440 分) までの任意の時間に設定できます。ローテーションの時期になると、新しい個別のログファイルが作成されます。ファイルには、`log_filename` パラメータによって指定されたパターンに従って名前が付けられます。
ログファイルは、`log_rotation_size` パラメータで指定されたサイズに従ってローテーションすることもできます。このパラメータは、ログが指定されたサイズ (キロバイト単位) に達したときにローテーションされるように指定します。デフォルトの `log_rotation_size` は、Aurora PostgreSQL DB クラスターの場合は 100,000 KB (キロバイト) ですが、この値を 50,000～1,000,000 キロバイトの任意の値に設定できます。
ログファイル名は、`log_filename` パラメータで指定されたファイル名のパターンに基づきます。このパラメータに使用できる設定は次のとおりです。
+ `postgresql.log.%Y-%m-%d` — ログファイル名のデフォルトフォーマット。年、月、日をログファイルの名前に含めます。
+ `postgresql.log.%Y-%m-%d-%H` — ログファイル名形式に時間を含めます。
+ `postgresql.log.%Y-%m-%d-%H%M` — 時間:分をログファイル名形式に含めます。
`log_rotation_age` パラメータを 60 分未満に設定した場合は、`log_filename` パラメータを分形式に設定します。
詳細については、PostgreSQL ドキュメントの「[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)」と「[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)」を参照してください。
## ログの送信先の設定 (`stderr`、`csvlog`)
デフォルトでは、Aurora PostgreSQL はスタンダードエラー (stderr) 形式でログを生成します。この形式は、`log_destination` パラメータのデフォルト設定です。各メッセージには、`log_line_prefix` パラメータで指定したパターンを使用してプレフィックスが付きます。詳細については、「[log\$1line\$1prefix パラメータの概要](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix)」を参照してください。
Aurora PostgreSQL は、`csvlog` フォーマットでログを生成することもできます。`csvlog` は、ログデータをカンマ区切り値 (CSV) データとして分析する場合に便利です。例えば、`log_fdw` 拡張機能を使用して外部テーブルとしてログを使用するとします。`stderr` ログファイルについて作成された外部テーブルには、ログイベントデータを含む 1 つの列が含まれます。`log_destination` パラメータに `csvlog` を追加すると、外部テーブルの複数の列の区切りを含む CSV 形式のログファイルが取得できます。ログをより簡単に分類して分析できるようになりました。
このパラメータに `csvlog` を指定する場合、`stderr` ファイル と `csvlog` ファイルの両方が生成されることに注意してください。ログのストレージと回転率に影響する `rds.log_retention_period` とその他の設定を考慮し、ログによって消費されるストレージに注意してください。`stderr` と `csvlog` を使用すると、ログで消費されるストレージが 2 倍以上になります。
`log_destination` に `csvlog` を追加して、`stderr` だけに戻す場合は、パラメータをリセットする必要があります。そのためには、Amazon RDS コンソールを開いて、インスタンスのカスタム DB クラスター パラメータグループを開きます。`log_destination` パラメータを選択し、**[Edit parameter]** (パラメータの編集) を選択し、**[Reset]** (リセット) を選択します。
ログの設定の詳細については、「[Amazon RDS および Aurora PostgreSQL ログの操作:パート 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/)」を参照してください。
## log\$1line\$1prefix パラメータの概要
`stderr` ログ形式では、各ログメッセージの先頭に `log_line_prefix` パラメータで指定した詳細が追加されます。デフォルト値は次のとおりです。
```
%t:%r:%u@%d:[%p]:t
```
Aurora PostgreSQL バージョン 16 以降では、以下を選択することもできます。
```
%m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a
```
stderr に送信される各ログエントリには、選択した値に応じて次の情報が含まれます。
+ `%t` – ミリ秒なしのログエントリの時刻
+ `%m` – ミリ秒付きのログエントリの時刻
+ `%r` – リモートホストのアドレス。
+ `%u@%d` – ユーザー名 @ データベース名。
+ `[%p]` – プロセス ID (使用可能な場合)。
+ `%l` – セッションあたりのログ行数
+ `%e` – SQL エラーコード
+ `%s` – プロセス開始時間
+ `%v` – 仮想トランザクション ID
+ `%x` – トランザクション ID
+ `%c` – セッション ID
+ `%q` – セッション以外のターミネータ
+ `%a` – アプリケーション名
# Aurora PostgreSQL DB クラスター のクエリログ記録をオンにする
次のテーブルに示すパラメータの一部を設定することで、クエリ、ロック待ちのクエリ、チェックポイント、その他多くの詳細を含む、データベースアクティビティに関するより詳細な情報を収集できます。このトピックでは、クエリのログ記録に焦点を当てます。
| パラメータ | デフォルト | 説明 |
| --- | --- | --- |
| log\$1connections | – | 成功した各接続をログに記録します。このパラメータを `log_disconnections` で使用して接続チャーンを検出する方法については、「[管理する Aurora PostgreSQL 接続チャーンとプーリング](AuroraPostgreSQL.BestPractices.connection_pooling.md)」を参照してください。 |
| log\$1disconnections | – | 各セッションの終了とその期間を記録します。このパラメータを `log_connections` で使用して接続チャーンを検出する方法については、「[管理する Aurora PostgreSQL 接続チャーンとプーリング](AuroraPostgreSQL.BestPractices.connection_pooling.md)」を参照してください。 |
| log\$1checkpoints | – | Aurora PostgreSQL には適用されません。 |
| log\$1lock\$1waits | – | 長期間にわたるロックの待機をログに記録します。デフォルトでは、このパラメータは設定されていません。 |
| log\$1min\$1duration\$1sample | – | (ms) ステートメントのサンプリングに関する最小実行時間を設定します。この値を超えるとステートメントがサンプリングされてログに記録されます。サンプルサイズは、log\$1statement\$1sample\$1rate パラメータを使用して設定されます。 |
| log\$1min\$1duration\$1statement | – | 少なくとも指定された時間以上実行された SQL ステートメントはすべてログに記録されます。デフォルトでは、このパラメータは設定されていません。このパラメータを有効にすると、最適化されていないクエリを見つけるために役立ちます。 |
| log\$1statement | – | ログに記録するステートメントのタイプを設定します。デフォルトでは、このパラメータは設定されていませんが、`all`、`ddl`、または `mod` に変更して、ログに記録する SQL ステートメントのタイプを指定できます。このパラメータの `none` 以外を指定する場合は、ログファイル内のパスワードが漏洩しないように、追加の手順も実行する必要があります。詳細については、「[クエリのログ記録を使用する際のパスワード漏洩リスクの軽減パスワード漏洩リスクの軽減](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk)」を参照してください。 |
| log\$1statement\$1sample\$1rate | – | `log_min_duration_sample` で指定された時間を超えるステートメントがログに記録される割合で、0.0 から 1.0 の間の浮動小数点値で表されます。 |
| log\$1statement\$1stats | – | 累積処理のパフォーマンスの統計情報をサーバーログに書き込みます。 |
## ログ記録を使用してパフォーマンスの低いクエリを見つける
SQL ステートメントとクエリをログに記録すると、パフォーマンスの悪いクエリを見つけるのに役立ちます。この機能を有効にするには、このセクションで説明されているとおり、`log_statement` および `log_min_duration` パラメータの設定を変更します。Aurora PostgreSQL DB クラスター、 のクエリログ記録を有効にする前に、ログにパスワードが漏洩する可能性と、そのリスクを軽減する方法について知っておく必要があります。詳細については、「[クエリのログ記録を使用する際のパスワード漏洩リスクの軽減パスワード漏洩リスクの軽減](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk)」を参照してください。
`log_statement` および `log_min_duration` のパラメータに関する参照情報は、以下を参照してください。log\$1statement
このパラメータは、ログに送信する SQL ステートメントのタイプを指定します。デフォルト値は `none` です。このパラメータを `all`、`ddl`、または `mod` に変更する場合は、ログにパスワードが漏洩するリスクを軽減するために、必ず推奨アクションを適用してください。詳細については、「[クエリのログ記録を使用する際のパスワード漏洩リスクの軽減パスワード漏洩リスクの軽減](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk)」を参照してください。
**すべて**
すべてのステートメントを記録します。この設定はデバッグ目的での使用を推奨します。
**ddl**
CREATE、ALTER、DROP などのすべてのデータ定義言語 (DDL) ステートメントをログに記録します。
**mod**
データを変更する DDL ステートメントと、INSERT、UPDATE、DELETE などのデータ操作言語 (DML) ステートメントをすべてログに記録します。
**なし**
SQL ステートメントはログに記録されません。ログにパスワードが漏れてしまうリスクを避けるため、この設定をお勧めします。log\$1min\$1duration\$1statement
少なくとも指定された時間以上実行された SQL ステートメントはすべてログに記録されます。デフォルトでは、このパラメータは設定されていません。このパラメータを有効にすると、最適化されていないクエリを見つけるために役立ちます。
**–1–2147483647**
ステートメントがログに記録される実行時間のミリ秒 (ms) 数。
**クエリのログ記録を設定するには**
これらのステップは、Aurora PostgreSQL DB クラスターがカスタム DB クラスターパラメータグループを使用していることを前提としています。
1. `log_statement` パラメータを `all` に設定します。以下の例に示しているのは、このパラメータ設定で `postgresql.log` ファイルに書き込まれる情報です。
```
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. `log_min_duration_statement` パラメータを設定します。以下の例に示しているのは、パラメータを `postgresql.log` に設定したときに `1` ファイルに書き込まれる情報です。
`log_min_duration_statement` パラメータで指定された期間を超えるクエリはログに記録されます。例を以下に示します。Aurora PostgreSQL DB クラスター のログファイルは 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 ----------------------
```
### クエリのログ記録を使用する際のパスワード漏洩リスクの軽減
パスワードが漏洩しないように、`log_statement` を `none` に設定したままにしておくことをお勧めします。`log_statement` を `all`、`ddl`、または `mod` に設定した場合は、次の手順を 1 つ以上実行することをお勧めします。
+ クライアントの場合は、機密情報を暗号化します。詳細については、PostgreSQL ドキュメントの「[暗号化オプション](https://www.postgresql.org/docs/current/encryption-options.html)」を参照してください。`CREATE` および `ALTER` ステートメントの `ENCRYPTED` (および`UNENCRYPTED`) オプションを使用してください。詳細については、PostgreSQL のドキュメントの「[CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html)」を参照してください。
+ Aurora PostgreSQL DB クラスター では 、PostgreSQL 監査 (pgAudit) 拡張機能をセットアップして使用します。この拡張機能は、ログに送信された CREATE および ALTER ステートメントの機密情報を編集します。詳細については、「[pgAudit を使用してデータベースのアクティビティを記録する](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)」を参照してください。
+ CloudWatch ログへのアクセスを制限します。
+ IAM など、より強力な認証メカニズムを使用してください。