이 페이지에서는 Kubernetes 로그 파일의 로그 수집에 대해 설명합니다.

컨테이너화된 애플리케이션이 로그를 표준 출력(stdout) 및 표준 오류(stderr)에 기록하는 경우 컨테이너 런타임과 Kubernetes가 로그를 자동으로 관리합니다. 기본적으로 Kubernetes는 이러한 로그 스트림을 호스트의/var/log/pods 폴더와 각 포드 및 컨테이너의 하위 폴더에 파일 형태로 저장합니다.

Datadog Agent는 아래 지침을 사용하여 이러한 컨테이너의 Kubernetes 로그 파일을 수집할 수 있습니다. 이 옵션은 Kubernetes가 생성하는 포드의 일시적 특성에 적합하게 확장되며 Docker 소켓을 사용한 로그 수집보다 리소스를 더 효율적으로 사용합니다. Datadog은 Kubernetes에서 이 로그 수집 방식을 권장합니다.

또한 Datadog Agent는 Docker 소켓을 통해 Docker API를 반복 호출하여 로그를 수집할 수도 있습니다. 그러나 이 방식은 Kubernetes 클러스터의 컨테이너 런타임으로 Docker를 사용해야 합니다. 또한 로그 파일을 사용하는 방식보다 더 많은 리소스를 소비합니다. Docker 소켓을 사용한 로그 수집 방법은 Docker 소켓을 사용한 로그 수집을 참조하세요. 컨테이너화된 애플리케이션이 컨테이너 내부의 로그 파일에 직접 기록하는 경우 로그 수집이 복잡해질 수 있습니다. 이 경우 파일에서 로그 수집을 참조하세요.

설정

로그 수집

애플리케이션 로그 수집을 시작하기 전에 Kubernetes 클러스터에서 Datadog Agent가 실행 중인지 확인하세요.

DaemonSet에서 로그 수집을 수동으로 구성하려면 DaemonSet 로그 수집을 참조하세요. 그렇지 않으면 아래 지침을 따르세요.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>

  features:
    logCollection:
      enabled: true
      containerCollectAll: true

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

datadog:
  logs:
    enabled: true
    containerCollectAll: true

권한 없는 설치

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>

  features:
    logCollection:
      enabled: true
      containerCollectAll: true

  override:
    nodeAgent:
      securityContext:
        runAsUser: <USER_ID>
        supplementalGroups:
          - <DOCKER_GROUP_ID>

datadog:
  securityContext:
    runAsUser: <USER_ID>
    supplementalGroups:
      - <DOCKER_GROUP_ID>

로그 검색

Kubernetes의 Datadog Agent는 DaemonSet(Datadog Operator 또는 Helm에서 관리)에 의해 배포됩니다. 이 DaemonSet은 클러스터의 각 노드에 Agent 포드 복제본 하나를 배치합니다. 각 Agent 포드는 자신이 실행 중인 노드의 다른 포드 및 컨테이너 로그를 보고하는 역할을 담당합니다. “Container Collect All” 기능이 활성화되면 Agent는 검색된 모든 컨테이너의 로그를 기본 태그 집합과 함께 보고합니다.

필터링

“Container Collect All"이 활성화되면 로그를 수집할 컨테이너를 선택적으로 지정할 수 있습니다. 예를 들어 Datadog Agent 자체의 로그 수집을 제외하려는 경우 유용합니다. 이를 위해 Datadog Agent에 수집 대상을 제어하는 구성을 전달하거나 Kubernetes 포드에 특정 로그를 명시적으로 제외하는 구성을 전달할 수 있습니다.

DD_CONTAINER_EXCLUDE_LOGS 또는 ad.datadoghq.com/logs_exclude과 같은 방법으로 로그를 제외하는 경우, Agent는 Autodiscovery 주석 또는 Autodiscovery 구성 파일에 명시적으로 정의된 로그 수집 구성이 있더라도 해당 로그를 수집하지 않습니다.

