Guance VS ELK, EFK¶

ELK, EFK 및 Guance 개요¶

현대 소프트웨어 시스템의 복잡성이 점점 높아짐에 따라 일반적으로 로그는 서버에서 생성되어 여러 파일로 출력됩니다. 일반적으로 시스템 로그, 애플리케이션 로그, 보안 로그가 있으며, 이러한 로그는 여러 머신에 분산되어 저장됩니다. 일반적으로 시스템 장애가 발생하면 엔지니어는 각 서버에 로그인하여 grep / sed / awk 등의 Linux 스크립트 도구를 사용해 로그에서 장애 원인을 찾아야 합니다. 로그 시스템이 없는 경우, 먼저 요청을 처리하는 서버를 찾아야 하며, 해당 서버에 여러 인스턴스가 배포되어 있다면 각 애플리케이션 인스턴스의 로그 디렉토리에서 로그 파일을 찾아야 합니다. 또한 각 애플리케이션 인스턴스는 로그 롤링 정책(예: 매일 하나의 파일 생성)과 로그 압축 및 보관 정책 등을 설정합니다. 이러한 일련의 과정은 장애를 진단하고 신속하게 원인을 찾는 데 큰 어려움을 초래합니다.

클라우드에 배포할 경우 각 노드에 로그인하여 각 모듈의 로그를 확인하는 것은 사실상 불가능합니다. 효율성이 낮을 뿐만 아니라 보안상의 이유로 엔지니어가 각 물리적 노드에 직접 접근할 수 없기 때문입니다. 또한 현재 대규모 소프트웨어 시스템은 기본적으로 클러스터 배포 방식을 사용하므로 각 서비스에 대해 동일한 POD 여러 개를 시작하여 외부 서비스를 제공하며, 각 컨테이너는 자체 로그를 생성합니다. 생성된 로그만으로는 어떤 POD에서 생성된 것인지 알 수 없어 분산 로그를 확인하는 것이 더욱 어려워집니다.

따라서 이러한 로그를 중앙에서 관리하고 중앙 검색 기능을 제공할 수 있다면 진단 효율성을 높일 수 있을 뿐만 아니라 시스템 상황을 종합적으로 이해하여 사후 대응의 수동적인 상황을 피할 수 있습니다.

ELK¶

그렇다면 ELK란 정확히 무엇일까요? "ELK"는 Elasticsearch, Logstash, Kibana라는 세 가지 오픈소스 프로젝트의 약자입니다. Elasticsearch는 검색 및 분석 엔진입니다. Logstash는 서버 측 데이터 처리 파이프라인으로, 여러 소스에서 동시에 데이터를 수집하고 변환한 다음 Elasticsearch와 같은 "저장소"로 데이터를 전송합니다. Kibana는 사용자가 Elasticsearch에서 그래프와 차트를 사용하여 데이터를 시각화할 수 있도록 합니다.

Elasticsearch¶

Elasticsearch는 JSON 기반의 분산 검색 및 분석 엔진입니다. RESTful 웹 서비스 인터페이스로 접근할 수 있으며, 스키마가 거의 없는 JSON(JavaScript Object Notation) 문서를 사용하여 데이터를 저장합니다. Java 프로그래밍 언어를 기반으로 하여 Elasticsearch가 다양한 플랫폼에서 실행될 수 있습니다. 사용자는 매우 빠른 속도로 대량의 데이터를 검색할 수 있습니다.

주요 특징¶

• 분산형 실시간 파일 저장소, 모든 필드가 인덱싱되어 검색 가능
• 분산형 실시간 분석 검색 엔진
• 수백 대의 서버로 확장 가능, PB급 구조화 또는 비구조화 데이터 처리 가능

Logstash¶

데이터 흐름을 위한 오픈소스 스트리밍 ETL 엔진으로, 몇 분 안에 데이터 흐름 파이프라인을 구축할 수 있습니다. 수평 확장이 가능하고 탄력적이며 적응형 버퍼링을 제공하며, 200개 이상의 통합 및 프로세서 플러그인 생태계를 갖추고 있습니다. Elastic Stack을 사용하여 배포를 모니터링하고 관리할 수 있습니다.

주요 특징¶

• 거의 모든 데이터에 접근 가능
• 다양한 외부 애플리케이션과 결합 가능
• 탄력적 확장 지원

Logstash 구성 요소¶

• 입력(inputs): inputs는 주로 데이터 수신 규칙을 제공합니다. 예를 들어 파일 내용을 수집하는 데 사용됩니다.
• 필터(filters): filters는 전송된 데이터를 필터링합니다. 예를 들어 grok 규칙을 사용하여 데이터를 필터링합니다.
• 출력(outputs): outputs는 수신된 데이터를 정의된 출력 모드에 따라 출력합니다. 예를 들어 Elasticsearch로 출력합니다.

Kibana¶

Kibana는 오픈소스 데이터 분석 및 시각화 플랫폼으로, Elastic Stack의 구성원 중 하나이며 Elasticsearch와 협력하도록 설계되었습니다. Kibana를 사용하여 Elasticsearch 인덱스의 데이터를 검색, 확인, 대화식으로 조작할 수 있습니다. 차트, 테이블 및 지도를 사용하여 데이터를 다양하게 분석하고 표현할 수 있습니다.

Kibana는 빅데이터를 이해하기 쉽게 만듭니다. 브라우저 기반의 간단한 인터페이스를 통해 Elasticsearch의 실시간 데이터 변화를 추적하는 동적 데이터 대시보드를 신속하게 생성하고 공유할 수 있습니다.

EFK¶

EFK는 소프트웨어가 아니라 일련의 솔루션입니다. EFK는 Elasticsearch, Fluentd, Kibana 또는 Elasticsearch, Filebeat, Kibana의 약자입니다. Elasticsearch는 로그 분석 및 저장을 담당하고, Fluentd와 Filebeat는 로그 수집을 담당하며, Kibana는 인터페이스 표시를 담당합니다. 이들은 서로 협력하여 완벽하게 연결되며 다양한 상황에서 효율적으로 사용됩니다. 현재 주류 로그 분석 시스템 솔루션 중 하나입니다.

Fluentd¶

Fluentd는 데이터 흐름 처리를 위해 설계된 오픈소스 데이터 수집기로, JSON을 데이터 형식으로 사용합니다. 플러그인 기반 아키텍처를 채택하여 높은 확장성과 가용성을 제공하며, 높은 신뢰성의 정보 전달을 구현합니다. 사용 시 다양한 소스의 정보를 먼저 Fluentd로 보낸 다음, Fluentd는 구성에 따라 다른 플러그인을 통해 정보를 파일, SaaS Platform, 데이터베이스 또는 다른 Fluentd로 전달할 수 있습니다.

주요 특징¶

• 설치가 간편함
• 적은 공간 차지
• 반구조화된 데이터 로그 기록
• 유연한 플러그인 메커니즘
• 신뢰할 수 있는 버퍼링
• 로그 전달

Fluentd 구성 요소¶

Fluentd의 Input/Buffer/Output은 Flume의 Source/Channel/Sink와 매우 유사합니다.

