C# Lambda 함수 로그 및 모니터링

C# Lambda 함수 로그 및 모니터링 (Log and monitor C# Lambda functions)

AWS Lambda는 Lambda 함수를 자동으로 모니터링하고 로그 항목을 Amazon CloudWatch로 보냅니다. Lambda 함수에는 함수의 각 인스턴스에 대한 CloudWatch Logs 로그 그룹과 로그 스트림이 있습니다. Lambda 런타임 환경은 각 호출에 대한 세부 정보와 함수의 코드에서 나온 기타 출력을 로그 스트림으로 보냅니다. CloudWatch Logs에 대한 자세한 내용은 Lambda 함수 로그를 CloudWatch Logs로 보내기를 참조하세요.

출처: AWS Lambda 개발자 안내서

본문

로그를 반환하는 함수 만들기

함수 코드에서 로그를 출력하려면 컨텍스트 객체의 ILambdaLogger, Console 클래스의 메서드, 또는 stdout이나 stderr에 쓰는 로깅 라이브러리를 사용할 수 있습니다.

.NET 런타임은 각 호출에 대해 START, END, REPORT 줄을 기록합니다. REPORT 줄은 다음 세부 정보를 제공합니다.

REPORT 줄 데이터 필드:

RequestId — 호출의 고유 요청 ID입니다.
Duration — 함수의 핸들러 메서드가 이벤트를 처리하는 데 보낸 시간입니다.
Billed Duration — 호출에 청구된 시간입니다.
Memory Size — 함수에 할당된 메모리 양입니다.
Max Memory Used — 함수가 사용한 메모리 양입니다. 호출이 실행 환경을 공유하면 Lambda는 모든 호출에서 사용된 최대 메모리를 보고합니다. 이 동작으로 인해 보고된 값이 예상보다 높을 수 있습니다.
Init Duration — 제공된 첫 번째 요청에 대해 런타임이 함수를 로드하고 핸들러 메서드 밖의 코드를 실행하는 데 걸린 시간입니다.
XRAY TraceId — 추적된 요청의 AWS X-Ray 추적 ID입니다.
SegmentId — 추적된 요청의 X-Ray 세그먼트 ID입니다.
Sampled — 추적된 요청의 샘플링 결과입니다.

.NET에서 Lambda 고급 로깅 제어 사용

함수 로그가 캡처, 처리, 소비되는 방식을 더 잘 제어하기 위해 지원되는 .NET 런타임에 대해 다음 로깅 옵션을 구성할 수 있습니다:

로그 형식 — 함수 로그에 대해 일반 텍스트와 구조화된 JSON 형식 중에서 선택합니다.
로그 수준 — JSON 형식 로그의 경우 Lambda가 CloudWatch로 보내는 로그의 상세 수준(예: ERROR, DEBUG, INFO)을 선택합니다.
로그 그룹 — 함수가 로그를 보낼 CloudWatch 로그 그룹을 선택합니다.

이러한 로깅 옵션과 함수에서 사용하도록 구성하는 방법에 대한 자세한 내용은 Lambda 함수에 대한 고급 로깅 제어 구성을 참조하세요.

로그 형식과 로그 수준 옵션을 .NET Lambda 함수에서 사용하려면 다음 섹션의 지침을 참조하세요.

.NET에서 구조화된 JSON 로그 형식 사용

함수의 로그 형식으로 JSON을 선택하면 Lambda는 ILambdaLogger로 출력된 로그를 구조화된 JSON으로 보냅니다. 각 JSON 로그 객체에는 다음 키가 있는 최소 5개의 키-값 쌍이 포함됩니다:

"timestamp" — 로그 메시지가 생성된 시간
"level" — 메시지에 할당된 로그 수준
"requestId" — 함수 호출의 고유 요청 ID
"traceId" — _X_AMZN_TRACE_ID 환경 변수
"message" — 로그 메시지 내용

ILambdaLogger 인스턴스는 예외를 기록할 때처럼 추가 키-값 쌍을 추가할 수 있습니다. 고객 제공 로그 파라미터 섹션에 설명된 대로 자체 추가 파라미터를 제공할 수도 있습니다.

