download the book: (pdf)

Exploring Splunk검색 처리 언어(SPL) 프리미어 및 쿡북

작성: Splunk Chief Mind 'David Carasso'

Exploring Splunk

빅 데이터는 엄청난 비즈니스 가치를 가지고 있습니다. Splunk는 이러한 가치를 캐내는 데 최상의 도구입니다. Exploring Splunk는 시스템 생성 데이터의 범람 속에서 어떻게 답을 찾아가고 잘 알려져 있지 않은 패턴을 찾아내는지 보여줍니다. 이 설명서는 Splunk 사용 방법을 빨리 익히도록 시각적 프레젠테이션 스타일로 작성되었습니다. Splunk 기초 사항을 먼저 마스터한 후에 실제 사용 환경에서 일어날 수 있는 문제들을 어떻게 창의적으로 해결하고, 빅 데이터에 숨겨진 보석들을 어떻게 찾아내는지 알아봅니다.

Splunk의 Chief Mind인 David Carasso씨는 Splunk의 제3의 직원이었습니다. 검색 처리 언어(SPL), 동적 이벤트 및 소스 태깅, 자동 필드 추출, 트랜잭션 그룹화, 이벤트 어그리게이션, 타임스탬핑 등등 Splunk 코어에서 어려운 문제들을 혁신하고 시제품화하는 역할을 맡고 있습니다. 그는 Splunk를 이용한 작업과 관련하여 2개의 특허를 보유하고 있으며 캘리포니아 마린카운티에서 아내와 3명의 아이들과 살고 있습니다.

Exploring Splunk

David C

arassoC

ITO R

esearch

$25.00 US

Exploring SplunkSPL(검색 처리 언어) 입문서 및 설명서

David Carasso(Splunk의 Chief Mind) 저

Exploring Splunk (저자: David Carasso)Copyright © 2012 by Splunk Inc.

All rights reserved. 미국에서 인쇄됨

Splunk, Inc.는 내부 사용 또는 개인적인 용도로 이 책자의 항목을 복사할 수 있는 권한을 부여합니다. Splunk, Inc.의 명시적인 서면 동의 없이는 그 외의 사용 목적으로는 복사할 수 없습니다.

CITO Research 발행, 1375 Broadway, Fl3, New York, NY 10018.

편집/분석: Dan Woods, Deb Cameron카피에디터: Deb Cameron제작 편집: Deb Gabriel표지: Splunk, Inc.그래픽: Deb Gabriel

초판: 2012년 4월

만반의 주의를 기울여 이 책을 제작했으나 발행자와 저자는 오류나 생략 또는 이 책에 담긴 정보 사용에 따라 발생하는 손해에 대해 어떠한 책임도 지지 않습니다.

ISBN: 978-0-9894448-0-4; 0-9894448-0-5

면책 조항이 책은 텍스트북 및 참고 서적으로만 사용되도록 작성되었습니다. 실제 Splunk 소프트웨어 제품 사용은 이 책에 작성된 내용이 아니라 해당 소프트웨어의 사용권 계약에 따라 이루어져야 합니다. Splunk 소프트웨어 제품을 사용하는 방법에 대한 정보는 이 책이 아니라 해당 제품과 함께 제공되는 설명서를 참조하십시오.

이 책에 포함된 정보의 정확성과 적시성을 보장하기 위해 최대한의 주의를 기울였지만 Splunk는 정보의 정확성과 적시성을 보증 또는 보장하지 않으며 이 책의 정보와 관련되거나 정보 사용으로 인한 결과에 대해 어떠한 책임도 지지 않습니다. Splunk의 기능에 대한 자세한 설명은 docs.splunk.com을 참조하시기 바랍니다.

목차머리말

이 책에 대하여 i

이 책의 내용 ii

규칙 ii

감사의 말씀 iii

1부: Exploring Splunk

SPLUNK 소개

데이터 센터 복구 작업에 이용되는 Splunk 3

마케팅 부서에서 이용되는 Splunk 4

Splunk에 대한 접근 5

Splunk: 회사 및 개념 7

Splunk가 데이터센터의 머신 데이터를 관리하는 방식 8

운영 인텔리전스 9

운영 인텔리전스의 활용 11

2 데이터 가져오기

머신 데이터 기본사항 13

Splunk에서 읽을 수 있는 데이터의 유형 15

Splunk 데이터 소스 15

Splunk 다운로드, 설치 및 시작 15

인덱스를 위해 데이터 가져오기 17

Splunk의 데이터 인덱스 방식 이해 18

3 Splunk를 사용한 검색

검색 대시보드 23

SPL™: 검색 처리 언어 27

파이프 27

내포된 AND 28

상위 사용자 28

필드 - 퍼센트 28

search 명령어 29

search 명령어 사용에 대한 도움말 30

하위 검색 30

4 SPL: 검색 처리 언어

결과 정렬 33

sort 33

결과 필터링 35

where 35

dedup 36

head 38

결과 그룹화 39

transaction 39

결과 보고 41

top 41

stats 43

chart 45

timechart 47

필드 필터링, 수정 및 추가 48

fields 49

replace 50

eval 51

rex 52

lookup 53

5 데이터 강화

Splunk를 사용하여 데이터 이해하기 55

필드 식별: 퍼즐 조각 살펴보기 56

데이터를 탐색하여 데이터의 범위 이해 58

보고 및 집계 준비 60

데이터 시각화 65

시각자료 만들기 65

대시보드 만들기 67

경고 만들기 68

마법사를 통한 경고 만들기 68

관리자를 사용한 경고 조절 71

경고에 대한 작업 사용자 지정 74

경고 관리자 74

II부: 방법

6 모니터링 및 경고 방법

모니터링 방법 79

동시 사용자 모니터링 79

비활성 호스트 모니터링 80

분류된 데이터에 대한 보고 81

오늘의 상위 값을 지난 달의 상위 값과 비교 82

1시간에 10% 감소한 측정값 찾기 84

주간 결과를 차트로 작성 85

데이터의 급등 부분 식별 86

시간 기반 차트 압축 88

XML 또는 JSON 내 필드에 대한 보고 88

이벤트에서 필드 추출 89

경고 방법 90

사전 정의된 부하 조건에 걸렸을 때 이메일 경고 발송 90

웹 서버 성능이 느려질 경우 경고 발생 91

불필요한 EC2 인스턴스 종료 91

모니터링을 경고로 변환 92

7 이벤트 그룹화

소개 95

방법 97

필드 이름 통합 97

불완전한 트랜잭션 찾기 97

트랜잭션 내의 시간 계산 99

최신 이벤트 찾기 100

반복 이벤트 찾기 101

트랜잭션 간 시간 102

특정 트랜잭션 찾기 104

다른 이벤트와 가까이 있는 이벤트 찾기 107

이벤트 후의 이벤트 찾기 108

그룹 그룹화 109

8 룩업 테이블

소개 113

lookup 113

inputlookup 113

outputlookup 114

추가 정보 114

방법 114

기본 룩업 값 설정 114

역방향 룩업 사용 114

2계층 룩업 116

여러 단계 룩업 사용 116

검색 결과에서 룩업 테이블 생성 117

Appending Results to Lookup Tables 117

대용량 룩업 테이블 사용 118

룩업 값과 결과 비교 120

룩업 일치 항목 제어 122

IP 일치 122

Matching with Wildcards 123

부록 A: 머신 데이터 기본사항

애플리케이션 로그 126

웹 액세스 로그 126

웹 프록시 로그 127

통화 내역 기록(CDR) 127

클릭스트림 데이터 127

메시지 대기열 128

패킷 데이터 128

구성 파일 128

데이터베이스 감사(Audit) 로그 및 테이블 128

파일 시스템 감사(Audit) 로그 128

관리 및 로깅 API 129

OS 메트릭, 상태 및 진단 명령어 129

기타 머신 데이터 소스 129

부록 B: 대소문자 구분

부록 C: 주요 명령어

부록 D: 주요 리소스

부록 E: Splunk 빠른 참조 가이드

개념 137

개요 137

이벤트 137

Source 및 Sourcetype 138

Host 138

인덱스 138

필드 138

태그 138

Event Type 139

보고서 및 대시보드 139

앱 139

권한/사용자/역할 139

트랜잭션 139

Forwarder/인덱서 140

SPL 140

하위 검색 141

상대적 시간 수정자 141

공통 검색 명령 142

검색 최적화 142

검색 예제 143

EVAL 함수 146

공통 STATS 함수 151

정규식 152

공통적인 SPLUNK STRPTIME 함수 153

i

머리말Splunk Enterprise Software(“Splunk”)는 현재까지 경험할 수 있는 가장 강력한 데이터 검색 및 탐색 도구라고 할 수 있습니다. 이 책은 Splunk 자체뿐만 아니라 Splunk를 사용해 수행할 수 있는 작업을 소개하기 위해 작성되었습니다. 또한 Splunk를 사용해 창의적인 작업을 수행하기 위한 출발점으로 이 책을 활용하실 수도 있습니다.