• Input: Input은 데이터를 수신하거나 능동적으로 가져오는 역할을 합니다. syslog, http, file tail 등을 지원합니다.
• Buffer: Buffer는 데이터 획득의 성능과 신뢰성을 담당하며, 파일 또는 메모리 등 다양한 유형의 Buffer를 구성할 수 있습니다.
• Output: Output은 데이터를 파일, AWS S3 또는 다른 Fluentd와 같은 대상으로 출력하는 역할을 합니다.

Filebeat¶

Filebeat는 Golang으로 구현된 경량 로그 수집기로, Elasticsearch stack의 일부입니다. 본질적으로 에이전트로, 각 노드에 설치하여 구성에 따라 해당 위치의 로그를 읽고 적절한 곳으로 보고할 수 있습니다.

Filebeat는 신뢰성이 매우 높아 로그를 최소 한 번 이상(At least once) 보고할 수 있으며, 로그 수집 시 발생하는 다양한 문제(예: 로그 중단점 재개, 파일 이름 변경, 로그 잘림 등)도 고려합니다.

Filebeat는 Elasticsearch에 의존하지 않으며 독립적으로 사용할 수 있습니다. Filebeat 단독으로 로그를 보고하고 수집할 수 있습니다. Filebeat에는 kafka, Elasticsearch, redis 등 일반적인 Output 컴포넌트가 내장되어 있으며, 디버깅 목적으로 console과 file로 출력할 수도 있습니다. 기존 Output 컴포넌트를 사용하여 로그를 보고할 수 있습니다. 물론 사용자 정의 Output 컴포넌트를 만들어 Filebeat가 원하는 곳으로 로그를 전달하도록 할 수도 있습니다.

Filebeat는 elastic/beats의 일부이며, filebeat 외에도 HeartBeat, PacketBeat가 있습니다. 이러한 beat는 모두 libbeat 프레임워크를 기반으로 구현됩니다.

Filebeat 구성 요소¶

• 수집기 harvester: 수집기 harvester의 주요 역할은 단일 파일의 내용을 읽는 것입니다. 각 파일을 읽고 내용을 출력(the output)으로 전송합니다. 각 파일에 대해 하나의 harvester가 시작되며, harvester는 파일을 열고 닫는 역할을 담당하므로 런타임 중에 파일 설명자가 열린 상태로 유지됩니다. 파일이 읽는 중에 삭제되거나 이름이 변경되면 Filebeat는 계속 파일을 읽습니다.

• 탐색기 prospector: 탐색기 prospector의 주요 역할은 harvester를 관리하고 읽을 모든 파일 소스를 찾는 것입니다. 입력 유형이 로그인 경우, prospector는 경로와 일치하는 모든 파일을 찾고 각 파일에 대해 하나의 harvester를 시작합니다. 각 prospector는 자체 Go 코루틴에서 실행됩니다.

참고: Filebeat prospector는 로컬 파일만 읽을 수 있으며, 원격 호스트에 연결하여 저장된 파일이나 로그를 읽는 기능은 없습니다. Filebeat의 적용 범위가 매우 제한적이므로 이 문서에서는 Filebeat에 대한 많은 비교를 수행하지 않습니다.

Guance¶

DataKit¶

DataKit은 사용자 로컬 머신에서 실행되는 기본 데이터 수집 도구로, 주로 시스템 실행의 다양한 메트릭, 로그 등의 데이터를 수집하여 Guance로 집계합니다. Guance에서 사용자는 자신의 다양한 메트릭, 로그 등의 데이터를 확인하고 분석할 수 있습니다. DataKit은 Guance에서 매우 중요한 데이터 수집 컴포넌트로, Guance의 모든 데이터는 DataKit에서 비롯됩니다.

1. DataKit은 주로 정기적인 수집 방식을 통해 다양한 메트릭을 수집한 후 정기적, 정량적으로 HTTP(s)를 통해 DataWay로 데이터를 전송합니다. 각 DataKit에는 사용자를 식별하기 위한 해당 token이 구성됩니다.
2. DataWay는 데이터를 수신한 후 Guance로 전달하며, Guance로 전송되는 데이터에는 API 서명이 포함됩니다.
3. Guance는 합법적인 데이터를 수신한 후 데이터 유형에 따라 각각 다른 저장소에 기록합니다.

수집 클래스 데이터 비즈니스의 경우 일반적으로 일부 데이터 손실이 허용됩니다(데이터 자체가 간헐적으로 수집되므로 간격 기간의 데이터는 데이터 손실로 간주될 수 있음). 현재 전체 데이터 전송 체인은 다음과 같은 손실 방지를 수행합니다:

1. DataKit이 특정 네트워크 이유로 DataWay 전송에 실패하면 DataKit은 최대 1000개 지점의 데이터를 캐시합니다. 캐시된 데이터가 이 양을 초과하면 캐시가 정리됩니다.
2. DataWay는 특정 이유로 Guance 전송에 실패하거나 트래픽이 많아 Guance로 전송할 시간이 부족할 수 있습니다. DataWay는 이러한 데이터를 디스크에 영구 저장합니다. 이후 트래픽이 감소하거나 네트워크가 복구되면 이러한 데이터를 Guance로 전송합니다. 지연 전송된 데이터는 적시성에 영향을 미치지 않으며, 타임스탬프는 캐시된 데이터에 첨부됩니다.

DataWay에서 디스크를 보호하기 위해 이 디스크의 최대 사용량도 구성 가능하여 노드의 저장소를 가득 채우는 것을 방지합니다. 사용량을 초과하는 데이터의 경우 DataWay는 데이터를 폐기합니다. 그러나 이 용량은 일반적으로 크게 설정됩니다.

DataKit 구성 요소¶

위에서 아래로 DataKit 내부는 주로 세 가지 계층으로 나뉩니다:

• 최상위 계층: 프로그램 진입 모듈 및 일부 공통 모듈 포함
• 구성 로드 모듈: DataKit은 자체 메인 구성(즉, conf.d/datakit.conf) 외에도 각 수집기의 구성이 별도로 구성됩니다. 함께 두면 구성 파일이 매우 커져 편집이 어려울 수 있습니다.
• 서비스 관리 모듈: 주로 전체 DataKit 서비스 관리를 담당합니다.
• 도구 체인 모듈: DataKit은 클라이언트 프로그램으로서 데이터 수집 외에도 문서 보기, 서비스 재시작, 업데이트 등 다양한 주변 기능을 제공하며, 이는 모두 도구 체인 모듈에서 구현됩니다.
• Pipeline 모듈: 로그 처리에서 Pipeline 스크립트(Grok 구문)를 통해 로그를 분할하고 비구조화된 로그 데이터를 구조화된 데이터로 변환합니다. 다른 비로그 데이터에서도 해당 데이터 처리를 수행할 수 있습니다.
• 선출 모듈: 배포된 DataKit이 많을 때 사용자는 모든 DataKit의 구성을 동일하게 만든 다음 자동화된 일괄 배포를 통해 각 DataKit에 구성을 전달할 수 있습니다. 선출 모듈의 의미는 클러스터에서 특정 데이터 수집(예: Kubernetes 클러스터 메트릭)은 하나의 DataKit만 수집을 수행해야 한다는 것입니다(그렇지 않으면 데이터가 중복되고 수집 대상에 부담을 줍니다). 모든 DataKit 구성이 동일한 클러스터에서 선출 모듈을 통해 언제든지 최대 하나의 DataKit만 수집을 수행하도록 할 수 있습니다.
• 문서 모듈: DataKit 문서는 설치 시 함께 제공되며, 사용자는 http://localhost:9529/man 페이지에서 문서 목록에 접근할 수 있습니다. 명령줄에서도 문서를 볼 수 있습니다.
• 전송 계층: 거의 모든 데이터의 입출력 담당
• HTTP 서비스 모듈: DataKit은 Telegraf/Prometheus와 같은 타사 데이터의 수집을 지원하며, 향후 더 많은 데이터 소스를 수집할 수 있습니다. 현재 이러한 데이터는 모두 HTTP를 통해 수집됩니다.
• IO 모듈: 각 데이터 수집 플러그인은 수집이 완료될 때마다 데이터를 IO 모듈로 전송합니다. IO 모듈은 통합된 데이터 구축, 처리 및 전송 인터페이스를 캡슐화하여 각 수집기 플러그인의 수집 데이터를 쉽게 수집할 수 있습니다. 또한 IO 모듈은 일정한 리듬(정기적, 정량적)으로 HTTP(s)를 통해 DataWay로 데이터를 전송합니다.
• 수집 계층: 다양한 데이터 수집 담당. 수집 유형에 따라 두 가지로 나뉩니다:
• 능동 수집형: 이 수집기는 구성된 고정 빈도로 수집합니다. 예: CPU, 네트워크 카드 트래픽, 클라우드 신서틱 테스트 등
• 수동 수집형: 이 수집기는 일반적으로 외부 데이터 입력을 통해 수집을 구현합니다. 예: RUM, Tracing 등. 일반적으로 DataKit 외부에서 실행되며, DataKit이 제공하는 데이터 업로드 API를 통해 데이터를 일정 수준 표준화 처리한 후 Guance로 업로드합니다.

Guance 플랫폼¶

강력한 데이터 수집 능력을 기반으로 "Guance"은 인프라, 컨테이너, 미들웨어, 데이터베이스, 메시지 큐, 애플리케이션 링크, 프론트엔드 접근, 시스템 보안, 네트워크 접근 성능의 전체 링크에 대한 관측 가능성을 구축했습니다. Guance 표준 제품을 기반으로 사용자가 DataKit 수집을 올바르게 구성하면 자신의 프로젝트에 대한 완전한 관측 가능성을 신속하게 구축할 수 있습니다. 또한 라인 프로토콜(Line Protocol)과 Guance의 시나리오 구축 능력을 기반으로 사용자는 관찰하려는 메트릭을 사용자 정의하여 편리하게 통합하고 추가적인 관측 가능성을 실현할 수 있습니다.

"Guance"은 전체적으로 관측 가능성을 지향하는 완전한 기술 제품으로, 자체적으로 많은 기술적 장벽이 존재합니다. 오픈소스 솔루션과 비교하여 Guance은 처음부터 사용자가 제품을 사용하는 학습 비용을 효과적으로 낮추고 사용 편의성을 높이는 방법을 강조합니다. 따라서 DataKit의 설치 배포부터 모든 구성 가능한 능력까지 "Guance"은 대부분의 프로그래머와 운영 엔지니어의 습관에 맞게 사용자의 구성 난이도를 낮추고 UI의 사용 편의성과 전문성을 높여 사용자가 제품의 사용자와 그 가치를 신속하게 이해할 수 있도록 합니다.

실행 플랫폼 비교¶

Logstash의 원래 장점 중 하나는 JRuby로 작성되어 Windows에서 실행될 수 있다는 점입니다.

Fluentd는 최근까지 Windows를 지원하지 않았으나, Linux 플랫폼 중심의 이벤트 라이브러리에 대한 의존성이 사라지면서 이제 Windows를 지원합니다. 또한 in_windows_eventlog 플러그인을 사용하여 Windows 이벤트 로그를 추적할 수 있습니다.

DataKit은 Guance 제품에서 공식 제공하는 데이터 수집기로, 자체적으로 다양한 데이터 소스 수집 스크립트를 내장하고 있으며, 다양한 데이터 수집을 지원합니다. Windows, Linux, Mac 운영 체제와 ARM, X86 등 다양한 시스템 유형을 지원하며, 로그 수집에 있어서는 모든 플랫폼과 호환됩니다.

Logstash¶

Linux 및 Windows

Fluentd¶

Linux 및 Windows

DataKit¶

모든 플랫폼 지원, 클라이언트 시각화를 통한 구성 관리 지원, 설치 배포 및 복잡한 구성의 학습 비용 대폭 감소

이벤트 라우팅 비교¶

이벤트 라우팅 구성 측면에서 Fluentd의 방식은 더 선언적인 반면, Logstash의 방식은 절차적입니다. 따라서 절차적 프로그래밍 교육을 받은 개발자는 Logstash의 구성이 더 쉽게 접근할 수 있다고 생각할 수 있습니다. 또한 Fluentd의 태그 기반 라우팅은 복잡한 라우팅을 명확하게 표현할 수 있습니다. 그러나 Guance은 완성된 제품 로직과 강력한 제품 구성 요소를 기반으로 다른 제품에 의존하지 않고 이벤트 알림이나 데이터 탐색 등의 기능을 수행할 수 있어 진정한 관측 폐쇄 루프를 실현합니다. 이는 데이터 보안을 보장할 뿐만 아니라 복잡한 구성을 피하여 탁월한 사용자 경험을 제공합니다.

Logstash 이벤트 라우팅¶

Logstash는 모든 데이터를 하나의 스트림으로 라우팅한 다음 if-then 문을 사용하여 원하는 대상으로 전송합니다. 다음은 프로덕션의 오류 이벤트를 PagerDuty로 전송하는 예시입니다:

output {
if [loglevel] == "ERROR" and [deployment] == "production" {
pagerduty {
...
}
}
}

Fluentd 이벤트 라우팅¶

Fluentd는 태그에 의존하여 이벤트를 라우팅합니다. 각 Fluentd 이벤트에는 Fluentd가 어디로 라우팅할지 알려주는 태그가 있습니다. 프로덕션에서 오류 이벤트를 PagerDuty로 전송하는 구성은 다음과 같습니다:

<source>
  @type forward
</source>

<filter app.**>
  @type record_transformer
  <record>
    hostname "#{Socket.gethostname}"
  </record>
</filter>

<match app.**>
  @type file
  # ...
</match>

DataKit 프록시¶

DataKit은 Guance의 강력한 제품 구성 요소 중 하나로, 데이터를 직접 클라우드의 Guance 플랫폼으로 보고하여 관측 및 분석을 수행합니다. LogStash 및 Fluentd처럼 이벤트 라우팅을 제공하여 데이터를 다른 도구로 전송하여 분석, 캐싱 등을 수행할 필요가 없습니다. 물론 사용자 데이터의 보안을 보장하고 DataKit이 인터넷에 접근할 수 없는 내부 네트워크 환경에 배포된 경우 프록시 서버를 사용하여 인터넷에 접근해야 하는 상황을 해결하기 위해 DataKit의 프록시 구성은 매우 간단하며 프록시 옵션만 활성화하면 됩니다. 간단한 구성만으로 풍부한 제품 기능을 경험할 수 있습니다.

