먼저, 메트릭, 트레이스 및 로그 수집을 시작하기 위해 Datadog Serverless Monitoring을 설치합니다. 설치를 완료하고 나면, 다음 주제를 참조하여 각자의 모니터링 요구 사항에 적합하게 설치를 구성합니다.

• 태그를 사용하여 텔레메트리 연결
• 요청 및 응답 페이로드 수집
• Lambda 외의 리소스에서 트레이스 수집
• Datadog SDK 구성
• APM 스팬 수집을 위한 샘플링 레이트 선택
• 트레이스에서 민감한 정보 필터링 또는 스크러빙
• 트레이스 수집 활성화/비활성화
• 로그 및 트레이스 연결
• 오류를 소스 코드와 연결
• 사용자 지정 메트릭 제출
• 프로파일링 데이터 수집
• 텔레메트리를 PrivateLink 또는 프록시를 통해 전송
• 여러 Datadog 조직에 텔레메트리 전송
• FIPS 규정 준수 활성화
• AWS 리소스에 트레이스 컨텍스트 전파
• X-Ray 및 Datadog 트레이스 병합
• AWS Lambda 코드 서명 활성화
• Datadog Lambda Extension으로 마이그레이션
• Datadog Lambda Extension을 사용하여 x86에서 arm64로 마이그레이션
• Datadog Lambda Extension을 로컬 테스트용으로 구성
• OpenTelemetry API를 사용하여 AWS Lambda 계측
• Datadog Lambda Extension v67+ 사용
• DynamoDB PutItem에 대한 자동 연결 구성
• AWS 서비스를 적절하게 시각화 및 모델링
• 로그를 Observability Pipelines로 전송
• API 키 시크릿을 정기적으로 다시 로드
• 문제 해결
• 추가 자료

위협 탐지를 활성화하여 공격 시도 관찰

서버리스 애플리케이션을 노리는 공격자에 대한 경보를 받고 신속하게 대응하세요.

시작하려면, 먼저 함수에 트레이싱이 활성화되어 있어야 합니다.

위협 모니터링을 활성화하려면 배포에 다음 환경 변수 추가:

environment:
  DD_SERVERLESS_APPSEC_ENABLED: true
  AWS_LAMBDA_EXEC_WRAPPER: /opt/datadog_wrapper

함수를 다시 배포하고 호출합니다. 몇 분 뒤, 해당 함수가 AAP 조회에 표시됩니다.

App and API Protection 위협 탐지가 실제로 작동하는 모습을 확인하려면 애플리케이션에 알려진 공격 패턴을 전송합니다. 예를 들어 값이 acunetix-product인 HTTP 헤더를 전송하면 보안 스캐너 공격 시도가 트리거됩니다.

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

애플리케이션을 활성화하고 공격 패턴을 전송한 뒤 몇 분이 지나면 **위협 정보가 Application Signals Explorer**에 표시됩니다.

태그를 사용하여 텔레메트리 연결

예약된 태그(env, service, version) 및 사용자 지정 태그를 사용하여 Datadog 텔레메트리를 서로 연결하세요. 이러한 태그를 사용하여 메트릭, 트레이스 및 로그를 원활하게 탐색할 수도 있습니다. 설치 방법에 따라 아래와 같은 추가 파라미터를 추가합니다.

datadog-ci lambda instrument \
    --env dev \
    --service web \
    --version v1.2.3 \
    --extra-tags "team:avengers,project:marvel"
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    env: dev
    service: web
    version: v1.2.3
    tags: "team:avengers,project:marvel"

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      env: dev
      service: web
      version: v1.2.3
      tags: "team:avengers,project:marvel"

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    env: "dev",
    service: "web",
    version: "v1.2.3",
    tags: "team:avengers,project:marvel"
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

또한 Datadog은 수집된 텔레메트리를 Lambda 함수에서 정의된 기존 AWS 리소스 태그로 보강할 수도 있습니다(몇 분의 지연 시간이 적용됨).

• Datadog Lambda Extension을 사용하여 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
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    captureLambdaPayload: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      captureLambdaPayload: true

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    captureLambdaPayload: true
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

요청 또는 응답 JSON 개체 내의 민감한 데이터가 Datadog으로 전송되지 않게 방지하려면 특정 파라미터를 스크러빙할 수 있습니다.