“Container Collect All"이 비활성화된 경우(기본값) 모든 항목이 기본적으로 제외되므로 별도의 필터링을 추가할 필요가 없습니다. 선택한 포드에 대해서만 로그 수집을 활성화하려면 해당 포드에 대해 Autodiscovery 주석 또는 Autodiscovery 구성 파일을 사용하여 로그 구성을 설정할 수 있습니다.

필터링에 대한 자세한 내용은 Container Discovery Management를 참조하세요.

태깅

Datadog Agent는 Kubernetes 컨테이너의 로그에 기본 Kubernetes 태그와 사용자 지정으로 추출된 태그를 추가합니다. “Container Collect All"이 활성화된 경우 Agent는 컨테이너의 단축 이미지 이름을 기반으로 source 및 service 태그를 설정하여 로그를 보고합니다. 예를 들어 gcr.io/owner/example-image:latest 컨테이너 이미지를 사용하는 컨테이너의 로그에는 example-image가 source, service, short_image 태그 값으로 설정됩니다.

service 태그는 U Unified Service Tagging 포드 레이블인 tags.datadoghq.com/service: "<SERVICE>"을 통해서도 설정할 수 있습니다. source 및 service 속성에 대한 자세한 내용은 Reserved Attributes를 참조하세요.

source 태그는 기본 제공 로그 파이프라인이 이 태그를 기준으로 필터링되므로 로그에 중요할 수 있습니다. 다만 이러한 파이프라인은 필요에 따라 완전히 사용자 지정할 수 있습니다. 로그의 태그를 추가로 사용자 지정하는 방법은 아래의 통합 로그 섹션을 참조하세요.

통합 로그

Autodiscovery를 사용하면 템플릿을 이용해 컨테이너의 로그 수집(및 기타 기능)을 구성할 수 있습니다. 이를 통해 로그 수집을 활성화하고, 태깅을 사용자 지정하며, 고급 수집 규칙을 추가할 수 있습니다. Autodiscovery를 사용하여 통합의 로그 수집을 구성하려면 다음 방법 중 하나를 사용할 수 있습니다.

• 특정 포드에 Autodiscovery 주석으로 로그 구성을 지정하여 해당 컨테이너에 대한 규칙을 구성*(권장)*
• 구성 파일로 로그 구성을 지정하여 일치하는 이미지의 각 컨테이너에 대한 규칙을 구성

이러한 로그 구성에는 최소한 source 및 service 태그가 필요합니다. 로그를 자동으로 보강하는 데 도움이 되도록 source 태그를 Datadog의 기본 제공 로그 파이프라인 중 하나와 일치시키는 것이 좋습니다. Datadog에서 제공하는 파이프라인 라이브러리도 활용할 수 있습니다.

Autodiscovery 주석

Autodiscovery를 사용하면 Agent가 모든 포드 주석에서 통합 템플릿을 자동으로 검색합니다.

특정 컨테이너에 특정 구성을 적용하려면 JSON 형식의 로그 구성을 포함하는 ad.datadoghq.com/<CONTAINER_NAME>.logs 주석을 포드에 추가합니다.

참고: Autodiscovery 주석은 이미지가 아니라 이름을 기준으로 컨테이너를 식별합니다. 즉, <CONTAINER_NAME>을 .spec.containers[i].image가 아니라 .spec.containers[i].name과 맞추려고 합니다.

단일 컨테이너 구성

포드 내 특정 컨테이너의 로그 수집을 구성하려면 다음 주석을 포드에 추가합니다.

apiVersion: v1
kind: Pod
# (...)
metadata:
  name: '<POD_NAME>'
  annotations:
    ad.datadoghq.com/<CONTAINER_NAME>.logs: '[<LOG_CONFIG>]'
    # (...)
spec:
  containers:
    - name: '<CONTAINER_NAME>'
# (...)

로그 Autodiscovery 주석 예제

다음 포드 주석은 예제 컨테이너에 대한 통합 템플릿을 정의합니다. 이 주석은 Deployment 자체가 아니라 포드 템플릿의 annotations에 정의됩니다. 이 로그 구성은 app 컨테이너의 모든 로그에 대해 source:java, service:example-app 태그와 추가 태그 foo:bar를 설정합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
  labels:
    app: example-app
