콘텐츠로 이동

DataKit 로그 수집 개요

로그 데이터는 전반적인 관찰 가능성을 위해 유연하고 변경 가능한 정보 조합 방법을 제공합니다. 이로 인해 메트릭 및 추적과 비교하여 다양한 환경, 아키텍처 및 기술 스택의 수집 시나리오에 적응할 수 있는 로그 수집 및 처리 방법이 더 많습니다.

일반적으로 DataKit에는 다음과 같은 로그 수집 솔루션이 있습니다.

위의 다양한 수집 방법은 특정 환경에 따라 약간의 차이가 있지만 일반적으로 이러한 방법을 조합합니다. 다음은 카테고리별로 나누어 하나씩 소개합니다.

디스크 파일에서 로그 수집

이는 로그 처리의 가장 원시적인 방법입니다. 개발자용이든 기존 로그 수집 솔루션용이든 로그는 일반적으로 처음에는 디스크 파일에 직접 기록됩니다. 디스크 파일에 기록된 로그에는 다음과 같은 특징이 있습니다.

디스크 파일에서 로그 추출

디스크 파일

에서 로그 추출

  • 순차적 쓰기: 일반 로그 프레임워크는 디스크 파일의 로그를 보장하고 시간 순서를 유지할 수 있습니다.
  • 자동 로테이션: 디스크의 로그 파일은 계속 커지므로 디스크 공간이 가득 차지 않도록 일반적으로 로깅 프레임워크가 파일을 자동으로 로테이션합니다. 외부 상주 스크립트로 로그 로테이션을 수행할 수도 있습니다.

위의 특성을 바탕으로 우리는 DataKit이 이러한 파일의 변경 사항만 감시하면 된다는 것을 쉽게 상상할 수 있습니다(즉, 최신 업데이트를 수집합니다). 로그가 작성되면 DataKit은 로그를 수집할 수 있으며 배포도 매우 간단합니다. 로그 수집기의 conf에서 수집할 파일 경로(또는 와일드카드 경로)만 입력하면 됩니다.

로그 경로를 하드코딩하는 대신 와일드카드 경로(현재는 없지만 앞으로 나타날 파일을 구성할 수도 있음)를 사용하는 것이 좋습니다. 애플리케이션 로그가 즉시 표시되지 않을 수 있기 때문입니다(예를 들어 일부 애플리케이션의 오류 로그는 오류가 발생한 경우에만 표시됩니다).

디스크 파일 수집에 관해 주의할 점 중 하나는 DataKit이 시작된 이후 업데이트된 로그 파일만 수집됩니다.라는 점입니다. 구성된 로그 파일(DataKit이 시작된 이후)이 업데이트되지 않은 경우 과거 데이터는 수집되지 않습니다.입니다.

이 기능으로 인해 로그 파일이 계속 업데이트되고 DataKit이 중간에 중지되는 경우(이 기간 동안의 로그는 수집되지 않습니다.), 이 문제를 완화하기 위해 나중에 몇 가지 전략이 구현될 수 있습니다.

컨테이너 stdout 로그

이 수집 방법은 현재 주로 컨테이너 환경의 stdout 로그를 대상으로 합니다. 이러한 종류의 로그를 사용하려면 컨테이너(또는 Kubernetes Pod)에서 실행 중인 애플리케이션이 로그를 stdout으로 출력해야 합니다. 이러한 stdout 로그는 실제로 노드에 배치됩니다. DataKit은 해당 컨테이너 ID를 통해 해당 로그 파일을 찾아 일반 디스크 파일로 수집할 수 있습니다.

컨테이너 stdout 로그 수집

수집 컨테이너 stdout 로그

DataKit의 기존 stdout 수집 솔루션(주로 k8s 환경용)에서 로그 수집은 다음과 같은 특징을 갖습니다.

  • 컨테이너 환경에 배포된 애플리케이션은 해당 컨테이너 이미지를 빌드해야 하기 때문입니다. DataKit의 경우 이미지 이름을 기반으로 특정 애플리케이션에 대한 로그를 선택적으로 수집할 수 있습니다.

이는 애플리케이션이 로그를 stdout으로 출력해야 하는 이 전략의 결함이기도 합니다. 일반적인 애플리케이션 개발에서 로그는 stdout에 직접 기록되는 경우가 거의 없으며(그러나 주류 로깅 프레임워크는 일반적으로 stdout에 대한 출력을 지원함) 개발자는 로그 구성을 조정해야 합니다. 그러나 컨테이너화된 배포 솔루션이 계속 대중화되면서 이 솔루션은 실행 가능한 로그 수집 방법으로 간주될 수 있습니다.