[[inputs.proxy]]
  ## default bind ip address
  bind = "0.0.0.0"
  ## default bind port
  port = 9530

플러그인 생태계 비교¶

Logstash, Fluentd 및 DataKit은 모두 풍부한 플러그인 생태계를 갖추고 있으며, 많은 입력 시스템(파일 및 TCP/UDP 등), 필터(필드별 분할 및 필터링)를 포함합니다.

Logstash 플러그인¶

Logstash는 GitHub 저장소에서 모든 플러그인을 관리하며, inputs, filter, output 플러그인은 총 200개 이상입니다. 사용자가 공동으로 유지 관리하며 공식 유지 관리가 부족합니다.

Fluentd 플러그인¶

Fluentd에는 입력, 파서, 필터, 출력, 포맷터, 저장소, 서비스 디스커버리, 버퍼 등 8가지 유형의 플러그인이 포함되어 있으며 총 500개 이상의 플러그인이 있습니다. 그러나 공식적으로 유지 관리되는 플러그인은 10개에 불과하며, 나머지는 사용자가 공동으로 유지 관리하여 공식 유지 관리 및 기술 스택 지원이 부족합니다.

DataKit 플러그인¶

DataKit에는 강력한 내장 기능이 포함되어 있습니다: 동적 grok 구문 쿼리 및 디버깅, 자체 개발 구문 DQL을 사용한 빠른 데이터 쿼리, 실시간 inputs 수집 실행 관측, 엣지 컴퓨팅 기능 및 시각적 클라이언트 방식의 구성, 수집 소스 배포 등. 또한 200개 이상의 공식 유지 관리 데이터 소스 수집 및 기술 스택 지원을 제공하며, Telefraf, Beats, Logstash, Fluentd 등 다양한 외부 데이터 수집과도 호환됩니다. 사용자에게 더 친숙한 점은 클라이언트 시각화를 통해 플러그인 및 에이전트를 관리하고 데이터 수집 상황을 실시간으로 확인할 수 있다는 것입니다.

큐 비교¶

Logstash는 지속적인 내부 메시지 큐가 부족합니다. 현재 Logstash는 20개의 이벤트(고정 크기)를 저장할 수 있는 메모리 큐를 가지고 있으며, 재시작 시 영구 저장을 위해 Redis와 같은 외부 큐에 의존합니다. Fluentd는 구성 가능한 버퍼 시스템을 가지고 있으며, 메모리 또는 디스크에 저장할 수 있지만 신뢰성을 구성하는 것은 복잡할 수 있습니다. DataKit은 내장 캐시 메커니즘을 제공하여 서버 구성에 따라 간단한 매개변수만 변경하면 데이터 캐싱 효과를 얻을 수 있습니다.

Logstash 큐¶

Logstash는 내장 지속성 메시지 큐가 부족하여 내장 큐 모델이 매우 단순하며, 지속성을 보장하기 위해 Redis와 같은 외부 큐가 필요합니다.

Fluentd 큐¶

Logstash에 비해 Fluentd는 내장 신뢰성을 제공하지만 구성이 비교적 복잡하여 사용자 학습 비용이 상당히 높습니다.

DataKit 큐¶

DataKit은 내장 캐시 메커니즘을 제공합니다. DataKit이 배포된 서버에서 네트워크 문제로 DataWay 전송에 실패하면 DataKit은 기본적으로 최대 1000개 지점의 데이터를 캐시하여 데이터 손실을 방지합니다. DataKit 구성 파일을 수정하여 최대 캐시 양을 제어할 수도 있으며, 구성이 간단하고 사용门槛이 낮아 거의 0에 가까운 학습 비용이 듭니다.

로그 파싱 비교¶

로그 분석은 기업 내에서 매우 기본적인 핵심 기술로, 보안 팀뿐만 아니라 IT 개발 팀, 비즈니스 팀에서도 사용됩니다. 보안 측면에서 보안 팀은 주로 알려지지 않은 보안 이벤트를 발견하고 알려진 보안 이벤트에 대한 추적 분석을 수행하기 위해 로그 분석을 추출합니다. 또 다른 중요한 목적은 국가 차원의 규제 및 규정 준수 요구 사항입니다. IT 개발 측면에서 기업 내부의 비보안 기술 팀이 로그 분석을 수행하는 주된 이유는 위치 문제를 발견하고 알려진 문제를 분석하는 것입니다. 주로 시스템 모니터링, APM(APM은 개발 팀이 관심을 갖는 모든 모니터링 항목을 포함)에 중점을 둡니다. 비즈니스 측면에서 비즈니스 팀의 로그 분석 요구 사항은 주로 리스크 제어, 운영 홍보, 사용자 프로파일링, 웹사이트 프로파일링 등에 집중됩니다. 따라서 로그가 하드디스크에 저장되어 있으면 가치가 없으며, 로그 분석 기술을 통해 로그 정보의 가치를 실현할 수 있습니다. 로그 가치의 실현 정도가 높을수록 회사의 기술력을 반영할 수 있습니다.

일반적으로 사용되는 Logstash는 임의의 텍스트를 구문 분석하고 구성하는 grok, 이벤트 필드에 대한 일반적인 변환을 수행하는 mutate, 이벤트를 완전히 삭제하는 drop, 이벤트의 복사본을 만드는 clone, IP 주소에 대한 지리적 위치 정보를 추가하는 geoip 등 일반적인 파서를 포함합니다. Fluentd 로그 파싱의 일반적인 작업은 하나 이상의 필드 값을 검색하여 이벤트를 필터링하거나, 새 필드를 추가하여 이벤트를 보강하거나, 개인 정보 보호 및 규정 준수를 위해 특정 필드를 삭제하거나 마스킹하는 것입니다. 플러그인은 상대적으로 적으며 record_transformer, filter_stdout, filter_grep, parser, filter_geoip의 다섯 가지 플러그인만 있습니다. DataKit 로그 파싱에는 비구조화된 텍스트 데이터를 분할하거나 구조화된 텍스트(예: JSON)에서 일부 정보를 추출하는 Pipeline, glob 규칙을 사용하여 로그 파일을 더 편리하게 지정하고 자동 발견 및 파일 필터링, 사용하기 쉬운 대화형 Grok 매칭 도구로 grok 사용门槛을 낮추고, 많은 스크립트 함수를 지원하여 데이터 형식을 더 유연하게 만드는 등 더 많은 기능이 포함되어 있습니다.

Logstash 로그 파싱¶

Grok은 현재 Logstash에서 비구조화된 로그 데이터를 구조화되고 쿼리 가능한 콘텐츠로 파싱하는 가장 좋은 방법입니다. 현재 Logstash에는 120개의 grok 파싱 템플릿이 내장되어 있지만, Logstash가 GitHub 저장소에서 관리하는 grok 파싱 템플릿은 사용자가 공동으로 유지 관리하며 공식 기술 지원이 부족합니다. grok 템플릿 성능 튜닝을 포함한 많은 비즈니스 요구 사항은 사용자가 직접 탐색해야 합니다.