참고

코드가 이미 다른 로깅 라이브러리를 사용해 JSON 형식 로그를 생성한다면 함수의 로그 형식이 일반 텍스트로 설정되어 있는지 확인하세요. 로그 형식을 JSON으로 설정하면 로그 출력이 이중 인코딩됩니다.

다음 예제 로깅 명령은 INFO 수준으로 로그 메시지를 쓰는 방법을 보여줍니다.

.NET 로깅 코드 예시:

context.Logger.LogInformation("Fetching cart from database");

다음 예제처럼 로그 수준을 인수로 사용하는 일반 로그 메서드도 사용할 수 있습니다.

context.Logger.Log(LogLevel.Information, "Fetching cart from database");

이 예제 코드 조각이 출력하는 로그는 CloudWatch Logs에 다음과 같이 캡처됩니다.

JSON 로그 레코드 예시:

{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "Fetching cart from database"
}

참고

함수의 로그 형식을 JSON이 아닌 일반 텍스트로 구성하면 메시지에 캡처된 로그 수준은 네 글자 라벨을 사용하는 Microsoft 규칙을 따릅니다. 예를 들어 Debug 로그 수준은 메시지에서 dbug로 표시됩니다.

함수를 JSON 형식 로그를 사용하도록 구성하면 로그에 캡처된 로그 수준은 위 JSON 로그 레코드 예시와 같이 전체 라벨을 사용합니다.

로그 출력에 수준을 할당하지 않으면 Lambda는 자동으로 INFO 수준을 할당합니다.

JSON에서 예외 로깅

ILambdaLogger로 구조화된 JSON 로깅을 사용할 때 다음 예제와 같이 코드에서 예외를 기록할 수 있습니다.

예외 로깅 사용 예시:

try
{
    connection.ExecuteQuery(query);
}
catch(Exception e)
{
    context.Logger.LogWarning(e, "Error executing query");
}

이 코드가 출력하는 로그 형식은 다음 예제 JSON과 같습니다. JSON의 message 속성은 LogWarning 호출에 제공된 message 인수로 채워지고, errorMessage 속성은 예외 자체의 Message 속성에서 나옵니다.

JSON 로그 레코드 예시:

{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Warning",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "Error executing query",
    "errorType": "System.Data.SqlClient.SqlException",
    "errorMessage": "Connection closed",
    "stackTrace": [""]
}

함수의 로깅 형식이 JSON으로 설정되면 코드가 처리되지 않은 예외(uncaught exception)를 던질 때 Lambda도 JSON 형식의 로그 메시지를 출력합니다. 다음 예제 코드 조각과 로그 메시지는 처리되지 않은 예외가 어떻게 기록되는지 보여줍니다.

예외 코드 예시:

throw new ApplicationException("Invalid data");

JSON 로그 레코드 예시:

{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Error",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "Invalid data",
    "errorType": "System.ApplicationException",
    "errorMessage": "Invalid data",
    "stackTrace": [""]
}

고객 제공 로그 파라미터

JSON 형식 로그 메시지에서는 추가 로그 파라미터를 제공하고 이를 로그 message에 포함할 수 있습니다. 다음 코드 조각 예시는 retryAttempt와 uri라는 레이블이 붙은 두 개의 사용자 제공 파라미터를 추가하는 명령을 보여줍니다. 예제에서 이 파라미터의 값은 로깅 명령에 전달된 retryAttempt 및 uriDestination 인수에서 나옵니다.

추가 파라미터가 있는 JSON 로깅 명령 예시:

context.Logger.LogInformation("Starting retry {retryAttempt} to make GET request to {uri}", retryAttempt, uriDestination);

이 명령이 출력하는 로그 메시지는 다음 예제 JSON과 같습니다.

JSON 로그 레코드 예시:

{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "Starting retry 1 to make GET request to http://example.com/",
    "retryAttempt": 1,
    "uri": "http://example.com/"
}

팁