이렇게 하려면 Lambda 함수 코드와 동일한 폴더에 새 파일 datadog.yaml을 추가하세요. 그러면 datadog.yaml의 apm_config 설정 내 replace_tags 블록을 통해 Lambda 페이로드의 필드 난독화를 사용할 수 있습니다.

apm_config:
  replace_tags:
    # Replace all the occurrences of "foobar" in any tag with "REDACTED":
    - name: "*"
      pattern: "foobar"
      repl: "REDACTED"
    # Replace "auth" from request headers with an empty string
    - name: "function.request.headers.auth"
      pattern: "(?s).*"
      repl: ""
    # Replace "apiToken" from response payload with "****"
    - 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": "****"
      }
]

AWS 서비스에서 페이로드를 수집하려면 AWS Services에서 요청 및 응답 캡처를 참조하세요.

Lambda 외의 리소스에서 트레이스 수집

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은 업스트림 Lambda 외 서비스 이름의 이름을 바꾸는 환경 변수입니다. 이 환경 변수는 old-service:new-service 페어와 함께 작동합니다.

구문

DD_SERVICE_MAPPING=key1:value1,key2:value2…

이 변수와 상호작용을 하는 방법은 두 가지입니다.

한 유형의 모든 서비스 이름 바꾸기

AWS Lambda 통합과 연결된 모든 업스트림 서비스의 이름을 바꾸려면 다음 식별자를 사용하세요.

특정 서비스 이름 변경

좀 더 세분화된 방식으로 접근하려면, 다음 서비스별 식별자를 사용합니다.

설명을 포함한 예시

다운스트림 서비스 이름 변경에 관한 내용은 트레이서의 구성 설명서에 있는 DD_SERVICE_MAPPING을 참조하세요.

Datadog SDK 구성

Datadog APM 클라이언트가 자동으로 계측하는 라이브러리와 프레임워크가 무엇인지 확인하려면 APM의 호환성 요구 사항을 참조하세요. 사용자 지정 애플리케이션을 계측하려면 Datadog의 사용자 지정 계측에 대한 APM 가이드를 참조하세요.

APM 스팬 수집을 위한 샘플링 레이트 선택

서버리스 함수의 APM 트레이싱 호출 샘플링 레이트를 관리하려면 함수의 DD_TRACE_SAMPLING_RULES 환경 변수를 0.000(Lambda 함수 호출 추적 안 함)에서 1.000(모든 Lambda 함수 호출 추적) 사이의 값으로 설정합니다.

참고:

• DD_TRACE_SAMPLE_RATE는 사용이 중단되었습니다. 대신 DD_TRACE_SAMPLING_RULES를 사용하세요. 예를 들어 이미 DD_TRACE_SAMPLE_RATE를 0.1로 설정한 경우, 대신 DD_TRACE_SAMPLING_RULES를 [{"sample_rate":0.1}]로 설정하세요.
• trace.<OPERATION_NAME>.hits와 같은 전체 트래픽 메트릭은 Lambda의 샘플링된 호출만 기반으로 계산됩니다.

처리량이 많은 서비스의 경우, 트레이스 데이터가 매우 반복적이기 때문에 모든 요청을 수집할 필요가 없는 것이 일반적입니다. 충분히 중요한 문제는 항상 트레이스 여러 개에 증상이 표시됩니다. Ingestion Control을 사용하면 예산 범위를 벗어나지 않으면서 문제를 해결하는 데 필요한 가시성을 확보할 수 있습니다.

수집의 기본 샘플링 메커니즘을 헤드 기반 샘플링이라고 합니다. 트레이스를 유지할지 제거할지에 대한 결정은 트레이스의 맨 처음, 즉 루트 스팬이 시작되는 시점에 이루어집니다. 이 결정은 이후 요청 컨텍스트의 일부로, 예를 들어 HTTP 요청 헤더로 다른 서비스에 전파됩니다. 결정이 트레이스 시작 시점에 이루어진 다음 트레이스의 모든 부분으로 전달되기 때문에, 루트 서비스에서 샘플링 레이트를 구성해야 효과가 있습니다.

