ML을 활용하여 Streams에서 로그 구문 분석 자동화하기

대표적인 AI 및 머신 러닝 플랫폼과 원활하게 연동하세요. Elastic의 생성형 AI 기능을 살펴보려면 무료 클라우드 체험을 시작하거나 지금 바로 내 기기에서 사용해 보세요.

최신 통합 가시성 스택에서 다양한 데이터 제공자로부터 비정형 로그를 Elasticsearch와 같은 플랫폼으로 수집하는 것은 여전히 어려운 과제입니다. 수동으로 작성된 구문 분석 규칙에 의존하면 취약한 파이프라인이 생성되어 사소한 업스트림 코드 업데이트만으로도 구문 분석 실패와 색인되지 않은 않은 데이터가 발생합니다. 이러한 취약성은 확장성 문제로 인해 더욱 악화됩니다. 동적인 마이크로서비스 환경에서는 새로운 서비스가 지속적으로 추가됨에 따라 수동 규칙 유지관리는 운영상의 악몽으로 변할 수 있습니다.

목표는 로그 구문 분석(필드 추출)과 로그 분할(소스 식별)을 모두 처리할 수 있는 자동화되고 적응형 접근 방식으로 전환하는 것이었습니다. 대규모 언어 모델(LLM)이 코드 구문과 의미론적 패턴에 대한 내재된 이해를 통해 이러한 작업을 최소한의 인간 개입으로 자동화할 수 있다고 가정했습니다.

Streams에서 이미 이 기능을 사용 가능하다는 기쁜 소식을 전해 드립니다!

데이터 세트 설명

PoC 목적으로 Loghub 로그 컬렉션을 선택했습니다. 조사를 위해 다음 주요 분야에서 대표적인 샘플을 선정했습니다.

• 분산 시스템: HDFS(Hadoop 분산 파일 시스템)와 Spark 데이터 세트를 사용했습니다. 여기에는 빅데이터 플랫폼에서 흔히 볼 수 있는 정보, 디버그, 오류 메시지가 섞여 있습니다.
• 서버 및 웹 애플리케이션: Apache 웹 서버 및 OpenSSH의 로그는 액세스, 오류 및 보안 관련 이벤트의 귀중한 소스를 제공했습니다. 이는 웹 트래픽을 모니터링하고 잠재적 위협을 탐지하는 데 매우 중요합니다.
• 운영 체제: Linux 및 Windows의 로그를 포함했습니다. 이러한 데이터 세트는 운영팀이 매일 접하는 일반적인 반정형 시스템 수준 이벤트를 나타냅니다.
• 모바일 시스템: 모바일 환경에서 발생하는 로그를 모델이 처리할 수 있는지 확인하기 위해 안드로이드 데이터 세트를 포함했습니다. 이러한 로그는 종종 상세한 내용을 담고 있으며 모바일 디바에스에서 발생하는 다양한 애플리케이션 및 시스템 수준의 활동을 기록합니다.
• 슈퍼컴퓨터: 고성능 컴퓨팅(HPC) 환경에서 성능을 테스트하기 위해 고도로 구조화된 로그와 특정 도메인 용어를 특징으로 하는 BGL (Blue Gene/L) 데이터 세트를 통합했습니다.

Loghub 컬렉션의 주요 장점은 로그가 대부분 정제되지 않고 레이블이 지정되지 않아 노이즈가 많은 실시간 프로덕션 환경을 마이크로서비스 아키텍처로 미러링한다는 점입니다.

로그 예:

또한 가장 일반적인 도메인에서 추가 로그를 수집하기 위해 일반적인 웹 애플리케이션과 데이터베이스 설정으로 Kubernetes 클러스터를 생성했습니다.

일반적인 로그 필드의 예: 타임스탬프, 로그 레벨(정보, 경고, 오류), 소스, 메시지.

LLM을 이용한 퓨샷 로그 구문 분석

첫 번째 실험은 근본적인 질문에 초점을 맞췄습니다: LLM이 핵심 필드를 안정적으로 식별하고 이를 추출하기 위한 일관된 구문 분석 규칙을 생성할 수 있는가?

