고급 로그 수집 구성 (Advanced Log Collection Configurations)

Datadog Agent로 로그를 수집해 Datadog에 보낼 때, 그 수집 구성을 더 세밀하게 커스터마이즈하는 방법을 알려드릴게요. 로그 필터링부터 민감 데이터 스크럽, 멀티라인 집계까지 하나씩 살펴봐요.

출처: 문서

본문

로그 수집을 설정한 뒤 수집 구성을 커스터마이즈할 수 있어요:

• 로그 필터링
  • 일치 시 제외 (Exclude at match)
  • 일치 시 포함 (Include at match)
  • 잘린 로그 제외 (Exclude truncated)
• 로그에서 민감 데이터 스크럽
• 멀티라인 집계
• 멀티라인 로그 자동 집계
• 흔히 사용되는 로그 처리 규칙
• 와일드카드로 디렉터리 테일링
  • 수정 시간 기준 테일링 파일 우선순위 지정
• 로그 파일 인코딩
• 전역 처리 규칙
• 더 알아보기

Datadog Agent가 수집하는 모든 로그에 처리 규칙을 적용하려면 전역 처리 규칙(Global processing rules) 섹션을 참고하세요.

참고:

• 여러 처리 규칙을 설정하면 순차적으로 적용되며 각 규칙은 이전 규칙의 결과에 적용돼요.
• 처리 규칙 패턴은 Golang regexp 구문을 준수해야 해요.
• log_processing_rules 파라미터는 통합 구성에서 로그 수집 구성을 커스터마이즈하는 데 사용돼요. Agent의 메인 구성에서는 processing_rules 파라미터로 전역 처리 규칙을 정의해요.

로그 필터링 (Filter logs)

특정 로그의 일부만 Datadog에 보내려면 구성 파일에서 log_processing_rules 파라미터를 exclude_at_match 또는 include_at_match 유형으로 사용하세요.

일치 시 제외 (Exclude at match)

파라미터	설명
exclude_at_match	메시지에 지정된 패턴이 포함되어 있으면 해당 로그는 제외되고 Datadog으로 보내지지 않아요.

예를 들어 Datadog 이메일 주소가 포함된 로그를 걸러내려면 다음 log_processing_rules를 사용하세요:

구성 파일

logs:
  - type: file
    path: /my/test/file.log
    service: cardpayment
    source: java
    log_processing_rules:
    - type: exclude_at_match
      name: exclude_datadoghq_users
      ## Regexp can be anything
      pattern: \[email protected]

Docker

Agent 구성에 대한 자세한 내용은 Container Discovery Management를 참고하세요.

Docker 환경에서 필터링하려는 로그를 보내는 컨테이너의 com.datadoghq.ad.logs 라벨을 사용해 log_processing_rules를 지정하세요. 예:

 labels:
    com.datadoghq.ad.logs: >-
      [{
        "source": "java",
        "service": "cardpayment",
        "log_processing_rules": [{
          "type": "exclude_at_match",
          "name": "exclude_datadoghq_users",
          "pattern" : "\\[email protected]"
        }]
      }]

참고:

• 라벨을 사용할 때 패턴의 정규식 문자를 이스케이프하세요. 예를 들어 \d는 \\d, \w는 \\w가 돼요.
• 라벨 값은 JSON 구문을 따라야 하므로 끝에 쉼표나 주석을 포함하지 마세요.

Kubernetes

Agent 구성에 대한 자세한 내용은 Container Discovery Management를 참고하세요.

Autodiscovery로 pod 내의 특정 컨테이너(이름 CONTAINER_NAME)의 컨테이너 로그를 수집하도록 구성하려면 pod의 log_processing_rules에 다음 어노테이션을 추가하세요:

apiVersion: apps/v1
metadata:
  name: cardpayment
spec:
  selector:
    matchLabels:
      app: cardpayment
  template:
    metadata:
      annotations:
        ad.datadoghq.com/<CONTAINER_NAME>.logs: >-
          [{
            "source": "java",
            "service": "cardpayment",
            "log_processing_rules": [{
              "type": "exclude_at_match",
              "name": "exclude_datadoghq_users",
              "pattern" : "\\[email protected]"
            }]
          }]
      labels:
        app: cardpayment
      name: cardpayment
    spec:
      containers:
        - name: '<CONTAINER_NAME>'
          image: cardpayment:latest