Fluentd 로그 파싱¶

Fluentd의 로그 파싱 방식은 Logstash와 유사하지만 구성 방식이 더 유연합니다. 그러나 해당 grok 파싱 템플릿을 제공하지 않고 몇 가지 구성 예제만 제공하므로 사용자는 문서 예제를 참조하여 직접 파싱 기능을 구성해야 합니다. 사용门槛이 상대적으로 높으며, 구성 과정에서 발생하는 문제에 대한 기술 지원이 부족하여 사용자가 직접 Google을 통해 해결해야 할 가능성이 높습니다.

동일하게 구성된 서버 환경에서 Nginx의 access log를 예로 들어, 다음 로그는 365바이트이며 14개 필드로 구조화됩니다:

다음 테스트에서는 다양한 부하를 시뮬레이션하여 해당 로그를 파일에 반복적으로 기록하며, 각 로그의 time 필드는 현재 시스템 시간을 사용하고 나머지 13개 필드는 동일합니다.

실제 시나리오와 비교하여 시뮬레이션 시나리오는 로그 파싱에 차이가 없으며, 한 가지 차이점은 높은 데이터 압축률이 네트워크 출력 트래픽을 줄일 수 있다는 것입니다.

Logstash¶

logstash-7.1.0 버전, grok을 통해 로그를 파싱하고 kafka로 출력(내장 플러그인, gzip 압축 활성화).

로그 파싱 구성:

grok { 
patterns_dir=> "/home/admin/workspace/survey/logstash/patterns"

match=>{ "message"=>"%{IPORHOST:ip} %{USERNAME:rt} -
\"%{WORD:method} %{DATA:url}\" %{NUMBER:status} %{NUMBER:size} \"%{DATA:ref}\" \"%{DATA:agent}\" \"%{DATA:cookie_unb}\" \"%{DATA:cookie_cookie2}\" \"%{DATA:monitor_traceid}\" %{WORD:cell} %{WORD:ups} %{BASE10NUM:remote_port}" }

remove_field=>[ "message"]
}

테스트 결과:

Fluentd¶

td-agent-4.1.0 버전, 정규식을 통해 로그를 파싱하고 kafka로 출력(서드파티 플러그인 fluent-plugin-kafka, gzip 압축 활성화).

로그 파싱 구성:

<source>
type tail
format /^(?<ip>\S+)\s(?<rt>\d+)\s-\s\[(?<time>[^\]]*)\]\s"(?<url>[^\"]+)"\s(?<status>\d+)\s(?<size>\d+)\s"(?<ref>[^\"]+)"\s"(?<agent>[^\"]+)"\s"(?<cookie_unb>\d+)"\s"(?<cookie_cookie2>\w+)"\s"(?
<monitor_traceid>\w+)"\s(?<cell>\w+)\s(?<ups>\w+)\s(?<remote_port>\d+).*$/
time_format %d/%b/%Y:%H:%M:%S %z
path /home/admin/workspace/temp/mock_log/access.log 
pos_file /home/admin/workspace/temp/mock_log/nginx_access.pos
tag nginx.access 
</source>

테스트 결과:

DataKit¶

DataKit-1.1.8-rc3, Pipeline을 통해 비구조화된 텍스트 데이터 분할.

# access log
grok(_, "%{NOTSPACE:ip} %{NOTSPACE:rt} - \"%{NOTSPACE:method} %{NOTSPACE:url}\" %{NOTSPACE:status} %{NOTSPACE:size} \"%{NOTSPACE:ref}\" \"%{NOTSPACE:agent}\" \"%{NOTSPACE:cookie_unb}\" \"%{NOTSPACE:cookie_cookie2}\" \"%{NOTSPACE:monitor_traceid}\" %{NOTSPACE:cell} %{NOTSPACE:ups} %{NOTSPACE:remote_port}")

cast(status_code, "int")
cast(bytes, "int")

default_time(time)

테스트 결과:

로그 수집 아키텍처 비교¶

ELK 방식¶

방식 1¶

가장 간단한 ELK 아키텍처 방식입니다. 장점은 구축이 간단하고 쉽게 시작할 수 있다는 점입니다. 단점은 Logstash가 리소스를 많이 소모하며 CPU와 메모리 사용량이 높고, 메시지 큐 캐시가 없어 데이터 손실 위험이 있다는 것입니다. 사용자는 Logstash, ElasticSearch 및 Kibana에 충분히精通하여 다양한 복잡한 비즈니스 문제를 능숙하게 해결할 수 있어야 하며, LogStash 클러스터와 ElasticSearch 클러스터의 유지 관리자는 클러스터 성능 최적화 및 리소스 관리에 충분히精通하여 비즈니스가 정상적으로 실행될 수 있도록 해야 합니다.

이 아키텍처는 Logstash가 각 노드에 분산되어 관련 로그 및 데이터를 수집하고, 분석 및 필터링을 거친 후 원격 서버의 Elasticsearch로 전송하여 저장합니다. Elasticsearch는 데이터를 샤드 형태로 압축 저장하고 사용자 쿼리 및 조작을 위한 다양한 API를 제공합니다. 사용자는 Kibana Web을 구성하여 로그를 더 직관적으로 쿼리하고 데이터를 기반으로 보고서를 생성할 수 있습니다.

방식 2¶

상대적으로 성숙된 ELK 아키텍처입니다. 장점은 Kafka를 도입하여 원격 Logstash 클러스터가 장애로 중단되더라도 데이터가 먼저 저장되어 데이터 손실을 방지할 수 있다는 점입니다. 단점은 구축이 복잡하고 기술 스택이 복잡하여 빠르게 시작하기 어렵고, Logstash가 리소스를 많이 소모하며 CPU와 메모리 사용량이 높다는 점입니다. 추가로 Kafka 클러스터를 유지 관리해야 하며, 대규모 시나리오에서는 Zookeeper 클러스터도 추가로 유지 관리해야 할 수 있습니다. 사용자는 Logstash, ElasticSearch, Kafka 및 Kibana에 충분히精通하여 다양한 복잡한 비즈니스 문제를 능숙하게 해결할 수 있어야 하며, LogStash 클러스터, Kafka 클러스터 및 ElasticSearch 클러스터의 유지 관리자는 클러스터 성능 최적화 및 리소스 관리에 충분히精通하여 비즈니스가 정상적으로 실행될 수 있도록 해야 합니다.

이 아키텍처는 메시지 큐 메커니즘을 도입하여 각 노드의 Logstash Agent가 데이터/로그를 Kafka(또는 Redis)로 전달하고, 큐의 메시지 또는 데이터를 간접적으로 Logstash로 전달합니다. Logstash는 필터링 및 분석 후 데이터를 Elasticsearch로 전달하여 저장합니다. 마지막으로 Kibana가 로그와 데이터를 사용자에게 표시합니다. Kafka(또는 Redis)를 도입했기 때문에 원격 Logstash 서버가 장애로 중단되더라도 데이터가 먼저 저장되어 데이터 손실을 방지할 수 있습니다.

