콘텐츠로 이동

DataKit 로그 처리 개요

이 문서는 DataKit이 로그를 처리하는 방법을 소개하는 데 사용됩니다. 다른 문서에서는 DataKit이 로그를 수집하는 방법을 소개했습니다. 이 두 문서는 함께 읽을 수 있습니다. 우리는 모든 사람이 전체 로그 처리에 대해 보다 포괄적으로 이해할 수 있기를 바랍니다.

핵심 질문:

  • 로그 수집 구성이 왜 그렇게 복잡합니까?
  • 로그 데이터 처리 방법

로그 수집 설정이 복잡한 이유

이 문서를 보면 로그 소스가 다양하기 때문에 로그 구성 방법도 다양하다는 사실을 알 수 있습니다. 모든 사람의 이해를 돕기 위해 여기서는 이를 정리할 필요가 있습니다.

로그 수집 프로세스 중에 DataKit에는 활성 및 수동이라는 두 가지 주요 수집 방법이 있습니다.

이러한 다양한 형태의 로그 수집 방법 중에서 모두 동일한 핵심 문제인 DataKit은 이 로그를 사용하여 다음으로 무엇을 합니까?를 해결해야 합니다.

이 핵심 문제는 다음과 같은 하위 문제로 분류될 수 있습니다.

  • source가 무엇인지 확인: 이후의 모든 로그 처리는 이 필드에 따라 달라집니다. (추가 service 필드가 있지만 지정하지 않으면 해당 값이 source 값과 동일하게 설정됩니다.)
  • Pipeline 구성 방법: 구성이 필수는 아니지만 널리 사용됩니다.
  • 추가 태그 구성: 반드시 구성할 필요는 없으나, 가끔 특수한 기능을 가지고 있는 경우가 있습니다.
  • 여러 줄의 로그를 분할하는 방법: 대상 로그가 각 로그를 분할하는 방법을 DataKit에 알려야 합니다. (DataKit은 기본적으로 공백이 아닌 문자로 시작하는 각 줄에 대한 새 로그를 지정합니다.)
  • 특별한 무시 전략이 있습니까? DataKit에서 수집한 모든 데이터를 처리할 필요는 없습니다. 특정 조건이 충족되면 수집하지 않을 수 있습니다. (수집 조건을 만족하더라도)
  • 기타 특수 구성: 색상 문자 필터링, 텍스트 인코딩 처리 등

현재 DataKit에 획득된 로그를 처리하는 방법을 알려주는 여러 가지 방법이 있습니다.

로그 수집기에서 conf를 통해 구성는 수집할 파일(또는 로그 스트림을 읽을 TCP/UDP 포트)을 나열합니다. conf에서 source/Pipeline/다라인 파싱/추가 태그 등 다양한 설정을 구성할 수 있습니다.

데이터가 TCP/UDP 형식으로 DataKit에 전송되면 후속 로그 처리는 login.conf를 통해서만 구성할 수 있습니다. TCP/UDP 프로토콜은 추가 설명 정보를 첨부하는 데 편리하지 않고 단순한 로그 스트림 데이터 전송만 담당하기 때문입니다.

이러한 형태의 로그 수집이 가장 이해하기 쉽습니다.

현재 컨테이너 수집기 conf는 로그에 대한 가장 피상적인 구성(컨테이너/Pod 이미지 이름 기반)만 수행할 수 있으며 로그의 후속 처리(예: Pipeline/source 설정 등)는 여기에서 구성할 수 없습니다. 왜냐하면 이 구성은 현재 호스트의 모든 로그 컬렉션을 목표로 하고 컨테이너 환경에서는 호스트에 다양한 로그가 있으며 여기에서 하나씩 구성할 수 없기 때문입니다.

  • 요청 시 DataKit에 로그 처리 구성 방법을 알려줌

HTTP를 통해 DataKit의 Log Streaming 서비스를 요청하고 요청에 다양한 요청 매개변수를 가져와 DataKit에 수신된 로그 데이터를 처리하는 방법을 알려줍니다.

  • 수집된 객체(예: 컨테이너/Pod)에 특정 주석을 작성하여 생성된 로그를 처리하는 방법을 DataKit에 알려줍니다.