모델에 원시 로그 샘플을 분석하고 정규식(Regex) 및 Grok 형식의 로그 구문 분석 규칙을 생성하도록 요청했습니다. 그 결과, 이 접근 방식은 잠재력이 많지만 구현에 상당한 어려움이 있음을 파악했습니다.

높은 신뢰도 및 상황 인식

초기 결과는 고무적이었습니다. LLM은 제공된 퓨샷 예시와 일치하는 구문 분석 규칙을 높은 신뢰도로 생성하는 뛰어난 능력을 보여주었습니다. 이 모델은 단순한 패턴 매칭 외에도 로그 소스를 정확하게 식별하고 이름을 지정할 수 있는 로그 이해 능력도 보여주었습니다(예: 상태 추적 앱, Nginx 웹 앱, Mongo 데이터베이스).

입력 샘플의 '골디락스' 딜레마

실험 결과, 입력 샘플에 대한 극도의 민감성 때문에 모델의 견고성이 상당히 부족하다는 점이 금방 드러났습니다. 모델의 성능은 프롬프트에 포함된 특정 로그 예시에 따라 크게 변동했습니다. 로그 샘플에는 충분히 다양한 로그가 포함되어야 하는 로그 유사성 문제가 있음을 확인했습니다.

• 너무 동질적인 경우(과적합): 입력 로그가 너무 유사하면 LLM은 과도하게 세부화하는 경향이 있습니다. 스택 추적의 특정 Java 클래스 이름과 같은 가변 데이터를 템플릿의 정적 부분으로 처리합니다. 이로 인해 극히 일부 로그만 다루고 사용할 수 없는 필드를 추출하는 취약한 규칙이 생성됩니다.
• 너무 이질적인 경우(혼란): 반대로 샘플에 형식상의 편차가 심하거나, 더 심각하게는 진행률 표시줄, 메모리 테이블 또는 ASCII 아트와 같은 '엉터리 로그'가 포함되면 모델은 공통분모를 찾는 데 어려움을 겪습니다. 이 경우 복잡하고 불완전한 정규식을 생성하거나 전체 줄을 단일 메시지 블롭 필드로 과도하게 일반화하는 경우가 많습니다.

컨텍스트 윈도우 제약 조건

또한 컨텍스트 윈도우 병목 현상에 직면했습니다. 입력 로그가 길거나, 이질적이거나, 추출 가능한 필드가 많을 경우, 모델의 출력 결과가 종종 저하되어 "정리되지 않은" 상태가 되거나 출력 컨텍스트 윈도우에 맞지 않을 정도로 길어졌습니다. 당연히 청킹이 이러한 문제를 해결하는 데 도움이 됩니다. 문자 기반 및 엔티티 기반 구분자를 사용하여 로그를 분할함으로써, 모델이 노이즈에 압도되지 않고 주요 필드를 추출하는 데 집중할 수 있도록 도울 수 있었습니다.

일관성 및 표준화 격차

모델이 규칙을 성공적으로 생성한 경우에도 다음과 같이 약간의 불일치가 발견되었습니다.

• 서비스 이름 지정 변형: 모델은 동일한 엔티티에 대해 서로 다른 이름을 제안합니다(예: 실행마다 소스를 'Spark', 'Apache Spark' 및 'Spark Log Analytics'로 레이블 지정).
• 필드 이름 지정의 변형: 필드 이름이 표준화되지 않았습니다(예: id , service.id , device.id). 표준화된 Elastic 필드 이름 지정을 사용하여 이름을 정규화했습니다.
• 해상도 편차: 필드 추출의 해상도는 입력 로그가 서로 얼마나 유사한지에 따라 달라집니다.

로그 형식 지문

로그 유사성 문제를 해결하기 위해 고성능 휴리스틱인 로그 형식 지문(LFF)을 도입합니다.

원시적이고 노이즈가 많은 로그를 LLM에 직접 입력하는 대신, 먼저 결정론적 변환을 적용하여 각 메시지의 기본 구조를 드러냅니다. 이 전처리 단계는 가변 데이터를 추상화하여 관련 로그를 그룹화할 수 있는 단순화된 '지문'을 생성합니다.

매핑 로직은 속도와 일관성을 보장하기 위해 다음과 같이 간단합니다.

