winlog.event_data.Application 필드는 프로세스 경로와 이름 정보를 담고 있다. 해당 정보를 경로와 파일로 분리해보자.
엘라스틱 노드는 로그스태시 필터 기능을 대체하는 processor 파이프라인 기능을 제공한다. 다음은 grok processor 파이프라인을 만드는 과정. 예전엔 각 processor를 플러그인 형태로 설치해야 했었는데 이제는 기본 제공이라 편하다.
참고로 사용된 정규표현식 중 경로와 파일명의 구분자는 순수 문자 '\'를 검사하기 위해 예외처리한 '\\'인데, 이 표현식은 엘라스틱이 인식하지 못한다.
자바 정규표현식은 '\'를 '\\'로 인식한다고 하는데, 엘라스틱 노드가 내부적으로 자바 정규표현식을 사용하는 모양. 결과적으로 '\\'는 '\\\\'로 입력해야 에러가 발생하지 않는다.
다음은 생성된 grok processor 파이프라인을 사용하기 위한 winlogbeat.yml 설정.
잘 동작함.
두 개 이상의 파이프라인
내친 김에 경로 길이도 측정해보자. 로그스태시는 ruby 필터의 event API를 이용해서 필드에 대한 2차 가공이 가능했는데, processor 파이프라인은 ctx 변수(?)를 이용해서 같은 작업을 할 수 있다.
① grok processor가 proc_path 필드를 추출하고 ② script processor가 해당 필드의 길이를 측정하는 방식.
다음은 생성된 두 개의 파이프라인을 사용하기 위한 winlogbeat.yml 설정.
하지만 실행 실패! grok processor는 잘 동작하는데, script processor는 동작하지 않는다. 버그인지 뭔지 모르겠지만 'grok > script' 순으로 동작하지 않는 듯. 파이프라인을 하나로 합쳐보자.
다음은 grok과 script를 합친 파이프라인을 사용하는 winlogbeat 설정.
이제 잘 동작한다.
그런데 귀찮다. ingest pipeline을 사용하려면 엘라스틱 노드와 beat 양쪽에 관련 설정을 추가해야 하고, 저장 전 테스트도 까다롭다. 무엇보다 아직까지 로그스태시의 다양한 필터 기능을 완전히 대체하지 못한다.
관련 글
댓글 없음:
댓글 쓰기