Splunk Summary Index에 관하여, savedsearch 등

splunk summary index에 관하여 포스팅을 한다.
참조한 페이지는 여기 , 그리고 여기 이다.

1. Summary Index란?

Summary Index는 보통 사전 분석된 결과를 보고서로 저장하여 이를 주기적으로 확인할 때에 사용된다.

예를 들어 내가 5분동안의 사용자 유입 수, 유입 host별 평균, 표준편차 등에 대한 결과를 주기적으로 보고싶다고 하자.

그러면 이 집계 커맨드를 실행한 결과를 매번 5분마다 내가 직접 실행할 수 없다. 이럴 때 SavedSearch를 이용해 사용자 대신 데이터 집계를 해주고, 사용자가 보려는 결과만을 Summary Index에 저장하는 것이다.

2. Summary Index의 특징

1. Summary Index가 쿼리 성능에 좋은 이유

1. 당연히 우리가 요약한, 원하는 결과만을 저장하기 때문에 우리가 원했던 결과를 별도의 집계함수 없이 바로 볼 수 있다.
2. 데이터를 오래저장할 수 있다. 내가 원하는 데이터만 저장되기 때문에 공간을 덜 차지한다.
3. 가장 중요한 점은 서머리 인덱스는 실행 시간이 긴 보고서의 범위를 매번 작은 시간으로 분할해서 사용하기 때문에 장기적으로 비용이 절약된다.

2. Summary Index의 효과를 극대화 하는 방법은?

1. like, sistats, sitop, sichart, sitimechart 명령어를 사용한다.
   (Summary Index 전용 집계함수라고 생각하면 된다.)
2. collect 함수를 사용한다.

3. Summary Index를 사용하는 방법

1. 보고서 생성하기

상단 탭 → 설정 → 검색, 보고서 및 경고를 클릭한다.

이후 새 보고서를 클릭한다.

여기에 제목, 설명을 기입하고 검색에는 내가 서머리 인덱스에 주기적으로 저장하고 싶은 검색 쿼리를 입력한다.

• 참고사항
• 쿼리의 경우 일반적으로 saved search는 느리게 작동하는 변환된 검색 결과를 빠르게 보고싶을 때 사용하기 때문에 transforming 명령어로 끝나는 형태여야 한다.(ex. fields와 같은 streaming 명령어로 끝나면 안됨)

2. Config Explorer에서도 확인해보기

내가 저장한 saved search의 여러 속성을 Config Explorer에서도 변경할 수 있다.

경로는 /etc/apps/search/local/savedsearch.conf 에 가보면 내가 저장한 세이브 서치 명과 속성을 확인할 수 있다.

• 참고사항
  /etc/apps/search/default 와 /etc/apps/search/local이 있는데 이 2가지의 차이점은 뭘까?
  → default는 설치 시점에 기본 옵션으로 생성되는 것들이다. 이후, 사용자가 개인적으로 생성하는 대부분의 변경된 설정사항은 local 폴더 하위에 저장된다.

3. 내가 저장한 Saved search의 timerange는?

만약 1시에 스케줄링 되도록 지정했고, 시간 범위가 -30분이 시작 시간이라면 데이터는 0시 30분부터 1시까지의 데이터가 저장될 것이다.

이렇게 하면 30분마다 earliest ="-30m@m" 으로 설정한다. 따라서 30분 단위의 검색 결과가 빠짐없이 존재할 수 있다.

• 참고사항
• 클러스터링 등의 문제로, savedsearch가 지정된 시간에 실행되지 못하더라도 earliest, latest time 은(검색하는 데이터의 범위 시간) 내가 예약한 시간에 맞춰 실행된다.
• 또한, 지정된 시간에 실행되지 못할 때 _time 시간은 밀릴 수 있다.
  ex) 30분에 실행되기로 했던 세이브 서치가 31분에 시작되었다면, 결과로 쌓이는 데이터들의 _time 은 31분 이후에 검색이 실행되고 결과가 발생하여 인덱스에 들어가는 순간의 시간으로 인덱싱 된다.

4. Summary Index 에 저장하기(스케줄, 인덱싱)

스케줄 편집

편집 → 스케줄 편집 → 스케줄 항목에 스케줄링 되는 방식을 선택한다.
보통 크론 스케줄로 실행한다.