추가 파라미터 지정 시 이름 대신 위치 속성(positional property)을 사용할 수도 있습니다. 예를 들어 이전 예제의 로깅 명령은 다음과 같이 쓸 수도 있습니다:

context.Logger.LogInformation("Starting retry {0} to make GET request to {1}", retryAttempt, uriDestination);

추가 로깅 파라미터를 제공하면 Lambda는 이를 JSON 로그 레코드의 최상위 속성으로 캡처합니다. 이 접근 방식은 Serilog 같은 인기 있는 .NET 로깅 라이브러리(추가 파라미터를 별도의 자식 객체에 캡처)와 다릅니다.

추가 파라미터에 제공하는 인수가 복잡한 객체라면 기본적으로 Lambda는 ToString() 메서드를 사용해 값을 제공합니다. 인수를 JSON 직렬화해야 함을 나타내려면 다음 코드 조각처럼 @ 접두사를 사용하세요. 이 예제에서 User는 FirstName과 LastName 속성을 가진 객체입니다.

JSON 직렬화 객체가 있는 JSON 로깅 명령 예시:

context.Logger.LogInformation("User {@user} logged in", User);

이 명령이 출력하는 로그 메시지는 다음 예제 JSON과 같습니다.

JSON 로그 레코드 예시:

{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "User {@user} logged in",
    "user":
    {
        "FirstName": "John",
        "LastName": "Doe"
    }
}

추가 파라미터의 인수가 배열이거나 IList 또는 IDictionary를 구현하면 Lambda는 다음 예제 JSON 로그 레코드와 같이 인수를 JSON 로그 메시지에 배열로 추가합니다. 이 예제에서 {users}는 이전 예제와 같은 형식의 User 속성 인스턴스를 포함하는 IList 인수를 받습니다. Lambda는 이 IList를 배열로 변환하며 각 값은 ToString 메서드로 생성됩니다.

IList 인수가 있는 JSON 로그 레코드 예시:

{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "{users} have joined the group",
    "users":
    [
        "Rosalez, Alejandro",
        "Stiles, John"
    ]
}

로깅 명령에서 @ 접두사를 사용해 목록을 JSON 직렬화할 수도 있습니다. 다음 예제 JSON 로그 레코드에서 users 속성은 JSON 직렬화됩니다.

JSON 직렬화 IList 인수가 있는 JSON 로그 레코드 예시:

{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "{@users} have joined the group",
    "users":
    [
        {
            "FirstName": "Alejandro",
            "LastName": "Rosalez"
        },
        {
            "FirstName": "John",
            "LastName": "Stiles"
        }
    ]
}

.NET에서 로그 수준 필터링 사용

로그 수준 필터링을 구성하면 일정 상세 수준 이하의 로그만 CloudWatch Logs로 보내도록 선택할 수 있습니다. 함수에 대한 로그 수준 필터링 구성 방법을 알아보려면 로그 수준 필터링을 참조하세요.

AWS Lambda가 로그 메시지를 로그 수준별로 필터링하게 하려면 JSON 형식 로그를 사용하거나 .NET Console 메서드를 사용해 로그 메시지를 출력할 수 있습니다. JSON 형식 로그를 만들려면 함수의 로그 유형을 JSON으로 구성하고 ILambdaLogger 인스턴스를 사용하세요.

JSON 형식 로그를 사용하면 Lambda는 .NET에서 구조화된 JSON 로그 형식 사용에 설명된 JSON 객체의 "level" 키-값 쌍으로 로그 출력을 필터링합니다.

.NET Console 메서드를 사용해 CloudWatch Logs에 메시지를 쓰면 Lambda는 메시지에 다음과 같이 로그 수준을 적용합니다:

Console.WriteLine 메서드 — Lambda는 INFO 로그 수준을 적용합니다.
Console.Error 메서드 — Lambda는 ERROR 로그 수준을 적용합니다.

함수를 로그 수준 필터링을 사용하도록 구성할 때 Lambda가 CloudWatch Logs로 보내려는 로그 수준에 대해 다음 옵션 중에서 선택해야 합니다. Lambda가 사용하는 로그 수준과 .NET ILambdaLogger가 사용하는 표준 Microsoft 수준의 매핑에 유의하세요.