1. 숫자 추상화: 모든 숫자 시퀀스(0-9)는 단일 '0'으로 대체됩니다.
2. 텍스트 추상화: 공백이 있는 알파벳 문자 시퀀스는 단일 ‘a’로 대체됩니다.
3. 공백 정규화: 모든 공백 시퀀스(공백, 탭, 줄바꿈)는 하나의 공백으로 축소됩니다.
4. 기호 보존: 구두점 및 특수 문자(예: :, [, ], /)는 로그 구조를 나타내는 가장 강력한 지표인 경우가 많으므로 보존됩니다.

로그 매핑 접근 방식을 소개합니다. 기본 매핑 패턴은 다음과 같습니다.

• 길이에 상관없이 0-9자리 숫자 ->'0'으로 대체.
• 모든 길이의 텍스트(공백이 있는 알파벳 문자) -> 'a'로 대체.
• 공백, 탭, 줄바꿈 -> 하나의 공간으로 축소.

이 매핑을 통해 로그를 어떻게 변환하는지에 대한 예를 살펴보겠습니다.

그 결과, 다음과 같은 로그 마스크를 얻습니다.

처음 두 로그의 지문을 주목하세요. 타임스탬프, 소스 클래스, 메시지 내용이 다르더라도 접두사(0/0/0 0:0:0 a a.a:)는 동일합니다. 이러한 구조적 정렬을 통해 이러한 로그를 동일한 클러스터에 자동으로 버킷화할 수 있습니다.

하지만 세 번째 로그는 완전히 다른 지문을 생성합니다(0-0-0...). 이를 통해 LLM을 호출하기 전에 첫 번째 그룹과 알고리즘적으로 분리할 수 있습니다.

보너스: ES|QL을 이용한 즉시 구현

Discover에서 이 쿼리를 전달하기만 하면 됩니다.

쿼리 분석:

FROM loghub: 원시 로그 데이터를 포함하는 인덱스를 대상으로 합니다.

EVAL 패턴 = …: 핵심 매핑 로직. REPLACE 함수를 연결하여 추상화(예: 숫자를 '0'으로, 텍스트를 'a'로 등)를 수행하고 결과를 '패턴' 필드에 저장합니다.

STATS [column1 =] expression1, … BY SUBSTRING(pattern, 0, 15):

이는 클러스터링 단계입니다. 패턴의 처음 15자를 공유하는 로그를 그룹화하고 그룹당 총 로그 수, 로그 데이터 소스 목록, 패턴 접두사, 3개의 로그 예시와 같은 집계 필드를 만듭니다.

SORT total_count DESC | LIMIT 100 : 가장 빈번한 상위 100개의 로그 패턴을 표시합니다

LogHub의 쿼리 결과는 아래와 같습니다.

시각화 자료에서 볼 수 있듯이, 이 'LLM 없는' 접근 방식은 높은 정확도로 로그를 분할합니다. LogHub 레이블을 기준으로 16개 데이터 소스 중 10개를 완벽하게(>90%) 클러스터링했고, 13개 소스에서는 과반수 클러스터링을 달성했습니다(>60%). 이 모든 결과는 추가적인 데이터 정제, 전처리 또는 미세 조정 없이 얻어졌습니다.

로그 형식 지문은 로그 패턴 분석과 같은 정교한 ML 솔루션에 더해 실용적이고 영향력이 큰 대안을 제공합니다. 로그 관계에 대한 즉각적인 인사이트를 제공하고 대규모 로그 클러스터를 효과적으로 관리할 수 있습니다.

• 원시적인 요소로서의 높은 활용도

ES|QL 구현 덕분에 LFF는 빠른 데이터 진단/시각화를 위한 독립형 도구로, 그리고 대용량 사용 사례를 위한 로그 분석 파이프라인의 구성 요소로 모두 사용할 수 있습니다.

• 유연성

LFF는 쉽게 사용자 정의하고 확장하여 특정 패턴(예: 16진수 및 IP 주소)을 캡처할 수 있습니다.

• 결정론적 안정성

ML 기반 클러스터링 알고리즘과 달리, LFF 로직은 간단하고 결정론적입니다. 새로 들어오는 로그는 기존 로그 클러스터에 소급하여 영향을 미치지 않습니다.

