# Lambda 함수 로그 작업
AWS Lambda는 문제 해결을 돕기 위해 사용자를 대신하여 Lambda 함수를 자동으로 모니터링합니다. Lambda 함수의 로그는 Lambda 콘솔, CloudWatch 콘솔, AWS Command Line Interface(AWS CLI), CloudWatch API.를 사용하여 확인할 수 있습니다. Amazon S3와 Firehose로 로그를 전송하도록 Lambda를 구성할 수도 있습니다.
함수의 [실행 역할](lambda-intro-execution-role.md)에 필요한 권한이 있는 한, Lambda는 함수가 처리하는 모든 요청에 대한 로그를 캡처하여 기본 대상인 Amazon CloudWatch Logs로 전송합니다. Lambda 콘솔을 사용하여 Amazon S3나 Firehose를 로깅 대상으로 구성할 수도 있습니다.
+ **CloudWatch Logs**는 Lambda 함수의 기본 로깅 대상입니다. CloudWatch Logs는 로그 데이터를 기반으로 지표와 경보를 생성할 수 있도록 지원하는 실시간 로그 보기 및 분석 기능을 제공합니다.
+ **Amazon S3**는 장기 스토리지에 경제적이며 Athena와 같은 서비스를 사용하여 로그를 분석할 수 있습니다. 일반적으로 지연 시간이 더 깁니다.
+ **Firehose**는 다양한 대상에 대한 로그의 관리형 스트리밍을 제공합니다. 다른 AWS 서비스(예: OpenSearch Service 또는 Redshift Data API)나 타사 플랫폼(예: Datadog, New Relic, Splunk)으로 로그를 전송해야 하는 경우 Firehose는 사전 구축된 통합을 제공하여 해당 프로세스를 간소화합니다. 추가 인프라를 설정하지 않고도 사용자 지정 HTTP 엔드포인트로 스트리밍할 수도 있습니다.
## 로그를 전송할 서비스 대상 선택
함수 로그의 대상으로 서비스를 선택할 때 다음 주요 요소를 고려하세요.
+ **비용 관리는 서비스에 따라 다릅니다.** Amazon S3는 일반적으로 장기 스토리지를 위한 가장 경제적인 옵션을 제공하는 반면, CloudWatch Logs를 사용하면 실시간으로 로그를 보고, 처리하고, 경고를 설정할 수 있습니다. Firehose 비용에는 스트리밍 서비스와 스트리밍하도록 구성한 대상과 관련된 비용이 모두 포함됩니다.
+ **분석 기능은 서비스마다 다릅니다.** CloudWatch Logs는 실시간 모니터링에 탁월하며, Logs Insights 및 Live Tail과 같은 다른 CloudWatch 기능과 기본적으로 통합됩니다. Amazon S3는 Athena와 같은 분석 도구와 잘 작동하며 추가 설정이 필요할 수 있지만 다양한 서비스와 통합할 수 있습니다. Firehose는 사전 구축된 통합을 제공하여 특정 AWS 서비스(OpenSearch Service, Redshift Data API 등)와 지원되는 타사 플랫폼(Datadog, Splunk 등)으로의 직접 스트리밍을 간소화하여 구성 작업을 줄일 수 있습니다.
+ **설정과 사용 편의성은 서비스에 따라 다릅니다.** CloudWatch Logs는 기본 로그 대상입니다. 추가 구성 없이 즉시 작동하며 CloudWatch 콘솔을 통해 간단한 로그 보기 및 분석을 제공합니다. Amazon S3로 전송되는 로그가 필요한 경우 Lambda 콘솔에서 초기 설정을 수행하고 버킷 권한을 구성해야 합니다. OpenSearch Service 또는 타사 분석 플랫폼과 같은 서비스로 직접 전송되는 로그가 필요한 경우 Firehose는 해당 프로세스를 간소화할 수 있습니다.
## 로그 대상 구성
AWS Lambda는 함수 로그에 대해 여러 대상을 지원합니다. 이 설명서는 사용 가능한 로깅 대상을 설명하며 필요에 적합한 옵션을 선택하는 데 도움이 됩니다. 선택한 대상에 관계없이 Lambda는 로그 형식, 필터링 및 전송을 제어하는 옵션을 제공합니다.
Lambda는 함수의 로그에 대해 JSON 형식과 일반 텍스트 형식을 모두 지원합니다. JSON 구조의 로그는 향상된 검색 기능을 제공하고 자동화된 분석을 가능하게 하는 반면, 일반 텍스트 로그는 단순성을 제공하고 잠재적으로 스토리지 비용을 절감해줍니다. 시스템 로그와 애플리케이션 로그 모두에 대한 로그 수준을 구성하여 Lambda가 선택한 대상으로 전송하는 로그를 제어할 수 있습니다. 필터링을 사용하면 스토리지 비용을 관리할 수 있고 디버깅 중 관련 로그 항목을 더 쉽게 찾을 수 있습니다.
각 대상에 대한 자세한 설정 지침은 다음 섹션을 참조하세요.
+ [CloudWatch Logs로 Lambda 함수 로그 전송](monitoring-cloudwatchlogs.md)
+ [Firehose로 Lambda 함수 로그 전송](logging-with-firehose.md)
+ [Amazon S3로 Lambda 함수 로그 전송](logging-with-s3.md)
## Lambda 함수에 대한 고급 로깅 제어 구성
함수의 로그를 캡처, 처리 및 사용하는 방법을 더 잘 제어할 수 있도록 Lambda는 다음과 같은 로깅 구성 옵션을 제공합니다.
+ **로그 형식** - 함수 로그에 대해 일반 텍스트와 정형 JSON 형식 중에서 선택합니다.
+ **로그 수준** - JSON 구조의 로그의 경우 Lambda가 CloudWatch로 전송하는 로그의 세부 수준(`FATAL`, `ERROR`, `WARN`, `INFO`, `DEBUG`, `TRACE` 등)을 선택합니다.
+ **로그 그룹** - 함수가 로그를 전송하는 CloudWatch 로그 그룹을 선택합니다.
고급 로깅 제어 구성에 대한 자세한 내용은 다음 섹션을 참조하세요.
+ [JSON 및 일반 텍스트 로그 형식 구성](monitoring-cloudwatchlogs-logformat.md)
+ [로그 수준 필터링](monitoring-cloudwatchlogs-log-level.md)
+ [CloudWatch 로그 그룹 구성](monitoring-cloudwatchlogs-loggroups.md)
# JSON 및 일반 텍스트 로그 형식 구성
로그 출력을 JSON 키 값 쌍으로 캡처하면 함수를 디버깅할 때 더 쉽게 검색하고 필터링할 수 있습니다. JSON 형식의 로그를 사용하면 로그에 태그와 컨텍스트 정보를 추가할 수도 있습니다. 이를 통해 대량의 로그 데이터를 자동으로 분석할 수 있습니다. 개발 워크플로가 Lambda 로그를 일반 텍스트로 사용하는 기존 도구를 사용하지 않는 한, 로그 형식으로 JSON을 선택하는 것이 좋습니다.
**Lambda 관리형 인스턴스**
Lambda 관리형 인스턴스는 JSON 로그 형식만 지원합니다. 관리형 인스턴스 함수를 생성하면 Lambda는 로그 형식을 JSON으로 자동 구성하고, 이를 일반 텍스트로 변경할 수는 없습니다. 관리형 인스턴스에 대한 자세한 내용은 [Lambda 관리형 인스턴스](lambda-managed-instances.md) 항목을 참조하세요.
모든 Lambda 관리형 런타임의 경우, 함수의 시스템 로그를 구조화되지 않은 일반 텍스트와 JSON 형식 중 어떻게 CloudWatch Logs에 보낼지 선택할 수 있습니다. 시스템 로그는 Lambda가 생성하는 로그이며 플랫폼 이벤트 로그라고도 합니다.
[지원되는 런타임](#monitoring-cloudwatchlogs-logformat-supported)의 경우, 지원되는 내장 로깅 방법 중 하나를 사용하면 Lambda는 함수의 애플리케이션 로그(함수 코드가 생성하는 로그)를 구조화된 JSON 형식으로 출력할 수도 있습니다. 이러한 런타임에 대해 함수의 로그 형식을 구성할 때 선택한 구성이 시스템 및 애플리케이션 로그 모두에 적용됩니다.
지원되는 런타임의 경우 함수가 지원되는 로깅 라이브러리 또는 메서드를 사용하는 경우 구조화된 JSON으로 로그를 캡처하기 위해 Lambda의 기존 코드를 변경할 필요가 없습니다.
**참고**
JSON 로그 형식을 사용하면 메타데이터가 추가되고 로그 메시지가 일련의 키 값 쌍을 포함하는 JSON 객체로 인코딩됩니다. 이로 인해 함수의 로그 메시지 크기가 커질 수 있습니다.
## 지원되는 런타임 및 로깅 메서드
Lambda는 현재 다음 런타임에 대해 JSON 구조화된 애플리케이션 로그를 출력하는 옵션을 지원합니다.
| 언어 | 지원되는 버전 |
| --- | --- |
| Java | Amazon Linux 1에서 Java 8을 제외한 모든 Java 런타임 |
| .NET | .NET 8 이상 |
| Node.js | Node.js 16 이상 |
| Python | Python 3.8 이상 |
| Rust | 해당 사항 없음 |
Lambda가 함수의 애플리케이션 로그를 구조화된 JSON 형식으로 CloudWatch에 보내려면 함수가 다음과 같은 내장 로깅 도구를 사용하여 로그를 출력해야 합니다.
+ **Java** - `LambdaLogger` 로거 또는 Log4j2. 자세한 내용은 [Java Lambda 함수 로깅 및 모니터링](java-logging.md) 섹션을 참조하세요.
+ **.NET** - 컨텍스트 객체의 `ILambdaLogger` 인스턴스. 자세한 내용은 [C\$1 Lambda 함수 로그 및 모니터링](csharp-logging.md) 섹션을 참조하세요.
+ **Node.js** - 콘솔 메서드`console.trace`, `console.debug`, `console.log`, `console.info`, `console.error` 및 `console.warn`. 자세한 내용은 [Node.js Lambda 함수 로깅 및 모니터링](nodejs-logging.md) 섹션을 참조하세요.
+ **Python** - 표준 Python `logging` 라이브러리. 자세한 내용은 [Python Lambda 함수 로깅 및 모니터링](python-logging.md) 섹션을 참조하세요.
+ **Rust**: `tracing` 크레이트. 자세한 내용은 [Rust Lambda 함수 기록 및 모니터링](rust-logging.md) 섹션을 참조하세요.
다른 관리형 Lambda 런타임의 경우, Lambda는 현재 구조화된 JSON 형식의 시스템 로그 캡처만 기본적으로 지원합니다. 하지만 JSON 형식의 로그 출력 출력에 대해 AWS Lambda용 Powertools와 같은 로깅 도구를 사용하면 모든 런타임에서 구조화된 JSON 형식으로 애플리케이션 로그를 캡처할 수 있습니다.
## 기본 로그 형식
현재 모든 Lambda 런타임의 기본 로그 형식은 일반 텍스트입니다. Lambda 관리형 인스턴스의 경우 로그 형식은 항상 JSON이며 변경할 수 없습니다.
이미 AWS Lambda용 Powertools과 같은 로깅 라이브러리를 사용하여 함수 로그를 JSON 구조 형식으로 생성하고 있다면 JSON 로그 형식 지정을 선택하면 코드를 변경할 필요가 없습니다. Lambda는 이미 JSON으로 인코딩된 로그를 이중 인코딩하지 않으므로 함수의 애플리케이션 로그는 이전과 같이 계속 캡처됩니다.
## 시스템 로그의 JSON 형식
함수의 로그 형식을 JSON으로 구성하면 각 시스템 로그 항목(플랫폼 이벤트)이 다음 키가 있는 키 값 쌍을 포함하는 JSON 객체로 캡처됩니다.
+ `"time"` - 로그 메시지가 생성된 시간
+ `"type"` - 로그되는 이벤트 유형
+ `"record"` - 로그 출력 내용
`"record"` 값 형식은 로그되는 이벤트 유형에 따라 달라집니다. 자세한 내용은 [텔레메트리 API `Event` 객체 유형](telemetry-schema-reference.md#telemetry-api-events)을 참조하세요. 시스템 로그 이벤트에 할당된 로그 수준에 대한 자세한 내용은 [시스템 로그 수준 이벤트 매핑](monitoring-cloudwatchlogs-log-level.md#monitoring-cloudwatchlogs-log-level-mapping)을 참조하세요.
비교를 위해 다음 두 예제는 일반 텍스트 형식과 구조화된 JSON 형식 모두에서 동일한 로그 출력을 보여줍니다. 대부분의 경우 시스템 로그 이벤트는 JSON 형식으로 출력할 때 일반 텍스트로 출력할 때보다 더 많은 정보를 포함합니다.
**Example 일반 텍스트**
```
2024-03-13 18:56:24.046000 fbe8c1 INIT_START Runtime Version: python:3.12.v18 Runtime Version ARN: arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0
```
**Example 구조화된 JSON**
```
{
"time": "2024-03-13T18:56:24.046Z",
"type": "platform.initStart",
"record": {
"initializationType": "on-demand",
"phase": "init",
"runtimeVersion": "python:3.12.v18",
"runtimeVersionArn": "arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0"
}
}
```
**참고**
[텔레메트리 API를 사용하여 확장의 실시간 텔레메트리 데이터에 액세스](telemetry-api.md)은 항상 JSON 형식으로 `START` 및 `REPORT` 등의 플랫폼 이벤트를 방출합니다. Lambda가 CloudWatch로 보내는 시스템 로그의 형식을 구성해도 Lambda Telemetry API 동작에는 영향을 주지 않습니다.
## 애플리케이션 로그의 JSON 형식
함수의 로그 형식을 JSON으로 구성하면 지원되는 로깅 라이브러리 및 메서드를 사용하여 작성된 애플리케이션 로그 출력이 다음 키와 함께 키 값 페어를 포함하는 JSON 객체로 캡처됩니다.
+ `"timestamp"` - 로그 메시지가 생성된 시간
+ `"level"` - 메시지에 할당된 로그 수준
+ `"message"` - 로그 메시지의 내용
+ `"requestId"`(Python, .NET 및 Node.js) 또는 `"AWSrequestId"`(Java) - 함수 간접 호출에 대한 고유한 요청 ID
함수에서 사용하는 런타임 및 로깅 방법에 따라 이 JSON 객체에 추가 키 페어가 포함될 수도 있습니다. 예를 들어 Node.js에서 함수가 `console` 메서드를 통해 여러 인수를 사용하여 오류 객체를 기록하는 경우 JSON 객체에는 키 `errorMessage`, `errorType`, `stackTrace`와 함께 추가 키 값 페어가 포함됩니다. 다양한 Lambda 런타임에서 JSON 형식 로그에 대한 자세한 내용은 [Python Lambda 함수 로깅 및 모니터링](python-logging.md), [Node.js Lambda 함수 로깅 및 모니터링](nodejs-logging.md), [Java Lambda 함수 로깅 및 모니터링](java-logging.md) 섹션을 참조하세요.
**참고**
Lambda가 타임스탬프 값에 사용하는 키는 시스템 로그와 애플리케이션 로그마다 다릅니다. 시스템 로그의 경우 Lambda는 `"time"` 키를 사용하여 텔레메트리 API와의 일관성을 유지합니다. 애플리케이션 로그의 경우 Lambda는 지원되는 런타임 의 규칙을 따르며 `"timestamp"`를 사용합니다.
비교를 위해 다음 두 예제는 일반 텍스트 형식과 구조화된 JSON 형식 모두에서 동일한 로그 출력을 보여줍니다.
**Example 일반 텍스트**
```
2024-10-27T19:17:45.586Z 79b4f56e-95b1-4643-9700-2807f4e68189 INFO some log message
```
**Example 구조화된 JSON**
```
{
"timestamp":"2024-10-27T19:17:45.586Z",
"level":"INFO",
"message":"some log message",
"requestId":"79b4f56e-95b1-4643-9700-2807f4e68189"
}
```
## 함수의 로그 형식 설정
함수의 로그 형식을 구성하려면 Lambda 콘솔 또는 AWS Command Line Interface(AWS CLI)을 사용할 수 있습니다. [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) 및 [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) Lambda API 명령, AWS Serverless Application Model(AWS SAM) [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) 리소스, CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html) 리소스를 사용하여 함수의 로그 형식을 구성할 수도 있습니다.
함수의 로그 형식을 변경해도 CloudWatch Logs에 저장된 기존 로그에는 영향을 주지 않습니다. 새 로그만 업데이트된 형식을 사용합니다.
함수의 로그 형식을 JSON으로 변경하고 로그 수준을 설정하지 않으면 Lambda는 함수의 애플리케이션 로그 수준과 시스템 로그 수준을 정보로 자동 설정합니다. 즉, Lambda는 정보 수준 이하의 로그 출력만 CloudWatch Logs로 전송합니다. 애플리케이션 및 시스템 로그 수준 필터링에 대한 자세한 내용은 [로그 수준 필터링](monitoring-cloudwatchlogs-log-level.md) 섹션을 참조하세요.
**참고**
Python 런타임의 경우 함수의 로그 형식이 일반 텍스트로 설정된 경우 기본 로그 수준 설정은 경고입니다. 즉, Lambda는 경고 수준 이하의 로그 출력만 CloudWatch Logs로 전송합니다. 함수의 로그 형식을 JSON으로 변경하면 이 기본 동작이 변경됩니다. Python에서 로깅에 대해 자세한 내용은 [Python Lambda 함수 로깅 및 모니터링](python-logging.md) 섹션을 참조하세요.
임베디드 지표 형식 (EMF) 로그를 내보내는 Node.js 함수의 경우 함수의 로그 형식을 JSON으로 변경하면 CloudWatch에서 지표를 인식하지 못할 수 있습니다.
**중요**
함수가 AWS Lambda용 Powertools(TypeScript) 또는 오픈 소스 EMF 클라이언트 라이브러리를 사용하여 EMF 로그를 방출하는 경우 CloudWatch가 계속해서 로그를 올바르게 구문분석할 수 있도록 [Powertools](https://github.com/aws-powertools/powertools-lambda-typescript) 및 [EMF](https://www.npmjs.com/package/aws-embedded-metrics) 라이브러리를 최신 버전으로 업데이트합니다. JSON 로그 형식으로 전환하는 경우 함수에 내장된 지표와의 호환성을 확인하기 위한 테스트도 수행하는 것이 좋습니다. EMF 로그를 내보내는 node.js 함수에 대한 자세한 내용은 [구조화된 JSON 로그가 포함된 임베디드 메트릭 형식(EMF) 클라이언트 라이브러리 사용](nodejs-logging.md#nodejs-logging-advanced-emf)을 참조하십시오.
**함수의 로그 형식 구성하기(콘솔)**
1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 함수 선택
1. 함수 구성 페이지에서 **모니터링 및 작업 도구**를 선택합니다.
1. **로깅 구성** 창에서 **편집**을 선택합니다.
1. **로그 콘텐츠**에서 **로그 형식**에 대해 **텍스트** 또는 **JSON**을 선택합니다.
1. **저장**을 선택합니다.
**기존 함수의 로그 형식 변경하기(AWS CLI)**
+ 기존 함수의 로그 형식을 변경하려면 [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) 명령을 사용합니다. `LoggingConfig`에서 `LogFormat` 옵션을 `JSON` 또는 `Text`로 설정합니다.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON
```
**함수를 생성할 때 로그 형식 설정하기(AWS CLI)**
+ 새 함수를 만들 때 로그 형식을 구성하려면 `--logging-config` 옵션을 [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) 명령에서 사용합니다. `LogFormat`을 `JSON` 또는 `Text`로 설정합니다. 다음 예제 명령은 구조화된 JSON으로 로그를 출력하는 Node.js 함수를 생성합니다.
함수를 생성할 때 로그 형식을 지정하지 않으면 Lambda는 선택한 런타임 버전의 기본 로그 형식을 사용합니다. 기본 로깅 형식에 대한 자세한 내용은 [기본 로그 형식](#monitoring-cloudwatchlogs-format-default)을 참조하세요.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON
```
# 로그 수준 필터링
Lambda는 특정 세부 수준 이하의 로그만 CloudWatch Logs로 전송되도록 함수의 로그를 필터링할 수 있습니다. 함수의 시스템 로그(Lambda가 생성하는 로그)와 애플리케이션 로그(함수 코드가 생성하는 로그)에 대해 개별적으로 로그 수준 필터링을 구성할 수 있습니다.
[지원되는 런타임 및 로깅 메서드](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-logformat-supported)의 경우 함수의 애플리케이션 로그를 필터링하기 위해 Lambda의 함수 코드를 변경할 필요가 없습니다.
다른 모든 런타임 및 로깅 메서드의 경우 함수 코드는 키 `"level"`과 키 값 쌍을 포함하는 JSON 형식의 객체로 로그 이벤트를 `stdout` 또는 `stderr`에 출력해야 합니다. 예를 들어 Lambda는 다음 `stdout`으로의 출력을 DEBUG 수준 로그로 해석합니다.
```
print('{"level": "debug", "msg": "my debug log", "timestamp": "2024-11-02T16:51:31.587199Z"}')
```
`"level"` 값 필드가 유효하지 않거나 누락된 경우 Lambda는 로그 출력에 수준 INFO를 할당합니다. Lambda가 타임스탬프 필드를 사용하려면 유효한 [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) 타임스탬프 형식으로 시간을 지정해야 합니다. 유효한 타임스탬프를 제공하지 않으면 Lambda는 로그에 레벨 INFO를 할당하고 타임스탬프를 추가합니다.
타임스탬프 키의 이름을 지정할 때는 사용 중인 런타임의 규칙을 따르십시오. Lambda는 관리형 런타임에서 사용되는 대부분의 일반적인 명명 규칙을 지원합니다.
**참고**
로그 수준 필터링을 사용하려면 함수가 JSON 로그 형식을 사용하도록 구성해야 합니다. 현재 모든 Lambda 관리형 런타임의 기본 로그 형식은 일반 텍스트입니다. 함수의 로그 형식을 JSON으로 구성하는 방법을 알아보려면 [함수의 로그 형식 설정](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-set-format)을 참조하세요.
애플리케이션 로그(함수 코드로 생성된 로그)의 경우 다음 로그 수준 중에서 선택할 수 있습니다.
| 로그 수준 | 표준 사용량 |
| --- | --- |
| TRACE(최대 세부 정보) | 코드 실행 경로를 추적하는 데 사용되는 가장 세밀한 정보 |
| DEBUG | 시스템 디버깅에 대한 세부 정보 |
| INFO | 함수의 정상 작동을 기록하는 메시지 |
| WARN | 해결되지 않을 경우 예상치 못한 동작으로 이어질 수 있는 잠재적 오류에 대한 메시지 |
| 오류 | 코드가 예상대로 작동하지 못하게 하는 문제에 대한 메시지 |
| FATAL(최소 세부 정보) | 응용 프로그램 작동을 중지시키는 심각한 오류에 대한 메시지 |
로그 수준을 선택하면 Lambda는 해당 수준 이하의 로그를 CloudWatch Logs로 보냅니다. 예를 들어 함수의 애플리케이션 로그 수준을 WARN으로 설정하면 Lambda는 INFO 및 DEBUG 수준에서 로그 출력을 전송하지 않습니다. 로그 필터링의 기본 애플리케이션 로그 수준은 INFO입니다.
Lambda가 함수의 애플리케이션 로그를 필터링할 때 레벨이 없는 로그 메시지에는 로그 수준 INFO가 할당됩니다.
시스템 로그(Lambda 서비스에서 생성된 로그)의 경우 다음 로그 수준 중에서 선택할 수 있습니다.
| 로그 수준 | 사용법 |
| --- | --- |
| DEBUG(최대 세부 정보) | 시스템 디버깅에 대한 세부 정보 |
| INFO | 함수의 정상 작동을 기록하는 메시지 |
| WARN(최소 세부 정보) | 해결되지 않을 경우 예상치 못한 동작으로 이어질 수 있는 잠재적 오류에 대한 메시지 |
로그 수준을 선택하면 Lambda는 해당 수준 이하의 로그를 전송합니다. 예를 들어 함수의 시스템 로그 수준을 INFO로 설정하면 Lambda는 DEBUG 수준에서 로그 출력을 전송하지 않습니다.
기본적으로 Lambda는 시스템 로그 레벨을 INFO로 설정합니다. 이 설정을 사용하면 Lambda는 자동으로 `"start"` 및 `"report"` 로그 메시지를 CloudWatch에 전송합니다. 더 많거나 덜 상세한 시스템 로그를 수신하려면 로그 수준을 DEBUG 또는 WARN으로 변경합니다. Lambda가 다양한 시스템 로그 이벤트를 매핑하는 로그 수준 목록을 보려면 [시스템 로그 수준 이벤트 매핑](#monitoring-cloudwatchlogs-log-level-mapping)을 참조하세요.
## 로그 수준 필터링 구성
함수에 대한 애플리케이션 및 시스템 로그 수준 필터링을 구성하려면 AWS Command Line Interface(AWS CLI)에서 Lambda 콘솔을 사용할 수 있습니다. [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) 및 [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) Lambda API 명령, AWS Serverless Application Model(AWS SAM) [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) 리소스, CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html) 리소스를 사용하여 함수의 로그 수준을 구성할 수도 있습니다.
코드에서 함수의 로그 수준을 설정하는 경우 이 설정은 구성된 다른 로그 수준 설정보다 우선합니다. 예를 들어 Python `logging` `setLevel()` 메서드를 사용하여 함수의 로깅 수준을 정보로 설정하는 경우 이 설정은 Lambda 콘솔을 사용하여 구성한 경고 설정보다 우선합니다.
**기존 함수의 애플리케이션 또는 시스템 로그 수준 구성하기(콘솔)**
1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 함수를 선택합니다.
1. 함수 구성 페이지에서 **모니터링 및 작업 도구**를 선택합니다.
1. **로깅 구성** 창에서 **편집**을 선택합니다.
1. **로그 콘텐츠**에서 **로그 형식**에 대해 **JSON**이 선택되어 있는지 확인합니다.
1. 라디오 버튼을 사용하여 함수에 대해 원하는 **애플리케이션 로그 수준** 및 **시스템 로그 수준**을 선택합니다.
1. **저장**을 선택합니다.
**기존 함수의 애플리케이션 또는 시스템 로그 수준 구성하기(AWS CLI)**
+ 기존 함수의 애플리케이션 또는 시스템 로그 수준을 변경하려면 [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) 명령을 사용합니다. `--logging-config`를 사용하여 `SystemLogLevel`을 `DEBUG`, `INFO` 또는 `WARN` 중 하나로 설정합니다. `ApplicationLogLevel`을 `DEBUG`, `INFO` `WARN`, `ERROR` 또는 `FATAL` 중 하나로 설정합니다.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
**함수를 생성할 때 로그 수준 필터링 구성하기**
+ 새 함수를 생성할 때 로그 수준 필터링을 구성하려면 `--logging-config`를 사용하여 [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) 명령에서 `SystemLogLevel` 및 `ApplicationLogLevel` 키를 설정합니다. `SystemLogLevel`을 `DEBUG`, `INFO` 또는 `WARN`중 하나로 설정합니다. `ApplicationLogLevel`을 `DEBUG`, `INFO` `WARN`, `ERROR` 또는 `FATAL` 중 하나로 설정합니다.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
## 시스템 로그 수준 이벤트 매핑
Lambda에서 생성된 시스템 수준 로그 이벤트의 경우 다음 표는 각 이벤트에 할당된 로그 수준을 정의합니다. 표에 나열된 이벤트에 대한 자세한 내용은 [Lambda Telemetry API `Event` 스키마 참조](telemetry-schema-reference.md)를 참조하세요.
| 이벤트 이름 | 조건 | 지정된 로그 수준 |
| --- | --- | --- |
| initStart | runtimeVersion is set | INFO |
| initStart | runtimeVersion is not set | DEBUG |
| initRuntimeDone | status=success | DEBUG |
| initRuntimeDone | status\$1=success | WARN |
| initReport | initializationType\$1=on-demand | INFO |
| initReport | initializationType=on-demand | DEBUG |
| initReport | status\$1=success | WARN |
| restoreStart | runtimeVersion is set | INFO |
| restoreStart | runtimeVersion is not set | DEBUG |
| restoreRuntimeDone | status=success | DEBUG |
| restoreRuntimeDone | status\$1=success | WARN |
| restoreReport | status=success | INFO |
| restoreReport | status\$1=success | WARN |
| 시작 | - | INFO |
| runtimeDone | status=success | DEBUG |
| runtimeDone | status\$1=success | WARN |
| report | status=success | INFO |
| report | status\$1=success | WARN |
| extension | state=success | INFO |
| extension | state\$1=success | WARN |
| logSubscription | - | INFO |
| telemetrySubscription | - | INFO |
| logsDropped | - | WARN |
**참고**
[텔레메트리 API를 사용하여 확장의 실시간 텔레메트리 데이터에 액세스](telemetry-api.md)은 항상 전체 플랫폼 이벤트 세트를 방출합니다. Lambda가 CloudWatch로 보내는 시스템 로그의 수준을 구성해도 Lambda Telemetry API 동작에는 영향을 미치지 않습니다.
## 사용자 지정 런타임을 사용한 애플리케이션 로그 수준 필터링
함수에 대한 애플리케이션 로그 레벨 필터링을 구성하면 Lambda는 `AWS_LAMBDA_LOG_LEVEL` 환경 변수를 사용하여 백그라운드에서 애플리케이션 로그 레벨을 설정합니다. 또한 Lambda는 `AWS_LAMBDA_LOG_FORMAT` 환경 변수를 사용하여 함수의 로그 형식을 설정합니다. 이러한 변수를 사용하여 Lambda 고급 로깅 제어를 [사용자 지정 런타임](runtimes-custom.md)에 통합할 수 있습니다.
Lambda 콘솔, AWS CLI 및 Lambda API로 사용자 지정 런타임을 사용하여 함수에 대한 로깅 설정을 구성하려면 이러한 환경 변수의 값을 확인하도록 사용자 지정 런타임을 구성합니다. 그런 다음 선택한 로그 형식 및 로그 수준에 따라 런타임의 로거를 구성할 수 있습니다.
# CloudWatch Logs로 Lambda 함수 로그 전송
기본적으로 Lambda는 함수의 실행 역할에 필요한 권한이 있는 경우 모든 함수 간접 호출에 대한 로그를 자동으로 캡처하여 CloudWatch Logs로 전송합니다. 이러한 로그는 기본적으로 /aws/lambda/**이라는 로그 그룹에 저장됩니다. 디버깅을 개선하기 위해 코드에 사용자 지정 로깅 문을 삽입하면 Lambda가 CloudWatch Logs와 완벽하게 통합됩니다. 필요한 경우 Lambda 콘솔, AWS CLI 또는 Lambda API를 사용하여 다른 그룹으로 로그를 전송하도록 함수를 구성할 수 있습니다. 자세한 내용은 [CloudWatch 로그 그룹 구성](monitoring-cloudwatchlogs-loggroups.md) 섹션을 참조하세요.
Lambda 함수의 로그는 Lambda 콘솔, CloudWatch 콘솔, AWS Command Line Interface(AWS CLI) 또는 CloudWatch API.를 사용해 확인할 수 있습니다. 자세한 내용은 [Lambda 함수에 대한 CloudWatch 로그 보기](monitoring-cloudwatchlogs-view.md) 섹션을 참조하세요.
**참고**
함수 호출 후 로그가 표시되는 데 5\$110분 정도 걸릴 수 있습니다.
## 필수 IAM 권한
[실행 역할](lambda-intro-execution-role.md)에는 CloudWatch Logs에 로그를 업로드할 수 있는 다음 권한이 필요합니다.
+ `logs:CreateLogGroup`
+ `logs:CreateLogStream`
+ `logs:PutLogEvents`
자세한 내용은 *Amazon CloudWatch 사용 설명서*의 [CloudWatch Logs에 대한 자격 증명 기반 정책(IAM 정책) 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html)을 참조하십시오.
Lambda에서 제공하는 `AWSLambdaBasicExecutionRole` AWS 관리형 정책을 사용하여 CloudWatch Logs 권한을 추가할 수 있습니다. 이 정책을 역할에 추가하려면 다음 명령을 실행합니다.
```
aws iam attach-role-policy --role-name your-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
자세한 내용은 [실행 역할에서 AWS 관리형 정책 작업](permissions-managed-policies.md) 섹션을 참조하세요.
## 요금
Lambda 로그 사용에 대한 추가 비용은 없지만 표준 CloudWatch Logs 비용이 적용됩니다. 자세한 내용은 [CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing/)을 참조하세요.
# CloudWatch 로그 그룹 구성
기본적으로 CloudWatch는 함수를 처음 간접 호출할 때 함수의 `/aws/lambda/`이라는 이름이 지정된 로그 그룹을 자동으로 생성합니다. 기존 로그 그룹에 로그를 전송하도록 함수를 구성하거나 함수에 대한 새 로그 그룹을 생성하려면 Lambda 콘솔 또는 AWS CLI를 사용할 수 있습니다. [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html), [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) Lambda API 명령 및 AWS Serverless Application Model (AWS SAM) [AWS::Serverless::Function]() 리소스를 사용하여 사용자 지정 로그 그룹을 구성할 수도 있습니다.
로그를 동일한 CloudWatch 로그 그룹에 전송하도록 여러 Lambda 함수를 구성할 수 있습니다. 예를 들어 단일 로그 그룹을 사용하여 특정 애플리케이션을 구성하는 모든 Lambda 함수에 대한 로그를 저장할 수 있습니다. Lambda 함수에 대한 사용자 지정 로그 그룹을 사용하는 경우 Lambda가 생성하는 로그 스트림에는 함수 이름과 함수 버전이 포함됩니다. 이렇게 하면 여러 함수에 동일한 로그 그룹을 사용하더라도 로그 메시지와 함수 간의 매핑이 보존됩니다.
사용자 지정 로그 그룹의 로그 스트림 이름 지정 형식은 다음 규칙을 따릅니다.
```
YYYY/MM/DD/[][]
```
사용자 지정 로그 그룹을 구성할 때 로그 그룹에 대해 선택한 이름은 [CloudWatch 로그 이름 지정 규칙](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)을 따라야 한다는 점에 유의합니다. 또한 사용자 지정 로그 그룹 이름은 `aws/` 문자열로 시작해서는 안 됩니다. `aws/`로 시작하는 사용자 지정 로그 그룹을 생성하는 경우 Lambda는 로그 그룹을 생성할 수 없습니다. 따라서 함수의 로그가 CloudWatch로 전송되지 않습니다.
**함수의 로그 그룹 변경하기(콘솔)**
1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 함수를 선택합니다.
1. 함수 구성 페이지에서 **모니터링 및 작업 도구**를 선택합니다.
1. **로깅 구성** 창에서 **편집**을 선택합니다.
1. **로깅 그룹** 창의 **CloudWatch 로그 그룹**에서 **사용자 지정**을 선택합니다.
1. **사용자 지정 로그 그룹**에서 함수가 로그를 전송하기를 원하는 CloudWatch 로그 그룹의 이름을 입력합니다. 기존 로그 그룹의 이름을 입력하면 함수가 해당 그룹을 사용합니다. 입력한 이름을 가진 로그 그룹이 없는 경우 Lambda는 해당 이름으로 함수에 대한 새 로그 그룹을 생성합니다.
**함수의 로그 그룹 변경하기(AWS CLI)**
+ 기존 함수의 로그 그룹을 변경하려면 [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) 명령을 사용합니다.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogGroup=myLogGroup
```
**함수를 생성할 때 사용자 지정 로그 그룹 지정하기(AWS CLI)**
+ AWS CLI를 사용하여 새 Lambda 함수를 생성할 때 사용자 지정 로그 그룹을 지정하려면 `--logging-config` 옵션을 사용하십시오. 다음 예제 명령은 `myLogGroup`이라는 로그 그룹에 로그를 보내는 Node.js Lambda 함수를 생성합니다.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogGroup=myLogGroup
```
## 실행 역할 권한
함수가 로그를 CloudWatch Logs로 전송하려면 해당 함수에 [logs:PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html) 권한이 있어야 합니다. Lambda 콘솔을 사용하여 함수의 로그 그룹을 구성하면 다음 조건에서 Lambda가 역할에 이 권한을 추가합니다.
+ 서비스 대상이 CloudWatch Logs로 설정됨
+ 함수의 실행 역할에 CloudWatch Logs(기본 대상)에 로그를 업로드할 수 있는 권한이 없습니다.
**참고**
Lambda가 Amazon S3 또는 Firehose 로그 대상에 대한 Put 권한을 추가하지 않습니다.
Lambda가 이 권한을 추가하면 모든 CloudWatch Logs 로그 그룹에 로그를 전송할 수 있는 권한을 함수에 부여합니다.
Lambda가 함수의 실행 역할을 자동으로 업데이트하지 않도록 하고 대신 수동으로 편집하려면 **권한**을 확장하고 **필요한 권한 추가**를 선택 취소합니다.
AWS CLI를 사용하여 함수의 로그 그룹을 구성하면 Lambda는 `logs:PutLogEvents` 권한을 자동으로 추가하지 않습니다. 함수의 실행 역할에 권한을 추가합니다(아직 권한이 없는 경우). 이러한 권한은 [AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole$jsonEditor) 관리형 정책에 포함됩니다.
## Lambda 관리형 인스턴스의 CloudWatch 로깅
[Lambda 관리형 인스턴스](lambda-managed-instances.md)를 사용하는 경우 CloudWatch Logs로 로그를 전송하는 것과 관련된 추가 고려 사항이 있습니다.
### VPC 네트워킹 요구 사항
Lambda 관리형 인스턴스는 VPC 내의 고객 소유 EC2 인스턴스에서 실행됩니다. CloudWatch Logs로 로그를 전송하고 X-Ray로 트레이스를 보내려면 VPC에서 AWS API가 라우팅 가능해야 합니다. 여러 가지 옵션이 있습니다.
+ **AWS PrivateLink(권장)**: [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)를 사용하여 CloudWatch Logs 및 X-Ray 서비스에 대한 VPC 엔드포인트를 생성합니다. 이를 통해 인스턴스는 인터넷 게이트웨이 또는 NAT 게이트웨이 없이 이러한 서비스에 비공개로 액세스할 수 있습니다. 자세한 내용은 [인터페이스 VPC 엔드포인트에서 CloudWatch Logs 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html) 항목을 참조하세요.
+ **NAT 게이트웨이**: 프라이빗 서브넷에서 아웃바운드 인터넷 액세스를 허용하도록 NAT 게이트웨이를 구성합니다.
+ **인터넷 게이트웨이**: 퍼블릭 서브넷의 경우 VPC에 인터넷 게이트웨이가 구성되어야 합니다.
CloudWatch Logs 또는 X-Ray API가 VPC에서 라우팅할 수 없는 경우 함수 로그 및 트레이스가 전달되지 않습니다.
### 동시 간접 호출 및 로그 어트리뷰션
Lambda 관리형 인스턴스 실행 환경은 여러 개의 간접 호출을 동시에 처리할 수 있습니다. 여러 간접 호출이 동시에 실행되면 해당 로그 항목이 동일한 로그 스트림에 인터리브됩니다. 동시 간접 호출에서 로그를 효과적으로 필터링 및 분석하려면 각 로그 항목에 AWS 요청 ID가 포함되어야 합니다.
다음 접근 방식 중 하나를 따르는 것이 좋습니다.
+ **기본 Lambda 런타임 로거 사용(권장)**: Lambda 관리형 런타임에서 제공하는 기본 로깅 라이브러리는 각 로그 항목에 요청 ID를 자동으로 포함합니다.
+ **구조화된 JSON 로깅 구현**: [사용자 지정 런타임](runtimes-custom.md)을 빌드하거나 사용자 지정 로깅이 필요한 경우 각 항목에 요청 ID가 포함된 JSON 형식의 로그를 구현합니다. Lambda 관리형 인스턴스는 JSON 로그 형식만 지원합니다. JSON 로그에 `requestId` 필드를 포함하여 간접 호출별 필터링을 활성화합니다.
```
{
"timestamp": "2025-01-15T10:30:00.000Z",
"level": "INFO",
"requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"message": "Processing request"
}
```
요청 ID 어트리뷰션을 사용하면 CloudWatch Logs Insights 쿼리를 사용하여 특정 간접 호출에 대한 CloudWatch Logs 로그 항목을 필터링할 수 있습니다. 예제:
```
fields @timestamp, @message
| filter requestId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
| sort @timestamp asc
```
Lambda 관리형 인스턴스 로깅 요구 사항에 대한 자세한 내용은 [Lambda 관리형 인스턴스 실행 환경 이해](lambda-managed-instances-execution-environment.md) 항목을 참조하세요.
# Lambda 함수에 대한 CloudWatch 로그 보기
Lambda 콘솔, CloudWatch 콘솔 또는 AWS Command Line Interface(AWS CLI)를 사용하여 Lambda 함수에 대한 Amazon CloudWatch Logs를 볼 수 있습니다. 함수 로그에 액세스하려면 다음 섹션의 지침을 따르세요.
## CloudWatch Logs Live Tail을 사용한 함수 로그 스트리밍
Amazon CloudWatch Logs Live Tail을 사용하면 Lambda 콘솔에 새로운 로그 이벤트의 스트리밍 목록을 직접 표시하여 함수의 문제를 신속하게 해결할 수 있습니다. Lambda 함수에서 수집된 로그를 실시간으로 보고 필터링하여 문제를 신속하게 감지하고 해결할 수 있습니다.
**참고**
Live Tail 세션은 세션 사용 시간(분)별로 비용이 발생합니다. 요금에 대한 자세한 정보는 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing/)을 참조하세요.
### Live Tail과 --log-type Tail 비교
Lambda API(AWS CLI의 `--log-type Tail`)의 CloudWatch Logs Live Tail과 [LogType: Tail](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-LogType) 옵션에는 몇 가지 차이점이 있습니다.
+ `--log-type Tail`은 호출 로그의 처음 4KB만 반환합니다. Live Tail은 이 제한을 공유하지 않으며 초당 최대 500개의 로그 이벤트를 수신할 수 있습니다.
+ `--log-type Tail`은 함수의 응답 지연 시간에 영향을 미칠 수 있는 응답과 함께 로그를 캡처하고 전송합니다. Live Tail은 함수 응답 지연 시간에 영향을 미치지 않습니다.
+ `--log-type Tail`은 동기식 간접 호출만 지원합니다. Live Tail은 동기식 간접 호출과 비동기식 간접 호출 모두에서 작동합니다.
**참고**
[Lambda 관리형 인스턴스](lambda-managed-instances.md)는 `--log-type Tail` 옵션을 지원하지 않습니다. CloudWatch Logs Live Tail을 사용하거나 CloudWatch Logs를 직접 쿼리하여 관리형 인스턴스 함수에 대한 로그를 봅니다.
### 권한
CloudWatch Logs Live Tail 세션을 시작하고 중지하려면 다음 권한이 필요합니다.
+ `logs:DescribeLogGroups`
+ `logs:StartLiveTail`
+ `logs:StopLiveTail`
### Lambda 콘솔에서 Live Tail 세션 시작
1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 함수의 이름을 선택합니다.
1. **테스트** 탭을 선택합니다.
1. **테스트 이벤트** 창에서 **CloudWatch Logs Live Tail**을 선택합니다.
1. **로그 그룹 선택**의 경우 함수의 로그 그룹이 기본적으로 선택됩니다. 한 번에 최대 5개의 로그 그룹을 선택할 수 있습니다.
1. (선택 사항) 특정 단어나 다른 문자열을 포함하는 로그 이벤트만 표시하려면 **필터 패턴 추가**에 단어나 문자열을 입력합니다. 필터 필드는 대소문자를 구분합니다. 이 필드에는 정규 표현식(regex)을 포함하여 여러 개의 항과 패턴 연산자를 포함할 수 있습니다. 패턴 구문에 대한 자세한 내용은 *Amazon CloudWatch Logs 사용 설명서*의 [필터 패턴 구문](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html)을 참조하세요.
1. **시작**을 선택합니다. 일치하는 로그 이벤트가 창에 나타나기 시작합니다.
1. Live Tail 세션을 중지하려면 **중지**를 선택합니다.
**참고**
Live Tail 세션은 15분 동안 활동이 없거나 Lambda 콘솔 세션 시간이 초과되면 자동으로 중지됩니다.
## 콘솔을 사용한 기능 로그 액세스
1. Lambda 콘솔의 [함수 페이지](https://console.aws.amazon.com/lambda/home#/functions)를 엽니다.
1. 함수를 선택합니다.
1. **모니터링** 탭을 선택합니다.
1. **CloudWatch 로그 보기**를 선택하여 CloudWatch 콘솔을 엽니다.
1. 아래로 스크롤하고 확인하고자 하는 함수 간접 호출의 **로그 스트림**을 선택합니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/log-stream.png)
Lambda 함수의 각 인스턴스에는 전용 로그 스트림이 있습니다. 함수가 스케일 업되면 각 동시 인스턴스는 자체 로그 스트림을 보유합니다. 간접 호출에 대한 응답으로 새로운 실행 환경이 생성될 때마다 새 로그 스트림이 생성됩니다. 로그 스트림의 이름 지정 규칙은 다음과 같습니다.
```
YYYY/MM/DD[Function version][Execution environment GUID]
```
단일 실행 환경은 해당 수명 동안 같은 로그 스트림에 씁니다. 로그 스트림에는 해당 실행 환경의 메시지 alc Lambda 함수 코드의 출력도 포함됩니다. 사용자 지정 로그를 포함하여 모든 메시지에는 타임스탬프가 지정됩니다. 함수가 코드에서 출력을 로깅하지 않더라도 간접 호출당 생성된 최소 로그 문은 세 개입니다(START, END 및 REPORT).
![\[모니터링 관찰성 그림 3\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/monitoring-observability-figure-3.png)
이러한 로그에는 다음이 표시됩니다.
+ **RequestId**-요청당 생성된 고유 ID. Lambda 함수가 요청을 재시도하는 경우 이 ID는 변경되지 않으며 후속 재시도마다 로그에 표시됩니다.
+ **Start/End**-단일 간접 호출을 북마크하므로 이 사이의 모든 로그 줄은 동일한 간접 호출에 속합니다.
+ **Duration**-`INIT` 코드를 제외한 핸들러 함수의 총 간접 호출 시간.
+ **Billed Duration**-청구 목적으로 반올림 로직을 적용합니다.
+ **Memory Size**-함수에 할당된 메모리 양.
+ **사용된 최대 메모리** - 간접 호출 중에 사용된 실제 메모리.
+ **Init Duration**-기본 핸들러 외부에서 코드의 `INIT` 섹션을 실행하는 데 걸리는 시간.
## AWS CLI를 사용한 로그 액세스
AWS CLI은(는) 명령줄 셸의 명령을 사용하여 AWS 서비스와 상호 작용할 수 있는 오픈 소스 도구입니다. 이 섹션의 단계를 완료하려면 [AWS CLI 버전 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)가 필요합니다.
[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html)를 사용하면 `--log-type` 명령 옵션을 통해 호출에 대한 로그를 검색할 수 있습니다. 호출에서 base64로 인코딩된 로그를 최대 4KB까지 포함하는 `LogResult` 필드가 응답에 포함됩니다.
**Example 로그 ID 검색**
다음 예제에서는 `LogResult`이라는 함수의 `my-function` 필드에서 *로그 ID*를 검색하는 방법을 보여줍니다.
```
aws lambda invoke --function-name my-function out --log-type Tail
```
다음 결과가 표시됩니다:
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example decode the logs**
동일한 명령 프롬프트에서 `base64` 유틸리티를 사용하여 로그를 디코딩합니다. 다음 예제에서는 `my-function`에 대한 base64로 인코딩된 로그를 검색하는 방법을 보여줍니다.
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
**cli-binary-format** 옵션은 AWS CLI 버전 2를 사용할 때 필요합니다. 이 설정을 기본 설정으로 지정하려면 `aws configure set cli-binary-format raw-in-base64-out`을(를) 실행하세요. 자세한 내용은 *AWS Command Line Interface 사용 설명서 버전 2*에서 [AWS CLI 지원 글로벌 명령줄 옵션](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)을 참조하세요.
다음 결과가 표시됩니다.
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
`base64` 유틸리티는 Linux, macOS 및 [Ubuntu on Windows](https://docs.microsoft.com/en-us/windows/wsl/install-win10)에서 사용할 수 있습니다. macOS 사용자는 `base64 -D`를 사용해야 할 수도 있습니다.
**Example get-logs.sh 스크립트**
동일한 명령 프롬프트에서 다음 스크립트를 사용하여 마지막 5개 로그 이벤트를 다운로드합니다. 이 스크립트는 `sed`를 사용하여 출력 파일에서 따옴표를 제거하고, 로그를 사용할 수 있는 시간을 허용하기 위해 15초 동안 대기합니다. 출력에는 Lambda의 응답과 `get-log-events` 명령의 출력이 포함됩니다.
다음 코드 샘플의 내용을 복사하고 Lambda 프로젝트 디렉터리에 `get-logs.sh`로 저장합니다.
**cli-binary-format** 옵션은 AWS CLI 버전 2를 사용할 때 필요합니다. 이 설정을 기본 설정으로 지정하려면 `aws configure set cli-binary-format raw-in-base64-out`을(를) 실행하세요. 자세한 내용은 *AWS Command Line Interface 사용 설명서 버전 2*에서 [AWS CLI 지원 글로벌 명령줄 옵션](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)을 참조하세요.
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example macOS 및 Linux(전용)**
동일한 명령 프롬프트에서 macOS 및 Linux 사용자는 스크립트가 실행 가능한지 확인하기 위해 다음 명령을 실행해야 할 수 있습니다.
```
chmod -R 755 get-logs.sh
```
**Example 마지막 5개 로그 이벤트 검색**
동일한 명령 프롬프트에서 다음 스크립트를 실행하여 마지막 5개 로그 이벤트를 가져옵니다.
```
./get-logs.sh
```
다음 결과가 표시됩니다.
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## 로그 및 구조화된 로깅 구문 분석
CloudWatch Logs Insights를 사용하면 특수 [쿼리 구문](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)을 사용하여 로그 데이터를 검색 및 분석할 수 있습니다. 여러 로그 그룹에서 쿼리를 수행하고 [glob](https://en.wikipedia.org/wiki/Glob_(programming)) 및 [정규식](https://en.wikipedia.org/wiki/Regular_expression) 패턴 일치를 사용하여 강력한 필터링을 제공합니다.
Lambda 함수에서 구조화된 로깅을 구현하여 이러한 기능을 활용할 수 있습니다. 구조화된 로깅은 로그를 미리 정의된 형식으로 구성하므로 쿼리하기가 더 쉽습니다. 로그 수준을 사용하는 것은 정보 메시지를 경고 또는 오류와 구분하는 필터 친화적 로그를 생성하는 중요한 첫 번째 단계입니다. 예를 들어 다음 Node.js 코드를 생각해 보겠습니다.
```
exports.handler = async (event) => {
console.log("console.log - Application is fine")
console.info("console.info - This is the same as console.log")
console.warn("console.warn - Application provides a warning")
console.error("console.error - An error occurred")
}
```
CloudWatch 로그 파일에는 로그 수준을 지정하는 별도의 필드가 포함되어 있습니다.
![\[모니터링 관찰성 그림 10\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/monitoring-observability-figure-10.png)
그런 다음 CloudWatch Logs Insights 쿼리를 로그 수준에서 필터링할 수 있습니다. 예를 들어 오류만 쿼리하려면 다음 쿼리를 사용할 수 있습니다.
```
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
```
### JSON 정형 로깅
JSON은 일반적으로 애플리케이션 로그에 대한 구조를 제공하는 데 사용됩니다. 다음 예제에서 로그는 JSON으로 변환되어 세 개의 고유한 값을 출력합니다.
![\[모니터링 관찰성 그림 11\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/monitoring-observability-figure-11.png)
CloudWatch Logs Insights 기능은 사용자 지정 glob 또는 정규식 없이도 JSON 출력의 값을 자동으로 검색하고 메시지를 필드로 구문 분석합니다. JSON 정형 로그를 사용하여 다음 쿼리는 업로드된 파일이 1MB보다 크고 업로드 시간이 1초를 초과하며 간접 호출이 콜드 스타트가 아닌 간접 호출을 찾습니다.
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
```
이 쿼리는 다음과 같은 출력을 반환합니다.
![\[모니터링 관찰성 그림 12\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/monitoring-observability-figure-12.png)
JSON에서 검색된 필드는 오른쪽에 있는 *발견된 필드* 메뉴에서 자동으로 채워집니다. Lambda 서비스에서 생성된 표준 필드에는 '@' 접두사가 붙으며 동일한 방식으로 이러한 필드에서 쿼리할 수 있습니다. Lambda 로그에는 항상 @timestamp, @logStream, @message, @requestId, @duration, @billedDuration, @type, @maxMemoryUsed, @memorySize 필드가 포함됩니다. 함수에 대해 X-Ray가 활성화된 경우 로그에는 @xrayTraceId 및 @xraySegmentId도 포함됩니다.
Amazon S3, Amazon SQS 또는 Amazon EventBridge와 같은 AWS 이벤트 소스가 함수를 간접적으로 호출하면 전체 이벤트가 함수에 JSON 객체 입력으로 제공됩니다. 함수의 첫 번째 줄에 로깅함으로써 CloudWatch Logs Insights를 사용하여 중첩된 필드를 쿼리할 수 있습니다.
### 유용한 Insights 쿼리
다음 표에는 Lambda 함수를 모니터링하는 데 유용할 수 있는 Insights 쿼리 예제가 나와 있습니다.
| 설명 | 쿼리 구문 예제 |
| --- | --- |
| 마지막 100개의 오류 |
```
fields Timestamp, LogLevel, Message
\| filter LogLevel == "ERR"
\| sort @timestamp desc
\| limit 100
``` |
| 청구된 상위 100개의 간접 호출 |
```
filter @type = "REPORT"
\| fields @requestId, @billedDuration
\| sort by @billedDuration desc
\| limit 100
``` |
| 총 간접 호출에서 콜드 스타트 비율 |
```
filter @type = "REPORT"
\| stats sum(strcontains(@message, "Init Duration"))/count(*) * 100 as
coldStartPct, avg(@duration)
by bin(5m)
``` |
| Lambda 지속 시간의 백분위수 보고서 |
```
filter @type = "REPORT"
\| stats
avg(@billedDuration) as Average,
percentile(@billedDuration, 99) as NinetyNinth,
percentile(@billedDuration, 95) as NinetyFifth,
percentile(@billedDuration, 90) as Ninetieth
by bin(30m)
``` |
| Lambda 메모리 사용의 백분위수 보고서 |
```
filter @type="REPORT"
\| stats avg(@maxMemoryUsed/1024/1024) as mean_MemoryUsed,
min(@maxMemoryUsed/1024/1024) as min_MemoryUsed,
max(@maxMemoryUsed/1024/1024) as max_MemoryUsed,
percentile(@maxMemoryUsed/1024/1024, 95) as Percentile95
``` |
| 할당된 메모리의 100%를 사용하는 간접 호출 |
```
filter @type = "REPORT" and @maxMemoryUsed=@memorySize
\| stats
count_distinct(@requestId)
by bin(30m)
``` |
| 간접 호출에 사용된 평균 메모리 |
```
avgMemoryUsedPERC,
avg(@billedDuration) as avgDurationMS
by bin(5m)
``` |
| 메모리 통계 시각화 |
```
filter @type = "REPORT"
\| stats
max(@maxMemoryUsed / 1024 / 1024) as maxMemMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemMB,
min(@maxMemoryUsed / 1024 / 1024) as minMemMB,
(avg(@maxMemoryUsed / 1024 / 1024) / max(@memorySize / 1024 / 1024)) * 100 as avgMemUsedPct,
avg(@billedDuration) as avgDurationMS
by bin(30m)
``` |
| Lambda에서 종료한 간접 호출 |
```
filter @message like /Process exited/
\| stats count() by bin(30m)
``` |
| 제한 시간이 초과된 간접 호출 |
```
filter @message like /Task timed out/
\| stats count() by bin(30m)
``` |
| 지연 시간 보고서 |
```
filter @type = "REPORT"
\| stats avg(@duration), max(@duration), min(@duration)
by bin(5m)
``` |
| 과다 프로비저닝된 메모리 |
```
filter @type = "REPORT"
\| stats max(@memorySize / 1024 / 1024) as provisonedMemMB,
min(@maxMemoryUsed / 1024 / 1024) as smallestMemReqMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemUsedMB,
max(@maxMemoryUsed / 1024 / 1024) as maxMemUsedMB,
provisonedMemMB - maxMemUsedMB as overProvisionedMB
``` |
## 로그 시각화 및 대시보드
모든 CloudWatch Logs Insights 쿼리의 경우 결과를 마크다운 또는 CSV 형식으로 내보낼 수 있습니다. 경우에 따라 하나 이상의 집계 함수가 있는 경우 [ 쿼리에서 시각화](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Visualizing-Log-Data.html)를 생성하는 것이 더 유용할 수 있습니다. `stats` 함수를 사용하면 집계 및 그룹화를 정의할 수 있습니다.
이전의 *logInsightsJSON* 예제에서는 업로드 크기 및 업로드 시간을 기준으로 필터링하고 첫 번째 간접 호출을 제외했습니다. 이 경우 데이터 테이블이 생성됩니다. 프로덕션 시스템을 모니터링하는 경우 최소, 최대 및 평균 파일 크기를 시각화하여 이상치를 찾는 것이 더 유용할 수 있습니다. 이를 위해 필요한 집계와 함께 통계 함수를 적용하고 1분마다와 같은 시간 값을 기준으로 그룹화합니다.
예를 들어 다음 쿼리를 생각해 보겠습니다. 이는 [JSON 정형 로깅](#querying-logs-json) 섹션의 동일한 예제 쿼리이지만 추가 집계 함수가 있습니다.
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
| stats min(uploadedBytes), avg(uploadedBytes), max(uploadedBytes) by bin (1m)
```
이상치를 찾기 위해 최소, 최대 및 평균 파일 크기를 시각화하는 것이 더 유용할 수 있으므로 이러한 집계를 포함했습니다. **시각화** 탭에서 결과를 볼 수 있습니다.
![\[모니터링 관찰성 그림 14\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/monitoring-observability-figure-14.png)
시각화 빌드를 완료한 후 선택적으로 CloudWatch 대시보드에 그래프를 추가할 수 있습니다. 이를 위해 시각화 위에서 **대시보드에 추가**를 선택합니다. 그러면 쿼리가 위젯으로 추가되고 자동 새로 고침 간격을 선택하여 결과를 지속적으로 더 쉽게 모니터링할 수 있습니다.
![\[모니터링 관찰성 그림 15\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/monitoring-observability-figure-15.png)
# Firehose로 Lambda 함수 로그 전송
이제 Lambda 콘솔에서 Firehose로 함수 로그를 전송하는 옵션을 제공합니다. 이를 통해 타사 분석 도구 및 사용자 지정 엔드포인트를 포함하여 Firehose에서 지원하는 다양한 대상으로 로그를 실시간으로 스트리밍할 수 있습니다.
**참고**
Lambda 콘솔, AWS CLI, AWS CloudFormation 및 모든 AWS SDK를 사용하여 Firehose로 Lambda 함수 로그가 전송되도록 구성할 수 있습니다.
## 요금
요금에 대한 자세한 내용은 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs)을 참조하세요.
## Firehose 로그 대상에 필요한 권한
Lambda 콘솔을 사용하여 Firehose를 함수의 로그 대상으로 구성할 때 다음이 필요합니다.
1. Lambda에서 CloudWatch Logs를 사용하는 데 [필요한 IAM 권한](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs)
1. [Firehose를 사용하여 구독 필터 설정](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#FirehoseExample) 이 필터는 Firehose 스트림으로 전송되는 로그 이벤트를 정의합니다.
## Firehose로 Lambda 함수 로그 전송
Lambda 콘솔에서 새 함수를 생성한 후 Firehose로 직접 함수 로그를 전송할 수 있습니다. 이렇게 하려면 다음 단계를 완료하세요.
1. AWS Management Console에 로그인하고 Lambda 콘솔을 엽니다.
1. 함수 이름을 선택합니다.
1. **구성** 탭을 선택합니다.
1. **모니터링 및 운영 도구** 탭을 선택합니다.
1. ‘로깅 구성’ 섹션에서 **편집**을 선택합니다.
1. ‘로그 콘텐츠’ 섹션에서 로그 형식을 선택합니다.
1. ‘로그 대상’ 섹션에서 다음 단계를 완료합니다.
1. 대상 서비스를 선택합니다.
1. **새 로그 그룹 생성**을 선택하거나 **기존 로그 그룹**을 사용합니다.
**참고**
Firehose 대상에 대한 기존 로그 그룹을 선택하는 경우 해당 로그 그룹이 `Delivery` 로그 그룹 유형인지 확인합니다.
1. Firehose 스트림을 선택합니다.
1. CloudWatch `Delivery` 로그 그룹이 나타납니다.
1. **저장**을 선택합니다.
**참고**
콘솔에 제공된 IAM 역할에 필요한 권한이 없으면 대상 설정이 실패합니다. 이를 해결하려면 Firehose 로그 대상에 필요한 권한을 참조하여 필요한 권한을 제공합니다.
## 교차 계정 로깅
다른 AWS 계정의 Firehose 전송 스트림으로 로그를 전송하도록 Lambda를 구성할 수 있습니다. 이렇게 하려면 대상을 설정하고 두 계정 모두에서 적절한 권한을 구성해야 합니다.
필요한 IAM 역할과 정책을 포함하여 교차 계정 로깅을 설정하는 방법에 대한 자세한 지침은 CloudWatch Logs 설명서의 [Setting up a new cross-account subscription](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html)을 참조하세요.
# Amazon S3로 Lambda 함수 로그 전송
Lambda 콘솔을 사용하여 Amazon S3로 직접 로그를 전송하도록 Lambda 함수를 구성할 수 있습니다. 이 기능은 장기 로그 스토리지를 위한 비용 효과적인 솔루션을 제공하며 Athena와 같은 서비스를 사용하여 강력한 분석 옵션을 활성화합니다.
**참고**
Lambda 콘솔, AWS CLI, AWS CloudFormation 및 모든 AWS SDK를 사용하여 Amazon S3로 Lambda 함수 로그가 전송되도록 구성할 수 있습니다.
## 요금
요금에 대한 자세한 내용은 [Amazon CloudWatch 요금](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs)을 참조하세요.
## Amazon S3 로그 대상에 필요한 권한
Lambda 콘솔을 사용하여 Amazon S3를 함수의 로그 대상으로 구성할 때 다음이 필요합니다.
1. Lambda에서 CloudWatch Logs를 사용하는 데 [필요한 IAM 권한](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs)
1. [Amazon S3로 Lambda 함수 로그를 전송하도록 CloudWatch Logs 구독 필터 설정](#using-cwl-subscription-filter-lambda-s3)을 수행합니다. 이 필터는 Amazon S3 버킷으로 전송되는 로그 이벤트를 정의합니다.
## Amazon S3로 Lambda 함수 로그를 전송하도록 CloudWatch Logs 구독 필터 설정
CloudWatch Logs에서 Amazon S3로 로그를 전송하려면 구독 필터를 생성해야 합니다. 이 필터는 Amazon S3 버킷으로 전송되는 로그 이벤트를 정의합니다. Amazon S3 버킷은 로그 그룹과 동일한 리전에 있어야 합니다.
### Amazon S3에 대한 구독 필터를 생성하려면 다음을 수행하세요.
1. Amazon Simple Storage Service(Amazon S3) 버킷을 생성합니다. CloudWatch Logs를 위해 특별히 생성한 버킷을 사용하는 것이 좋습니다. 그러나 기존 버킷을 사용하고 싶으면 2단계로 건너뛸 수 있습니다.
다음 명령을 실행하여 자리 표시자 리전을 사용하고자 하는 리전으로 바꿉니다.
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
**참고**
`amzn-s3-demo-bucket2`는 예시 Amazon S3 버킷 이름입니다. *예약*되어 있습니다. 이 절차를 수행하려면 고유한 Amazon S3 버킷 이름으로 바꿔야 합니다.
다음은 예 출력입니다.
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Amazon S3 버킷에 데이터를 입력하는 데 필요한 권한을 CloudWatch Logs에 부여하는 IAM 역할을 생성합니다. 이 정책에는 혼동된 대리자 보안 문제를 방지하는 데 도움이 되는 aws:SourceArn 글로벌 조건 컨텍스트 키가 포함되어 있습니다. 자세한 내용은 [혼동된 대리자 방지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions-confused-deputy.html)를 참조하세요.
1. 텍스트 편집기를 사용하여 신뢰 정책을 다음과 같은 `~/TrustPolicyForCWL.json` 파일로 생성합니다.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
},
"Action": "sts:AssumeRole"
}
}
```
1. create-role 명령을 사용하여 신뢰 정책 파일을 지정하는 IAM 역할을 생성합니다. 이후 단계에서 필요할 수 있기 때문에 반환된 Role.Arn 값을 적어둡니다.
```
aws iam create-role \
--role-name CWLtoS3Role \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoS3Role"
}
}
```
1. CloudWatch Logs가 계정에서 수행할 수 있는 작업을 정의하는 권한 정책을 생성합니다. 먼저 텍스트 편집기를 사용하여 권한 정책을 `~/PermissionsForCWL.json` 파일로 생성합니다.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket2/*"]
}
]
}
```
다음 `put-role-policy` 명령을 사용하여 권한 정책을 역할에 연결합니다.
```
aws iam put-role-policy --role-name CWLtoS3Role --policy-name Permissions-Policy-For-S3 --policy-document file://~/PermissionsForCWL.json
```
1. `Delivery` 로그 그룹을 생성하거나 기존 `Delivery` 로그 그룹을 사용합니다.
```
aws logs create-log-group --log-group-name my-logs --log-group-class DELIVERY --region REGION_NAME
```
1. `PutSubscriptionFilter`를 사용하여 대상을 설정합니다.
```
aws logs put-subscription-filter
--log-group-name my-logs
--filter-name my-lambda-delivery
--filter-pattern ""
--destination-arn arn:aws:s3:::amzn-s3-demo-bucket2
--role-arn arn:aws:iam::123456789012:role/CWLtoS3Role
--region REGION_NAME
```
## Amazon S3로 Lambda 함수 로그 전송
Lambda 콘솔에서 새 함수를 생성한 후 Amazon S3로 직접 함수 로그를 전송할 수 있습니다. 이렇게 하려면 다음 단계를 완료하세요.
1. AWS Management Console에 로그인하고 Lambda 콘솔을 엽니다.
1. 함수 이름을 선택합니다.
1. **구성** 탭을 선택합니다.
1. **모니터링 및 운영 도구** 탭을 선택합니다.
1. ‘로깅 구성’ 섹션에서 **편집**을 선택합니다.
1. ‘로그 콘텐츠’ 섹션에서 로그 형식을 선택합니다.
1. ‘로그 대상’ 섹션에서 다음 단계를 완료합니다.
1. 대상 서비스를 선택합니다.
1. **새 로그 그룹 생성**을 선택하거나 **기존 로그 그룹**을 사용합니다.
**참고**
Amazon S3 대상에 대한 기존 로그 그룹을 선택하는 경우 해당 로그 그룹이 `Delivery` 로그 그룹 유형인지 확인합니다.
1. 함수 로그의 대상으로 Amazon S3 버킷을 선택합니다.
1. CloudWatch `Delivery` 로그 그룹이 나타납니다.
1. **저장**을 선택합니다.
**참고**
콘솔에 제공된 IAM 역할에 필요한 권한이 없으면 대상 설정이 실패합니다. 이 문제를 해결하려면 [Amazon S3 로그 대상에 필요한 권한](#logging-s3-permissions)을 참조하세요.
## 교차 계정 로깅
다른 AWS 계정의 Amazon S3 버킷으로 로그를 전송하도록 Lambda를 구성할 수 있습니다. 이렇게 하려면 대상을 설정하고 두 계정 모두에서 적절한 권한을 구성해야 합니다.
필요한 IAM 역할과 정책을 포함하여 교차 계정 로깅을 설정하는 방법에 대한 자세한 지침은 CloudWatch Logs 설명서의 [Setting up a new cross-account subscription](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html)을 참조하세요.