윈도우8, i5(CPU), 8GB(Memory), SSD(mSATA) 사용 환경에서 grok, dissect 필터를 이용한 로그 백만 개 입력 테스트를 해봤다.
grok {
match => { "message" => "%{COMMONAPACHELOG}" }
}
}
COMMONAPACHELOG는 사전 정의된 7개의 grok 패턴 조합인데, 각 패턴은 다시 다른 패턴의 조합으로 이루어진다. 처음 등장하는 IPORHOST의 경우 HOSTNAME과 IP의 조합인데, IP는 다시 IPV6와 IPV4의 조합. 그만큼 복잡하다는 얘기.
다음은 COMMONAPACHELOG 패턴에 사용된 정규표현식을 나열한 결과. 172단계의 검사 과정을 거친다.
다음은 grok 필터에 사용되는 정규표현식을 직접 만들어서 테스트한 결과. 검사 과정은 68단계.
사용자 grok 패턴
- 결과 : 230초 소요
- 사용된 필터 :
grok {
match => { "message" => "(?<client>\S+) - - .(?<timestamp>[^]]+). .(?<method>\S+) (?<uri>\S+) \S+ (?<status>\S+) (?<bytes>\S+)" }
}
match => { "message" => "(?<client>\S+) - - .(?<timestamp>[^]]+). .(?<method>\S+) (?<uri>\S+) \S+ (?<status>\S+) (?<bytes>\S+)" }
}
}
연동 대상 로그에 최적화된 사용자 grok 패턴을 사용했는데 COMMONAPACHELOG보다 많이 빠르지는 않다. 컴퓨터가 일을 잘하는 건가? 정규표현식이 일을 잘하는 건가? 다음은 정규표현식을 아예 사용하지 않는 필터 테스트 결과.
정규표현식을 사용하지 않는 dissect 필터
- 결과 : 220초 소요
- 사용된 필터 :
filter {
dissect {
mapping => { "message" => '%{clientip} %{} %{} [%{timestamp} %{+timestamp}] "%{verb} %{request} %{}" %{response} %{bytes}' }
}
mapping => { "message" => '%{clientip} %{} %{} [%{timestamp} %{+timestamp}] "%{verb} %{request} %{}" %{response} %{bytes}' }
}
}
성능 차이가 생각보다 크진 않다.
Elastic{ON}17 |
그래도 복잡한 정규표현식, 간단한 정규표현식, 정규표현식 사용 안함 순서대로 아주 정직한 테스트 결과를 보여준다.
관련 글
댓글 없음:
댓글 쓰기