참고:

• pod 어노테이션을 사용할 때 패턴의 정규식 문자를 이스케이프하세요. 예를 들어 \d는 \\d, \w는 \\w가 돼요.
• 어노테이션 값은 JSON 구문을 따라야 하므로 끝에 쉼표나 주석을 포함하지 마세요.

일치 시 포함 (Include at match)

파라미터	설명
include_at_match	지정된 패턴을 포함하는 메시지가 있는 로그만 Datadog으로 보내져요. 여러 include_at_match 규칙이 정의된 경우 로그가 포함되려면 모든 규칙 패턴이 일치해야 해요.

예를 들어 다음 log_processing_rules 구성을 사용해 Datadog 이메일 주소가 포함된 로그를 걸러내려면(필터 인) 하세요:

구성 파일

logs:
  - type: file
    path: /my/test/file.log
    service: cardpayment
    source: java
    log_processing_rules:
    - type: include_at_match
      name: include_datadoghq_users
      ## Regexp can be anything
      pattern: \[email protected]

하나 이상의 패턴을 매칭하려면 단일 표현식으로 정의해야 해요:

logs:
  - type: file
    path: /my/test/file.log
    service: cardpayment
    source: java
    log_processing_rules:
    - type: include_at_match
      name: include_datadoghq_users
      pattern: abc|123

패턴이 한 줄에 읽기 좋게 맞지 않을 정도로 길다면 여러 줄로 나눌 수 있어요:

logs:
  - type: file
    path: /my/test/file.log
    service: cardpayment
    source: java
    log_processing_rules:
    - type: include_at_match
      name: include_datadoghq_users
      pattern: "abc\
|123\
|\\[email protected]"

Docker

Docker 환경에서 필터링하려는 로그를 보내는 컨테이너의 com.datadoghq.ad.logs 라벨을 사용해 log_processing_rules를 지정하세요. 예:

 labels:
    com.datadoghq.ad.logs: >-
      [{
        "source": "java",
        "service": "cardpayment",
        "log_processing_rules": [{
          "type": "include_at_match",
          "name": "include_datadoghq_users",
          "pattern" : "\\[email protected]"
        }]
      }]

참고:

• 라벨을 사용할 때 패턴의 정규식 문자를 이스케이프하세요. 예를 들어 \d는 \\d, \w는 \\w가 돼요.
• 라벨 값은 JSON 구문을 따라야 하므로 끝에 쉼표나 주석을 포함하지 마세요.

Kubernetes

Kubernetes 환경에서 pod의 ad.datadoghq.com 어노테이션을 사용해 log_processing_rules를 지정하세요. 예:

apiVersion: apps/v1
metadata:
  name: cardpayment
spec:
  selector:
    matchLabels:
      app: cardpayment
  template:
    metadata:
      annotations:
        ad.datadoghq.com/<CONTAINER_NAME>.logs: >-
          [{
            "source": "java",
            "service": "cardpayment",
            "log_processing_rules": [{
              "type": "include_at_match",
              "name": "include_datadoghq_users",
              "pattern" : "\\[email protected]"
            }]
          }]
      labels:
        app: cardpayment
      name: cardpayment
    spec:
      containers:
        - name: '<CONTAINER_NAME>'
          image: cardpayment:latest

참고:

• pod 어노테이션을 사용할 때 패턴의 정규식 문자를 이스케이프하세요. 예를 들어 \d는 \\d, \w는 \\w가 돼요.
• 어노테이션 값은 JSON 구문을 따라야 하므로 끝에 쉼표나 주석을 포함하지 마세요.

잘린 로그 제외 (Exclude truncated)

파라미터	설명
exclude_truncated	존재하면 잘린(truncated) 로그를 제외하고 Datadog으로 보내지 않아요. exclude_truncated 규칙은 Agent v7.69부터 사용할 수 있어요.