Datadog에서 스팬이 수집된 뒤, Datadog 지능형 보존 필터가 트레이스의 일부분을 인덱싱하여 애플리케이션 상태를 모니터링하는 데 도움이 됩니다. 사용자 지정 보존 필터를 정의하여 조직의 목표를 지원하고자 더 오래 보관하려는 트레이스 데이터를 인덱싱할 수도 있습니다.

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

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

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

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

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

Datadog Lambda Extension을 통한 트레이스 수집은 기본적으로 활성화됩니다.

Lambda 함수로부터 트레이스 수집을 시작하려면 아래의 구성을 적용하세요.

datadog-ci lambda instrument \
    --tracing true
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    enableDDTracing: true

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      enableDDTracing: true

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    enableDatadogTracing: true
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

트레이스 수집 비활성화

Lambda 함수로부터 트레이스 수집을 중지하려면 아래의 구성을 적용하세요.

datadog-ci lambda instrument \
    --tracing false
    # ... other required arguments, such as function names

custom:
  datadog:
    # ... other required parameters, such as the Datadog site and API key
    enableDDTracing: false

Transform:
  - AWS::Serverless-2016-10-31
  - Name: DatadogServerless
    Parameters:
      # ... other required parameters, such as the Datadog site and API key
      enableDDTracing: false

const datadog = new DatadogLambda(this, "Datadog", {
    // ... other required parameters, such as the Datadog site and API key
    enableDatadogTracing: false
});
datadog.addLambdaFunctions([<LAMBDA_FUNCTIONS>]);

로그 및 트레이스 연결

Lambda 확장을 사용하여 트레이스 및 로그를 수집하는 경우, Datadog이 자동으로 AWS Lambda 요청 ID를 request_id 태그 아래의 aws.lambda 스팬에 추가합니다. 또한, 동일한 요청에 대한 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 함수의 소스 코드에 연결할 수 있습니다.

서버리스 애플리케이션에서 소스 코드 통합을 설정하는 방법에 대한 지침은 빌드 아티팩트에 Git 정보 임베딩 섹션을 참조하세요.

프로파일링 데이터 수집

Datadog의 Continuous Profiler는 Python 트레이서 버전 4.62.0 및 레이어 버전 62 이하에서 미리 보기로 이용할 수 있습니다. 이 옵션 기능은 DD_PROFILING_ENABLED 환경 변수를 true로 설정하여 활성화합니다.

Continuous Profiler는 정기적으로 CPU 및 실행 중인 모든 Python 코드의 힙 스냅샷을 생성하는 스레드를 스포닝하는 방식으로 작동합니다. 여기에는 프로파일러 자체도 포함할 수 있습니다. 프로파일러가 자신을 무시하도록 하려면 DD_PROFILING_IGNORE_PROFILER를 true로 설정하세요.

텔레메트리를 PrivateLink 또는 프록시를 통해 전송

Datadog Lambda Extension은 Datadog으로 데이터를 전송하기 위해 퍼블릭 인터넷에 대한 액세스가 필요합니다. Lambda 함수가 퍼블릭 인터넷에 액세스할 수 없는 VPC에 배포된 경우, AWS PrivateLink를 통해 데이터를 datadoghq.com Datadog 사이트에 전송하고, 다른 모든 사이트로는 프록시를 통해 데이터를 전송하세요.

Datadog Forwarder를 사용하는 경우, 이 지침을 따르세요.

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

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

# Enable dual shipping for metrics
DD_ADDITIONAL_ENDPOINTS={"https://app.datadoghq.com": ["<your_api_key_2>", "<your_api_key_3>"], "https://app.datadoghq.eu": ["<your_api_key_4>"]}
# Enable dual shipping for APM (traces)
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>"]}
# Enable dual shipping for APM (profiling)
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>"]}
# Enable dual shipping for logs
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}]

고급 사용법에 대한 내용은 이중 전달 가이드를 참조하세요.

FIPS 규정 준수 활성화

AWS Lambda 함수에 대하여 FIPS 규정 준수를 활성화하려면 다음 단계를 따르세요.

1. 적절한 ARN을 참조하여 FIPS 규정을 준수하는 확장 레이어 사용:

arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-FIPS:99
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-ARM-FIPS:99

arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension-FIPS:99
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension-ARM-FIPS:99

2. Python, JavaScript 또는 Go를 사용하는 Lambda 함수의 경우, 환경 변수 DD_LAMBDA_FIPS_MODE를 true로 설정합니다. 이 환경 변수의 설명:

   • FIPS 모드에서, Lambda 메트릭 헬퍼 함수에 메트릭 제출을 위해 FIPS 규정을 준수하는 확장이 필요합니다.
   • API 키 조회를 위해 AWS FIPS 엔드포인트 사용
   • GovCloud 환경에서 기본적으로 활성화됨

3. Ruby, .NET 또는 Java를 사용하는 Lambda 함수의 경우, 환경 변수를 추가로 구성할 필요가 없습니다.

4. 완전한 엔드 투 엔드 FIPS 규정 준수를 위해서는, Lambda 함수가 Datadog for Government 사이트를 사용하도록 구성하세요.

   • DD_SITE를 ddog-gov.com(US1-FED) 또는 us2.ddog-gov.com(US2-FED)으로 구성 참고: FIPS 규정을 준수하는 Lambda 구성 요소는 모든 Datadog 사이트에서 작동하지만, FIPS 규정을 준수하는 인테이크 엔드포인트는 Datadog for Government 사이트에만 있습니다.

AWS 리소스에 트레이스 컨텍스트 전파

Datadog은 발신되는 AWS SDK 요청에 자동으로 트레이스 컨텍스트를 주입하고, Lambda 이벤트로부터 트레이스 컨텍스트를 추출합니다. 이렇게 하면 Datadog이 분산된 여러 서비스에서 요청 또는 트랜잭션을 추적할 수 있습니다. Serverless 트레이스 전파를 참조하세요.

X-Ray 및 Datadog 트레이스 병합

AWS X-Ray는 특정 AWS 관리형 서비스(예: AppSync 및 Step Functions)를 통한 트레이싱을 지원하며, 이것은 Datadog APM에서는 기본적으로 지원되지 않습니다. Datadog X-Ray 통합을 활성화하고 X-Ray 트레이스를 Datadog 네이티브 트레이스와 병합할 수 있습니다. 추가 세부 정보를 참조하세요.

AWS Lambda 코드 서명 활성화

AWS Lambda용 코드 서명은 신뢰할 수 있는 코드만 Lambda 함수에서 AWS로 배포되도록 보장하는 데 도움이 됩니다. 함수에서 코드 서명을 활성화하면 AWS가 배포의 모든 코드가 신뢰할 수 있는 소스로 서명되었는지 검증합니다. 신뢰할 수 있는 소스는 코드 서명 구성에서 정의합니다.

Lambda 함수가 코드 서명을 사용하도록 구성된 경우, 함수의 코드 서명 구성에 Datadog의 Signing Profile ARN을 추가해야만 Datadog이 게시한 Lambda Layers를 사용하여 Lambda 함수를 배포할 수 있습니다.

Datadog의 Signing Profile ARN:

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

Datadog Lambda Extension으로 마이그레이션

Datadog은 Forwarder Lambda 함수 또는 Lambda 확장을 사용하여 Lambda 함수로부터 모니터링 데이터를 수집할 수 있습니다. Datadog은 새 설치의 경우 Lambda 확장을 권장합니다. 확실하지 않은 경우, Datadog Lambda Extension으로 마이그레이션 결정을 참조하세요.

마이그레이션하려면 Datadog Lambda Extension을 사용한 설치 지침을 Datadog Forwarder 사용 지침과 비교합니다. 편의를 위해 주요 차이점을 아래에 요약했습니다.

참고: Datadog은 먼저 개발 및 스테이징 애플리케이션부터 마이그레이션한 다음 프로덕션 애플리케이션을 하나씩 마이그레이션할 것을 권장합니다.

Datadog Lambda Extension을 사용하여 x86에서 arm64로 마이그레이션

Datadog Extension은 컴파일된 바이너리로, x86 및 arm64 버전 둘 다에서 사용할 수 있습니다. CDK, Serverless Framework 또는 SAM과 같은 배포 도구를 사용하여 x86 Lambda 함수를 arm64로 마이그레이션하는 경우(또는 arm64를 x86으로), 서비스 통합(API Gateway, SNS 또는 Kinesis)이 Lambda 함수의 버전 또는 별칭을 사용하도록 구성되어 있는지 확인하세요. 그러지 않으면 배포 중에 약 10초간 함수를 사용할 수 없을 가능성이 있습니다.

