# Amazon Aurora 로그 파일 모니터링
모든 RDS 데이터베이스 엔진은 감사 및 문제 해결을 위해 액세스할 수 있는 로그를 생성합니다. 로그 유형은 데이터베이스 엔진에 따라 다릅니다.
AWS Management Console, AWS Command Line Interface(AWS CLI) 또는 Amazon RDS API를 사용하여 DB 인스턴스 로그에 액세스할 수 있습니다. 트랜잭션 로그를 보거나 다운로드할 수 없습니다.
**참고**
경우에 따라 로그에 숨겨진 데이터가 포함됩니다. 따라서 AWS Management Console은 콘텐츠를 로그 파일에 표시할 수 있지만 다운로드할 때 로그 파일이 비어 있을 수 있습니다.
**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 Management Console을 사용하여 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. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **데이터베이스**를 선택합니다.
1. 보고자 하는 로그 파일을 보유한 DB 인스턴스의 이름을 선택합니다.
1. **로그 및 이벤트** 탭을 선택합니다.
1. 아래로 스크롤하여 **로그** 섹션을 찾습니다.
1. (선택 사항) 검색어를 입력하여 결과를 필터링합니다.
다음 예에는 텍스트 **error**로 필터링된 로그가 나와 있습니다.
![\[DB 로그 나열\]](http://docs.aws.amazon.com/ko_kr/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) 명령을 사용합니다.
다음 예에서는 `my-db-instance`라는 DB 인스턴스에 대한 로그 파일 목록을 반환합니다.
**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 Management Console, AWS CLI 또는 API를 사용하여 데이터베이스 로그 파일을 다운로드할 수 있습니다.
## 콘솔
**데이터베이스 로그 파일을 다운로드하려면**
1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **데이터베이스**를 선택합니다.
1. 보고자 하는 로그 파일을 보유한 DB 인스턴스의 이름을 선택합니다.
1. **로그 및 이벤트** 탭을 선택합니다.
1. 아래로 스크롤하여 [**Logs**] 섹션을 찾습니다.
1. **로그** 섹션에서 다운로드할 로그 옆에 있는 버튼을 선택한 다음 **다운로드**를 선택합니다.
1. 제공된 링크에 대한 컨텍스트(마우스 오른쪽 클릭) 메뉴를 열고 나서 [**Save Link As**]를 선택합니다. 로그 파일을 저장할 위치를 입력한 다음 **저장**을 선택합니다.
![\[로그 파일 보기\]](http://docs.aws.amazon.com/ko_kr/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**
대상 LinuxmacOS, 또는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 Management Console을 사용하여 로그 파일을 볼 수 있습니다. RDS는 5초마다 로그 테일을 새로 고칩니다.
**데이터베이스 로그 파일을 조사하려면**
1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **데이터베이스**를 선택합니다.
1. 보고자 하는 로그 파일을 보유한 DB 인스턴스의 이름을 선택합니다.
1. **로그 및 이벤트** 탭을 선택합니다.
![\[로그 및 이벤트 탭을 선택합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_logsEvents.png)
1. **로그** 섹션에서 로그 파일을 선택한 다음 **보기**를 선택합니다.
![\[로그를 선택합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch.png)
RDS는 다음 MySQL 예제와 같이 로그의 끝부분을 보여줍니다.
![\[로그 파일의 끝\]](http://docs.aws.amazon.com/ko_kr/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 Agent로 데이터를 관리할 수 있습니다.
**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. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **데이터베이스**를 선택합니다.
1. 다음 중 하나를 수행하세요.
+ **데이터베이스 생성**을 선택합니다.
+ 목록에서 데이터베이스를 선택한 다음 **수정**을 선택합니다.
1. **로그 내보내기**에서 게시할 로그를 선택합니다.
다음 예시에서는 Aurora MySQL DB 클러스터에 대한 감사 로그, 오류 로그, 일반 로그, 인스턴스 로그, IAM 데이터베이스 인증 오류 로그 및 느린 쿼리 로그를 지정합니다.
## CloudWatch Logs에서 로그 검색 및 필터링
CloudWatch Logs 콘솔을 이용하여 지정된 기준을 충족하는 로그 항목을 검색할 수 있습니다. CloudWatch Logs 콘솔로 연결되는 RDS 콘솔이나 CloudWatch Logs 콘솔에서 직접 로그에 액세스할 수 있습니다.
**콘솔을 이용하여 로그 항목 검색**
1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **데이터베이스**를 선택합니다.
1. DB 클러스터 또는DB 인스턴스를 고르십시오.
1. **구성**을 선택합니다.
1. **게시된 로그**에서 보려는 데이터베이스 로그를 선택합니다.
**CloudWatch Logs 콘솔을 사용하여 플로우 로그 레코드 검색**
1. [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다.
1. 탐색 창에서 **로그 그룹**을 선택합니다.
1. 필터 상자에 **/aws/rds**를 입력합니다.
1. **로그 그룹**에서 검색할 로그 스트림이 포함된 로그 그룹의 이름을 선택합니다.
1. **로그 스트림**에서 검색할 로그 스트림의 이름을 선택합니다.
1. **로그 이벤트**에서 사용할 필터 구문을 입력합니다.
자세한 내용은 *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 데이터베이스 로그 파일
Amazon RDS 콘솔, Amazon RDS API, AWS CLI 또는 AWS SDK를 통해 Aurora MySQL 로그를 직접 모니터링할 수 있습니다. 또한, 주 데이터베이스에 있는 데이터베이스 테이블로 로그를 전송하고 그 테이블을 쿼리하여 MySQL 로그에 액세스할 수 있습니다. mysqlbinlog 유틸리티를 사용하여 이진 로그를 다운로드할 수 있습니다.
파일 기반 데이터베이스 로그 보기, 다운로드 및 조사 방법에 대한 자세한 내용은 [Amazon Aurora 로그 파일 모니터링](USER_LogAccess.md) 단원을 참조하십시오.
**Topics**
+ [Aurora MySQL 데이터베이스 로그 개요](USER_LogAccess.MySQL.LogFileSize.md)
+ [AuroraMySQL 로그 출력을 표로 보내기](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 Management Console에서 오류 로그의 특정 크기(바이트 또는 킬로바이트)를 볼 수 있지만 다운로드할 때 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% 이하로 제한됩니다. 이 임계값을 유지하기 위해 매시간 로그가 자동으로 교체됩니다. Aurora MySQL은 30일 후 또는 디스크 공간의 15%가 차면 로그를 제거합니다. 오래된 로그 파일을 제거한 후 로그 파일의 총 크기가 임계값을 초과하는 경우에는 로그 파일의 전체 크기가 임계값 이하로 작아질 때까지 가장 오래된 로그 파일부터 차례대로 삭제됩니다.
+ Aurora MySQL는 24시간 후 또는 스토리지의 15%가 사용된 후 감사, 일반 및 느린 쿼리 로그를 제거합니다.
+ `FILE` 로깅을 사용하는 경우 일반 로그 및 느린 쿼리 로그 파일은 매시간 검사되며 24시간 이상 지난 로그 파일은 삭제됩니다. 삭제 후 남은 결합 로그 파일 크기가 DB 인스턴스에 할당된 로컬 공간 중 15%의 임계값을 초과하는 경우도 있습니다. 이 경우 로그 파일의 전체 크기가 임계값 이하로 작아질 때까지 가장 오래된 로그 파일부터 차례대로 삭제됩니다.
+ `TABLE` 로깅을 사용하는 경우 로그 테이블이 교체되거나 삭제되지 않습니다. 결합된 모든 로그의 크기가 너무 크면 로그 테이블이 잘립니다. 공간 확보를 위해 로그 테이블을 수동으로 교체하거나 삭제해야 할 때 알림을 받기 위해 `low storage` 이벤트 범주를 구독할 수 있습니다. 자세한 내용은 [Amazon RDS 이벤트 알림 작업](USER_Events.md) 섹션을 참조하세요.
`mysql.rds_rotate_general_log` 절차를 호출하면 수동으로 `mysql.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 감사 로그는 파일 크기가 100MB에 도달하면 교체되고 24시간 후에 제거됩니다.
+ Amazon RDS는 10MB보다 큰 IAM 데이터베이스 인증 오류 로그 파일을 교체합니다. Amazon RDS는 5일 이상 또는 100MB 이상의 IAM 데이터베이스 인증 오류 로그 파일을 제거합니다.
Amazon RDS 콘솔, Amazon RDS API, Amazon RDS CLI 또는 AWS SDK에서 로그를 사용하여 작업하려면 `log_output` 파라미터를 FILE로 설정합니다. Aurora MySQL 오류 로그와 마찬가지로, 이러한 로그 파일은 매시간 교체됩니다. 이전의 24시간 동안 생성된 로그 파일이 보존됩니다. 보존 기간은 Amazon RDS와 Aurora 간에 다릅니다.
## Amazon CloudWatch Logs에 Aurora MySQL 로그 게시
Amazon CloudWatch Logs의 로그 그룹에 로그 데이터를 게시하도록 Aurora MySQL DB 클러스터를 구성할 수 있습니다. CloudWatch Logs를 통해 로그 데이터에 대한 실시간 분석을 수행할 수 있고, CloudWatch를 사용하여 경보를 만들고 지표를 볼 수 있습니다. CloudWatch Logs를 사용하여 내구성이 뛰어난 스토리지에 로그 레코드를 저장할 수 있습니다. 자세한 내용은 [Amazon CloudWatch Logs에 Amazon Aurora MySQL 로그 게시](AuroraMySQL.Integrating.CloudWatch.md) 섹션을 참조하세요.
# AuroraMySQL 로그 출력을 표로 보내기
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;
```
오래된 데이터를 완전히 제거하고 디스크 공간을 회수하려면 알맞은 프로시저를 두 번 연속으로 호출합니다.
# 단일 AZ 데이터베이스의 Aurora MySQL 이진 로깅 구성
*이진 로그*는 Aurora MySQL 서버 인스턴스의 데이터 수정에 대한 정보를 포함하는 로그 파일 세트입니다. 이진 로그에는 다음과 같은 정보가 포함되어 있습니다.
+ 테이블 생성 또는 행 수정과 같은 데이터베이스 변경 사항을 설명하는 이벤트
+ 데이터를 업데이트한 각 문의 기간에 대한 정보
+ 데이터를 업데이트할 수 있었지만 업데이트하지 않은 문에 대한 이벤트
이진 로그는 복제 중 전송된 문을 기록합니다. 일부 복구 작업에도 필요합니다. 자세한 내용은 MySQL 설명서의 [바이너리 로그](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) 단원을 참조하십시오.
바이너리 로그는 복제본이 아닌 프라이머리 DB 인스턴스에서만 액세스할 수 있습니다.
Amazon Aurora의 MySQL은 *행 기반*, *문 기반*, *혼합* 바이너리 로깅 형식을 지원합니다. 특정한 binlog 형식이 필요한 경우가 아니면 혼합하는 것이 좋습니다. 다양한 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에서 MySQL이 `binlog_format` 파라미터를 더 이상 사용하지 않습니다. 이후 MySQL 버전에서 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 설명서의 [Determination of Safe and Unsafe Statements in Binary Logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html)을 참조하십시오.
이진 로깅을 활성화하면 DB 클러스터에 대한 평균 디스크 쓰기 I/O 작업 수가 증가합니다. ```VolumeWriteIOPs` CloudWatch 지표를 사용하여 IOPS 사용량을 모니터링할 수 있습니다.
**MySQL 이진 로깅 형식을 설정하려면**
1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **파라미터 그룹**을 선택합니다.
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` - 원시 출력을 수신할 로컬 파일.
+ `--stop-never` - 이진 로그 파일을 스트리밍합니다.
+ `--verbose` - `ROW` binlog 형식을 사용할 경우 이 옵션을 포함하면 행 이벤트를 유사 SQL 문으로 볼 수 있습니다. `--verbose` 옵션에 대한 자세한 내용은 MySQL 설명서의 [mysqlbinlog 행 이벤트 표시](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html)를 참조하세요.
+ 하나 이상의 이진 로그 파일의 이름을 지정합니다. 사용 가능한 로그의 목록을 획득하려면 SQL 명령 `SHOW BINARY LOGS`를 사용합니다.
mysqlbinlog 옵션에 대한 자세한 내용은 MySQL 설명서의 [mysqlbinlog - 이진 로그 파일 처리용 유틸리티](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html)를 참조하세요.
다음 예시에서는 mysqlbinlog 유틸리티를 사용하는 방법을 보여줍니다.
대상 LinuxmacOS, 또는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 Management Console을 통해 액세스할 수 있으며, 여기에서 해당 로그를 보거나 다운로드할 수 있습니다. 기본 로깅 수준에서는 로그인 실패, 치명적인 서버 오류, 교착 상태 및 쿼리 실패를 캡처합니다.
파일 기반 데이터베이스 로그 보기, 다운로드 및 조사 방법에 대한 자세한 내용은 [Amazon Aurora 로그 파일 모니터링](USER_LogAccess.md) 섹션을 참조하세요. PostgreSQL 로그에 대한 자세한 내용은 [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/)(RDS 및 Aurora PostgreSQL 로그로 작업하기: 파트 1) 및 [Working with Amazon RDS and Aurora PostgreSQL logs: Part 2](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/)(RDS 및 Aurora PostgreSQL 로그로 작업하기: 파트 2)를 참조하세요.
이 주제에서 설명하는 표준 PostgreSQL 로그 외에 Aurora PostgreSQL은 PostgreSQL Auidt 확장(`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\$11,000,000KB 범위 내에서 이 값을 변경할 수 있습니다. 자세한 내용은 [로그 파일 회전 설정](#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에서 해당 로그를 삭제하지 않습니다.
DB 인스턴스의 스토리지가 임계값에 도달하면 Amazon Aurora가 오래된 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는 기본적으로 매시간 새 로그 파일을 생성합니다. 타이밍은 `log_rotation_age` 파라미터로 제어됩니다. 이 파라미터의 기본값은 60(분)이지만 1분에서 24시간(1,440분) 사이로 설정할 수 있습니다. 교체 시간이 되면 새 로그 파일이 생성됩니다. 파일의 이름은 `log_filename` 파라미터로 지정된 패턴에 따라 결정됩니다.
로그 파일은 `log_rotation_size` 파라미터에 지정된 대로 크기에 따라 교체될 수도 있습니다. 이 파라미터는 로그가 지정된 크기(KB)에 도달하면 교체되도록 지정합니다. 기본값 `log_rotation_size`는 Aurora PostgreSQL DB 클러스터의 경우 100,000KB(킬로바이트)이지만 이 값을 50,000\$11,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` 로그 파일에 만들어진 외부 테이블에는 로그 이벤트 데이터가 있는 하나의 열이 포함되어 있습니다. `log_destination` 파라미터에 `csvlog`를 추가하면 외부 테이블의 여러 열에 대한 구분이 있는 CSV 형식의 로그 파일을 얻게 됩니다. 이제 로그를 더 쉽게 정렬하고 분석할 수 있습니다.
이 파라미터에 `csvlog`를 지정하는 경우 `stderr` 및 `csvlog` 파일이 모두 생성된다는 점에 유의하세요. `rds.log_retention_period` 및 로그 스토리지와 회전율에 영향을 주는 다른 설정을 고려하여 로그에서 사용하는 스토리지를 모니터링해야 합니다. `stderr` 및 `csvlog`를 사용하는 경우 로그에서 소비하는 스토리지가 두 배 이상 늘어납니다.
`log_destination`에 `csvlog`를 추가하고 `stderr`로만 되돌리려면 파라미터를 재설정해야 합니다. 이렇게 하려면 Amazon RDS 콘솔을 연 다음 인스턴스에 대한 사용자 지정 DB 클러스터 파라미터 그룹을 엽니다. `log_destination` 파라미터를 선택하고 **파라미터 편집**을 선택한 다음 **재설정**을 선택합니다.
로깅 구성에 대한 자세한 내용은 [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 | – | (밀리초) 문 샘플이 로그되는 최소 실행 시간을 설정합니다. 샘플 크기는 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**
모든 데이터 정의 언어(DDL) 문(CREATE, ALTER, DROP 등)을 로깅합니다.
**mod**
NSERT, UPDATE, DELETE 등 데이터를 수정하는 모든 DDL 문과 데이터 조작 언어(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` 파라미터에 지정된 기간을 초과하는 쿼리가 로깅됩니다. 다음은 그 한 예입니다. Amazon RDS 콘솔에서 Aurora PostgreSQL DB 클러스터에 대한 로그 파일을 볼 수 있습니다.
```
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`로 설정하는 경우 다음 단계 중 하나 이상을 수행하는 것이 좋습니다.
+ 클라이언트의 경우 민감한 정보를 암호화합니다. 자세한 내용은 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 Auditing(pgAudit) 확장을 설정하고 사용합니다. 이 확장은 로그로 전송된 CREATE 및 ALTER 문에서 민감한 정보를 삭제합니다. 자세한 내용은 [pgAudit를 사용하여 데이터베이스 활동 로깅](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md) 섹션을 참조하세요.
+ CloudWatch 로그에 대한 액세스를 제한합니다.
+ IAM 등의 보다 강력한 인증 메커니즘을 사용합니다.