시스템 관리자와 네트워크 관리자 그리고 보안 전문가가 Splunk를 사용하는 사례가 빈번하지만, 이러한 담당자들만 사용할 수 있도록 국한된 것은 아닙니다. 기업의 데이터에는 Splunk로 활용할 수 있는 엄청난 비즈니스 가치가 숨어 있습니다. 이 책은 오라일리(O'Reilly) 출판사의 일반적인 기술 관련 서적의 독자 외에도 마케팅 전문가는 물론 빅 데이터 및 운영 인텔리전스에 관심이 있는 모든 사람을 위해 디자인되었습니다.

이 책에 대하여이 책의 주요 목표는 Splunk가 무엇인지를 알고 Splunk를 사용하는 방법을 빠르게 이해할 수 있도록 도움을 주는 것입니다. 이 책에서는 이러한 목표를 달성하기 위해 Splunk SPL™(검색 처리 언어)의 가장 중요한 부분을 설명합니다. Splunk는 기술자와 비즈니스 전문가 모두에게 여러 측면에서 도움이 됩니다. Splunk를 한 번에 모두 배울 수 있다고 생각하지 마시기 바랍니다. Splunk는 간단한 도구지만 다양한 일을 할 수 있는 야전용 다용도 나이프와도 같습니다.

이제 다음과 같은 질문이 떠오르실 것입니다. '이 책이 어떻게 도움이 될까?' 간단하게 말씀드리면 이 책에서는 Spunk를 사용해 무엇을 할 수 있고, 어디에서 궁금한 내용을 찾아볼 수 있는지를 알 수 있습니다.

하지만 이미 많은 Splunk 설명서가 있지 않나요? 예 그렇습니다.

• http://docs.splunk.com에 보면 Splunk 시스템에 대한 자세한 설명과 함께 다양한 설명서가 있습니다.

• http://splunkbase.com에는 질문과 답변을 검색할 수 있는 데이터베이스가 있습니다. 하지만 이러한 정보는 Splunk에 대해 사전 지식이 있고 일반적인 문제를 해결하려는 경우에 도움이 됩니다.

이 책은 이 두 가지 수준의 설명서 사이에 속합니다. 이 책에서는 Splunk의 가장 중요한 부분에 대해 기본적으로 설명하고 해당 설명과 더불어 실무에서 접하게 되는 문제에 대한 해결책을 함께 제공합니다.

이 책의 내용1장에서는 Splunk가 무엇이고 어떻게 도움이 되는 지에 대해 설명합니다.

2장에서는 Splunk를 다운로드하고 시작하는 방법에 대해 설명합니다.

3장에서는 검색 사용자 인터페이스와 Splunk를 사용한 검색에 대해 설명합니다.

4장에서는 가장 일반적으로 사용되는 SPL 부분에 대해 설명합니다.

5장에서는 정보를 활용하여 데이터를 시각화하고 강화하는 방법에 대해 설명합니다.

6장에서는 가장 일반적인 모니터링 및 경고 방법에 대해 설명합니다.

7장에서는 이벤트 그룹화를 통해 해결할 수 있는 문제 유형에 대해 설명합니다.

8장에서는 룩업 테이블을 사용하여 일반적인 문제를 해결하는 여러 가지 방법에 대해 설명합니다.

1부(1장 - 5장)를 Splunk에 대한 속성 과정이라고 한다면 2부(6장 - 8장)는 Splunk를 사용하여 일반적이고 흥미로운 문제를 해결하고 1부에서 설명한 기능을 모두 종합해 고급 작업을 수행하는 방법을 보여줍니다. 이러한 방법들을 검토하고 따라해보면, 여러분이 겪고 있는 다양한 문제점 해결에 Splunk를 어떻게 적용할 수 있을지 아이디어를 얻을 수 있을 것입니다.

책 끝 부분의 부록에는 몇 가지 유용한 정보가 들어 있습니다. 부록 A에서는 빅 데이터의 가능성과 다양성을 파악하는 데 필요한 머신 데이터의 기본사항에 대한 개요를 제공합니다. 부록 B에서는 Splunk 검색에서 대소문자가 어떻게 구분되는지를 테이블로 보여줍니다. 부록 C에서는 Splunk를 사용한 가장 일반적인 검색 실행(Splunk를 사용하여 파악)에 대해 간략하게 설명합니다. 부록 D에서는 Splunk에 대해 보다 자세히 알아보는 데 도움이 되는 최고의 리소스를 소개합니다. 부록 E는 가장 널리 사용되는 교육용 설명서인 Splunk 참조 카드 버전으로 특별히 디자인되었습니다.

규칙이 책에서는 특정 요소를 나타내기 위해 다양한 글꼴을 사용했습니다.

• UI 요소는 굵게 표시됩니다.

• 명령어와 필드 이름은 일정한 너비로 표시됩니다.

X 메뉴에서 Y 옵션을 선택해야 하는 경우 간단하게 “X » Y를 선택합니다”라고 표시됩니다.

iii

감사의 말씀시간과 재능을 나누어주신 Splunk 여러분의 도움이 없었더라면 이 책은 세상에 나오지 못했을 것입니다. 원고 초안을 주의깊게 검토하고 훌륭하게 교정해 주신 Ledion Bitincka, Gene Hartsell, Gerald Kanapathy, Vishal Patel, Alex Raitz, Stephen Sorkin, Sophy Ting 그리고 Steve Zhang 박사님과 인터뷰 시간을 내주신 Maverick Garner에게도 감사드리며 그 밖에 많은 도움을 주신 Jessica Law, Tera Mendonca, Rachel Perkins, 및 Michael Wilde에게도 고마운 마음을 전합니다.

1부

Exploring Splunk

3

SPLUNK 소개Splunk는 머신 데이터, 즉 시스템에서 대량으로 방출하지만 거의 효과적으로 사용되지 않는 데이터를 분석하기 위한 강력한 플랫폼입니다. 머신 데이터는 기술 세계에서는 이미 중요한 가치를 가지고 있으며 비즈니스 세계에서도 그 중요성이 점차 확대되고 있습니다. (머신 데이터에 대해 자세히 알아보려면 부록 A를 참조하십시오.)

Splunk의 기능과 다양성을 빠르게 이해하는 수단으로 데이터 센터 시나리오와 마케팅 부서 시나리오를 제공합니다.

데이터 센터 복구 작업에 이용되는 Splunk수요일 오전 2시입니다. 전화 벨이 울립니다. 상사의 전화로 웹 사이트가 다운되었다고 합니다. 왜 다운되었을까요? 웹 서버, 애플리케이션, 데이터베이스 서버, 전체 디스크 또는 부하 분산기 중 무엇이 잘못되었을까요? 상사는 당장 고치라고 소리를 지릅니다. 밖에는 비가 내리고 있습니다. 어떻게 해야할지 모르겠습니다.

안심하세요. 어제 Splunk를 구축했습니다.

Splunk를 시동합니다. 한 곳에서 모든 웹 서버, 데이터베이스, 방화벽, 라우터 그리고 부하 분산기의 로그 파일은 물론 기타 모든 장치, 운영 체제 또는 관심이 있는 에플리케이션의 구성 데이터 파일을 검색할 수 있습니다. (여러 군데의 데이터센터나 클라우드 제공업체에 분산되어 있어도 문제 없습니다.)

웹 서버 트래픽의 그래프를 보면 언제 문제가 발생했는지 알 수 있습니다. 오후 5:03분에 웹 서버의 오류가 폭증했습니다. 오류가 적힌 위의 10페이지를 확인합니다. 홈 페이지에는 문제가 없습니다. 검색 페이지에도 문제가 없습니다. 아! 장바구니가 문제군요. 5:03분부터 해당 페이지에 대한 모든 요청이 오류를 일으켰습니다. 이 오류는 판매에 지장을 주고 고객을 쫓아내는 격이기 때문에 재정적 손해를 유발하며 반드시 해결해야 합니다.

장바구니는 데이터베이스에 연결된 전자상거래 서버에 의존한다는 것을 알고 있습니다. 로그를 보니 데이터베이스는 가동 중입니다. 잘되었군요. 전자상거래 서버 로그를 살펴보겠습니다. 오후 5:03분에 전자상거래 서버에서 데이터베이스 서버에 연결할 수 없다는 메시지를 보내기 시작합니다. 그런 다음 구성 파일의 변경 사항을 검색하고 누군가가 네트워크 설정을 변경했다는 것을 알아차렸습니다. 더 자세히 들여다보니 잘못 변경되었군요. 설정을 변경한 사람에게 연락하여 변경 사항을 롤백하도록 합니다. 시스템이 다시 작동하기 시작합니다.

신속하게 검색할 수 있는 중앙 인덱스로 Splunk가 모든 관련 정보를 수집하기 때문에 이 모든 작업이 채 5분도 걸리지 않았습니다.

Exploring Splunk

4

마케팅 부서에서 이용되는 Splunk대형 소매업체의 프로모션 부서에서 일하고 있습니다. 수신 트래픽 발생량을 최적화하기 위해 검색 엔진 최적화 및 제품에 대한 프로모션을 조정했습니다. 지난 주에는 데이터센터 직원이 (지난 시간, 날, 주에 해당하는 기간 동안) 회사 사이트를 찾기 위해 사용된 모든 검색어를 보여주는 새 Splunk 대시보드를 설치했습니다.

지난 몇 시간 동안 그래프를 보면 20분 전에 트래픽이 급격히 증가했다는 것을 알 수 있습니다. 회사 이름과 최신 제품에 대한 검색이 크게 증가했습니다. Splunk를 통해 최근 많이 엑세스된 URL에 대한 보고서를 조회해 본 결과, 한 연예인이 제품에 대해 트윗하고 회사 홈 페이지를 연결했다는 것을 알게 되었습니다.

가장 많은 사람이 방문한 페이지의 성능을 보여주는 다른 그래프를 확인합니다. 검색 페이지에 과부하가 걸려 느려지고 있습니다. 많은 사람이 회사 사이트를 방문했지만 원하는 제품을 찾을 수 없어서 모두 검색 기능을 사용하고 있습니다.

사이트의 콘텐츠 관리 시스템에 로그인하여 홈 페이지 중앙에 신제품에 대한 프로모션 광고를 게시합니다. 그런 다음 돌아가서 상위 페이지를 확인합니다. 검색 트래픽 감소가 시작되고 신제품 페이지에 대한 트래픽이 증가하고 이에 따라 장바구니에 대한 트래픽도 증가하기 시작합니다. 장바구니에 추가된 상위 10개 제품과 구매한 상위 10개 제품을 확인합니다. 신제품이 리스트의 가장 위에 있습니다. 홍보부에 이에 대한 후속 조치를 취하라는 메모를 보냅니다. 수신 트래픽은 이제 정확히 회사가 원하는 대로 오류 대신 판매로 전환되고 있습니다. Splunk 덕분에 예측할 수 없던 기회를 최대한 활용할 수 있게 되었습니다. 다음 단계는 해당 제품의 재고가 충분한지 확인하는 것입니다. 행복한 고민입니다.

이 두 예를 보면, Splunk를 통해서 머신 데이터에 발생하는 문제를 자세히 파악할 수 있다는 것을 알 수 있습니다. Splunk는 또한 과거 추세를 보여주고 여러 출처의 정보를 연결하며 그 밖에 수천 가지 방법으로 도움을 줍니다.

1장: Splunk 소개

5

Splunk에 대한 접근Splunk를 사용하여 질문에 답변하다 보면 작업을 세 단계로 나눌 수 있다는 것을 알 수 있습니다.

• 첫째, 질문에 답변할 수 있는 데이터를 식별합니다.

• 둘째, 식별한 데이터를 질문에 답변할 수 있는 결과로 변환합니다.

• 셋째, 답변을 보고서, 대화형 차트 또는 그래프로 표시하여 광범위한 관련자들이 이해할 수 있도록 만듭니다.

답변하고 싶은 질문부터 시작하십시오. 시스템에 왜 장애가 발생했습니까? 최근에 왜 이렇게 느려집니까? 사람들이 웹 사이트의 어느 부분에서 문제를 겪고 있습니까? Splunk에 정통하게 되면 어떤 유형의 데이터와 검색결과가 이러한 질문에 답변하는 데 도움이 되는지 보다 분명하게 알 수 있습니다. 이 책을 통해 Splunk를 완전 정복할 수 있는 과정을 속성으로 진행할 수 있습니다.

그럼 다음에는 다음과 같은 질문이 나오게 됩니다. 데이터가 문제의 해답을 제공할 수 있습니까? 종종 분석을 시작할 때는 데이터를 통해 무엇을 알 수 있는지 모릅니다. 하지만 Splunk는 데이터를 탐색하고 파악하는 강력한 도구입니다. 가장 일반적인 값이나 가장 예외적인 값을 찾을 수 있습니다. 통계를 활용하여 데이터를 요약하고, 예를 들어 레코드 시스템에 걸쳐 온라인 호텔 예약을 하는 모든 이벤트를 트랜잭션으로 그룹화할 수 있습니다. 전체 데이터 세트로 시작하는 워크플로를 생성한 후 관련이 없는 이벤트를 필터링하여 제외하고 나머지 이벤트를 분석합니다. 그런 다음 몇 가지 단계를 거쳐 질문에 답변하는 데 필요한 데이터만 남을 때까지 외부 소스로부터 일부 정보를 추가하기도 합니다. 그림 1은 기본적인 Splunk 분석 프로세스를 보여줍니다.

Exploring Splunk

6

그림 1-1. Splunk 사용

III sourcetypesyslogsyslogother-sourcesyslogsyslogsyslogother-sourcesyslogother-source<events…>

…… ERROR ……… ERROR …… WARNING …… WARNING ……… ERROR ………

…12.1.1.002…12.1.1.14012.1.1.14012.1.1.002…12.1.1.43 ……

<�elds...>…………………………

1장: Splunk 소개

7

Splunk: 회사 및 개념대부분의 사람들은 Splunk 고객들이 항상 접하게 되는 복잡하고 반복적인 문제를 해결하는 Splunk의 장점에 열광합니다. Splunk의 이야기는 2002년 공동설립자 Erik Swan과 Rob Das가 다음 도전을 찾아나섰을 때 시작되었습니다. 이미 두 개의 벤처 기업을 함께 시작한 Erik과 Rob은 새로운 벤처 아이디어를 찾으면서 자신들의 문제에 대해 다른 회사와 이야기를 나누기 시작했습니다.

Erik과 Rob은 잠재 고객들에게 다음과 같이 물었습니다. “귀사의 인프라 문제를 어떻게 해결하고 있습니까?” Erik과 Rob은 IT 문제를 해결하고 전통적인 방법으로 데이터를 검색하려는 실무자의 경험에 대해 수도 없이 들었습니다. 데이터가 너무 넓게 분포되어 있어서 한 데 모아서 분석하기 어렵다는 고충이었습니다. 모든 사람이 문제를 해결하기 위해 로그 파일을 손으로 분석하고 때로는 스크립트를 작성했습니다. 이렇게 사내에서 작성된 스크립트는 조악했으며 스크립트를 작성하고 문제 해결에 경험이 있는 사람이 회사를 떠나면서, 이후 문제를 해결하려는 모든 시도는 손가락질, 책임 전가, 스크립트 재작성으로 이어지고 IT 부서의 지원에 크게 의존할 수 밖에 없는 상황이 발생했습니다. 이 실무자들은 Splunk의 설립자들에게 인프라 문제를 해결하는 것은 어두컴컴한 동굴(데이터센터) 속을 (오래된 스크립트와 로그 관리 기술만으로) 방향 감각 없이 느릿느릿하게 기어다니는 것과 같다고 말했습니다. 요약하자면, 동굴 탐험과 같았습니다. Splunk라는 회사 이름은 이로부터 탄생했습니다.

디지털 동굴 탐험의 어려움 속에서 이들에게 유일한 대안은 다른 회사들도 유사한 문제가 있어서 해결 방법을 온라인으로 게시했는지 웹을 검색하는 것뿐이었습니다. Splunk 설립자들은 사람들이 이렇게 광범위하게 인식되고 있는 문제에 비용을 지출하고 있지만 아직 누구도 문제 해결에 성공하지 못했다는 데 놀랐습니다. Erik과 Rob은 다음과 같이 자문했습니다. “왜 IT 데이터는 Google™ 검색처럼 쉽고 직관적으로 검색할 수 없을까?”

Splunk의 첫 번째 비전은 데이터센터나 대형 컴퓨팅 또는 네트워킹 환경을 실행하고 문제를 해결하는 데 필요한 데이터를 훨씬 더 쉽게 조합하고 분석할 수 있도록 만드는 것이었습니다. Splunk의 미션은 IT 전문가가 문제 해결을 위해 자체적으로 사용하던 힘든 방식에 웹 검색의 편리함을 결합하는 것이었습니다.

Exploring Splunk

8

Erik과 Rob은 자금을 모아 2005년 LinuxWorld®에서 Splunk의 첫 번째 버전을 선보였습니다. 제품은 크게 인기를 끌었으며 무료로 다운로드할 수 있어서 즉시 널리 퍼졌습니다. 일단 다운로드되면 Splunk는 상상할 수 없는 광범위한 고객의 문제를 해결하면서 부서 간 또는 회사 사이에 퍼져나가기 시작했습니다. 사용자들은 경영진에게 Splunk 구입을 요청할 때, 이미 Splunk를 사용하여 단시간에 문제를 해결했던 경험을 가지고 있었습니다.

초기에는 IT와 데이터센터 관리자가 기술적인 문제를 해결하는 데 도움이 되는 것으로 인식되었던 Splunk는 이제 모든 종류의 비즈니스 사용자가 전통적인 데이터베이스보다 훨씬 더 포괄적이고 훨씬 덜 노동 집약적인 방법으로 데이터를 검색, 수집 및 정리할 수 있기 때문에 이들에게도 아주 유용한 플랫폼으로 성장했습니다. 그 결과 조직에서 전에 없이 새로운 비즈니스 통찰력 및 운영 인텔리전스를 보유하게 되었습니다.

Splunk가 데이터센터의 머신 데이터를 관리하는 방식Splunk가 장악한 첫 번째 장소는 당연히 머신 데이터로 넘쳐나는 데이터센터였습니다. Splunk는 시스템 관리자, 네트워크 엔지니어, 애플리케이션 관리자 사이에서 머신 데이터를 신속하게 파악하고 머신 데이터의 유용성을 높일 수 있는 엔진으로 유명세를 떨쳤습니다. 하지만 이들이 Splunk를 그렇게 좋아한 이유는 무엇일까요? 한 가지 예를 살펴보면 Splunk가 초기에 인기를 끌었던 이유를 알 수 있을 뿐만 아니라 Splunk가 비즈니스 세계에 제공하는 더 큰 가치의 중심이 되는 머신 데이터의 본질을 이해하는 데도 도움이 됩니다.

대부분의 컴퓨팅 환경에서 많은 시스템들이 서로 종속되어 있습니다. 무언가 잘못되면 모니터링 시스템에서 경고를 보냅니다. 예를 들어, 한 사이트의 주요 웹 페이지는 웹 서버, 애플리케이션 서버, 데이터베이스 서버, 파일 시스템, 부하 분산기, 라우터, 애플리케이션 가속기, 캐시 시스템 등에 종속되어 있습니다. 이들 시스템 중에 하나, 이를테면 데이터베이스에서 무언가 잘못되면 모든 수준에서 거의 동시에 경고가 울리기 시작합니다. 이러한 일이 발생하면 시스템 관리자나 애플리케이션 전문가가 근본 원인을 찾아 해결해야 합니다. 문제는 로그 파일이 여러 시스템, 때로는 서로 다른 시간대에 분산되어 있고 대부분 문제와 아무 관련이 없는 수백만 개의 항목이 포함되어 있다는 것입니다. 또한, 시스템의 일부 오류를 나타내는 관련 레코드는 모두 한 번에 나타나는 경향이 있습니다. 따라서 이러한 오류를 유발하는 문제를 찾아내는 것이 중요합니다. Splunk가 이러한 문제를 찾아내는 데 어떻게 도움이 되는지 살펴보겠습니다.

• Splunk의 가치는 다양한 위치에서 모든 데이터를 수집하여 중앙 집중식 저장소로 모으는 인덱스에서부터 시작됩니다. Splunk가 나오기 전에는 시스템 관리자가 수많은 여러 시스템에 로그인하여

1장: Splunk 소개

9

훨씬 더 성능이 떨어지는 도구를 사용하여 모든 데이터에 대한 액세스 권한을 확보해야 했습니다.

• 인덱스를 사용하여 Splunk는 모든 서버의 로그를 신속하게 검색하고 언제 문제가 발생했는지 찾아낼 수 있습니다. Splunk는 속도, 규모, 유용성을 활용하여 문제가 언제 발생했는지 훨씬 더 빠르게 확인할 수 있습니다.

• Splunk는 문제가 처음 발생한 기간을 세밀하게 조사하여 근본 원인을 파악할 수 있습니다. 그런 다음, 경고를 생성하여 미래의 문제에 대비할 수 있습니다.

Splunk는 여러 소스의 로그 파일을 인덱스하고 집계하여 한 곳에서 검색 가능하도록 만들어졌기 때문에 시스템 관리자와 전세계에서 비즈니스를 위해 기술 작업을 수행하는 사람들 사이에 유명해졌습니다. 보안 분석가는 Splunk를 사용하여 보안 취약성과 공격을 탐지합니다. 시스템 분석가는 Splunk를 사용하여 복잡한 애플리케이션에서 비효율성과 병목 현상을 찾아냅니다. 네트워크 분석가는 Splunk를 사용하여 네트워크 중단과 대역폭 병목 현상의 원인을 찾을 수 있습니다.

이제 Splunk의 몇 가지 핵심 포인트에 대해 설명하겠습니다.

• 중앙 저장소를 만드는 것이 중요합니다. Splunk의 주요 장점 중 하나는 여러 소스의 다양한 유형의 데이터를 검색 가능하도록 한 곳에 모으는 방식입니다.

• Splunk는 데이터를 문제에 대한 해답으로 바꿔 줍니다. Splunk는 데이터에 묻힌 통찰력을 찾아내는 데 도움이 됩니다.

• Splunk는 데이터의 구조와 의미를 이해하는 데 도움이 됩니다. 데이터를 제대로 이해하면 데이터 안에서 더 많은 것을 볼 수 있습니다. Splunk는 또한 확인된 내용을 파악하여 향후 조사를 보다 용이하게 하고 확인된 내용을 다른 사람과 공유하는 데도 도움이 됩니다.

• 시각화를 통해 반복 탐색의 어려움을 줄입니다. 인덱스와 검색 작업을 통해서 문제에 대한 명확한 답을 보여주는 차트나 보고서를 만들 수 있습니다. 데이터를 여러 가지 방법으로 시각화할 수 있기 때문에 더 신속하게 이해할 수 있으며 이해한 내용을 다른 사람과 공유하는 데도 도움이 됩니다.

운영 인텔리전스우리가 실행하는 거의 모든 것이 어떤 식으로든 기술의 지원을 받기 때문에 우리들 각자에 대해 수집되는 정보는 폭증하고 있습니다. 서버에 의해 기록되는 많은 이벤트는 실제로 고객 또는 파트너의 행동을 나타냅니다. Splunk의 고객들은 일찍이 웹 서버 액세스 로그를 사용하여 시스템을 진단할 뿐만 아니라 웹 사이트를 탐색하는 사람들의 행동을 보다 잘 파악할 수 있다는 것을 알았습니다.

Exploring Splunk

10

Splunk는 머신 데이터를 사용하여 비즈니스에 대한 가시성을 확보하고 IT 및 기업 전체에 대한 통찰력을 발견하는 새로운 범주의 방법과 기술인 운영 인텔리전스에 대한 인지도를 제고하기 위해 노력해 왔습니다. 운영 인텔리전스는 비즈니스 인텔리전스(BI)의 부산물이 아니라 일반적으로 BI 솔루션의 범주 내에 포함되지 않는 정보 소스에 기반을 둔 새로운 접근 방식입니다. 운영 데이터는 IT 작업을 개선하는 것 뿐만 아니라 비즈니스의 기타 부분에 대한 통찰력을 높이는 데도 유용하게 사용됩니다.

조직에서는 운영 데이터를 사용하여 다음 작업을 수행할 수 있습니다.

• 머신 데이터를 사용하여 고객을 보다 심층적으로 이해: 예를 들어, 웹 사이트의 트랜잭션을 추적하면 사람들이 무엇을 구입하는지 알 수 있습니다. 하지만 웹 서버 로그를 자세히 살펴보면 사람들이 구입하기 전에 방문한 모든 페이지를 볼 수 있으며, 아마도 훨씬 더 중요하게도, 구입하지 않은 사람들이 방문한 페이지마저도 볼 수 있습니다. (앞 부분의 신제품 검색에 대한 예가 생각나십니까?)

• 여러 소스의 관련 이벤트에서 파생된 주요 패턴 및 분석 결과를 공개: 웹 사이트, 자세한 통화 기록, 소셜 미디어 및 매장 내 소매 트랜잭션에서 소비자 행동의 지표를 추적해 보면 고객에 대해 훨씬 더 포괄적인 그림을 그릴 수 있습니다. 머신 데이터에 고객 상호작용이 많이 나타나면 나타날수록 더 많은 정보를 얻을 수 있습니다.

• 중요한 이벤트 및 이벤트 탐지 사이의 시간 단축: 머신 데이터를 실시간으로 모니터링하고 상호 연결할 수 있습니다.

• 라이브 피드와 과거 데이터를 활용하여 지금 무슨 일이 일어나고 있는지 파악하고 추세 및 변칙 상황을 확인하고 해당 정보를 기반으로 보다 정보에 입각한 결정을 내림: 예를 들어, 웹 프로모션에 의해 생성된 트래픽을 실시간으로 측정하고 이전 프로모션과 비교할 수 있습니다.

• 솔루션을 신속히 구축하고 현재 및 미래에 조직이 필요로 하는 유연성, 즉 임시 보고서를 제공하고 질문에 답변하고 새 데이터 소스를 추가할 수 있는 기능 제공: Splunk 데이터는 전통적인 대시보드에 표시되어, 사용자는 이를 이용해 이벤트를 탐색하고 새로운 질문을 계속해서 던질 수 있습니다.

1장: Splunk 소개

11

운영 인텔리전스의 활용Splunk는 다른 어떤 제품도 제공하지 못하는 작업을 수행합니다. 즉, 대량의 비정형 시계열 텍스트 형식의 머신 데이터를 효율적으로 수집하고 분석합니다. IT 부서는 보통 기술적으로 난해한 문제를 해결하기 위해 Splunk 사용을 시작하지만, 자신들의 업무 내에서도 귀중한 통찰력을 신속하게 얻습니다.

Splunk의 머신 데이터를 사용하면 복잡한 비즈니스 문제를 해결하는 데 도움이 됩니다. 다음은 몇 가지 예입니다.

• 한 운영 팀에서 고객이 접하게 되는 클라우드 기반의 애플리케이션을 구현하고 진단하기 위해 Splunk를 사용했습니다. 이들은 곧 사용자 통계를 추적하고 비즈니스 측면에서 중요한 의미를 갖는 측정 기준인 용량을 보다 효율적으로 계획할 수 있다는 것을 알았습니다.

• 웹 서버 트래픽 로그는 장바구니를 채우거나 장바구니에 저장된 품목을 취소하는 상태를 실시간으로 추적하는데 사용할 수 있습니다. 마케팅 부서에서는 이 정보를 사용하여 소비자들이 어느 부분에서 주춤하고, 어떤 유형의 구매를 단념하는지 파악하여 어떤 문제든지 즉시 해결하고 단념한 품목을 대상으로 프로모션을 진행할 수 있습니다.

• 문제 해결을 위해 Splunk를 사용하여 애플리케이션을 모니터링하는 조직에서는 고객의 전화를 고비용의 엔지니어링 리소스에 전달하는 대신 일선 지원 팀에서 직접 처리할 수 있도록 쉽게 뷰를 제공할 수 있다는 사실을 알았습니다.

• 한 주요 공기업에 여섯 가지의 모니터링과 진단 도구를 Splunk로 교체하여 소프트웨어 유지관리 비용을 절감하는 한편, NERC 및 SOX 컴플라이언스 작업을 강화할 수 있었습니다.

• 한 주요 공공 미디어 기관에서 중요한 웹 분석 결과를 파악하는 데 걸리는 시간을 몇 개월에서 몇 시간으로 단축했습니다. 또한 디지털 자산을 보다 세밀하고 정확하게 추적하여 Splunk 없이는 불가능했던 로열티 정산 및 콘텐츠 마케팅을 효율적으로 처리할 수 있었습니다.

• 한 타코 전문 레스토랑에서 POS(판매시점관리) 시스템을 Splunk에 연결해, 비즈니스 분석가가 "이맘때 이 지역에서 자정부터 새벽 2시 사이에 타코를 사는 사람들이 몇 명이나 됩니까?" 등과 같은 질문까지도 1시간 내에 답변할 수 있게 되었습니다.

Exploring Splunk

12

결과적으로 조직들은 운영 인텔리전스를 활용하여 정확한 질문을 할 수 있고, 이 질문은 실시간 데이터와 과거 데이터를 조합하여 쉽게 요약할 수 있는 대시보드와 그래픽 도구에 표시되는 비즈니스 통찰력을 제공하는 답변을 유도합니다.

머신 데이터를 "빅 데이터"라고 부르는 데는 이유가 있습니다. 방대한 머신 데이터 어디엔가는 회사의 미래를 좌우할 수 있는 중요한 데이터가 묻혀 있습니다. 이제 2장으로 이동하겠습니다. 2장에서는 데이터를 Splunk로 가져와 데이터에 숨겨져 있는 보물을 찾아내는 방법에 대해 설명합니다.

13

2 데이터 가져오기1장에서는 Splunk를 소개하고 Splunk가 어떻게 도움이 되는 지에 대해 설명했습니다. 이제 다음 단계, 데이터를 Splunk로 가져오는 단계를 시작하겠습니다.

이 장에서는 Splunk 설치 및 데이터 가져오기에 대해 설명하고 원활한 검색을 위해 데이터를 정리하는 방법에 대해서도 간략하게 설명합니다.

머신 데이터 기본사항Splunk의 미션은 머신 데이터를 사람들에게 유용하도록 만드는 것입니다. 먼저 머신 데이터에 대한 기본사항과 Splunk에서 머신 데이터를 추적하는 방법에 대해 살펴보겠습니다.

시스템(웹 서버, 부하 분산기, 비디오 게임 또는 소셜 미디어 플랫폼 등)을 구축하는 사람들은 시스템이 실행될 때 로그 파일에 작성하는 정보도 지정합니다. 이 정보(로그 파일에 포함되어 있는 머신 데이터)를 이용하면 시스템이 실행될 때(또는 실행되지 못할 때) 시스템에서 무슨 일이 일어나고 있는지 파악할 수 있습니다. 예를 들어, 다음은 가상 시계 애플리케이션의 로그 파일 출력 내용입니다.

Action: ticked s:57, m:05, h:10, d:23, mo:03, y:2011Action: ticked s:58, m:05, h:10, d:23, mo:03, y:2011Action: ticked s:59, m:05, h:10, d:23, mo:03, y:2011Action: ticked s:00, m:06, h:10, d:23, mo:03, y:2011

시계가 똑딱거릴 때마다 작업과 작업이 이루어진 시간을 기록합니다. 시계를 자세히 추적하기 위해 똑딱거림 외에 배터리 잔여 시간, 알람 설정 시간, 알람 사용 여부, 소리 사용 여부 등 시계 작동 상태를 파악하는 데 도움이 되는 기타 유용한 정보를 로그에 포함할 수도 있습니다. 위에 표시된 머신 데이터의 각 줄은 별도의 이벤트로 간주될 수 있는데, 다른 머신 데이터의 경우에는 하나의 이벤트가 여러 줄 또는 심지어 수백줄에 걸쳐 표시되는 것이 일반적입니다.

Splunk에서는 원시 머신 데이터를 이벤트라고 하는 별개의 정보 단위로 나눕니다. 단순 검색 시 Splunk는 검색어와 일치하는 이벤트를 검색합니다. 각 이벤트는 필드라고 하는 별개의 데이터 단위로 구성됩니

Exploring Splunk

14

다. 시계 데이터의 경우 second, minute, hour, day, month, 및 year 필드로 구성됩니다. 이벤트 그룹이 스프레드시트 또는 데이터베이스로 구성되어 있다고 생각하면, 그림 2-1에 표시된 것처럼 이벤트는 행이고 필드는 컬럼이 됩니다.

그림 2-1. 스프레드시트 형식의 시계 이벤트

이벤트를 키워드/값 쌍의 필드의 집합으로 생각할 수도 있습니다. 키워드/값 쌍으로 나타낼 경우 시계 이벤트는 그림 2-2와 같은 모양이 됩니다.

그림 2-2. 키워드/값 쌍의 필드로 나타낸 시계 이벤트

다음은 가장 일반적이고 유용한 유형의 실제 머신 데이터의 예입니다. 서버에서 요청된 모든 URL을 기록하는 로그 파일이 한 웹 서버에 있습니다.

웹 서버 데이터의 일부 필드는 다음과 같습니다. client IP, timestamp, http method, status, bytes, referrer, user agent

웹페이지를 한 번 방문하면 텍스트, 이미지 및 기타 리소스를 검색하기 위해 수십 개의 요청이 호출됩니다. 각 요청은 일반적으로 로그 파일에 별도의 이벤트로 기록됩니다. 그 결과는 그림 2-3과 같은 모양의 파일입니다(하이라이트는 필드를 보는 데 도움이 되도록 넣은 것으로 실제 파일에는 표시되지 않습니다.)

그림 2-3. 일반적인 웹 서버 로그

Second=58, Minute=01, Hour=14, Day=23, Year=2011Second=59, Minute=01, Hour=14, Day=23, Year=2011Second=60, Minute=01, Hour=14, Day=23, Year=2011Second=01, Minute=02, Hour=14, Day=23, Year=2011Second=02, Minute=02, Hour=14, Day=23, Year=2011

12.1.1.015 - - [01/Aug/2011:12:29:58 -0700] "GET /pages/hltabs_c.html HTTP/1.1" 200 1211 "http://webdev:2000/pages/" "Mozilla/5.0 AppleWebKit/102.1 (KHTML) Safari/102"

12.1.1.015 - - [01/Aug/2011:12:29:58 -0700] "GET /pages/joy.html HTTP/1.1" 200 0012 "http://webdev:2000/pages/" "Mozilla/5.0 AppleWebKit/102.1 (KHTML) Safari/102"

12.1.1.015 - - [01/Aug/2011:12:29:58 -0700] "GET /pages/dochomepage.html HTTP/1.1" 200 1000 "http://webdev:2000/pages/" "Mozilla/5.0 AppleWebKit/102.1 (KHTML) Safari/102"

2장: 데이터 가져오기

15

Splunk에서 읽을 수 있는 데이터의 유형머신 데이터의 가장 일반적인 특징 중 하나는 항상 데이터가 만들어진 시기 또는 데이터에 의해 설명되는 이벤트가 발생한 시기를 나타내는 정보가 포함되어 있다는 점입니다. 이러한 특징을 고려하여 Splunk의 인덱스는 이벤트를 시계열 순서로 검색할 수 있도록 최적화되어 있습니다. 원시 데이터에 명시적인 타임스탬프가 없는 경우 Splunk는 데이터의 이벤트에 대해, 이벤트가 Splunk에 의해 인덱스된 시간을 지정하거나 파일이 마지막으로 수정된 시간 또는 이전 이벤트의 타임스탬프 등 다른 근사값을 사용합니다.

그 밖에 유일한 요건은 머신 데이터는 이진 데이터가 아니라 텍스트 데이터여야 한다는 점입니다. 예를 들어, 이미지 및 사운드 파일이 일반적인 이진 데이터 파일입니다. 프로그램 중단 시 생성되는 코어 덤프와 같은 일부 유형의 이진 파일은 스택 추적과 같은 텍스트 정보로 변환할 수 있습니다. Splunk는 데이터를 인덱스하기 전에 스크립트를 호출하여 변환 작업을 실행합니다. 궁극적으로 Splunk 데이터는 인덱스하거나 검색할 수 있도록 텍스트 형태로 표시되어야 합니다.

Splunk 데이터 소스인덱싱하는 동안 Splunk는 여러 소스의 머신 데이터를 읽을 수 있습니다. 가장 일반적인 입력 소스는 다음과 같습니다.

• 파일: Splunk에서는 특정 파일 또는 디렉터리를 모니터링할 수 있습니다. 데이터가 파일에 추가되거나 새 파일이 모니터링되는 디렉터리에 추가되는 경우 Splunk는 해당 데이터를 읽습니다.

• 네트워크: Splunk는 TCP 또는 UDP 포트를 수신하고 전송되는 모든 데이터를 읽을 수 있습니다.

• 스크립트 기반 입력 정보: Splunk에서는 센서를 모니터링하는 Unix® 명령어 또는 사용자 지정 스크립트와 같이 프로그램 또는 스크립트의 머신 데이터 출력 정보를 읽을 수 있습니다.

이제 충분한 배경 지식을 갖추었으니 Splunk를 사용해 보겠습니다.

Splunk 다운로드, 설치 및 시작이 책에 설명된 내용을 따라해 보기 위해 Splunk를 설치하고 일부 머신 데이터를 추가하기를 권고드립니다. 이 책에 설명된 모든 내용은 Splunk Free를 사용하여 따라해 볼 수 있습니다(아래 참조).

이 절에서는 Splunk를 설치하고 시작하는 방법에 대해 설명합니다.

Exploring Splunk

16

Splunk 다운로드Splunk를 배우거나 중소 규모 수준의 Splunk 사용을 지원하기 위해, 다기능 Splunk를 무료로 다운로드할 수 있습니다. splunk.com 홈 페이지에서 다음 버튼을 찾을 수 있습니다.

이 버튼을 클릭하여 Windows®, Mac™, Linux® 또는 Unix를 구동 중인 컴퓨터에 Splunk를 다운로드 하십시오.

Splunk 설치Splunk 설치는 간단하기 때문에 개별적으로 설치한 것으로 간주하겠습니다. 질문이 있는 경우 Splunk 자습서(http://splunk.com/goto/book#tutorial)를 참고하십시오. 모든 것이 자세히 설명되어 있습니다.

Splunk 시작Windows에서 Splunk를 시작하려면 시작 메뉴에서 Splunk 애플리케이션을 실행합니다. 그림 2-4의 '환영' 화면이 표시되는지 확인하고 계속 읽어보십시오.

Mac OS X 또는 Unix에서 Splunk를 시작하려면 터미널 창을 엽니다. Splunk를 설치한 디렉터리로 이동하고 bin 하위 디렉터리로 이동한 후 명령 프롬프트에 다음과 같이 입력합니다.

./splunk start

Splunk가 시작되면 표시되는 정보의 맨 마지막 줄은 다음과 같습니다.The Splunk web interface is at http://your-machine-name:8000

로그인 화면의 해당 링크를 연결합니다. 사용자 이름과 암호가 없는 경우 기본 접속 정보는 각각 admin 및 changeme입니다. 로그인 후 환영 화면이 나타납니다.


17

그림 2-4. 환영 화면

환영 화면에는 데이터 추가 및 검색 앱 실행 등 새로운 Splunk 인스턴스를 사용해 수행할 수 있는 작업이 표시됩니다.

인덱스를 위해 데이터 가져오기Splunk를 배우고 탐색하는 데 있어 다음 단계는 일부 데이터를 탐색 가능하도록 인덱스에 추가하는 것입니다.

이 장에서는 일부 샘플 데이터를 사용하도록 하겠습니다. 이 데이터를 가져오는 방법은 다음 페이지에 나와 있습니다. http://splunk.com/goto/book#add_data

인덱스 프로세스에는 다음의 두 단계가 있습니다.

• Splunk 웹 사이트에서 샘플 파일 다운로드

• Splunk에 해당 파일을 인덱스하도록 요청

샘플 파일을 다운로드하려면 다음 링크를 연결하고 파일을 바탕 화면에 저장하십시오. http://splunk.com/goto/book#sample_data

Splunk에 파일을 추가하는 방법:

1. 환영 화면에서 데이터 추가를 클릭합니다.

2. 화면 하단에서 파일 및 디렉터리에서를 클릭합니다.

3. 미리보기 건너뛰기를 선택합니다.

4. 파일 업로드 및 인덱스 옆의 라디오 버튼을 클릭합니다.

5. 바탕 화면에 다운로드한 파일을 선택합니다.

6. 저장을 클릭합니다.

Exploring Splunk

18

데이터 추가가 완료되었습니다. 보이지 않는 곳에서 Splunk가 무엇을 수행하는지를 설명하겠습니다.

Splunk의 데이터 인덱스 방식 이해대부분의 조직에 있어 Splunk의 핵심적인 가치는 분석, 보고 및 경고를 위해 머신 데이터를 신속하게 검색 가능하도록 인덱스할 수 있는 고유 기능입니다. 인덱스하기 전의 데이터를 원시 데이터라고 합니다. Splunk는 데이터 자체는 수정하지 않고 데이터 내 단어에 대해 시간 기반 지도를 만들어 원시 데이터를 인덱스합니다.

Splunk에서 대량의 데이터를 검색하려면 데이터를 먼저 인덱스해야 합니다. Splunk 인덱스는 특정 키워드가 있는 페이지를 가리키는 책의 마지막 부분에 있는 인덱스와 유사한 개념입니다. Splunk에서는 "페이지"를 이벤트라고 합니다.

그림 2-5. Splunk 인덱스의 고유한 특징

Splunk에서는 머신 데이터의 스트림을 개별 이벤트로 나눕니다. 머신 데이터의 이벤트는 로그 파일의 한 줄처럼 간단할 수도 있고 수백 줄이 포함된 스택 추적처럼 복잡할 수도 있습니다.

Splunk의 모든 이벤트에는 표 2-1에 나와 있는 것처럼 4개 이상의 기본 필드가 있습니다.

인덱스 A

인덱스 B

인덱스 C

이벤트: 원시 텍스트 + source, sourcetype, host 및 _time과 같은 필드

splunk 검색 명령

검색 결과

인덱스A

결과 병합

인덱스B

인덱스C

12.1.1.140 - - [01/Aug/2009:09:37:01 -0700] "GET /home/themes/ComBeta/images/btn_login.gif

12.1.1.140 - - [01/Aug/2009:09:37:01 -0700] "GET /home/themes/ComBeta/images/btn_login.gif HTTP/1.1" 304 - "htp://webdev:2000/home/iex.php" "Mozilla/5.0

.111 111..111444000 - - [01///2200000999::00999::333777:01 -0

hthmm

1pp::////wwwee eeevvv 200 hompp::////ww eevvvv:2200eex hppp"" ""M iilllla/5l


111 111..111444000 - - [0199::00999::333777:01 -0

hm th

1wwee eeevvv 200 homw eevvvv:2200hppp"" ""M iilllla/5l


.111 111..111444000 - - [01///220000999::0 00999::333777:01 -0

hm th

1pp::////wwwee eeevvv 200 hompp::////ww eevvvv:2200eex hppp"" ""M iilllla/5l

12.1/2009/2////""""""""""GGGET eeeeettta/iiiiifff HTpppp://wpppppp:://weeex.ph

.111///220000099//

pppp:::////wwpppppp::://///weexexe


19

표 2-1. Splunk에서 항상 인덱스하는 필드

필드 질문 예

source 데이터를 어디서 가져왔습니까?

파일(/var/log/), 스크립트(myscript.bat), 네트워크 피드(UDP:514)

sourcetype 어떤 종류의 데이터입니까? access_combined, syslog

host 어느 호스트 또는 시스템에서 데이터를 가져왔습니까?

webserver01, cisco_router

_time 이벤트가 언제 발생했습니까? Sat Mar 31 02:16:57 2012

이러한 기본 필드는 원시 데이터와 함께 인덱스됩니다.

타임스탬프(_time) 필드는 Splunk 인덱서에서 타임스탬프를 사용하여 이벤트를 정렬하기 때문에 특별한데, 이를 통해 Splunk는 특정 시간 범위 내에서 이벤트를 효율적으로 검색할 수 있습니다.

3장에서는 대부분의 작업이 발생하는 Splunk의 검색 인터페이스에 대해 설명합니다.

21

3 Splunk를 사용한 검색앞서 2장에서 Splunk가 데이터를 인덱스하는 방식에 대해 살펴보았기 때문에 Splunk를 사용하여 검색할 때 어떤 일이 일어나는지 보다 쉽게 이해할 수 있을 것입니다.

물론, 검색의 목표는 필요한 항목을 정확하게 찾는 것입니다. 즉, 데이터 관련 질문에 답변할 수 있도록 대량의 데이터를 필터링, 요약, 시각화하는 것입니다. 경우에 따라 대량의 데이터를 정기적으로 탐색해야 할 수도 있습니다. 어떤 경우에는 건초더미에서 바늘을 찾는 것처럼, 시스템 중단을 초래한 하나의 이벤트를 찾아야 할 때도 있습니다.

요약 대시보드를 보면 데이터의 개요를 신속하게 확인할 수 있습니다. Splunk 환영 탭에서 검색 앱 실행을 클릭하십시오. Splunk 홈 탭에 있는 경우에는 내 앱 아래 검색을 클릭합니다. 그림 3-1에 표시된 것과 같은 요약 대시보드가 표시됩니다.

Exploring Splunk

22

그림 3-1. 검색 앱의 요약 대시보드

이 대시보드에서 다음과 같은 몇 가지 사항을 주지하십시오.

• 상단의 검색란은 비어 있으며 언제든지 검색어를 입력할 수 있습니다.

• 검색란 오른쪽의 시간 범위 선택기를 사용하면 시간 범위 조정이 가능합니다. 예를 들어 지난 15분 또는 원하는 시간 범위 내의 이벤트를 볼 수 있습니다. 실시간 스트리밍 데이터의 경우 30초에서 1시간까지 원하는 간격을 선택할 수 있습니다.

• 인덱스된 모든 데이터 패널에는 인덱스된 데이터의 누적 합계가 표시됩니다.

3장: Splunk를 사용한 검색

23

다음 세 패널에는 각 범주에서 인덱스된 가장 최근의 값 또는 일반적인 값이 표시됩니다.

• Sources 패널에는 데이터를 가져온 파일(또는 다른 소스)이 표시됩니다.

• Source type 패널에는 데이터 내 소스의 유형이 표시됩니다.

• Host 패널에는 데이터를 가져온 호스트가 표시됩니다.

이제 페이지 상단 근처의 검색 탐색 메뉴를 살펴보겠습니다.

그림 3-2. 검색 탐색 메뉴

• 요약은 현재 위치입니다

• 검색은 기본 검색 인터페이스인 검색 대시보드로 연결됩니다.

• 상태에는 Splunk 인스턴스의 상태에 대한 대시보드가 나열됩니다.

• 대시보드 및 뷰에는 대시보드와 뷰가 나열됩니다.

• 검색 및 보고서에는 저장된 검색 내용과 보고서가 나열됩니다.

다음 절에서는 검색 대시보드를 소개합니다.

검색 대시보드검색 옵션을 클릭하거나 검색 창에 검색어를 입력하면 페이지가 검색 대시보드(때로는 시간 표시줄 또는 플래시 시간 표시줄 뷰라고 함)로 전환됩니다. 검색이 시작되면 거의 즉시 결과가 표시되기 시작합니다. 예를 들어, 검색란에 별표(*)를 입력하면 기본 인덱스 내 모든 데이터가 검색되고 그림 3-3과 유사한 화면이 나타납니다.

Exploring Splunk

24

그림 3-3. 검색 대시보드

이 대시보드의 내용을 살펴보겠습니다.

• 시간 표시줄: 시간별로 검색어와 일치하는 이벤트 수를 그래픽으로 나타냅니다.

• 필드 사이드바: 관련 필드를 이벤트 수와 함께 표시합니다. 이 메뉴를 사용하면 결과에 필드를 추가할 수도 있습니다.

• 필드 검색 스위치: 자동 필드 검색 기능을 켜거나 끕니다. Splunk에서 검색을 실행하고 필드 검색 기능이 켜져 있는 경우 Splunk에서는 현재 검색에 대해 필드를 자동으로 검색하려고 시도합니다.


25

• 결과 영역: 검색에 따른 이벤트를 보여줍니다. 이벤트는 각 이벤트의 왼쪽에 표시되는 타임스탬프 순으로 정렬됩니다. 각 이벤트의 원시 텍스트 아래에는 이벤트가 값을 가지고 있는 필드 사이드바에서 선택된 모든 필드가 표시됩니다.

검색란에 검색어를 입력하기 시작하면 검색란 아래 상황별 정보가 왼쪽에는 일치하는 검색 결과, 오른쪽에는 도움말과 함께 표시됩니다.

그림 3-4. 검색란에 텍스트를 입력하면 유용한 정보가 표시됩니다.

시간 범위 선택기 아래 한 줄의 아이콘이 표시됩니다.

그림 3-5. 검색 아이콘

검색 작업 컨트롤은 검색이 실행 중인 경우에만 작동됩니다. 검색을 실행하지 않거나 검색이 완료된 경우에는 작동하지 않으며 회색으로 표시됩니다. 그러나, 완료하는 데 오랜 시간이 걸리는 검색을 실행하는 경우 이들 아이콘을 사용하여 검색 진행 상태를 제어할 수 있습니다.

• 검색을 백그라운드로 보내면 검색이 완료될 때까지 계속 실행되도록 하고 그 동안 다른 검색을 실행하거나, 창을 닫고 로그아웃할 수도 있습니다. 백그라운드로 보내기를 클릭하면 검색란이 지워지고 다른 작업을 계속할 수 있습니다. 작업이 완료되면 아직 로그인 중인 경우 화면에 알림이 표시되고, 그렇지 않는 경우 Splunk에서 이메일을 보냅니다(이메일 주소를 지정한 경우). 그 동안 또

Exploring Splunk

26

는 나중에 작업을 확인하려면 페이지 상단의 작업 링크를 클릭하십시오.

• 검색을 일시 중지하면 검색이 일시적으로 중단되며 해당 시점까지의 결과를 탐색할 수 있습니다. 검색이 일시 중지된 동안에는 아이콘이 재생 버튼으로 바뀝니다. 이 버튼을 클릭하면 검색을 일시 중지했던 시점부터 검색이 재시작됩니다.

• 검색이 완료되기 전에 검색을 종료하면 검색이 중단되지만 해당 시점까지의 결과는 그대로 남아 있어 검색 뷰에서 결과를 보고 탐색할 수 있습니다.

• 이와 대조적으로 검색을 취소하면 검색 실행이 중단되고 결과가 없어지고 화면에서 삭제됩니다.

작업 검사기 아이콘을 클릭하면 작업 검사기 페이지로 이동합니다. 이 페이지에는 검색 실행 비용, 디버그 메시지, 검색 작업 속성 등 검색에 대한 세부정보가 표시됩니다.

저장 메뉴를 사용하면 검색을 저장하거나 검색 결과를 저장하거나, 결과를 저장하여 공유할 수 있습니다. 검색을 저장한 경우에는 검색 및 보고서 메뉴에서 찾을 수 있습니다. 결과를 저장하는 경우 화면의 오른쪽 상단에 있는 작업을 클릭하여 검토할 수 있습니다.

만들기 메뉴를 사용하면 대시보드, 경고, 보고서, event types 및 예약된 검색을 만들 수 있습니다. 이에 대해서는 5장에서 자세히 설명하겠습니다.

결과 영역 왼쪽 상단쪽 아래로 이동하면 다음과 같은 아이콘이 표시됩니다.

그림 3-6. 결과 영역 아이콘

기본적으로 Splunk에서는 이벤트를 가장 최근의 이벤트부터 가장 오래된 이벤트까지 리스트 형태로 표시하지만 테이블 아이콘을 클릭하여 결과를 테이블로 표시하거나 차트 아이콘을 클릭하여 결과를 차트로 표시할 수 있습니다. 내보내기 버튼을 사용하면 검색 결과를 CSV, 원시 이벤트, XML, JSON 등 다양한 형식으로 내보낼 수 있습니다.


27

이벤트? 결과? 어떤 차이가 있습니까?기술적인 관점에서 인덱스에서 검색된 이벤트를 '이벤트'라고 합니다. 이러한 이벤트가 변환되거나 요약되어 디스크의 이벤트와 더 이상 1대1로 일치하지 않는 경우에는 '결과'라고 합니다. 예를 들어, 검색을 통해 검색된 웹 액세스 이벤트는 이벤트이지만 오늘 방문한 상위 URL은 결과입니다. 따라서, 까다롭게 구별하는 대신 두 용어를 서로 번갈아 사용하겠습니다.

SPL™: 검색 처리 언어Splunk를 사용하면 대량의 인덱스된 이벤트를 실제 문제에 대응하는데 유용한 형태로 분류할 수 있습니다.

그림 3-7은 이벤트 검색, 보고서 생성 등 일반적인 검색 패턴을 보여줍니다. 이 검색은 syslog 오류가 있는 상위 사용자들을 반환합니다.

그림 3-7. 단순 Splunk 검색이 처리되는 방식

전체 문자열sourcetype=syslog ERROR | top user | fields - percent

을 검색이라고 하며 파이프 문자(|)는 검색을 구성하는 개별 명령어를 구분합니다.

파이프파이프 뒤의 첫 번째 키워드는 검색 명령어의 이름입니다. 이 경우 명령어는 top 및 fields입니다. 어느 명령어가 인덱스에서 이벤트를 검색합니까? 파이프 문자로 시작하지 않는 모든 검색의 처음에는 search

Summarize into table of top ten users

Remove “percent” column

Final results

Events fetchedfrom disk

top user fields - percent

sourcetype = syslog ERROR | top user | fields - percent

sourcetypesyslogsyslogother-sourcesyslogsyslogsyslogother-sourcesyslogother-source<events…>

…… ERROR ……… ERROR …… WARNING …… WARNING ……… ERROR ………

…user_A…user_Auser_Auser_A…user_B…

<�elds...>…………………………

user_01user_02...user-10

2217…5

2217…5


2217…5

2217…5


2217…5

Exploring Splunk

28

라고 하는 명령어가 내포되어 있습니다. 따라서, 위 검색에는 search, top, fields 등 세 개의 검색 명령어가 있습니다.

각 명령의 결과는 다음 명령에 입력값으로 전달됩니다. bash와 같은 Linux 쉘을 사용해 본 사용자는 이런한 개념이 익숙할 것입니다.

내포된 ANDsourcetype=syslog ERROR는 search 명령어가 sourcetype이 syslog와 같으며 ERROR 단어를 포함하는 이벤트만 검색한다는 것을 나타냅니다.

상위 사용자그 다음 명령어로 쓰인 top은 지정한 필드의 가장 자주 나타나는 값을 반환합니다. 기본적으로 top은 지정된 필드의 가장 일반적인 상위 10개의 값을 내림차순으로 반환합니다. 이 경우 지정된 필드가 user이기 때문에 top 명령어는 용어 ERROR가 포함된 syslog 이벤트에 가장 자주 나타나는 사용자를 반환합니다. top의 결과는 3개의 컬럼(user, count, percent), 10개 행의 값으로 구성된 테이블입니다.

또한 top 명령어의 출력값이 파이프 뒤의 다음 명령어의 입력값이 된다는 것을 이해하는 것이 중요합니다. 즉, top 명령어는 검색 결과를 더 작은 값의 집합으로 변환하며 이 값들은 다음 명령어에 의해 추가로 처리됩니다.

필드 - 퍼센트두 번째 명령어 fields 및 – percent 인수는 Splunk에 top 명령어의 출력값에서 percent 컬럼을 제거하도록 요청합니다.

시험적 데이터 분석: Splunk를 사용한 동굴 탐험데이터에 대해 아무 것도 모른다면 어떻겠습니까? 창의성을 발휘하여 탐험하십시오. “*”를 사용하여 모든 이벤트를 검색하고 이벤트에 대해 알아볼 수 있습니다. 몇 가지 이벤트를 살펴보고, 흥미롭게 보이는 필드 몇 개를 추출하고, 해당 필드의 top 값을 가져오고, 이벤트가 어떻게 나눠지는지 확인하고, 다른 필드를 기준으로 새 필드 몇 개를 파생하고, 결과를 분류하고, 한 필드가 다른 필드에 따라 어떻게 달라지는지 확인해 볼 수 있습니다. (사전 지식이 없는 소스의 내용을 알아보는 방법은 http://splunk.com/goto/book#mining_tips를 참조하십시오.)

4장에서 검색 명령어에 대해 자세히 알아보기 전에 Splunk를 사용하는 데 있어 매우 특별한 명령어인 search 명령어 자체에 대해 살펴보겠습니다.


29

search 명령어 search 명령어는 Splunk의 강력한 도구입니다. 이 명령어는 Splunk에서 가장 간단하고 강력한 명령어입니다. 이 명령어는 가장 기본적인 명령어로, 첫 번째 파이프의 앞부분에서는 입력할 필요가 없으며, 암묵적으로 호출되어 디스크 상의 인덱스에서 이벤트를 검색합니다.

모든 검색이 Splunk 인덱스에서 데이터를 검색하는 것은 아닙니다. 예를 들어, inputcsv 명령어는 CSV 파일에서 데이터를 읽습니다. 이러한 종류의 명령어를 첫 번째 명령어로 입력하려면 명령어 앞에 파이프 문자를 놓으십시오. 예: | inputcsv myfile.csv

Search가 검색의 첫 명령어가 아닌 경우, 이전 명령의 결과 집합을 search 명령어를 이용하여 필터링할 수 있습니다. 이렇게 하려면 다른 명령어들처럼 파이프 뒤에 명시적으로 호출하십시오. 이렇게 하려면 search 명령어를 다른 명령어와 같이, 즉 파이프 문자 뒤에 명시적인 명령어 이름을 붙여 사용하십시오. 예를 들어, error | top url | search count>=2 명령은 디스크에서 error라는 단어가 포함된 이벤트를 검색하고, 상위 URL을 찾고, 한 번만 발생하는 모든 URL을 필터링합니다. 다시 말해 top 명령어가 반환하는 10개의 오류 이벤트 중 해당 URL이 두 번 이상 나타나는 이벤트만 표시합니다.

표 3-1에는 암시적인 search 명령어에 대한 암시적인 호출의 몇 가지 예와 그 결과가 나와 있습니다.

표 3-1. 암시적 search 명령어

검색 인수 결과(warn OR error) NOT fail* "warn" 또는 "error"가 포함되어 있

지만 "fail", "fails", "failed", "failure" 등은 포함되어 있지 않는 모든 이벤트를 검색합니다.

“database error” fatal disk “database error”, “fatal” 및 “disk” 등의 문구가 포함된 모든 이벤트를 검색합니다(AND가 내포되어 있습니다).

host=main_web_server delay>2 host 필드의 값이 main_web_server이고 delay 필드의 값이 2보다 큰 모든 이벤트를 검색합니다.

Exploring Splunk

30

search 명령어 사용에 대한 도움말다음은 search 명령어 사용에 유용한 몇 가지 도움말입니다. 이 도움말은 대부분의 다른 명령어에도 적용됩니다.

대소문자 구분search 명령어에 대한 키워드 인수는 대소문자를 구분하지 않지만 필드 이름의 경우에는 대소문자를 구분합니다. (대소문자 구분에 대한 자세한 내용은 부록 B를 참조하십시오.)

검색에 따옴표 사용공백, 쉼표, 파이프, 대괄호, 등호 등 구분 문자가 포함된 문구나 필드는 따옴표로 둘러싸야 합니다. 따라서 host=web09는 괜찮지만 예를 들어, 호스트 값에 공백이 있는 경우에는 host=”webserver #9”에서처럼 따옴표가 필요합니다. 또한 예약 키워드(예: AND, OR, NOT 등)를 검색하려면 따옴표를 사용하십시오.

따옴표를 검색하려면 역슬래시를 사용하여 따옴표 문자를 이스케이프 처리하십시오. Splunk changed “life itself” for me라는 문구를 검색하려면 다음과 같이 입력합니다.

“Splunk changed \”life itself\” for me”

부울 논리search 명령어에 대한 인수(키워드 및 필드)는 암시적으로 AND가 사용된 것으로 간주됩니다.

두 개 이상의 인수 중 하나만 참이면 되는 경우 OR 키워드(대문자)를 사용하여 지정할 수 있습니다. OR은 AND보다 우선 순위가 높기 때문에 OR를 사용하는 인수는 괄호로 둘러싸인 것으로 생각할 수 있습니다.

특정 단어가 포함된 이벤트를 필터링하여 제외하려면 NOT 키워드를 사용하십시오.

마지막으로, 원할 경우 명시적으로 괄호를 사용하여 더 명확하게 지정할수 있습니다. 예를 들어, x y OR z NOT w에 대한 검색은 x AND (y OR z) AND NOT w와 같습니다.

하위 검색search 명령어는 모든 명령어와 마찬가지로 검색 결과를 다른 명령어에 대한 인수로 사용되는 하위 검색으로 이용할 수 있습니다. 하위 검색은 대괄호로 둘러쌉니다. 예를 들어, 마지막 로그인 오류를 경험했던 사용자로부터 모든 syslog 이벤트를 찾으려면 다음 명령을 입력합니다.

sourcetype=syslog [search login error | return user]


31

login 및 error라는 단어가 포함된 이벤트 검색이 맨처음 찾은 user 값(예를 들어 bob)을 반환하면서 수행되고 sourcetype=syslog user=bob에 대한 검색이 이어집니다.

Splunk에 대해 더 알아보려면 4장을 통해 즉시 도움이 되는 다른 명령어들을 살펴볼 수 있습니다.

33

4 SPL: 검색 처리 언어3장에서는 SPL에서 가장 기본적인 Splunk 명령어, search에 대해 알아봤습니다. 이 장에서는 그 밖에 다른 SPL 명령어에 대해 설명합니다.

이 장에서는 SPL 명령어에 대해 기본적인 예를 들어 설명합니다. 전체 참조 설명서는 http://docs.splunk.com을 참조하십시오.

표 4-1에는 이 장에 설명된 SPL 명령어가 범주별로 요약되어 있습니다.

표 4-1. 공통 SPL 명령어

범주 설명 명령어 결과 정렬 결과를 정렬하고 (선택 사항) 결과의

수를 제한합니다.sort

결과 필터링 이벤트 또는 결과의 집합을 더 작은 결과의 집합으로 필터링합니다.

searchwherededupheadtail

결과 그룹화 패턴을 볼 수 있도록 이벤트를 그룹화합니다.

transaction

결과 보고 검색 결과를 가지고 보고를 위한 요약을 생성합니다.

top/rarestatscharttimechart

필드 필터링, 수정 및 추가

필요한 필드에 초점을 맞추기 위해 일부 필드를 필터링하여 제외(제거)하거나 결과나 이벤트를 강화하기 위해 필드를 수정 또는 추가합니다.

fieldsreplaceevalrexlookup

결과 정렬결과 정렬은 예측한 대로 sort 명령어의 영역입니다.

sortsort 명령어는 검색 결과를 지정된 필드를 기준으로 정렬합니다.

표 4-2에 몇 가지 예가 나와 있습니다.

Exploring Splunk

34

검색의 일부를 간략하게 표시표 4-2에서처럼 여러 명령어의 일부만 보여주는 경우 다음과 같이 표시합니다.

... | 즉, 이 명령어 앞에 다른 검색이 있지만 뒤에 나오는 부분에 대해 초점을 맞춘다는 의미입니다.

표 4-2. sort 명령어의 예

명령 결과… | sort 0 field1 결과를 by field1 기준으로 오름차순

으로 정렬하고 모든 결과를 반환합니다(0은 기본값인 10,000개에서 중지하지 않고 모든 이벤트를 반환한다는 것을 의미합니다).

… | sort field1,-field2 결과를 field1 기준으로 오름차순으로 정렬한 후 field2 기준으로 내림차순으로 정렬하고 최대 10,000개의 결과(기본값)를 반환합니다.

… | sort 100 –field1,+field2 결과를 field1 기준으로 내림차순으로 정렬한 후 field2 기준으로 오름차순으로 정렬하고 정렬된 처음 100개의 결과를 반환합니다.

… | sort filename… | sort num(filename)… | sort str(filename)

결과를 filename 기준으로 정렬합니다.

• 첫 번째 명령어로 Splunk는 필드 값을 정렬하는 방법을 결정합니다.

• 두 번째 명령은 Splunk에 값을 숫자순으로 정렬하도록 요청합니다.

• 세 번째 명령은 Splunk에 값을 사전순으로 정렬하도록 요청합니다.

힌트: 검색 결과의 기본 정렬 순서는 오름차순입니다. 결과의 순서를 뒤집으려면 결과를 정렬하기 위해 사용되는 필드 앞에 빼기 기호를 사용하십시오.

그림 4-1에 두 번째 예가 나와 있습니다. 가격을 기준으로 오름차순, 평가를 기준으로 내림차순으로 정렬하겠습니다. 첫 번째 결과는 사용자 평가가 가장 높고 가장 저렴한 품목입니다.

4장: SPL: 검색 처리 언어

35

...| 가격 정렬,-등급

9.999.88

22.5022.5048.88

9.999.99

48.8822.50

122334455

9.889.999.999.99

22.5022.5022.5048.8848.88

214423535

9.889.999.999.99

22.5022.5022.5048.8848.88

244153253

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

. . .

그림 4-1. sort 명령어

결과 필터링이 명령어들은 이전 명령의 검색 결과를 더 작은 결과의 집합으로 줄입니다. 다시 말해, 데이터의 뷰를 좁혀 원하는 결과만 표시합니다.

wherewhere 필터링 명령은 표현식을 평가하여 결과를 필터링합니다 평가가 성공적으로 완료되어 결과가 TRUE인 경우 결과가 유지되며, 그렇지 않은 경우 결과가 제외됩니다. 예:

source=job_listings | where salary > industry_average

이 예에서는 채용 정보를 검색하여 급여가 업계 평균 급여보다 많지 않은 결과를 제외합니다. 또한 salary 필드 또는 industry_average 필드가 누락된 이벤트를 제외합니다.

이 예에서는 두 개의 필드, salary와 industry_average를 비교합니다. 이 작업은 where 명령어를 사용해 가능합니다. 필드 값을 문자 값과 비교하는 경우 search 명령어를 사용하십시오.

source=job_listings salary>80000

Exploring Splunk

36

표 4-3. where 명령어의 예

명령 결과… | where distance/time > 100 distance 필드 값을 time 필드

값으로 나눈 값이 100보다 큰 결과를 유지합니다.

… | where like(src, “10.9.165.%”) OR cidrmatch(“10.9.165.0/25”, dst)

IP 주소와 일치하거나 지정된 서브넷에 포함되는 결과를 유지합니다.

그림 4-2에는 distance/time > 100인 명령이 예시되어 있습니다.

그림 4-2. where 명령어의 예

where 사용에 대한 도움말eval 명령어와 마찬가지로 where 명령어는 수많은 수식 평가 함수와 함께 사용할 수 있습니다(전체 리스트는 부록 E를 참조하십시오).

dedup중복된 데이터를 제거하는 일은 dedup 필터링 명령어의 역할입니다. 이 명령어는 지정된 기준과 일치하는 후속 결과를 제거합니다. 즉, 지정된 필드 값의 각각의 조합에 대해 지정된 count 만큼의 결과만 유지합니다. count가 지정되지 않은 경우에는 1로 설정되어 처음 발견된(일반적으로 가장 최근의) 결과를 반환합니다.

...| where distance/time > 100

evaluate (distance/time>100)and keep only events for which the result is TRUE

50100200300300100500

1010

532

0.52

50100200300300100500

1010

532

0.52

distance/time>100. . . . . . . . . . . . . . . . . . . FALSE. . . . . . . . . . . . . . . . . . . FALSE. . . . . . . . . . . . . . . . . . . FALSE. . . . . . . . . . . . . . . . . . . FALSE. . . . . . . . . . . . . . . . . . . .TRUE. . . . . . . . . . . . . . . . . . . .TRUE. . . . . . . . . . . . . . . . . . . .TRUE

300100500

20.5

2


37

표 4-4. dedup 명령어의 예

명령 결과dedup host 각각의 고유한 host에 대해 첫 번째

결과를 유지합니다.

dedup 3 source 각각의 고유한 host에 대해 처음 3개의 결과를 유지합니다.

dedup source sortby -delay 결과를 delay 필드를 기준으로 내림차순으로 먼저 정렬한 후 각각의 고유한 source에 대해 첫 번째 결과를 반환합니다. 이 명령은 각각의 고유한 source에 대해 지연 값이 가장 큰 결과를 효과적으로 유지합니다.

dedup 3 source,host source 및 host 값의 각각의 고유한 조합에 대해 처음 3개의 결과를 유지합니다.

dedup source keepempty=true 각각의 고유한 source에 대해 첫 번째 결과를 유지하고 source 필드가 없는 결과도 유지합니다.

그림 4-3에 dedup 3 source 명령어가 예시되어 있습니다.

그림 4-3. dedup 명령어의 예

요점• 모든 결과를 유지하지만 중복된 값을 제거하려면 keepevents 옵션

을 사용하십시오.

• 지정된 필드 값의 조합에 대해 첫 번째 발견된 결과, 일반적으로 가장 최근의 결과가 반환됩니다. 필요한 경우 정렬 순서를 변경하려면 sortby 절을 사용하십시오.

...| dedup 3 source

for events with matching “source” �eld values, remove all except the �rst three

sourcesource_Asource_Asource_Bsource_Bsource_Asource_Asource_Asource_Bsource_B

�eld2f2_value1

f2_v alue2f2_v alue3f2_v alue4f2_v alue5f2_v alue6f2_v alue7f2_v alue8f2_v alue9

<�elds. . . >. . .. . . .. . .. . .. . .. . .. . .. . .. . .

sourcesource_Asource_Asource_Bsource_Bsource_Asource_Asource_Asource_Bsource_B

�eld2f2_value1

f2_v alue2f2_v alue3f2_v alue4f2_v alue5f2_v alue6f2_v alue7f2_v alue8f2_v alue9

<�elds. . . >. . .. . . .. . .. . .. . .. . .. . .. . .. . .

sourcesource_Asource_Asource_Bsource_Bsource_Asource_B

�eld2f2_value1

f2_v alue2f2_v alue3f2_v alue4f2_v alue5f2_v alue8

<�elds. . . >. . .. . . .. . .. . .. . .. . .

Exploring Splunk

38

• 지정된 필드가 전혀 존재하지 않는 필드는 기본적으로 유지됩니다. 원할 경우 기본 동작을 재지정하려면 keepnull=<true/false> 옵션을 사용하십시오.

head head 필터링 명령어는 지정된 개수의 처음 결과를 반환합니다. head를 사용하면 원하는 수의 결과를 찾은 경우 디스크에서 이벤트 검색을 중단할 수 있습니다.

Heads 또는 Tails?head 명령어의 반대는 first가 아니라, 가장 최근 결과를 반환하는 tail 명령어입니다. 결과는 결과의 끝에서 시작하여 역순으로 반환됩니다. 처음은 일반적으로 시간 내림차순으로 표시된 이벤트의 입력 순서에 상대적입니다. 즉, 예를 들어 head 10은 최신 10개의 이벤트를 반환합니다.

표 4-5. head 명령어의 예

명령 결과… | head 5 처음 5개의 결과를 반환합니다.

… | head (action=”startup”) 값이 startup인 action 필드가 없는 이벤트에 도달할 때까지 처음 이벤트를 반환합니다.

표 4-5의 첫 번째 예 head 5가 그림 4-4에 나와 있습니다.

그림 4-4. head 명령어의 예

...| head 5

retrieve only the �rst �ve (5)

�eld1123456789

<�elds. . . >. . .. . . .. . .. . .. . .. . .. . .. . .. . .

�eld112345

<�elds. . . >. . .. . . .. . .. . .. . .


39

결과 그룹화transaction 명령어는 연관된 이벤트들을 묶어줍니다.

transactiontransaction 명령어는 다양한 제약조건을 충족하는 이벤트를 트랜젝션, 즉 여러 소스의 이벤트 집합으로 그룹화합니다. 이벤트는 모든 트랜잭션 정의 제약조건이 충족되는 경우 하나로 그룹화됩니다. 트랜잭션은 각 구성 이벤트의 원시 텍스트(_raw 필드), 최초 구성 이벤트의 타임스탬프(_time 필드), 각 구성 이벤트의 기타 모든 필드의 조합, dura-tion 및 eventcount와 같이 트랜잭션을 기술하는 몇몇 추가 필드로 구성됩니다.

표 4-6. transaction 명령어의 예

명령 결과… | transaction clientip maxpause=5s

동일한 클라이언트 IP 주소를 공유하고 5초를 초과하는 간격이나 일시중지가 없는 이벤트를 그룹화합니다.

이 명령어를 사용하면 host 필드에 대한 검색 결과에 여러 값이 존재할 수도 있습니다. 예를 들어, 여러 사람이 동일한 위치에서 서버에 액세스하는 경우 단일 IP 주소로부터의 요청들이 여러 호스트에서 나올 수 있습니다.

… | transaction clien-tip host maxspan=30s maxpause=5s

첫 번째와 마지막 이벤트 사이의 시간차가 30초를 넘지 않고, 이벤트들 사이의 간격이 5초를 넘지 않으며, 클라이언트 IP 주소와 호스트가 같은 이벤트들을 그룹화합니다.

첫 번째 예제와는 다르게, 시간 제약조건을 충족하면서 서로 다른 clientip과 host를 조합하는 결과를 얻게 됩니다. 따라서 하나의 트랜잭션 내에서는 host 또는 clien-tip 주소 값이 다른 이벤트는 없습니다.

Exploring Splunk

40

sourcetype=access* action=purchase | transaction clientip maxspan=10m maxevents=3

action=purchase 값을 갖는 웹 액세스 이벤트를 검색합니다. 이러한 이벤트는 동일한 clientip를 공유하며 각 세션의 지속 시간이 10분을 초과하지 않고 3개를 초과하는 이벤트를 포함하지 않을 경우 transaction 명령어에 의해 그룹화됩니다.

… | transaction JSES-SIONID clientip startswith=”signon” endswith=”purchase” | where duration>=1

세션 ID(JSESSIONID)가 동일하고, 동일한 IP 주소(clientip)를 가지고 있고, 첫 번째 이벤트에 “signon” 문자열이 포함되어 있고, 마지막 이벤트에 “purchase” 문자열이 포함되어 있는 이벤트를 하나로 그룹화합니다.

이 검색에서는 startswith=”signon” 인수를 사용하여 트랜잭션의 첫 번째 이벤트를 “signon” 문자열을 포함하는 이벤트로 정의합니다. endswith=”purchase” 인수는 트랜잭션의 마지막 이벤트에 대해 동일하게 작동합니다.

이 예에서는 duration 필드를 사용하여 완료 시간이 1초 미만인 트랜잭션을 필터링하여 제외하는 where 명령어로 트랜잭션을 전달합니다.

표 4-6의 두 번째 예, transaction clientip maxspan=30s maxpause=5s는 그림 4-5에 나와 있습니다.

그림 4-5. transaction 명령어의 예


41

요점모든 transaction 명령어의 인수는 선택 사항이지만 이벤트가 트랜잭션으로 그룹화되는 방식을 정의하려면 일부 제약조건을 지정해야 합니다.

Splunk에서는 여러 필드 조건으로 정의된 트랜잭션을 꼭 필드간의 AND조건(즉, field1 AND field2 AND field3) 또는 필드간의 OR조건(즉, field1 OR field2 OR field3)로 간주하지 않습니다. <fields list>의 필드 사이에 서로 연결되는 관계가 있을 경우 transaction 명령어에서는 이를 사용합니다.

예를 들어, transaction host cookie를 검색한 경우 다음과 같은 이벤트가 단일 트랜잭션으로 그룹화될 수 있습니다.

event=1 host=a

event=2 host=a cookie=b

event=3 cookie=b

처음 두 이벤트는 host=a가 공통으로 포함되어 있기 때문에 결합되며, 세 번째 이벤트는 두 번째 이벤트와 cookie=b를 공통으로 가지고 있기 때문에 결합됩니다.

transaction 명령어는 두 개의 필드를 생성합니다.

• duration: 트랜잭션 내 첫 번째와 마지막 이벤트의 타임스탬프 간의 차이.

• eventcount: 트랜잭션 내 이벤트의 수.

stats 명령어(이 절의 뒷부분에서 설명)와 transaction 명령어 모두 이벤트를 집계하는데 사용할 수 있지만 중요한 차이점이 있습니다.

• stats: 필드 값을 기준으로 그룹화된 이벤트에 대한 통계치를 계산합니다(그런 다음 이벤트를 제외합니다).

• transaction: 이벤트를 그룹화하고, 이벤트 그룹화 방식에 대한 추가 옵션을 지원하며 원시 이벤트 텍스트 및 원래 이벤트의 기타 필드 값을 유지합니다.

결과 보고이 절에서는 top, stats, chart, timechart 등과 같은 보고 명령어에 대해 설명합니다.

top필드 리스트가 주어진 상태에서 top 명령어는 가장 자주 발생하는 필드 값의 조합을 개수 및 백분율과 함께 반환합니다. by-clause를 이용하여 필드들을 지정하면, by-clause로 지정된 필드들의 그룹별로 가장 빈번한 값을 반환합니다.

Exploring Splunk

42

top의 반대는 rare입니다.top 명령어의 반대는 rare 명령어입니다. 때로는 필드의 (가장 일반적인 값 대신) 가장 드문 값을 알아야 할 수도 있습니다. rare 명령어가 정확히 이러한 기능을 합니다.

표 4-7. top 명령어의 예

명령 결과… | top 20 url 가장 일반적인 20개의 URL을 반환

합니다.

… | top 2 user by host 각 호스트에 대해 상위 2명의 user 값을 반환합니다.

… | top user, host 상위 10개(기본값)의 user-host 조합을 반환합니다.

표 4-7의 두 번째 예, top 2 user by host가 그림 4-6에 나와 있습니다.

그림 4-6. top 명령어의 예

intermediate results:identifying count &percent of “user” valuesfor each “host” value

...|

top 2 user by host

host-1host-1host-1host-1host-1host-1host-1host-2host-2host-2host-2host-2

useruser_Auser_Auser_Buser_Cuser_Cuser_Cuser_Duser_Euser_Euser_Fuser_Guser_G

<�elds. . . >. . .. . . .. . . .. . . .. . . .. . . .. . . ..

. . ... . . .. . . .. . . ... . ..

host-1host-1host-1host-1host-2host-2host-2

useruser_Auser_Buser_Cuser_Duser_Euser_Fuser_G

2131212

16.678.33

25.008.33

16.678.33

16.67

host-1host-1host-2host-2

useruser_Cuser_Auser_Euser_G

3222

25.0016.6716.6716.67


43

statsstats 명령어는 데이터세트에 대해 SQL 집계와 유사한 집계 통계를 계산합니다. 결과 테이블에는 전체 수신 결과 집합에 대한 집계를 나타내는 하나의 행이 포함되거나, 또는 지정된 by-clause의 고유한 각 값마다 하나의 행이 포함될 수 있습니다.

통계 계산을 수행할 수 있는 여러 가지의 명령어가 있습니다. stats, chart 및 timechart 명령어는 데이터에 대해 동일한 통계 계산을 수행하지만 약간 다른 결과 집합을 반환하기 때문에 필요에 따라 더 쉽게 결과를 활용할 수 있습니다.

• stats stats 명령어는 group-by 필드 값들의 조합 별로 각 행이 표시된 결과 테이블을 반환합니다.

• chart 명령어의 경우에도 지정된 임의의 필드들이 행으로 표시되는 위와 동일한 결과 테이블을 반환합니다.

• timechart 명령어도 테이블 형태의 동일한 결과를 반환하지만 각 행이 내부 필드인 _time으로 설정되어 시간 범위에 따라 결과를 차트로 표시할 수 있습니다.

표 4-8에는 stats 명령어를 사용하는 몇 가지 예가 나와 있습니다.

“as”의 의미참고: 표 4-14의 일부 명령어에서와 같이 키워드 as 사용. as는 필드의 이름을 바꾸기 위해 사용됩니다. 예를 들어, sum(price) as “Revenue”는 모든 price 필드를 합한 후 결과 컬럼의 이름을 “Revenue”로 지정한다는 의미입니다.

표 4-8. stats 명령어의 예

명령 결과… | stats dc(host) 고유한 host 값의 개수를 반환합니

다.

… | stats avg(kbps) by host 각 호스트의 평균 전송율을 반환합니다.

… | stats count(eval(method=”GET”)) as GET, count(eval(method=”POST”)) as POST by host

각 웹 서버(host)에 대해 서로 다른 요청 유형의 수를 반환합니다. 결과 테이블에는 각 호스트에 대한 행과 GET 및 POST 요청 방법 개수에 대한 컬럼이 포함됩니다.

... | top limit=100 referer_domain | stats sum(count) as total

referer_domain의 상위 100개 값에서 총 히트 수를 반환합니다.

Exploring Splunk

44

… | stats count, max(Magnitude), min(Magnitude), range(Magnitude), avg(Magnitude) by Region

USGS 지진 데이터를 사용하여 각 Region에 대한 지진 발생 수와 추가 통계치를 반환합니다.

… | stats values(product_type) as Type, values(product_name) as Name, sum(price) as “Rev-enue” by product_id | re-name product_id as “Prod-uct ID” | eval Revenue=”$ “.tostring(Revenue,”commas”)

매장에서 판매된 각 product_id에 대해 Type, Name 및 Revenue 컬럼이 포함된 테이블을 반환합니다. 또한 Revenue의 서식을 $123,456으로 지정합니다.

호스트당 GET 및 POST 요청 개수를 검색하는 표 4-8의 세 번째 예는 그림 4-7에 나와 있습니다.

그림 4-7. stats 명령어의 예

표 4-9에는 stats 명령어와 함께 사용할 수 있는 통계 함수가 나열되어 있습니다. (이 함수들은 이후에 설명하는 chart 및 timechart 명령어에도 사용할 수 있습니다.)

표 4-9. stats 통계 함수

수학적 계산avg(X) 필드 X 값의 평균을 반환합니다. mean(X) 참조.

count(X) 필드 X의 발생횟수를 반환합니다. 일치하는 필드 값을 나타내기 위해 X 인수의 서식을 eval(field="value")와 같은 표현식으로 지정합니다.

dc(X) 필드 X의 개별 값의 개수를 반환합니다.

max(X) 필드 X의 최대값을 반환합니다. 값이 숫자가 아닌 경우에는 최대값이 사전 순서에 따라 결정됩니다.

median(X) 필드 X의 중앙값을 반환합니다.

min(X) 필드 X의 최소값을 반환합니다. 값이 숫자가 아닌 경우에는 최소값이 사전 순서에 따라 결정됩니다.

mode(X) 필드 X의 최빈값을 반환합니다.


45

perc<percent-num>(X)

필드 X의 <percent-num>번째 값을 반환합니다. 예를 들어 perc5(total)는 total 필드의 5백분위수를 반환합니다.

range(X) 필드 X의 최대값과 최소값 사이의 차이를 반환합니다(값이 숫자인 경우).

stdev(X) 필드 X의 표본표준편차를 반환합니다. 필드 이름을 지정할 때 와일드카드를 사용할 수 있습니다. 예를 들어 "*delay"는 "delay"와 "xdelay" 둘 모두에 일치합니다.

sum(X) 필드 X의 값의 합을 반환합니다.

var(X) 필드 X의 표본 분산을 반환합니다.

값 선택first(X) 필드 X의 첫 번째 값을 반환합니다. last(X)의 반대입

니다.

last(X) 필드 X의 마지막 값을 반환합니다. first(X)의 반대입니다. 일반적으로 필드의 마지막 값은 연대순으로 가장 오래된 값입니다.

list(X) 필드 X의 모든 값의 리스트를 다중값 항목으로 반환합니다. 값의 순서는 입력 이벤트의 순서와 일치합니다.

values(X) 사전 순으로 정렬된 필드 X의 모든 개별 값의 리스트를 (다중값 항목으로) 반환합니다.

timechart 전용(chart나 stats에는 해당되지 않음)per_day(X) 하루당 필드 X의 비율을 반환합니다.

per_hour(X) 시간당 필드 X의 비율을 반환합니다.

per_minute(X) 분당 필드 X의 비율을 반환합니다.

per_second(X) 초당 필드 X의 비율을 반환합니다.

참고: timechart 전용 범주의 함수를 제외한 모든 함수는 chart, stats 및 timechart 명령어에 적용됩니다.

chartchart 명령어는 차트에 사용할 수 있도록 테이블 형식의 데이터 결과를 생성합니다. over 또는 by를 사용하여 x축 변수를 지정합니다.

표 4-10에는 chart 명령어를 사용하는 몇 가지 예가 나와 있습니다. 자세한 실제 시나리오는 6장을 참조하십시오.

Exploring Splunk

46

표 4-10. chart 명령어의 예

명령 결과… | chart max(delay) over host 각 host 값에 대해 max(delay)를

반환합니다.

… | chart max(delay) by size bins=10

size별로 최대 delay를 차트로 표시합니다. 여기서 size는 최대 10개의 같은 크기 버킷으로 분할됩니다.

… | chart eval(avg(size)/max(delay)) as ratio by host user

각 개별 host 및 user 쌍에 대해 평균 size 대 최대 delay의 비율을 차트로 표시합니다.

... | chart dc(clientip) over date_hour by category_id usenull=f

시간당 고유한 clientip 값의 수를 범주별로 차트로 표시합니다. usenull=f은 값이 없는 필드를 제외합니다.

… | chart count over Magnitude by Region useother=f

지진의 수를 Magnitude 및 Region별로 차트로 표시합니다. 드문 Re-gions에 대해 "other" 값을 출력하지 않으려면 useother=f 인수를 사용하십시오.

… | chart count(eval(method=”GET”)) as GET, count(eval(method=”POST”)) as POST by host

각 웹 서버(host)에 대해 발생한 GET 및 POST 페이지 요청의 수를 차트로 표시합니다.

그림 4-8(테이블 형식의 결과) 및 4-9(로그 눈금의 막대 차트)는 표 4-10의 마지막 예의 실행 결과를 보여줍니다.

그림 4-8. chart 명령어의 예 - 테이블 형식의 결과


47

그림 4-9. chart 명령어의 예 - 보고서 작성기 형식의 차트

timechart timechart 명령어는 시간을 x축으로 하여 필드에 적용된 통계 집계에 대한 차트를 만듭니다.

표 4-11에는 timechart 명령어를 사용하는 몇 가지 예가 나와 있습니다. 6장에 이 명령어를 사용하는 예가 자세히 나와 있습니다.

표 4-11. timechart 명령어의 예

명령 결과… | timechart span=1m avg(CPU) by host

각 호스트의 분당 평균 CPU 사용량의 평균값을 차트로 표시합니다.

… | timechart span=1d count by product-type

각 제품 유형별 일일 구매 횟수를 차트로 표시합니다. span=1d 인수는 주간 구매 횟수를 일별 청크에 넣습니다.

…| timechart avg(cpu_seconds) by host | outlier

host별 평균 cpu_seconds를 차트로 표시하고 시간 차트의 y축을 왜곡하는 이상값을 제거합니다.

…| timechart per_hour(price) by product_name

어제 판매된 제품의 시간별 수익을 차트로 표시합니다. per_hour() 함수는 각 항목 (product_name)의 가격 필드의 값을 합하고 그 합을 각 버킷의 시간 범위에 따라 적절히 조정합니다.

Exploring Splunk

48

… | timechart count(eval(method=”GET”)) as GET, count(eval(method=”POST”)) as POST

시간별 페이지 요청의 수를 차트로 표시합니다. count() 함수 및 eval 서로 다른 페이지 요청 방식인 GET 및 POST의 개수를 세기 위해 사용됩니다.

… | timechart per_hour(eval(method=”GET”)) as Views, per_hour(eval(action=”purchase”)) as Purchases

전자상거래 웹 사이트의 경우 시간당(per_hour) 제품을 본 횟수와 구매 횟수를 차트로 표시하면, 제품을 검색하고 나서 구매로 이어지지 않은 횟수를 알 수 있습니다.

표 4-11에서 제품 이름별 시간당 수익을 차트로 표시하는 네 번째 예는 그림 4-10과 4-11에 나와 있습니다.

그림 4-10. timechart 명령어의 예 - 테이블 형식의 결과

그림 4-11. timechart 명령어의 예 - 서식이 지정된 시간 차트

필드 필터링, 수정 및 추가이 명령어들은 검색 결과에서 원하는 필드만을 추려내는 데 도움이 됩니다. fields 명령어를 사용하여 일부 필드를 제거하여 결과를 단순화할 수도 있습니다. replace 명령어를 사용하여 필드 값을 사용자가 더 읽


49

기 쉽도록 만들 수 있습니다. 또는 eval, rex 및 lookup과 같은 명령어를 이용하여 새 필드를 추가할 수도 있습니다.

• eval 명령어는 다른 필드간의 산술 계산이나 문자열의 연결, 또는 부울 논리 연산을 통해 새 필드의 값을 계산합니다.

• rex 명령어는 정규식을 사용해 다른 필드에서 패턴이 있는 데이터를 추출하여 새 필드를 만드는데 사용할 수 있습니다.

• lookup 명령어는 이벤트의 값을 기준으로 룩업 테이블을 참조하고, 룩업 테이블에서 일치하는 행의 필드를 해당 이벤트에 추가하는 방식으로 필드를 추가합니다.

이 명령어들은 새 필드를 만들기 위해 사용하거나 기존 필드의 값을 덮어쓰기 위해 사용할 수 있습니다. 이는 사용자의 선택에 달려 있습니다.

fieldsfields 명령어는 검색 결과에서 필드를 제거합니다. 일반적인 명령어는 표 4-6에 나와 있습니다.

표 4-12. fields 명령어의 예

명령 결과… | fields – field1, field2 검색 결과에서 field1과 field2를 제

거합니다.

… | fields field1 field2 field1과 field2만 유지합니다.

… | fields field1 error* field1과 이름이 error로 시작하는 모든 필드만 유지합니다.

… | fields field1 field2 | fields - _*

field1과 field2만 유지하고 (밑줄로 시작하는) 모든 내부 필드를 제거합니다. (참고: 내부 필드를 제거하면 Splunk Web에서 결과를 잘못 표시하고 다른 검색 문제가 발생할 수 있습니다.)

표 4-12의 첫 번째 예 fields – field1, field2가 그림 4-12에 나와 있습니다.

Exploring Splunk

50

그림 4-12. fields 명령어의 예

요점내부 필드, 즉 이름이 밑줄로 시작하는 필드는 명시적으로 지정되지 않는 한 fields 명령어에 영향을 받지 않습니다.

replacereplace 명령어는 대치 값을 사용하여 지정된 필드 값의 검색 및 바꾸기를 수행합니다.

검색어나 대치어의 값은 대소문자를 구분합니다.

표 4-13. replace 명령어의 예

명령 결과replace *localhost with loc-alhost in host

localhost로 끝나는 모든 host 값을 localhost로 변경합니다.

replace 0 with Critical , 1 with Error in msg_level

msg_level 값 0을 Critical로, msg_level 값 1을 Error로 변경합니다.

replace aug with August in start_month end_month

모든 start_month 또는 end_month 값 aug를 August로 변경합니다.

replace 127.0.0.1 with local-host

모든 필드 값 127.0.0.1을 local-host로 변경합니다.

표 4-13의 두 번째 예 replace 0 with Critical , 1 with Error가 그림 4-13에 나와 있습니다.

...| 필드 - field1 field2

�eld1123456789

�eld1ABCDEFGHI

�eld1abcdef

ghi

<�elds. . . >. . .. . .. . .. . .. . .. . .. . .. . .. . .

�eld1abcdef

ghi

<�elds. . . >. . .. . .. . .. . .. . .. . .. . .. . .. . .

�eld1123456789

�eld1ABCDEFGHI

�eld1abcdef

ghi

<�elds. . . >. . .. . .. . .. . .. . .. . .. . .. . .. . .


51

그림 4-13. replace 명령어의 예

evaleval 명령어는 표현식을 계산하고 결과 값을 새 필드에 넣습니다. eval 및 where 명령어는 동일한 표현식 구문을 사용합니다. 부록 E에 사용 가능한 모든 함수가 나열되어 있습니다.

표 4-14. eval 명령어의 예

명령 결과… | eval velocity=distance/time

velocity를 distance 나누기 time으로 설정합니다

… | eval status = if(error == 200, “OK”, “Error”)

error가 200이면 status를 OK로, 그렇지 않은 경우 Error로 설정합니다.

… | eval sum_of_areas = pi() * pow(radius_a, 2) + pi() * pow(radius_b, 2)

sum_of_areas를 두 원의 면적의 합으로 설정합니다.

그림 4-14에 표 4-14의 첫 번째 예 eval velocity=distance/time가 나와 있습니다.

...| replace 0 with Critical,1 with Error in msg_level

msg_level010034031

<�elds. . . >. . .. . .. . .. . .. . .. . .. . .. . .. . .

msg_level

34

3

<�elds. . . >. . .. . .. . .. . .. . .. . .. . .. . .. . .

Exploring Splunk

52

그림 4-14. eval 명령어의 예

eval 명령어의 결과가 새 velocity 필드를 생성합니다. (velocity 필드가 존재하느 경우 eval 명령어가 값을 업데이트합니다.) eval 명령어는 한 번에 하나의 필드만 만들거나 재지정합니다.

rexrex 명령어는 지정된 PCRE(Perl Compatible Regular Expression)와 값이 일치하는 필드를 추출합니다. (rex는 regular expression의 줄임말입니다.)

정규식이란 무엇입니까?정규식을 "광범위한 와일드카드'로 생각하십시오. 아마도 *.doc 또는 *.xls와 같은 표현을 사용하여 파일을 검색해 보셨을 것입니다. 정규식을 사용하면 기능과 유연성을 높일 수 있습니다. 정규식에 익숙한 경우 이 내용을 읽지 않아도 됩니다. 자세한 내용은 http://www.regular-expressions.info를 참조하십시오.

표 4-15. rex 명령어의 예

명령 결과… | rex “From: (?<from>.*) To: (?<to>.*)”

정규식을 사용하여 from 및 to 필드를 추출합니다. 원시 이벤트에 “From: Susan To: Bob”이 포함되어 있는 경우 from=Susan 및 to=Bob입니다.

rex field=savedsearch_id (?<user>\w+);(?<app>\w+);(?<SavedSearchName>\w+)

savedsearch_id라고 하는 필드에서 user, app 및 SavedSearchName을 추출합니다. savedsearch_id = “bob;search;my_saved_search”의 경우 user=bob, app=search 및 SavedSearchName=my_saved_search입니다.

eval velocity=distance/time...|

50100200

velocity5

1040

1010

5

<�elds. . . >. . .. . .. . .

50100200

1010

5

<�elds. . . >. . .. . .. . .


53

rex mode=sed “s/(\\d{4}-){3}/XXXX-XXXX-XXXX-/g”

정규식을 일련의 숫자와 일치시키고 익명처리된 문자열로 대치하려면 sed 구문을 사용하십시오.

그림 4-15는 from 및 to 필드를 추출한 표 4-15의 첫 번째 예를 보여줍니다.

그림 4-15. rex 명령어의 예

lookuplookup 명령어는 룩업 테이블에서 필드 룩업을 수동으로 호출하며, 이 명령어를 사용하여 외부 소스에서 필드 값을 추가할 수 있습니다. 예를 들어, 5자리 우편번호가 있는 경우 거리 이름을 조회하여 ZIP+4 9자리 우편번호를 적용할 수 있습니다.

표 4-16. 명령어의 예

명령 결과… | lookup usertogroup user as local_user OUTPUT group as user_group

transform.conf1의 스탠자 이름 usertogroup에 지정된, user 및 group 필드가 있는 룩업 테이블에 대해 각 이벤트의 local_user 필드의 값을 조회합니다. 일치하는 항목의 경우 룩업 테이블의 group 필드의 값이 이벤트의 user_group 필드에 쓰여집니다.

rex "From: (?<from>.*)To: (?<to>.*)”

...|

_rawFrom: Susan To: Bob Subject: current to-do list Message Hi Bob, I wanted to …From: Meenu Subject: version 6 docs Message Hi Jan, Let's set up a time to …

From: John To: Miguel Message Here's what we need to arrange for the . . .

_rawSubject: current to-do list Message Hi Bob, I wanted to …

Subject: version 6 docs Message Hi Jan, Let's set up a time to … Message Here's what we need to arrange for the . . .

fromSusan

MeenuJohn

toBob

Miguel

1 룩업 테이블은 관리자 » 룩업에서 구성할 수 있습니다.

Exploring Splunk

54

… | lookup dnslookup host OUTPUT ip

역 DNS 룩업을 수행하고 호스트 이름 또는 IP 주소를 인수로 수신하는 Python 스크립트를 참조하는 dns-lookup 이름의 필드 룩업이 지정된 경우, 이벤트의 호스트 이름 값(host 필드)을 테이블의 호스트 이름 값과 일치시킨 다음 해당하는 IP 주소 값(ip 필드)을 이벤트에 추가합니다.

… | lookup local=true user-ziplookup user as local_user OUTPUT zip as user_zip

검색 헤드에만 존재하는 로컬 룩업 테이블에 대해 각 이벤트의 user 필드의 값을 조회합니다. 일치하는 항목의 경우 룩업 테이블의 zip 필드의 값이 이벤트의 user_zip 필드에 쓰여집니다.

그림 4-16에 표 4-16의 첫 번째 예 lookup usertogroup user as lo-cal_user OUTPUT group as user_group이 나와 있습니다.

그림 4-16. lookup 명령어의 예

이 장에서는 SPL의 명령어에 대한 속성 과정을 제공했습니다. 다음 장에서는 태그와 event type을 사용하여 데이터를 강화하고 Splunk에서 특정 패턴을 감독하고 경고를 보내도록 설정하는 방법에 대해 설명합니다.

lookup usertogroup user as local_userOUTPUT group as user_group

...|

local_userUser1User2User3

user_groupCEF

<�elds. . . >. . .. . . .. . . ..

search results

userUser10

User9User1User7User2User3

User27User98

groupABCDEFGH

<�elds. . . >. . .. . . .. . . .. . . .. . . .. . . .. . . .. . . ..

usergroup lookup table

local_userUser1User2User3

<�elds. . . >. . .. . . .. . . ..

55

5 데이터 강화데이터를 더 유용하게 만들려면 데이터에 정보를 추가하십시오. 이 말이 무슨 의미일까요? Splunk에서 데이터로부터 필드를 추출하는 방법을 설정하는 경우, 해당 필드에 대해 논리적으로 생각해보고 심층적인 분석을 위한 데이터 분류를 위해 정보를 추가할 수 있습니다. 보고서와 대시보드를 설정하면 사용자와 다른 사람들이 데이터를 더 쉽게 이해할 수 있게 됩니다. 또한, 경고를 만들면 Splunk에서 능동적으로 잠재적인 문제를 발견하므로 뒤늦게 수동으로 문제를 검색하지 않아도 됩니다.

이 장에서는 다음과 같은 세 가지 분야에 대해 설명합니다.

• Splunk를 사용하여 데이터 이해에서는 데이터를 탐색하고, 분류하고, 익숙해지는 방법에 대해 설명합니다.

• 데이터 표시에서는 데이터 시각화의 기본사항에 대해 설명합니다.

• 잠재적인 문제에 대한 경고 만들기에서는 측정값이 임계값을 초과하는 경우 추적하고 경고를 보내는 방법에 대해 설명합니다.

Splunk를 사용하여 데이터 이해하기새로운 머신 데이터 소스는 처음에는 의미없는 숫자와 암호 문자가 뒤죽박죽 엉켜 있는 것처럼 보입니다. 그러나 머신 데이터를 만들어내는 시스템에 대해 많이 알수록 데이터의 의미는 더욱 커집니다. 데이터 세트에 대해 잘 알고 있더라도 계속해서 탐색하면 새로운 통찰력을 얻을 수도 있습니다.

데이터를 알게 되는 첫 번째 단계는 Splunk를 사용하여 데이터의 필드를 식별하는 것입니다. 이 작업은 퍼즐의 모든 조각을 살펴보고 모양을 인식하는 것과 같습니다. 그 다음 단계는 집계 및 보고의 시작 단계로서 데이터를 분류하는 것입니다. 이 작업은 퍼즐 조각을 바깥쪽 조각과 안쪽 조각으로 분류하는 것과 같습니다. 데이터를 이해하고 퍼즐 조각을 짜맞출수록 그림이 더 분명해집니다. 마침내 그림이 완성되고(데이터가 표시되고) 다른 사람과 공유할 수 있게 됩니다.

Exploring Splunk

56

필드 식별: 퍼즐 조각 살펴보기Splunk는 source type이라고 불리는 다양한 데이터들의 공통 유형들을 인식할 수 있습니다. 올바른 source type을 설정하는 경우 Splunk에서는 사전 구성된 설정을 사용하여 필드를 식별할 수 있습니다. 예를 들어, 대부분의 웹 서버 유형이 이 경우에 해당합니다.

하지만 종종 머신 데이터에 포함된 숨겨진 속성이 있습니다. 예를 들어, URL의 일부로 제품의 카테고리 정보가 있는 경우가 있습니다. URL에 특정한 제품 범주가 있는 이벤트들을 조사하면 사이트의 여러 섹션에 대한 반응 시간과 오류율 그리고 가장 많이 검색된 제품에 대한 정보를 확인할 수 있 습니다.

자동 필드 검색검색 시 Splunk는 키와 값 사이 등호(=)의 존재와 같이 데이터 내에서 공통적인 패턴을 식별하여 필드를 자동으로 추출합니다. 예를 들어, 이벤트에 “… id=11 lname=smith … ”가 포함되어 있는 경우 Splunk에서는 예제 값을 갖는 id 및 lname 필드를 자동으로 생성합니다. 또한 2장에서 언급했듯이 일부 필드(source, sourcetype, host, _time, 및 line-count 등)는 항상 식별됩니다.

원하는 정보를 찾을 수 없습니까? 검색을 시작해 보십시오. Splunk에서는 기본적으로 UI에서 일정한 수의 필드만 표시됩니다. 수백 개의 필드를 완벽하게 더 추출할 수도 있습니다. 이들 필드를 검색하면 맨 위에 표시됩니다.

UI turUI의 필드 사이드바에 있는 필드 검색 스위치를 사용하면 이 동작을 켜거나 끌 수 있습니다. 선택된 필드(Splunk에서 기본적으로 선택했거나 사용자가 선택한 필드)들이 표시되고 Splunk가 추출한 필드들이 이어서 표시됩니다. 수정을 클릭하면 Splunk에서 선택된 필드 그룹에 추가할 수 있는 더 많은 필드를 나열합니다. 아무 필드나 클릭하면 검색 결과에서 추출된 상위 값이 표시됩니다.

자동 필드 검색에 대한 자세한 내용은 http://splunk.com/goto/book#auto_fields를 참조하십시오.

필드 추출 구성필드 추출 구성은 두 가지 방법으로 이루어집니다. Splunk에서 대화형 필드 추출기를 사용하여 구성을 자동화하도록 하거나 사용자 자신이 수동으로 구성할 수 있습니다.

5장: 데이터 강화

57

대화형 필드 추출기

검색 결과의 어느 이벤트에서든 이벤트 리스트의 이벤트 왼쪽에 있는 아래쪽 화살표를 클릭하면 표시되는 이벤트 옵션 메뉴에서 필드 추출을 선택하여 대화형 필드 추출기(IFX)를 시작할 수 있습니다(그림 5-1 참조).

그림 5-1. 이벤트 옵션 메뉴에서 필드 추출을 선택하면 대화형 필드 추출기가 시작됩니다.

IFX는 브라우저의 다른 탭이나 창에 표시됩니다. 검색하는 값의 종류(예를 들어, 웹 로그의 클라이언트 IP 주소)를 입력하면 Splunk에서 유사한 값을 추출하는 정규식을 생성합니다(이 기능은 사용자가 정규식에 대해 지식이 없을 때 특히 유용합니다). 원하는 필드를 제대로 찾도록 추출을 테스트하고 추출 내용을 필드 이름과 함께 저장할 수 있습니다.

대화형 필드 추출기에 대해 자세히 알아보려면 http://splunk.com/goto/book#ifx를 참조하십시오.

수동으로 필드 추출 구성

관리자 » 필드 » 필드 추출에서 수동으로 정규식을 지정하여 필드를 추출할 수 있습니다. 이 방법이 필드를 추출하는 보다 유연하고 고급스러운 방법입니다.

정규식을 수동으로 지정하는 데 대해 자세히 알아보려면 http://splunk.com/goto/book#config_fields를 참조하십시오.

검색 언어 추출필드를 추출하는 또 다른 방법은 검색 명령어를 사용하는 것입니다. 데이터를 추출하기 위한 가장 일반적인 명령어는 이전 장에 설명된 rex 명령어입니다. 이 명령어에서는 정규식을 가지고 해당 정규식과 일치하는 필드를 추출합니다.

Exploring Splunk

58

때때로 필드를 추출하는 데이터의 종류에 따라 사용하는 명령어가 달라집니다. 여러 줄의 테이블 형식의 이벤트(명령줄 출력 등)에서 필드를 추출하려면 multikv를 사용하고, XML 및 JSON 데이터에서 추출하려면 spath 또는 xmlkv를 사용하십시오.

필드를 추출하는 명령에 대해 자세히 알아보려면 http://splunk.com/goto/book#search_fields를 참조하십시오.

데이터를 탐색하여 데이터의 범위 이해필드를 추출한 후 데이터 탐색을 시작하여 데이터의 의미를 파악할 수 있습니다. 다시 퍼즐의 비유로 돌아가서, 이제 여러분은 패턴을 찾기 시작했습니다. 어떤 조각이 퍼즐의 테두리 부분의 조각인가요? 어떤 다른 방법으로 퍼즐 조각들을 분류할 수 있나요? 모양 또는 색깔로 분류할 수 있나요?

검색 대시보드의 필드 사이드바는 다음과 같은 각 필드에 대한 정보를 즉시 제공합니다.

• 필드의 기본 데이터 유형. 필드 이름 왼쪽에 문자로 표시됩니다("a"는 텍스트, "#"는 숫자를 나타냅니다.

• 이벤트 리스트 내 필드의 발생 횟수(필드 이름 뒤의 괄호 안에 표시됩니다).

필드 사이드바에서 필드 이름을 클릭하면 상위 값 및 차트에 대한 링크를 포함한 필드 요약이 표시됩니다.

그림 5-2. 필드 사이드바에서 필드 이름을 클릭하여 필드 요약 보기


59

또한 이벤트 리스트의 범위를 좁혀 해당 필드에 값이 있는 이벤트만 표시할 수도 있습니다.

top을 사용한 데이터 탐색top 명령어는 가장 일반적인 필드 값, 기본적으로 상위 10개의 값을 제공합니다. top 명령어를 사용하여 다음과 같은 질문에 대답할 수 있습니다.

• 가장 많이 나타나는 10개의 페이지는 무엇인가? sourcetype=”access*” | top uri

• 각 호스트의 상위 사용자는 누구인가?sourcetype=”access*” | top user by host

• 상위 50개의 원본 및 대상 IP 쌍은 무엇인가?…| top limit=50 src_ip, dest_ip

stats를 사용한 데이터 탐색stats 명령어는 데이터에 대한 풍부한 통계적 정보를 제공합니다.

다음은 stats 명령어를 사용하는 몇 가지 간단한 방법입니다.

• 지금까지 발생한 503 응답 오류2는 몇 개입니까?sourcetype=”access*” status=503 | stats count

• 각 호스트의 초당 평균 킬로바이트는 어떻게 됩니까?sourcetype=”access*” | stats avg(kbps) by host

• 어제 몇 사람이 꽃을 구입했습니까? stats dc(개별 개수)를 사용하면 각 IP 주소가 한 번만 계산됩니다.sourcetype=”access*” action=purchase category_id=flowers | stats dc(clientip)

• 서버가 웹 요청에 응답하는 데 걸린 시간의 95백분위수는 무엇입니까?sourcetype=”access*” | stats perc95(spent)

결과에 스파크라인 추가

Splunk 4.3부터는 테이블 결과에 스파크라인이라고 하는 간단한 선 그래프를 추가할 수 있습니다. 스파크라인을 사용하면 별도의 선 차트를 만들지 않고 데이터 패턴을 신속하게 시각화할 수 있습니다.

예를 들어, 다음 검색에서는 스파크라인을 사용한 각 호스트의 시간별 이벤트 수를 보여줍니다.

* | stats sparkline count by host

2 웹 서버 로그의 503의 상태는 서버측 오류입니다. 웹 서버에서 "서비스 사용 불가" 메시지를 보냈습니다. 경제적인 측면에서 보면 이는 누군가 사이트에 왔다가 작업을 계속하지 못했다는 것을 나타냅니다. 이 오류가 계속 발생하면 운영 측면을 살펴봐야 합니다.

Exploring Splunk

60

그림 5-3은 테이블의 스파크라인을 보여줍니다.

그림 5-3. 스파크라인이 이벤트 테이블 내 데이터의 패턴을 보여줍니다.

다음은 스파크라인을 사용하는 방법을 보여주는 몇 가지 명령어입니다.

• 각 status와 category_id 조합별로 이벤트의 개수는 어떻습니까?sourcetype=”access*” | stats sparkline count by status, category_id

• 각 category_id별로 평균 반응 시간은 어떻게 됩니까?sourcetype=”access*” | stats sparkline(avg(spent)) by cat-egory_id

다른 데이터(지진 강도 데이터)를 사용하여 지난 6시간 동안의 지진 강도가 지역별로 어떻게 다른지를 가장 잘 알려진 지역이 먼저 표시되도록 하여 확인할 수 있습니다.3

source=eqs7day-M2.5.csv | stats sparkline(avg(Magnitude),6h) as magnitude_trend, count, avg(Magnitude) by Region | sort count

보고 및 집계 준비필드를 식별하고 데이터를 탐색했다면 그 다음 단계는 어떤 일이 일어나고 있는지 파악하는 것입니다. 데이터를 범주별로 나누어 각 범주에 대해 검색 및 보고하고 경고할 수 있습니다.

여기서 말하는 범주는 사용자 정의 범주입니다. 사용자가 데이터를 알고 있고 데이터에서 무엇을 얻고 싶은지 알고 있는 상태입니다. Splunk를 사용하여 데이터를 원하는 방식으로 분류할 수 있습니다.

Splunk에서 데이터를 분류하는 데는 태그 지정과 event type 등 두 가지 유용한 방법이 있습니다.

3 여기서는 예제로 제공되었지만 아래 페이지에서 실제 데이터를 다운로드하여 테스트 해 볼 수 있습니다. http://earthquake.usgs.gov/earthquakes/catalogs/.


61

태그 지정태그는 필드 값에 쉽게 레이블을 지정할 수 있는 방법입니다. 호스트 이름 bdgpu-login-01이 이해하기 쉽지 않은 경우 authentication_server와 같은 태그를 붙이면 이해력을 높이는데 도움이 됩니다. UI에서 보이는 이상값에 대해 나중에 자세히 알아보고 싶은 경우 follow_up이라고 레이블을 붙일 수 있습니다.

이벤트 리스트의 필드 값에 태그를 지정하려면 태그를 지정하고자 하는 필드 값 옆의 아래쪽 화살표를 클릭하십시오(그림 5-4 참조).

그림 5-4. 호스트에 태그 지정

관리자 » 태그로 이동하면 모든 태그를 관리할 수 있습니다.

여러 호스트 값에 webserver, database_server 등의 태그를 사용하여 레이블을 지정했다고 가정하겠습니다. 이러한 사용자 지정 태그를 이용하여 임의의 이름 대신에 사용자가 원하는 방식으로 데이터를 볼 수 있습니다. 자신이 원하는 데이터 보기 방식을 지정할 수 있습니다. 예를 들어, 여러 호스트의 시간별 성능을 비교하려면 다음과 같은 명령을 실행하십시오.

… | timechart avg(delay) by tag::host

보고 및 부정 검색(Negative Searching)의 즐거움데이터를 살펴보기 시작하는 순간부터 보고에 대해서 생각해야 합니다. 데이터에 대해 무엇을 알고 싶으십니까? 무엇을 찾고 계십니까? 어떤 '무의미한 정보'를 데이터에서 제거하여 원하는 것을 쉽게 찾고 싶으십니까? 마지막 질문의 경우 대부분의 데이터 분석 소프트웨어에서는 할 수 없지만 Splunk의 강점인 부정 검색(Negative Searching)에 대한 추가 설명이 필요합니다.

Exploring Splunk

62

종종 존재하지 않는 것은 증명할 수 없다고 합니다. 그러나 모든 곳을 둘러 볼 수 없는 상황에서 내가 지금 찾는 것이 여기 없다고 단정지을 수도 없습니다. Splunk를 사용하면 부정 검색이 가능합니다. 로그 파일과 기타 많은 데이터 유형으로 무슨 일이 일어나고 있는지 알기 어려운 이유는 대부분의 데이터가 동일한 일상적인 머신 데이터이기 때문입니다. Splunk를 사용하면 관심 없는 데이터를 분류해 내고, 예외적이거나 특별한 데이터만 표시하도록 요청할 수 있습니다. 지금까지 내가 보지 못한 걸 보여줘 하고 말이죠. 일부 보안 전문가는 Splunk를 침입을 나타낼 수 있는 비정상 이벤트를 식별하는데 사용합니다. 전에 본 적이 있는 이벤트의 경우 태그를 붙이고 검색에서 제외합니다. 얼마간 시간이 지난 후 이상한 일이 발생하면 즉시 알아챌 수 있습니다.

Event TypeSplunk에서 검색하는 경우 이벤트 검색부터 시작합니다. 특정한 종류의 이벤트를 검색하면서 함축적으로 이벤트를 찾아봅니다. 다시 말해 특정한 유형의 이벤트를 찾고 있다고 말할 수 있습니다. "event type"은 이벤트를 분류하는 방식에 사용됩니다.

event type을 사용하면 search 명령어의 모든 기능을 활용하여 신속하게 이벤트를 분류할 수 있습니다. 즉 부울 식, 와일드카드, 필드 값, 구문 등을 사용할 수 있습니다. 따라서 event type은 필드 값에만 국한되는 태그보다 훨씬 더 강력합니다. 하지만 태그와 마찬가지로 데이터를 분류하는 방식은 전적으로 사용자에게 달려 있습니다.

event type을 생성하여 고객이 구매한 위치, 시스템이 중단된 시기, 발생한 오류 조건 유형 등 이벤트를 분류할 수 있습니다.

이벤트에 대해 무엇을 알고 싶은지가 중요합니다.

다음은 event type을 정의하는 검색에 대한 몇 가지 기본 규칙입니다.

• 파이프 제외. event type을 만들기 위해 사용하는 검색에는 파이프를 포함할 수 없습니다(즉, 내포된 search 명령어 외에 다른 검색 명령어를 사용할 수 없습니다).

• 하위 검색 제외. 3장 말미에서 하위 검색에 대해 간략하게 설명했습니다. 그러나, 지금은 event type을 만들 때 하위 검색을 사용할 수 없다는 점을 기억하십시오.

다음은 간단한 예입니다. 웹 사이트를 개선하기 위한 노력의 일환으로 status 필드를 기반으로 다음과 같은 네 가지 event type을 만들라고 합니다.

• status=”2*”는 success로 정의됩니다.

• status=”3*”는 redirect로 정의됩니다.

• status=”4*”는 client_error로 정의됩니다.

• status=”5*”는 server_error로 정의됩니다.


63

정의한 대로 event type success를 만들기 위해 다음과 같이 검색을 수행합니다.

sourcetype=”access*” status=”2*”

다음에는 만들기 » Event type을 선택합니다. event type의 이름을 지정하고, 태그를 지정하고(선택사항), 저장을 클릭할 수 있는 Event Type으로 저장 대화 상자가 표시됩니다.

검색 결과와 일치하는 event type을 보려면 필드 사이드바에서 eventtype을 클릭합니다. 이 다중값 필드에는 이벤트 리스트의 이벤트에 대한 모든 event type이 표시됩니다.

같은 방법으로 세 가지 유형 event type을 더 만든 다음 stats count를 실행하여 분포를 표시합니다.

sourcetype=”access*”| stats count by eventtype

결과는 그림 5-5와 같은 모양입니다.

그림 5-5. event type별로 이벤트 구분

server_error event type의 이벤트가 상대적으로 많지는 않지만, 이러한 이벤트에서 공통적인 사항을 알아낼 수 있는지를 확인하기 위해 자세히 살펴볼 가치가 있습니다.

server_error를 클릭하면 해당 event type만 드릴다운하여 그림 5-6과 같은 15개의 이벤트를 볼 수 있습니다.

Exploring Splunk

64

그림 5-6. 서버 오류 이벤트

server_error 이벤트들은 한 가지 우려가 되는 공통점을 가지고 있습니다. 즉, 서버 이용이 불가능한 때에 사람들이 무언가를 구매하려고 시도한다는 점입니다. 다시 말해 수익 손실이 발생합니다. 따라서 서버를 관리하는 담당자에게 무엇이 잘못되었는지 확인하도록 요청해야 합니다.

event type 중첩일반적인 event type 외에 보다 구체적인 event type을 만들 수 있습니다. 다른 event type을 빌딩 블록으로 새 event type web_error를 정의할 수 있습니다.

eventtype=client_error OR eventtype=server_error더 이상 추적하지 못하고 순환 정의가 작성되는 일이 발생하지 않도록 이 명령은 신중하게 사용해야 합니다.

Event Type 태그 지정 event type에 태그를 지정할 수 있습니다(또한 필드 값에도 태그를 지정할 수 있습니다). 예를 들어, 모든 event type에 error 태그를 붙일 수 있습니다. 그런 다음 해당 event type과 관련된 오류 유형에 대해 보다 자세한 설명을 제공하는 태그를 추가할 수 있습니다. 예를 들어, 잠재적인 문제에 대한 사전 경고를 나타내는 유형, 사용자에게 영향을 미치는 중단을 나타내는 유형, 치명적인 오류를 나타내는 유형 등 세 가지 오류 유형 등이 있습니다. 오류 event type에 early_warning, user_impact, red_alert 등 보다 자세한 설명을 제공하는 다른 태그를 추가하고 각 오류 event type에 대해 별도로 보고할 수 있습니다.

event type과 태그를 함께 사용하면 검토 중인 머신 데이터의 상세 이벤트에서 보다 높은 수준의 모델 구축이 가능합니다. 일반적으로 이 작업은 반복적인 프로세스입니다. 먼저 유용한 필드 몇 개에 태그를 지정하고 이 필드들을 모니터링과 경고에 사용합니다. 이어서 보다 복잡한 범주 구분을 위해 몇 가지 event type을 만듭니다. 일반적으로 더 낮은 수준의 event type을 참조하여 높은 수준의 event type을 구축하게 됩니다. 그런 다음에는 여러 범주를 통합하기 위해 event type에 태그를 추가합니다. 즉 처음부터 끝까지 필요에 따라 데이터를 구성하고 레이블 지정 방법에 대한 정보를 Splunk에 추가하는 것입니다.


65

앞서 무관 검색에 대해 이야기한 바 있습니다. 특별히 보고 싶지 않은 모든 event type에 normal 태그를 사용하여 태그를 지정하는 경우 normal이 아닌 이벤트를 검색할 수 있습니다. 이렇게 하면 비정상 데이터가 드러나게 됩니다.

NOT tag::eventtype=normal

데이터 시각화이제까지 다음과 같은 데이터 시각화 방법에 대해 설명했습니다.

• 필드 사이드바에서 필드 이름을 클릭하여 필드에 대한 간단한 몇 가지 그래픽 표시.

• top 및 stats 검색 명령어 사용.

• 스파크라인을 사용하여 이벤트 테이블 결과에서 인라인 시각자료 보기.

이 절에서는 데이터를 시각화하기 위해 차트와 대시보드를 만드는 방법에 대해 설명합니다.

시각자료 만들기데이터 테이블을 보면 무언가 흥미로운 것을 발견할 수도 있습니다. 동일한 데이터를 차트와 그래프에 추가하면 새로운 차원의 정보를 확인하고 다른 방법으로는 보기 어려운 세부정보를 표시할 수 있습니다.

데이터의 차트를 만들려면 검색을 실행한 후 만들기 » 보고서를 선택합니다. 또는 Splunk 4.3의 경우 결과 영역에서 결과 차트 아이콘을 클릭하여 결과 차트를 표시합니다.

Splunk는 컬럼, 선, 영역, 막대, 파이, 산점도 등 다양한 차트 유형을 제공합니다.

어느 제품 범주가 404 오류에 가장 영향을 받습니까? 다음 검색은 각 category_id 에 대한 이벤트 수를 계산하고 그림 5-7에 표시된 파이 차트를 생성합니다.

sourcetype=”access*” status=”404” | stats count by catego-ry_id

Exploring Splunk

66

그림 5-7. 제품 category_id별 404 오류 회수

꽃과 선물이 마진이 가장 높은 상품이므로 잘못된 URL에 대해서는 몇 가지 리디렉션을 추가하는 것이 좋습니다. (그리고 외부 링크를 업데이트하기 위해 회사 페이지로 연결되는 사이트를 조회해 보는 것이 좋습니다.)

Splunk에서 아무 그래픽 위에 마우스를 올려놓으면 그래픽의 해당 부분 뒤에 있는 데이터에 대해 더 많은 정보를 얻을 수 있습니다. 그림 5-8을 참조하십시오.

그림 5-8. 그래픽의 한 부분에 마우스를 올려 놓으면 데이터에 대한 세부정보가 표시됩니다.


67

대시보드 만들기모니터링을 위해 Splunk를 사용하는 경우 최종 결과는 보통 여러 시각 자료가 포함된 대시보드 형태로 만들어지게 됩니다. 대시보드는 검색 결과의 차트, 게이지, 테이블 또는 리스트(데이터를 보는 것 자체가 도움이 되는 경우도 종종 있습니다)로 구성된 보고서 패널을 말합니다.

대시보드를 설계하는 경우 "이들 중 내가 제일 먼저 보고 싶은 차트는 어떤 것인가? 최종 사용자는 어느 차트를 먼저 보고 싶어할까? 일선 관리자는 어느 차트를 먼저 보고 싶어하나?"라고 자문해 보십시오. 사용자마다 자신만의 대시보드를 필요로 하는 경우가 많습니다.

그렇다면 "이 대시보드를 보면 어떤 질문이 떠오를까?"라고 질문해 보십시오. Splunk에서는 간단히 차트를 클릭하면 차트 세부정보에 대한 다양한 종류의 드릴다운 항목이 자동으로 처리됩니다. (고급 사용자는 드릴다운 동작을 명확하게 지정할 수 있지만 이는 이 책의 범위를 벗어납니다.)

한 가지 유의할 점은 단순한 시각화가 모든 수준의 사용자에게 가장 인기있다는 것입니다. 고급형의 상세한 대시보드를 만들 수 있고, 또 만들어야 하지만, 간결하면서 수준 높은 뷰를 만드는데에 집중하십시오.

그림 5-9에는 대시보드의 예가 나와 있습니다.

그림 5-9. 대시보드

대시보드를 구축하는 최선의 방법은 각 패널을 구현함에 있어서 하향식이 아니라 상향식으로 구축하는 것입니다. 먼저 Splunk의 차트 작성 기능을 사용하여 중요한 사항을 다양한 방식으로 표시하십시오. 시스템의 상태를 표시하는 여러 개의 개별 차트가 있는 경우 대시보드에 배치하십시오.

Exploring Splunk

68

대시보드 만들기Splunk 4.3에서 대시보드를 만들고 보고서, 차트 또는 검색 결과를 대시보드에 추가하려면 다음 단계를 수행합니다.

1. 대시보드용 보고서를 생성하는 검색을 실행합니다.

2. 만들기 » 대시보드 패널을 선택합니다.

3. 검색에 이름을 지정하고 다음을 클릭합니다.

4. 이 보고서를 새 대시보드에 추가할 것인지 기존 대시보드에 추가할 것인지 결정합니다. 새 대시보드를 만드는 경우 이름을 지정합니다. 다음을 클릭합니다.

5. 대시보드와 시각자료(테이블, 막대, 파이, 게이지 등)의 제목 그리고 패널용 보고서 실행 시기를 지정합니다(대시보드가 표시될 때마다 또는 정해진 일정에 따라).

6. 다음, 대시보드 보기 링크 또는 확인을 차례로 클릭합니다.

대시보드 보기언제든지 페이지 상단의 대시보드 및 뷰 메뉴에서 대시보드를 선택해 볼 수 있습니다.

대시보드 편집대시보드를 보는 동안 편집 모드 선택기에서 설정을 클릭한 다음 편집하고자 하는 패널의 편집 메뉴를 클릭하여 대시보드를 편집할 수 있습니다. 여기서 보고서를 생성하는 검색 또는 검색이 시각화되는 방식을 편집하거나 패널을 삭제할 수 있습니다.

경고 만들기 경고란 무엇입니까? 경고는 주기적으로 실행되는 "if-then" 문으로 생각할 수 있습니다.

만약(if) 이러한 일이 발생하면, 이렇게(then) 반응합니다.

이 경우 "if"는 검색입니다. "then"은 "if" 절이 충족되는 경우 이에 대한 반응으로 취하고자 하는 조치입니다.

보다 공식적으로 말하자면 경고는 주기적으로 실행되는 검색으로서 검색 결과에 대한 조건을 평가합니다. 조건이 일치하면 일부 조치가 실행됩니다.

마법사를 통한 경고 만들기경고를 만드는 첫 번째 단계는 경고하고자 하는 항목에 대한 조건을 검색하는 것입니다. Splunk에서 경고를 만들 때는 검색란에 있는 검색을


69

가져와서 저장하여 사용하며, 이 검색이 경고의 기반("if-then"의 "if")이 됩니다.

검색란에서 원하는 검색을 선택한 상태에서 만들기 » 경고를 선택합니다. 이렇게 하면 마법사가 시작되고 경고를 쉽게 만들 수 있습니다.

경고 예약경고 만들기 대화 상자의 예약 화면에서 경고의 이름을 지정하고 Splunk에서 경고를 실행할 방식을 지정합니다.

Splunk에서 검색을 실시간으로 실행하거나, 주기적으로 예약된 검색을 실행하거나, 롤링 윈도우에서 실시간으로 모니터링하여 조건을 모니터링하도록 선택할 수 있습니다.

다음은 이 세 가지 옵션을 사용하는 예입니다.

• 조건이 발생할 때마다 언제나 경고를 받으려면 실시간으로 모니터링합니다.

• 긴급성이 떨어지는 조건이지만, 그 내용을 알고자 하는 조건의 경우 예약 방식으로 모니터링합니다.

• 일정 기간 내 일정한 수의 일이 발생하는지 여부를 확인하려면 실시간 롤링 윈도우를 사용하여 모니터링합니다(이 옵션은 첫 번째 두 옵션을 조합한 것입니다). 예를 들어, 5분 동안 20번 이상 404 오류가 발생하면 바로 경고를 트리거할 수 있습니다.

예약 방식으로 롤링 윈도우에서 모니터링하도록 지정하는 경우, 경고를 트리거하기 위해 검색에 일치하는 시간 간격 및 결과의 수도 지정해야 합니다. 또는 경고 조건이 충족될 경우 실행되는 검색인 사용자 지정 조건을 입력할 수도 있습니다. 사용자 지정 조건은 이 장의 뒷부분에 설명되어 있습니다.

그림 5-10. 경고 예약

Exploring Splunk

70

다음 단계는 한도를 설정하고 경고가 트리거될 때 실행될 작업을 지정하는 것입니다.

작업 지정경고 조건이 발생하면 어떤 일을 해야 합니까? 경고 만들기 대화 상자의 작업 화면에서 실행할 작업(이메일 보내기, 스크립트 실행, 경고 관리자에서 트리거된 경고 표시)을 지정할 수 있습니다.

그림 5-11에서 사용자는 위의 모든 작업을 선택하여 전체 옵션을 사용할 수 있도록 지정했습니다.

그림 5-11. 마법사의 작업 화면


71

• 이메일 보내기. 이메일에는 다음과 같은 옵션이 있습니다.

◊ 이메일 주소. 하나 이상을 입력합니다.

◊ 제목. 이 옵션은 기본값(Splunk Alert: AlertName)으로 남겨둘 수 있습니다. $name$이 경고 이름으로 대치됩니다. (즉, 제목을 "이런! $name$이 발생했습니다"로 변경할 수 있습니다.)

◊ 경고를 트리거하는 결과 포함. 체크박스를 클릭하여 결과를 첨부된 CSV 파일로 포함하거나 인라인을 선택하여 이메일에 바로 추가할 수 있습니다.

• 스크립트 실행. 스크립트 이름을 지정합니다. 스크립트는 /bin/scripts 또는 앱의 /bin/scripts 디렉토리 내 Splunk의 홈 디렉토리에 있어야 합니다.

• 경고 관리자에 트리거된 경고를 표시합니다. 경고 관리자는 UI의 오른쪽 상단에 있는 경고를 클릭하면 열립니다.

하나(또는 두 개나 세 개)의 작업을 선택한 후 다음과 같은 추가 옵션을 입력할 수 있습니다.

• 심각도를 설정합니다. 심각도는 경고를 분류할 수 있는 참조용 메타데이터입니다. 수준은 정보, 낮음, 중간, 높음 및 중요입니다. 심각도는 경고 관리자에 표시됩니다.

• 모든 결과 또는 각 결과에 대해 작업을 실행합니다. 이에 따라 Splunk에서 검색과 일치하는 결과 그룹 또는 각 개별 결과에 대해 (이메일 보내기와 같은) 작업을 실행하는지 여부가 결정됩니다. "모든 결과"가 기본값입니다.

• 경보 조절. 경고는 필요할 때 알고 싶은 정보를 제공하는 경우에만 효과적입니다. 경고가 너무 많으면 무시하게 됩니다. 너무 적으면 무슨 일이 일어나고 있는지 알 수 없습니다. 이 옵션은 경고가 트리거된 후 Splunk에서 경고와 관련된 작업을 다시 수행할 때까지 얼마나 기다려야 하는지를 지정합니다. 롤링 윈도우를 지정하는 경우에는 마법사가 해당 기간과 일치하도록 경보 조절 간격의 기본값을 지정합니다. 추가 경보 조절 옵션은 이 장의 뒷부분에 설명되어 있습니다.

다음을 클릭한 후 마지막 단계는 경고가 현재 앱의 사용자에 대해 비공개인지, 읽기 전용 액세스 상태로 공유되는지 여부를 지정하는 것입니다. 완료를 클릭하여 마법사를 종료합니다.

관리자를 사용한 경고 조절경고에 대한 적절한 한도를 설정하는 데는 일반적으로 시행착오가 필요합니다. 중요하지 않은 경고가 너무 많거나 중요한 경고가 너무 적지 않도록 조정해야 할 수도 있습니다. 예를 들어, 중요한 이벤트가 한 번 발생해서는 경고가 발생되지만, 상한 10% 내에 들어가는 10번의 중요

Exploring Splunk

72

이벤트는 경고를 트리거하도록 한도를 조정해야 합니다.

마법사를 사용하여 신속하게 경고를 만들 수 있으며 관리자를 사용하여 경고의 여러 옵션을 조정할 수 있습니다.

저장된 검색이 경고의 기반이라는 점을 기억하십시오. 따라서 경고는 저장된 검색과 같은 방법으로 편집합니다. 경고를 편집하려면 관리자, 검색 및 보고서를 차례로 선택합니다.

리스트에서 저장된 검색을 선택하여 매개변수를 표시합니다.

경고 조건 설정경고를 If-Then 문으로 생각할 경우 관리자를 통해 If 부분을 보다 유연하게 편집할 수 있습니다. 경고는 다음과 같이 트리거되도록 설정할 수 있습니다.

• 항상

• event, host, source의 수에 따라

• 사용자 지정 조건

마법사는 이벤트의 수에 따라 경고를 제공하지만 여기서는 host 또는 source의 수에 따라 경고를 트리거할 수 있습니다. 호스트를 고려하십시오. 클러스터의 한 웹 서버에서 "서버 사용 불가" 상태를 발견하는 것은 대수롭지 않을 수도 있지만, 이러한 상태가 점점 더 많은 서버에서 발견되는 것은 차원이 다른 이야기입니다. 분명한 것은 이벤트가 급증하고 있고 서버들이 트래픽을 처리하지 않고 있다는 것입니다.

이 화면에서는 경고에 대한 임계값을 다음과 같이 보다 유연하게 정의할 수 있습니다.

• 보다 큼

• 보다 작음

• 같음

• 같지 않음

• 증가

• 감소

처음 네 가지 옵션은 마법사를 통해 제공되지만 여기서는 일정한 개수 또는 일정한 비율(예: 50%)로 증가하거나 감소하는 경우 경고를 보낼 수 있는 기능 또한 추가로 제공됩니다. "증가" 및 "감소"를 사용하면 상대적인 조건에 대한 경고를 효과적으로 설정할 수 있습니다(종종 경고를 받고자 하는 항목의 두 배 또는 세 배와 같이 절대적인 수가 아닙니다). "증가' 또는 "감소"는 실시간 검색을 사용하는 조건에 대해서는 지원되지 않습니다.


73

사용자 지정 조건 설정UI를 통해 가장 일반적인 종류의 경고 조건을 유연하게 구성할 수 있지만 사용자 지정 조건의 형태로 훨씬 더 유연하게 구성해야 하는 경우도 있습니다.

사용자 지정 조건은 경고의 기본 검색 결과에 대한 검색입니다. 검색에서 결과값을 반환하면 조건이 참이 되고 경고가 트리거됩니다.

예를 들어, 호스트가 중단되는 경우 언제나 경고를 받지만 예정된 유지보수가 진행 중인 호스트는 제외할 수 있습니다. 이렇게 하려면, 중단되는 모든 호스트를 반환하도록 기본 검색을 만들고 사용자 지정 조건으로 "false positive", 즉 유지보수 일정에 포함된 호스트를 제외시킵니다. 이러한 방식으로 호스트가 예기치 않게 중단되는 경우에만 경고를 받습니다.

경고 조절Splunk를 사용하면 경고를 통해 유용한 정보를 제공하도록 조정할 수 있습니다. 중요한 정보를 제공하는 하나의 메시지는 도움이 됩니다. 반면에 아무리 조건에 매치된다 하더라도 메시지가 100개씩 제공된다면 그 경고는 의미가 퇴색됩니다. 이것은 의미 없는 정보가 됩니다.

Splunk를 사용하면 경고를 조절하여 경고가 트리거되더라도 특정한 시간 간격으로 한 번만 울리도록 지정할 수 있습니다. 다시 말해, 첫 번째 경고는 팝콘을 튀길 때 처음 터지는 옥수수알과 같으며 실제로 이후의 관련된 다른 모든 옥수수알이 터지는 것에 대한 경고들은 원하지 않을 것입니다. (만약 팝콘의 예에서 두 번째 경고가 필요하다면, 모든 옥수수알이 터진 후 타버리기 전에 울리는 것이 기능적으로 적당할 것입니다.)

이것이 경보 조절의 기능입니다. Splunk에서 경고를 보내되, 끊임없이 경고를 보내지 않도록 지정할 수 있습니다.

경고를 편집하기 위한 관리자 화면의 가운데에 경고 모드(그림 5-12 참조)라고 하는 옵션이 있습니다.

그림 5-12. 경고 모드

검색당, 즉 전체 검색 결과에 대해 한 번 경고를 받거나 또는 각각의 결과 별로 한 번씩의 경고를 받을 수 있습니다. 결과당 경고는 필드별로 추가 조절할 수 있습니다. 예를 들어, 조건이 충족되는 경우 언제나, 호

Exploring Splunk

74

스트당 한 번만 경고를 받을 수 있습니다. 서버의 디스크 공간이 부족해지고 있어서 사용 가능한 공간이 30% 미만이 되면 경고를 받고 싶다고 가정하겠습니다. 필드 경고를 조절하는 결과별에 호스트를 지정하면 지정된 기간 동안 각 호스트에 대해 한 번 경고를 받습니다. 사용자 로그인 실패를 처리하는 경우에는 사용자 이름을 입력하면 됩니다.

경고에 대한 작업 사용자 지정스크립트를 작성하거나 수정하여 경고에 대한 사용자 지정 작업을 설정할 수 있습니다. 예를 들어, 다음과 같은 작업을 설정할 수 있습니다.

• 문제 해결에 도움이 되는 사람들에게 SMS 보내기.

• 헬프데스크 티켓 또는 다른 유형의 문제 티켓 생성.

• 서버 재시작.

이메일 보내기를 비롯한 모든 경고 작업은 스크립트를 기반으로 합니다. RSS 피드를 만드는 경우도 마찬가지입니다. 이러한 정보를 바탕으로, 스크립트를 사용하여 필요한 대로 유연하게 경고 작업을 설정할 수 있습니다.

사용자 지정 경고 스크립트 만들기에 대해 자세히 알아보려면 http://splunk.com/goto/book#custom_alerts를 참조하십시오.

경고 관리자경고에 대한 설정은 경고 관리자에서 제어합니다.

경고 관리자를 표시하려면 화면 오른쪽 상단에서 경고를 클릭하십시오.


75

그림 5-13. 경고 관리자

여기서 간략한 용어 설명이 필요합니다. 저장된 if-then 예약 검색을 경고라고 부르고, 해당 경고의 개별적인 발생을 경고 인스턴스라고 부르겠습니다.

경고 관리자에는 가장 최근에 발생한 경고 (즉, 경고 인스턴스)의 리스트가 표시됩니다. 이 리스트는 경고 인스턴스가 발생된 시기를 보여주고, 해당 인스턴스의 검색 결과를 보고 인스턴스를 삭제할 수 있는 링크를 제공합니다. 또한 경고의 이름, 앱, 유형(예약, 실시간 또는 롤링 윈도우), 심각도 및 모드(요약 또는 결과별)를 보여줍니다. 경고의 정의를 편집할 수도 있습니다.

II부

방법

79

6 모니터링 및 경고 방법이 책의 처음 다섯 장에서는 Splunk를 사용하여 새롭고 흥미로운 방식으로 문제를 해결하고, 질문에 대답하고, 데이터를 탐색하는 방법에 대해 설명했습니다.

이 장에서는 모니터링 및 경고 방법에 대해 설명합니다. 모니터링은 시각적으로 모니터링할 수 있는 보고서를 가리키며 경고는 자동으로 작업을 트리거할 수 있는 Splunk에 의해 모니터링되는 조건을 가리킵니다.

이 방법들은 일반적인 모니터링 및 경고 문제에 대해 간단한 해결책으로 사용할 수 있습니다. 각 방법에는 문제 내용과 Splunk를 사용하여 해당 문제를 해결하는 방법을 설명하는 내용이 포함되어 있습니다. 일부 복잡한 예제를 통해 변형된 방법도 살펴볼 수 있습니다.

질문에 답변하고 추가 답변을 알아보려면 http://splunkbase.com을 참조하십시오.

모니터링 방법모니터링은 데이터에서 무슨 일이 일어나고 있는지 확인하는 데 도움이 됩니다. 동시 사용자 수가 얼마나 됩니까? 주요 측정값이 시간에 따라 어떻게 변화하고 있습니까?

다양한 조건을 모니터링하는 방법 외에 이 절에서는 검색 명령어를 사용하여 반정형화된 데이터와 정형화된 데이터에서 필드를 추출하는 방법에 대해 설명합니다.

동시 사용자 모니터링

문제특정 시간대의 동시 사용자를 알아야 합니다. 동시 사용자 수를 알면 일부 호스트에 과부하가 걸리는지 확인하고 최고 수요를 충족하도록 리소스를 보다 효율적으로 제공할 수 있습니다.

Exploring Splunk

80

해결책먼저, 검색을 수행하여 관련 이벤트를 검색합니다. 그런 다음 concur-rency 명령어를 사용하여 겹치는 사용자의 수를 찾습니다. 마지막으로 timechart 보고 명령어를 사용하여 시간별 동시 사용자 수에 대한 차트를 표시합니다.

다음 이벤트를 통해 날짜, 시간, 요청 기간 및 사용자 이름을 지정한다고 가정하겠습니다.

5/10/10 1:00:01 ReqTime=3 User=jsmith5/10/10 1:00:01 ReqTime=2 User=rtyler5/10/10 1:00:01 ReqTime=50 User=hjones5/10/10 1:00:11 ReqTime=2 User=rwilliams5/10/10 1:00:12 ReqTime=3 User=apond

1:00:01에 세 개의 동시 요청(jsmith, rtyler, hjones), 1:00:11에 두 개의 동시 요청(hjones, rwilliams), 1:00:12에 세 개의 동시 요청(hjones, rwilliams, apond)이 있음을 알 수 있습니다.

다음 검색을 사용하여 특정 시간의 최대 동시 사용자 수를 표시할 수 있습니다.

<your search here> sourcetype=login_data| concurrency duration=ReqTime | timechart max(concurrency)

concurrency 명령어에 대해 자세히 알아보려면 http://splunk.com/goto/book#concurrency를 참조하십시오.

비활성 호스트 모니터링

문제어느 호스트에서 데이터 송신을 중단했는지 확인해야 합니다. 로그를 생성하는 애플리케이션이나 서버에 장애가 발생하거나 중단된 경우 호스트에서 이벤트 로깅을 중단할 수 있습니다. 이 경우 종종 심각한 문제를 나타냅니다. 호스트에서 이벤트 로깅을 중단하는 경우에는 검토가 필요합니다.

해결책Splunk 인덱스의 host, source 및 source type에 대한 상위 수준의 정보를 제공하는 metadata 명령어를 사용합니다. 이 명령어는 요약 대시보드를 만드는 데 사용됩니다. Splunk 인덱스에서 이벤트를 검색하는 것이 아니라 metadata 명령어를 호출하기 때문에 이 검색은 파이프 문자로 시작합니다.

6장: 모니터링 및 경고 방법

81

다음 검색을 사용하여 호스트에 대한 정보를 가져와서 가장 최근에 참조된 호스트가 먼저 오도록 정렬하고, 판독할 수 있는 시간 형식으로 표시합니다.

| metadata type=hosts | sort recentTime | convert ctime(recentTime) as Latest_Time

어느 호스트에서 최근에 데이터를 로깅하지 않았는지 바로 표시됩니다.

metadata 명령어에 대해 자세히 알아보려면 http://splunk.com/goto/book#metadata를 참조하십시오.

분류된 데이터에 대한 보고

문제적절하게 정의되지 않은 데이터 세그먼트에 대해 보고해야 합니다.

해결책데이터의 특정 부분을 검색하려면 태그 및 event type을 사용하여 이벤트를 분류합니다. 태그가 간단하지만 event type이 더 강력합니다(태그와 event type은 5장에 설명되어 있습니다).

데이터 분류가 어떻게 해서 모니터링에 포함되는지 의아해 하실 수도 있습니다. 이는 태그와 event type을 사용하여 데이터를 분류할 때 오늘 현재의 데이터만 분류하는 것이 아니라 Splunk에서 이와 같은 데이터가 나타날 때마다 데이터를 분류하도록 설정하기 때문입니다. Splunk에서 일정한 특성을 지닌 데이터를 지켜보도록 설정합니다. 태그와 event type을 전국을 대상으로 데이터 지명수배(APB)를 내리는 것과 같습니다.

태그 사용태그를 사용하여 간단한 필드=값 쌍을 분류할 수 있습니다. 예를 들어, 필드 값에 태그를 지정하여 host=db09가 database 호스트인 이벤트를 분류합니다. 이렇게 하면 값이 database인 tag::host 필드가 host=db09인 이벤트에 만들어집니다. 그런 다음 이 사용자 지정 분류를 사용하여 보고서를 생성할 수 있습니다.

다음은 태그를 사용하는 두 가지 예입니다.

상위 10개의 호스트 유형 표시(막대 또는 파이 차트에 적합)... | top 10 tag::host

여러 호스트 유형의 시간별 성능 비교... | timechart avg(delay) by tag::host

Exploring Splunk

82

Event Type 사용태그 대신 event type을 사용하여 이벤트를 분류하는 경우 단순히 "필드=값"의 형태만 사용할 수 있는 것은 아닙니다. 부울 연산, 문구 일치, 와일드 카드 등 search 명령어의 모든 기능을 사용할 수 있습니다. “host=db* OR host=orcl*”의 정의를 사용하여 database_host라는 event type을 만들고 web_host라고 하는 또 다른 event type도 만들 수 있습니다. 태그의 경우와 동일한 검색을 반복하십시오. 단, tag::host를 eventtype으로 대치합니다. 예를 들어, 상위 10개의 event type을 표시하려면 다음 명령어를 사용합니다.

... | top 10 eventtype

event type은 호스트, 사용자 유형, 오류 코드 등 특정 차원에 한정되지 않기 때문에 모두 공통된 네임스페이스에 하나로 포함됩니다. top eventtypes에 대한 검색은 database_host 및 web_error를 반환합니다. 하지만 이는 비교 대상이 아닙니다. 다행히 event type에 대해 공통적인 이름 지정 규약을 사용할 경우 eval 명령어를 사용하여 어느 event type을 보고할 것인지 필터링할 수 있습니다.

예를 들어, _host로 끝나는 event type만을 사용하여 (시간 차트로 표시되는) 여러 호스트 유형의 성능을 비교해 보십시오.

…| eval host_types = mvfilter(match(eventtype, “_host$”)) | timechart avg(delay) by host_types

오늘의 상위 값을 지난 달의 상위 값과 비교

문제오늘 현재 상위 N개의 값을 확인하고 지난 달의 값과 비교해야 합니다. 이렇게 하면 어느 제품이 갑자기 인기가 많아지고 또는 어느 데이터베이스 오류가 많이 발생하는지 알아볼 수 있습니다.

해결책이 해결책의 경우 음악 데이터의 예를 사용하여 오늘 현재 가장 많이 연주되는 상위 10대 아티스트 및 각 아티스트의 월 평균 순위를 표시하겠습니다. 이벤트에 artist 필드 및 특정 시간에 판매된 개수를 알려주는 sales 필드가 있다고 가정합니다. sales의 합계 sum(sales)를 측정 기준으로 사용하지만 다른 측정 기준도 사용할 수 있습니다.

전체 검색은 처음에는 복잡해 보이지만 다음과 같이 간단한 단계로 구분할 수 있습니다.

1. 아티스트별 순위를 가져옵니다.

2. 아티스트별 일일 순위를 가져와 결과에 추가합니다.

3. stats를 사용하여 아티스트별 월간 및 일일 순위를 결합합니다.

4. sort 및 eval을 사용하여 결과의 형식을 지정합니다.


83

월간 순위 가져오기

다음 검색을 사용하여 상위 10개의 아티스트별 최대 판매량을 찾습니다.sourcetype=music_sales earliest=-30d@d | stats sum(sales) as month_sales by artist | sort 10 - month_sales| streamstats count as MonthRank

earliest=-30d@d는 Splunk에서 30일 전에 시작된 이벤트를 검색하도록 합니다(다시 말해 지난 달의 이벤트를 가져옵니다). stats는 각 아티스트의 판매량 합계를 month_sales 필드로 계산합니다. 이제 각 아티스트에 대해 다음과 같은 두 개의 컬럼과 하나의 행이 표시됩니다. month_sales 및 artist. sort 10 – month_sales에서는 가장 큰 10개 month_sales 값만 있는 행을 가장 큰 값에서 가장 작은 값의 정렬된 순서로 유지합니다. streamstats 명령어는 (stats 명령어와 같이 전체 결과가 아니라) 이벤트가 표시된 시간에 현재 집계 값을 기준으로 각 이벤트에 하나 이상의 통계치를 추가합니다. streamstats count as Mon-thRank는 첫 번째 결과 MonthRank=1, 두 번째 결과 MonthRank=2, 등을 효과적으로 할당합니다.

어제의 순위 가져오기

어제의 순위를 가져오려면 월간 순위 검색에서 다음과 같이 세 가지를 약간씩 변경합니다.

• 어제의 순위를 가져오기 위해 earliest의 값을 -30d@d에서 -1d@d로 변경합니다.

• 검색에 나오는 모든 "month"를 "day"로 변경합니다.

• 검색을 append 명령어로 둘러싸 첫 번째 검색으로 나타난 결과에 결과가 추가되도록 합니다. append [ search sourcetype=music_sales earliest=-1d@d | stats sum(sales) as day_sales by artist | sort 10 - day_sales | streamstats count as DayRank ]

stats를 사용하여 아티스트별 월간 및 일일 순위 결합

stats 명령어를 사용하여 첫 번째 월간 순위와 일일 순위를 하나의 결과에 넣어 아티스트별 결과를 결합합니다.

stats first(MonthRank) as MonthRank first(DayRank) as DayRank by artist

Exploring Splunk

84

출력 형식 지정

마지막으로 월간 순위와 일일 순위 간의 차이를 계산하고, 일일 순위를 기준으로 결과를 정렬하고, 음악 빌보드 순서(순위, 아티스트, 순위 변동, 과거 순위)로 필드를 표시합니다.

eval diff=MonthRank-DayRank | sort DayRank | table DayRank, artist, diff, MonthRank

요약

모든 명령을 종합하면 검색은 다음과 같은 모양이 됩니다. sourcetype=music_sales earliest=-30d@d | stats sum(sales) as month_sales by artist | sort 10 - month_sales | streamstats count as MonthRankappend [ search sourcetype=music_sales earliest=-1d@d | stats sum(sales) as day_sales by artist | sort 10 - day_sales | streamstats count as DayRank ]| stats first(MonthRank) as MonthRank first(DayRank) as DayRank by artist| eval diff=MonthRank-DayRank | sort DayRank | table DayRank, artist, diff, MonthRank

변형여기서는 판매량의 합 sum(sales)을 측정 기준으로 사용했지만 min(sales)와 같은 측정 기준을 사용하거나, 시간 범위를 변경하여 지난 주와 이번 주를 비교할 수도 있습니다.

streamstats 명령어에 대해 자세히 알아보려면 http://splunk.com/goto/book#streamstats를 참조하십시오.

1시간에 10% 감소한 측정값 찾기

문제지난 시간 동안 10% 감소한 측정값을 확인하려고 합니다. 이는 고객 감소, 웹 페이지 보기 감소, 데이터 패킷 감소 등을 의미할 수 있습니다.


85

해결책지난 시간 동안 감소했는지를 보려면 지난 2시간 동안의 결과를 살펴봐야 합니다. 두 시간 동안의 이벤트를 보고 각 시간의 측정값을 따로 계산한 다음 두 시간 사이에 측정값이 얼마나 변화했는지 확인하겠습니다. 여기서 확인하는 측정값은 두 시간 전과 지난 시간 사이의 이벤트 수입니다. 다음 검색에서는 이전 시간의 호스트별 개수를 현재 시간과 비교하고 개수가 10% 이상 감소한 경우를 필터링합니다.

earliest=-2h@h latest=@h | stats count by date_hour,host | stats first(count) as previous, last(count) as current by host | where current/previous < 0.9

첫 번째 조건(earliest=-2h@h latest=@h)은 정시에 맞춰(오후 2:01-4:01이 아니라 오후 2-4시) 두 시간 분량의 데이터를 검색합니다. 그런 다음 시간별 및 호스트별 이벤트 수를 계산합니다. 두 시간(두 시간 전과 한 시간 전)만 있기 때문에 stats first(count)에서는 두 시간 전의 개수를 반환하고 last(count)에서는 한 시간 전의 개수를 반환합니다. where 절은 현재 시간의 개수가 이전 시간의 개수보다 90% 미만인(즉, 10% 이상 감소를 보여주는) 이벤트만을 반환합니다.

한 가지 연습으로서 시간 범위가 자정을 넘을 경우 이 검색에 어떤 문제가 생기는지 생각해 보십시오. 첫 번째 stats 명령어에 first(_time)을 추가하고 새 값을 기준으로 정렬하여 문제를 수정하는 방법을 알고 계십니까?

변형이벤트의 수 대신 평균 지연 시간이나 초당 최소 바이트 수 등 다른 측정값을 사용하고 일별 등과 같은 다른 시간 범위도 고려해 보십시오.

주간 결과를 차트로 작성

문제이번 주의 결과를 지난 주와 비교해야 합니다.

해결책먼저 모든 이벤트에 대해 검색을 실행하고 이벤트가 이번 주 또는 지난 주에 속하는지 표시합니다. 그런 다음 지난 주 이벤트의 시간 값을 이번 주의 이벤트처럼 보이도록 (그래서 그래프가 동일한 시간 범위에 겹쳐 표시되도록) 조정합니다. 마지막으로 차트를 만듭니다.

다음과 같이 해당 주의 처음부터 시작하여 지난 두 주의 결과를 가져오겠습니다.

earliest=-2w@w latest=@w

Exploring Splunk

86

이벤트를 지난 주 또는 이번 주의 이벤트로 표시합니다.eval marker = if (_time < relative_time(now(), “-1w@w”), “last week”, “this week”)

지난 주의 이벤트를 이번 주에 발생한 것처럼 조정합니다.eval _time = if (marker==”last week”, _time + 7*24*60*60, _time)

우리가 만든 week를 표시하는 marker 필드를 이용하여, 주별 다운로드한 평균 바이트 수 timechart와 같은 원하는 측정값을 차트로 나타냅니다.

timechart avg(bytes) by marker

레이블( "last week" 및 "this week"라는 두 개의 열이 지정된 timechart가 만들어집니다.

종합하면 다음과 같습니다. earliest=-2w@w latest=@w | eval marker = if (_time < relative_time(now(), “-1w@w”), “last week”, “this week”) | eval _time = if (marker==”last week”, _time + 7*24*60*60, _time) | timechart avg(bytes) by marker

이 패턴을 자주 사용하는 경우 매크로로 저장하여 재사용할 수 있습니다.

변형일별 등 다른 기간을 다른 차트 유형을 사용하여 비교해 보십시오. avg(bytes)와는 다른 차트를 시도해 봅니다. 또는 latest 값(기본 값이 "now")이 아니라 earliest=-2w를 설정하고 relative_time() 인수를 –1w로 변경하여 주 경계에 딱 떨어지지 않고 걸치도록 해보십시오.

데이터의 급등 부분 식별

문제데이터에서 급등 부분을 찾으려고 합니다. 급등 부분을 보면 일부 측정값의 급격한 증가 또는 감소를 나타내는 최고점(또는 최저점)이 어디인지를 알 수 있습니다. 트래픽 급등, 판매 급등, 반품 수 급등, 데이터베이스 로드 급등 등 주의를 기울이고 있는 급등 현상을 지켜본 다음 적절한 조치를 취해야 합니다.


87

해결책이동 추세선을 사용하면 급등 부분을 찾는 데 도움이 됩니다. 검색을 실행하고 추세선을 만들려고 하는 필드를 사용하여 trendline 명령어를 실행합니다.

예를 들어, 웹 액세스 데이터에 대해 다음과 같이 bytes 필드의 평균을 차트로 표시할수 있습니다.

sourcetype=access* | timechart avg(bytes) as avg_bytes

bytes의 마지막 5개 값의 단순이동평균(sma)에 대한 차트에 다른 선/막대 계열을 추가하려면 다음 명령을 사용하십시오.

trendline sma5(avg_bytes) as moving_avg_bytes

급등 부분을 확실하게 식별하기 위해 현재 값이 이동평균의 두 배 이상인 경우 급등 부분에 대한 추가 계열을 추가할 수도 있습니다.

eval spike=if(avg_bytes > 2 * moving_avg_bytes, 10000, 0)

여기서 10000은 임의의 값으로, 급등 부분으로 인식되는 데이터와 관련된 값을 선택해야 합니다. Y축을 로그 눈금 형식으로 바꾸는 것도 도움이 됩니다.

이 명령들을 통합하면 다음과 같은 검색이 됩니다.sourcetype=access* | timechart avg(bytes) as avg_bytes| trendline sma5(avg_bytes) as moving_avg_bytes| eval spike=if(avg_bytes > 2 * moving_avg_bytes, 10000, 0)

변형위에서는 마지막 5개의 결과(sma5)에 대한 단순이동평균을 사용했습니다. 다른 값(예를 들어, sma20), 그리고 지수이동평균(ema)과 가중이동평균(wma) 등과 같은 다른 이동평균 유형을 고려해 보십시오.

또는 모든 차트를 작성하지 않고 위의 eval을 where 절로 대치하여 결과를 필터링할 수 있습니다.

... | where avg_bytes > 2 * moving_avg_bytes

그리고 테이블 뷰나 경고로 표시하여 avg_bytes가 급등한 시간만 표시할 수 있습니다.

trendline 검색 명령어에 대해 자세히 알아보려면 http://splunk.com/goto/book#trendline를 참조하십시오.

Exploring Splunk

88

시간 기반 차트 압축

문제데이터의 여러 추세를 작은 공간에 시각화하려고 합니다. 이러한 경우 스파크라인(결과 테이블의 셀 내에 표시되는 작은 시간 기반 차트)을 사용할 수 있습니다. 스파크라인은 Edward Tufte에 의해 개발되었으며 Splunk 4.3에 적용했습니다.

해결책테이블에 스파크라인을 생성하려면 stats 또는 chart 함수를 spar-kline() 함수로 둘러싸면 됩니다.

여기서는 웹 액세스 로그의 예를 사용합니다. 각 웹 페이지가 반응하는 데 걸리는 시간을 보여주는 작은 그래프를 만들려고 합니다(spent 필드가 웹 페이지를 제공하는 데 걸리는 시간이라고 가정합니다). 많은 페이지가 있기 때문에 가장 많이 액세스되는(즉, count 값이 가장 큰) 페이지를 찾기 위해 정렬합니다. 5m은 Splunk에서 스파크라인의 5분 단위로 세분하여 표시하도록 합니다.

sourcetype=access* | stats sparkline(avg(spent),5m), count by file | sort - count

지난 시간에 대해 이 검색을 실행합니다. 각 페이지가 로드되는 데 걸린 평균 시간을 보여주는 일련의 미니 그래프가 생성됩니다.

변형avg가 아닌 다른 함수를 사용해 보십시오. 5m와 다른 시간 간격을 사용해 보십시오. 5m을 제거하는 경우에는 Splunk에서 검색 시간 범위에 적절한 값을 자동으로 선택합니다.

XML 또는 JSON 내 필드에 대한 보고

문제XML 또는 JSON 형식으로 지정된 데이터에 대해 보고해야 합니다.

해결책Splunk 4.3에 소개된 spath 명령어를 사용하면 XML 및 JSON 형식 데이터에서 값을 추출할 수 있습니다. 이 예에서는 책 데이터의 source type이 XML 또는 JSON이라고 가정합니다. XML 또는 JSON을 이벤트의 텍스트로 반환하는 검색을 실행하고 다음과 같이 spath 명령어를 사용하여 저자 이름을 추출합니다.

sourcetype=books | spath output=author path=catalog.book.author


89

path 인수 없이 호출하면 spath는 처음 5000자(설정 가능) 내의 모든 필드를 추출하고 각 경로 요소에 대해 필드를 만듭니다. 경로는 foo.bar.baz와 같은 형태가 됩니다. 각 레벨에 중괄호(예: foo{1}.bar)로 표시되는 어레이 인덱스(선택사항)를 포함할 수 있습니다. 모든 어레이 인수는 빈 중괄호(예: foo{})로 표시할 수 있습니다. XML 쿼리의 마지막 레벨에는 중괄호(예: foo.bar{@title})로 둘러싸이고 @가 앞에 붙은 속성 이름을 포함할 수도 있습니다.

필드를 추출한 후 필드에 대해 보고할 수 있습니다.... | top author

변형이전 검색 명령어 xmlkv는 단순 XML 키-값 쌍을 추출합니다. 예를 들어, ... | xmlkv를 <foo>bar</foo>와 같은 값을 가진 이벤트에 대해서 호출하면 bar라는 값을 가진 foo 필드가 만들어집니다. XML에서 필드를 추출하는 또 다른 이전 명령어는 xpath입니다.

이벤트에서 필드 추출

문제패턴을 검색하고 이벤트에서 해당 정보를 추출하려고 합니다.

해결책일시적으로 필요해서 혹은 source 또는 source type이 일반적이지 않는 특정 검색에 적용하기 위해 필드를 추출할 때 가장 편하고 빠르게 추출하는 방법은 필드 추출 명령어를 사용하는 것입니다.

정규식

rex 명령어를 사용하면 정규식으로 필드를 쉽게 추출할 수 있습니다. 예를 들어, 이메일 데이터에서 다음과 같은 검색은 rex 명령어를 사용해 이메일 데이터로부터 from 필드와 to 필드를 추출합니다.

sourcetype=sendmail_syslog | rex “From: (?<from>.*) To: (?<to>.*)”

구분자

구분자를 사용하여 여러 필드를 추출할 때는 extract 명령어를 사용합니다.

다음과 같은 이벤트를 가정해 보겠습니다.|height:72|age:43|name:matt smith|

다음과 같은 방법으로 구분자를 없애 event 추출해 냅니다.... | extract pairdelim=”|” kvdelim=”:”

Exploring Splunk

90

결과는 예상한 대로 다음과 같이 나옵니다. height=72, age=43, and name=matt smith.

변형multikv, spath 또는 xmlkv도 사용해 보십시오.

경고 방법5장에서 언급한 바대로 경고는 다음 두 부분으로 구성됩니다.

• 조건: 알고 싶은 관심사항

• 작업: 관심사항이 발생할 때 수행하는 작업

이 외에도 경고 조절을 통해 동일한 유형의 경고가 과다하게 발생되는 현상을 방지할 수 있습니다.

예:

• 서버 중 하나가 특정 비중 이상으로 부하에 걸렸을 때마다 이메일을 받고 싶습니다.

• 모든 서버가 특정 비중 이상으로 부하에 걸렸을 때 이메일을 받고 싶은데, 단, 이메일이 계속 쌓이는 것을 막기 위해 24시간 단위로 경고 빈도를 조절했으면 합니다.

사전 정의된 부하 조건에 걸렸을 때 이메일 경고 발송

문제한 서버 부하가 80% 이상일 때 이메일 알림을 받고 싶습니다.

해결책다음 검색은 평균 부하가 80% 이상인 이벤트를 검색하고, 각 호스트의 최대값을 계산합니다. “top” source type은 Splunk Unix 앱(splunkbase.com에서 다운로드 가능)에서 사용하는 유형으로, 이 source type은 Unix top 명령어를 통해 5초마다 데이터를 가져옵니다.

sourcetype=top load_avg>80 | stats max(load_avg) by host

이 경고는 다음과 같이 설정합니다. 자세한 지침은 5장을 참조하십시오.

• 경고 조건: 하나 이상의 검색 결과 반환 시 경고 발생

• 경고 작업: "서버 부하 80% 이상" 제목으로 경고 이메일 발송

• 작업 빈도: 1시간


91

변형경고 조건과 작업 빈도를 변경합니다.

웹 서버 성능이 느려질 경우 경고 발생

문제웹 서버의 95백분위수 응답 시간이 특정 밀리초 이상일 때마다 알림 이메일을 받고 싶습니다.

해결책다음 검색은 웹 로그 이벤트를 검색하여 각 웹 주소(uri_path)의 95백분위수 응답 시간을 계산한 후, 95백분위수가 200밀리초 미만인 모든 값을 필터링하여 제외합니다.

sourcetype=weblog

| stats perc95(response_time) AS resp_time_95 by uri_path

| where resp_time_95>200

다음과 같이 경고를 설정합니다.

• 경고 조건: 검색 결과가 X개(경고가 발생하도록 설정하고 싶은 느린 웹 요청 개수) 이상 반환될 때 경고 발생

• 경고 작업: "웹 서버 실행 느림" 제목으로 경고 이메일 발송 만약 클라우드에서 실행 중인 경우(예를 들어, Amazon EC2™) 새로운 서버 인스턴스를 시작할 수 있습니다.

• 작업 빈도: 1시간

불필요한 EC2 인스턴스 종료

문제더 이상 사용하지 않는 EC2 인스턴스는 종료하고 싶습니다.

해결책다음 검색은 웹로그 이벤트를 검색해서 (검색이 실행되는 시간 동안) 요청 수가 10000개 미만인 호스트 테이블을 반환합니다.

sourcetype=weblog | stats count by host | where count<10000

Exploring Splunk

92

다음과 같이 경고를 설정합니다.

• 경고 조건: 검색 결과가 X개(경고가 발생하도록 설정하고 싶은 호스트 수) 이상 반환될 때 경고 발생.

• 경고 작업: 부하 분산 장치로부터 해당 서버를 제거하고 서버를 종료시키는 스크립트를 트리거합니다.

• 작업 빈도: 10분

모니터링을 경고로 변환이 장에서 소개하는 모니터링 방법은 보고서 작업에 유용한 내용들입니다. 경고 설정 기본사항들을 숙지하면 Splunk를 통해 상황을 모니터링하는 것이 훨씬 수월해집니다.

여기서는 모니터링을 경고로 변환하는 몇 가지 방법을 간략하게 살펴보겠습니다.

동시 사용자 모니터링이 방법은 사용자 지정 경고 조건을 “where max(concurrency) > 20”으로 설정해서 검색하면 경고로 변환됩니다. 이 경고는 너무 많은 사용자가 동시에 로그인할 때 발생됩니다.

변형: 평균 동시 사용자 수를 계산해서 최대값이 평균의 2배일 경우 경고.

비활성 호스트 모니터링where now() - recentTime > 60*60으로 경고 조건을 사용자 지정하면 한 시간 이상 동안 호스트에 수신되는 요청이 없을 경우 경고가 발생합니다.

오늘의 최대값과 지난 달의 최대값 비교where diff < -10으로 경고 조건을 사용자 지정하면 아티스트가 지난 달에는 상위 10위 안에 들지 않았는데 오늘 1위를 한 경우 경고가 발생됩니다.

변형: 이와 동일한 방법으로 HTTP 상태 코드를 모니터링하여 지난 달과 비교해 상태 코드(예: 404)가 갑자기 많아지거나 적어지는 경우 이를 보고합니다.

1시간에 10% 감소한 측정값 찾기이 방법은 경고를 다루면서 이미 알맞게 설정하였습니다. 이떤 이벤트가 보일 경우 경고가 발생됩니다.

변형: N 이상의 감소세가 연이어 보일 경우에만 경고가 발생됩니다.


93

이동 추세선 표시 및 급등 부분 식별이 방법은 경고를 다루면서 이미 알맞게 설정하였습니다. 이떤 이벤트가 보일 경우 경고가 발생됩니다.

변형: 일정한 시간 동안(예: 5분)에 N개 이상의 급등 부분이 보일 경우에만 경고가 발생합니다.

나머지 모니터링 방법을 연습삼아 경고 작업을 해보시기 바랍니다.

95

7 이벤트 그룹화다음의 방법들은 이벤트를 그룹화하면 해결될 수 있는 실제 흔히 접할 수 있는 몇 가지 문제들에 대한 빠른 해결책입니다.

소개이벤트를 그룹화하는 방법은 여러 가지가 있습니다. 그 중 가장 일반적인 방법은 transaction 또는 stats 명령어를 사용하는 것입니다. 그렇다면 어떤 경우에 transaction을 사용하고, 어떤 경우에 stats를 사용할까요?

기본적으로 stats를 사용할 수 있다면 stats를 사용하십시오. 특히 분산된 환경에서 transaction보다 훨씬 빠릅니다. 하지만 속도가 빠른 반면 일부 제약이 있습니다. 이벤트가 최소 하나 이상의 공통 필드 값을 가지고 있고, 다른 어떤 제약 조건도 필요 없는 경우에만 stats로 이벤트를 그룹화할 수 있습니다. 일반적으로 원시 이벤트 텍스트는 무시됩니다.

stats와 마찬가지로 transaction 명령어도 공통 필드 값을 기반으로 이벤트를 그룹화합니다. 하지만 다른 점은 트랜잭션의 총 시간 범위, 해당 트랜잭션 내에서 이벤트 간 지연, 시작/종료 필수 이벤트와 같은 보다 복잡한 제약 조건을 사용할 수 있다는 점입니다. stats와 달리 transaction은 원시 이벤트 텍스트와 원래 이벤트의 필드 값을 유지합니다. 하지만 duration(트랜잭션에서 가장 오래된 이벤트와 가장 최신 이벤트 간의 _time 필드 델타 값)과 eventcount(트랜잭션의 전체 이벤트 수)를 제외한, 그룹화된 이벤트들에 대한 다른 모든 통계값은 계산하지 않습니다.

transaction 명령어는 다음 두 가지 상황에서 가장 유용합니다.

• 서로 다른 트랜잭션들을 구분하는 데 고유 필드 값(식별자라고도 함)만으로는 충분하지 않은 경우. 이 경우는 예를 들면, 웹 세션을 식별하는데 cookie나 clientip를 사용하는 경우와 같이 식별자가 재사용될 수 있는 경우를 말합니다. 이 경우 트랜잭션을 만들기 위해서 timespan이나 pause 등을 사용해야 합니다. 또 DHCP 로그에서와 같이 식별자가 재사용되는 경우, 시작하고 끝 맺는 특정 메시지를 이용하여 트랜잭션을 식별할 수도 있습니다.

• 이벤트의 구성 필드에 대한 분석이 아닌, 이벤트의 원시 텍스트를 보는 것이 더 바람직한 경우.

Exploring Splunk

96

다시 말해서, 이 두 경우 중 어떤 경우도 해당되지 않을 경우에는 stats를 사용하는 것이 더 좋습니다. 그것은 일반적으로 stats의 검색 성능이 transaction보다 더 뛰어나기 때문입니다. 보통 고유한 식별자가 있어 stats를 사용할 수 있습니다.

예를 들어, 고유한 식별자 trade_id로 식별되는 거래 기간에 대한 통계를 계산하려면 다음과 같은 검색으로 동일한 답을 구할 수 있습니다.

… | transaction trade_id | chart count by duration… | stats range(_time) as duration by trade_id | chart count by duration

두 번째 검색이 더 효율적입니다.

그런데, trade_id가 재사용될 수 있고 "END"라는 텍스트를 통해 트랜잭션이 끝났음을 알 수 있는 상황이라면, 적용할 수 있는 유일한 방법은 다음과 같습니다.

… | transaction trade_id endswith=END | chart count by duration

종료 조건 대신, trade_id 값이 10분 안에 재사용되지 않을 경우 가장 바람직한 해결책은 다음과 같습니다.

… | transaction trade_id maxpause=10m | chart count by duration

마지막으로 성능에 대해 간략히 설명하겠습니다. 어떤 검색 명령어를 사용하든 기본 검색을 가능한 구체적으로 하는 것이 검색 성능을 높이는 데 있어 무엇보다도 중요합니다. 다음 검색을 살펴보겠습니다.

sourcetype=x | transaction field=ip maxpause=15s | search ip=1.2.3.4

여기서 우리는 sourcetype=x의 모든 이벤트를 검색하려고 합니다. 이 검색 명령어는 트랜잭션을 만든 후 ip=1.2.3.4를 가지고 있지 않은 모든 이벤트는 버립니다. 모든 이벤트가 동일한 ip 값을 가지고 있는 경우 이 검색은 다음과 같이 바꿀 수 있습니다.

sourcetype=x ip=1.2.3.4 | transaction field=ip maxpause=15s

이 검색은 필요한 이벤트만 검색하기 때문에 훨씬 효율적입니다. 이에 대한 자세한 내용은 나중에 나오는 이 장의 "특정 트랜잭션 찾기"를 참조하십시오.

7장: 이벤트 그룹화

97

방법

필드 이름 통합

문제동일한 식별자에 대해 서로 다른 필드 이름을 사용하는 여러 데이터 소스로부터 트랜잭션을 작성해야 합니다.

해결책일반적으로 다음과 같은 공통 필드로 트랜잭션을 조인할 수 있습니다.

… | transaction username

하지만 username 식별자가 서로 다른 데이터 소스에서 여러 이름(로그인, 이름, 사용자, 소유자 및 기타)으로 불리는 경우 해당 필드 이름들을 정규화해야 합니다.

sourcetype A는 field_A만 가지고 있고 sourcetype B에는 field_B만 가지고 있는 경우, field_Z라고 하는 새 필드를 만드십시오. 이 필드는 이벤트에 어떤 것이 있느냐에 따라 field_A이거나 field_B가 됩니다. field_Z의 값에 따라 트랜잭션을 작성할 수 있습니다.

sourcetype=A OR sourcetype=B | eval field_Z = coalesce(field_A, field_B) | transaction field_Z

변형이벤트에 있는 어떤 필드든 이 필드를 사용하기 위해 coalesce를 호출했습니다. 하지만 이벤트를 통합하는 데 사용할 필드를 결정하기 위해 서는 특정 논리를 사용해야 하는 경우가 있습니다. 이 때 eval’s if 또는 case 함수가 도움이 될 수 있습니다.

불완전한 트랜잭션 찾기

문제로그인은 했지만 로그아웃하지 않은 사용자와 같이 불완전한 트랜잭션에 대해 보고해야 합니다.

Exploring Splunk

98

해결책로그인으로 시작해서 로그아웃으로 끝난 사용자 세션을 검색한다고 가정해 보겠습니다.

… | transaction userid startswith=”login” endswith=”logout”

로그인은 했지만 로그아웃하지 않은 사용자와 같이 불완전한 트랜잭션을 보여주는 보고서를 만들고 싶다면 어떻게 해야 할까요?

transaction 명령어는 closed_txn이라는 내부 부울 필드를 생성합니다. 이 필드는 해당 트랜잭션의 불완전 여부를 나타냅니다. 일반적으로 불완전한 트랜잭션은 반환되지 않지만, keepevicted=true로 지정하면 이처럼 "제거된(evicted)" 일부 트랜잭션까지도 함께 반환할 수 있습니다. 제거된 트랜잭션은 어떤 트랜잭션 매개 변수와도 일치하지 않는 이벤트의 집합입니다. 예를 들어, 제거된 트랜잭션에서 시간 요구사항이 충족되지 않는 경우를 들 수 있습니다. 모든 요구사항을 충족하는 트랜잭션은 필드 closed_txn을 1(불완전한 트랜잭션의 경우 0)로 설정함으로써 완전한 것으로 표시됩니다. 불완전한 트랜잭션을 찾는 패턴은 일반적으로 다음과 같습니다.

… | transaction <conditions> keepevicted=true | search closed_txn=0

어쨋든, 이 경우에 쓸 수 있는 묘안이 하나 있습니다. 이벤트는 최신 것부터 오래된 것의 순서로 처리되기 때문에, endswith 조건이 맞지 않으면 closed_txn=0으로 세팅되지 않습니다. 기술적으로 데이터 프로세싱의 관점에서 말하자면, endswith 조건이 트랜잭션을 시작시킵니다. 이를 위해서 closed_txn필드에 기반한 트랜잭션을 필터링해야 합니다. 뿐만 아니라 트랜잭션에 login과 logout이 둘 다 없어야 합니다.

… | transaction userid startswith=”login” endswith=”logout” keepevicted=true | search closed_txn=0 NOT (login logout)

변형이 해결책에 대한 변형은 stats를 사용하는 것입니다. 단 트랜잭션이 startswith/endswith 조건이나 시간 제약 사항이 없는 경우로, 실제 transaction을 유지하는데는 신경을 쓰지 않는 경우입니다. 이 예에서는 로그아웃하지 않은 사용자들의 userid를 원합니다.

먼저, 로그인 및 로그아웃 이벤트에 대해 검색합니다.action=”login” OR action=”logout”


99

그런 다음, 각 userid에 대해 stats를 사용하여 userid당 보여지는 ac-tion을 추적합니다. 이벤트는 시간 역순으로 정렬되므로 맨 위에 나오는 작업이 가장 최근 작업입니다.

… | stats first(action) as last_action by userid

마지막으로 가장 최근 사용자 작업이 로그인인 이벤트만 유지합니다.… | search last_action=”login”

이렇게 하면 최근 작업이 로그인인 모든 userid 값 리스트를 볼 수 있습니다.

트랜잭션 내의 시간 계산

문제하나의 트랜잭션 내의 이벤트 간 기간(시간)들을 알아야 합니다.

해결책가장 기본적인 방법은 eval 명령어를 사용하여 서로 다른 기간을 측정하는 데 필요한 시점 단위 시간을 표시한 후, transaction 명령 뒤에 eval을 사용하여 이러한 시점 간의 시간 길이를 계산하는 것입니다.

참고: 이 장에서는 한 트랜잭션 내의 샘플 이벤트에 event1, event2 등의 번호를 붙입니다.

예를 들어, 4개의 이벤트로 구성된 한 트랜잭션이 있다고 가정합니다. 이 4개의 이벤트는 공통 id 필드로 통합되어 있습니다. 이 상태에서 phase1과 phase2의 기간(시간)을 측정하려고 합니다.

[1] Tue Jul 6 09:16:00 id=1234 start of event. [2] Tue Jul 6 09:16:10 id=1234 phase1: do some work. [3] Tue Jul 6 09:16:40 id=1234 phase2: do some more. [4] Tue Jul 6 09:17:00 id=1234 end of event.

트랜잭션 이벤트의 타임스탬프는 첫 이벤트(event1)에서 가져오게 되며, duration 값은 event4와 event1 사이의 시간 간격이 됩니다.

phase1의 기간을 얻으려면 event2와 event3의 타임스탬프가 표시되어야 합니다. 이 예에서는 eval’s searchmatch 함수가 적당합니다. 지금보다 더 복잡한 상황에도 사용할 수 있는 많은 eval 함수가 있습니다.

Exploring Splunk

100

…| eval p1start = if(searchmatch(“phase1”), _time, null()) | eval p2start = if(searchmatch(“phase2”), _time, null())

이제 실제 트랜잭션을 만들겠습니다.… | transaction id startswith=”start of event” endswith=“end of event”

마지막으로 위에서 계산된 값을 사용하여 각 transaction의 기간을 계산합니다.

…| eval p1_duration = p2start - p1start | eval p2_duration = (_time + duration) - p2start

이 예에서는 추가된 _time(첫 번째 이벤트의 시간)에 의한 마지막 이벤트의 시간을 계산해서 기간을 추가합니다. 마지막 이벤트 시간을 알아냈으면 p2_duration을 통해 마지막 이벤트와 phase2 시작 사이의 시간 차이를 계산합니다.

변형기본적으로 transaction 명령어는 트랜잭션 내 복합 이벤트들 중에서 둘 이상의 이벤트에서 보여지는 필드 값 중 다중값 필드를 만듭니다. 하지만 이러한 값들은 발생순에 따라 정렬된 것이 아닌, 중복값을 삭제하고 하나의 값만 존재하는 상태로 유지됩니다. 예를 들어, 트랜잭션이 4개의 이벤트로 구성되어 있는 경우, 이 각 이벤트는 name 필드(name=matt, name=amy, name=rory, name=amy)를 가지고 있습니다. 즉, 이 4개 이벤트로 구성된 트랜잭션은 “amy”, “matt”, “rory”라는 다중값을 가진 name 필드를 가지게 됩니다. 주의할 것은 이벤트가 발생한 순서를 알 수 없고, 여기서 “amy”가 하나 누락되었다는 점입니다. 전체 값 리스트를 순서대로 유지하려면 mvlist 옵션을 사용하십시오.

다음과 같이 트랜잭션을 작성하고 여기에 속한 이벤트의 시간 리스트를 유지합니다.

… | eval times=_time | transaction id mvlist=”times”

여기서 eval 명령어를 추가하여 시간 차이를 계산할 수 있습니다. 다음, 트랜잭션 내에서 첫 번째 이벤트와 두 번째 이벤트 간의 시간을 계산합니다.

… | eval diff_1_2 = mvindex(times,1) - mvindex(times,0)

최신 이벤트 찾기

문제고유한 각 필드 값의 최신 이벤트를 찾아야 합니다. 예를 들면, 각 사용자가 로그인한 마지막 시간이 언제인지 알아야 하는 경우가 될 수 있습니다.


101

해결책아마 처음에는 transaction 또는 stats 명령어를 사용하려는 생각이 들 것입니다. 예를 들어, 이 검색은 다음과 같이 각 필드 첫 번째 값으로 표시될 고유한 userid를 각각 반환합니다.

… | stats first(*) by userid

이 검색은 동일한 userid를 가지는 이벤트에 해당하는 각 필드의 첫 번째 값을 반환한다는 점에 유의해야 합니다. 즉, 해당 user ID를 가지는 모든 이벤트 집합을 제공합니다. 이것은 우리가 원하던 결과가 아닙니다. 우리가 여기서 원하는 결과는 고유한 userid의 첫 번째 이벤트입니다. 이 값을 얻으려면 dedup 명령어를 사용하면 됩니다.

… | dedup userid

변형고유한 userid의 가장 오래된(최신이 아님) 이벤트를 얻고 싶다면 ded-up 명령어의 sortby 절을 사용합니다.

… | dedup userid sortby + _time

반복 이벤트 찾기

문제보고서와 경고에서 무의미한 정보를 제거하기 위해 반복적으로 발생하는 값을 가진 이벤트를 모두 그룹화하려고 합니다.

해결책다음과 같은 이벤트를 가지고 있다고 가정합니다.

2012-07-22 11:45:23 code=239 2012-07-22 11:45:25 code=773 2012-07-22 11:45:26 code=-1 2012-07-22 11:45:27 code=-1 2012-07-22 11:45:28 code=-1 2012-07-22 11:45:29 code=292 2012-07-22 11:45:30 code=292 2012-07-22 11:45:32 code=-1 2012-07-22 11:45:33 code=444 2012-07-22 11:45:35 code=-1 2012-07-22 11:45:36 code=-1

목표는 7개 이벤트를 얻는 것입니다. 각기 하나의 코드 값이 있습니다. 239, 773, -1, 292, -1, 444, -1. 다음과 같이 transaction 명령어를 사용하려고 시도할 수도 있습니다.

… | transaction code

Exploring Splunk

102

그러나 여기서 transaction 명령은 적절한 도구가 아닙니다. 여러 번의 연속 중복을 신경쓰지 않는다면, 중복을 제거하는 가장 간편한 방법은 dedup을 사용하는 것입니다. 기본적으로 dedup은 모든 중복 사항(지정된 필드에 동일한 값이 있는 경우)을 제거합니다. 하지만 이것이 우리가 원하는 정확한 결과는 아닙니다. 우리는 지금 연속해서 나타나는 중복을 제거하려고 합니다. 이렇게 하려면 dedup에서 consecutive=true 옵션을 사용해 연속적인 중복 사항만을 제거합니다.

… | dedup code consecutive=true

트랜잭션 간 시간

문제사용자가 여러분의 사이트에 얼마만에 방문했는지 등과 같이 트랜잭션 사이의 시간을 알고 싶습니다.

해결책우선 기본 transaction 검색을 통해 지정된 사용자(clientip-cookie 쌍)별로 모든 이벤트를 그룹화하지만, 이 사용자가 10분 동안 비활성 상태일 경우 해당 트랜잭션을 분리합니다.

… | transaction clientip, cookie maxpause=10m

최종적으로 우리의 목표는 각 clientip-cookie 쌍에 대해 트랜잭션의 종료 시간과 더 최근(예를 들면, 반환된 이벤트 순서에서 '이전') 트랜잭션의 시작 시간 사이의 시간 차이를 계산하는 것입니다. 이 시간 차이는 트랜잭션 간의 차이이기도 합니다. 예를 들어, 가장 오래된 시간부터 최근까지 반환된 2개의 유사 트랜잭션이 있다고 가정해 보겠습니다.

T1: start=10:30 end=10:40 clientip=a cookie=xT2: start=10:10 end=10:20 clientip=a cookie=x

이 두 트랜잭션 간의 시간 차이는 T1 시작 시간(10:30)과 T2 종료 시간(10:20)의 차이를 말합니다. 나머지 방법은 이러한 값을 계산하는 방법을 설명합니다.

먼저, 각 트랜잭션의 종료 시간을 계산해야 합니다. 트랜잭션의 타임스탬프는 첫 번째 이벤트가 발생한 시간이고, duration은 트랜잭션 내에서 첫 번째 이벤트와 마지막 이벤트 사이에 경과된 시간(초)을 말합니다.

… | eval end_time = _time + duration


103

그 다음에는 이전(예를 들어, 더 최근) 트랜잭션의 시작 시간을 각 트랜잭션에 더해야 합니다. 이렇게 하면 이전 트랜잭션의 시작 시간과 우리가 계산한 end_time 사이의 차이를 계산할 수 있습니다.

이렇게 계산하려면, streamstats를 사용하여 변동하는 하나의 트랜잭션의 간격(global=false and window=1)에서 보여지는 시작 시간(_time)의 마지막 값을 계산하고, 변동 간격(current=false)의 현재 이벤트는 무시하십시오. 효과적으로 하기 위해 streamstats를 사용해 이전 이벤트 값만 확인합니다. 마지막으로 이 윈도우는 지정된 사용자(clientip-cookie 쌍)에만 적용할 수 있다는 점에 유의해야 합니다.

… | streamstats first(_time) as prev_starttime global=false window=1 current=false by clientip, cookie

이 시점에 해당 필드들은 다음과 유사하게 보일 것 입니다.T1: _time=10:00:06, duration=4, end_time=10:00:10 T2: _time=10:00:01, duration=2, end_time=10:00:03 prev_starttime=10:00:06 T3: _time=10:00:00, duration=0, end_time=10:00:01 prev_starttime=10:00:01

이제 마지막으로 이전 트랜잭션의 시작 시간(prev_starttime)과 지금 계산한 end_time 사이의 시간 차이를 계산합니다. 이 시간 차이는 트랜잭션 간의 차이로, 즉 동일한 사용자(clientip-cookie 쌍)에 의해 두 번 연속 수행된 트랜잭션 사이에 경과된 시간의 양(초)을 말합니다.

… | eval gap_time = prev_starttime – end_time

종합하면 다음과 같습니다.… | transaction clientip, cookie maxpause=10m | eval end_time = _time + duration | streamstats first(_time) as prev_starttime global=false window=1 current=false by clientip, cookie | eval gap_time = prev_starttime - end_time

이제 gap_time 값을 보고할 수 있습니다. 예를 들어, 사용자당 가장 큰 차이와 평균 차이 값은 얼마일까요?

… | stats max(gap_time) as max, avg(gap_time) as avg by clientip, cookie

Exploring Splunk

104

변형요구사항이 단순해 질수록 더 간단하게 이벤트 간 차이를 계산할 수 있습니다. 트랜잭션의 유일한 제약 조건이 startswith 및 endswith인 경우, 즉, 시간 제약 조건(예: maxpause=10m) 또는 필드(예: clien-tip, cookie) 제약 조건이 트랜잭션의 유일한 제약 조건인 경우 간단히 startswith 값과 endswith 값만 바꿔서 트랜잭션 간의 차이를 계산할 수 있습니다.

예를 들어, 다음과 같은 이벤트가 있습니다. 10:00:01 login 10:00:02 logout 10:00:08 login 10:00:10 logout 10:00:15 login 10:00:16 logout

다음과 같이 하지 마십시오.… | transaction startswith=”login” endswith=”logout”

표준 트랜잭션(로그인 후 로그아웃) 사이의 시간 차이를 (로그아웃 후 로그인) 트랜잭션으로 대신할 수 있습니다.

… | transaction endswith=”login” startswith=”logout”

여기서 트랜잭션은 로그아웃 이벤트와 로그인 이벤트 사이의 차이입니다. 따라서 duration을 사용하여 차이 값을 계산할 수 있습니다.

… | stats max(duration) as max, avg(duration) as avg

주어진 이벤트(event A)와 가장 최신 이벤트(event B) 간의 시간 차이 값을 알고 싶은 경우 이벤트 간의 시간 차이를 알 수 있는 변형 방법은 또 있습니다. streamstats를 사용하면 현재 이벤트와 이전 이벤트 간의 차이인 마지막 두 이벤트 간의 시간 범위를 알 수 있습니다.

… | streamstats range(_time) as duration window=2

특정 트랜잭션 찾기

문제특정 필드 값을 가진 트랜잭션만 찾아야 합니다.

해결책모든 트랜잭션의 일반적인 검색은 다음과 같습니다.

sourcetype=email_logs | transaction userid


105

하지만 우리는 지금 필드/값 쌍인 to=root와 from=msmith를 가진 이벤트가 있는 트랜잭션만 식별하려고 합니다. 다음 검색을 사용할 수 있습니다.

sourcetype=email_logs | transaction userid | search to=root from=msmith

이 경우 문제점은 이 sourcetype에서 발생하는 모든 이벤트(수십억 개가 넘을 수도 있음)를 검색하게 되고, 모든 트랜잭션을 작성한 후에 그 데이터의 99%가 결국 휴지통으로 간다는 점입니다. 이것은 느릴 뿐만아니라 비효율적인 작업입니다.

그래서 다음과 같이 수신 데이터를 줄이려고 시도할 수도 있습니다.sourcetype=email_logs (to=root OR from=msmith) | transaction userid | search to=root from=msmith

이렇게 하면 지정된 sourcetype에서 발생하는 이벤트를 모두 비효율적으로 검색하지는 않지만, 이 경우에는 또 다른 두 가지 문제점이 발생합니다. 첫 번째 문제점은 치명적입니다. 즉, 문제를 해결하는 데 필요한 이벤트 중에서 일부만 검색된다는 점입니다. 특히, to 또는 from 필드를 가진 이벤트만 검색하게 됩니다. 이 구문을 사용하면 트랜잭션을 구성하는 다른 모든 이벤트는 누락됩니다. 예를 들어, 전체 트랜잭션이 다음과 같다고 가정하겠습니다.

[1] 10/15/2012 10:11:12 userid=123 to=root [2] 10/15/2012 10:11:13 userid=123 from=msmith [3] 10/15/2012 10:11:14 userid=123 subject=”serious error” [4] 10/15/2012 10:11:15 userid=123 server=mailserver [5] 10/15/2012 10:11:16 userid=123 priority=high

위와 같이 검색하면 subject를 가진 event3 또는 server를 가진 event4가 누락됩니다. 따라서 완전한 트랜잭션을 반환할 수 없습니다.

두 번째 문제점은 to=root는 매우 흔해서 실제로 너무 많은 이벤트가 검색되어 엄청난 트랜잭션을 작성하게 된다는 점입니다.

그럼 다른 해결책이 있을까요? 두 가지 방법이 있습니다. 하위 검색을 사용하는 방법과 searchtxn 명령어를 사용하는 방법이 있습니다.

Exploring Splunk

106

하위 검색 사용

지금 원하는 것은 to=root 또는 from=msmith를 가진 이벤트의 모든 userid 값을 가져오는 것입니다. 최대한 신속하게 후보 userid 값을 가져올 수 있는 더 흔치 않은 조건을 선택합니다. from=msmith는 더 흔치 않다고 가정하겠습니다.

sourcetype=email_logs from=msmith | dedup userid | fields userid

이제 관련 userid 값이 있으니, 다음과 같이 이 값을 포함하는 이벤트만 검색해서 더 효율적으로 해당 트랜잭션을 작성할 수 있습니다.

… | transaction userid

마지막으로 트랜잭션이 to=root 및 from=msmith(userid 값이 다른 to 및 from 값에 사용될 수 있음)를 가지고 있는지 확인하기 위해 해당 트랜잭션을 필터링합니다.

… | search to=root AND from=msmith

종합하면 userid를 외부 검색으로 전달하는 하위 검색으로 첫 번째 검색을 수행합니다.

[search sourcetype=email_logs from=msmith | dedup userid | fields userid ] | transaction userid | search to=root from=msmith

searchtxn 사용

searchtxn("search transaction") 명령어는 상세한 하위 검색 작업을 수행합니다. 이 명령어는 transaction 작성에 필요한 이벤트만 검색합니다. 특히 searchtxn은 transaction에 필요한 필드에 대한 전이 폐쇄(transitive closure)를 하지 않습니다. 트랜잭션에서 이벤트를 찾는 데 필요한 검색을 실행한 후 transaction 검색을 실행하고 최종적으로 지정된 제약 조건으로 그 결과를 필터링합니다. 둘 이상의 필드로 이벤트를 통합하려면 이 하위 검색 해법으로는 곤란합니다. searchtxn은 가장 빠른 결과를 얻기 위해 어떤 속도 조건이 가장 좋은지를 결정합니다. 따라서 to=root 및 from=msmith를 가진 이메일 트랜잭션 검색은 아래와 같이 간단히 수행할 수 있습니다.

| searchtxn email_txn to=root from=msmith


107

그런데 위의 검색에서 email_txn은 무엇일까요? 그것은 Splunk 구성 파일(transactiontype.conf)에 반드시 있어야 하는 트랜잭션 유형의 정의입니다. 이 경우 transactiontype.conf는 다음과 같습니다.

[email_txn] fields=userid search = sourcetype=email_logs

searchtxn 검색을 실행하면 자동으로 다음 검색이 실행됩니다. sourcetype=email_logs from=msmith | dedup userid

이 검색의 결과는 운영을 위해 userids 리스트를 searchtxn에 제공합니다. 그런 다음 또 다른 검색을 실행합니다.

sourcetype=email_logs (userid=123 OR userid=369 OR use-rid=576 ...) | transaction name=email_txn | search to=root from=msmith

이 검색은 searchtxn 검색의 반환 결과에서 "건초 더미 속 바늘"과 같은 트랜잭션을 반환합니다.

참고: transaction 명령어 필드 리스트에 둘 이상의 필드가 있는 경우, searchtxn은 여러 검색을 자동으로 실행해서 필요한 모든 값에 대한 전이 폐쇄를 가져옵니다.

변형searchtxn 명령어로 여러 필드를 탐색해 봅니다. 관련 이벤트를 가져오는 데 관심이 있고, 트랜잭션을 실제 작성하는 데 searchtxn을 원하지 않는 경우에는 eventsonly=true를 사용합니다.

다른 이벤트와 가까이 있는 이벤트 찾기

문제이벤트 전 후의 다른 이벤트를 찾아야 합니다. 루트별 로그인을 검색한 후, 실패한 루트 로그인에 대해 최대 1분까지 뒤로 검색을 하고, 암호 변경을 위해 최대 1분까지 앞으로 검색합니다.

해결책한 가지 해법은 하위 검색을 사용하고 이 시나리오의 최종 인스턴스를 찾는 것입니다. 루트 로그인을 하위 검색하고 starttimeu 및 endtimeu를 반환합니다. 이것은 동일한 src_ip에서 failed_login 또는 pass-

Exploring Splunk

108

word_changed 중 하나를 검색할 때 이러한 시간 한계를 지정해 상위 검색 범위를 좁힐 수 있습니다.

[search sourcetype=login_data action=login user=root | eval starttimeu=_time - 60 | eval endtimeu=_time + 60 | return starttimeu, endtimeu, src_ip ] action=failed_login OR action=password_changed

이 검색의 단점은 failed_logins(이후) 또는 password_changed(이전)를 서로 구분할 수 없기 때문에 로그인의 마지막 인스턴스만 찾아내고, false positive가 있을 수 있다는 점입니다.

대신, 관심있는 이벤트에 집중해 이벤트 필터링 범위를 좁혀서 이 문제를 해결할 수 있습니다.

sourcetype=login_data ( action=login OR action=failed_login OR action=password_changed )

트랜잭션을 failed_login으로 시작하고, password_changed로 끝나는 동일한 src_ip로부터 발생하는 이벤트로 구성합니다. 또한 이 트랜잭션은 시작에서 끝날 때까지 2분이 넘지 않아야 합니다.

… | transaction src_ip maxspan=2m startswith=(action=failed_login) endswith=(action=password_changed)

마지막으로, user=root를 가진 트랜잭션만 필터링해야 합니다. 왜냐하면 failed_login 이벤트에는 보통 user=root가 없기 때문에 다음과 같은 트랜잭션 후에 필터링이 필요합니다.

… | search user=root

반대로 user=root가 모든 관련 이벤트에 있다고 확신하는 경우, 마지막 필터링(search user=root)을 건너 띄면서 검색 절에 추가해야 합니다.

이벤트 후의 이벤트 찾기

문제특정 이벤트(예를 들어, 로그인 이벤트) 이후에 발생하는 첫 3개 이벤트 확인이 필요한데, 제대로 정의된 종료 이벤트가 없습니다.


109

해결책다음과 같이 로그인 작업으로 시작하는 이상적인 트랜잭션이 있다고 가정해 보겠습니다.

[1] 10:11:12 src_ip=10.0.0.5 user=root action=login [2] 10:11:13 src_ip=10.0.0.5 user=root action=”cd /” [3] 10:11:14 src_ip=10.0.0.5 user=root action=”rm -rf *” [4] 10:11:15 src_ip=10.0.0.5 user=root server=”echo lol”

한가지 확실한 방법은 startswith action=login인 transaction을 만드는 것입니다.

... | transaction src_ip, user startswith=”(action=login)” maxevents=4

여기서 문제점은 action=login이 없는 트랜잭션도 결과에 포함된다는 점입니다. 왜 그럴까요? startswith 옵션으로는 사용자가 제공하고 있는 문자열로 실제 시작되는 트랜잭션만 반환하도록 transaction을 구성할 수 없기 때문입니다. 오히려 이 옵션은 startswith 지시문과 일치하는 라인을 만나는 경우 이것이 새로운 트랜잭션의 시작이라고 transaction에 명령합니다. 하지만 startswith 조건과 상관없이 src_ip의 서로 다른 값에 대해 트랜잭션이 만들어집니다.

이를 피하기 위해 위의 transaction 검색 후에 필터링 검색 명령어를 추가해야 합니다.

… | search action=login

반환된 트랜잭션은 action=login으로 시작되고, src_ip 및 user에 대해 다음 3가지 이벤트가 포함됩니다.

참고: 두 개의 로그인 사이에 세 개 미만의 이벤트가 있는 트랜잭션은 4개보다 적은 이벤트가 됩니다. transaction 명령어는 각 트랜잭션에 eventcount 필드를 추가합니다. 이렇게 해야 그 다음에 트랜잭션을 추가 필터링할 수 있습니다.

그룹 그룹화

문제트랜잭션 내에서 값을 변경하는 여러 필드로 트랜잭션을 작성해야 합니다.

Exploring Splunk

110

해결책다음과 같이 host 필드와 cookie 필드를 사용한 4개의 이벤트로부터 트랜잭션을 작성해야 한다고 가정하겠습니다.

[1] host=a [2] host=a cookie=b [3] host=b [4] host=b cookie=b

이 트랜잭션 과정에서 host 값이 변경되기 때문에 유감스럽게도 단순 transaction 명령어는 다음과 같이 두 개의 서로 다른 트랜잭션을 만들게 됩니다.

… | transaction host, cookie

event1과 event2를 보면 host=a로 트랜잭션을 작성하지만, 호스트(host=b)에 대해 다른 값을 가지는 event3에서는 host=b를 가지는 이벤트들의 각 트랜잭션으로 event3과 event4를 추가합니다. 그 결과 이러한 4개 이벤트가 cookie 공통 값 기반의 하나의 트랜잭션이 아니라, 두 개의 트랜잭션으로 변환됩니다.

트랜잭션 1:[1] host=a [2] host=a cookie=b

트랜잭션 2:[3] host=b [4] host=b cookie=b

이 경우 보통 transaction 명령어에서 host 필드를 제거하고, cookie 값을 기반으로 트랜잭션들을 결합하려고 시도할 수도 있습니다. 하지만 이렇게 하면 event2와 event4를 가진 트랜잭션은 생성되는데, event1과 event3은 무시됩니다. 왜냐하면 이 두 이벤트는 쿠키 값을 가지고 있지 않기 때문입니다.

이 문제점을 해결하는 방법은 트랜잭션 위에 트랜잭션을 작성하는 것입니다.

… | transaction host, cookie | transaction cookie

이 2차 transaction 명령은 위의 두 개 트랜잭션을 가져와 공통 cookie 필드를 사용해 트랜잭션들을 통합합니다.

이제, 계산된 duration과 eventcount필드는 정확하지 않게 됩니다. 2차 transaction 명령 뒤에 나오는 duration은 해당 명령이 통합한 트랜잭션들 간의 차이이지, 명령을 구성하고 있는 이벤트들 간의 차이가 아닙니다. 이와 마찬가지로 eventcount는 이벤트의 정확한 수가 아니라, 결합한 트랜잭션 수가 됩니다.


111

첫 번째 transaction 명령 이후에 정확한 eventcount를 얻으려면 my-count라고 하는 필드를 만들어서 모든 eventcount 값을 저장하고 난 후에, 두 번째 transaction 명령 다음에 모든 mycount 값을 합산해서 real_eventcount를 계산해야 합니다. 마찬가지로 1차 transaction 명령 후에 각 트랜잭션의 시작 및 종료 시간을 기록한 후 2차 transaction 명령 다음에 최소 시작 시간과 최대 종료 시간을 구한 후 real_dura-tion를 계산합니다.

… | transaction host, cookie | eval mycount=eventcount | eval mystart=_time | eval myend=duration + _time | transaction cookie mvlist=”mycount” | eval first = min(mystart) | eval last=max(myend) | eval real_duration=last-first | eval real_eventcount = sum(mycount)

113

8 룩업 테이블이 룩업 테이블 사용법은 실무에서 접하는 공통적인 문제점에 대한 고급 해결책을 간략하게 소개합니다. Splunk의 룩업 기능을 사용하면 이벤트 데이터의 필드와 일치하는 필드를 외부 CSV 파일에서 참조할 수 있습니다. 이러한 일치 기능을 사용해 추가 필드로 이벤트 데이터를 강화할 수 있습니다. 참고로 여기서는 외부 스크립트 룩업 또는 시간 기반 룩업은 다루지 않습니다.

소개이 사용법에서는 lookup, inputlookup, outputlookup 등과 같은 세 개의 룩업 검색 명령어를 광범위하게 사용합니다.

lookup이 명령어는 각 이벤트에 대해 외부 CSV 테이블의 행과 일치하는 항목을 찾아내 다른 컬럼 값을 반환하면서 이벤트를 강화합니다. 예를 들어, …| lookup mylookup host라는 명령어는 (host 및 machine_type 컬럼을 가진) 룩업 테이블과 host 필드 값이 있는 이벤트를 매핑하여 host 값에 해당하는 machine_type 값을 각 이벤트에 추가합니다. 기본적으로 일치 작업은 대소문자를 구분하며 와일드카드 문자는 지원하지 않지만 이러한 옵션을 구성할 수는 있습니다. lookup 명령은 외부 테이블의 값과 명확하게 값을 일치시킵니다. Splunk 관리자를 사용하여 설정된 자동 룩업 기능은 암시적으로 값을 일치시킵니다. 자동 룩업 구성에 대한 자세한 내용은 http://splunk.com/goto/book#autolookup을 참조하십시오.

inputlookup이 명령어는 전체 룩업 테이블을 검색 결과로 반환합니다. 예를 들어, … | inputlookup mylookup은 테이블 mylookup의 각 행에 대해 검색 결과를 반환합니다. 여기에는 두 개의 host 및 machine_type 필드 값이 있습니다.

Exploring Splunk

114

outputlookup룩업 테이블을 만드는 방법에 대해 궁금해할 수도 있습니다. 이 명령어는 디스크의 룩업 테이블에 대한 현재 검색 결과를 출력합니다. 예를 들어, … | outputlookup mytable.csv saves는 모든 결과를 mytable.csv에 저장합니다.

추가 정보http://splunk.com/goto/book#lookuptutorialhttp://splunk.com/goto/book#externallookups

방법

기본 룩업 값 설정

문제이벤트의 값이 룩업 테이블에 없는 경우에는 기본값을 지정하고 싶습니다.

해결책몇 가지 해결책이 있습니다.

명시적 lookup 명령어를 이용하여 다음과 같은 간단한 eval coalesce를 사용할 수 있습니다.

… | lookup mylookup ip | eval domain=coalesce(domain,”unknown”)

자동 룩업 기능을 사용하기 위한 설정도 있습니다. 관리자 >> 룩업 >> 룩업 정의 >> mylookup으로 이동하여 고급 옵션 체크박스를 선택하고 다음과 같이 변경합니다.

최소 일치 항목 수 설정: 1

기본 일치 항목 수 설정: 알 수 없음

변경 사항을 저장합니다.

역방향 룩업 사용

문제룩업 테이블 출력 자료를 기반으로 이벤트 검색이 필요합니다.

8장: 룩업 테이블

115

해결책Splunk에서는 역방향 룩업 검색을 사용하여 자동 룩업의 출력값을 검색할 수 있으며, 이 출력값을 룩업의 해당 입력 필드에 대한 검색으로 변환할 수 있습니다.

예를 들어, machine_name을 owner에 매핑하는 룩업 테이블이 있다고 가정해 보겠습니다.

machine_name, ownerwebserver1,erikdbserver7,stephendbserver8,amrit…

이벤트에 machine_name 필드가 있고, 특정 owner인 erik를 검색하고 싶다면 아래와 같이 비효율적인 검색을 사용할 수도 있습니다.

… | lookup mylookup machine_name | search owner=erik

이 검색은 모든 이벤트를 검색하고, owner가 erik이 아닌 모든 값을 필터링해야 하므로 매우 비효율적입니다.

반대로, 효율적이지만 까다로운 하위 검색 방법도 있습니다.… [ inputlookup mylookup | search owner=erik | fields ma-chine_name]

이 검색은 룩업 테이블의 모든 행을 검색하고, owner가 erik이 아닌 모든 행을 필터링하여 제외한 후, Splunk가 최종적으로 검색할 장황한 시스템 이름 OR 표현식을 반환합니다.

하지만 이중 어떤 것도 필요하지 않습니다. 자동 룩업 테이블을 설정했으면 Splunk에서 간단히 owner=erik를 검색할 수 있습니다.

아주 간단합니다. 효과적인 검색을 위해 Splunk는 보이지 않는 곳에서 하위 검색 솔루션을 사용해 OR 절 검색을 만듭니다.

참고: Splunk에서는 정의된 필드 추출, 태그 및 eventtype에 대한 자동 역방향 검색이 가능합니다.사용자는 추출된 값, 태그를 지정한 값, 유형이 지정된 값을 검색할 수 있고, Splunk는 이를 통해 정확한 이벤트를 검색합니다.

변형 자동 룩업 기능과 내장된 역방향 룩업 기능을 사용하여 Splunk의 태깅 시스템을 재생성할 수 있습니다. 예를 들어, host에서 host_tag라는 필드에 매핑합니다. 이제 host 값뿐만 아니라, host_tag에 기반하여 이벤트를 검색할 수 있습니다. 많은 사람들이 Splunk 태그보다 룩업 테이블을 유지하는 것이 더 쉽다고 알고 있습니다.

Exploring Splunk

116

2계층 룩업

문제2계층 룩업 수행이 필요합니다. 예를 들어, 잘 알려진 일반적인 호스트 테이블에서 IP 주소를 조회합니다. 그러나 주어진 이벤트에 대해 이 조회가 실패할 경우, 더 비효율적인 2차 DNS 전체 룩업을 사용하게 됩니다.

해결책이벤트를 검색한 후에 다음의 로컬 룩업 파일 local_dns.csv에 대해 최초의 룩업을 수행합니다.

... | lookup local_dns ip OUTPUT hostname

룩업이 일치하지 않을 경우 해당 이벤트에 대한 hostname 필드는 null입니다.

이제 hostname이 없는 이벤트에 대해 비효율적인 두 번째 룩업을 수행합니다. OUTPUT 대신 OUTPUTNEW를 사용하면 hostname이 null 값인 이벤트만 조회됩니다.

... | lookup dnslookup ip OUTPUTNEW hostname

종합하면 다음과 같습니다.... | lookup local_dns ip OUTPUT hostname | lookup dnslookup ip OUTPUTNEW hostname

여러 단계 룩업 사용

문제하나의 룩업 파일에서 값을 조회해야 하는데, 첫 번째 룩업에서 반환된 필드 값을 사용하여, 다른 룩업 파일에서 두 번째 룩업을 수행해야 합니다.

해결책순차적으로 룩업 명령을 실행하여 수동으로 이를 해결할 수 있습니다. 예를 들어, 첫 번째 룩업 테이블이 필드 A의 값과 필드 B의 출력값을 가져오고, 두 번째 룩업 테이블이 필드 B의 값과 필드 C의 출력값을 가져옵니다.

… | lookup my_first_lookup A | lookup my_second_lookup B

흥미로운 점은 이와 같은 연속 구조가 자동으로 발생되는 자동 룩업을 사용할 수 있다는 점입니다. 그러나 반드시 속성 이름을 영숫자순으로 사용하여 올바른 순서대로 룩업을 사용해야 합니다.


117

관리자 >> 룩업 >> 자동 룩업으로 이동하여 두 개의 자동 룩업을 만듭니다. 나중에 실행하는 룩업은 이전 룩업 이름보다 더 큰 값으로, 이름이 지정된 값을 가져야 합니다. 예:

0_first_lookup = my_first_lookup A OUTPUT B 1_second_lookup = my_second_lookup B OUTPUT C

참고: 이 사용법에 나와 있는 룩업의 연속 구조를 사용하면 '역방향 룩업 사용' 방법에서 설명된 역방향 룩업은 실행되지 않습니다. 그 이유는 Splunk가 현재 여러 단계의 자동 필드 룩업을 역방향으로 실행할 수 없기 때문입니다(예: 연속된 출력 필드 값 C=baz 검색을 입력 필드 값 A=foo 검색으로 자동 변환).

검색 결과에서 룩업 테이블 생성

문제검색 결과에서 룩업 테이블을 생성하려고 합니다.

해결책간단히 다음과 같이 하면 됩니다.

<some search> | outputlookup mylookupfile.csv

하지만 두 가지 문제가 있습니다. 첫 번째는 _raw와 _time과 같은 내부 필드를 비롯해 룩업 테이블에서 원하지 않는 필드가 이벤트에 너무 많다는 점입니다. 두 번째는 관심을 가지고 있는 필드 중에서, 검색된 이벤트에 있는 값이 중복되어 있다는 점입니다. 첫 번째 문제를 해결하기 위해 여기서는 fields 명령어를 사용하지 않겠습니다. 이유는 이 명령어를 사용하면 내부 필드를 제거하는 것이 번거로워지기 때문입니다. 대신 table 명령어를 사용하여 명시적으로 지정하고 싶은 항목으로 필드를 더 효과적으로 제한할 수 있습니다. 두 번째 문제는 dedup 명령어를 사용하여 해결할 수 있습니다. 종합하면 다음과 같습니다.

… | table field1, field2 | dedup field1 | outputlookup mylookupfile.csv

Appending Results to Lookup Tables

문제기존 룩업 테이블에 결과를 추가해야 합니다. 예를 들어, 동일한 검색을 여러 번 검색한 결과를 바탕으로 하나의 룩업 테이블을 만들려고 합니다. 특히, 각 사용자가 로그인한 최종 IP를 추적하기를 원합니다. 이를 위해서 최종 IP를 조회하기 위해 매 15분마다 작업을 실행하거나 새로운 사용자로 룩업 테이블을 업데이트하려고 시도할 수도 있습니다.

Exploring Splunk

118

해결책기본적인 절차는 룩업 테이블에 추가하려는 결과 세트를 가져오고, in-putlookup을 사용해 현재의 룩업 내용을 추가하고, outputlookup을 사용해 해당 룩업을 작성하는 것입니다. 명령어는 다음과 같습니다.

your_search_to_retrieve_values_needed | fields the_interesting_fields | inputlookup mylookup append=true| dedup the_interesting_fields| outputlookup mylookup

먼저, Splunk를 사용해 새로운 데이터를 검색하고 룩업 테이블에 필요한 필드만을 유지합니다. 그런 다음, inputlookup을 사용해 mylookup의 기존 행을 추가하는데, 이 때 append=true 옵션을 사용합니다. 그 다음 dedup을 사용하여 중복 항목을 제거합니다. 마지막으로 outputlookup을 사용해 모든 결과를 mylookup에 출력합니다.

변형최근 30일간의 값만 있는 룩업 테이블이 필요합니다. 예약 검색을 통해 룩업 테이블이 매일 업데이트되도록 설정할 수 있습니다. 룩업 테이블을 출력하도록 예약 검색을 설정할 때, 그리고 outputlookup 명령 전에, 30일이 넘는 데이터만 필터링하여 제외하는 조건을 추가합니다.

... | where _time >= now() - (60*60*24*30)

여기서 60*60*24*30은 30일을 초로 환산한 것입니다.

정리하면 검색은 다음과 같아집니다.your_search_to_retrieve_values_needed | fields just_the_interesting_fields | inputlookup mylookup append=true| where _time >= now() - (60*60*24*30) | outputlookup mylookup

그리고 룩업 테이블의 필드 중 하나로 _time이 반드시 유지되어야 합니다.

대용량 룩업 테이블 사용

문제대용량 룩업 테이블이 있지만 빠른 성능을 원합니다.


119

해결책성능에 영향을 미칠 수 있는 매우 큰 대용량 룩업 테이블의 경우 몇 가지 해결책이 있습니다.

먼저, 특정 룩업 테이블을 좀 더 적은 용량으로 만들 수 있는지 여부를 파악합니다. 예를 들어, 행과 컬럼의 하위집합만 검색 시 필요한 경우에는 이러한 검색을 위해 축약된 버전의 룩업을 만드십시오. 다음 검색은 몇 가지 조건(중복 제거, 필요한 입력, 출력 필드만 남기고 모든 컬럼 제거, 마지막으로 결과를 mylookup2 테이블에 작성)을 충족하는 룩업 테일블의 행을 줄여서 mylookup 테이블 크기를 줄였습니다.

| inputlookup mylookup | search somecondition | dedup someinputfield | table someinputfield, someoutputfield | outputlookup mylookup2

룩업 테이블의 크기를 줄일 수 없는 경우에는 다른 해결책이 있습니다. Splunk 설치에 몇 가지 인덱서가 포함된 경우, 해당 인덱서가 자동으로 룩업 테이블을 복제합니다. 하지만 룩업 파일이 대용량 파일(예: 100MB)일 경우 시간이 많이 소요됩니다.

한가지 해결책은 번들이 자주 업데이트될 경우, 번들 복제를 비활성화하고, 대신 NFS를 사용하여 번들을 모든 노드에 사용할 수 있도록 하는 것입니다.

참조: http://splunk.com/goto/book#mount

또 다른 해결책으로, 룩업 테이블이 자주 변경되지 않고 장착된 공유 드라이브에 의존할 수 없는 경우 로컬 룩업을 사용하면 됩니다.

• 룩업이 복제 및 분산되는 것을 막으려면 룩업 테이블을 dist-search.conf의 replicationBlacklist에 추가합니다. (자세한 내용 참조: http://splunk.com/goto/book#distributed)

• 룩업 테이블 CSV 파일을 다음의 각 인덱서에 복사합니다. $SPLUNK_HOME/etc/system/lookup

• 검색을 실행할 때 lookup 검색 명령어에 local=true 옵션을 추가합니다.

참고: 룩업에 대한 정의는 props.conf를 통하여 암묵적으로 실행되도록 정의되어야 하는데, 이것은 룩업의 속성상 로컬이 아니라 인덱스에 분산되어 있어야 하기 때문입니다.

마지막으로, 대용량 CSV파일을 사용하기보다는 외부 룩업(일반적으로 데이터베이스를 조회하는 스크립트 활용)을 고려해 보십시오.

Exploring Splunk

120

참고: .csv 룩업 테이블 크기가 10MB(기본 크기)에 다다르면 빠른 액세스를 위해 Splunk는 해당 룩업 테이블을 인덱스합니다. 이렇게 .csv 파일을 인덱스함으로써 Splunk는 테이블을 스캔하는 대신 검색을 수행하게 됩니다. 파일이 인덱스되기 전에 크기를 편집하려면 limits.conf의 룩업 스탠자를 편집하고 max_memtable_bytes 값을 변경합니다.

룩업 값과 결과 비교

문제룩업 리스트 값과 이벤트 리스트 값을 비교하고 싶습니다. 예를 들어, IP 주소를 가진 룩업 테이블이 있는데, 지금 데이터에 어떤 IP 주소가 발생했는지 알고 싶은 경우입니다.

해결책특정 필드 값을 가진 이벤트들의 수가 적은 경우, 하위 검색을 사용하여 효율적으로 관련 이벤트를 찾을 수 있습니다. 하위 검색에서 input-lookup을 사용하여 룩업 테이블에 표시된 모든 값에 대해 대규모 OR 검색을 만듭니다. 하위 검색으로 반환된 리스트 크기는 10,000개까지 가능합니다(제한량은 limits.conf에서 수정가능).

yoursearch [ inputlookup mylookup | fields ip ]

결과적으로 실행되는 검색은 다음과 유사합니다.yoursearch AND ( ip=1.2.3.4 OR ip=1.2.3.5 OR ... )

하위 검색 안에 있는 검색을 실행하고, format 명령어를 붙이면 하위 검색에서 반환된 결과를 테스트할 수 있습니다.

| inputlookup mylookup | fields ip | format

참조: http://splunk.com/goto/book#subsearch

변형 I유사한 방식으로 룩업 테이블에 없는 값을 가진 이벤트를 검색하려면 다음과 같은 패턴을 사용합니다.

yoursearch NOT [ inputlookup mylookup | fields ip ]

이 패턴을 사용한 검색은 다음과 같습니다.yoursearch AND NOT ( ip=1.2.3.4 OR ip=1.2.3.5 OR ... )


121

변형 II반대로, 데이터에서 일치되지 않는 룩업 테이블 값을 원할 경우에는 다음을 사용합니다.

| inputlookup mylookup | fields ip | search NOT [ search yoursearch | dedup ip | fields ip ]

이것은 룩업 테이블에 있는 모든 값에 대해서 데이터와 일치하는 값을 필터링하여 제외합니다.

변형 III대용량 리스트의 경우, 룩업 테이블에도 있는 이벤트의 모든 값을 검색하는 효율적인 검색 패턴이 있습니다. 이 검색 패턴은 이벤트를 검색한 후 전체 룩업 테이블을 해당 이벤트에 추가합니다. 필드(예: marker) 설정을 통해 결과('행')가 이벤트 또는 룩업 테이블 행인지의 여부를 추적할 수 있습니다. stats를 사용하여 두 리스트(count>1)에 있는 IP 주소 리스트를 얻을 수 있습니다.

yoursearch | eval marker=data | append [ inputlookup mylookup | eval marker=lookup ] | stats dc(marker) as list_count by ip | where list_count > 1

참고: append 명령어가 하위 검색을 실행 중인 것처럼 보이더라도 실제로는 실행되는 것이 아닙니다. 기본적으로 10,000개까지 결과 수가 제한되어 있는 하위 검색과 다르게, 추가할 수 있는 결과 수에는 제한이 없습니다.

아주 넓은 시간 간격에서 이 방법을 사용할 경우에는 긴 시간 동안 상태가 유지되는 다른 룩업 테이블을 사용하는 것이 더 효율적입니다. 간략히 설명하면, IP가 나타난 마지막 시간을 계산하는 시간 범위를 더 짧은 시간 범위로 해서 검색을 예약합니다. 예를 들면, 하루로 예약합니다. 그런 다음 inputlookup, dedup 및 outputlookup을 결합해 장시간에 걸친 룩업 테이블을 점차적으로 업데이트합니다. 이렇게 함으로써 가장 최근 상태를 볼 수 있는 매우 빠른 리소스가 제공됩니다. 자세한 내용은 "룩업 테이블에 결과 추가" 방법을 참조하십시오.

Exploring Splunk

122

룩업 일치 항목 제어

문제정해진 조합의 입력 필드에 대해 룩업 테이블 상에 여러 항목이 있고, 이 중 일치하는 첫 번째 값을 원합니다. 예를 들어, 룩업 테이블은 여러 호스트 별칭에 호스트 이름을 매핑시키고, 첫 번째 별칭을 원하는 경우입니다.

해결책기본적으로 Splunk는 시간 요소와 관련 없는 룩업에 대해 최대 100개의 일치 항목을 반환합니다. 하나만 반환하도록 업데이트할 수 있습니다.

UI를 사용하여 업데이트하려면 관리자 >> 룩업 >> 룩업 정의로 이동하여 룩업 정의를 편집하거나 만듭니다. 고급 옵션 체크박스를 선택하고 최대 일치 항목 수에 1을 입력합니다.

또한 해당되는 transforms.conf를 편집할 수 있습니다. 룩업 스탠자에 max_matches=1을 추가합니다.

참조: http://splunk.com/goto/book#field_lookup

변형룩업 테이블에 제거하고 싶은 중복 항목이 있는 경우 다음과 유사한 검색으로 이를 정리할 수 있습니다

| inputlookup mylookup | dedup host | outputlookup mylookup

이렇게 하면 해당 파일에서 첫 번째 나타나는 각 호스트를 제외하고 모두 제거됩니다.

IP 일치

문제일치시키고 싶은 IP 주소 범위의 룩업 테이블을 가지고 있습니다.

해결책이벤트에 IP 주소가 있고 IP 범위와 ISP가 있는 테이블이 있다고 가정하겠습니다.

network_range, isp 220.165.96.0/19, isp_name1 220.64.192.0/19, isp_name2 ...

사용자는 룩업을 위해 match_type을 지정할 수 있습니다. 단, 이 기능은 UI 메뉴로는 지정할 수 없고, transforms.conf 구성 파일에서 설정해야 합니다.


123

network_range에 대해 match_type을 CIDR로 설정합니다.

transforms.conf에서 다음을 설정합니다.[mylookup] match_type = CIDR(network_range)

참조: http://splunk.com/goto/book#transform

변형가능한 match_type 값은 WILDCARD, CIDR 및 EXACT입니다. EXACT가 기본값으로 지정되어 있습니다.

또한 조회할 때 대소문자를 구분할지 여부를 transforms.conf 파일에 지정할 수 있습니다(기본적으로 대소문자 구분). 일치시킬 때 대소문자를 구분하려면 다음 구문을 사용하십시오.

case_sensitive_match = False

Matching with Wildcards

문제룩업 테이블에 일치하는 와일드카드가 필요합니다.

해결책일치시키고 싶은 URL이 있는 룩업 테이블이 있다고 가정해 보겠습니다.

url, allowed *.google.com/*, True www.blacklist.org*, False */img/*jpg, False

룩업 테이블 값에 와일드카드(*) 문자를 삽입하여, Splunk에서 와일드카드에 일치하는 검색을 수행할 수 있습니다.

"IP 일치" 방법에서 설명한 바와 같이 transforms.conf 구성 파일에서 조회를 위해 match_type을 지정할 수 있습니다.

[mylookup] match_type = WILDCARD(url)

Exploring Splunk

124

참고: 기본적으로 룩업 테이블의 최대 일치 항목 수는 100입니다. 일치하는 여러 행이 있다면 출력 필드에도 여러 값이 생깁니다. 예를 들어, URL “www.google.com/img/pix.jpg”는 위의 테이블에서 첫 번째 행 그리고 세 번째 행과 일치하는 경우, 허용된 필드는 True 또는 False 값을 가진 다중값 필드가 됩니다. 일반적으로 이것은 원하는 결과가 아닙니다. 최대 일치 항목 수를 1로 설정하면 첫 번째 일치 값이 사용되고, 우선 순위를 결정하기 위해 테이블 순서를 사용할 수 있습니다. 고급 옵션 체크박스를 선택한 후 관리자 >> 룩업 >> 룩업 정의 >> mylookup에서 이 설정을 찾을 수 있습니다.

변형이 장의 첫 번째 방법에서는 룩업 실행 후 일치 항목을 찾지 못할 경우의 기본값을 처리하는 방법을 다루었습니다. 또 다른 방법으로는 와일드카드 일치를 이용하는 것입니다. 룩업 테이블의 마지막 항목이 일치값 *를 가지도록 설정하고 룩업 테이블의 최소/최대 일치 항목 수를 1로 설정하십시오.

125

부록 A: 머신 데이터 기본사항머신 데이터는 IT 전문가들에 의해 데이터 센터에서 오랫동안 활용되어 왔지만, 최근에는 다른 부서에서도 활용할 수 있는 소스로 인식되고 있습니다. IT 데이터 또는 운영 데이터라고도 불리는 머신 데이터는 비즈니스 상에서 애플리케이션, 서버, 네트워크 장치, 보안 장치 등의 시스템에 의해 생성되는 모든 데이터를 일컫습니다. 보통 머신 데이터의 범주에는 로그 파일보다 훨씬 더 많은 데이터가 포함됩니다. 여기에는 구성, 클릭스트림, 변경 이벤트, 진단, API, 메시지 대기열, 사용자 지정 애플리케이션 등의 데이터가 포함됩니다. 이러한 데이터는 엄격히 정형화되어 있고 시계열 기반으로 볼륨이 큽니다. IT의 거의 모든 구성요소에서 생성된다고 할 수 있으며 데이터 형식과 소스 또한 매우 다양합니다. 사용자 지정 애플리케이션에서 나오는 수많은 로그 형식은 서비스 문제를 진단하고, 복잡한 보안 위협을 감지하고, 컴플라이언스를 입증하는 데 매우 중요한 역할을 합니다. 또한 연결되는 장치들이 급증하면서, GPS 장치, RFID 태그, 핸드폰, 유틸리티 장비 등 다양한 종류의 많은 시스템에서 엄청난 양의 정보들이 쏟아지고 있는 가운데 데이터 증가 속도는 이러한 정보 처리 및 활용 기술 속도를 빠르게 능가하고 있습니다.

IT 전문가들에게는 머신 데이터의 가치가 새삼스러운 것이 아닙니다. 이미 수년 전부터 활용되던 것입니다. Splunk 사용자들도 Splunk가 자신들의 비즈니스 이슈와 관련하여 유용한 정보를 제공한다는 것을 깨닫고 있습니다. 머신 데이터는 대부분 대용량 파일로 저장되는데, Splunk 사용 이전에는 문제가 발생하여 파일들을 수동으로 검사하기 전까지 머신 데이터는 사용되지 않는 휴면 상태였을 가능성이 높습니다. 이제 Splunk를 사용하면 이러한 파일들이 인덱스되어 활용 가능하게 됩니다.

비즈니스 사용자는 비즈니스 프로세스에 관여하는 많은 사람들에 의해 생성되는 데이터를 처리해야 합니다. 이러한 데이터를 흔히 일컫는 트랜잭션 데이터는 다음의 두 데이터베이스 양식 중 하나로 저장됩니다.

관계형 데이터베이스: 트랜잭션 데이터를 저장하는 데 널리 사용됩니다. 관계형 데이터베이스는 재무 기록, 인사 기록, 제조 정보, 물류 정보처럼 주로 정형화된 엔터프라이즈 데이터를 저장합니다. 관계형 데이터베이스는 설계 상 데이터베이스의 구조를 설명하는 엄격한 스키마나 공식들의 집합으로 구성되어 있습니다. 이와 같은 스키마를 변경하게 되면 지연 시간이 길어지고 위험이 동반되어 기능 상 손상이 발생할

Exploring Splunk

126

수도 있습니다. 그럼에도 관계형 데이터베이스에서 검색을 구성하려면 일반적으로 실무자는 스키마를 변경해야 합니다.

다차원 데이터베이스(MDB): 대규모 레코드 그룹 분석에 적합하도록 설계되었습니다. OLAP(On-Line Analytical Processing)라는 용어는 "다차원 데이터베이스"와 거의 동의어가 되었습니다. 사용자는 OLAP 도구를 통해 다차원 데이터를 서로 다른 차원에서 분석할 수 있습니다. 다차원 데이터베이스는 실시간 이벤트에는 적합하지 않고 데이터 마이닝과 월간 보고에 적합합니다.

머신 데이터는 트랜잭션 데이터보다 세부 수준이 훨씬 낮습니다. 트랜잭션 데이터는 온라인 구매와 관련한 모든 제품, 배송, 결제 데이터를 저장합니다. 이처럼 구매 관련 머신 데이터에는 사용자의 모든 클릭, 로드한 모든 페이지와 이미지, 요청된 모든 광고 요청 등 수천 개의 레코드나 이벤트가 포함됩니다. 완성된 결과나 목적지가 아니라 전체 여정의 한 부분이라고 할 수 있는 머신 데이터는.

매우 세부적이라 아주 다양한 용도로 사용될 수 있습니다. IT 환경에서 머신 데이터는 문제점을 찾아내는데 도움이 되고, 시스템이 허용 성능 범위 내에서 작동되고 있는지를 보여주기도 합니다. 비즈니스 환경에서 머신 데이터는 소비자 행동을 추적하고, 소비자층을 구분해 마케팅 타겟 메시지를 작성하는데 활용되기도 합니다.

이 부록에서는 머신 데이터 속성을 보다 잘 활용할 수 있도록 사용자들이 겪을 수 있는 다양한 유형에 대해 간략하게 설명하겠습니다.

애플리케이션 로그자체 제작한 패키지 애플리케이션 대부분은 주로 로깅 서비스가 내장된 미들웨어(WebLogic, WebSphere®, JBoss™, .NET™, PHP 및 기타)를 사용하여 로컬 로그 파일을 작성합니다. 로그 파일은 개발자와 애플리케이션 지원에 필요한 실운영 애플리케이션의 일상적인 디버깅 작업에 매우 중요합니다. 뿐만 아니라 로그 파일에는 트랜잭션의 모든 세부 정보가 담겨 있기 때문에 비즈니스 활동과 사용자 활동을 보고하고 악의적 활동을 감지하는 데 가장 좋은 방법이기도 합니다. 개발자가 로그 이벤트에 타이밍 정보를 넣을 경우, 애플리케이션 성능 모니터링과 보고에도 사용할 수 있습니다.

웹 액세스 로그웹 액세스 로그는 웹 서버에서 처리되는 모든 요청을 보고합니다. 예를 들어, 어떤 클라이언트 IP 주소가 수신되었고, 어떤 URL이 요청되었는지, 참조 URL은 무엇인지, 그리고 요청 성공/실패에 관한 데이터 등을 보고합니다. 로그 파일은 일일 방문자 수, 가장 많이 요청된 페이지 등과 같이 마케팅을 위한 웹 분석 보고서를 작성하기 위해 일반적으로 처리됩니다.


127

또한 실패한 요청에 대한 로그에는 정확한 오류 시점이 나타나므로, 보고된 문제점을 조사하는 시작점으로써 로그 파일은 매우 가치 있는 데이터라고 할 수 있습니다. 웹 로그는 표준화되어 있고 구조화되어 있습니다. 그러나 최대 난제는 일반적으로 하루에 수 십억 건의 방문이 이루어지는 인기 웹 사이트들의 엄청난 볼륨을 어떻게 다루냐는 것입니다.

웹 프록시 로그직원, 고객 또는 게스트에 웹 액세스를 제공하는 거의 대부분의 기업, 서비스 제공업체, 기관, 정부 조직 등이 웹 프록시를 사용하여 액세스를 제어하고 모니터링합니다. 웹 프록시는 프록시를 통한 사용자의 모든 웹 요청을 기록합니다. 여기에는 회사 사용자 이름 및 URL이 포함될 수 있습니다. 이러한 로그는 "이용 약관" 악용이나 회사 웹 사이트 이용 정책을 모니터링하고 조사하는데 매우 요긴하게 사용되며, 데이터 누출에 대한 효과적인 모니터링과 조사에도 핵심적인 구성요소가 되기도 합니다.

통화 내역 기록(CDR)CDR(Call Detail Records, 통화 내역 기록), Charging Data Record(과금 부과 데이터 기록) 및 EDR(Event Data Records, 이벤트 데이터 기록)은 전자통신 및 네트워크 스위치에 의해 기록되는 이벤트에 붙여진 이름들입니다. CDR에는 스위치를 통과한 통화 또는 서비스의 유용한 세부정보가 포함됩니다. 즉, 발신번호, 수신번호, 전화 건 시간, 통화한 시간(양), 통화 유형과 같은 정보가 포함됩니다. 통신 서비스가 인터넷 프로토콜 기반 서비스로 이동하면서, 이러한 데이터는 IP 주소, 포트 번호 등과 같은 세부정보를 포함하는 IPDR로 참조되기도 합니다. 이러한 파일의 사양, 형식 및 구조는 매우 다양해 모든 경우의 수를 처리하고 추적하는 것은 일반적으로 어려운 난제가 되고 있습니다. CDR에 포함되는 데이터는 과금, 매출 보장, 고객 보장, 파트너 정산, 마케팅 인텔리전스 등에 매우 중요합니다. Splunk를 사용하면 데이터를 신속하게 인덱스하여 다른 비즈니스 데이터와 인덱스한 데이터를 결합해 새로운 통찰력을 얻을 수 있습니다.

클릭스트림 데이터웹 사이트에서 웹 페이지의 이용은 클릭스트림 데이터로 수집됩니다. 클릭스트림 데이터를 통해 웹 사이트에서의 사용자 활동을 알 수 있고, 이 데이터는 유용성 분석, 마케팅 및 일반 리서치에도 유용하게 사용됩니다. 클릭스트림 데이터의 형식은 비표준화되어 있고, 다양한 작업들이 웹 서버, 라우터, 프록시 서버, 광고 서버 등 여러 곳에서 로깅될 수 있습니다. 모니터링 도구는 특정 소스로부터 데이터의 일부분에 대한 뷰만 제공하는 경우가 많습니다. 웹 분석 및 데이터 웨어하우스 제품은 데이터를 샘플링하기 때문에 동작에 대한 전체 뷰를 놓치거나 실시간 분석을 제공하지 못합니다.

Exploring Splunk

128

메시지 대기열TIBCO®, JMS, AquaLogic™ 등의 메시지 대기열 기술은 공개/구독 형태로 서비스와 애플리케이션 구성요소 간에 데이터와 작업을 전달하는 데 사용됩니다. 이러한 메시지 대기열을 구독하는 것은 복잡한 애플리케이션에서 문제를 디버깅하는 좋은 방법입니다. 즉, 다음 구성요소가 연이어서 이전 구성요소로부터 받은 것이 무엇인지를 정확히 볼 수 있습니다. 메시지 대기열은 애플리케이션을 위한 로깅 아키텍처의 백본으로서 점점 더 많이 사용되고 있습니다.

패킷 데이터네트워크에서 생성되는 데이터는 tcpdump 및 tcpflow와 같은 도구를 사용하여 처리되며, 이 도구들은 pcaps 데이터와 기타 유용한 패킷 레벨 및 세션 레벨 정보를 생성합니다. 이 정보는 성능 저하, 시간 초과, 병목현상 또는 네트워크를 손상시킬 수 있는 의심스러운 활동 또는 원격 공격 개체를 처리하는데 필요합니다.

구성 파일인프라가 어떻게 설정되었는지 이해하는 데 있어 실제 작동되고 있는 시스템 구성을 대신할 만한 것은 없습니다. 과거 구성은 다시 발생할 수 있는 과거 실패를 디버깅하는 데 필요합니다. 구성이 변경된 경우, 무엇이 변경되었는지, 언제 변경이 승인되었고, 실제 변경이 승인되었는지, 그리고 성공적인 공격자가 백도어, 시한 폭탄 또는 기타 잠복되어 있던 위협을 통해 시스템을 손상시켰는지 여부를 아는 것이 중요합니다.

데이터베이스 감사(Audit) 로그 및 테이블데이터베이스에는 고객 정보, 금융 데이터, 환자 기록 등 민감한 기업 데이터들이 들어 있습니다. 모든 데이터베이스 쿼리의 감사(Audit) 레코드는 어떤 데이터에 언제 누가 액세스를 했고, 언제 누가 데이터를 변경했는지를 아는데 반드시 필요합니다. 데이터베이스 감사(Audit) 로그는 애플리케이션이 쿼리를 최적화하는 데 데이터베이스를 어떻게 사용하는지 이해하는 데도 유용합니다. 일부 데이터베이스는 파일에 감사(Audit) 레코드를 기록하고, 또 다른 데이터베이스는 SQL을 사용하여 접근 가능한 감사(Audit) 테이블을 유지 관리합니다.

파일 시스템 감사(Audit) 로그데이터베이스에 없는 민감한 데이터는 파일 시스템에 저장되어 종종 공유됩니다. 의료산업과 같은 일부 산업계에서 가장 큰 데이터 누출 위험은 공유 파일 시스템에 있는 소비자 관련 데이터입니다. 서로 다른


129

운영 체제나 타사의 도구들 그리고 다양한 스토리지 기술이 파일 시스템 레벨에서 민감한 데이터를 읽는 엑세스를 감사하는데 있어 다양한 옵션을 제공합니다. 이 감사(Audit) 데이터는 민감한 정보에 대한 액세스를 모니터링하고 조사하는 데 중요한 데이터 소스입니다.

관리 및 로깅 API점점 더 많은 공급업체들이 중요한 관리 데이터와 로그 이벤트를 파일에 로깅하는 대신, 표준화된 독점 API를 통해 해당 관리 데이터와 로그 이벤트를 노출하고 있습니다. Checkpoint® 방화벽은 OPSEC Log Export API(OPSEC LEA)를 사용하여 로깅합니다. VMware®, Citrix® 등의 가상화 업체는 자사의 자체 API를 사용하여 구성, 로그 및 시스템 상태를 노출합니다.

OS 메트릭, 상태 및 진단 명령어운영 체제는 Unix 및 Linux 운영 체제의 경우 ps 및 iostat, Windows에서는 perfmon와 같은 명령줄 유틸리티를 사용하여 CPU, 메모리 활용률, 상태 정보와 같은 중요한 메트릭을 노출시킵니다. 일반적으로 이 데이터는 서버 모니터링 도구를 통해 그 활용도가 커지지만, 문제 해결이나 잠재적 문제 감지를 위한 추세 분석 그리고 보안 사건을 조사하는 데 있어 잠재적으로 상당히 중요한 데이터임에도 계속 지속되는 것이 쉽지 않습니다.

기타 머신 데이터 소스지금까지 설명한 것 외에도, 소스 코드 리포지토리 로그, 물리적 보안 로그 등 여기서 다 설명하지 못한 다른 유용하고 중요한 머신 데이터 소스도 셀 수 없이 많습니다. 네트워크 연결 및 공격을 보고하는 데 방화벽과 IDS 로그가 여전히 필요합니다. Unix 및 Linux의 syslog와 Windows 이벤트 로그 등을 포함한 OS 로그는 서버에 누가 로그인했는지, 로그인해서 어떤 관리 작업을 수행했는지, 서비스가 언제 시작되고 중지되었는지, 커널 패닉이 언제 발생했는지 등의 정보가 기록됩니다. DNS, DHCP 및 기타 네트워크 서비스의 로그에는 누구에게 어떤 IP 주소가 할당되었는지가 기록되고 도메인을 확인하는 방법도 기록됩니다. 라우터, 스위치 및 네트워크 장치의 syslog에는 네트워크 연결 상태와 중요한 네트워크 구성요소 오류가 기록됩니다. 머신 데이터에는 단순한 로그 이상의 데이터가 존재할 뿐만 아니라, 기존의 로그 관리 솔루션들이 지원하는 것보다 훨씬 다양한 범위의 로그가 있습니다.

131

부록 B: 대소문자 구분Splunk는 대소문자를 구분하는 것도 있고, 그렇지 않은 것도 있습니다. 표 B-1을 참조하십시오.

표 B-1. 대소문자 구분

구분 구분 안함 예명령어 이름 X TOP, top, sTaTs명령어 키워드 X AS used by stats, re-

name, …; BY used by stats, chart, top, …;WITH used by replace

검색어 X error, ERROR, Error통계 함수 X avg, AVG, Avg used by

stats, chart, …부울 연산자 X

(대문자)

AND, OR, NOT (boolean operators)vs. and, or, not (lit-eral keywords)

필드 이름 X host vs. HOST필드 값 X host=localhost,

host=LOCALhost정규식 X \d\d\d vs. \D\D\Dreplace com-mand

X error vs. ERROR

133

부록 C: 주요 명령어다음은 최종 사용자의 샘플에서 그리고 Splunk 애플리케이션에서 가장 많이 사용되는 검색 명령어들입니다.

최종 사용자의 주요 검색 명령어 Splunk 애플리케이션의 주요 검색 명령어

명령어 비중 명령어 비중

search 10964 search 1030

eval 4840 stats 232

fields 2045 timechart 215

stats 1840 eval 211

rename 1416 fields 142

timechart 1185 top 116

sort 1127 dedup 100

dedup 730 rename 96

fillnull 534 chart 79

rex 505 sort 76

table 487 rex 42

convert 467 head 29

metadata 451 multikv 26

loadjob 438 collect 25

chart 437 sitop 21

where 384 convert 20

append 373 where 17

join 314 fillnull 17

head 307 regex 17

top 280 format 16

transaction 260 lookup 14

Exploring Splunk

134

makemv 209 outlier 12

rangemap 202 join 9

appendcols 201 replace 9

lookup 157 streamstats 8

replace 102

135

부록 D: 주요 리소스본 설명서에서 다룬 내용 이외에도 Splunk에 대해 알아두면 유용한 많은 정보가 있습니다. 자세한 정보는 아래 웹 사이트를 참조하십시오. 아래 링크들은 ttp://splunk.com/goto/book#links에도 나와 있습니다.

Splunk 다운로드 페이지 http://splunk.com/downloadSplunk 설명서 및 문서 http://docs.splunk.comSplunk 커뮤니티 http://splunkbase.com 커뮤니티 기반 문서 http://innovato.com교육 비디오 http://splunk.com/view/SP-CAAAGB6Splunk 비디오 http://splunk.com/videosSplunk 블로그 http://blogs.splunk.comSplunk TV http://splunk.tv

137

부록 E: Splunk 빠른 참조 가이드

개념

개요인덱스-시간 처리: Splunk는 호스트(예: "내 시스템")에서 파일 또는 포트와 같이 소스로부터 데이터를 읽고, 해당 소스를 sourcetype(예:syslog, access_combined 또는 apache error)으로 분류한 후, 타임스탬프를 추출하고, 소스를 개별 이벤트(예: 로그 이벤트, 경고)로 나눕니다. 이러한 개별 이벤트는 한 줄 혹은 여러 줄로 구성될 수 있으며, 각 이벤트를 디스크 상의 인덱스에 작성해 나중에 검색에 사용할 수 있습니다.

검색-시간 처리: 검색이 시작되면 일치하는, 인덱스된 이벤트가 디스크로부터 검색되고, 이벤트 텍스트로부터 필드(예: code=404 또는 user=david,...)가 추출됩니다. 그리고 eventtype 정의(예: error 또는 login)에 맞는 일치 작업을 통해 이벤트가 분류됩니다. 검색을 통해 반환된 이벤트는 SPL을 사용해 강력하게 변환되어 대시보드에 표시되는 보고서를 생성합니다.

이벤트이벤트는 한 줄 데이터입니다. 다음은 웹 활동 로그의 이벤트입니다.

173.26.34.223 - - [01/Jul/2009:12:05:27 -0700] “GET /trade/app?action=logout HTTP/1.1” 200 2953

좀 더 구체적으로 설명하면, 이벤트는 타임스탬프와 관련된 값의 집합입니다. 대부분의 이벤트가 한두 줄 정도로 짧은데, 전체 텍스트 문서, 구성 파일 또는 전체 Java 스택 트레이스와 같이 긴 이벤트도 있습니다. Splunk는 검색 결과에 표시할 이벤트를 어떻게 나눌지를 결정하기 위해 줄바꿈 규칙을 사용합니다.

Exploring Splunk

138

Source 및 SourcetypeSource는 이벤트가 발생한 파일, 스트림 또는 기타 입력의 이름입니다. 예: /var/log/messages 또는 UDP:514. Source는 sourcetype으로 분류됩니다. sourcetype은 access_combined(웹 서버 로그)와 같이 잘 알려진 것일 수도 있으나, 데이터와 source를 확인했으나 해당 source가 이전에 본 적이 없는 형식일 경우 Splunk에 의해 sourcetype이 즉석에서 생성될 수도 있습니다. 동일한 sourcetype을 가진 이벤트가 서로 다른 source에서 발생한 것일 수 있습니다. 예를 들어, 파일 /var/log/messages의 이벤트와 udp:514의 syslog 입력에서 발생한 이벤트는 모두 sourcetype=linux_syslog를 가질 수 있습니다.

Hosthost는 이벤트가 발생한 물리적 장치 또는 가상 장치의 이름입니다. Host는 특정 장치에서 발생하는 모든 데이터를 찾는 가장 쉬운 방법을 제공합니다.

인덱스Splunk에 데이터를 추가할 때, Splunk는 데이터를 처리하고 데이터를 개별 이벤트, 타임스탬프 및 이벤트로 나누어, 이를 인덱스에 저장해서 나중에 데이터를 검색하고 분석할 수 있도록 합니다. 기본적으로 Splunk에 제공하는 데이터는 main 인덱스에 저장되지만, 서로 다른 데이터 입력을 위해 Splunk가 사용하기 위해 다른 인덱스를 만들고 지정할 수 있습니다.

필드필드는 이벤트 데이터에서 검색 가능한 이름/값의 쌍입니다. Splunk는 인덱스 시점 및 검색 시점에 이벤트를 처리하면서 자동으로 필드를 추출합니다. Splunk는 인덱스를 만드는 동안 각 이벤트에 대해 host, source 및 sourcetype을 비롯한 몇 가지의 기본 필드를 추출합니다. 또한 검색 시점에는 userid=jdoe와 같이 명확한 필드 이름/값 쌍과 사용자 지정 패턴을 포함하여, 이벤트 데이터로부터 광범위한 종류의 필드를 추출합니다.

태그태그는 필드 값에 대한 별칭입니다. 예를 들어, 두 개의 호스트 이름이 동일한 컴퓨터를 참조할 경우 두 호스트 값 모두에 동일한 태그를 제공할 수 있습니다(예: hal9000). tag=hal9000을 검색하면 Splunk는 두 호스트 이름 값과 관련된 이벤트를 반환합니다.

부록 E: Splunk 빠른 참조 안내서

139

Event TypeEvent type은 Event type의 검색 정의와 일치할 경우 이벤트에 첨부되는 동적 태그입니다. 예를 들어, problem이라고 하는 Event type을 검색 정의인 error OR warn OR fatal OR fail로 정의할 경우, 검색 결과에 error, warn, fatal 또는 fail이 포함될 때마다 해당 이벤트는 eventtype=problem인 eventtype 필드/값을 가집니다. 만약 login을 검색하면 문제가 있는 로그인은 eventtype=problem이라는 주석이 붙습니다. Event type은 검색 시 이벤트 범주를 분류하는 상호 참조되는 검색입니다.

보고서 및 대시보드서식 정보(예: 테이블 또는 차트)를 가지고 있는 검색 결과를 비공식적으로는 보고서라고 하며, 대시보드라고 하는 공통 페이지에 여러 보고서를 표시할 수 있습니다.

앱앱은 Splunk 구성, 개체 및 코드의 집합입니다. 앱을 통해서 Splunk에서 사용할 수 있는 다른 환경들을 구축할 수 있습니다. 예를 들어 문제 해결 이메일 서버를 위한 앱이나 웹 분석을 위한 앱 등을 보유할 수 있습니다.

권한/사용자/역할저장된 Splunk 개체(예: savedsearches, eventtypes, reports 및 tags)는 데이터가 더 쉽게 검색되고 파악될 수 있도록 만들어 데이터를 강화합니다. 이러한 개체는 권한이 있으며, 역할(예: admin, power, user)별로 다른 사용자와 비공개되거나 공유될 수 있습니다. 역할은 특정 역할이 데이터를 추가하거나 또는 보고서를 편집할 수 있는지 여부와 같이, 정의를 할 수 있는 기능 집합입니다. Splunk 무료 버전은 사용자 인증을 지원하지 않습니다.

트랜잭션트랜잭션은 좀 더 쉬운 분석을 위해 이벤트 집합을 하나로 그룹화합니다. 예를 들어, 고객 온라인 쇼핑은 동일한 SessionID로 여러 웹 액세스 이벤트를 생성하므로 이러한 이벤트를 하나의 트랜잭션으로 그룹화하는 것이 편리합니다. 트랜잭션 이벤트가 하나인 경우 이용자가 쇼핑몰에 머무른 시간, 구입한 물품 수, 어떤 이용자들이 물품을 구매하고 환불했는지 등에 대한 통계를 생성하는 것이 더욱 쉬워집니다.

Exploring Splunk

140

Forwarder/인덱서Forwarder는 사용자가 중앙 Splunk 인덱서 또는 인덱서 그룹에 데이터를 전송할 수 있는 Splunk 버전입니다. 인덱서는 로컬/원격 데이터에 대한 인덱싱 기능을 제공합니다.

SPL검색은 일련의 명령어와 인수로, 파이프 문자(|)로 연결되어 있습니다. 파이프 문자는 하나의 명령어에서 나온 출력을 다음 명령어에 제공합니다.

search-args | cmd1 cmd-args | cmd2 cmd-args | ...

검색 명령어는 인덱스된 데이터를 가져와 원하지 않는 정보를 필터링하고, 추가 정보를 추출하고, 값을 계산 및 변환하고, 결과를 통계 분석하는데 사용됩니다. 인덱스로부터 검색된 검색 결과는 동적으로 생성된 테이블로 간주할 수 있습니다. 각 검색 명령어는 해당 테이블의 모양을 다시 정의합니다. 인덱스된 각 이벤트는 각 필드 값에 대해 컬럼


141

을 가진 행입니다. 컬럼에는 데이터에 대한 기본 정보가 포함되고 검색 시간에 동적으로 추출된 데이터입니다.

각 검색의 헤드에는 암시적인 search-the-index-for-events 명령어가 있습니다. 이 명령어는 키워드(예: error), 부울 식(예: (error OR fail-ure) NOT success), 구문(예: “database error”), 와일드카드(예: fail* matches fail, fails, failure), 필드 값(예: code=404), 부등식(예: code!=404 또는 code>200), 값이 있거나 값이 없는 필드(예: code=* 또는 NOT code=*)를 검색하는 데 사용할 수 있습니다. 예:

sourcetype=”access_combined” error | top 10 uri

위 검색은 error(AND는 검색어 간에 암시적으로 내재)라는 단어를 포함하는 인덱스된 access_combined 이벤트를 디스크에서 검색한 후, 검색된 이벤트에 대해 가장 흔히 나오는 상위 10개 URL 값을 보고합니다.

하위 검색하위 검색은 자체 검색을 실행하는 명령에 대한 인수로, 상위 명령어에 인수 값으로서 결과를 반환합니다. 하위 검색은 대괄호로 둘러쌉니다. 예를 들어, 이 명령어는 다음과 같이 마지막 로그인 오류가 있는 사용자로부터 나온 모든 syslog 이벤트를 검색합니다.

sourcetype=syslog [search login error | return user]

하위 검색은 return 명령어가 기본적으로 하나의 값만 반환하기 때문에 하나의 사용자 값을 반환합니다. 물론 더 많은 값을 반환하도록 설정할 수 있는 옵션이 있습니다(예: | return 5 user).

상대적 시간 수정자사용자 인터페이스에서 사용자 지정 시간 범위를 사용하는 것 외에도 latest 및 earliest 검색 수정자를 사용하여 검색할 이벤트의 시간 범위를 지정할 수 있습니다. 상대 시간의 지정은 시간의 양(숫자와 단위)을 나타내는 문자열과 선택적으로 정시 맞춤 조정자(snap to time unit)를 이용해 지정할 수 있습니다.

[+|-]<time_integer><time_unit>@<snap_time_unit>

예를 들어, error earliest=-1d@d latest=-1h@h는 어제(자정으로 맞춤)부터 최종 시간까지(해당 시간으로 맞춤)의 error를 포함하는 이벤트를 검색합니다.

시간 단위: 초(s), 분(m), 시간(h), 일(d), 주(w), 월(mon), 분기(q) 또는 년(y)으로 지정됩니다. 단위 앞에 붙는 숫자는 기본적으로 1입니다(예를 들어, m은 1m과 동일).

Exploring Splunk

142

시간 맞춤: 시간을 내림하여 가장 가까운 최신 시간을 나타냅니다. 정시 맞춤은 지정된 시간을 넘지 않는 가장 최근 시간으로 맞춥니다. 예를 들어, 11:59:00을 시간(@h)으로 "정시 맞춤"하면 12:00가 아니라 11:00에 맞춰집니다. 요일도 맞출 수 있습니다. 일요일은 @w0, 월요일은 @w1...을 사용하면 됩니다.

공통 검색 명령

명령chart/timechart 테이블 형식의 출력을 (시간 기반) 차트 형식으로

결과를 반환합니다.

dedup 반복적으로 발생하는 일치 결과를 제거합니다.

eval 식을 계산합니다. (EVAL 함수 테이블 참조)

fields 검색 결과에서 필드를 제거합니다.

head/tail 첫 번째/N 번째 결과를 반환합니다.

lookup 외부 소스의 필드 값을 추가합니다.

rename 지정된 필드 이름을 변경합니다. 와일드카드를 사용하여 여러 필드를 지정할 수 있습니다.

replace 지정된 필드의 값을 지정된 새 값으로 대체합니다.

rex 정규식을 지정하여 필드 추출에 사용합니다.

search 검색 식과 일치하도록 결과를 필터링합니다.

sort 지정된 필드를 기준으로 검색 결과를 정렬합니다.

stats 통계를 제공합니다. 원할 경우 필드별로 그룹화할 수 있습니다.

top/rare 필드의 가장 흔한 값/드문 값을 보여줍니다.

transaction 검색 결과를 트랜잭션으로 그룹화합니다.

검색 최적화빠른 검색을 하기 위한 방법은 디스크에서 읽는 데이터를 최대한 최소화하도록 제한한 후 가능한 빨리 데이터를 필터링해서 가장 적은 양의 데이터에서 처리가 이루어지도록 하는 것입니다.

여러 데이터 유형에 걸쳐 검색을 수행하는 경우가 거의 드물다면 데이터를 개별 인덱스로 파티셔닝하십시오. 예를 들어, 하나의 인덱스에는 웹 데이터를 넣고, 또 다른 인덱스에는 방화벽 데이터를 넣습니다.


143

유용한 팁:

• 가능한 세부적으로 검색합니다(*error* 대신 fatal_error).

• 시간 범위를 제한합니다(예: -1w 대신 -1h).

• 가능한 빨리 불필요한 필드를 필터링하여 제거합니다.

• 계산 전에 최대한 빨리 결과를 필터링하여 제거합니다.

• 보고서 생성 검색의 경우, 시간대를 계산하는 시간 표시줄 보기 대신에 고급 차트 작성 보기를 사용합니다.

• 필요하지 않을 경우 필드 검색 스위치를 끕니다.

• 요약 인덱스를 사용하여 흔히 사용하는 값을 미리 계산합니다.

• 해당 디스크 I/O가 사용 가능한 것 중 가장 빠른지 확인합니다.

검색 예제

결과 필터링행 텍스트에 fail이 있고 status=0인 항목만 결과에 포함되도록 필터링합니다.

… | search fail status=0

동일한 호스트 값을 가진 중복 결과를 제거합니다.

… | dedup host

_raw 필드에 라우팅할 수 없는 클래스 A (10.0.0.0/8)의 IP 주소가 있는 검색 결과만 유지합니다.

… | regex _raw="(?<!\d)10.\ d{1,3}\.\d{1,3}\.\d{1,3}(?!\d)"

결과 그룹화클러스터 결과를 cluster_count 값별로 정렬한 다음 데이터 크기가 가장 큰 20개 클러스터를 반환합니다.

… | cluster t=0.9 showcount=true | sort limit=20 -cluster_count

동일한 호스트와 쿠키가 있으며 각각 30초 이내에 발생하고 각 이벤트 간 일시 정지 시간이 5초를 넘지 않는 검색 결과를 트랜잭션으로 그룹화합니다.

… | transaction host cookie maxspan=30s maxpause=5s

동일한 IP 주소로 결과를 그룹화하고(clientip), 첫 번째 결과에 로그온이 포함되고 마지막 결과에 구매가 포함됩니다.

… | transaction clien-tip startswith="signon" endswith="purchase"

Exploring Splunk

144

결과 순서 지정처음 20개의 결과를 반환합니다. … | head 20결과 집합의 순서를 반대로 바꿉니다.

… | reverse

ip 값을 기준으로 결과를 오름차순으로 정렬한 다음 url 값을 기준으로 내림차순으로 정렬합니다.

… | sort ip, -url

마지막 20개의 결과를 반환합니다(역순).

… | tail 20

보고희귀 값을 가진 이벤트를 반환합니다.

… | anomalousvalue action=filter pthresh=0.02

"size"별로 최대 "delay"를 반환합니다. 여기서 "size"는 최대 10개의 같은 크기 버킷으로 분할됩니다.

… | chart max(delay) by size bins=10

bar 값으로 분할된 각 foo 값에 대해 max(delay)를 반환합니다.

… | chart max(delay) over foo by bar

각 foo 값에 대해 max(delay)를 반환합니다.

… | chart max(delay) over foo

범위를 벗어난 숫자 값을 모두 제거합니다.

… | outlier

동일한 호스트 값을 가진 중복 결과를 제거하고 남은 총 결과 수를 반환합니다.

… | stats dc(host)

lay 문자열로 끝나는 고유 필드(예: delay, xdelay, relay)의 매시간 평균을 반환합니다.

… | stats avg(*lay) by date_hour

각 호스트의 분당 CPU의 평균값을 계산합니다.

… | timechart span=1m avg(CPU) by host

호스트별 웹 소스의 개수에 대한 시간 차트를 만듭니다.

… | timechart count by host

url 필드의 가장 일반적인 20개 값을 반환합니다.

… | top limit=20 url

url 필드의 가장 드문 값을 반환합니다.

… | rare url


145

필드 추가속도를 거리/시간으로 설정합니다. … | eval velocity=distance/

time정규식을 사용하여 from 및 to 필드를 추출합니다. 원시 이벤트에 From:이 포함된 경우 Susan To: David, 그 다음 from=Susan 및 to=David.

… | rex field=_raw "From: (?<from>.*) To: (?<to>.*)"

총 실행 개수 누계를 total_count라는 필드에 저장합니다.

… | accum count as total_count

count가 있는 각 이벤트에 대해 count와 이전 값의 차이를 계산한 후 그 결과를 countdiff에 저장합니다.

… | delta count as countdiff

필드 필터링host 및 ip 필드만 유지하고 host, ip대로 순서대로 표시합니다.

… | fields + host, ip

host 및 ip 필드를 제거합니다. … | fields - host, ip

필드 수정

host 및 ip 필드만 유지하고 host, ip 순서대로 표시합니다.

… | fields + host, ip

host 및 ip 필드를 제거합니다. … | fields - host, ip

다중값 필드recipients 필드의 다중값을 하나의 값으로 결합합니다.

… | nomv recipients

상위 수신인을 표시하면서 recipients 필드의 값을 여러 필드 값으로 분리합니다.

… | makemv delim="," recipi-ents | top recipients

다중값 필드 recipients의 각 값에 대해 새 값을 생성합니다.

… | mvexpand recipients

RecordNumber를 제외하고, 동일한 각 결과를 결합시킵니다. Record-Number를 다양한 모든 값을 가진 다중값 필드로 설정합니다.

… | fields EventCode, Category, RecordNumber| mvcombine delim=”,” Record-Number

recipient 값의 숫자를 찾습니다. … | eval to_count = mvcount(recipients)

recipient 필드에서 첫 번째 이메일 주소를 검색합니다.

… | eval recipient_first = mvindex(recipient,0)

Exploring Splunk

146

.net 또는 .org로 끝나는 모든 re-cipient 값을 검색합니다.

… | eval netorg_recipients = mvfilter(match(recipient, "\.net$") OR match(recipient, "\.org$"))

foo 필드의 값에 "bar"라는 문자열과 baz 필더의 값을 추가하여 newval 필드를 만듭니다.

… | eval newval = mvappend(foo, "bar", baz)

"\.org$"와 일치하는 첫 번째 수신인 값의 인덱스를 검색합니다.

… | eval orgindex = mvfind(recipient, "\.org$")

룩업 테이블룩업 테이블 usertogroup에서 각 이벤트 사용자 필드의 값을 조회하고 이벤트의 그룹 필드를 설정합니다.

… | lookup usertogroup user output group

검색 결과를 룩업 파일 users.csv에 작성합니다.

… | outputlookup users.csv

검색 결과로서 룩업 파일 users.csv를 읽습니다.

… | inputlookup users.csv

EVAL 함수eval 명령어는 식을 계산하고 결과 값을 필드(예: “...| eval force = mass * acceleration”)에 넣습니다. 다음 표는 기본적인 산술 연산자(+ - * / %), 문자열 연결(예: ‘...| eval name = last . “, “ . last’), 그리고 부울 연산자(AND OR NOT XOR < > <= >= != = == LIKE) 외에 eval이 이해하는 함수의 리스트입니다.

Eval 함수 테이블

함수 설명 예abs(X) 절대값 X를 반환합니다. abs(number)case(X,"Y",…) X와 Y를 인수 쌍으로 다

룹니다. 여기서 X 인수는 부울 식이며, TRUE로 계산하는 경우 해당되는 Y 인수를 반환합니다.

case(error == 404, "Not found", error == 500,"Internal Server Error", er-ror == 200, "OK")

ceil(X) 숫자 X 실링 ceil(1.9)cidrmatch("X",Y) 서브넷에 속하는 IP 주

소를 식별합니다.cidrmatch("123.132. 32.0/25",ip)

coalesce(X,…) null이 아닌 첫 번째 값을 반환합니다.

coalesce(null(), "Returned val", null())


147

exact(X) 배정도 부동소수점 연산을 사용하여 식 X를 계산합니다.

exact(3.14*num)

exp(X) eX를 반환합니다. exp(3)floor(X) 숫자 X의 가장 작은 값

을 반환합니다.floor(1.9)

if(X,Y,Z) X가 TRUE로 평가되면 결과는 두 번째 인수 Y입니다. X가 FALSE로 평가될 경우 그 결과는 세 번째 인수 Z가 됩니다.

if(error==200, "OK", "Error")

isbool(X) X가 부울일 경우 TRUE를 반환합니다.

isbool(field)

isint(X) X가 정수일 경우 TRUE를 반환합니다.

isint(field)

isnotnull(X) X가 NULL이 아닐 경우 TRUE를 반환합니다.

isnotnull(field)

isnull(X) X가 NULL일 경우 TRUE를 반환합니다.

isnull(field)

isnum(X) X가 숫자일 경우 TRUE를 반환합니다.

isnum(field)

isstr() X가 문자열일 경우 TRUE를 반환합니다.

isstr(field)

len(X) 이 함수는 문자열 X의 문자 길이를 반환합니다.

len(field)

like(X,"Y") X가 Y의 SQLite 패턴과 유사한 경우(유사한 경우에만) TRUE를 반환합니다.

like(field, "foo%")

ln(X) 자연 로그 X를 반환합니다.

ln(bytes)

log(X,Y) 두 번째 인수 Y를 기본으로 사용하여 첫 번째 인수 X에 대한 로그를 반환합니다. Y의 기본값은 10입니다.

log(number,2)

lower(X) 소문자 X를 반환합니다. lower(username)ltrim(X,Y) 왼쪽에서부터 트리밍된

Y에서 해당 문자로 X를 반환합니다. Y는 기본적으로 공백과 탭으로 지정됩니다.

ltrim(" ZZZabcZZ ", " Z")

Exploring Splunk

148

match(X,Y) X가 정규식 패턴 Y와 일치할 경우 True를 반환합니다.

match(field, "^\d{1,3}\.\d$")

max(X,…) 두 개의 값보다 큰 값을 반환합니다.

max(delay, mydelay)

md5(X) 문자열 값 X의 MD5 해시를 반환합니다.

md5(field)

min(X,…) 분을 반환합니다. min(delay, mydelay)mvcount(X) X 값의 개수를 반환합

니다.mvcount(multifield)

mvfilter(X) 부울 식 X를 기준으로 다중값 필드를 필터링합니다.

mvfilter(match(emai l, "net$"))

mvindex(X,Y,Z) 시작점(0 기반) Y에서 Z(옵션)로 다중값 필드 X의 하위 집합을 반환합니다.

mvindex( multifield, 2)

mvjoin(X,Y) 다중값 필드 X와 문자열 구분자 Y가 주어진 경우 Y를 사용하여 X 각각의 값을 조인합니다.

mvjoin(foo, ";")

now() Unix 시계에 표시되는 현재 시간을 반환합니다.

now()

null() 인수가 없어 NULL을 반환합니다.

null()

nullif(X,Y) 두 개의 인수, 필드 X와 Y가 주어진 상태에서 이 인수들이 서로 다를 경우 X를 반환하고, 그렇지 않으면 NULL을 반환합니다.

nullif(fieldA, fieldB)

pi() 상수 pi를 반환합니다. pi()pow(X,Y) XY를 반환합니다. pow(2,10)random() 0 - 2147483647 범위의

유사 랜덤 숫자를 반환합니다.

random()

relative_time(X,Y) epochtime 시간 X와 상대적 시간 지정자 Y가 주어진 경우 X에 적용된 epochtime 값 Y를 반환합니다.

relative_time(now(),"-1d@d")


149

replace(X,Y,Z) 문자열 X에서 정규식 문자열 Y가 발생할 때마다 문자열 Z를 치환해서 구성된 문자열을 반환합니다.

Returns date with the month and day numbers switched, so if the in-put is 1/12/2009 the return value is 12/1/2009: replace(date, "^(\d{1,2})/(\d{1,2})/", "\2/\1/")

round(X,Y) Y에 의해 지정된 소수점 자리만큼 반올림한 X를 반환합니다. 기본값은 정수로 반올림입니다.

round(3.5)

rtrim(X,Y) 오른쪽에서부터 트리밍된 Y에서 해당 문자로 X를 반환합니다. Y가 지정되지 않은 경우 공백과 탭은 잘립니다.

rtrim(" ZZZZabcZZ ", " Z")

searchmatch(X) 이벤트가 검색 문자열 X와 일치할 경우 true를 반환합니다.

searchmatch("foo AND bar")

split(X,"Y") 구분자 Y로 분활된 다중값 필드로 X를 반환합니다.

split(foo, ";")

sqrt(X) 제곱근 X를 반환합니다. sqrt(9)strftime(X,Y) Y에 의해 지정된 형식

을 사용하여 랜더링된 epochtime 값 X를 반환합니다.

strftime(_time, "%H:%M")

strptime(X,Y) 문자열 X로 표시되는 시간의 경우, 형식 Y로 구문 분석된 값을 반환합니다.

strptime(timeStr, "%H:%M")

substr(X,Y,Z) Z(옵션) 문자에 대해 시작점(1 기반) Y에서 하위 문자열 필드 X를 반환합니다.

substr("string", 1, 3) +substr("string", -3)

time() 마이크로초 단위의 wall-clock 시간을 반환합니다.

time()

Exploring Splunk

150

tonumber(X,Y) 입력 문자열 X를 숫자로 변환합니다. 여기서 Y(옵션, 기본값 10)는 변환될 숫자의 기본값을 정의합니다.

tonumber("0A4",16)

tostring(X,Y) 필드 값 X를 문자열로 반환합니다. X가 숫자인 경우 문자열로 재포맷합니다. 부울 값일 경우 "True"이거나 "False"입니다. X가 숫자인 경우 두 번째 인수 Y는 옵션이며, "hex"(X를 16진수로 변환), "commas"(콤마와 2자리 소수점으로 X 형식 지정) 또는 "duration"(초 X를 HH:MM:SS로 변환) 중 하나가 됩니다.

This example re-turns foo=615 and foo2=00:10:15:… | eval foo=615 |eval foo2=tostring(foo,” duration”)

trim(X,Y) 양쪽에서부터 트리밍된 Y에서 해당 문자로 X를 반환합니다. Y가 지정되지 않은 경우 공백과 탭은 잘립니다.

trim(" ZZZZabcZZ ", " Z")

typeof(X) 해당 유형의 문자열 표현을 반환합니다.

This example returns: "NumberStringBoolIn-valid":typeof(12)+ typeof(“string”)+ typeof(1==2)+ typeof(badfield)

upper(X) 대문자 X를 반환합니다. upper(username)urldecode(X) 디코딩된 URL X를 반환

합니다.urldecode(“http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader”)

validate(X,Y,…) 부울 식 X와 문자열 Y로된 인수 쌍이 있는 경우, False로 평가되고 모두 True인 경우 NULL로 기본값이 설정되는 첫 번째 식 X에 해당하는 문자열 Y를 반환합니다.

validate(isint(port), "ERROR: Port is not an integer", port >= 1 AND port <= 65535, "ERROR: Port is out of range")


151

공통 STATS 함수chart, stats 및 timechart 명령어를 사용하는 일반적인 통계 함수입니다. 필드 이름에 와일드카드를 사용할 수 있습니다. 따라서 avg(*delay)는 delay와 xdelay 필드의 평균을 계산할 수 있습니다.

함수 설명avg(X) 필드 X의 값 평균을 반환합니다.

count(X) 필드 X의 발생횟수를 반환합니다. 일치하는 필드값을 나타내려면 X 형식을 eval(field="value")로 지정합니다.

dc(X) 필드 X의 개별 값 개수를 반환합니다.

first(X) 첫 번째 보이는 필드 X 값을 반환합니다. 일반적으로 첫 번째 보이는 필드 값이 시간순으로 가장 최근의 인스턴스 필드입니다.

last(X) 가장 마지막에 본 필드 X 값을 반환합니다.

list(X) 이 필드 X의 모든 값 리스트를 다중값 항목으로 반환합니다. 값의 순서는 입력 이벤트의 순서를 반영합니다.

max(X) 필드 X의 최대값을 반환합니다. 값 X가 숫자가 아닐 경우 최대값은 사전 순서로 표시됩니다.

median(X) 필드 X의 가장 중간 값을 반환합니다.

min(X) 필드 X의 최소값을 반환합니다. 값 X가 숫자가 아닐 경우 최소값은 사전 순서로 표시됩니다.

mode(X) 필드 X의 최빈값을 반환합니다.

perc<X>(Y) 필드 Y의 X백분위수를 반환합니다. 예를 들어, perc5(total)는 필드 전체 값에서 5백분위수 값을 반환합니다.

range(X) 필드 X의 최대값과 최소값 사이의 차이를 반환합니다.

stdev(X) 필드 X의 표본 표준편차를 반환합니다.

stdevp(X) 필드 X의 모 표준편차를 반환합니다.

sum(X) 필드 X의 값 합계를 반환합니다.

sumsq(X) 필드 X 값의 제곱 합계를 반환합니다.

values(X) 필드 X의 모든 개별 값 리스트를 다중값 항목으로 반환합니다. 값 순서는 사전 순서로 정렬됩니다.

var(X) 필드 X의 표본 분산을 반환합니다.

Exploring Splunk

152

정규식정규식은 regex 및 rex 검색 명령어, eval 함수 match() 및 replace() 그리고 필드 추출 등 많은 영역에서 유용하게 사용됩니다.

정규식 참고사항 예제 설명\s 공백 \d\s\d 숫자 공백 숫자

\S 공백 아님 \d\S\d 숫자 비공백 숫자

\d 숫자 \d\d\d-\d\d-\d\d\d\d

SSN

\D 숫자 아님 \D\D\D 세 개의 비숫자

\w 단어 문자(글자, 숫자 또는 _ )

\w\w\w 세 자리 단어 문자

\W 단어 문자 아님 \W\W\W 세 개의 비단어 문자

[...] 모든 문자 포함 [a-z0-9#] a - z, 0 - 9 또는 # 문자

[^...] 문자 포함 안 됨 [^xyx] x, y, z가 아닌 모든 문자

* 0 이상 \w* 0 이상의 단어 문자

+ 하나 이상 \d+ 정수

? 0/1 \d\d\d-?\d\d-?\d\d\d\d

대시 구분 SSN(옵션)

| Or \w|\d 단어 또는 숫자 문자

(?P<var> ...)

이름 지정 추출 (?P<ssn>\d\d\d-\d\d\-\d\d\d\d)

pull out a SSN and assign to 'ssn' field

(?: ... ) 논리적 그룹화 (?:\w|\d)|(?:\d|\w)

단어 문자 다음에 숫자 OR 숫자 다음에 단어 문자

^ 줄 시작 ^\d+ 적어도 하나의 숫자로 줄 시작

$ 줄 종료 \d+$ 적어도 하나의 숫자로 줄 종료

{...} 반복 수 \d{3,5} 3-5 숫자 사이

\ Escape \[ [ 문자 이스케이프

(?= ...) 미리보기(Looka-head)

(?=\D)error error must be preceded by a non-digit


153

(?! ...) 부정적 미리보기(negative looka-head)

(?!\d)error 숫자가 선행할 수 없는 오류

공통적인 SPLUNK STRPTIME 함수strptime 형식은 eval 함수 strftime() 및 strptime()와 시간스탬프 이벤트 데이터에 유용합니다.

시간 %H 24시간제(00 - 23) (선행 0)

%I 12시간제(01- 12) (선행 0)

%M 분(00 - 59)

%S 초(00 0 61)

%N 간격(%3N = millisecs, %6N = microsecs, %9N = nanosecs)로 하위초

%p AM 또는 PM

%Z 시간대(GMT)%s 1/1/1970 이후부터 초(1308677092)

일 %d 한달 중 일 수(01 - 31) (선행 0)

%j 일년 중 일 수(001 - 366)

%w 일주일 중 일 수(0 - 6)

%a 요일 줄임말(일)

%A 요일(일요일)

%b 월 줄임말(1)

%B 월 이름(1월)

%m 월(01 - 12)

%y 두자리 연도(00 - 99)

%Y 연도(2008)

%Y-%m-%d 1998-12-31

%y-%m-%d 98-12-31

%b %d, %Y Jan 24, 2003

%B %d, %Y January 24, 2003

q|%d %b '%y = %Y-%m-%d

q|25 Feb '03 = 2003-02-25|

Exploring Splunk

154

download the book: (pdf)

Documents