• 성능 및 mMemory

최소한의 메모리만 필요하고, 학습이나 GPU도 필요 없으므로 실시간 고처리량 환경에 적합합니다.

로그 형식 지문과 LLM 결합하기

제안된 하이브리드 아키텍처를 검증하기 위해 각 실험에는 각 데이터 소스에서 무작위로 선택한 20%의 로그 하위 집합이 포함되었습니다. 이러한 제약 조건은 로그가 배치 처리되는 실제 프로덕션 환경을 시뮬레이션한 것으로, 로그가 하나의 거대한 과거 데이터 더미로 처리되는 환경과는 다릅니다.

목표는 LFF가 효과적인 압축 레이어로 작용함을 입증하는 것이었습니다. 또한 엄선된 소규모 샘플로부터 높은 커버리지를 갖는 구문 분석 규칙을 생성하고 이를 전체 데이터 세트에 성공적으로 일반화할 수 있음을 증명하고자 했습니다.

실행 파이프라인

데이터가 LLM에 도달하기 전에 필터링, 클러스터링, 계층화된 샘플링을 적용하는 다단계 파이프라인을 구현했습니다.

1. 2단계 계층적 클러스터링

• 하위 클래스(정확히 일치): 로그는 동일한 지문을 기준으로 집계됩니다. 하나의 하위 클래스에 있는 모든 로그는 정확히 동일한 형식 구조를 공유합니다.
• 이상값 정리. 전체 로그 볼륨의 5% 미만을 차지하는 하위 클래스는 모두 삭제합니다. 이렇게 하면 LLM이 주요 신호에 집중할 수 있고 노이즈나 잘못된 로그에 의해 방해받지 않게 됩니다.
• 메타클래스(접두사 일치): 나머지 하위 클래스는 형식 지문 일치의 첫 N 문자에 의해 메타클래스로 그룹화됩니다. 이 그룹화 전략은 어휘적으로 유사한 형식을 하나의 범주로 효과적으로 분할합니다. 데이터 소스를 알 수 없는 경우 로그 구문 분석에는 N=5를, 로그 분할에는 N=15를 선택했습니다.

2. 계층화된 샘플링. 계층 구조 트리가 구축되면 LLM에 대한 로그 샘플을 구성합니다. 전략적 목표는 분산 범위를 최대화하고 토큰 사용량을 최소화하는 것입니다.

• 더 넓은 메타클래스 내의 각 유효한 하위 클래스에서 대표적인 로그를 선택합니다.
• 너무 많은 하위 클래스의 예외적인 경우를 관리하기 위해 대상 윈도우 크기에 맞게 무작위 다운샘플링을 적용합니다.

3. 규칙 생성 마지막으로, LLM에 각 메타클래스에 대해 제공된 샘플의 모든 로그에 맞는 정규식 구문 분석 규칙을 생성하도록 지시합니다. 본 PoC에서는 GPT-4o 미니 모델을 사용했습니다.

실험 결과 및 관찰

Loghub 데이터 세트에서 구문 분석 정확도 94%, 분할 정확도 91%를 달성했습니다.

위의 혼동 행렬은 로그 분할 결과를 보여줍니다. 세로축은 실제 데이터 소스를 나타내고 가로축은 예측된 데이터 소스를 나타냅니다. 히트맵 강도는 로그 볼륨에 대응하며, 밝은 타일은 더 많은 수를 나타냅니다. 대각선 정렬은 산포가 최소화된 상태에서 모델이 소스 귀속을 매우 정확하게 수행함을 보여줍니다.

성과 벤치마크 인사이트:

• 최적의 기준선: 카테고리당 30–40개 로그 샘플의 컨텍스트 윈도우가 '최적의 지점'으로 입증되었으며, 정규식과 Grok 패턴에서 모두 일관되게 강력한 구문 분을 생성했습니다.
• 입력 최소화: 정규식 패턴에 대해 카테고리당 입력 크기를 10개의 로그로 늘렸을 때 구문 분석 성능이 2%만 저하하는 것을 확인했으며, 이는 다양성 기반 샘플링이 원시 볼륨보다 더 중요하다는 점을 입증합니다.