이런 문제가 발생하는 이유는 Lambda 함수를 x86에서 arm64로 마이그레이션하는 작업은 병렬 API 호출 두 개, updateFunction 및 updateFunctionConfiguration으로 구성되기 때문입니다. 이러한 호출이 진행되는 동안, Lambda updateFunction 호출은 완료되어 코드가 새 아키텍처를 사용하도록 업데이트되었지만, updateFunctionConfiguration 호출은 아직 완료되지 않아 Extension에는 여전히 기존 아키텍처가 구성되어 있는 짧은 구간이 발생합니다.

Layer Versions를 사용할 수 없는 경우, Datadog은 아키텍처 마이그레이션 프로세스를 진행하는 동안 Datadog Forwarder를 구성할 것을 권장합니다.

Datadog Lambda Extension을 로컬 테스트용으로 구성

모든 Lambda 에뮬레이터가 AWS Lambda Telemetry API를 지원하는 것은 아닙니다. Lambda 함수의 컨테이너 이미지를 Datadog Lambda Extension이 설치된 상태로 로컬로 테스트하려면 로컬 테스트 환경에서 DD_SERVERLESS_FLUSH_STRATEGY를 periodically,1로 설정해야 합니다. 그러지 않으면 확장이 AWS Lambda Telemetry API로부터 응답을 기다리며 호출을 차단합니다.

OpenTelemetry API를 사용하여 AWS Lambda 계측

Datadog SDK는 Datadog Lambda Extension 설치 시 포함되며 OpenTelemetry로 계측된 코드가 생성한 스팬과 트레이스를 수락하고, 텔레메트리를 처리하여 Datadog으로 전송합니다.

이 접근 방식은 일례로 코드가 이미 OpenTelemetry API를 사용하여 계측된 경우 사용할 수 있습니다. 또한 OpenTelemetry API로 벤더 무관 코드를 사용해 계측하면서 Datadog SDK 사용 시 이점도 계속 누리고자 하는 경우에도 이 방식을 사용할 수 있습니다.

OpenTelemetry API를 사용하여 AWS Lambda를 계측하려면 환경 변수 DD_TRACE_OTEL_ENABLED를 true로 설정합니다. 자세한 내용은 OpenTelemetry API를 사용한 사용자 지정 계측을 참조하세요.

Datadog Lambda Extension v67+ 사용

Datadog Extension의 버전 67+는 콜드 스타트 시간을 대폭 단축하도록 최적화되었습니다. 최적화된 확장을 사용하려면 DD_SERVERLESS_APPSEC_ENABLED 환경 변수를 false로 설정하세요. DD_SERVERLESS_APPSEC_ENABLED 환경 변수가 true로 설정되어 있으면 Datadog Extension이 기본적으로 완전히 호환되는 오래된 버전으로 설정됩니다. DD_EXTENSION_VERSION을 compatibility로 설정하여 확장이 오래된 버전을 사용하도록 강제할 수도 있습니다. Datadog에서는 문제를 GitHub에 추가하고 문제를 version/next로 태그하여 피드백 또는 버그를 신고할 것을 독려합니다.

DynamoDB PutItem에 대한 자동 연결 구성

Python 및 Node.js 런타임에 대하여 사용 가능. 비동기 요청의 세그먼트가 트레이스 컨텍스트를 전파할 수 없으면, Datadog의 스팬 자동 연결 기능이 자동으로 연결된 스팬을 감지합니다. DynamoDB Change Streams의 PutItem 작업에 대하여 스팬 자동 연결을 활성화하려면 기본 키 이름을 테이블에 대하여 구성합니다.

ddtrace.config.botocore['dynamodb_primary_key_names_for_tables'] = {
    'table_name': {'key1', 'key2'},
    'other_table': {'other_key'},
}

// Initialize the tracer with the configuration
const tracer = require('dd-trace').init({
  dynamoDb: {
    tablePrimaryKeys: {
      'table_name': ['key1', 'key2'],
      'other_table': ['other_key']
    }
  }
})

