먼저 Datadog 서버리스 모니터링을 설치하여 메트릭, 트레이스 및 로그 수집을 시작합니다. 설치가 완료되면 다음 항목을 참조하여 모니터링 요구 사항에 맞도록 설치 옵션을 설정합니다.

• 태그를 사용하여 텔레메트리 연결
• 요청 및 응답 페이로드 수집
• 논람다 리소스에서 트레이스 수집
• Datadog 트레이서 구성
• APM 스팬 수집용 샘플 속도 선택
• 트레이스에서 민감한 정보 필터링 또는 스크러빙
• 트레이스 수집 활성화/비활성화
• 로그와 트레이스 연결
• 오류를 소스 코드에 연결
• 커스텀 메트릭 제출
• 프로파일링 데이터 수집 (퍼블릭 베타)
• PrivateLink나 프록시를 통해 텔레메트리 전송
• 다중 Datadog 조직에 텔레메트리 전송
• AWS 리소스를 통한 트레이스 컨텍스트 전파
• X-Ray 및 Datadog 트레이스 병합
• AWS Lambda 코드 서명 활성화
• Datadog Lambda 확장으로 마이그레이션
• Datadog Lambda 확장을 사용하여 x86에서 arm64로 마이그레이션
• 로컬 테스트용 Datadog Lambda 확장 구성
• OpenTelemetry API로 AWS Lambda 계측
• 문제 해결
• 더 알아보기

위협 탐지를 활성화하여 공격 시도를 주시하세요

서버리스 애플리케이션을 공격하려는 시도에 대한 알림을 받고 신속하게 대응하세요.

시작하려면 먼저 함수가 추적 활성화되어 있는지 확인하세요.

위협 모니터링을 사용하려면 다음 환경 변수를 배포에 추가하세요.

environment:
  DD_SERVERLESS_APPSEC_ENABLED: true
  AWS_LAMBDA_EXEC_WRAPPER: /opt/datadog_wrapper

함수를 다시 배포하고 호출합니다. 몇 분 후에 ASM 보기에 표시됩니다.

애플리케이션 보안 관리 위협 탐지 기능이 실제로 작동하는지 확인하려면 알려진 공격 패턴을 애플리케이션에 전송하세요. 예를 들어, 보안 스캐너 공격 시도를 트리거하려면 다음과 같은 acunetix-product 값이 포함된 HTTP 헤더를 전송합니다:

curl -H 'My-ASM-Test-Header: acunetix-product' https://<YOUR_FUNCTION_URL>/<EXISTING_ROUTE>

애플리케이션을 활성화하고 공격 패턴을 전송한 뒤 몇 분 후 **위협 정보가 애플리케이션 신호 탐색기**에 표시됩니다.

태그를 활용해 텔레메트리 연결

예약(env, service, version) 및 사용자 지정 태그를 사용하여 Datadog 텔레메트리에 함께 연결합니다. 해당 태그를 사용하여 메트릭, 트레이스 및 로그를 원활하게 탐색할 수 있습니다. 적용한 설치 방법에 따른 추가 파라미터를 추가합니다.

datadog-ci lambda instrument \
    --env dev \
    --service web \
    --version v1.2.3 \
    --extra-tags "team:avengers,project:marvel"
    # ... 함수 이름과 같은 기타 필수 인수

custom:
  datadog:
    # ...  Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
    env: dev
    service: web
    version: v1.2.3
    tags: "team:avengers,project:marvel"

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
      env: dev
      service: web
      version: v1.2.3
      tags: "team:avengers,project:marvel"