앞서 언급했듯이 단순히 컨테이너 수집기 conf에서 로그 수집을 구성하는 것은 세분화가 너무 거칠고 세부 구성에 도움이 되지 않기 때문입니다. 하지만 컨테이너/Pod 라벨 지정에 설정할 수 있으며 DataKit은 주도적으로 이러한 주석을 찾아보세요.가 되며, 그러면 각 컨테이너/Pod 로그를 처리하는 방법을 알게 됩니다.

설정 우선순위

일반적인 상황에서는 컨테이너/Pod의 주석이 가장 높은 우선순위를 가지며 conf/Env의 설정을 재정의합니다. 둘째, Env는 중간 우선순위를 가지며 conf의 구성을 덮어씁니다. conf의 구성은 우선순위가 가장 낮으며 언제든지 Env 또는 주석의 설정으로 해당 구성을 덮어쓸 수 있습니다.

현재 로그 수집/처리와 직접적으로 관련된 Env는 없으며, 향후 관련 환경변수가 추가될 수 있습니다.

예를 들어, Container.conf에서 'my_test'라는 이미지를 로그 수집에서 제외한다고 가정합니다.

container_exclude_log = ["image:my_test*"]

현재 DataKit은 이미지 이름과 일치하는 모든 컨테이너 또는 포드를 수집하지 않습니다. 그러나 해당 주석이 해당 포드에 표시된 경우:

apiVersion: apps/v1
kind: Pod
metadata:
  name: test-app
  annotations:
    datakit/logs: |   # <----------
      [
        {
          "source": "my-testing-app",
          "pipeline": "test.p",
        }
      ]

spec:
   containers:
   - name : mytest
     image: my_test:1.2.3

컨테이너.conf에서 와일드카드 my_test.*가 있는 모든 이미지를 제외하더라도 포드에는 특정 레이블(datakit/logs)이 있으므로 DataKit은 계속해서 포드의 로그를 수집하고 Pipeline과 같은 많은 설정을 구성할 수 있습니다.

로그 데이터 처리 방법

DataKit에서 로그는 현재 다음 처리 단계를 거칩니다(처리 순서대로 나열).

  • 수집단계

외부에서 로그를 읽어(수신) 받은 후, 수집단계에서 기본적인 처리를 진행합니다. 이러한 프로세스에는 로그 분할(큰 텍스트 섹션을 여러 개의 독립적인 기본 로그로 나누기), 인코딩 및 디코딩(UTF8 인코딩으로 통합 변환), 일부 간섭하는 색상 문자 제거 등이 포함됩니다.

  • 개별 로그 파싱

해당 로그가 Pipeline 파싱으로 구성된 경우 각 로그(단일 및 다중 행 로그 포함)는 Pipeline으로 파싱됩니다. Pipeline은 주로 두 단계로 나뉩니다.

  1. Grok/JSON 파싱: Grok/JSON을 통해 단일 원시 로그를 구조화된 데이터로 파싱합니다.

  2. 추출된 필드(예: 완전한 IP 정보, 로그 둔감화 등)를 신중하게 처리하세요.

  3. 블랙리스트(필터)

필터는 필터의 집합입니다.는 구조화된 데이터 세트를 수신하고 특정 논리적 판단을 통해 데이터 폐기 여부를 결정합니다. 필터는 센터에서 발행한 논리적 운영 규칙 세트입니다(DataKit에서 적극적으로 가져옴). 그 형태는 대략 다음과 같습니다.

{ source = 'datakit' AND bar IN [ 1, 2, 3] }

센터에서 로그 블랙리스트를 구성하는 경우, 잘라낸 로그 100개 중 10개가 여기 조건을 충족한다고 가정하면(즉, source는 datakit이고 bar 필드의 값이 후속 목록에 나타납니다) 이 10개의 로그는 Guance에 보고되지 않고 자동으로 삭제됩니다. 폐기 통계는 DataKit Monitor에서 볼 수 있습니다.

  • 보고서 Guance

위의 단계를 거쳐 최종적으로 로그 데이터가 Guance로 보고되고, 로그 보기 페이지에서 로그 데이터를 확인할 수 있습니다.

일반적인 상황에서는 로그가 생성된 후, 수집이 성공한 경우 해당 페이지에서 데이터를 볼 수 있을 때까지 약 30초 정도의 지연이 발생합니다. 이 기간 동안 DataKit 자체 데이터는 최대 10초에 한 번만 보고되며, 센터에서도 최종적으로 데이터베이스에 저장되기까지 일련의 과정을 거쳐야 합니다.

추가 자료

문서 평가

이 페이지가 도움이 되었나요?