Splunk Job Inspector에 관해

Munang·2023년 2월 22일

목록 보기

29/52

Splunk 작업 검사기에 대해 정리한다. 매번 볼 때마다 정리의 필요성을 느껴왔다.
나는 보통 custom command search를 만들어서 사용할때 에러 로깅으로만 사용해왔는데, Splunk를 쓸 수록 세이브 서치를 만들면서, 다량의 데이터를 이용해 검색하면서 이 작업 검사기의 항목을 이해하는 것이 중요하다고 느껴진다.

아무튼 정리를 하겠다. 오늘 참고한 내용은 Splunk 페이지의 글을 많이 참고했다.

1. Job Inspector - 실행 비용

1) 기간, 구성요소, 호출, 입력/ 출력 수

기간: SH 및 인덱서를 포함해 모든 단계에 걸친 실행시간을 보여준다.
구성 요소: 검색 내에서 사용되는 명령어를 모두 보여주고, 그것의 계층 구조를 나타내준다. 각 하위 구성 요소의 재생시간은 상위 구성 요소의 전체 재생 시간에 포함된다.
호출: 구성 요소가 수행된 횟수이다.
입력/ 출력 수는 각 구성 요소에 들어가고 나가는 이벤트 수 이다.

2) 명령 구성 요소

① command.<command>

검색에서 실행된 명령을 나타내는 구성요소이다. 내가 실행한 명령은 search문이 가장 오래걸렸다. 그 외 addinfo, fields는 splunk에서 디폴트 옵션으로 붙여쥬는 명령이며, 시간은 거의 소요되지 않았다.

② command.<knowledge data>

command.search.lookups: 자동 룩업을 통해 추가된 필드에 대한 구성요소이다.
command.search.kv: 검색시 적용한 필드 추출에 걸리는 시간을 확인할 수 있다.
- Splunk 커뮤니티에 보면 이 항목에 대한 시간이 너무 길다는 문의글이 많다. 내가 적용한 정규식 패턴 말고 필드가 추출되는 것이 있다면 자동 키, 값 추출 모드가 적용 되어있을 수 있으니 확인해보도록 하자. (props.conf KV_MODE)
command.search.fieldalias: props.conf에서 지정한 필드별 별칭을 처리하는 데에 소요되는 시간을 확인할 수 있다.
- 검색하다가, 필드 별칭을 설정해둔 것을 한번에 확인할 수 있는 쿼리가 있어 공유한다.
```
| rest /services/data/props/fieldaliases 
| rename title as Name, value as "Field aliases", eai:acl.app as App, eai:acl.owner as Owner 
| table Name "Field aliases" App Owner
```
command.search.tags: 태그를 가져오는데 소요된 비용을 알려준다.
command.search.typer: 이벤트 타입을 가져오는데 소요된 비용을 알려준다.

③ command.search.index*

command.search.index: tsidx 파일을 가져오는 데에 소요된 시간을 알려준다.
command.search.index.bucketcache.hit: 캐시에 있는 SmartStore 버킷의 수를 확인하는 데에 소요된 비용을 알려준다.
- SmartStore 인덱스: Amazon S3와 같은 원격 개체 저장소를 사용하여 인덱싱된 데이터를 저장하는 방법을 제공하는 인덱서 기능 이다.
command.search.index.usec_N_M: N과 M 마이크로초 사이에 지속된 IO 작업의 수를 보여준다. 예를 들어 구성 요소가 command.search.index.usec_64_512이고 315개의 호출이 있는 경우 검색에서 64~512마이크로초가 소요되는 315개의 IO 작업이 생성된다.

2) Dispatch 구성 요소

명령 구성 요소 외에 Dispatch와 관련된 비용이 있다.
검색이 시작될 때 가장 먼저 발생하는 일 중 하나는 검색이 인덱서로 전송되는 것 이다. 이 과정에서 발생되는 구성 요소들이 dispatch.* 구성요소 이다.