EFK 방식¶

방식 1¶

더 유연한 EFK 아키텍처입니다. 장점은 더 유연하고 Logstash에 비해 리소스 소모가 적으며 확장성이 뛰어나다는 점입니다. 단점은 LogStash 클러스터로 로그를 보고하여 집중 처리하려면 방대한 LogStash 클러스터가 컴퓨팅 성능을 제공해야 하며, 사용자는 Logstash, ElasticSearch 및 Kibana에 충분히精通하여 다양한 복잡한 비즈니스 문제를 능숙하게 해결할 수 있어야 하고, LogStash 클러스터와 ElasticSearch 클러스터의 유지 관리자는 클러스터 성능 최적화 및 리소스 관리에 충분히精通하여 비즈니스가 정상적으로 실행될 수 있도록 해야 합니다.

이 아키텍처는 수집端 Logstash를 Filebeats로 대체하고, Logstash 및 Elasticsearch 클러스터를 구성하여 대규모 클러스터 시스템의 운영 로그 데이터 모니터링 및 쿼리를 지원할 수 있습니다.

방식 2¶

ELK를 기반으로 Filebeat를 로그 수집端으로 사용합니다. 장점은 ELK 아키텍처에서 Logstash를 로그 수집端으로 사용할 경우 각 서버에 JAVA 환경을 설치해야 하지만(Logstash는 Java 기반이므로), Filebeat는 어떤 종속성도 필요 없이 설치 후 구성 파일을 수정하고 서비스를 시작하면 됩니다. 단점은 기술 스택이 복잡하여 빠르게 시작하기 어렵고, Logstash가 리소스를 많이 소모하며 CPU와 메모리 사용량이 높다는 점입니다. 추가로 Kafka 클러스터를 유지 관리해야 하며, 대규모 시나리오에서는 Zookeeper 클러스터도 추가로 유지 관리해야 할 수 있습니다. 사용자는 FileBeats, Logstash, ElasticSearch, Kafka 및 Kibana에 충분히精通하여 다양한 복잡한 비즈니스 문제를 능숙하게 해결할 수 있어야 하며, LogStash 클러스터, Kafka 클러스터 및 ElasticSearch 클러스터의 유지 관리자는 클러스터 성능 최적화 및 리소스 관리에 충분히精通하여 비즈니스가 정상적으로 실행될 수 있도록 해야 합니다.

이 아키텍처에서 수집端이 로그 파일을 수집할 때 Filebeat의 input에서 log_topic 필드를 정의하여 지정된 경로의 로그 파일을 하나의 클래스로 분류합니다. Output에서는 Kafka로 출력하도록 지정합니다. Kafka는 메시지 큐로 Filebeat 클라이언트에서 수집한 모든 로그를 수신하고, 로그 유형(예: nginx, php, system)에 따라 분류하여 전달합니다. Kafka에서는 input에서 정의한 로그 유형에 따라 Kafka에 다른 topic을 생성합니다. Logstash는 Kafka 메시지 큐에서 메시지를 수신하고 Kafka의 다른 topic에 따라 로그를 분류하여 Elasticsearch에 기록합니다. Kibana는 Elasticsearch의 인덱스와 매칭하여 로그 내용을 분석, 검색, 차트 표시할 수 있습니다(물론 직접 차트를 설계해야 합니다).

방식 3¶

Fluentd를 로그 수집端으로 사용합니다. 장점은 Fluentd의 리소스 점유율이 LogStash 클러스터보다 훨씬 낮아 아키텍처를 더 간단하고 유연하게 만들 수 있다는 점입니다. 단점은 Fluentd 구성이 상대적으로 복잡하고 사용门槛이 높아 빠르게 시작하기 어렵고, 구성 파일이 복잡하여 수정하기 번거롭다는 점입니다. 사용자는 Fluentd, ElasticSearch 및 Kibana에 충분히精通하여 다양한 복잡한 비즈니스 문제를 능숙하게 해결할 수 있어야 하며, ElasticSearch 클러스터의 유지 관리자는 클러스터 성능 최적화 및 리소스 관리에 충분히精通하여 비즈니스가 정상적으로 실행될 수 있도록 해야 합니다.

이 아키텍처는 Fluentd를 통해 프로그램의 로그를 수집하고, 로그를 elasticsearch 클러스터에 저장한 다음, kibana에서 elasticsearch를 연결하여 로그를 쿼리합니다.

Guance 아키텍처¶

DataKit은 기본 데이터 수집 도구로, 시스템 실행의 다양한 메트릭, 로그 등의 데이터를 수집하여 Dataway를 통해 Guance로 집계합니다. Guance에서 사용자는 자신의 다양한 메트릭, 로그 등의 데이터를 확인하고 분석할 수 있습니다. DataKit은 Guance에서 매우 중요한 데이터 수집 컴포넌트로, Guance의 모든 데이터는 DataKit에서 비롯됩니다.

DataKit의 배포 구성은 매우 간단하고 명확하며, 시각화된 클라이언트를 통해 사용자가 DataKit을 관리할 수 있습니다. DataKit은 로그 데이터뿐만 아니라 APM 데이터, 인프라, 컨테이너, 미들웨어, 네트워크 성능 등도 수집할 수 있습니다. DataKit은 LogStash 및 Fluentd처럼 ElasticSearch, Kafka와 같은 컴포넌트에 의존하여 비즈니스 기능을 보완할 필요가 없습니다. Guance은 이러한 문제를 전혀 고려할 필요 없이 사용자는 자신의 비즈니스 최적화에만 집중할 수 있습니다. DataKit은 사용자가 방대한 기술 스택을 익히고 높은 학습 비용을 지불할 필요 없이 간단한 구성만으로 Guance과 함께 다양한 복잡한 비즈니스 문제를 해결할 수 있습니다. ELK와 EFK는 전체 운영 비용이 막대하며, ElasticSearch 클러스터만 해도 많은 비용이 듭니다. 비용 절감을 위해 콜드/핫 데이터를 고려해야 한다면 더욱 골치 아픕니다. Guance을 사용하면 이러한 문제를 고려할 필요 없이 비즈니스에만 집중하면 됩니다.

하드웨어 비용 비교¶

가격은 누구나 매우 관심을 가지는 요소입니다. 클라우드 서비스를 사용하여 ELK, EFK 및 Guance 간의 비용을 비교해 보겠습니다.

ELK 비용¶

Elastic의 기본 컴포넌트는 오픈소스이므로 주요 비용은 하드웨어 비용에서 발생합니다. 다양한 아키텍처 구성으로 10대 서버의 로그를 수집하고, 각 서버에서 하루 1GB의 로그 양을 기준으로 비용을 계산합니다.

LogStash 클러스터 + Kafka 클러스터 + ElasticSearch 클러스터 + Kibana

• LogStash 클러스터

• Kafka 클러스터

• ElasticSearch 클러스터

• Kibana 노드