const datadog = new Datadog(this, "Datadog", {
    // ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
    env: "dev",
    service: "web",
    version: "v1.2.3",
    tags: "team:avengers,project:marvel"
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

아울러, Datadog은 몇 분의 지연 시간만으로 Lambda 함수에 정의된 기존 AWS 리소스 태그를 사용하여 수집한 텔레메트리를 보강할 수 있습니다.

• Datadog Lambda 확장을 사용하여 Lambda 함수에서 텔레메트리를 수집하는 경우, Datadog AWS 통합을 활성화하세요. 본 기능으로 사용자 지정 태그를 사용하여 텔레메트리를 강화합니다. Datadog 예약 태그(env, service, version)는 해당 환경 파라미터(각DD_ENV, DD_SERVICE, DD_VERSION)로 설정해야 합니다. 예약 태그는 서버리스 개발 툴과 Datadog 통합에서 제공하는 파라미터를 사용하여 설정할 수도 있습니다. 해당 기능은 컨테이너 이미지와 함께 배포된 Lambda 함수에서는 작동하지 않습니다.

• Datadog Forwarder Lambda 함수를 사용하여 Lambda 함수로부터 텔레메트리를 수집하는 경우, DdFetchLambdaTags 옵션을 Datadog Forwarder의 CloudFormation 스택에서 true로 설정합니다. 해당 옵션은 버전 3.19.0부터 기본값이 true입니다.

요청 및 응답 페이로드 수집

Datadog은 AWS Lambda 함수의 JSON 요청 및 응답 페이로드를 수집하고 시각화하여 서버리스 애플리케이션에 대한 심층적인 인사이트를 제공하며, Lambda 함수 오류를 해결하는 데 도움을 드릴 수 있습니다.

본 기능은 기본적으로 비활성화되어 있습니다. 적용되는 설치 방법은 하단의 지침을 참조하세요.

datadog-ci lambda instrument \
    --capture-lambda-payload true
    # ... 함수 이름과 같은 기타 필수 인수

custom:
  datadog:
    # ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
    captureLambdaPayload: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
      captureLambdaPayload: true

const datadog = new Datadog(this, "Datadog", {
    // ...  Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
    captureLambdaPayload: true
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

요청 또는 응답 JSON 객체 내부의 민감한 데이터가 Datadog으로 전송되지 않도록 하려면 특정 파라미터를 스크러빙합니다.

해당 작업을 하려면, Lambda 함수 코드와 동일한 폴더에 datadog.yaml 파일을 새로 추가합니다. 그런 다음, 아래와 같이 datadog.yaml의 apm_config 설정 내 replace_tags 블록을 사용해 Lambda 페이로드의 필드를 난독화할 수 있습니다:

apm_config:
  replace_tags:
    # 태그에서 "foobar"가 포함된 모든 항목을 "REDACTED"로 변경:
    - name: "*"
      pattern: "foobar"
      repl: "REDACTED"
    # 요청 헤더에서 "auth"를 빈 문자열로 변경
    - name: "function.request.headers.auth"
      pattern: "(?s).*"
      repl: ""
    # 응답 페이로드의 "apiToken"를 "****"로 변경
    - name: "function.response.apiToken"
      pattern: "(?s).*"
      repl: "****"

또는 다음과 같이 Lambda 함수에 DD_APM_REPLACE_TAGS 환경 변수를 삽입하여 특정 필드를 난독화할 수도 있습니다:

DD_APM_REPLACE_TAGS=[
      {
        "name": "*",
        "pattern": "foobar",
        "repl": "REDACTED"
      },
      {
        "name": "function.request.headers.auth",
        "pattern": "(?s).*",
        "repl": ""
      },
      {
        "name": "function.response.apiToken",
        "pattern": "(?s).*"
        "repl": "****"
      }
]

논람다 리소스에서 트레이스 수집

Datadog은 Lambda 함수를 트리거하는 AWS 관리 리소스로 들어오는 Lambda 이벤트를 기반으로 APM 스팬을 추론할 수 있습니다. 이를 통해 AWS 관리 리소스 간의 관계를 시각화하고 서버리스 애플리케이션의 성능 문제를 식별할 수 있도록 도와드립니다. 자세한 내용은 추가 제품 세부 정보를 참조하세요.

현재 지원되는 리소스는 다음과 같습니다.

• API Gateway (REST API, HTTP API, WebSocket)
• 함수 URL
• SQS
• SNS (SQS를 통해 전송되는 SNS 메시지도 지원)
• Kinesis Streams (데이터가 JSON 문자열 또는 base64로 인코딩된 JSON 문자열인 경우)
• EventBridge (커스텀 이벤트, 여기서 Details는 JSON 문자열을 뜻함)
• S3
• DynamoDB

이 기능을 비활성화하려면 DD_TRACE_MANAGED_SERVICES를 false로 설정합니다.

DD_SERVICE_MAPPING

DD_SERVICE_MAPPING는 업스트림 논람다 서비스 이름의 이름을 변경하는 환경 변수입니다. old-service:new-service과 한 쌍으로 동작합니다.

구문

DD_SERVICE_MAPPING=key1:value1,key2:value2…

해당 변수와 상호 작용하는 방법은 다음 두 가지가 있습니다:

해당 유형의 모든 서비스 이름 변경하기

AWS Lambda 통합과 관련된 모든 업스트림 서비스의 이름을 변경하려면 다음의 식별자를 사용합니다:

특정 서비스 이름 변경

보다 세분화된 접근법을 취하고 싶다면 다음과 같은 서비스별 식별자를 사용하세요:

설명이 첨부된 예시

다운스트림 서비스의 이름을 변경하려면 트레이서 구성 문서의 DD_SERVICE_MAPPING을 참조하세요.

Datadog 트레이서 구성

Datadog APM 클라이언트가 자동으로 계측하는 라이브러리 및 프레임워크를 확인하려면 APM 호환성 요구 사항을 참조합니다. 사용자 지정 애플리케이션을 계측하려면 커스텀 계측에 관한 Datadog의 APM 지침을 확인하세요.

APM 스팬 수집용 샘플링 속도 선택

서버리스 함수용 APM 호출 트레이스 샘플링 속도를 관리하려면 함수의 DD_TRACE_SAMPLE_RATE 환경 변수를 0.000(Lambda 함수 호출 트레이스 없음)에서 1.000(모든 Lambda 함수 호출 트레이스) 사이의 값으로 설정합니다.

메트릭은 애플리케이션 트래픽의 100%를 기준으로 산출되며, 샘플링 구성에 관계없이 정확성을 유지합니다.

처리량이 많은 서비스의 경우, 트레이싱 데이터가 고빈도로 반복되기 때문에 대개 모든 요청을 수집할 필요가 없습니다. 상당히 중요한 문제의 경우 항상 여러 트레이스에서 그 증상을 나타냅니다. 이러한 수집 관리는 예산 범위 내에서 문제를 해결하는 데 필요한 가시성을 확보하도록 도와드립니다.

데이터 수집을 위한 기본 샘플링 메커니즘을 헤드 기반 샘플링이라고 합니다. 트레이스를 유지할지 중단할지 여부는 트레이스의 맨 처음, 루트 스팬의 시작 지점에서 결정됩니다. 그런 다음 해당 결정은 요청 컨텍스트의 일부로 다른 서비스(예: HTTP 요청 헤더)로 전파됩니다. 트레이스의 시작 부분에서 결정이 내려지고 해당 결정이 트레이스의 모든 부분에 전달되기 때문에 루트 서비스에서 샘플링 속도를 설정해야 적용이 가능합니다.

Datadog이 스팬을 수집한 후, Datadog Intelligent Retention 필터는 애플리케이션의 상태를 모니터링하는 데 도움이 되도록 트레이스의 일부를 인덱스화합니다. 아울러, 사용자 지정 보존 필터를 정의하여 조직의 목표 달성을 위해 더 오래 보관하려는 트레이스 데이터를 인덱스화할 수도 있습니다.

Datadog 트레이스 파이프라인에 대해 더 자세히 알아보세요.

트레이스에서 민감한 정보 필터링 또는 스크러빙

트레이스를 Datadog으로 전송하기 전에 필터링하려면 APM에서 원치 않는 리소스 무시하기를 참조하세요.

데이터 보안을 위해 트레이스 속성을 스크러빙하려면 데이터 보안을 위한 Datadog 에이전트 또는 트레이서 구성을 참조하세요.

트레이스 수집 활성화/비활성화

Datadog Lambda 확장 프로그램을 사용한 트레이스 수집은 기본으로 활성화되어 있습니다.

Lambda 함수에서 트레이스 수집을 시작하려면 다음과 같은 설정을 적용하세요:

datadog-ci lambda instrument \
    --tracing true
    # ... 함수 이름과 같은 기타 필수 인수

custom:
  datadog:
    # ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
    enableDDTracing: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
      enableDDTracing: true

const datadog = new Datadog(this, "Datadog", {
    // ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
    enableDatadogTracing: true
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

트레이스 수집 비활성화

Lambda 함수에서 트레이스 수집을 중단하려면 다음과 같은 설정을 적용하세요:

datadog-ci lambda instrument \
    --tracing false
    # ... 함수 이름과 같은 기타 필수 인수

custom:
  datadog:
    # ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
    enableDDTracing: false

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
      enableDDTracing: false

const datadog = new Datadog(this, "Datadog", {
    // ... Datadog 사이트 및 API 키와 같은 기타 필수 파라미터
    enableDatadogTracing: false
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

로그 및 트레이스 연결

트레이스 및 로그를 수집하기 위해 Lambda 확장을 사용하는 경우, Datadog은 request_id 태그 아래의 aws.lambda 스팬에 AWS Lambda 요청 ID를 자동으로 추가합니다. 아울러, 동일한 요청에 대한 Lambda 로그가 lambda.request_id 속성 아래에 추가됩니다. Datadog 트레이스 및 로그 보기는 AWS Lambda 요청 ID를 사용하여 연결합니다.

Forwarder Lambda 함수를 사용하여 추적 및 로그를 수집하는 경우, dd.trace_id 가 자동으로 로그에 삽입됩니다(환경 변수 DD_LOGS_INJECTION로 활성화됨). Datadog 트레이스 및 로그 보기는 Datadog 추적 ID를 사용하여 연결합니다. 해당 기능은 주로 사용되는 런타임 및 로거를 활용하는 대부분의 애플리케이션에서 지원됩니다(런타임별 지원 참조).

지원하지 않는 런타임 또는 커스텀 로거를 사용하는 경우 다음 지침을 따르세요:

• JSON으로 로그인할 때, 다음과 같이 dd-trace을 사용하여 Datadog 트레이스 ID를 불러와 dd.trace_id 필드 아래에 있는 로그에 추가합니다:

  {
    "message": "This is a log",
    "dd": {
      "trace_id": "4887065908816661012"
    }
    // ... the rest of your log
  }
  

• 플레인 텍스트로 로그인 시에는 다음 지침에 따릅니다:
  1. dd-trace을 사용하여 Datadog 트레이스 ID를 불러와 로그에 추가합니다.
  2. 기본 Lambda 로그 파이프라인을 복제합니다. 해당 파이프라인은 읽기 전용입니다.
  3. 복제한 파이프라인을 활성화하고 기본 파이프라인을 비활성화합니다.
  4. 복제한 파이프라인의 Grok 파서 규칙을 업데이트하여 Datadog 트레이스 ID를 dd.trace_id 특성으로 파싱합니다. 예를 들어, [INFO] dd.trace_id=4887065908816661012 My log message과 같은 로그에 대해 my_rule \[%{word:level}\]\s+dd.trace_id=%{word:dd.trace_id}.* 규칙을 적용합니다.

소스 코드에 오류 연결

Datadog 소스 코드 통합을 사용하면 내 텔레메트리(스택 트레이스 등)를 Git 리포지토리에 있는 Lambda 함수의 소스 코드에 연결할 수 있습니다.

서버리스 애플리케이션에 소스 코드 통합을 설정하는 방법에 관한 지침은 빌드 아티팩트 섹션의 Embed Git 정보를 참고하세요.

프로파일링 데이터 수집(공개 베타)

Datadog의 연속 프로파일러는 파이썬(Python) 버전 4.62.0 및 레이어 버전 62 이하에서 베타 버전으로 사용할 수 있습니다. 해당 옵션 기능은 DD_PROFILING_ENABLED 환경 변수를 true로 설정하여 활성화합니다.

연속 프로파일러는 실행 중인 모든 파이썬(Python) 코드의 CPU 및 힙의 스냅샷을 주기적으로 생성하는 스레드를 생성하는 방식으로 동작합니다. 여기에는 프로파일러 자체가 포함될 수 있습니다. 프로파일러 자체를 무시하려면 DD_PROFILING_IGNORE_PROFILER을 true으로 설정합니다.

PrivateLink 또는 프록시로 텔레메트리 전송하기

Datadog Lambda 확장 프로그램이 데이터를 Datadog으로 전송하려면 공용 인터넷에 접근해야 합니다. 공용 인터넷에 접근할 수 없는 VPC에서 Lambda 함수를 배포한 경우, datadoghq.com Datadog 사이트로 AWS PrivateLink를 통해 데이터를 전송하거나, 나머지 모든 사이트의 경우 프록시를 통해 데이터를 전송할 수 있습니다.

Datadog 포워더(Forwarder)를 사용하는 경우 다음 지침을 따르세요.

여러 Datadog 조직에 텔레메트리 전송

여러 조직에 데이터를 전송하려면 플레인 텍스트 API 키, AWS Secrets Manager 또는 AWS KMS를 사용하여 이중 전송 옵션을 활성화할 수 있습니다.

# 메트릭에 대한 이중 전송 활성화
DD_ADDITIONAL_ENDPOINTS={"https://app.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://app.datadoghq.eu": ["<your_api_key_4>"]}
# APM (트레이스)에 대한 이중 전송 활성화
DD_APM_ADDITIONAL_ENDPOINTS={"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
# APM (프로파일링)에 대한 이중 전송 활성화
DD_APM_PROFILING_ADDITIONAL_ENDPOINTS={"https://trace.agent.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://trace.agent.datadoghq.eu": ["<your_api_key_4>"]}
# 로그에 대한 이중 전송 활성화
DD_LOGS_CONFIG_FORCE_USE_HTTP=true
DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS=[{"api_key": "<your_api_key_2>", "Host": "agent-http-intake.logs.datadoghq.com", "Port": 443, "is_reliable": true}]

고급 사용법을 확인하려면 이중 전송 지침을 참조하세요.

AWS 리소스를 통한 트레이스 컨텍스트 전파

Datadog은 자동으로 트레이스 컨텍스트를 발신 AWS SDK 요청에 삽입하고 Lambda 이벤트에서 트레이스 컨텍스트를 추출합니다. Datadog은 이러한 기능으로 배포 서비스를 통해 요청 또는 트랜잭션을 트레이싱할 수 있습니다. 서버리스 트레이스 전파 지침을 참조하세요.

X-Ray 및 Datadog 트레이스 병합

AWS X-Ray는 AppSync 및 Step 함수와 같은 특정 AWS 관리형 서비스를 통한 트레이싱을 지원하며, 이는 데이터독 APM에서 기본 지원되지 않습니다. Datadog X-Ray 통합을 활성화하고 X-Ray 트레이스를 Datadog 기본 트레이스와 병합할 수 있습니다. 자세한 내용을 보려면 추가 세부 정보를 참조하세요.

AWS Lambda 코드 서명 사용

AWS Lambda 코드 서명은 신뢰할 수 있는 코드만 Lambda 함수에서 AWS로 배포하도록 도와드립니다. 함수에서 코드 서명을 활성화하면 AWS는 배포 시 모든 코드가 코드 서명 설정에서 정의한 신뢰할 수 있는 소스에 의해 서명되었는지 확인합니다.

코드 서명을 사용하도록 Lambda 함수를 설정한 경우, Lambda 함수를 배포하기 전에 Datadog에서 퍼블리싱한 Lambda 레이어를 사용하여 함수의 코드 서명 설정에 Datadog의 서명 프로필 ARN을 추가해야 합니다.

Datadog의 서명 프로필 ARN:

arn:aws:signer:us-east-1:464622532012:/signing-profiles/DatadogLambdaSigningProfile/9vMI9ZAGLc

arn:aws:signer:us-east-1:464622532012:/signing-profiles/DatadogLambdaSigningProfile/9vMI9ZAGLc

Datadog Lambda 확장으로 마이그레이션

Datadog은 Forwarder Lambda 함수 또는 Lambda 확장을 사용하여 Lambda 함수에서 모니터링 데이터를 수집할 수 있습니다. Datadog은 신규 설치 시 Lambda 확장을 설치하시길 권장합니다. 확실하지 않다면 Datadog Lambda 확장으로 마이그레이션 결정하기를 참조하세요.

마이그레이션하려면, Datadog Lambda 확장 프로그램 사용 설치 지침과 Datadog Forwarder 사용 지침을 비교해서 확인하세요. 고객님의 편의를 위해 주요 차이점을 하단에 요약해 드리겠습니다.

참고: Datadog은 개발 및 스테이징 애플리케이션을 먼저 마이그레이션하고 그 후 제품 애플리케이션을 하나씩 마이그레이션할 것을 권장합니다.

Datadog Lambda 확장 프로그램을 사용하여 x86에서 arm64로 마이그레이션하기

Datadog 확장 프로그램은 컴파일된 바이너리이며, x86 및 arm64 변형 버전 모두에서 사용할 수 있습니다. CDK, 서버리스 프레임워크 또는 SAM과 같은 배포 도구를 사용하여 x86 Lambda 함수를 arm64로(또는 arm64에서 x86으로) 마이그레이션하는 경우, 서비스 통합(예: API Gateway, SNS 또는 Kinesis)이 Lambda 함수의 버전 또는 별칭을 사용하도록 설정되어 있는지 확인하세요. 그렇지 않은 경우 배포 중 약 10초 동안 해당 기능을 사용하지 못할 수도 있습니다.

이러한 현상은 Lambda 함수를 x86에서 arm64로 마이그레이션하는 작업이 updateFunction와 updateFunctionConfiguration라는 두 개의 병렬 API 호출로 구성되기 때문에 발생합니다. 해당 호출 중에는 Lambda updateFunction 호출이 완료되고 코드가 새 아키텍처를 사용하도록 업데이트되는 짧은 간격이 존재하나updateFunctionConfiguration 호출은 아직 완료되지 않은 상태이므로, 이전 아키텍처가 여전히 확장 프로그램에 적용됩니다.

레이어 버전을 사용할 수 없는 경우, 아키텍처 마이그레이션 프로세스 중에 Datadog Forwarder를 구성할 것을 권장합니다.

로컬 테스트용 Datadog Lambda 확장 구성

Datadog Lambda 확장 프로그램이 설치된 상태에서 로컬로 Lambda 함수의 컨테이너 이미지를 테스트하려면, 로컬 테스트 환경에서 DD_LOCAL_TEST을 true로 설정해야 합니다. 그렇지 않은 경우 확장 프로그램이 AWS 확장 API의 응답을 기다렸다가 호출을 차단합니다.

OpenTelemetry API를 사용해 AWS Lambda 계측

Datadog 추적 라이브러리는 Datadog Lambda Extension을 설치할 때 포함되어 있으며, OpenTelemetry 계측 코드로 생성된 스팬과 트레이스를 허용하고, 텔레메트리를 처리하며, Datadog로 전송할 수 있습니다.

예를 들어 코드가 이미 OpenTelemetry API로 계측된 상태라면 이 방법을 사용할 수 있습니다. 또 OpenTelemetry API를 사용해 벤더 중립적 코드로 계측하면서 Datadog 추적 라이브러리의 혜택을 누리고 싶을 경우에 이 방법을 사용할 수 있습니다.

OpenTelemetry API로 AWS Lambda를 계측하려면 환경 변수 DD_TRACE_OTEL_ENABLED를 true로 설정하세요. 자세한 내용은 OpenTelemetry API로 커스텀 계측을 참고하세요.

문제 해결

설치 구성에 문제가 있는 경우, 디버깅 로그를 위해 환경 변수 DD_LOG_LEVEL를 debug로 설정하세요. 추가 문제 해결 팁을 확인하려면 서버리스 모니터링 문제 해결 지침를 참조하세요.

참고 자료

추가 유용한 문서, 링크 및 기사:

AWS Lambda용 서버리스 모니터링 설치설명서 AWS Lambda용 서버리스 모니터링 문제 해결설명서 Datadog GitHub 통합설명서