예를 들어 잘린 로그를 걸러내려면:

구성 파일

logs:
  - type: file
    path: /my/test/file.log
    service: cardpayment
    source: java
    log_processing_rules:
    - type: exclude_truncated

Docker

Docker 환경에서 필터링하려는 로그를 보내는 컨테이너의 com.datadoghq.ad.logs 라벨을 사용해 log_processing_rules를 지정하세요. 예:

 labels:
    com.datadoghq.ad.logs: >-
      [{
        "source": "java",
        "service": "cardpayment",
        "log_processing_rules": [{
          "type": "exclude_truncated"
        }]
      }]

참고: 라벨 값은 JSON 구문을 따라야 하므로 끝에 쉼표나 주석을 포함하지 마세요.

Kubernetes

Kubernetes 환경에서 pod의 ad.datadoghq.com 어노테이션을 사용해 log_processing_rules를 지정하세요. 예:

apiVersion: apps/v1
metadata:
  name: cardpayment
spec:
  selector:
    matchLabels:
      app: cardpayment
  template:
    metadata:
      annotations:
        ad.datadoghq.com/<CONTAINER_NAME>.logs: >-
          [{
            "source": "java",
            "service": "cardpayment",
            "log_processing_rules": [{
              "type": "exclude_truncated"
            }]
          }]
      labels:
        app: cardpayment
      name: cardpayment
    spec:
      containers:
        - name: '<CONTAINER_NAME>'
          image: cardpayment:latest

참고: 어노테이션 값은 JSON 구문을 따라야 하므로 끝에 쉼표나 주석을 포함하지 마세요.

로그에서 민감 데이터 스크럽하기 (Scrub sensitive data from your logs)

로그에 편집이 필요한 민감 정보가 포함되어 있다면 구성 파일에서 log_processing_rules 파라미터를 mask_sequences 유형으로 사용해 민감 시퀀스를 스크럽하도록 Datadog Agent를 구성하세요.

이것은 일치한 모든 그룹을 replace_placeholder 파라미터의 값으로 대체해요.

예를 들어 신용카드 번호를 편집하려면:

구성 파일

logs:
 - type: file
   path: /my/test/file.log
   service: cardpayment
   source: java
   log_processing_rules:
      - type: mask_sequences
        name: mask_credit_cards
        replace_placeholder: "[masked_credit_card]"
        ##One pattern that contains capture groups
        pattern: (?:4[0-9]{12}(?:[0-9]{3})?|[25][1-7][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})

Docker

Docker 환경에서 컨테이너의 com.datadoghq.ad.logs 라벨을 사용해 log_processing_rules를 지정하세요. 예:

 labels:
    com.datadoghq.ad.logs: >-
      [{
        "source": "java",
        "service": "cardpayment",
        "log_processing_rules": [{
          "type": "mask_sequences",
          "name": "mask_credit_cards",
          "replace_placeholder": "[masked_credit_card]",
          "pattern" : "(?:4[0-9]{12}(?:[0-9]{3})?|[25][1-7][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\\d{3})\\d{11})"
        }]
      }]

참고:

• 라벨을 사용할 때 패턴의 정규식 문자를 이스케이프하세요. 예를 들어 \d는 \\d, \w는 \\w가 돼요.
• 라벨 값은 JSON 구문을 따라야 하므로 끝에 쉼표나 주석을 포함하지 마세요.

Kubernetes

Kubernetes 환경에서 pod의 ad.datadoghq.com 어노테이션을 사용해 log_processing_rules를 지정하세요. 예:

apiVersion: apps/v1
metadata:
  name: cardpayment
spec:
  selector:
    matchLabels:
      app: cardpayment
  template:
    metadata:
      annotations:
        ad.datadoghq.com/<CONTAINER_NAME>.logs: >-
          [{
            "source": "java",
            "service": "cardpayment",
            "log_processing_rules": [{
              "type": "mask_sequences",
              "name": "mask_credit_cards",
              "replace_placeholder": "[masked_credit_card]",
              "pattern" : "(?:4[0-9]{12}(?:[0-9]{3})?|[25][1-7][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\\d{3})\\d{11})"
            }]
          }]
      labels:
        app: cardpayment
      name: cardpayment
    spec:
      containers:
        - name: '<CONTAINER_NAME>'
          image: cardpayment:latest