export DD_BOTOCORE_DYNAMODB_TABLE_PRIMARY_KEYS='{
    "table_name": ["key1", "key2"],
    "other_table": ["other_key"]
}'

이렇게 하면 DynamoDB PutItem 호출이 스팬 포인터를 사용하여 계측되게 할 수 있습니다. 많은 DynamoDB API 호출은 항목의 기본 키 필드를 별도의 값으로 포함하지 않으므로, 그러한 필드를 SDK에 별도로 제공해야 합니다. 위의 구성은 딕셔너리(dict) 또는 테이블 이름을 문자열로 하여 키로 지정된 개체(str)로 구조화됩니다. 각 값은 연결된 테이블의 기본 키 필드 이름 세트(문자열 형식)입니다. 세트에는 테이블의 기본 키 스키마에 따라 정확히 한 개 또는 두 개의 요소를 포함할 수 있습니다.

리소스 이름 기준으로 AWS 서비스 시각화 및 모델링

Node.js, Python 및 Java Lambda 레이어의 다음 버전은 AWS 관리형 서비스를 올바로 이름 지정, 모델링, 시각화하도록 변경 사항을 릴리스했습니다.

서비스 이름이 AWS 서비스만이 아니라 실제 AWS 리소스 이름을 반영합니다.

• aws.lambda → [function_name]
• aws.dynamodb → [table_name]
• aws.sns → [topic_name]
• aws.sqs → [queue_name]
• aws.kinesis → [stream_name]
• aws.s3 → [bucket_name]
• aws.eventbridge → [event_name]

대시보드 및 모니터가 레거시 명명 규칙에 의존하는 경우, 오래된 서비스 표시 방식을 선호할 수 있습니다. 이전 동작을 복원하려면 환경 변수를 다음과 같이 설정:DD_TRACE_AWS_SERVICE_REPRESENTATION_ENABLED=false

업데이트된 서비스 모델링 구성을 권장합니다.

로그를 Observability Pipelines로 전송

Version 87+ of the Datadog Lambda Extension allows users to send logs to Observability Pipelines.

To enable this feature, set these environment variables:

• DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_ENABLED: true
• DD_OBSERVABILITY_PIPELINES_WORKER_LOGS_URL: <YOUR_OBSERVABILITY_PIPELINE_URL>

자세한 내용은 Datadog Lambda Extension Forwarder 로그를 Observability Pipelines로 전송을 참조하세요.

API 키 시크릿을 정기적으로 다시 로드

DD_API_KEY_SECRET_ARN을 사용하여 Datadog API 키를 지정하는 경우, DD_API_KEY_SECRET_RELOAD_INTERVAL을 설정하여 시크릿을 정기적으로 다시 로드할 수도 있습니다. 예를 들어 DD_API_KEY_SECRET_RELOAD_INTERVAL을 43200으로 설정하면 데이터를 전송하는 데 API 키가 필요할 때, 마지막 로드 이후 43,200초 넘게 지났을 때 시크릿이 다시 로드됩니다.

사용 사례 예시: 보안상의 이유로, API 키는 매일(86,400초) 교체되며 시크릿이 새 키로 업데이트되며, 기존 API 키는 유예 기간으로 하루 더 유효한 상태로 유지됩니다. 이 상황에서는 DD_API_KEY_SECRET_RELOAD_INTERVAL을 43200으로 설정하여 기존 키의 유예 기간 동안 API 키가 다시 로드되도록 할 수 있습니다.

이 기능은 Datadog Lambda Extension 버전 88+에서 사용할 수 있습니다.

문제 해결

설치를 구성하다가 문제가 발생하는 경우, 환경 변수 DD_LOG_LEVEL를 디버깅 로그에 대하여 debug로 설정합니다. 더 많은 문제 해결 팁은 서버리스 모니터링 문제 해결 가이드를 참조하세요.

추가 자료

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

AWS Lambda용 Serverless Monitoring 설치설명서 AWS Lambda용 Serverless Monitoring 문제 해결설명서 Datadog GitHub 통합설명서 Datadog으로 AWS Lambda를 Serverless Monitoring에 맞춰 구성학습 센터