dispatch.startup.handoff: 모든 인덱서와 통신하고 검색 프로세스를 설정하는 데 소요된 누적 시간을 확인
dispatch.emit_prereport_files: 데이터가 검색 피어에서 돌아온 후 명령을 변환하여 로컬 파일에 쓰는 데 걸리는 시간
dispatch.fetch: 모든 피어가 데이터를 보낼 때까지 검색 헤드가 대기하는 데 걸린 시간
** 헷갈림 주의!!!
command.search와 많이 겹치지만 몇 가지 차이점이 있다. command.search에는 SH에서 실행되는 모든 비생성 검색 명령이 포함되고 dispatch.fetch에는 IDX에서 실행되는 다른 분산 스트리밍 명령이 포함된다.
eval은 IDX에서 실행되므로 dispatch.fetch에 런타임이 포함되고 command.eval에서 개별적으로 호출된다.
dispatch.stream.remote: 인덱서에서 소요한 시간과 검색 헤드에서 반환된 총 바이트 수를 표시하여 모든 작업을 수행하는 것이 인덱서인지 검색 헤드인지를 나타낸다. 바이트 수가 적을수록 검색이 더 효율적임을 나타낸다. 서로 다른 인덱서에 대해 '반환된 바이트' 간에 큰 차이가 있는 경우 데이터 균형이 좋지 않음을 나타낼 수 있다.

2. Job Inspector - 검색 작업 속성

1) Count

scanCount: 이벤트가 디스크에서 로드되고, props.conf가 적용된 후 필터링된 이벤트 수
eventCount: 이벤트에 대해 생성 검색 명령이 실행되고, 추가적인 필터가 적용된 이벤트 수
resultCount: SPL의 마지막 명령에 의해 반환된 이벤트 수
runDuraion: 처음부터 끝까지 검색의 누적시간을 나타낸다.

2) Search 쿼리문 정보

optimizedSearch: 실행된 검색에 대한 Spluk가 재구성한 쿼리문이다. 기본 제공 최적화 프로그램은 검색을 분석하고 가능한 경우 검색 구문을 재구성하여 검색 성능을 향상시킨다.
remoteSearch: 모든 검색 피어에 전송되는 검색 문자열이다.

3) 검색 관련 정보

dispatchState: 검색 상태입니다. (대기 중, 파싱, 실행 중, 중단, 완료, 내부취소, 사용자취소, BAD_INPUT_CANCEL, 그만두다, 실패, 완료)
doneProgress: 검색의 대략적인 진행률을 나타내는 0에서 1.0 사이의 숫자
eventIsStreaming: 이 검색의 이벤트가 스트리밍되고 있는지 여부를 나타낸다.
eventIsTruncated: 검색 이벤트가 저장되지 않았으므로 검색을 위해 이벤트 엔드포인트에서 사용할 수 없는지 여부를 나타낸다.
isSavedSearch: 스케줄러를 사용하는 저장된 검색 실행인지 여부를 나타낸다.
isZombie: 검색을 실행하는 프로세스가 종료되었지만 검색이 완료되지 않았음을 나타낸다.
keywords: 이 검색에 사용된 모든 긍정적인 키워드이다. 긍정 키워드는 NOT 절에 없는 키워드이다.
label: 이 검색에 대해 생성된 사용자 지정 이름이다.
eai:acl: 앱 및 사용자 수준 권한을 설명합니다. 예를 들어 앱이 전역적으로 공유되고 어떤 사용자가 검색을 실행하거나 볼 수 있는지를 나타낸다.

4) 검색 종료 후 발생하는 정보

sid: 검색 ID 번호
ttl: TTL(Time to Live) 또는 검색 작업이 완료된 후 만료되기 전의 시간

3. 로깅

로그를 남겨서 디버깅할 수 있는 방법은 크게 2가지가 있다.

1) debug 옵션 추가

기본적으로 Splunk 검색결과는 디버그 메시지를 숨겨준다. 따라서 search.log에 직접 들어가서 봐야한다. 하지만 이 옵션을 추가하면 디버스 메세지를 봄과 동시에 하위 검색을 포함하여 수행할 때에 하위 검색 정보에 관한 디버그 내용을 같이 출력해준다. 따라서 검사기에 직접들어가지 않고도 하위 검색 결과에 대한 디버그 정보를 같이 확인할 수 있다. limits.conf에 다음을 추가하면 된다.