spec:
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
      annotations:
        ad.datadoghq.com/app.logs: '[{"source":"java", "service":"example-app", "tags":["foo:bar"]}]'
    spec:
      containers:
        - name: app
          image: owner/example-image:latest

서로 다른 두 컨테이너 구성

포드 내 두 개의 서로 다른 컨테이너(<CONTAINER_NAME_1> 및 <CONTAINER_NAME_2>)에 각각 다른 통합 템플릿을 적용하려면 다음 주석을 포드에 추가합니다.

apiVersion: v1
kind: Pod
# (...)
metadata:
  name: '<POD_NAME>'
  annotations:
    ad.datadoghq.com/<CONTAINER_NAME_1>.logs: '[<LOG_CONFIG_1>]'
    # (...)
    ad.datadoghq.com/<CONTAINER_NAME_2>.logs: '[<LOG_CONFIG_2>]'
spec:
  containers:
    - name: '<CONTAINER_NAME_1>'
    # (...)
    - name: '<CONTAINER_NAME_2>'
# (...)

Autodiscovery 구성 파일

Datadog Agent에 구성 파일을 제공하면, Agent가 지정된 이미지 식별자와 일치하는 컨테이너를 발견했을 때 지정된 통합을 실행하도록 할 수 있습니다. 이를 통해 특정 컨테이너 이미지 집합에 공통으로 적용되는 일반적인 로그 구성을 생성할 수 있습니다.

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  #(...)
  override:
    nodeAgent:
      extraConfd:
        configDataMap:
          <INTEGRATION_NAME>.yaml: |-
            ad_identifiers:
            - <CONTAINER_IMAGE>
        
            logs:
            - source: example-source
              service: example-service

datadog:
  #(...)
  confd:
    <INTEGRATION_NAME>.yaml: |-
      ad_identifiers:
      - <CONTAINER_IMAGE>
      
      logs:
      - source: example-source
        service: example-service

etcdctl mkdir /datadog/check_configs/redis
etcdctl set /datadog/check_configs/redis/logs '[{"source": "redis", "service": "redis", "tags": ["env:prod"]}]'

config_providers:
  - name: etcd
    polling: true
    template_dir: /datadog/check_configs
    template_url: '<KV_STORE_IP>:<KV_STORE_PORT>'
    username:
    password:

  - name: consul
    polling: true
    template_dir: datadog/check_configs
    template_url: '<KV_STORE_IP>:<KV_STORE_PORT>'
    ca_file:
    ca_path:
    cert_file:
    key_file:
    username:
    password:
    token:

  - name: zookeeper
    polling: true
    template_dir: /datadog/check_configs
    template_url: '<KV_STORE_IP>:<KV_STORE_PORT>'
    username:
    password:

/datadog/
  check_configs/
    <CONTAINER_IMAGE>/
      - logs: ["<LOGS_CONFIG>"]
    ...

컨테이너 단축 이미지 이름보다 더 세밀하게 컨테이너 집합에 로그 구성을 적용하려면 Autodiscovery Container Identifiers를 참조하세요.

고급 로그 수집

Autodiscovery 로그 레이블을 사용하여 다음과 같은 고급 로그 수집 처리 로직을 적용할 수 있습니다.

• Datadog으로 전송하기 전에 로그 필터링
• 로그의 민감한 데이터 스크러빙
• 여러 줄 로그 집계 수행

컨테이너 로컬 로그 파일에서 수집

Datadog은 컨테이너화된 애플리케이션에서 stdout 및 stderr 출력 스트림을 사용하는 것을 권장합니다. 이 방식을 사용하면 로그 수집을 보다 자동으로 구성할 수 있습니다.

그러나 Agent는 주석을 기반으로 파일에서 직접 로그를 수집할 수도 있습니다. 이러한 로그를 수집하려면 ad.datadoghq.com/<CONTAINER_NAME>.logs을 type: file 및 path 구성과 함께 사용합니다. 이 주석을 통해 파일에서 수집된 로그는 해당 컨테이너 자체에서 수집된 로그와 동일한 태그 집합이 자동으로 적용됩니다. Datadog은 컨테이너화된 애플리케이션에서 stdout 및 stderr 출력 스트림 사용을 권장합니다. 이를 통해 로그 수집을 자동으로 구성할 수 있습니다. 자세한 내용은 권장 구성을 참조하세요.