Lambda 로그 수준	해당 Microsoft 수준	표준 용도
TRACE (가장 상세)	Trace	코드 실행 경로를 추적하는 데 사용되는 가장 세분화된 정보
DEBUG	Debug	시스템 디버깅을 위한 상세 정보
INFO	Information	함수의 정상 작동을 기록하는 메시지
WARN	Warning	해결하지 않으면 예기치 않은 동작으로 이어질 수 있는 잠재적 오류에 대한 메시지
ERROR	Error	코드가 예상대로 수행되지 못하게 하는 문제에 대한 메시지
FATAL (가장 덜 상세)	Critical	애플리케이션이 작동을 멈추게 하는 심각한 오류에 대한 메시지

Lambda는 선택한 상세 수준 이하의 로그를 CloudWatch로 보냅니다. 예를 들어 로그 수준을 WARN으로 구성하면 Lambda는 WARN, ERROR, FATAL 수준에 해당하는 로그를 보냅니다.

추가 로깅 도구 및 라이브러리

Powertools for AWS Lambda (.NET)는 Serverless 모범 사례를 구현하고 개발자 생산성을 높이는 개발자 툴킷입니다. Logging 유틸리티는 모든 함수에 걸쳐 함수 컨텍스트에 대한 추가 정보를 포함하고 JSON으로 구조화된 출력을 제공하는 Lambda 최적화 로거를 제공합니다. 이 유틸리티로 다음을 수행할 수 있습니다:

Lambda 컨텍스트에서 주요 필드를 캡처하고, 콜드 스타트를 캡처하며 로깅 출력을 JSON으로 구조화합니다.
지시된 경우 Lambda 호출 이벤트를 기록합니다(기본적으로 비활성화).
로그 샘플링으로 호출의 일정 비율에 대해서만 모든 로그를 출력합니다(기본적으로 비활성화).
언제든지 구조화된 로그에 추가 키를 추가합니다.
조직의 Logging RFC와 호환되는 구조로 로그를 출력하는 사용자 지정 로그 포맷터(BYOF)를 사용합니다.

Powertools for AWS Lambda (.NET) 및 AWS SAM으로 구조화된 로깅 사용

다음 단계에 따라 AWS SAM으로 통합된 Powertools for AWS Lambda (.NET) 모듈이 있는 Hello World C# 샘플 애플리케이션을 다운로드, 빌드, 배포합니다. 이 애플리케이션은 기본 API 백엔드를 구현하고 로그, 메트릭, 추적을 내보내는 데 Powertools를 사용합니다. Amazon API Gateway 엔드포인트와 Lambda 함수로 구성됩니다. API Gateway 엔드포인트에 GET 요청을 보내면 Lambda 함수가 호출되어 Embedded Metric Format으로 CloudWatch에 로그와 메트릭을 보내고 AWS X-Ray로 추적을 보냅니다. 함수는 hello world 메시지를 반환합니다.

사전 조건:

이 섹션의 단계를 완료하려면 다음이 있어야 합니다:

.NET 8
AWS CLI 버전 2
AWS SAM CLI 버전 1.75 이상. 더 오래된 버전의 AWS SAM CLI가 있으면 AWS SAM CLI 업그레이드를 참조하세요.

샘플 AWS SAM 애플리케이션 배포:

Hello World TypeScript 템플릿으로 애플리케이션을 초기화합니다.

sam init --app-template hello-world-powertools-dotnet --name sam-app --package-type Zip --runtime dotnet6 --no-tracing

앱을 빌드합니다.

cd sam-app && sam build

앱을 배포합니다.

sam deploy --guided

화면 프롬프트를 따릅니다. 대화형 환경에서 제공된 기본 옵션을 수락하려면 Enter를 누르세요.

참고

"HelloWorldFunction may not have authorization defined. Is this okay?"에서는 y를 입력해야 합니다.

배포된 애플리케이션의 URL을 가져옵니다:

aws cloudformation describe-stacks --stack-name sam-app --query 'Stacks[0].Outputs[?OutputKey==`HelloWorldApi`].OutputValue' --output text

API 엔드포인트를 호출합니다:

curl -X GET <URL>

성공하면 다음 응답이 표시됩니다:

{"message":"hello world"}

함수 로그를 얻으려면 sam logs를 실행합니다. 자세한 내용은 AWS Serverless Application Model 개발자 안내서의 로그 작업을 참조하세요.

sam logs --stack-name sam-app

로그 출력은 다음과 같습니다:

2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:27.988000 INIT_START Runtime Version: dotnet:6.v13        Runtime Version ARN: arn:aws:lambda:ap-southeast-2::runtime:699f346a05dae24c58c45790bc4089f252bf17dae3997e79b17d939a288aa1ec
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:28.229000 START RequestId: bed25b38-d012-42e7-ba28-f272535fb80e Version: $LATEST
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:29.259000 2025-09-20T14:15:29.201Z        bed25b38-d012-42e7-ba28-f272535fb80e    info   {"_aws":{"Timestamp":1676902528962,"CloudWatchMetrics":[{"Namespace":"sam-app-logging","Metrics":[{"Name":"ColdStart","Unit":"Count"}],"Dimensions":[["FunctionName"],["Service"]]}]},"FunctionName":"sam-app-HelloWorldFunction-haKIoVeose2p","Service":"PowertoolsHelloWorld","ColdStart":1}
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.479000 2025-09-20T14:15:30.479Z        bed25b38-d012-42e7-ba28-f272535fb80e    info   {"ColdStart":true,"XrayTraceId":"1-63f3807f-5dbcb9910c96f50742707542","CorrelationId":"d3d4de7f-4ccc-411a-a549-4d67b2fdc015","FunctionName":"sam-app-HelloWorldFunction-haKIoVeose2p","FunctionVersion":"$LATEST","FunctionMemorySize":256,"FunctionArn":"arn:aws:lambda:ap-southeast-2:123456789012:function:sam-app-HelloWorldFunction-haKIoVeose2p","FunctionRequestId":"bed25b38-d012-42e7-ba28-f272535fb80e","Timestamp":"2025-09-20T14:15:30.4602970Z","Level":"Information","Service":"PowertoolsHelloWorld","Name":"AWS.Lambda.Powertools.Logging.Logger","Message":"Hello world API - HTTP 200"}
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.599000 2025-09-20T14:15:30.599Z        bed25b38-d012-42e7-ba28-f272535fb80e    info   {"_aws":{"Timestamp":1676902528922,"CloudWatchMetrics":[{"Namespace":"sam-app-logging","Metrics":[{"Name":"ApiRequestCount","Unit":"Count"}],"Dimensions":[["Service"]]}]},"Service":"PowertoolsHelloWorld","ApiRequestCount":1}
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.680000 END RequestId: bed25b38-d012-42e7-ba28-f272535fb80e
2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.680000 REPORT RequestId: bed25b38-d012-42e7-ba28-f272535fb80e  Duration: 2450.99 ms   Billed Duration: 2692 ms Memory Size: 256 MB     Max Memory Used: 74 MB  Init Duration: 240.05 ms
XRAY TraceId: 1-63f3807f-5dbcb9910c96f50742707542       SegmentId: 16b362cd5f52cba0

이것은 인터넷을 통해 액세스할 수 있는 공개 API 엔드포인트입니다. 테스트 후 엔드포인트를 삭제할 것을 권장합니다.

sam delete

로그 보존 관리

함수를 삭제해도 로그 그룹은 자동으로 삭제되지 않습니다. 로그를 무기한 저장하지 않으려면 로그 그룹을 삭제하거나 CloudWatch가 로그를 자동으로 삭제하는 보존 기간을 구성하세요. 로그 보존을 설정하려면 AWS SAM 템플릿에 다음을 추가합니다:

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      # Omitting other properties

  LogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub "/aws/lambda/${HelloWorldFunction}"
      RetentionInDays: 7

Lambda 콘솔에서 로그 보기