비즈니스 규모가 크지 않은 저장소 및 서버 구성을 기준으로 LogStash + Kafka + ElasticSearch + Kibana의 한 달 총 비용은 5175.4원입니다.

간단한 아키텍처(Kafka 클러스터 미사용) LogStash + ElasticSearch + Kibana의 한 달 총 비용은 2511.4원입니다.

EFK 비용¶

Elastic의 기본 컴포넌트는 오픈소스이므로 주요 비용은 하드웨어 비용에서 발생합니다. 다양한 아키텍처 구성으로 10대 서버의 로그를 수집하고, 각 서버에서 하루 1GB의 로그 양을 기준으로 비용을 계산합니다.

Fluentd + ElasticSearch 클러스터 + Kibana

• Fluentd

Fluentd는 별도로 클러스터로 배포할 필요가 없으므로 Fluentd 비용은 고려하지 않고 ElasticSearch + Kibana만 계산합니다.

• ElasticSearch 클러스터

• Kibana 노드

동일한 비즈니스 규모로 저장소 및 서버 구성을 기준으로 Fluentd + ElasticSearch + Kibana의 한 달 총 비용은 2028원입니다.

Guance 비용¶

Guance은 제품 비용을 별도로 청구하지 않으며 저장소 사용량에 따라서만 요금을 부과합니다. DataKit 수집기 수, 로그 클래스 데이터 양, 백업 로그 데이터 양, 일일 작업 호출 횟수, 단일 DataKit 타임라인, RUM 일일 세션 수, APM trace 수를 기준으로 가격이 계산됩니다. 동일하게 10대 서버의 로그를 수집하고, 각 서버에서 하루 1GB의 로그 양을 기준으로 비용을 계산합니다.

10대 서버에 DataKit 설치, 로그 수집 각 서버 하루 1GB, 4KB/건 기준.

동일한 비즈니스 규모로 Guance의 한 달 총 비용은 1825원입니다.

운영 비용 비교¶

운영 비용에 대해 말하자면, 클러스터의 완전성을 보장하기 위해 관련 운영이 필수적이라는 것을 알고 있습니다. 그럼 다양한 방식 간의 비용 차이를 함께 분석해 보겠습니다.

ELK 운영 비용¶

Elastic의 기본 컴포넌트는 오픈소스이므로 사용자가 직접 클러스터를 구축하여 운영 관리해야 합니다. 복잡한 아키텍처의 ELK는 LogStash 클러스터 + Kafka 클러스터 + ElasticSearch 클러스터 + Kibana 노드로 구성될 수 있습니다. 첫째, 사용자 비즈니스 로그 양이 많고 계산 로직이 복잡한 경우 LogStash 클러스터, Kafka 클러스터, ElasticSearch 클러스터의 규모와 구성 요구 사항이 높아집니다. 둘째, 다양한 규모의 클러스터에 대한 운영 담당자의 역량 요구 사항도 높습니다. 규모가 큰 클러스터는 다양한 문제가 발생할 수 있으며, 리소스 활용도를 최대화하려면 충분한 경험을 바탕으로 성능 튜닝을 수행해야 합니다. 마지막으로 운영 담당자의 기술 스택 요구 사항은 필수적입니다.

EFK 운영 비용¶

ELK와 마찬가지로 EFK도 오픈소스 컴포넌트를 기반으로 하므로 사용자가 직접 클러스터를 구축하여 관리해야 합니다. ELK보다 나은 점은 EFK가 Fluentd를 수집기로 사용하여 데이터를 수집할 때 LogStash 클러스터를 생략할 수 있고 리소스 점유율도 더 낮다는 점입니다. 그러나 여전히 비즈니스 규모에 따라 ElasticSearch 클러스터 규모를 동적으로 확장해야 하며, 대규모 클러스터에서 운영 담당자의 역량 요구 사항이 높고 최적화가 어렵다는 문제에 직면합니다. 또한 Fluentd의 구성은 Logstash보다 더 어려워 운영 담당자의 경험에 의존해야 합니다. 스크립트 최적화가 제대로 이루어지지 않으면 로그를 파싱할 때 서버의 기존 비즈니스에 영향을 줄 수 있습니다. 온라인 비즈니스의 안정적인 운영을 보장하려면 운영 담당자에 대한 요구 사항이 더 높을 수 있습니다.

Guance 운영 비용¶

Guance은 SaaS 기반 관측 가능성 플랫폼으로, 사용자는 데이터를 수집하려는 서버에 DataKit을 배포하고 시각적 관리 기능을 활성화하기만 하면 원격 시각화 방식으로 수집端 구성을 관리할 수 있습니다. Guance 플랫폼은 최적의 로그 파싱 템플릿을 제공하여 서버에 대한 부담을 최소화하면서 성능 활용을 최대화하고, 간단한 구성만으로 비즈니스 로그를 파싱하여 사용자가 비즈니스 최적화 및 확장에 더 집중할 수 있도록 합니다. 수집端 및 로그 파싱 클러스터 최적화에 더 이상 에너지를 쏟을 필요가 없습니다. 또한 Guance은 인프라, 컨테이너, 미들웨어, 데이터베이스, 메시지 큐, 애플리케이션 링크, 프론트엔드 접근, 시스템 보안, 네트워크 접근 성능의 전체 링크에 대한 완전한 관측 가능성 기능을 온라인으로 제공하며, 비즈니스 요구 사항에 따라 자체 관측 시나리오를 구축할 수 있습니다. 미성숙한 오픈소스 제품을 연구하거나 개조하는 데 시간을 쏟을 필요 없이 진정한 0 운영 비용으로 비즈니스 발전에 집중할 수 있습니다.

학습 비용 비교¶

로그 분석 시스템을 구축하거나 사용하는 데 있어 학습 비용은 필수적인 요소입니다. 잘 사용하려면 먼저 잘 배워야 합니다. 그럼 다양한 방식의 시작 난이도를 살펴보겠습니다.

ELK 학습 비용¶

Elastic의 컴포넌트는 오픈소스이므로 사용자가 직접 클러스터를 구축해야 합니다. 따라서 ELK 시스템을 사용하여 로그를 분석하고 처리하려면 ELK 환경 준비 및 ELK 컴포넌트 구성 사용에 대한 학습이 필수적입니다. 예를 들어 Elasticsearch에 대한 이해를 먼저 구축하고, Elasticsearch 기초를 익히고, Elasticsearch 인덱스 작업을掌握하며, Elasticsearch 클러스터를 계획하고, 오픈소스 버전의 LogStash, ElasticSearch에 대한 성능 구성 최적화 등을 수행해야 합니다.

EFK 학습 비용¶

ELK와 마찬가지로 EFK도 이러한 내용을 학습해야 합니다. 또한 Fluentd는 LogStash보다 구성이 더 유연하므로 학습 비용이 더 높아집니다. 성능 최적화는 사용 경험에 더욱 의존하게 됩니다. LogStash가 120개 이상의 grok 템플릿을 제공하는 것과 달리 Fluentd는 사용자가 문서를 참조하여 더 많은 학습을 해야 실제로 사용할 수 있습니다.

Guance 학습 비용¶

