logstash 필터 dissect 성능 테스트

Share
logstash 필터 dissect 성능 테스트

방화벽처럼 key-value 구조가 반복되는 로그의 필드 분류에는 kv 필터가 딱이다. 특히 구분기호로 '='을 사용하는 key-value 구조는 kv {} 구문만으로도 완벽한 테이블 구조를 만들어 줌.

sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 action = permit
sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 action = permit
sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 attack = 10.10.10.10
sip = 1.1.1.1 dip = 2.2.2.2 attack = 10.10.10.10
sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 action = permit
sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 attack = 10.10.10.10
sip = 1.1.1.1 dip = 2.2.2.2 attack = 10.10.10.10
sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 action = permit
sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 attack = 10.10.10.10
sip = 1.1.1.1 dip = 2.2.2.2 attack = 10.10.10.10

문제는 kv 필터가 내부적으로 정규표현식을 사용한다는 것. 성능 저하가 발생할 수 있다는 얘기. 이때 dissect 필터가 대안이 될 수 있다. dissect는 데이터 전체에 반영된 공통된 구조를 그대로 이용해서 원하는 부분을 잘라내는 기능을 제공하며, 로그는 보통 사람 읽기 좋으라고 띄어쓰기를 하기 때문에 '공백' 구조를 많이 활용한다. 로그 구조가 다음과 같을 때

sip = 1.1.1.1 dip = 2.2.2.2 attack = 10.10.10.10

다음 필터식을 이용하면

dissect {
 mapping => {
  "message" => "%{} = %{sip} %{} = %{dip} %{} = %{attack}"
 }
}

다음과 같은 테이블 구조를 만들 수 있다. %{} 구문은 데이터 검사만 하고, %{sip} 구문은 검사 결과를 sip 필드에 저장.

{
 "sip":"1.1.1.1"
 "dip": 2.2.2.2"
 "attack":"10.10.10.10"
}

데이터가 key-value 구조라면 더 효율적으로 테이블 구조를 만들 수도 있다. %{?same_name}구분기호%{&same_name} 구문을 사용하면 '구분기호'를 기준으로 앞에 있는 %{?same_name} 구문은 key, 뒤에 있는 %{&same_name} 구문은 value로 저장.

input {
 file {
  path => "D:/test.log"
  start_position => "beginning"
  sincedb_path => "nul"
 }
}
­
filter {
 #kv {}
­
 ruby {
  code => "event.set('field_count', event.get('message').split('=').count() - 1)"
}
­
 if [field_count] == 5 {
  dissect {
   mapping => {
    "message" => "%{?1} = %{&1} %{?2} = %{&2} %{?3} = %{&3} %{?4} = %{&4} %{?5} = %{&5}"
   }
  }
 } else {
   dissect {
    mapping => {
     "message" => "%{?1} = %{&1} %{?2} = %{&2} %{?3} = %{&3}"
   }
  }
 }
}
­
output {
 file {
  path => "d:/test-dissect.log"
 }
}

kv처럼 유연한 처리는 어렵기 때문에 ruby 필터를 이용해서 필드 개수를 파악, 들쭉날쭉 변하는 필드 개수에 대응했다. 참고로 로그스태시가 드디어 숫자를 인식한다. [field_count] == "5" 구문 안 먹더라. 버전 7부터 바뀐 건가?

I7(4코어), SSD 환경에서 kv 필터를 사용했을 때 로그 백만 개 연동에 22초 소요. 약 45,000 eps.

1
2

dissect 필터는 18초 소요. 약 55,000 eps.

3
4

몇 번 반복해본 결과 대략 2~30% 정도, 많게는 40% 까지도 성능이 향상된다.

Read more

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로 TypeSafe AI가 2026년 9월 15일에 Jev를 내놨습니다. 텍스트를 쓰지 않고 타입이 정해진 판정과 확률을 바로 내는 모델입니다. 유추카 검색에서 가장 느린 단계가 마침 텍스트가 필요 없는 판정이었습니다. 그 구간만 Jev로 갈아끼우고 일주일간 측정했습니다. 콜드

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

스위스 아미 나이프. 도구가 몇 개인지는 보면 알지만, 지금 어느 도구를 펴야 하는지는 안 적혀 있습니다. 요즘 AI 활용법을 다루는 글은 스킬 만드는 법부터 가르칩니다. 얼마 전까지는 MCP였고요. 저희 기록을 열어봤습니다. 석 달 동안 스킬 60회, 서브에이전트 42회, 브라우저 자동화 988회를 썼습니다. 안 쓴 게 아닙니다. 다만 붙인 MCP 서버는

By 김형준