이러한 파일 경로는 Agent 컨테이너를 기준으로 한 상대 경로입니다. 따라서 Agent가 로그 파일을 볼 수 있도록 로그 파일이 저장된 디렉터리를 애플리케이션 컨테이너와 Agent 컨테이너 모두에 마운트해야 합니다.

예를 들어 공유 hostPath voume을 사용하여 이를 구성할 수 있습니다. 아래 포드 예제는 /var/log/example/app.log 파일에 로그를 기록합니다. 이는 /var/log/example 디렉터리에서 수행되며, volume과 volumeMount를 사용하여 해당 디렉터리를 공유 볼륨(hostPath)으로 구성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: logger
  annotations:
    ad.datadoghq.com/busybox.logs: |
      [{
          "type": "file",
          "path": "/var/log/example/app.log",
          "source": "example-source",
          "service": "example-service"
      }]
spec:
  containers:
   - name: busybox
     image: busybox
     command: [ "/bin/sh", "-c", "--" ]
     args: [ "while true; do sleep 1; echo `date` example file log >> /var/log/example/app.log; done;" ]
     volumeMounts:
     - name: applogs
       mountPath: /var/log/example
  volumes:
     - name: applogs
       hostPath:
         path: /var/log/example

동일한 로그 파일을 읽을 수 있도록 에이전트 컨테이너에 동일한 볼륨과 volumeMount 경로를 설정해야 합니다.

  containers:
  - name: agent
    # (...)
    volumeMounts:
    - mountPath: /var/log/example
      name: applogs
    # (...)
  volumes:
  - name: applogs
    hostPath:
      path: /var/log/example
    # (...)

권장 구성

• 이 전략은 개별 포드에서는 사용할 수 있지만, 여러 애플리케이션이 동일한 방식을 사용하는 경우 관리가 복잡해질 수 있습니다. 또한 여러 복제본이 동일한 로그 경로를 사용하는 경우 문제가 발생할 수 있습니다. 가능하면 Datadog은 Autodiscovery 템플릿 변수 %%kube_pod_name%%를 활용할 것을 권장합니다. 예를 들어 path를 다음 변수 참조 방식으로 설정할 수 있습니다. "path": "/var/log/example/%%kube_pod_name%%/app.log" 애플리케이션 포드 역시 이 새로운 경로를 기준으로 로그 파일을 기록하도록 구성해야 합니다. 애플리케이션이 자신의 포드 이름을 확인할 수 있도록 Downward API를 사용할 수 있습니다.

• 이와 같은 주석을 컨테이너에 사용하는 경우 stdout 및 stderr 로그는 자동으로 수집되지 않습니다. 컨테이너 출력 스트림과 파일 로그를 모두 수집해야 하는 경우 주석에서 이를 명시적으로 활성화해야 합니다. 예:

  ad.datadoghq.com/<CONTAINER_IMAGE>.logs: |
    [
      {"type":"file","path":"/var/log/example/app.log","source":"file","service":"example-service"},
      {"source":"container","service":"example-service"}
    ]
  

• 이와 같은 조합을 사용하는 경우 파일에서 수집된 로그에는 source 및 service에 대한 기본값이 없으므로 주석에서 명시적으로 설정해야 합니다.

문제 해결

문제 해결 단계는 컨테이너 로그 수집 문제 해결을 참조하세요.

추가 자료

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

Datadog을 사용하여 Fargate 기반 Amazon EKS의 로그 모니터링블로그 애플리케이션 트레이스 수집설명서 Prometheus 메트릭 수집설명서 애플리케이션 메트릭 및 로그 자동 수집설명서 데이터 수집을 컨테이너의 하위 집합으로만 제한설명서 컨테이너에서 내보내는 모든 데이터에 태그 할당설명서 컨테이너 로그 수집 문제 해결설명서