DataKit으로 원격 로그 전송

원격 로그 푸시의 경우 주로

타사 로그 액세스

타사 로그 액세스

이 형태의 특징은 로그를 중간에 저장할 필요 없이 DataKit으로 직접 전송한다는 점입니다. 이 양식으로 로그를 수집할 때 다음 사항에 주의해야 합니다.

  • TCP 로그 푸시의 경우 로그 유형(source/service)이 변경되면 DataKit에서 여러 TCP 포트를 열어야 합니다.

DataKit에서 단일(또는 몇 개의) TCP 포트만 열고 싶다면 후속 Pipeline 처리에서 파싱된 필드의 특성을 식별하고 set_tag() 함수를 통해 service로 표시해야 합니다(현재 로그의 source 필드를 수정하는 것은 불가능하며 이 함수에는 버전 1.2.8 이상에서만 지원됩니다.만 있습니다).

Sidecar를 통한 로그 수집

이 수집 방법은 실제로 디스크 로그 수집과 로그 원격 푸시를 결합합니다. 구체적으로는 DataKit(예: logfwd)과 일치하는 사이드카 애플리케이션을 사용자의 Pod에 추가하는 것입니다. 수집방법은 다음과 같습니다.

사이드카 양식 로그 수집

사이드카 양식 로그 수집
  • 먼저 logfwd를 통해 로그를 디스크 파일로 얻습니다.
  • 그런 다음 logfwd는 원격으로(WebSocket) 로그를 DataKit에 푸시합니다.

이 방법은 현재 k8s 환경에서만 사용할 수 있습니다. 다음과 같은 특징이 있습니다.

  • 단순한 원격 로그 푸시와 비교하면 포드 이름, k8s 네임스페이스 정보 등 포드의 일부 k8s 속성 필드를 자동으로 추가할 수 있습니다.
  • 개발자는 로그 구성을 수정하지 않고도 로그를 디스크에 출력할 수 있습니다. k8s 환경에서는 외부 스토리지가 필요하지 않습니다. logfwd는 포드 자체 스토리지에서 로그를 직접 검색하여 푸시합니다(단, 포드 스토리지가 가득 차지 않도록 자동 파싱을 위해 로그를 설정해야 함).

로그 처리

위의 로그가 수집된 후 모두 후속 Pipeline 파싱을 지원하지만 구성 형식이 약간 다릅니다.

  • 디스크 로그 수집:logging.conf에서 직접 구성하고 Pipeline 이름을 지정합니다.
  • 컨테이너 stdout 로그 수집: Container.conf에서 Pipeline을 구성할 수 없습니다., 이는 모든 컨테이너의 로그 수집을 위한 것이며, 일반적인 Pipeline을 사용하여 모든 로그를 처리하기 어렵기 때문입니다. 따라서 Annotation인 관련 Pod의 Pipeline 구성을 지정합니다.를 통해서 이루어져야 한다.
  • 원격 로그 수집: TCP/UDP 전송 모드의 경우 로깅.conf에서 Pipeline 구성을 지정할 수도 있습니다. HTTP 전송 방법의 경우 개발자는 Pipeline을 구성하기 위해 HTTP 요청 매개변수가 나타납니다.를 입력해야 합니다.
  • 사이드카 로그 수집: logfwd 구성에서 호스트 Pod의 Pipeline을 구성합니다. 이는 본질적으로 컨테이너 stdout과 유사하며 Pod의 고정 소수점 표시입니다.

로그 수집 공통 추가 옵션

위에서 언급한 Pipeline 파싱을 제외한 모든 로그 수집은 사용된 수집 방법에 관계없이 다음과 같은 수집 구성을 지원합니다.

  • 여러 줄 자르기: 대부분의 로그는 한 줄 로그이지만 호출 스택 로그 및 일부 특수 애플리케이션 로그(예: MySQL 느린 로그)와 같은 일부 로그는 여러 줄 형식입니다.
  • 인코딩: 저장을 위해 최종 로그를 UTF8로 변환해야 합니다. 일부 Windows 로그의 경우 인코딩 및 디코딩이 필요할 수 있습니다.

요약

위 내용은 DataKit의 현재 로그 수집 솔루션에 대한 전반적인 소개를 제공합니다. 일반적으로 이러한 현재 솔루션은 기본적으로 주류 로그 데이터 시나리오를 다룰 수 있습니다. 소프트웨어 기술이 계속해서 반복됨에 따라 새로운 로그 데이터 형식이 계속 등장할 것이며 DataKit도 새로운 시나리오에 적응하기 위해 상응하는 조정을 수행할 것입니다.

문서 평가

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