Lambda 함수를 호출한 후 Lambda 콘솔을 사용해 로그 출력을 볼 수 있습니다.

내장 Code 편집기에서 코드를 테스트할 수 있다면 실행 결과에서 로그를 찾습니다. 콘솔 테스트 기능으로 함수를 호출하면 Details(세부 정보) 섹션에서 Log output(로그 출력) 을 찾습니다.

CloudWatch 콘솔에서 로그 보기

Amazon CloudWatch 콘솔을 사용해 모든 Lambda 함수 호출의 로그를 볼 수 있습니다.

CloudWatch 콘솔에서 로그를 보려면:

CloudWatch 콘솔에서 Log groups(로그 그룹) 페이지를 엽니다.
함수의 로그 그룹(/aws/lambda/your-function-name)을 선택합니다.
로그 스트림을 선택합니다.

각 로그 스트림은 함수의 인스턴스에 해당합니다. Lambda 함수를 업데이트할 때와 동시 호출을 처리하기 위해 추가 인스턴스가 생성될 때 로그 스트림이 나타납니다. 특정 호출의 로그를 찾으려면 AWS X-Ray로 함수를 계측할 것을 권장합니다. X-Ray는 추적에서 요청과 로그 스트림에 대한 세부 정보를 기록합니다.

AWS CLI로 로그 보기

AWS CLI는 명령줄 셸에서 명령을 사용해 AWS 서비스를 상호작용할 수 있는 오픈 소스 도구입니다. 이 섹션의 단계를 완료하려면 AWS CLI 버전 2가 있어야 합니다.

AWS CLI를 사용해 --log-type 명령 옵션으로 호출에 대한 로그를 검색할 수 있습니다. 응답에는 호출에서 최대 4KB의 base64 인코딩 로그가 포함된 LogResult 필드가 있습니다.

로그 ID 검색 예시:

다음 예제는 my-function이라는 함수의 LogResult 필드에서 로그 ID를 검색하는 방법을 보여줍니다.

aws lambda invoke --function-name my-function out --log-type Tail

다음과 같은 출력이 표시되어야 합니다:

{
    "StatusCode": 200,
    "LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
    "ExecutedVersion": "$LATEST"
}

로그 디코딩 예시:

같은 명령 프롬프트에서 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

AWS CLI 버전 2를 사용하는 경우 cli-binary-format 옵션이 필요합니다. 기본 설정으로 만들려면 aws configure set cli-binary-format raw-in-base64-out을 실행하세요. 자세한 내용은 AWS Command Line Interface User Guide for Version 2의 AWS CLI 지원 글로벌 명령줄 옵션을 참조하세요.

다음과 같은 출력이 표시되어야 합니다:

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, Windows의 Ubuntu에서 사용할 수 있습니다. macOS 사용자는 base64 -D를 사용해야 할 수 있습니다.

get-logs.sh 스크립트 예시:

같은 명령 프롬프트에서 다음 스크립트를 사용해 마지막 5개 로그 이벤트를 다운로드합니다. 스크립트는 sed를 사용해 출력 파일에서 따옴표를 제거하고, 로그를 사용할 수 있게 될 시간을 주기 위해 15초간 대기합니다. 출력에는 Lambda의 응답과 get-log-events 명령의 출력이 포함됩니다.

다음 코드 샘플 내용을 복사해 Lambda 프로젝트 디렉터리에 get-logs.sh로 저장합니다.

#!/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

macOS 및 Linux (전용):

같은 명령 프롬프트에서 macOS와 Linux 사용자는 스크립트가 실행 가능한지 확인하기 위해 다음 명령을 실행해야 할 수 있습니다.

chmod -R 755 get-logs.sh

마지막 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"
}

로그 삭제

함수를 삭제해도 로그 그룹은 자동으로 삭제되지 않습니다. 로그를 무기한 저장하지 않으려면 로그 그룹을 삭제하거나 로그가 자동으로 삭제되는 보존 기간을 구성하세요.

더 알아보기 (Learn more)

Lambda 고급 로깅 제어
C# Lambda 함수
CloudWatch Logs 모니터링