• 예약 우선순위
  → 스케줄링 되는 우선순위를 정하는 것 이다. 가장 높은 우선 순위를 정하면 Splunk에서 가장 먼저 스케줄링 되는 것이라고 생각하면 된다.
• 예약 창
  → 스케줄링 윈도우를 설정하는 것 이다. 만약 스케줄링 Priority가 같은 세이브 서치가 여러개 있을 때 5분 간격의 스케줄링 윈도우를 설정했다면 첫 번째 세이브 서치가 실행되고, 5분 뒤 실행되고, 그 다음 5분 뒤 실행되는 식이다.

요약 인덱싱 편집

요약 인덱싱 편집 → 요약 인덱싱의 체크박스에 체크 후 인덱스를 선택한다.

• 저장될 요약 인덱스는 저장이 가능한 인덱스에만 저장된다. indexer에 실제로 존재하고 write권한이 있는 인덱스여야 한다.
• sourcetype을 지정하고 싶어서, add fields에 sourcetype을 사용하는 경우가 있다. 기본적으로 요약 인덱싱에는 stash라는 소스타입이 지정되는데 이것을 별도의 소스타입으로 지정하게 되면 라이선스를 사용이 발생한다.(사용량을 먹는다는 의미로 알면 된다.) 그래서 보통 소스타입을 따로 가지고 싶다면, search 쿼리에 eval 로 소스타입을 생성한 후 결과에 orig_sourcetype(보통 마커필드 라고 부름) 을 활용한다.
• 추가로 이 페이지 를 참고하면 된다.

4. Summary Index 쿼리에 사용하는 명령어

1. collect

| collect index="Summary Index 명" 

쿼리마지막에 collect를 사용하면, 해당 쿼리가 Summary Index로 저장된다. 보통은 세이브 서치에 사용하지 않고, 단순 search문을 Summary Index로 넣고 싶을 때 사용한다.

2. overlap

index=Summary Index 
| oeverlap 

이렇게 하면, 해당 Summary Index에서 세이브 서치가 실행된 전체적인 시간과 시간 차이는 어떻게 되는지 언제 실행됐는지, 소스 타입은 무엇인지? 등과 같이 대략적인 정보를 볼 수 있다.

3. sistats, sirare, sitop, sitimechart
   이 명령어 들은 평소에 splunk를 사용하는 유저라면 잘 알 것 같다. Summary Index에 저장할 때 해당 집계함수를 사용하면 성능향상에 도움이 된다.

5. Summary Index에서 time 필드가 없을 때 Splunk가 사용하는 시간 정보

다음과 같은 정보를 우선순위로 사용한다.

1. _time (현재 인덱싱 되고있는 이벤트의 _time 필드)
2. earlist 시간은 summary index가 검색하는 시간 범위의 최초시간이 된다. 예를 들어 만약 Summary Index의 스케줄링이 2분마다 실행 된다면, earliest 시간은 검색이 실행되는 시간의 -2m을 한 시간이다.
3. 현재 시스템 시간 (earliest가 존재하지 않는 전체 시간의 경우)

대부분의 경우 이벤트에 _time필드가 있기 때문에 문제가 없지만, _time 필드를 포함하지 않는 경우 위의 케이스를 참고한다고 생각하면 된다.

6. Summary Index에 쿼리를 사용할 때 참고할 디자인

1. _raw 필드가 없어야 한다.
   요약 검색에 _raw 필드가 있을 경우, Splunk는 로우 데이터에 중점을 두게 되고, _time 기반의 검색을 하는 것이 어렵게 된다고 한다.

2. si* 명령어 뒤에 다른 추가 검색 연산자를 넣지 말라.
   요약 인덱스에 실행할 검색에 추가적으로 검색 연산자를 더 저장하게 된다고 한다.

3. si* 명령어를 사용한 검색 결과는 최종 결과를 반환하기 전에 수정하기 어려운 특수 형식으로 저장된다고 한다.
   즉, index=<summary> source=<saved search name> | sistats <args> 이러한 검색이 있을 때 sistats 이전에 필드를 생성하거나 수정하면 안된다고 한다.

4. sourcetype을 사용하는 경우, orig_sourcetype을 대신 사용해라.
   기본적으로 stash로 저장되기 때문에 원칙에 위배되지 않는 것이 좋겠다!

끝이다.