참고:

• pod 어노테이션을 사용할 때 패턴의 정규식 문자를 이스케이프하세요. 예를 들어 \d는 \\d, \w는 \\w가 돼요.
• 어노테이션 값은 JSON 구문을 따라야 하므로 끝에 쉼표나 주석을 포함하지 마세요.

Agent 7.17+ 버전에서 replace_placeholder 문자열은 $1, $2 같은 캡처 그룹 참조를 확장할 수 있어요. 캡처 그룹 뒤에 문자열이 공백 없이 따라오게 하려면 ${<GROUP_NUMBER>} 형식을 사용하세요.

예를 들어 로그 User email: [email protected]에서 사용자 정보를 스크럽하려면 다음을 사용하세요:

• pattern: "(User email: )[^@]*@(.*)"
• replace_placeholder: "$1 masked_user@${2}"

이러면 다음 로그가 Datadog으로 전송돼요: User email: [email protected]

멀티라인 로그 자동 집계 (Automatically aggregate multi-line logs)

자동 멀티라인 감지는 복잡한 형식의 로그 소스가 많거나 각 소스를 개별적으로 구성할 시간이 없을 때 유용해요. 이 기능은 커스텀 정규식 패턴을 작성하지 않고도 멀티라인 로그를 자동으로 감지하고 집계해요.

자동 멀티라인 감지 및 집계 문서를 참고하세요.

이 기능의 레거시 지원은 자동 멀티라인 감지 및 집계 (레거시) 문서를 참고하세요.

멀티라인 로그 수동 집계 (Manually aggregate multi-line logs)

수동 멀티라인 규칙은 로그 형식을 알고 있을 때 로그 집계를 정밀하게 제어할 수 있게 해 줘요. 이 접근 방식은 특정 로그 구조에 맞는 커스텀 정규식 패턴으로 일관된 로그 처리를 보장하는 데 이상적이에요.

로그가 JSON이 아니고 여러 줄을 단일 항목으로 집계하려면, 줄마다 별도 로그를 두는 대신 특정 정규식 패턴으로 새 로그를 감지하도록 Datadog Agent를 구성하세요. log_processing_rules 파라미터에서 multi_line 유형을 사용해 지정된 패턴이 다시 감지될 때까지 모든 줄을 단일 항목으로 집계해요.

예를 들어 모든 Java 로그 줄은 yyyy-dd-mm 형식의 타임스탬프로 시작해요. 이 줄들에는 두 로그로 보낼 수 있는 스택 트레이스가 포함돼 있어요:

2018-01-03T09:24:24.983Z UTC Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(Book.java:16)
        at com.example.myproject.Author.getBookTitles(Author.java:25)
        at com.example.myproject.Bootstrap.main(Bootstrap.java:14)
2018-01-03T09:26:24.365Z UTC starting upload of /my/file.gz

구성 파일

설정 파일로 위 예시 로그를 보내려면 다음 log_processing_rules를 사용하세요:

logs:
 - type: file
   path: /var/log/pg_log.log
   service: database
   source: postgresql
   log_processing_rules:
      - type: multi_line
        name: new_log_start_with_date
        pattern: \d{4}\-(0?[1-9]|1[012])\-(0?[1-9]|[12][0-9]|3[01])

Docker

Docker 환경에서 컨테이너의 com.datadoghq.ad.logs 라벨을 사용해 log_processing_rules를 지정하세요. 예:

 labels:
    com.datadoghq.ad.logs: >-
      [{
        "source": "postgresql",
        "service": "database",
        "log_processing_rules": [{
          "type": "multi_line",
          "name": "log_start_with_date",
          "pattern" : "\\d{4}-(0?[1-9]|1[012])-(0?[1-9]|[12][0-9]|3[01])"
        }]
      }]

Kubernetes

Kubernetes 환경에서 pod의 ad.datadoghq.com 어노테이션을 사용해 log_processing_rules를 지정하세요. 예:

apiVersion: apps/v1
metadata:
  name: postgres
spec:
  selector:
    matchLabels:
      app: database
  template:
    metadata:
      annotations:
        ad.datadoghq.com/<CONTAINER_NAME>.logs: >-
          [{
            "source": "postgresql",
            "service": "database",
            "log_processing_rules": [{
              "type": "multi_line",
              "name": "log_start_with_date",
              "pattern" : "\\d{4}-(0?[1-9]|1[012])-(0?[1-9]|[12][0-9]|3[01])"
            }]
          }]
      labels:
        app: database
      name: postgres
    spec:
      containers:
        - name: '<CONTAINER_NAME>'
          image: postgres:latest

참고:

• pod 어노테이션으로 멀티라인 집계를 수행할 때 패턴의 정규식 문자를 이스케이프하세요. 예를 들어 \d는 \\d, \w는 \\w가 돼요.
• 어노테이션 값은 JSON 구문을 따라야 하므로 끝에 쉼표나 주석을 포함하지 마세요.

중요! 멀티라인 로그용 정규식 패턴은 로그의 시작에서 시작해야 해요. 패턴은 줄 중간에서 매칭될 수 없어요. 절대 매칭되지 않는 패턴은 로그 줄 손실을 일으킬 수 있어요. 로그 수집은 밀리초 정밀도까지 동작해요. 그보다 높은 정밀도의 로그는 패턴에 일치하더라도 전송되지 않아요.

더 많은 예시:

원시 문자열 (Raw string)	패턴 (Pattern)
14:20:15	\d{2}:\d{2}:\d{2}
11/10/2014	\d{2}\/\d{2}\/\d{4}
Thu Jun 16 08:29:03 2016	\w{3}\s+\w{3}\s+\d{2}\s\d{2}:\d{2}:\d{2}\s\d{4}
20180228	\d{8}
2020-10-27 05:10:49.657	\d{4}-\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}\.\d{3}
{"date": "2018-01-02"	\{"date": "\d{4}-\d{2}-\d{2}

흔히 사용되는 로그 처리 규칙 (Commonly used log processing rules)

예시 목록은 전용 Commonly Used Log Processing Rules FAQ를 참고하세요.

와일드카드로 디렉터리 테일링하기 (Tail directories using wildcards)

로그 파일이 날짜로 라벨링되거나 모두 같은 디렉터리에 저장된다면, path 속성에서 와일드카드를 사용해 모두 모니터링하고 새 파일을 자동으로 감지하도록 Datadog Agent를 구성하세요. 선택한 path와 일치하는 일부 파일을 제외하려면 exclude_paths 속성에 나열하세요.

• path: /var/log/myapp/*.log 사용:

  • /var/log/myapp/ 디렉터리에 포함된 모든 .log 파일과 일치해요.
  • /var/log/myapp/myapp.conf와는 일치하지 않아요.

• path: /var/log/myapp/*/*.log 사용:

  • /var/log/myapp/log/myfile.log와 일치해요.
  • /var/log/myapp/errorLog/myerrorfile.log와 일치해요.
  • /var/log/myapp/mylogfile.log와는 일치하지 않아요.

Linux 구성 예시:

logs:
  - type: file
    path: /var/log/myapp/log/*.log
    exclude_paths:
      - /var/log/myapp/log/debug.log
      - /var/log/myapp/log/trace.log
    service: mywebapp
    source: go

위 예시는 /var/log/myapp/log/myfile.log와 일치하고 /var/log/myapp/log/debug.log와 /var/log/myapp/log/trace.log를 제외해요.

Windows 구성 예시:

logs:
  - type: file
    path: C:\\MyApp\\*.log
    exclude_paths:
      - C:\\MyApp\\MyLog.*.log
    service: mywebapp
    source: csharp

위 예시는 C:\\MyApp\\MyLog.log와 일치하고 C:\\MyApp\\MyLog.20230101.log와 C:\\MyApp\\MyLog.20230102.log를 제외해요.

참고:

• Agent는 디렉터리의 사용 가능한 파일을 모두 나열하려면 디렉터리에 대한 읽기 및 실행 권한이 필요해요.
• path와 exclude_paths 값은 대소문자를 구분해요.
• Agent 7.76.0부터 datadog.yaml에서 logs_config.enable_recursive_glob: true를 설정하면 path와 exclude_paths에서 재귀 글로브(**)가 지원돼요. 기본값은 비활성화돼요.

수정 시간 기준 테일링 파일 우선순위 지정하기 (Prioritize tailed files by modification time)

이 기능에는 Agent 7.40.0 이상이 필요해요.

Agent는 logs_config.open_files_limit 파라미터로 동시에 테일링할 수 있는 파일 수를 제한해요. 구성된 로그 소스(예: 와일드카드)와 일치하는 파일 수가 한도 이내라면 Agent는 모두 테일링해요. 한도보다 많은 파일이 일치하면 Agent는 파일 이름을 역사전식(reverse lexicographic) 순서로 정렬해 우선순위를 지정하며, 최신 타임스탬프나 더 큰 번호의 파일을 먼저 테일링해요.

파일 이름이 순차적이거나 타임스탬프 패턴을 따르지 않으면 기본 정렬이 이상적이지 않을 수 있어요. 수정 시간 기준 우선순위를 지정하려면 logs_config.file_wildcard_selection_mode를 by_modification_time으로 설정하세요. 이 설정을 사용하면 Agent가 가장 최근에 수정된 파일을 먼저 테일링해요.

예시:

• open_files_limit = 500
• 와일드카드 패턴이 700개 파일과 일치.
• by_name 사용 시: Agent가 역사전식 순서로 가장 높은 이름을 가진 500개 파일을 테일링해요(예: app.log.700에서 app.log.201까지).
• by_modification_time 사용 시: Agent가 이름과 무관하게 가장 최근에 기록된 500개 파일을 테일링해요.

logs_enabled: true
logs_config:
 [...]
  open_files_limit: 500

  ## @param file_wildcard_selection_mode - string - optional - default: by_name
  ## The strategy used to prioritize wildcard matches if they exceed open_files_limit.
  ## Choices:
  ##   - by_name: files are sorted in reverse lexicographic order (default).
  ##   - by_modification_time: files are sorted by modification time, with the most recent first.
  ## WARNING: by_modification_time is less performant and increases disk I/O.
  file_wildcard_selection_mode: by_modification_time

기본 동작으로 되돌리려면 logs_config.file_wildcard_selection_mode 항목을 제거하거나 명시적으로 by_name으로 설정하세요.

로그 파일 인코딩 (Log file encodings)

기본적으로 Datadog Agent는 로그가 UTF-8 인코딩이라고 가정해요. 애플리케이션 로그가 다른 인코딩을 사용한다면 로그 구성 설정에서 encoding 파라미터를 지정하세요.

아래 목록은 지원되는 인코딩 값이에요. 지원되지 않는 값을 제공하면 Agent는 그 값을 무시하고 파일을 UTF-8로 읽어요.

• utf-16-le - UTF-16 리틀엔디언 (Datadog Agent v6.23/v7.23)
• utf-16-be - UTF-16 빅엔디언 (Datadog Agent v6.23/v7.23)
• shift-jis - Shift-JIS (Datadog Agent v6.34/v7.34)

Agent가 이미 테일링 중인 파일의 encoding을 변경하면 깨진 문자(mojibake)가 생길 수 있어요. Agent는 이전 바이트 오프셋부터 다시 시작하는데, 인코딩 변경 후에는 그 오프셋이 문자 경계에 맞지 않을 수 있어요. 해결하려면 로그 파일을 로테이션하거나 교체하거나, 새 인코딩을 사용하는 파일의 처음부터 테일링을 재시작하세요. 이렇게 하면 Agent가 올바른 인코딩으로 시작할 수 있어요.

구성 예시:

logs:
  - type: file
    path: /test/log/hello-world.log
    tags: key:value
    service: utf-16-logs
    source: mysql
    encoding: utf-16-be

참고: encoding 파라미터는 type 파라미터가 file로 설정된 경우에만 적용돼요.

전역 처리 규칙 (Global processing rules)

Datadog Agent v6.10+에서 exclude_at_match, include_at_match, mask_sequences 처리 규칙은 Agent의 메인 구성 파일이나 환경 변수로 전역 정의할 수 있어요. exclude_truncated 규칙은 Agent v7.69부터 사용할 수 있어요.

구성 파일

datadog.yaml 파일에서:

logs_config:
  processing_rules:
    - type: exclude_at_match
      name: exclude_healthcheck
      pattern: healthcheck
    - type: mask_sequences
      name: mask_user_email
      pattern: \[email protected]
      replace_placeholder: "MASKED_EMAIL"

환경 변수

DD_LOGS_CONFIG_PROCESSING_RULES 환경 변수를 사용해 전역 처리 규칙을 구성하세요. 예:

DD_LOGS_CONFIG_PROCESSING_RULES='[{"type": "mask_sequences", "name": "mask_user_email", "replace_placeholder": "MASKED_EMAIL", "pattern" : "\\[email protected]"}]'

Datadog Operator

Datadog Operator 매니페스트에서 spec.override.[key].env 파라미터를 사용해 DD_LOGS_CONFIG_PROCESSING_RULES 환경 변수를 설정해 전역 처리 규칙을 구성하세요. 여기서 [key]는 nodeAgent, clusterAgent, clusterChecksRunner예요. 예:

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  override:
    nodeAgent:
      env:
        - name: DD_LOGS_CONFIG_PROCESSING_RULES
          value: '[{"type": "mask_sequences", "name": "mask_user_email", "replace_placeholder": "MASKED_EMAIL", "pattern" : "\\[email protected]"}]'

Helm

Helm 차트에서 datadog.env 파라미터를 사용해 DD_LOGS_CONFIG_PROCESSING_RULES 환경 변수를 설정해 전역 처리 규칙을 구성하세요. 예:

datadog:
  env:
    - name: DD_LOGS_CONFIG_PROCESSING_RULES
      value: '[{"type": "mask_sequences", "name": "mask_user_email", "replace_placeholder": "MASKED_EMAIL", "pattern" : "\\[email protected]"}]'

Datadog Agent가 수집하는 모든 로그는 전역 처리 규칙의 영향을 받아요.

참고: 전역 처리 규칙에 형식 문제가 있으면 Datadog Agent는 로그 수집기를 시작하지 않아요. 문제를 해결하려면 Agent의 status 하위 명령어를 실행하세요.

멀티라인 로그 집계 FAQ (Multi-line log aggregation FAQ)

1. 수동 멀티라인 규칙과 자동 멀티라인 감지는 언제 각각 사용해야 하나요?

로그의 형식을 알고 있다면 정밀한 제어를 위해 수동 멀티라인 규칙을 사용해야 해요. 멀티라인 로그를 많이 보내지만 그 형식이 확실하지 않거나 모든 소스를 개별적으로 구성할 수단이 없다면 자동 멀티라인 감지를 사용해야 해요.

2. 멀티라인 패턴이 어떤 로그와도 일치하지 않으면 어떻게 되나요?

JSON이 아닌 모든 로그 줄은 별도의 로그 항목으로 개별 처리돼요. JSON 형식의 모든 로그 줄은 한 줄의 로그로 취급되며, 첫 번째 유효한 JSON 형식만 intake에 들어가고 나머지는 버려져요.

3. 전역 규칙과 통합별 규칙이 모두 있으면 어떻게 되나요? 통합별 규칙은 해당 특정 통합에 대해 전역 규칙을 완전히 덮어써요.

더 알아보기 (Learn more)

도움이 되는 추가 문서, 링크, 글:

• Logging without Limits™ 시작하기
• 로그 수집 전용으로 Datadog Agent 사용하기
• 로그를 처리하는 방법 알아보기
• 파싱에 대해 자세히 알아보기
• Datadog live tail 기능
• 로그 탐색 방법 보기
• "tail" 용어집 항목

*Logging without Limits는 Datadog, Inc.의 상표예요.