Guance의 경우 사용자는 DataKit만 환경에 배포하여 데이터를 수집하면 됩니다. 사용자가 필요한 데이터 수집 구성은 공식적으로 구성 참조 및 사용 지침이 제공됩니다(현재 200개 이상의 기술 스택 지원). 사용자는 로그 분석, 비즈니스 관측 또는 분산 추적 등을 위해 단지 Guance 플랫폼의 해당 모듈 제품 사용법을 학습하고, DataKit 수집 항목을 활성화하면 비즈니스 추적 등의 요구 사항을 충족할 수 있습니다. 오픈소스 클러스터를 구축하여 로그 분석 등을 구현하기 위해 많은 기술을 학습할 필요가 없으므로, 사용자는 오픈소스 클러스터 운영을 보장하기 위해 많은 시간을 기술 학습에 할애하는 대신 비즈니스 문제 처리에 더 많은 에너지를 쏟을 수 있습니다.

사용 경험 비교¶

제품 사용 경험에 대한 비교도 중요합니다. 동일한 기능을 구현할 때 사용자에게 어떤 다른 인상을 주는지 살펴보겠습니다.

ELK 사용 경험¶

ELK를 사용하여 로그 분석을 수행하려면 먼저 LogStash, Kafka, ElasticSearch 클러스터 및 Kibana 표시 노드를 구축해야 합니다. 다음으로 특정 컴포넌트의 데이터 수집 및 파싱을 구현하려면 기존 120개 이상의 파싱 템플릿 중에서 사용할 수 있는 것이 있는지 확인해야 합니다. 없으면 몇 번의 테스트를 거쳐야 데이터 수집 및 파싱을 구현할 수 있습니다. 수집 시 성능 소모가 너무 크거나 파싱 처리가 너무 느린 경우 디버깅은 또 다른 번거로운 과정입니다. 또한 로그 증분이 너무 많으면 ElasticSearch 쿼리 인덱스 최적화 및 클러스터의 빈번한 확장에 직면하게 됩니다. 마지막으로 특정 비즈니스를 표시하려면 Kibana의 KQL을 학습하여 데이터를 쿼리하고 표시해야 합니다. 데이터를 실시간으로 추적하고 알림을 보내려면 다른 오픈소스 컴포넌트에 의존해야 할 수도 있습니다. 사용 과정에서 요구 사항이 제기된 후 해결될 때까지 80% 이상의 시간이 오픈소스 컴포넌트의 다양한 문제를 처리하는 데 소비되며, 결국 실제 비즈니스 분석 및 최적화에 사용되는 시간은 일부에 불과합니다.

EFK 사용 경험¶

EFK를 사용하여 로그 분석을 수행하는 경우에도 ElasticSearch 클러스터 및 Kibana 표시 노드를 구축해야 합니다. Fluentd의 더 유연한 구성으로 인해 사용자는 데이터 수집 및 파싱을 성공적으로 완료하는 데 더 많은 시간이 필요할 수 있습니다. ElasticSearch 클러스터를 사용하면 ElasticSearch 인덱스 최적화 및 클러스터 확장을 피할 수 없습니다. 마지막으로 Kibana를 학습하여 데이터를 쿼리하고 표시해야 합니다. 마찬가지로 사용자는 요구 사항이 제기된 후 해결될 때까지 80% 이상의 시간이 오픈소스 컴포넌트의 다양한 문제를 처리하는 데 소비되며, 결국 실제 비즈니스 분석 및 최적화에 사용되는 시간은 일부에 불과합니다.

Guance 사용 경험¶

Guance을 사용하여 로그 분석 등의 요구 사항을 구현하는 것은 매우 사용자 친화적입니다. 첫째, Guance의 데이터 수집端 DataKit은 단일 명령만으로 설치 및 구성이 완료됩니다. 둘째, 사용자의 컴포넌트 로그 또는 데이터 수집 요구 사항에 대해 Guance은 200개 이상의 주요 기술 스택을 지원하며, 인프라, 컨테이너, 미들웨어, 데이터베이스, 메시지 큐, 애플리케이션 링크, 프론트엔드 접근, 시스템 보안, 네트워크 접근 성능 등 전방위 지원을 제공합니다. 또한 완벽한 문서 체계를 갖추고 있어 모든 사용자 요구 사항을 문서를 기반으로 충족할 수 있습니다. 수집기 DataKit에 대해 시각적 클라이언트 방식을 제공하여 사용자의 사용 어려움을 낮춥니다. 동시에 Guance 플랫폼은 많은 공식 시나리오 뷰를 제공하여 사용자가 자신의 비즈니스 상태를 더 잘 관측할 수 있도록 합니다.

Guance은 인프라, 컨테이너, 미들웨어, 데이터베이스, 메시지 큐, 애플리케이션 링크, 프론트엔드 접근, 시스템 보안, 네트워크 접근 성능의 전체 링크에 대한 관측 가능성을 구축했습니다. Guance의 표준 제품을 기반으로 사용자가 DataKit을 올바르게 구성하면 자신의 프로젝트에 대한 완전한 관측 가능성을 신속하게 구축할 수 있습니다. 또한 라인 프로토콜(Line Protocol)과 Guance의 시나리오 구축 능력을 기반으로 사용자는 관찰하려는 메트릭을 사용자 정의하여 편리하게 통합하고 추가적인 관측 가능성을 실현할 수 있습니다.

간단한 DataKit 설치¶

단일 명령만으로 DataKit 설치가 완료됩니다.

편리한 수집 항목 관리¶

DataKit 클라이언트 접근을 활성화하면 DataKit 클라이언트에서 수집 항목을 수정할 수 있습니다. 또한 많은 템플릿이 내장되어 있어 사용자는 수집하려는 콘텐츠에 따라 해당 구성을 활성화하기만 하면 데이터 수집을 완료할 수 있습니다.

풍부한 공식 컴포넌트 지원¶

DataKit에는 강력한 내장 기능이 포함되어 있습니다: 동적 grok 구문 쿼리 및 디버깅, 자체 개발 구문 DQL을 사용한 빠른 데이터 쿼리, 실시간 inputs 수집 실행 관측, 엣지 컴퓨팅 기능 및 시각적 클라이언트 방식의 구성, 수집 소스 배포 등. 또한 200개 이상의 공식 유지 관리 데이터 소스 수집 및 기술 스택 지원을 제공하며, Telefraf, Beats, Logstash, Fluentd 등 다양한 외부 데이터 수집과도 호환됩니다.

더 강력한 제품 능력¶

Guance은 인프라, 컨테이너, 미들웨어, 데이터베이스, 메시지 큐, 애플리케이션 링크, 프론트엔드 접근, 로그, 시스템 보안, 네트워크 접근 성능의 전체 링크에 대한 관측 가능성을 구축했습니다. Guance의 표준 제품을 기반으로 사용자가 DataKit을 올바르게 구성하면 자신의 프로젝트에 대한 완전한 관측 가능성을 신속하게 구축할 수 있습니다. 또한 다양한 기술 스택의 이상 탐지 라이브러리와 같은 기능을 지원하여 사용자가 복잡한 비즈니스 문제에 대해 더 많은 선택지를 가질 수 있습니다.