Exploring Splunk SPL(검색 처리 언어) 입문서 및 설명서 David Carasso(Splunk의 Chief Mind) 저

Transcription

1 Exploring Splunk Exploring Splunk David Carasso 빅 데이터는 엄청난 비즈니스 가치를 가지고 있습니다. Splunk는 이러한 가치를 캐내는 데 최상의 도구입니다. Exploring Splunk 는 시스템 생성 데이터의 범람 속에서 어떻게 답을 찾아가고 잘 알려져 있지 않은 패턴을 찾아내는지 보여줍니다. 이 설명서는 Splunk 사용 방법을 빨리 익히도록 시각적 프레젠테이션 스타일로 작성되었습니다. Splunk 기초 사항을 먼저 마스터한 후에 실제 사용 환경에서 일어날 수 있는 문제들을 어떻게 창의적으로 해결하고, 빅 데이터에 숨겨진 보석들을 어떻게 찾아내는지 알아봅니다. Splunk의 Chief Mind인 David Carasso씨는 Splunk의 제3의 직원이었습니다. 검색 처리 언어(SPL), 동적 이벤트 및 소스 태깅, 자동 필드 추출, 트랜잭션 그룹화, 이벤트 어그리게이션, 타임스탬핑 등등 Splunk 코어에서 어려운 문제들을 혁신하고 시제품화하는 역할을 맡고 있습니다. 그는 Splunk를 이용한 작업과 관련하여 2개의 특허를 보유하고 있으며 캘리포니아 마린카운티에서 아내와 3명의 아이들과 살고 있습니다. CITO Research $25.00 US Exploring Splunk 검색 처리 언어(SPL) 프리미어 및 쿡북 작성: Splunk Chief Mind 'David Carasso'

2 Exploring Splunk SPL(검색 처리 언어) 입문서 및 설명서 David Carasso(Splunk의 Chief Mind) 저

3 Exploring Splunk (저자: David Carasso) Copyright 2012 by Splunk Inc. All rights reserved. 미국에서 인쇄됨 Splunk, Inc.는 내부 사용 또는 개인적인 용도로 이 책자의 항목을 복사 할 수 있는 권한을 부여합니다. Splunk, Inc.의 명시적인 서면 동의 없이 는 그 외의 사용 목적으로는 복사할 수 없습니다. CITO Research 발행, 1375 Broadway, Fl3, New York, NY 편집/분석: Dan Woods, Deb Cameron 카피에디터: Deb Cameron 제작 편집: Deb Gabriel 표지: Splunk, Inc. 그래픽: Deb Gabriel 초판: 2012년 4월 만반의 주의를 기울여 이 책을 제작했으나 발행자와 저자는 오류나 생 략 또는 이 책에 담긴 정보 사용에 따라 발생하는 손해에 대해 어떠한 책임도 지지 않습니다. 면책 조항 ISBN: ; 이 책은 텍스트북 및 참고 서적으로만 사용되도록 작성되었습니다. 실 제 Splunk 소프트웨어 제품 사용은 이 책에 작성된 내용이 아니라 해 당 소프트웨어의 사용권 계약에 따라 이루어져야 합니다. Splunk 소프 트웨어 제품을 사용하는 방법에 대한 정보는 이 책이 아니라 해당 제품 과 함께 제공되는 설명서를 참조하십시오. 이 책에 포함된 정보의 정확성과 적시성을 보장하기 위해 최대한의 주의를 기울였지만 Splunk는 정보의 정확성과 적시성을 보증 또는 보장하지 않으며 이 책의 정보와 관련되거나 정보 사용으로 인한 결과에 대해 어떠한 책임도 지지 않습니다. Splunk의 기능에 대한 자세한 설명은 docs.splunk.com을 참조하시기 바랍니다.

4 목차 머리말 이 책에 대하여 이 책의 내용 규칙 감사의 말씀 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

5 파이프 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

6 데이터를 탐색하여 데이터의 범위 이해 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 7 이벤트 그룹화 소개 95 방법 97 필드 이름 통합 97 불완전한 트랜잭션 찾기 97 트랜잭션 내의 시간 계산 99 최신 이벤트 찾기 100 반복 이벤트 찾기 101 트랜잭션 간 시간 102 특정 트랜잭션 찾기 104 다른 이벤트와 가까이 있는 이벤트 찾기 107 이벤트 후의 이벤트 찾기 108 그룹 그룹화 룩업 테이블 소개 113 lookup 113 inputlookup 113 outputlookup 114 추가 정보 114 방법 114 기본 룩업 값 설정 114 역방향 룩업 사용 114 2계층 룩업 116 여러 단계 룩업 사용 116 검색 결과에서 룩업 테이블 생성 117 Appending Results to Lookup Tables 117 대용량 룩업 테이블 사용 118 룩업 값과 결과 비교 120

8 룩업 일치 항목 제어 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

9 Event Type 139 보고서 및 대시보드 139 앱 139 권한/사용자/역할 139 트랜잭션 139 Forwarder/인덱서 140 SPL 140 하위 검색 141 상대적 시간 수정자 141 공통 검색 명령 142 검색 최적화 142 검색 예제 143 EVAL 함수 146 공통 STATS 함수 151 정규식 152 공통적인 SPLUNK STRPTIME 함수 153

10 머리말 Splunk Enterprise Software( Splunk )는 현재까지 경험할 수 있는 가장 강력한 데이터 검색 및 탐색 도구라고 할 수 있습니다. 이 책은 Splunk 자체뿐만 아니라 Splunk를 사용해 수행할 수 있는 작업을 소개하기 위 해 작성되었습니다. 또한 Splunk를 사용해 창의적인 작업을 수행하기 위한 출발점으로 이 책을 활용하실 수도 있습니다. 시스템 관리자와 네트워크 관리자 그리고 보안 전문가가 Splunk를 사 용하는 사례가 빈번하지만, 이러한 담당자들만 사용할 수 있도록 국한 된 것은 아닙니다. 기업의 데이터에는 Splunk로 활용할 수 있는 엄청 난 비즈니스 가치가 숨어 있습니다. 이 책은 오라일리(O'Reilly) 출판사 의 일반적인 기술 관련 서적의 독자 외에도 마케팅 전문가는 물론 빅 데이터 및 운영 인텔리전스에 관심이 있는 모든 사람을 위해 디자인되 었습니다. 이 책에 대하여 이 책의 주요 목표는 Splunk가 무엇인지를 알고 Splunk를 사용하는 방 법을 빠르게 이해할 수 있도록 도움을 주는 것입니다. 이 책에서는 이 러한 목표를 달성하기 위해 Splunk SPL (검색 처리 언어)의 가장 중요 한 부분을 설명합니다. Splunk는 기술자와 비즈니스 전문가 모두에게 여러 측면에서 도움이 됩니다. Splunk를 한 번에 모두 배울 수 있다고 생각하지 마시기 바랍니다. Splunk는 간단한 도구지만 다양한 일을 할 수 있는 야전용 다용도 나이프와도 같습니다. 이제 다음과 같은 질문이 떠오르실 것입니다. '이 책이 어떻게 도움이 될까?' 간단하게 말씀드리면 이 책에서는 Spunk를 사용해 무엇을 할 수 있고, 어디에서 궁금한 내용을 찾아볼 수 있는지를 알 수 있습니다. 하지만 이미 많은 Splunk 설명서가 있지 않나요? 예 그렇습니다. 보면 Splunk 시스템에 대한 자세한 설명 과 함께 다양한 설명서가 있습니다. 질문과 답변을 검색할 수 있는 데이터베 이스가 있습니다. 하지만 이러한 정보는 Splunk에 대해 사전 지식 이 있고 일반적인 문제를 해결하려는 경우에 도움이 됩니다. 이 책은 이 두 가지 수준의 설명서 사이에 속합니다. 이 책에서는 Splunk 의 가장 중요한 부분에 대해 기본적으로 설명하고 해당 설명과 더불어 실무에서 접하게 되는 문제에 대한 해결책을 함께 제공합니다. i

11 이 책의 내용 규칙 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를 선택합니 다 라고 표시됩니다.

12 감사의 말씀 시간과 재능을 나누어주신 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에게도 고마운 마음을 전합니다. iii

13

14 1부 Exploring Splunk

15

16 SPLUNK 소개 Splunk는 머신 데이터, 즉 시스템에서 대량으로 방출하지만 거의 효과 적으로 사용되지 않는 데이터를 분석하기 위한 강력한 플랫폼입니다. 머신 데이터는 기술 세계에서는 이미 중요한 가치를 가지고 있으며 비 즈니스 세계에서도 그 중요성이 점차 확대되고 있습니다. (머신 데이터 에 대해 자세히 알아보려면 부록 A를 참조하십시오.) Splunk의 기능과 다양성을 빠르게 이해하는 수단으로 데이터 센터 시 나리오와 마케팅 부서 시나리오를 제공합니다. 데이터 센터 복구 작업에 이용되는 Splunk 수요일 오전 2시입니다. 전화 벨이 울립니다. 상사의 전화로 웹 사이트 가 다운되었다고 합니다. 왜 다운되었을까요? 웹 서버, 애플리케이션, 데이터베이스 서버, 전체 디스크 또는 부하 분산기 중 무엇이 잘못되었 을까요? 상사는 당장 고치라고 소리를 지릅니다. 밖에는 비가 내리고 있습니다. 어떻게 해야할지 모르겠습니다. 안심하세요. 어제 Splunk를 구축했습니다. Splunk를 시동합니다. 한 곳에서 모든 웹 서버, 데이터베이스, 방화벽, 라우터 그리고 부하 분산기의 로그 파일은 물론 기타 모든 장치, 운영 체제 또는 관심이 있는 에플리케이션의 구성 데이터 파일을 검색할 수 있습니다. (여러 군데의 데이터센터나 클라우드 제공업체에 분산되어 있어도 문제 없습니다.) 웹 서버 트래픽의 그래프를 보면 언제 문제가 발생했는지 알 수 있습 니다. 오후 5:03분에 웹 서버의 오류가 폭증했습니다. 오류가 적힌 위 의 10페이지를 확인합니다. 홈 페이지에는 문제가 없습니다. 검색 페이 지에도 문제가 없습니다. 아! 장바구니가 문제군요. 5:03분부터 해당 페 이지에 대한 모든 요청이 오류를 일으켰습니다. 이 오류는 판매에 지장 을 주고 고객을 쫓아내는 격이기 때문에 재정적 손해를 유발하며 반드 시 해결해야 합니다. 장바구니는 데이터베이스에 연결된 전자상거래 서버에 의존한다는 것 을 알고 있습니다. 로그를 보니 데이터베이스는 가동 중입니다. 잘되었 군요. 전자상거래 서버 로그를 살펴보겠습니다. 오후 5:03분에 전자상 거래 서버에서 데이터베이스 서버에 연결할 수 없다는 메시지를 보내 기 시작합니다. 그런 다음 구성 파일의 변경 사항을 검색하고 누군가가 네트워크 설정을 변경했다는 것을 알아차렸습니다. 더 자세히 들여다 보니 잘못 변경되었군요. 설정을 변경한 사람에게 연락하여 변경 사항 을 롤백하도록 합니다. 시스템이 다시 작동하기 시작합니다. 신속하게 검색할 수 있는 중앙 인덱스로 Splunk가 모든 관련 정보를 수 집하기 때문에 이 모든 작업이 채 5분도 걸리지 않았습니다. 3

17 Exploring Splunk 마케팅 부서에서 이용되는 Splunk 대형 소매업체의 프로모션 부서에서 일하고 있습니다. 수신 트래픽 발 생량을 최적화하기 위해 검색 엔진 최적화 및 제품에 대한 프로모션을 조정했습니다. 지난 주에는 데이터센터 직원이 (지난 시간, 날, 주에 해 당하는 기간 동안) 회사 사이트를 찾기 위해 사용된 모든 검색어를 보 여주는 새 Splunk 대시보드를 설치했습니다. 지난 몇 시간 동안 그래프를 보면 20분 전에 트래픽이 급격히 증가했 다는 것을 알 수 있습니다. 회사 이름과 최신 제품에 대한 검색이 크게 증가했습니다. Splunk를 통해 최근 많이 엑세스된 URL에 대한 보고서 를 조회해 본 결과, 한 연예인이 제품에 대해 트윗하고 회사 홈 페이지 를 연결했다는 것을 알게 되었습니다. 가장 많은 사람이 방문한 페이지의 성능을 보여주는 다른 그래프를 확 인합니다. 검색 페이지에 과부하가 걸려 느려지고 있습니다. 많은 사람 이 회사 사이트를 방문했지만 원하는 제품을 찾을 수 없어서 모두 검색 기능을 사용하고 있습니다. 사이트의 콘텐츠 관리 시스템에 로그인하여 홈 페이지 중앙에 신제품 에 대한 프로모션 광고를 게시합니다. 그런 다음 돌아가서 상위 페이지 를 확인합니다. 검색 트래픽 감소가 시작되고 신제품 페이지에 대한 트 래픽이 증가하고 이에 따라 장바구니에 대한 트래픽도 증가하기 시작 합니다. 장바구니에 추가된 상위 10개 제품과 구매한 상위 10개 제품 을 확인합니다. 신제품이 리스트의 가장 위에 있습니다. 홍보부에 이에 대한 후속 조치를 취하라는 메모를 보냅니다. 수신 트래픽은 이제 정확 히 회사가 원하는 대로 오류 대신 판매로 전환되고 있습니다. Splunk 덕분에 예측할 수 없던 기회를 최대한 활용할 수 있게 되었습니다. 다 음 단계는 해당 제품의 재고가 충분한지 확인하는 것입니다. 행복한 고 민입니다. 이 두 예를 보면, Splunk를 통해서 머신 데이터에 발생하는 문제를 자 세히 파악할 수 있다는 것을 알 수 있습니다. Splunk는 또한 과거 추세 를 보여주고 여러 출처의 정보를 연결하며 그 밖에 수천 가지 방법으 로 도움을 줍니다. 4

18 1장: Splunk 소개 Splunk에 대한 접근 Splunk를 사용하여 질문에 답변하다 보면 작업을 세 단계로 나눌 수 있 다는 것을 알 수 있습니다. 첫째, 질문에 답변할 수 있는 데이터를 식별합니다. 둘째, 식별한 데이터를 질문에 답변할 수 있는 결과로 변환합니다. 셋째, 답변을 보고서, 대화형 차트 또는 그래프로 표시하여 광범위 한 관련자들이 이해할 수 있도록 만듭니다. 답변하고 싶은 질문부터 시작하십시오. 시스템에 왜 장애가 발생했습 니까? 최근에 왜 이렇게 느려집니까? 사람들이 웹 사이트의 어느 부분 에서 문제를 겪고 있습니까? Splunk에 정통하게 되면 어떤 유형의 데 이터와 검색결과가 이러한 질문에 답변하는 데 도움이 되는지 보다 분 명하게 알 수 있습니다. 이 책을 통해 Splunk를 완전 정복할 수 있는 과 정을 속성으로 진행할 수 있습니다. 그럼 다음에는 다음과 같은 질문이 나오게 됩니다. 데이터가 문제의 해 답을 제공할 수 있습니까? 종종 분석을 시작할 때는 데이터를 통해 무 엇을 알 수 있는지 모릅니다. 하지만 Splunk는 데이터를 탐색하고 파악 하는 강력한 도구입니다. 가장 일반적인 값이나 가장 예외적인 값을 찾 을 수 있습니다. 통계를 활용하여 데이터를 요약하고, 예를 들어 레코 드 시스템에 걸쳐 온라인 호텔 예약을 하는 모든 이벤트를 트랜잭션으 로 그룹화할 수 있습니다. 전체 데이터 세트로 시작하는 워크플로를 생 성한 후 관련이 없는 이벤트를 필터링하여 제외하고 나머지 이벤트를 분석합니다. 그런 다음 몇 가지 단계를 거쳐 질문에 답변하는 데 필요 한 데이터만 남을 때까지 외부 소스로부터 일부 정보를 추가하기도 합 니다. 그림 1은 기본적인 Splunk 분석 프로세스를 보여줍니다. 5

19 Exploring Splunk III sourcetype syslog syslog other-source syslog syslog syslog other-source syslog other-source <events > ERROR ERROR WARNING WARNING ERROR <fields...> 그림 1-1. Splunk 사용 6

20 1장: Splunk 소개 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 전 문가가 문제 해결을 위해 자체적으로 사용하던 힘든 방식에 웹 검색의 편리함을 결합하는 것이었습니다. 7

21 Exploring Splunk Erik과 Rob은 자금을 모아 2005년 LinuxWorld 에서 Splunk의 첫 번째 버전을 선보였습니다. 제품은 크게 인기를 끌었으며 무료로 다운로드 할 수 있어서 즉시 널리 퍼졌습니다. 일단 다운로드되면 Splunk는 상상 할 수 없는 광범위한 고객의 문제를 해결하면서 부서 간 또는 회사 사 이에 퍼져나가기 시작했습니다. 사용자들은 경영진에게 Splunk 구입을 요청할 때, 이미 Splunk를 사용하여 단시간에 문제를 해결했던 경험을 가지고 있었습니다. 초기에는 IT와 데이터센터 관리자가 기술적인 문제를 해결하는 데 도움 이 되는 것으로 인식되었던 Splunk는 이제 모든 종류의 비즈니스 사용 자가 전통적인 데이터베이스보다 훨씬 더 포괄적이고 훨씬 덜 노동 집 약적인 방법으로 데이터를 검색, 수집 및 정리할 수 있기 때문에 이들에 게도 아주 유용한 플랫폼으로 성장했습니다. 그 결과 조직에서 전에 없 이 새로운 비즈니스 통찰력 및 운영 인텔리전스를 보유하게 되었습니다. Splunk가 데이터센터의 머신 데이터를 관리하는 방식 Splunk가 장악한 첫 번째 장소는 당연히 머신 데이터로 넘쳐나는 데이 터센터였습니다. Splunk는 시스템 관리자, 네트워크 엔지니어, 애플리 케이션 관리자 사이에서 머신 데이터를 신속하게 파악하고 머신 데이 터의 유용성을 높일 수 있는 엔진으로 유명세를 떨쳤습니다. 하지만 이 들이 Splunk를 그렇게 좋아한 이유는 무엇일까요? 한 가지 예를 살펴 보면 Splunk가 초기에 인기를 끌었던 이유를 알 수 있을 뿐만 아니라 Splunk가 비즈니스 세계에 제공하는 더 큰 가치의 중심이 되는 머신 데 이터의 본질을 이해하는 데도 도움이 됩니다. 대부분의 컴퓨팅 환경에서 많은 시스템들이 서로 종속되어 있습니다. 무언가 잘못되면 모니터링 시스템에서 경고를 보냅니다. 예를 들어, 한 사이트의 주요 웹 페이지는 웹 서버, 애플리케이션 서버, 데이터베이스 서버, 파일 시스템, 부하 분산기, 라우터, 애플리케이션 가속기, 캐시 시 스템 등에 종속되어 있습니다. 이들 시스템 중에 하나, 이를테면 데이 터베이스에서 무언가 잘못되면 모든 수준에서 거의 동시에 경고가 울 리기 시작합니다. 이러한 일이 발생하면 시스템 관리자나 애플리케이 션 전문가가 근본 원인을 찾아 해결해야 합니다. 문제는 로그 파일이 여러 시스템, 때로는 서로 다른 시간대에 분산되어 있고 대부분 문제와 아무 관련이 없는 수백만 개의 항목이 포함되어 있다는 것입니다. 또 한, 시스템의 일부 오류를 나타내는 관련 레코드는 모두 한 번에 나타 나는 경향이 있습니다. 따라서 이러한 오류를 유발하는 문제를 찾아내 는 것이 중요합니다. Splunk가 이러한 문제를 찾아내는 데 어떻게 도움 이 되는지 살펴보겠습니다. Splunk의 가치는 다양한 위치에서 모든 데이터를 수집하여 중앙 집중식 저장소로 모으는 인덱스에서부터 시작됩니다. Splunk가 나 오기 전에는 시스템 관리자가 수많은 여러 시스템에 로그인하여 8

22 1장: Splunk 소개 훨씬 더 성능이 떨어지는 도구를 사용하여 모든 데이터에 대한 액 세스 권한을 확보해야 했습니다. 인덱스를 사용하여 Splunk는 모든 서버의 로그를 신속하게 검색 하고 언제 문제가 발생했는지 찾아낼 수 있습니다. Splunk는 속도, 규모, 유용성을 활용하여 문제가 언제 발생했는지 훨씬 더 빠르게 확인할 수 있습니다. Splunk는 문제가 처음 발생한 기간을 세밀하게 조사하여 근본 원 인을 파악할 수 있습니다. 그런 다음, 경고를 생성하여 미래의 문 제에 대비할 수 있습니다. Splunk는 여러 소스의 로그 파일을 인덱스하고 집계하여 한 곳에서 검 색 가능하도록 만들어졌기 때문에 시스템 관리자와 전세계에서 비즈 니스를 위해 기술 작업을 수행하는 사람들 사이에 유명해졌습니다. 보 안 분석가는 Splunk를 사용하여 보안 취약성과 공격을 탐지합니다. 시 스템 분석가는 Splunk를 사용하여 복잡한 애플리케이션에서 비효율성 과 병목 현상을 찾아냅니다. 네트워크 분석가는 Splunk를 사용하여 네 트워크 중단과 대역폭 병목 현상의 원인을 찾을 수 있습니다. 이제 Splunk의 몇 가지 핵심 포인트에 대해 설명하겠습니다. 중앙 저장소를 만드는 것이 중요합니다. Splunk의 주요 장점 중 하나는 여러 소스의 다양한 유형의 데이터를 검색 가능하도록 한 곳에 모으는 방식입니다. Splunk는 데이터를 문제에 대한 해답으로 바꿔 줍니다. Splunk는 데이터에 묻힌 통찰력을 찾아내는 데 도움이 됩니다. Splunk는 데이터의 구조와 의미를 이해하는 데 도움이 됩니다. 데이 터를 제대로 이해하면 데이터 안에서 더 많은 것을 볼 수 있습니다. Splunk는 또한 확인된 내용을 파악하여 향후 조사를 보다 용이하게 하고 확인된 내용을 다른 사람과 공유하는 데도 도움이 됩니다. 시각화를 통해 반복 탐색의 어려움을 줄입니다. 인덱스와 검색 작 업을 통해서 문제에 대한 명확한 답을 보여주는 차트나 보고서를 만들 수 있습니다. 데이터를 여러 가지 방법으로 시각화할 수 있기 때문에 더 신속하게 이해할 수 있으며 이해한 내용을 다른 사람과 공유하는 데도 도움이 됩니다. 운영 인텔리전스 우리가 실행하는 거의 모든 것이 어떤 식으로든 기술의 지원을 받기 때 문에 우리들 각자에 대해 수집되는 정보는 폭증하고 있습니다. 서버에 의해 기록되는 많은 이벤트는 실제로 고객 또는 파트너의 행동을 나타 냅니다. Splunk의 고객들은 일찍이 웹 서버 액세스 로그를 사용하여 시 스템을 진단할 뿐만 아니라 웹 사이트를 탐색하는 사람들의 행동을 보 다 잘 파악할 수 있다는 것을 알았습니다. 9

23 Exploring Splunk Splunk는 머신 데이터를 사용하여 비즈니스에 대한 가시성을 확보하 고 IT 및 기업 전체에 대한 통찰력을 발견하는 새로운 범주의 방법과 기술인 운영 인텔리전스에 대한 인지도를 제고하기 위해 노력해 왔습 니다. 운영 인텔리전스는 비즈니스 인텔리전스(BI)의 부산물이 아니라 일반적으로 BI 솔루션의 범주 내에 포함되지 않는 정보 소스에 기반을 둔 새로운 접근 방식입니다. 운영 데이터는 IT 작업을 개선하는 것 뿐 만 아니라 비즈니스의 기타 부분에 대한 통찰력을 높이는 데도 유용하 게 사용됩니다. 조직에서는 운영 데이터를 사용하여 다음 작업을 수행할 수 있습니다. 머신 데이터를 사용하여 고객을 보다 심층적으로 이해: 예를 들어, 웹 사이트의 트랜잭션을 추적하면 사람들이 무엇을 구입하는지 알 수 있습니다. 하지만 웹 서버 로그를 자세히 살펴보면 사람들이 구 입하기 전에 방문한 모든 페이지를 볼 수 있으며, 아마도 훨씬 더 중요하게도, 구입하지 않은 사람들이 방문한 페이지마저도 볼 수 있습니다. (앞 부분의 신제품 검색에 대한 예가 생각나십니까?) 여러 소스의 관련 이벤트에서 파생된 주요 패턴 및 분석 결과를 공개: 웹 사이트, 자세한 통화 기록, 소셜 미디어 및 매장 내 소매 트랜잭션에서 소비자 행동의 지표를 추적해 보면 고객에 대해 훨 씬 더 포괄적인 그림을 그릴 수 있습니다. 머신 데이터에 고객 상 호작용이 많이 나타나면 나타날수록 더 많은 정보를 얻을 수 있습 니다. 중요한 이벤트 및 이벤트 탐지 사이의 시간 단축: 머신 데이터를 실시간으로 모니터링하고 상호 연결할 수 있습니다. 라이브 피드와 과거 데이터를 활용하여 지금 무슨 일이 일어나고 있는지 파악하고 추세 및 변칙 상황을 확인하고 해당 정보를 기반 으로 보다 정보에 입각한 결정을 내림: 예를 들어, 웹 프로모션에 의해 생성된 트래픽을 실시간으로 측정하고 이전 프로모션과 비교 할 수 있습니다. 솔루션을 신속히 구축하고 현재 및 미래에 조직이 필요로 하는 유 연성, 즉 임시 보고서를 제공하고 질문에 답변하고 새 데이터 소스 를 추가할 수 있는 기능 제공: Splunk 데이터는 전통적인 대시보 드에 표시되어, 사용자는 이를 이용해 이벤트를 탐색하고 새로운 질문을 계속해서 던질 수 있습니다. 10

24 1장: Splunk 소개 운영 인텔리전스의 활용 Splunk는 다른 어떤 제품도 제공하지 못하는 작업을 수행합니다. 즉, 대 량의 비정형 시계열 텍스트 형식의 머신 데이터를 효율적으로 수집하 고 분석합니다. IT 부서는 보통 기술적으로 난해한 문제를 해결하기 위 해 Splunk 사용을 시작하지만, 자신들의 업무 내에서도 귀중한 통찰력 을 신속하게 얻습니다. Splunk의 머신 데이터를 사용하면 복잡한 비즈니스 문제를 해결하는 데 도움이 됩니다. 다음은 몇 가지 예입니다. 한 운영 팀에서 고객이 접하게 되는 클라우드 기반의 애플리케이 션을 구현하고 진단하기 위해 Splunk를 사용했습니다. 이들은 곧 사용자 통계를 추적하고 비즈니스 측면에서 중요한 의미를 갖는 측정 기준인 용량을 보다 효율적으로 계획할 수 있다는 것을 알았 습니다. 웹 서버 트래픽 로그는 장바구니를 채우거나 장바구니에 저장된 품목을 취소하는 상태를 실시간으로 추적하는데 사용할 수 있습니 다. 마케팅 부서에서는 이 정보를 사용하여 소비자들이 어느 부분 에서 주춤하고, 어떤 유형의 구매를 단념하는지 파악하여 어떤 문 제든지 즉시 해결하고 단념한 품목을 대상으로 프로모션을 진행 할 수 있습니다. 문제 해결을 위해 Splunk를 사용하여 애플리케이션을 모니터링하 는 조직에서는 고객의 전화를 고비용의 엔지니어링 리소스에 전달 하는 대신 일선 지원 팀에서 직접 처리할 수 있도록 쉽게 뷰를 제 공할 수 있다는 사실을 알았습니다. 한 주요 공기업에 여섯 가지의 모니터링과 진단 도구를 Splunk로 교체하여 소프트웨어 유지관리 비용을 절감하는 한편, NERC 및 SOX 컴플라이언스 작업을 강화할 수 있었습니다. 한 주요 공공 미디어 기관에서 중요한 웹 분석 결과를 파악하는 데 걸리는 시간을 몇 개월에서 몇 시간으로 단축했습니다. 또한 디 지털 자산을 보다 세밀하고 정확하게 추적하여 Splunk 없이는 불 가능했던 로열티 정산 및 콘텐츠 마케팅을 효율적으로 처리할 수 있었습니다. 한 타코 전문 레스토랑에서 POS(판매시점관리) 시스템을 Splunk 에 연결해, 비즈니스 분석가가 "이맘때 이 지역에서 자정부터 새벽 2시 사이에 타코를 사는 사람들이 몇 명이나 됩니까?" 등과 같은 질문까지도 1시간 내에 답변할 수 있게 되었습니다. 11

25 Exploring Splunk 결과적으로 조직들은 운영 인텔리전스를 활용하여 정확한 질문을 할 수 있고, 이 질문은 실시간 데이터와 과거 데이터를 조합하여 쉽게 요 약할 수 있는 대시보드와 그래픽 도구에 표시되는 비즈니스 통찰력을 제공하는 답변을 유도합니다. 머신 데이터를 "빅 데이터"라고 부르는 데는 이유가 있습니다. 방대한 머신 데이터 어디엔가는 회사의 미래를 좌우할 수 있는 중요한 데이터 가 묻혀 있습니다. 이제 2장으로 이동하겠습니다. 2장에서는 데이터를 Splunk로 가져와 데이터에 숨겨져 있는 보물을 찾아내는 방법에 대해 설명합니다. 12

26 2 데이터 가져오기 1장에서는 Splunk를 소개하고 Splunk가 어떻게 도움이 되는 지에 대 해 설명했습니다. 이제 다음 단계, 데이터를 Splunk로 가져오는 단계를 시작하겠습니다. 이 장에서는 Splunk 설치 및 데이터 가져오기에 대해 설명하고 원활 한 검색을 위해 데이터를 정리하는 방법에 대해서도 간략하게 설명합 니다. 머신 데이터 기본사항 Splunk의 미션은 머신 데이터를 사람들에게 유용하도록 만드는 것입 니다. 먼저 머신 데이터에 대한 기본사항과 Splunk에서 머신 데이터를 추적하는 방법에 대해 살펴보겠습니다. 시스템(웹 서버, 부하 분산기, 비디오 게임 또는 소셜 미디어 플랫폼 등) 을 구축하는 사람들은 시스템이 실행될 때 로그 파일에 작성하는 정보 도 지정합니다. 이 정보(로그 파일에 포함되어 있는 머신 데이터)를 이 용하면 시스템이 실행될 때(또는 실행되지 못할 때) 시스템에서 무슨 일이 일어나고 있는지 파악할 수 있습니다. 예를 들어, 다음은 가상 시 계 애플리케이션의 로그 파일 출력 내용입니다. Action: ticked s:57, m:05, h:10, d:23, mo:03, y:2011 Action: ticked s:58, m:05, h:10, d:23, mo:03, y:2011 Action: ticked s:59, m:05, h:10, d:23, mo:03, y:2011 Action: ticked s:00, m:06, h:10, d:23, mo:03, y:2011 시계가 똑딱거릴 때마다 작업과 작업이 이루어진 시간을 기록합니다. 시계를 자세히 추적하기 위해 똑딱거림 외에 배터리 잔여 시간, 알람 설정 시간, 알람 사용 여부, 소리 사용 여부 등 시계 작동 상태를 파악 하는 데 도움이 되는 기타 유용한 정보를 로그에 포함할 수도 있습니 다. 위에 표시된 머신 데이터의 각 줄은 별도의 이벤트로 간주될 수 있 는데, 다른 머신 데이터의 경우에는 하나의 이벤트가 여러 줄 또는 심 지어 수백줄에 걸쳐 표시되는 것이 일반적입니다. Splunk에서는 원시 머신 데이터를 이벤트라고 하는 별개의 정보 단위 로 나눕니다. 단순 검색 시 Splunk는 검색어와 일치하는 이벤트를 검 색합니다. 각 이벤트는 필드라고 하는 별개의 데이터 단위로 구성됩니 13

27 Exploring Splunk 다. 시계 데이터의 경우 second, minute, hour, day, month, 및 year 필드 로 구성됩니다. 이벤트 그룹이 스프레드시트 또는 데이터베이스로 구 성되어 있다고 생각하면, 그림 2-1에 표시된 것처럼 이벤트는 행이고 필드는 컬럼이 됩니다. 그림 2-1. 스프레드시트 형식의 시계 이벤트 이벤트를 키워드/값 쌍의 필드의 집합으로 생각할 수도 있습니다. 키 워드/값 쌍으로 나타낼 경우 시계 이벤트는 그림 2-2와 같은 모양이 됩 니다. Second=58, Minute=01, Hour=14, Day=23, Year=2011 Second=59, Minute=01, Hour=14, Day=23, Year=2011 Second=60, Minute=01, Hour=14, Day=23, Year=2011 Second=01, Minute=02, Hour=14, Day=23, Year=2011 Second=02, Minute=02, Hour=14, Day=23, Year=2011 그림 2-2. 키워드/값 쌍의 필드로 나타낸 시계 이벤트 다음은 가장 일반적이고 유용한 유형의 실제 머신 데이터의 예입니다. 서버에서 요청된 모든 URL을 기록하는 로그 파일이 한 웹 서버에 있 습니다. 웹 서버 데이터의 일부 필드는 다음과 같습니다. client IP, timestamp, http method, status, bytes, referrer, user agent 웹페이지를 한 번 방문하면 텍스트, 이미지 및 기타 리소스를 검색하기 위해 수십 개의 요청이 호출됩니다. 각 요청은 일반적으로 로그 파일에 별도의 이벤트로 기록됩니다. 그 결과는 그림 2-3과 같은 모양의 파일 입니다(하이라이트는 필드를 보는 데 도움이 되도록 넣은 것으로 실제 파일에는 표시되지 않습니다.) [01/Aug/2011:12:29: ] "GET /pages/hltabs_c.html HTTP/1.1" " "Mozilla/5.0 AppleWebKit/102.1 (KHTML) Safari/102" [01/Aug/2011:12:29: ] "GET /pages/joy.html HTTP/1.1" " "Mozilla/5.0 AppleWebKit/102.1 (KHTML) Safari/102" [01/Aug/2011:12:29: ] "GET /pages/dochomepage.html HTTP/1.1" " "Mozilla/5.0 AppleWebKit/102.1 (KHTML) Safari/102" 그림 2-3. 일반적인 웹 서버 로그 14

28 2장: 데이터 가져오기 Splunk에서 읽을 수 있는 데이터의 유형 머신 데이터의 가장 일반적인 특징 중 하나는 항상 데이터가 만들어진 시기 또는 데이터에 의해 설명되는 이벤트가 발생한 시기를 나타내는 정보가 포함되어 있다는 점입니다. 이러한 특징을 고려하여 Splunk의 인덱스는 이벤트를 시계열 순서로 검색할 수 있도록 최적화되어 있습 니다. 원시 데이터에 명시적인 타임스탬프가 없는 경우 Splunk는 데이 터의 이벤트에 대해, 이벤트가 Splunk에 의해 인덱스된 시간을 지정하 거나 파일이 마지막으로 수정된 시간 또는 이전 이벤트의 타임스탬프 등 다른 근사값을 사용합니다. 그 밖에 유일한 요건은 머신 데이터는 이진 데이터가 아니라 텍스트 데 이터여야 한다는 점입니다. 예를 들어, 이미지 및 사운드 파일이 일반 적인 이진 데이터 파일입니다. 프로그램 중단 시 생성되는 코어 덤프와 같은 일부 유형의 이진 파일은 스택 추적과 같은 텍스트 정보로 변환할 수 있습니다. Splunk는 데이터를 인덱스하기 전에 스크립트를 호출하 여 변환 작업을 실행합니다. 궁극적으로 Splunk 데이터는 인덱스하거 나 검색할 수 있도록 텍스트 형태로 표시되어야 합니다. Splunk 데이터 소스 인덱싱하는 동안 Splunk는 여러 소스의 머신 데이터를 읽을 수 있습니 다. 가장 일반적인 입력 소스는 다음과 같습니다. 파일: Splunk에서는 특정 파일 또는 디렉터리를 모니터링할 수 있 습니다. 데이터가 파일에 추가되거나 새 파일이 모니터링되는 디 렉터리에 추가되는 경우 Splunk는 해당 데이터를 읽습니다. 네트워크: Splunk는 TCP 또는 UDP 포트를 수신하고 전송되는 모 든 데이터를 읽을 수 있습니다. 스크립트 기반 입력 정보: Splunk에서는 센서를 모니터링하는 Unix 명령어 또는 사용자 지정 스크립트와 같이 프로그램 또는 스크립트의 머신 데이터 출력 정보를 읽을 수 있습니다. 이제 충분한 배경 지식을 갖추었으니 Splunk를 사용해 보겠습니다. Splunk 다운로드, 설치 및 시작 이 책에 설명된 내용을 따라해 보기 위해 Splunk를 설치하고 일부 머 신 데이터를 추가하기를 권고드립니다. 이 책에 설명된 모든 내용은 Splunk Free를 사용하여 따라해 볼 수 있습니다(아래 참조). 이 절에서는 Splunk를 설치하고 시작하는 방법에 대해 설명합니다. 15

29 Exploring Splunk Splunk 다운로드 Splunk를 배우거나 중소 규모 수준의 Splunk 사용을 지원하기 위해, 다 기능 Splunk를 무료로 다운로드할 수 있습니다. splunk.com 홈 페이지 에서 다음 버튼을 찾을 수 있습니다. 이 버튼을 클릭하여 Windows, Mac, Linux 또는 Unix를 구동 중인 컴퓨터에 Splunk를 다운로드 하십시오. Splunk 설치 Splunk 설치는 간단하기 때문에 개별적으로 설치한 것으로 간주하 겠습니다. 질문이 있는 경우 Splunk 자습서( book#tutorial)를 참고하십시오. 모든 것이 자세히 설명되어 있습니다. Splunk 시작 Windows에서 Splunk를 시작하려면 시작 메뉴에서 Splunk 애플리케 이션을 실행합니다. 그림 2-4의 '환영' 화면이 표시되는지 확인하고 계 속 읽어보십시오. Mac OS X 또는 Unix에서 Splunk를 시작하려면 터미널 창을 엽니다. Splunk를 설치한 디렉터리로 이동하고 bin 하위 디렉터리로 이동한 후 명령 프롬프트에 다음과 같이 입력합니다../splunk start Splunk가 시작되면 표시되는 정보의 맨 마지막 줄은 다음과 같습니다. The Splunk web interface is at 로그인 화면의 해당 링크를 연결합니다. 사용자 이름과 암호가 없는 경 우 기본 접속 정보는 각각 admin 및 changeme입니다. 로그인 후 환영 화면이 나타납니다. 16

30 2장: 데이터 가져오기 그림 2-4. 환영 화면 환영 화면에는 데이터 추가 및 검색 앱 실행 등 새로운 Splunk 인스턴 스를 사용해 수행할 수 있는 작업이 표시됩니다. 인덱스를 위해 데이터 가져오기 Splunk를 배우고 탐색하는 데 있어 다음 단계는 일부 데이터를 탐색 가 능하도록 인덱스에 추가하는 것입니다. 이 장에서는 일부 샘플 데이터를 사용하도록 하겠습니다. 이 데이터를 가져오는 방법은 다음 페이지에 나와 있습니다. book#add_data 인덱스 프로세스에는 다음의 두 단계가 있습니다. Splunk 웹 사이트에서 샘플 파일 다운로드 Splunk에 해당 파일을 인덱스하도록 요청 샘플 파일을 다운로드하려면 다음 링크를 연결하고 파일을 바탕 화면 에 저장하십시오. Splunk에 파일을 추가하는 방법: 1. 환영 화면에서 데이터 추가를 클릭합니다. 2. 화면 하단에서 파일 및 디렉터리에서를 클릭합니다. 3. 미리보기 건너뛰기를 선택합니다. 4. 파일 업로드 및 인덱스 옆의 라디오 버튼을 클릭합니다. 5. 바탕 화면에 다운로드한 파일을 선택합니다. 6. 저장을 클릭합니다. 17

31 Exploring Splunk 데이터 추가가 완료되었습니다. 보이지 않는 곳에서 Splunk가 무엇을 수행하는지를 설명하겠습니다. Splunk의 데이터 인덱스 방식 이해 대부분의 조직에 있어 Splunk의 핵심적인 가치는 분석, 보고 및 경고 를 위해 머신 데이터를 신속하게 검색 가능하도록 인덱스할 수 있는 고유 기능입니다. 인덱스하기 전의 데이터를 원시 데이터라고 합니다. Splunk는 데이터 자체는 수정하지 않고 데이터 내 단어에 대해 시간 기 반 지도를 만들어 원시 데이터를 인덱스합니다. Splunk에서 대량의 데이터를 검색하려면 데이터를 먼저 인덱스해야 합 니다. Splunk 인덱스는 특정 키워드가 있는 페이지를 가리키는 책의 마 지막 부분에 있는 인덱스와 유사한 개념입니다. Splunk에서는 "페이지" 를 이벤트라고 합니다 [01/Aug /2009:09:37: ] "GET /home/themes/comb h eta/images/btn_login.g if HTTP/1.1" "ht p://webdev:2000/home/i ev:20 ex.php" "Mozilla/5.0 l [01/Aug /2009:09:37: ] "GET /home/themes/comb h eta/images/btn_login.g if HTTP/1.1" "ht p://webdev:2000/home/i ev:20 ex.php" "Mozilla/5.0 l [01/Aug /2009:09:37:01 09:37: ] "GET /home/themes/comb h eta/images/btn_login.g if HTTP/1.1" "ht p://webdev:2000/home/i ev:20 ex.php" "Mozilla/5.0 l : + source, sourcetype, host _time A B C splunk A B C [01/Aug/2009:09 :37: ] "GET /home/theme s/combeta/images/btn_login.gif 그림 2-5. Splunk 인덱스의 고유한 특징 Splunk에서는 머신 데이터의 스트림을 개별 이벤트로 나눕니다. 머신 데이터의 이벤트는 로그 파일의 한 줄처럼 간단할 수도 있고 수백 줄이 포함된 스택 추적처럼 복잡할 수도 있습니다. Splunk의 모든 이벤트에는 표 2-1에 나와 있는 것처럼 4개 이상의 기 본 필드가 있습니다. 18

32 2장: 데이터 가져오기 source 표 2-1. Splunk에서 항상 인덱스하는 필드 필드 질문 예 데이터를 어디서 가져왔습니 까? 파일(/var/log/), 스크 립트(myscript.bat), 네 트워크 피드(UDP:514) sourcetype 어떤 종류의 데이터입니까? access_combined, syslog host 어느 호스트 또는 시스템에서 데이터를 가져왔습니까? webserver01, cisco_ router _time 이벤트가 언제 발생했습니까? Sat Mar 31 02:16: 이러한 기본 필드는 원시 데이터와 함께 인덱스됩니다. 타임스탬프(_time) 필드는 Splunk 인덱서에서 타임스탬프를 사용하여 이벤트를 정렬하기 때문에 특별한데, 이를 통해 Splunk는 특정 시간 범 위 내에서 이벤트를 효율적으로 검색할 수 있습니다. 3장에서는 대부분의 작업이 발생하는 Splunk의 검색 인터페이스에 대 해 설명합니다. 19

33

34 3 Splunk를 사용한 검색 앞서 2장에서 Splunk가 데이터를 인덱스하는 방식에 대해 살펴보았기 때문에 Splunk를 사용하여 검색할 때 어떤 일이 일어나는지 보다 쉽게 이해할 수 있을 것입니다. 물론, 검색의 목표는 필요한 항목을 정확하게 찾는 것입니다. 즉, 데이 터 관련 질문에 답변할 수 있도록 대량의 데이터를 필터링, 요약, 시각 화하는 것입니다. 경우에 따라 대량의 데이터를 정기적으로 탐색해야 할 수도 있습니다. 어떤 경우에는 건초더미에서 바늘을 찾는 것처럼, 시 스템 중단을 초래한 하나의 이벤트를 찾아야 할 때도 있습니다. 요약 대시보드를 보면 데이터의 개요를 신속하게 확인할 수 있습니다. Splunk 환영 탭에서 검색 앱 실행을 클릭하십시오. Splunk 홈 탭에 있 는 경우에는 내 앱 아래 검색을 클릭합니다. 그림 3-1에 표시된 것과 같 은 요약 대시보드가 표시됩니다. 21

35 Exploring Splunk 그림 3-1. 검색 앱의 요약 대시보드 이 대시보드에서 다음과 같은 몇 가지 사항을 주지하십시오. 상단의 검색란은 비어 있으며 언제든지 검색어를 입력할 수 있습 니다. 검색란 오른쪽의 시간 범위 선택기를 사용하면 시간 범위 조정이 가능합니다. 예를 들어 지난 15분 또는 원하는 시간 범위 내의 이 벤트를 볼 수 있습니다. 실시간 스트리밍 데이터의 경우 30초에서 1시간까지 원하는 간격을 선택할 수 있습니다. 인덱스된 모든 데이터 패널에는 인덱스된 데이터의 누적 합계가 표시됩니다. 22

36 3장: Splunk를 사용한 검색 다음 세 패널에는 각 범주에서 인덱스된 가장 최근의 값 또는 일반적 인 값이 표시됩니다. Sources 패널에는 데이터를 가져온 파일(또는 다른 소스)이 표시 됩니다. Source type 패널에는 데이터 내 소스의 유형이 표시됩니다. Host 패널에는 데이터를 가져온 호스트가 표시됩니다. 이제 페이지 상단 근처의 검색 탐색 메뉴를 살펴보겠습니다. 그림 3-2. 검색 탐색 메뉴 요약은 현재 위치입니다 검색은 기본 검색 인터페이스인 검색 대시보드로 연결됩니다. 상태에는 Splunk 인스턴스의 상태에 대한 대시보드가 나열됩니다. 대시보드 및 뷰에는 대시보드와 뷰가 나열됩니다. 검색 및 보고서에는 저장된 검색 내용과 보고서가 나열됩니다. 다음 절에서는 검색 대시보드를 소개합니다. 검색 대시보드 검색 옵션을 클릭하거나 검색 창에 검색어를 입력하면 페이지가 검색 대시보드(때로는 시간 표시줄 또는 플래시 시간 표시줄 뷰라고 함)로 전환됩니다. 검색이 시작되면 거의 즉시 결과가 표시되기 시작합니다. 예를 들어, 검색란에 별표(*)를 입력하면 기본 인덱스 내 모든 데이터가 검색되고 그림 3-3과 유사한 화면이 나타납니다. 23

37 Exploring Splunk 그림 3-3. 검색 대시보드 이 대시보드의 내용을 살펴보겠습니다. 시간 표시줄: 시간별로 검색어와 일치하는 이벤트 수를 그래픽으 로 나타냅니다. 필드 사이드바: 관련 필드를 이벤트 수와 함께 표시합니다. 이 메 뉴를 사용하면 결과에 필드를 추가할 수도 있습니다. 필드 검색 스위치: 자동 필드 검색 기능을 켜거나 끕니다. Splunk 에서 검색을 실행하고 필드 검색 기능이 켜져 있는 경우 Splunk에 서는 현재 검색에 대해 필드를 자동으로 검색하려고 시도합니다. 24

38 3장: Splunk를 사용한 검색 결과 영역: 검색에 따른 이벤트를 보여줍니다. 이벤트는 각 이벤트 의 왼쪽에 표시되는 타임스탬프 순으로 정렬됩니다. 각 이벤트의 원시 텍스트 아래에는 이벤트가 값을 가지고 있는 필드 사이드바 에서 선택된 모든 필드가 표시됩니다. 검색란에 검색어를 입력하기 시작하면 검색란 아래 상황별 정보가 왼 쪽에는 일치하는 검색 결과, 오른쪽에는 도움말과 함께 표시됩니다. 그림 3-4. 검색란에 텍스트를 입력하면 유용한 정보가 표시됩니다. 시간 범위 선택기 아래 한 줄의 아이콘이 표시됩니다. 그림 3-5. 검색 아이콘 검색 작업 컨트롤은 검색이 실행 중인 경우에만 작동됩니다. 검색을 실 행하지 않거나 검색이 완료된 경우에는 작동하지 않으며 회색으로 표 시됩니다. 그러나, 완료하는 데 오랜 시간이 걸리는 검색을 실행하는 경우 이들 아이콘을 사용하여 검색 진행 상태를 제어할 수 있습니다. 검색을 백그라운드로 보내면 검색이 완료될 때까지 계속 실행되 도록 하고 그 동안 다른 검색을 실행하거나, 창을 닫고 로그아웃 할 수도 있습니다. 백그라운드로 보내기를 클릭하면 검색란이 지 워지고 다른 작업을 계속할 수 있습니다. 작업이 완료되면 아직 로 그인 중인 경우 화면에 알림이 표시되고, 그렇지 않는 경우 Splunk 에서 이메일을 보냅니다(이메일 주소를 지정한 경우). 그 동안 또 25

39 Exploring Splunk 는 나중에 작업을 확인하려면 페이지 상단의 작업 링크를 클릭하 십시오. 검색을 일시 중지하면 검색이 일시적으로 중단되며 해당 시점까지 의 결과를 탐색할 수 있습니다. 검색이 일시 중지된 동안에는 아이 콘이 재생 버튼으로 바뀝니다. 이 버튼을 클릭하면 검색을 일시 중 지했던 시점부터 검색이 재시작됩니다. 검색이 완료되기 전에 검색을 종료하면 검색이 중단되지만 해당 시점까지의 결과는 그대로 남아 있어 검색 뷰에서 결과를 보고 탐 색할 수 있습니다. 이와 대조적으로 검색을 취소하면 검색 실행이 중단되고 결과가 없어지고 화면에서 삭제됩니다. 작업 검사기 아이콘을 클릭하면 작업 검사기 페이지로 이동합니다. 이 페이지에는 검색 실행 비용, 디버그 메시지, 검색 작업 속성 등 검색에 대한 세부정보가 표시됩니다. 저장 메뉴를 사용하면 검색을 저장하거나 검색 결과를 저장하거나, 결 과를 저장하여 공유할 수 있습니다. 검색을 저장한 경우에는 검색 및 보고서 메뉴에서 찾을 수 있습니다. 결과를 저장하는 경우 화면의 오른 쪽 상단에 있는 작업을 클릭하여 검토할 수 있습니다. 만들기 메뉴를 사용하면 대시보드, 경고, 보고서, event types 및 예약 된 검색을 만들 수 있습니다. 이에 대해서는 5장에서 자세히 설명하겠 습니다. 결과 영역 왼쪽 상단쪽 아래로 이동하면 다음과 같은 아이콘이 표시됩 니다. 그림 3-6. 결과 영역 아이콘 기본적으로 Splunk에서는 이벤트를 가장 최근의 이벤트부터 가장 오 래된 이벤트까지 리스트 형태로 표시하지만 테이블 아이콘을 클릭하여 결과를 테이블로 표시하거나 차트 아이콘을 클릭하여 결과를 차트로 표시할 수 있습니다. 내보내기 버튼을 사용하면 검색 결과를 CSV, 원시 이벤트, XML, JSON 등 다양한 형식으로 내보낼 수 있습니다. 26

40 3장: Splunk를 사용한 검색 이벤트? 결과? 어떤 차이가 있습니까? 기술적인 관점에서 인덱스에서 검색된 이벤트를 '이벤트'라고 합니다. 이러한 이벤트가 변환되거나 요약되어 디스크의 이벤트와 더 이상 1대1로 일치하지 않는 경우에는 '결과'라고 합니다. 예를 들어, 검색을 통해 검색된 웹 액세스 이벤트는 이벤트이지만 오늘 방문한 상위 URL은 결과입니다. 따라서, 까다롭게 구별하는 대신 두 용어를 서로 번갈아 사용하겠습니다. SPL : 검색 처리 언어 Splunk를 사용하면 대량의 인덱스된 이벤트를 실제 문제에 대응하는데 유용한 형태로 분류할 수 있습니다. 그림 3-7은 이벤트 검색, 보고서 생성 등 일반적인 검색 패턴을 보여줍 니다. 이 검색은 syslog 오류가 있는 상위 사용자들을 반환합니다. sourcetype = syslog ERROR top user fields - percent sourcetype syslog syslog other-source syslog syslog syslog other-source syslog other-source <events > ERROR ERROR WARNING WARNING ERROR Events fetched from disk user_a user_a user_a user_a user_b <fields...> user_01 user_02... user Summarize into table of top ten users user_01 user_02... user Remove percent column user_01 user_02... user Final results top user fields - percent 파이프 그림 3-7. 단순 Splunk 검색이 처리되는 방식 전체 문자열 sourcetype=syslog ERROR top user fields - percent 을 검색이라고 하며 파이프 문자( )는 검색을 구성하는 개별 명령어를 구분합니다. 파이프 뒤의 첫 번째 키워드는 검색 명령어의 이름입니다. 이 경우 명 령어는 top 및 fields입니다. 어느 명령어가 인덱스에서 이벤트를 검색 합니까? 파이프 문자로 시작하지 않는 모든 검색의 처음에는 search 27

41 Exploring Splunk 라고 하는 명령어가 내포되어 있습니다. 따라서, 위 검색에는 search, top, fields 등 세 개의 검색 명령어가 있습니다. 각 명령의 결과는 다음 명령에 입력값으로 전달됩니다. bash와 같은 Linux 쉘을 사용해 본 사용자는 이런한 개념이 익숙할 것입니다. 내포된 AND sourcetype=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 값을 가져오고, 이벤트가 어떻게 나눠지는지 확인하고, 다른 필드를 기준으로 새 필드 몇 개를 파생하고, 결과를 분류하고, 한 필드가 다른 필드에 따라 어떻게 달라지는지 확인해 볼 수 있습니다. ( 사전 지식이 없는 소스의 내용을 알아보는 방법은 book#mining_tips를 참조하십시오.) 4장에서 검색 명령어에 대해 자세히 알아보기 전에 Splunk를 사용하 는 데 있어 매우 특별한 명령어인 search 명령어 자체에 대해 살펴보 겠습니다. 28

42 3장: Splunk를 사용한 검색 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보다 큰 모 든 이벤트를 검색합니다. 29

43 Exploring Splunk 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] 30

44 3장: Splunk를 사용한 검색 login 및 error라는 단어가 포함된 이벤트 검색이 맨처음 찾은 user 값 (예를 들어 bob)을 반환하면서 수행되고 sourcetype=syslog user=bob 에 대한 검색이 이어집니다. Splunk에 대해 더 알아보려면 4장을 통해 즉시 도움이 되는 다른 명령 어들을 살펴볼 수 있습니다. 31

45

46 4 SPL: 검색 처리 언어 3장에서는 SPL에서 가장 기본적인 Splunk 명령어, search에 대해 알아 봤습니다. 이 장에서는 그 밖에 다른 SPL 명령어에 대해 설명합니다. 이 장에서는 SPL 명령어에 대해 기본적인 예를 들어 설명합니다. 전체 참조 설명서는 참조하십시오. 표 4-1에는 이 장에 설명된 SPL 명령어가 범주별로 요약되어 있습니다. 표 4-1. 공통 SPL 명령어 범주 설명 명령어 결과 정렬 결과를 정렬하고 (선택 사항) 결과의 sort 수를 제한합니다. 결과 필터링 이벤트 또는 결과의 집합을 더 작은 결과의 집합으로 필터링합니다. search where dedup head tail 결과 그룹화 패턴을 볼 수 있도록 이벤트를 그룹 화합니다. transaction 결과 보고 필드 필터링, 수정 및 추가 결과 정렬 sort 검색 결과를 가지고 보고를 위한 요 약을 생성합니다. 필요한 필드에 초점을 맞추기 위해 일부 필드를 필터링하여 제외(제거) 하거나 결과나 이벤트를 강화하기 위해 필드를 수정 또는 추가합니다. 결과 정렬은 예측한 대로 sort 명령어의 영역입니다. top/rare stats chart timechart fields replace eval rex lookup sort 명령어는 검색 결과를 지정된 필드를 기준으로 정렬합니다. 표 4-2에 몇 가지 예가 나와 있습니다. 33

47 Exploring Splunk 검색의 일부를 간략하게 표시 표 4-2에서처럼 여러 명령어의 일부만 보여주는 경우 다음과 같이 표시합니다.... 즉, 이 명령어 앞에 다른 검색이 있지만 뒤에 나오는 부분에 대해 초점을 맞춘다는 의미입니다. 표 4-2. sort 명령어의 예 명령 sort 0 field1 sort field1,-field2 sort 100 field1,+field2 sort filename sort num(filename) sort str(filename) 결과 결과를 by field1 기준으로 오름차순 으로 정렬하고 모든 결과를 반환합니 다(0은 기본값인 10,000개에서 중지하 지 않고 모든 이벤트를 반환한다는 것 을 의미합니다). 결과를 field1 기준으로 오름차순으로 정렬한 후 field2 기준으로 내림차순으 로 정렬하고 최대 10,000개의 결과(기 본값)를 반환합니다. 결과를 field1 기준으로 내림차순으로 정렬한 후 field2 기준으로 오름차순으 로 정렬하고 정렬된 처음 100개의 결 과를 반환합니다. 결과를 filename 기준으로 정렬합니다. 첫 번째 명령어로 Splunk는 필드 값을 정렬하는 방법을 결정합니다. 두 번째 명령은 Splunk에 값을 숫자순으로 정렬하도록 요청합니다. 세 번째 명령은 Splunk에 값을 사전순으로 정렬하도록 요청합니다. 힌트: 검색 결과의 기본 정렬 순서는 오름차순입니다. 결과의 순서를 뒤집으려면 결과를 정렬하기 위해 사용되는 필드 앞에 빼기 기호를 사용하십시오. 그림 4-1에 두 번째 예가 나와 있습니다. 가격을 기준으로 오름차순, 평 가를 기준으로 내림차순으로 정렬하겠습니다. 첫 번째 결과는 사용자 평가가 가장 높고 가장 저렴한 품목입니다. 34

48 4장: SPL: 검색 처리 언어 결과 필터링 where...,- 그림 4-1. sort 명령어 이 명령어들은 이전 명령의 검색 결과를 더 작은 결과의 집합으로 줄입 니다. 다시 말해, 데이터의 뷰를 좁혀 원하는 결과만 표시합니다. where 필터링 명령은 표현식을 평가하여 결과를 필터링합니다 평가가 성공적으로 완료되어 결과가 TRUE인 경우 결과가 유지되며, 그렇지 않 은 경우 결과가 제외됩니다. 예: source=job_listings where salary > industry_average 이 예에서는 채용 정보를 검색하여 급여가 업계 평균 급여보다 많지 않 은 결과를 제외합니다. 또한 salary 필드 또는 industry_average 필드 가 누락된 이벤트를 제외합니다. 이 예에서는 두 개의 필드, salary와 industry_average를 비교합니다. 이 작업은 where 명령어를 사용해 가능합니다. 필드 값을 문자 값과 비 교하는 경우 search 명령어를 사용하십시오. source=job_listings salary>

49 Exploring Splunk 표 4-3. where 명령어의 예 명령 where distance/time > 100 where like(src, % ) OR cidrmatch( /25, dst) 결과 distance 필드 값을 time 필드 값으로 나눈 값이 100보다 큰 결 과를 유지합니다. IP 주소와 일치하거나 지정된 서 브넷에 포함되는 결과를 유지합 니다. 다 그림 4-2에는 distance/time > 100인 명령이 예시되어 있습니 distance/time>100. FALSE. FALSE. FALSE. FALSE..TRUE..TRUE..TRUE evaluate (distance/time>100) and keep only events for which the result is TRUE where 사용에 대한 도움말 dedup... where distance/time > 100 그림 4-2. where 명령어의 예 eval 명령어와 마찬가지로 where 명령어는 수많은 수식 평가 함수와 함 께 사용할 수 있습니다(전체 리스트는 부록 E를 참조하십시오). 중복된 데이터를 제거하는 일은 dedup 필터링 명령어의 역할입니다. 이 명령어는 지정된 기준과 일치하는 후속 결과를 제거합니다. 즉, 지정된 필드 값의 각각의 조합에 대해 지정된 count 만큼의 결과만 유지합니 다. count가 지정되지 않은 경우에는 1로 설정되어 처음 발견된(일반 적으로 가장 최근의) 결과를 반환합니다. 36

50 4장: SPL: 검색 처리 언어 명령 dedup host 표 4-4. dedup 명령어의 예 결과 각각의 고유한 host에 대해 첫 번째 결과를 유지합니다. dedup 3 source 각각의 고유한 host에 대해 처음 3 개의 결과를 유지합니다. dedup source sortby -delay dedup 3 source,host dedup source keepempty=true 결과를 delay 필드를 기준으로 내림 차순으로 먼저 정렬한 후 각각의 고 유한 source에 대해 첫 번째 결과 를 반환합니다. 이 명령은 각각의 고 유한 source에 대해 지연 값이 가장 큰 결과를 효과적으로 유지합니다. source 및 host 값의 각각의 고유한 조합에 대해 처음 3개의 결과를 유 지합니다. 각각의 고유한 source에 대해 첫 번 째 결과를 유지하고 source 필드가 없는 결과도 유지합니다. 그림 4-3에 dedup 3 source 명령어가 예시되어 있습니다. source source_a source_a source_b source_b source_a source_a source_a source_b source_b field2 f2_value1 f2_v alue2 f2_v alue3 f2_v alue4 f2_v alue5 f2_v alue6 f2_v alue7 f2_v alue8 f2_v alue9 <fields >. source source_a source_a source_b source_b source_a source_a source_a source_b source_b field2 f2_value1 f2_v alue2 f2_v alue3 f2_v alue4 f2_v alue5 f2_v alue6 f2_v alue7 f2_v alue8 f2_v alue9 <fields >. source source_a source_a source_b source_b source_a source_b field2 f2_value1 f2_v alue2 f2_v alue3 f2_v alue4 f2_v alue5 f2_v alue8 <fields >. for events with matching source field values, remove all except the first three... dedup 3 source 요점 그림 4-3. dedup 명령어의 예 모든 결과를 유지하지만 중복된 값을 제거하려면 keepevents 옵션 을 사용하십시오. 지정된 필드 값의 조합에 대해 첫 번째 발견된 결과, 일반적으로 가장 최근의 결과가 반환됩니다. 필요한 경우 정렬 순서를 변경하 려면 sortby 절을 사용하십시오. 37

51 Exploring Splunk head 지정된 필드가 전혀 존재하지 않는 필드는 기본적으로 유지됩니 다. 원할 경우 기본 동작을 재지정하려면 keepnull=<true/false> 옵션을 사용하십시오. 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에 나와 있습니다. field <fields >. field <fields >. retrieve only the first five (5)... head 5 그림 4-4. head 명령어의 예 38

52 4장: SPL: 검색 처리 언어 결과 그룹화 transaction 명령어는 연관된 이벤트들을 묶어줍니다. transaction transaction 명령어는 다양한 제약조건을 충족하는 이벤트를 트랜젝 션, 즉 여러 소스의 이벤트 집합으로 그룹화합니다. 이벤트는 모든 트 랜잭션 정의 제약조건이 충족되는 경우 하나로 그룹화됩니다. 트랜잭 션은 각 구성 이벤트의 원시 텍스트(_raw 필드), 최초 구성 이벤트의 타 임스탬프(_time 필드), 각 구성 이벤트의 기타 모든 필드의 조합, duration 및 eventcount와 같이 트랜잭션을 기술하는 몇몇 추가 필드로 구 성됩니다. 표 4-6. transaction 명령어의 예 명령 transaction clientip maxpause=5s transaction clientip host maxspan=30s maxpause=5s 결과 동일한 클라이언트 IP 주소를 공유하고 5 초를 초과하는 간격이나 일시중지가 없는 이벤트를 그룹화합니다. 이 명령어를 사용하면 host 필드에 대한 검색 결과에 여러 값이 존재할 수도 있습 니다. 예를 들어, 여러 사람이 동일한 위치 에서 서버에 액세스하는 경우 단일 IP 주소 로부터의 요청들이 여러 호스트에서 나올 수 있습니다. 첫 번째와 마지막 이벤트 사이의 시간차 가 30초를 넘지 않고, 이벤트들 사이의 간 격이 5초를 넘지 않으며, 클라이언트 IP 주 소와 호스트가 같은 이벤트들을 그룹화합 니다. 첫 번째 예제와는 다르게, 시간 제약조건을 충족하면서 서로 다른 clientip과 host를 조합하는 결과를 얻게 됩니다. 따라서 하나 의 트랜잭션 내에서는 host 또는 clientip 주소 값이 다른 이벤트는 없습니다. 39

53 Exploring Splunk sourcetype=access* action=purchase transaction clientip maxspan=10m maxevents=3 transaction JSES- SIONID clientip startswith= signon endswith= purchase where duration>=1 action=purchase 값을 갖는 웹 액세스 이 벤트를 검색합니다. 이러한 이벤트는 동 일한 clientip를 공유하며 각 세션의 지 속 시간이 10분을 초과하지 않고 3개를 초과하는 이벤트를 포함하지 않을 경우 transaction 명령어에 의해 그룹화됩니 다. 세션 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 명령어의 예 40

54 4장: SPL: 검색 처리 언어 요점 모든 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 이 절에서는 top, stats, chart, timechart 등과 같은 보고 명령어에 대 해 설명합니다. 필드 리스트가 주어진 상태에서 top 명령어는 가장 자주 발생하는 필 드 값의 조합을 개수 및 백분율과 함께 반환합니다. by-clause를 이용 하여 필드들을 지정하면, by-clause로 지정된 필드들의 그룹별로 가장 빈번한 값을 반환합니다. 41

55 Exploring Splunk top의 반대는 rare입니다. top 명령어의 반대는 rare 명령어입니다. 때로는 필드의 (가장 일반적인 값 대신) 가장 드문 값을 알아야 할 수도 있습니다. rare 명령어가 정확히 이러한 기능을 합니다. 표 4-7. top 명령어의 예 명령 top 20 url top 2 user by host top user, host 결과 가장 일반적인 20개의 URL을 반환 합니다. 각 호스트에 대해 상위 2명의 user 값을 반환합니다. 상위 10개(기본값)의 user-host 조 합을 반환합니다. 표 4-7의 두 번째 예, top 2 user by host가 그림 4-6에 나와 있습니다. host-1 host-1 host-1 host-1 host-1 host-1 host-1 host-2 host-2 host-2 host-2 host-2 user user_a user_a user_b user_c user_c user_c user_d user_e user_e user_f user_g user_g <fields > host-1 host-1 host-1 host-1 host-2 host-2 host-2 user user_a user_b user_c user_d user_e user_f user_g host-1 host-1 host-2 host-2 user user_c user_a user_e user_g intermediate results: identifying count & percent of user values for each host value top 2 user by host 그림 4-6. top 명령어의 예 42

56 4장: SPL: 검색 처리 언어 stats stats 명령어는 데이터세트에 대해 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) stats avg(kbps) by host stats count(eval(method= GET )) as GET, count(eval(method= POST )) as POST by host... top limit=100 referer_ domain stats sum(count) as total 결과 고유한 host 값의 개수를 반환합니 다. 각 호스트의 평균 전송율을 반환합 니다. 각 웹 서버(host)에 대해 서로 다른 요청 유형의 수를 반환합니다. 결과 테이블에는 각 호스트에 대한 행과 GET 및 POST 요청 방법 개수에 대 한 컬럼이 포함됩니다. referer_domain의 상위 100개 값 에서 총 히트 수를 반환합니다. 43

57 Exploring Splunk stats count, max(magnitude), min(magnitude), range(magnitude), avg(magnitude) by Region stats values(product_type) as Type, values(product_name) as Name, sum(price) as Revenue by product_id rename product_id as Product ID eval Revenue= $.tostring(revenue, commas ) USGS 지진 데이터를 사용하여 각 Region에 대한 지진 발생 수와 추가 통계치를 반환합니다. 매장에서 판매된 각 product_id에 대해 Type, Name 및 Revenue 컬럼이 포함된 테이블을 반환합니다. 또한 Revenue의 서식을 $123,456으로 지 정합니다. 호스트당 GET 및 POST 요청 개수를 검색하는 표 4-8의 세 번째 예는 그림 4-7에 나와 있습니다. 그림 4-7. stats 명령어의 예 표 4-9에는 stats 명령어와 함께 사용할 수 있는 통계 함수가 나열되어 있습니다. (이 함수들은 이후에 설명하는 chart 및 timechart 명령어에 도 사용할 수 있습니다.) avg(x) count(x) dc(x) max(x) median(x) min(x) mode(x) 표 4-9. stats 통계 함수 수학적 계산 필드 X 값의 평균을 반환합니다. mean(x) 참조. 필드 X의 발생횟수를 반환합니다. 일치하는 필드 값을 나타내기 위해 X 인수의 서식을 eval(field="value") 와 같은 표현식으로 지정합니다. 필드 X의 개별 값의 개수를 반환합니다. 필드 X의 최대값을 반환합니다. 값이 숫자가 아닌 경 우에는 최대값이 사전 순서에 따라 결정됩니다. 필드 X의 중앙값을 반환합니다. 필드 X의 최소값을 반환합니다. 값이 숫자가 아닌 경 우에는 최소값이 사전 순서에 따라 결정됩니다. 필드 X의 최빈값을 반환합니다. 44

58 4장: SPL: 검색 처리 언어 chart perc<percentnum>(x) range(x) stdev(x) sum(x) var(x) first(x) last(x) list(x) values(x) 필드 X의 <percent-num>번째 값을 반환합니다. 예를 들어 perc5(total)는 total 필드의 5백분위수를 반 환합니다. 필드 X의 최대값과 최소값 사이의 차이를 반환합니다( 값이 숫자인 경우). 필드 X의 표본표준편차를 반환합니다. 필드 이름을 지 정할 때 와일드카드를 사용할 수 있습니다. 예를 들어 "*delay"는 "delay"와 "xdelay" 둘 모두에 일치합니다. 필드 X의 값의 합을 반환합니다. 필드 X의 표본 분산을 반환합니다. 값 선택 필드 X의 첫 번째 값을 반환합니다. last(x)의 반대입 니다. 필드 X의 마지막 값을 반환합니다. first(x)의 반대입 니다. 일반적으로 필드의 마지막 값은 연대순으로 가 장 오래된 값입니다. 필드 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 명령어에 적용됩니다. chart 명령어는 차트에 사용할 수 있도록 테이블 형식의 데이터 결과를 생성합니다. over 또는 by를 사용하여 x축 변수를 지정합니다. 표 4-10에는 chart 명령어를 사용하는 몇 가지 예가 나와 있습니다. 자 세한 실제 시나리오는 6장을 참조하십시오. 45

59 Exploring Splunk 표 chart 명령어의 예 명령 chart max(delay) over host chart max(delay) by size bins=10 chart eval(avg(size)/ max(delay)) as ratio by host user... chart dc(clientip) over date_hour by category_id usenull=f chart count over Magnitude by Region useother=f chart count(eval(method= GET )) as GET, count(eval(method= POST )) as POST by host 결과 각 host 값에 대해 max(delay)를 반환합니다. size별로 최대 delay를 차트로 표 시합니다. 여기서 size는 최대 10개 의 같은 크기 버킷으로 분할됩니다. 각 개별 host 및 user 쌍에 대해 평 균 size 대 최대 delay의 비율을 차 트로 표시합니다. 시간당 고유한 clientip 값의 수 를 범주별로 차트로 표시합니다. usenull=f은 값이 없는 필드를 제 외합니다. 지진의 수를 Magnitude 및 Region 별로 차트로 표시합니다. 드문 Regions에 대해 "other" 값을 출력하 지 않으려면 useother=f 인수를 사 용하십시오. 각 웹 서버(host)에 대해 발생한 GET 및 POST 페이지 요청의 수를 차트로 표시합니다. 그림 4-8(테이블 형식의 결과) 및 4-9(로그 눈금의 막대 차트)는 표 4-10의 마지막 예의 실행 결과를 보여줍니다. 그림 4-8. chart 명령어의 예 - 테이블 형식의 결과 46

60 4장: SPL: 검색 처리 언어 그림 4-9. chart 명령어의 예 - 보고서 작성기 형식의 차트 timechart timechart 명령어는 시간을 x축으로 하여 필드에 적용된 통계 집계에 대한 차트를 만듭니다. 표 4-11에는 timechart 명령어를 사용하는 몇 가지 예가 나와 있습니 다. 6장에 이 명령어를 사용하는 예가 자세히 나와 있습니다. 표 timechart 명령어의 예 명령 timechart span=1m avg(cpu) by host timechart span=1d count by product-type timechart avg(cpu_seconds) by host outlier timechart per_hour(price) by product_name 결과 각 호스트의 분당 평균 CPU 사용량 의 평균값을 차트로 표시합니다. 각 제품 유형별 일일 구매 횟수를 차 트로 표시합니다. span=1d 인수는 주간 구매 횟수를 일별 청크에 넣습 니다. host별 평균 cpu_seconds를 차트로 표시하고 시간 차트의 y축을 왜곡하 는 이상값을 제거합니다. 어제 판매된 제품의 시간별 수익을 차트로 표시합니다. per_hour() 함 수는 각 항목 (product_name)의 가 격 필드의 값을 합하고 그 합을 각 버킷의 시간 범위에 따라 적절히 조 정합니다. 47

61 Exploring Splunk 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에 나와 있습니다. 그림 timechart 명령어의 예 - 테이블 형식의 결과 그림 timechart 명령어의 예 - 서식이 지정된 시간 차트 필드 필터링, 수정 및 추가 이 명령어들은 검색 결과에서 원하는 필드만을 추려내는 데 도움이 됩 니다. fields 명령어를 사용하여 일부 필드를 제거하여 결과를 단순화할 수도 있습니다. replace 명령어를 사용하여 필드 값을 사용자가 더 읽 48

62 4장: SPL: 검색 처리 언어 fields 기 쉽도록 만들 수 있습니다. 또는 eval, rex 및 lookup과 같은 명령어 를 이용하여 새 필드를 추가할 수도 있습니다. eval 명령어는 다른 필드간의 산술 계산이나 문자열의 연결, 또는 부울 논리 연산을 통해 새 필드의 값을 계산합니다. rex 명령어는 정규식을 사용해 다른 필드에서 패턴이 있는 데이터 를 추출하여 새 필드를 만드는데 사용할 수 있습니다. lookup 명령어는 이벤트의 값을 기준으로 룩업 테이블을 참조하 고, 룩업 테이블에서 일치하는 행의 필드를 해당 이벤트에 추가하 는 방식으로 필드를 추가합니다. 이 명령어들은 새 필드를 만들기 위해 사용하거나 기존 필드의 값을 덮 어쓰기 위해 사용할 수 있습니다. 이는 사용자의 선택에 달려 있습니다. fields 명령어는 검색 결과에서 필드를 제거합니다. 일반적인 명령어는 표 4-6에 나와 있습니다. 표 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에 나와 있습 니다. 49

63 Exploring Splunk field field1 A B C D E F G H I field1 a b c d e f g h i <fields > field field1 A B C D E F G H I field1 a b c d e f g h i <fields > field1 a b c d e f g h i <fields >... - field1 field2 요점 그림 fields 명령어의 예 내부 필드, 즉 이름이 밑줄로 시작하는 필드는 명시적으로 지정되지 않 는 한 fields 명령어에 영향을 받지 않습니다. replace replace 명령어는 대치 값을 사용하여 지정된 필드 값의 검색 및 바꾸 기를 수행합니다. 검색어나 대치어의 값은 대소문자를 구분합니다. 표 replace 명령어의 예 명령 replace *localhost with localhost in host replace 0 with Critical, 1 with Error in msg_level replace aug with August in start_month end_month replace with localhost 결과 localhost로 끝나는 모든 host 값 을 localhost로 변경합니다. msg_level 값 0을 Critical로, msg_level 값 1을 Error로 변경합 니다. 모든 start_month 또는 end_month 값 aug를 August로 변경합니다. 모든 필드 값 을 localhost로 변경합니다. 표 4-13의 두 번째 예 replace 0 with Critical, 1 with Error가 그 림 4-13에 나와 있습니다. 50

64 4장: SPL: 검색 처리 언어 msg_level <fields > msg_level <fields >... replace 0 with Critical, 1 with Error in msg_level 그림 replace 명령어의 예 eval eval 명령어는 표현식을 계산하고 결과 값을 새 필드에 넣습니다. eval 및 where 명령어는 동일한 표현식 구문을 사용합니다. 부록 E에 사용 가능한 모든 함수가 나열되어 있습니다. 표 eval 명령어의 예 명령 eval velocity=distance/ time eval status = if(error == 200, OK, Error ) eval sum_of_areas = pi() * pow(radius_a, 2) + pi() * pow(radius_b, 2) 결과 velocity를 distance 나누기 time으 로 설정합니다 error가 200이면 status를 OK로, 그 렇지 않은 경우 Error로 설정합니다. sum_of_areas를 두 원의 면적의 합 으로 설정합니다. 그림 4-14에 표 4-14의 첫 번째 예 eval velocity=distance/time가 나 와 있습니다. 51

65 Exploring Splunk <fields > velocity <fields >... eval velocity=distance/time 그림 eval 명령어의 예 eval 명령어의 결과가 새 velocity 필드를 생성합니다. (velocity 필드 가 존재하느 경우 eval 명령어가 값을 업데이트합니다.) eval 명령어는 한 번에 하나의 필드만 만들거나 재지정합니다. rex rex 명령어는 지정된 PCRE(Perl Compatible Regular Expression)와 값 이 일치하는 필드를 추출합니다. (rex는 regular expression의 줄임말 입니다.) 정규식이란 무엇입니까? 정규식을 "광범위한 와일드카드'로 생각하십시오. 아마도 *.doc 또는 *.xls와 같은 표현을 사용하여 파일을 검색해 보셨을 것입니다. 정규식을 사용하면 기능과 유연성을 높일 수 있습니다. 정규식에 익숙한 경우 이 내용을 읽지 않아도 됩니다. 자세한 내용은 참조하십시오. 표 rex 명령어의 예 명령 rex From: (?<from>.*) To: (?<to>.*) rex field=savedsearch_id (?<user>\w+);(?<app>\w+); (?<SavedSearchName>\w+) 결과 정규식을 사용하여 from 및 to 필 드를 추출합니다. 원시 이벤트에 From: Susan To: Bob 이 포함되 어 있는 경우 from=susan 및 to=bob 입니다. savedsearch_id라고 하는 필드에 서 user, app 및 SavedSearchName 을 추출합니다. savedsearch_id = bob;search;my_saved_search 의 경우 user=bob, app=search 및 SavedSearchName=my_saved_ search입니다. 52

66 4장: SPL: 검색 처리 언어 rex mode=sed s/(\\d{4}-){3}/ XXXX-XXXX-XXXX-/g 정규식을 일련의 숫자와 일치시키 고 익명처리된 문자열로 대치하려면 sed 구문을 사용하십시오. 그림 4-15는 from 및 to 필드를 추출한 표 4-15의 첫 번째 예를 보여 줍니다. _raw From: 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 from Susan Meenu John to Bob Miguel _raw Subject: 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... rex "From: (?<from>.*) To: (?<to>.*) 그림 rex 명령어의 예 lookup lookup 명령어는 룩업 테이블에서 필드 룩업을 수동으로 호출하며, 이 명령어를 사용하여 외부 소스에서 필드 값을 추가할 수 있습니다. 예를 들어, 5자리 우편번호가 있는 경우 거리 이름을 조회하여 ZIP+4 9자리 우편번호를 적용할 수 있습니다. 표 명령어의 예 명령 lookup usertogroup user as local_user OUTPUT group as user_group 결과 transform.conf 1 의 스탠자 이름 usertogroup에 지정된, user 및 group 필드가 있는 룩업 테이블에 대해 각 이벤트의 local_user 필드 의 값을 조회합니다. 일치하는 항목 의 경우 룩업 테이블의 group 필드 의 값이 이벤트의 user_group 필드 에 쓰여집니다. 1 룩업 테이블은 관리자» 룩업에서 구성할 수 있습니다. 53

67 Exploring Splunk lookup dnslookup host OUTPUT ip lookup local=true userziplookup user as local_user OUTPUT zip as user_zip 역 DNS 룩업을 수행하고 호스트 이 름 또는 IP 주소를 인수로 수신하는 Python 스크립트를 참조하는 dnslookup 이름의 필드 룩업이 지정된 경우, 이벤트의 호스트 이름 값(host 필드)을 테이블의 호스트 이름 값과 일치시킨 다음 해당하는 IP 주소 값 (ip 필드)을 이벤트에 추가합니다. 검색 헤드에만 존재하는 로컬 룩업 테이블에 대해 각 이벤트의 user 필 드의 값을 조회합니다. 일치하는 항 목의 경우 룩업 테이블의 zip 필드 의 값이 이벤트의 user_zip 필드에 쓰여집니다. 그림 4-16에 표 4-16의 첫 번째 예 lookup usertogroup user as local_user OUTPUT group as user_group이 나와 있습니다. usergroup lookup table user User10 User9 User1 User7 User2 User3 User27 User98 group A B C D E F G H <fields > local_user User1 User2 User3 search results user_group C E F <fields >... local_user User1 User2 User3 <fields >... lookup usertogroup user as local_user OUTPUT group as user_group... 그림 lookup 명령어의 예 이 장에서는 SPL의 명령어에 대한 속성 과정을 제공했습니다. 다음 장 에서는 태그와 event type을 사용하여 데이터를 강화하고 Splunk에서 특정 패턴을 감독하고 경고를 보내도록 설정하는 방법에 대해 설명합 니다. 54

68 5 데이터 강화 데이터를 더 유용하게 만들려면 데이터에 정보를 추가하십시오. 이 말 이 무슨 의미일까요? Splunk에서 데이터로부터 필드를 추출하는 방법 을 설정하는 경우, 해당 필드에 대해 논리적으로 생각해보고 심층적인 분석을 위한 데이터 분류를 위해 정보를 추가할 수 있습니다. 보고서 와 대시보드를 설정하면 사용자와 다른 사람들이 데이터를 더 쉽게 이 해할 수 있게 됩니다. 또한, 경고를 만들면 Splunk에서 능동적으로 잠 재적인 문제를 발견하므로 뒤늦게 수동으로 문제를 검색하지 않아도 됩니다. 이 장에서는 다음과 같은 세 가지 분야에 대해 설명합니다. Splunk를 사용하여 데이터 이해에서는 데이터를 탐색하고, 분류 하고, 익숙해지는 방법에 대해 설명합니다. 데이터 표시에서는 데이터 시각화의 기본사항에 대해 설명합니다. 잠재적인 문제에 대한 경고 만들기에서는 측정값이 임계값을 초과 하는 경우 추적하고 경고를 보내는 방법에 대해 설명합니다. Splunk를 사용하여 데이터 이해하기 새로운 머신 데이터 소스는 처음에는 의미없는 숫자와 암호 문자가 뒤 죽박죽 엉켜 있는 것처럼 보입니다. 그러나 머신 데이터를 만들어내는 시스템에 대해 많이 알수록 데이터의 의미는 더욱 커집니다. 데이터 세 트에 대해 잘 알고 있더라도 계속해서 탐색하면 새로운 통찰력을 얻을 수도 있습니다. 데이터를 알게 되는 첫 번째 단계는 Splunk를 사용하여 데이터의 필드 를 식별하는 것입니다. 이 작업은 퍼즐의 모든 조각을 살펴보고 모양을 인식하는 것과 같습니다. 그 다음 단계는 집계 및 보고의 시작 단계로 서 데이터를 분류하는 것입니다. 이 작업은 퍼즐 조각을 바깥쪽 조각과 안쪽 조각으로 분류하는 것과 같습니다. 데이터를 이해하고 퍼즐 조각 을 짜맞출수록 그림이 더 분명해집니다. 마침내 그림이 완성되고(데이 터가 표시되고) 다른 사람과 공유할 수 있게 됩니다. 55

69 Exploring Splunk 필드 식별: 퍼즐 조각 살펴보기 Splunk는 source type이라고 불리는 다양한 데이터들의 공통 유형들 을 인식할 수 있습니다. 올바른 source type을 설정하는 경우 Splunk에 서는 사전 구성된 설정을 사용하여 필드를 식별할 수 있습니다. 예를 들어, 대부분의 웹 서버 유형이 이 경우에 해당합니다. 하지만 종종 머신 데이터에 포함된 숨겨진 속성이 있습니다. 예를 들 어, URL의 일부로 제품의 카테고리 정보가 있는 경우가 있습니다. URL 에 특정한 제품 범주가 있는 이벤트들을 조사하면 사이트의 여러 섹션 에 대한 반응 시간과 오류율 그리고 가장 많이 검색된 제품에 대한 정 보를 확인할 수 있 습니다. 자동 필드 검색 검색 시 Splunk는 키와 값 사이 등호(=)의 존재와 같이 데이터 내에서 공통적인 패턴을 식별하여 필드를 자동으로 추출합니다. 예를 들어, 이 벤트에 id=11 lname=smith 가 포함되어 있는 경우 Splunk에서 는 예제 값을 갖는 id 및 lname 필드를 자동으로 생성합니다. 또한 2장 에서 언급했듯이 일부 필드(source, sourcetype, host, _time, 및 linecount 등)는 항상 식별됩니다. 원하는 정보를 찾을 수 없습니까? 검색을 시작해 보십시오. Splunk에서는 기본적으로 UI에서 일정한 수의 필드만 표시됩니다. 수백 개의 필드를 완벽하게 더 추출할 수도 있습니다. 이들 필드를 검색하면 맨 위에 표시됩니다. UI turui의 필드 사이드바에 있는 필드 검색 스위치를 사용하면 이 동 작을 켜거나 끌 수 있습니다. 선택된 필드(Splunk에서 기본적으로 선택 했거나 사용자가 선택한 필드)들이 표시되고 Splunk가 추출한 필드들 이 이어서 표시됩니다. 수정을 클릭하면 Splunk에서 선택된 필드 그룹 에 추가할 수 있는 더 많은 필드를 나열합니다. 아무 필드나 클릭하면 검색 결과에서 추출된 상위 값이 표시됩니다. 자동 필드 검색에 대한 자세한 내용은 를 참조하십시오. 필드 추출 구성 필드 추출 구성은 두 가지 방법으로 이루어집니다. Splunk에서 대화형 필드 추출기를 사용하여 구성을 자동화하도록 하거나 사용자 자신이 수동으로 구성할 수 있습니다. 56

70 5장: 데이터 강화 대화형 필드 추출기 검색 결과의 어느 이벤트에서든 이벤트 리스트의 이벤트 왼쪽에 있는 아래쪽 화살표를 클릭하면 표시되는 이벤트 옵션 메뉴에서 필드 추출 을 선택하여 대화형 필드 추출기(IFX)를 시작할 수 있습니다(그림 5-1 참조). 그림 5-1. 이벤트 옵션 메뉴에서 필드 추출을 선택하면 대화형 필드 추출기 가 시작됩니다. IFX는 브라우저의 다른 탭이나 창에 표시됩니다. 검색하는 값의 종류( 예를 들어, 웹 로그의 클라이언트 IP 주소)를 입력하면 Splunk에서 유사 한 값을 추출하는 정규식을 생성합니다(이 기능은 사용자가 정규식에 대해 지식이 없을 때 특히 유용합니다). 원하는 필드를 제대로 찾도록 추출을 테스트하고 추출 내용을 필드 이름과 함께 저장할 수 있습니다. 대화형 필드 추출기에 대해 자세히 알아보려면 를 참조하십시오. 수동으로 필드 추출 구성 관리자» 필드» 필드 추출에서 수동으로 정규식을 지정하여 필드를 추출할 수 있습니다. 이 방법이 필드를 추출하는 보다 유연하고 고급스 러운 방법입니다. 정규식을 수동으로 지정하는 데 대해 자세히 알아보려면 goto/book#config_fields를 참조하십시오. 검색 언어 추출 필드를 추출하는 또 다른 방법은 검색 명령어를 사용하는 것입니다. 데 이터를 추출하기 위한 가장 일반적인 명령어는 이전 장에 설명된 rex 명령어입니다. 이 명령어에서는 정규식을 가지고 해당 정규식과 일치 하는 필드를 추출합니다. 57

71 Exploring Splunk 때때로 필드를 추출하는 데이터의 종류에 따라 사용하는 명령어가 달 라집니다. 여러 줄의 테이블 형식의 이벤트(명령줄 출력 등)에서 필드 를 추출하려면 multikv를 사용하고, XML 및 JSON 데이터에서 추출하 려면 spath 또는 xmlkv를 사용하십시오. 필드를 추출하는 명령에 대해 자세히 알아보려면 book#search_fields를 참조하십시오. 데이터를 탐색하여 데이터의 범위 이해 필드를 추출한 후 데이터 탐색을 시작하여 데이터의 의미를 파악할 수 있습니다. 다시 퍼즐의 비유로 돌아가서, 이제 여러분은 패턴을 찾기 시작했습니다. 어떤 조각이 퍼즐의 테두리 부분의 조각인가요? 어떤 다 른 방법으로 퍼즐 조각들을 분류할 수 있나요? 모양 또는 색깔로 분류 할 수 있나요? 검색 대시보드의 필드 사이드바는 다음과 같은 각 필드에 대한 정보를 즉시 제공합니다. 필드의 기본 데이터 유형. 필드 이름 왼쪽에 문자로 표시됩니다 ("a"는 텍스트, "#"는 숫자를 나타냅니다. 이벤트 리스트 내 필드의 발생 횟수(필드 이름 뒤의 괄호 안에 표 시됩니다). 필드 사이드바에서 필드 이름을 클릭하면 상위 값 및 차트에 대한 링크 를 포함한 필드 요약이 표시됩니다. 그림 5-2. 필드 사이드바에서 필드 이름을 클릭하여 필드 요약 보기 58

72 5장: 데이터 강화 또한 이벤트 리스트의 범위를 좁혀 해당 필드에 값이 있는 이벤트만 표 시할 수도 있습니다. 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의 상태는 서버측 오류입니다. 웹 서버에서 "서비스 사용 불가" 메시지를 보냈습니다. 경제적인 측면에서 보면 이는 누군가 사이트에 왔 다가 작업을 계속하지 못했다는 것을 나타냅니다. 이 오류가 계속 발생하면 운영 측면을 살펴봐야 합니다. 59

73 Exploring Splunk 그림 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 category_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 등 두 가 지 유용한 방법이 있습니다 여기서는 예제로 제공되었지만 아래 페이지에서 실제 데이터를 다운로드하 여 테스트 해 볼 수 있습니다.

74 5장: 데이터 강화 태그 지정 태그는 필드 값에 쉽게 레이블을 지정할 수 있는 방법입니다. 호스트 이 름 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)에 대한 추가 설명이 필요합니다. 61

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

76 5장: 데이터 강화 정의한 대로 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개의 이벤트를 볼 수 있습니다. 63

77 Exploring Splunk 그림 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에 추가하는 것입니다. 64

78 5장: 데이터 강화 앞서 무관 검색에 대해 이야기한 바 있습니다. 특별히 보고 싶지 않은 모든 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 category_id 65

79 Exploring Splunk 그림 5-7. 제품 category_id별 404 오류 회수 꽃과 선물이 마진이 가장 높은 상품이므로 잘못된 URL에 대해서는 몇 가지 리디렉션을 추가하는 것이 좋습니다. (그리고 외부 링크를 업데 이트하기 위해 회사 페이지로 연결되는 사이트를 조회해 보는 것이 좋 습니다.) Splunk에서 아무 그래픽 위에 마우스를 올려놓으면 그래픽의 해당 부분 뒤에 있는 데이터에 대해 더 많은 정보를 얻을 수 있습니다. 그림 5-8을 참조하십시오. 그림 5-8. 그래픽의 한 부분에 마우스를 올려 놓으면 데이터에 대한 세부정 보가 표시됩니다. 66

80 5장: 데이터 강화 대시보드 만들기 모니터링을 위해 Splunk를 사용하는 경우 최종 결과는 보통 여러 시각 자료가 포함된 대시보드 형태로 만들어지게 됩니다. 대시보드는 검색 결과의 차트, 게이지, 테이블 또는 리스트(데이터를 보는 것 자체가 도 움이 되는 경우도 종종 있습니다)로 구성된 보고서 패널을 말합니다. 대시보드를 설계하는 경우 "이들 중 내가 제일 먼저 보고 싶은 차트는 어떤 것인가? 최종 사용자는 어느 차트를 먼저 보고 싶어할까? 일선 관 리자는 어느 차트를 먼저 보고 싶어하나?"라고 자문해 보십시오. 사용 자마다 자신만의 대시보드를 필요로 하는 경우가 많습니다. 그렇다면 "이 대시보드를 보면 어떤 질문이 떠오를까?"라고 질문해 보 십시오. Splunk에서는 간단히 차트를 클릭하면 차트 세부정보에 대한 다양한 종류의 드릴다운 항목이 자동으로 처리됩니다. (고급 사용자는 드릴다운 동작을 명확하게 지정할 수 있지만 이는 이 책의 범위를 벗 어납니다.) 한 가지 유의할 점은 단순한 시각화가 모든 수준의 사용자에게 가장 인 기있다는 것입니다. 고급형의 상세한 대시보드를 만들 수 있고, 또 만 들어야 하지만, 간결하면서 수준 높은 뷰를 만드는데에 집중하십시오. 그림 5-9에는 대시보드의 예가 나와 있습니다. 그림 5-9. 대시보드 대시보드를 구축하는 최선의 방법은 각 패널을 구현함에 있어서 하향 식이 아니라 상향식으로 구축하는 것입니다. 먼저 Splunk의 차트 작성 기능을 사용하여 중요한 사항을 다양한 방식으로 표시하십시오. 시스 템의 상태를 표시하는 여러 개의 개별 차트가 있는 경우 대시보드에 배 치하십시오. 67

81 Exploring Splunk 대시보드 만들기 Splunk 4.3에서 대시보드를 만들고 보고서, 차트 또는 검색 결과를 대 시보드에 추가하려면 다음 단계를 수행합니다. 1. 대시보드용 보고서를 생성하는 검색을 실행합니다. 2. 만들기» 대시보드 패널을 선택합니다. 3. 검색에 이름을 지정하고 다음을 클릭합니다. 4. 이 보고서를 새 대시보드에 추가할 것인지 기존 대시보드에 추가 할 것인지 결정합니다. 새 대시보드를 만드는 경우 이름을 지정합 니다. 다음을 클릭합니다. 5. 대시보드와 시각자료(테이블, 막대, 파이, 게이지 등)의 제목 그리 고 패널용 보고서 실행 시기를 지정합니다(대시보드가 표시될 때 마다 또는 정해진 일정에 따라). 6. 다음, 대시보드 보기 링크 또는 확인을 차례로 클릭합니다. 대시보드 보기 언제든지 페이지 상단의 대시보드 및 뷰 메뉴에서 대시보드를 선택해 볼 수 있습니다. 대시보드 편집 대시보드를 보는 동안 편집 모드 선택기에서 설정을 클릭한 다음 편집 하고자 하는 패널의 편집 메뉴를 클릭하여 대시보드를 편집할 수 있습 니다. 여기서 보고서를 생성하는 검색 또는 검색이 시각화되는 방식을 편집하거나 패널을 삭제할 수 있습니다. 경고 만들기 경고란 무엇입니까? 경고는 주기적으로 실행되는 "if-then" 문으로 생 각할 수 있습니다. 만약(if) 이러한 일이 발생하면, 이렇게(then) 반응합니다. 이 경우 "if"는 검색입니다. "then"은 "if" 절이 충족되는 경우 이에 대한 반응으로 취하고자 하는 조치입니다. 보다 공식적으로 말하자면 경고는 주기적으로 실행되는 검색으로서 검 색 결과에 대한 조건을 평가합니다. 조건이 일치하면 일부 조치가 실 행됩니다. 마법사를 통한 경고 만들기 경고를 만드는 첫 번째 단계는 경고하고자 하는 항목에 대한 조건을 검 색하는 것입니다. Splunk에서 경고를 만들 때는 검색란에 있는 검색을 68

82 5장: 데이터 강화 경고 예약 가져와서 저장하여 사용하며, 이 검색이 경고의 기반("if-then"의 "if") 이 됩니다. 검색란에서 원하는 검색을 선택한 상태에서 만들기» 경고를 선택합 니다. 이렇게 하면 마법사가 시작되고 경고를 쉽게 만들 수 있습니다. 경고 만들기 대화 상자의 예약 화면에서 경고의 이름을 지정하고 Splunk에서 경고를 실행할 방식을 지정합니다. Splunk에서 검색을 실시간으로 실행하거나, 주기적으로 예약된 검색을 실행하거나, 롤링 윈도우에서 실시간으로 모니터링하여 조건을 모니터 링하도록 선택할 수 있습니다. 다음은 이 세 가지 옵션을 사용하는 예입니다. 조건이 발생할 때마다 언제나 경고를 받으려면 실시간으로 모니 터링합니다. 긴급성이 떨어지는 조건이지만, 그 내용을 알고자 하는 조건의 경 우 예약 방식으로 모니터링합니다. 일정 기간 내 일정한 수의 일이 발생하는지 여부를 확인하려면 실 시간 롤링 윈도우를 사용하여 모니터링합니다(이 옵션은 첫 번째 두 옵션을 조합한 것입니다). 예를 들어, 5분 동안 20번 이상 404 오류가 발생하면 바로 경고를 트리거할 수 있습니다. 예약 방식으로 롤링 윈도우에서 모니터링하도록 지정하는 경우, 경고 를 트리거하기 위해 검색에 일치하는 시간 간격 및 결과의 수도 지정해 야 합니다. 또는 경고 조건이 충족될 경우 실행되는 검색인 사용자 지 정 조건을 입력할 수도 있습니다. 사용자 지정 조건은 이 장의 뒷부분 에 설명되어 있습니다. 그림 경고 예약 69

83 Exploring Splunk 작업 지정 다음 단계는 한도를 설정하고 경고가 트리거될 때 실행될 작업을 지정 하는 것입니다. 경고 조건이 발생하면 어떤 일을 해야 합니까? 경고 만들기 대화 상자 의 작업 화면에서 실행할 작업(이메일 보내기, 스크립트 실행, 경고 관 리자에서 트리거된 경고 표시)을 지정할 수 있습니다. 그림 5-11에서 사용자는 위의 모든 작업을 선택하여 전체 옵션을 사용 할 수 있도록 지정했습니다. 70 그림 마법사의 작업 화면

84 5장: 데이터 강화 이메일 보내기. 이메일에는 다음과 같은 옵션이 있습니다. 이메일 주소. 하나 이상을 입력합니다. 제목. 이 옵션은 기본값(Splunk Alert: AlertName)으로 남겨둘 수 있습니다. $name$이 경고 이름으로 대치됩니다. (즉, 제목을 "이런! $name$이 발생했습니다"로 변경할 수 있습니다.) 경고를 트리거하는 결과 포함. 체크박스를 클릭하여 결과를 첨 부된 CSV 파일로 포함하거나 인라인을 선택하여 이메일에 바 로 추가할 수 있습니다. 스크립트 실행. 스크립트 이름을 지정합니다. 스크립트는 /bin/ scripts 또는 앱의 /bin/scripts 디렉토리 내 Splunk의 홈 디렉 토리에 있어야 합니다. 경고 관리자에 트리거된 경고를 표시합니다. 경고 관리자는 UI의 오른쪽 상단에 있는 경고를 클릭하면 열립니다. 하나(또는 두 개나 세 개)의 작업을 선택한 후 다음과 같은 추가 옵션 을 입력할 수 있습니다. 심각도를 설정합니다. 심각도는 경고를 분류할 수 있는 참조용 메 타데이터입니다. 수준은 정보, 낮음, 중간, 높음 및 중요입니다. 심 각도는 경고 관리자에 표시됩니다. 모든 결과 또는 각 결과에 대해 작업을 실행합니다. 이에 따라 Splunk에서 검색과 일치하는 결과 그룹 또는 각 개별 결과에 대해 (이메일 보내기와 같은) 작업을 실행하는지 여부가 결정됩니다. " 모든 결과"가 기본값입니다. 경보 조절. 경고는 필요할 때 알고 싶은 정보를 제공하는 경우에 만 효과적입니다. 경고가 너무 많으면 무시하게 됩니다. 너무 적으 면 무슨 일이 일어나고 있는지 알 수 없습니다. 이 옵션은 경고가 트리거된 후 Splunk에서 경고와 관련된 작업을 다시 수행할 때까 지 얼마나 기다려야 하는지를 지정합니다. 롤링 윈도우를 지정하 는 경우에는 마법사가 해당 기간과 일치하도록 경보 조절 간격의 기본값을 지정합니다. 추가 경보 조절 옵션은 이 장의 뒷부분에 설 명되어 있습니다. 다음을 클릭한 후 마지막 단계는 경고가 현재 앱의 사용자에 대해 비공 개인지, 읽기 전용 액세스 상태로 공유되는지 여부를 지정하는 것입니 다. 완료를 클릭하여 마법사를 종료합니다. 관리자를 사용한 경고 조절 경고에 대한 적절한 한도를 설정하는 데는 일반적으로 시행착오가 필 요합니다. 중요하지 않은 경고가 너무 많거나 중요한 경고가 너무 적지 않도록 조정해야 할 수도 있습니다. 예를 들어, 중요한 이벤트가 한 번 발생해서는 경고가 발생되지만, 상한 10% 내에 들어가는 10번의 중요 71

85 Exploring Splunk 이벤트는 경고를 트리거하도록 한도를 조정해야 합니다. 마법사를 사용하여 신속하게 경고를 만들 수 있으며 관리자를 사용하 여 경고의 여러 옵션을 조정할 수 있습니다. 저장된 검색이 경고의 기반이라는 점을 기억하십시오. 따라서 경고는 저장된 검색과 같은 방법으로 편집합니다. 경고를 편집하려면 관리자, 검색 및 보고서를 차례로 선택합니다. 리스트에서 저장된 검색을 선택하여 매개변수를 표시합니다. 경고 조건 설정 경고를 If-Then 문으로 생각할 경우 관리자를 통해 If 부분을 보다 유 연하게 편집할 수 있습니다. 경고는 다음과 같이 트리거되도록 설정할 수 있습니다. 항상 event, host, source의 수에 따라 사용자 지정 조건 마법사는 이벤트의 수에 따라 경고를 제공하지만 여기서는 host 또는 source의 수에 따라 경고를 트리거할 수 있습니다. 호스트를 고려하십 시오. 클러스터의 한 웹 서버에서 "서버 사용 불가" 상태를 발견하는 것 은 대수롭지 않을 수도 있지만, 이러한 상태가 점점 더 많은 서버에서 발견되는 것은 차원이 다른 이야기입니다. 분명한 것은 이벤트가 급증 하고 있고 서버들이 트래픽을 처리하지 않고 있다는 것입니다. 이 화면에서는 경고에 대한 임계값을 다음과 같이 보다 유연하게 정의 할 수 있습니다. 보다 큼 보다 작음 같음 같지 않음 증가 감소 처음 네 가지 옵션은 마법사를 통해 제공되지만 여기서는 일정한 개수 또는 일정한 비율(예: 50%)로 증가하거나 감소하는 경우 경고를 보낼 수 있는 기능 또한 추가로 제공됩니다. "증가" 및 "감소"를 사용하면 상 대적인 조건에 대한 경고를 효과적으로 설정할 수 있습니다(종종 경고 를 받고자 하는 항목의 두 배 또는 세 배와 같이 절대적인 수가 아닙니 다). "증가' 또는 "감소"는 실시간 검색을 사용하는 조건에 대해서는 지 원되지 않습니다. 72

86 5장: 데이터 강화 사용자 지정 조건 설정 경고 조절 UI를 통해 가장 일반적인 종류의 경고 조건을 유연하게 구성할 수 있 지만 사용자 지정 조건의 형태로 훨씬 더 유연하게 구성해야 하는 경 우도 있습니다. 사용자 지정 조건은 경고의 기본 검색 결과에 대한 검색입니다. 검색에 서 결과값을 반환하면 조건이 참이 되고 경고가 트리거됩니다. 예를 들어, 호스트가 중단되는 경우 언제나 경고를 받지만 예정된 유 지보수가 진행 중인 호스트는 제외할 수 있습니다. 이렇게 하려면, 중 단되는 모든 호스트를 반환하도록 기본 검색을 만들고 사용자 지정 조 건으로 "false positive", 즉 유지보수 일정에 포함된 호스트를 제외시킵 니다. 이러한 방식으로 호스트가 예기치 않게 중단되는 경우에만 경고 를 받습니다. Splunk를 사용하면 경고를 통해 유용한 정보를 제공하도록 조정할 수 있습니다. 중요한 정보를 제공하는 하나의 메시지는 도움이 됩니다. 반 면에 아무리 조건에 매치된다 하더라도 메시지가 100개씩 제공된다면 그 경고는 의미가 퇴색됩니다. 이것은 의미 없는 정보가 됩니다. Splunk를 사용하면 경고를 조절하여 경고가 트리거되더라도 특정한 시 간 간격으로 한 번만 울리도록 지정할 수 있습니다. 다시 말해, 첫 번 째 경고는 팝콘을 튀길 때 처음 터지는 옥수수알과 같으며 실제로 이 후의 관련된 다른 모든 옥수수알이 터지는 것에 대한 경고들은 원하지 않을 것입니다. (만약 팝콘의 예에서 두 번째 경고가 필요하다면, 모든 옥수수알이 터진 후 타버리기 전에 울리는 것이 기능적으로 적당할 것 입니다.) 이것이 경보 조절의 기능입니다. Splunk에서 경고를 보내되, 끊임없이 경고를 보내지 않도록 지정할 수 있습니다. 경고를 편집하기 위한 관리자 화면의 가운데에 경고 모드(그림 5-12 참 조)라고 하는 옵션이 있습니다. 그림 경고 모드 검색당, 즉 전체 검색 결과에 대해 한 번 경고를 받거나 또는 각각의 결 과 별로 한 번씩의 경고를 받을 수 있습니다. 결과당 경고는 필드별로 추가 조절할 수 있습니다. 예를 들어, 조건이 충족되는 경우 언제나, 호 73

87 Exploring Splunk 스트당 한 번만 경고를 받을 수 있습니다. 서버의 디스크 공간이 부족 해지고 있어서 사용 가능한 공간이 30% 미만이 되면 경고를 받고 싶 다고 가정하겠습니다. 필드 경고를 조절하는 결과별에 호스트를 지정 하면 지정된 기간 동안 각 호스트에 대해 한 번 경고를 받습니다. 사용 자 로그인 실패를 처리하는 경우에는 사용자 이름을 입력하면 됩니다. 경고에 대한 작업 사용자 지정 스크립트를 작성하거나 수정하여 경고에 대한 사용자 지정 작업을 설 정할 수 있습니다. 예를 들어, 다음과 같은 작업을 설정할 수 있습니다. 문제 해결에 도움이 되는 사람들에게 SMS 보내기. 헬프데스크 티켓 또는 다른 유형의 문제 티켓 생성. 서버 재시작. 이메일 보내기를 비롯한 모든 경고 작업은 스크립트를 기반으로 합니 다. RSS 피드를 만드는 경우도 마찬가지입니다. 이러한 정보를 바탕으 로, 스크립트를 사용하여 필요한 대로 유연하게 경고 작업을 설정할 수 있습니다. 사용자 지정 경고 스크립트 만들기에 대해 자세히 알아보려면 com/goto/book#custom_alerts를 참조하십시오. 경고 관리자 경고에 대한 설정은 경고 관리자에서 제어합니다. 경고 관리자를 표시하려면 화면 오른쪽 상단에서 경고를 클릭하십시오. 74

88 5장: 데이터 강화 그림 경고 관리자 여기서 간략한 용어 설명이 필요합니다. 저장된 if-then 예약 검색을 경 고라고 부르고, 해당 경고의 개별적인 발생을 경고 인스턴스라고 부르 겠습니다. 경고 관리자에는 가장 최근에 발생한 경고 (즉, 경고 인스턴스)의 리스 트가 표시됩니다. 이 리스트는 경고 인스턴스가 발생된 시기를 보여주 고, 해당 인스턴스의 검색 결과를 보고 인스턴스를 삭제할 수 있는 링 크를 제공합니다. 또한 경고의 이름, 앱, 유형(예약, 실시간 또는 롤링 윈도우), 심각도 및 모드(요약 또는 결과별)를 보여줍니다. 경고의 정의 를 편집할 수도 있습니다. 75

89

90 II부 방법

91

92 6 모니터링 및 경고 방법 이 책의 처음 다섯 장에서는 Splunk를 사용하여 새롭고 흥미로운 방식 으로 문제를 해결하고, 질문에 대답하고, 데이터를 탐색하는 방법에 대 해 설명했습니다. 이 장에서는 모니터링 및 경고 방법에 대해 설명합니다. 모니터링은 시 각적으로 모니터링할 수 있는 보고서를 가리키며 경고는 자동으로 작 업을 트리거할 수 있는 Splunk에 의해 모니터링되는 조건을 가리킵니 다. 이 방법들은 일반적인 모니터링 및 경고 문제에 대해 간단한 해결책으 로 사용할 수 있습니다. 각 방법에는 문제 내용과 Splunk를 사용하여 해당 문제를 해결하는 방법을 설명하는 내용이 포함되어 있습니다. 일 부 복잡한 예제를 통해 변형된 방법도 살펴볼 수 있습니다. 질문에 답변하고 추가 답변을 알아보려면 참 조하십시오. 모니터링 방법 모니터링은 데이터에서 무슨 일이 일어나고 있는지 확인하는 데 도움 이 됩니다. 동시 사용자 수가 얼마나 됩니까? 주요 측정값이 시간에 따 라 어떻게 변화하고 있습니까? 다양한 조건을 모니터링하는 방법 외에 이 절에서는 검색 명령어를 사 용하여 반정형화된 데이터와 정형화된 데이터에서 필드를 추출하는 방 법에 대해 설명합니다. 동시 사용자 모니터링 문제 특정 시간대의 동시 사용자를 알아야 합니다. 동시 사용자 수를 알면 일 부 호스트에 과부하가 걸리는지 확인하고 최고 수요를 충족하도록 리 소스를 보다 효율적으로 제공할 수 있습니다. 79

93 Exploring Splunk 해결책 먼저, 검색을 수행하여 관련 이벤트를 검색합니다. 그런 다음 concurrency 명령어를 사용하여 겹치는 사용자의 수를 찾습니다. 마지막으로 timechart 보고 명령어를 사용하여 시간별 동시 사용자 수에 대한 차 트를 표시합니다. 다음 이벤트를 통해 날짜, 시간, 요청 기간 및 사용자 이름을 지정한다 고 가정하겠습니다. 5/10/10 1:00:01 ReqTime=3 User=jsmith 5/10/10 1:00:01 ReqTime=2 User=rtyler 5/10/10 1:00:01 ReqTime=50 User=hjones 5/10/10 1:00:11 ReqTime=2 User=rwilliams 5/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 명령어에 대해 자세히 알아보려면 book#concurrency를 참조하십시오. 비활성 호스트 모니터링 문제 해결책 어느 호스트에서 데이터 송신을 중단했는지 확인해야 합니다. 로그를 생성하는 애플리케이션이나 서버에 장애가 발생하거나 중단된 경우 호 스트에서 이벤트 로깅을 중단할 수 있습니다. 이 경우 종종 심각한 문 제를 나타냅니다. 호스트에서 이벤트 로깅을 중단하는 경우에는 검토 가 필요합니다. Splunk 인덱스의 host, source 및 source type에 대한 상위 수준의 정 보를 제공하는 metadata 명령어를 사용합니다. 이 명령어는 요약 대시 보드를 만드는 데 사용됩니다. Splunk 인덱스에서 이벤트를 검색하는 것이 아니라 metadata 명령어를 호출하기 때문에 이 검색은 파이프 문 자로 시작합니다. 80

94 6장: 모니터링 및 경고 방법 다음 검색을 사용하여 호스트에 대한 정보를 가져와서 가장 최근에 참 조된 호스트가 먼저 오도록 정렬하고, 판독할 수 있는 시간 형식으로 표시합니다. metadata type=hosts sort recenttime convert ctime(recenttime) as Latest_Time 어느 호스트에서 최근에 데이터를 로깅하지 않았는지 바로 표시됩니 다. metadata 명령어에 대해 자세히 알아보려면 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 81

95 Exploring Splunk 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을 사용하여 결과의 형식을 지정합니다. 82

96 6장: 모니터링 및 경고 방법 월간 순위 가져오기 다음 검색을 사용하여 상위 10개의 아티스트별 최대 판매량을 찾습니다. sourcetype=music_sales 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 MonthRank는 첫 번째 결과 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 83

97 Exploring Splunk 출력 형식 지정 요약 변형 마지막으로 월간 순위와 일일 순위 간의 차이를 계산하고, 일일 순위를 기준으로 결과를 정렬하고, 음악 빌보드 순서(순위, 아티스트, 순위 변 동, 과거 순위)로 필드를 표시합니다. eval diff=monthrank-dayrank sort DayRank table DayRank, artist, diff, MonthRank 모든 명령을 종합하면 검색은 다음과 같은 모양이 됩니다. sourcetype=music_sales stats sum(sales) as month_sales by artist sort 10 - month_sales streamstats count as MonthRank 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 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 명령어에 대해 자세히 알아보려면 book#streamstats를 참조하십시오. 1시간에 10% 감소한 측정값 찾기 문제 지난 시간 동안 10% 감소한 측정값을 확인하려고 합니다. 이는 고객 감 소, 웹 페이지 보기 감소, 데이터 패킷 감소 등을 의미할 수 있습니다. 84

98 6장: 모니터링 및 경고 방법 해결책 변형 지난 시간 동안 감소했는지를 보려면 지난 2시간 동안의 결과를 살펴봐 야 합니다. 두 시간 동안의 이벤트를 보고 각 시간의 측정값을 따로 계 산한 다음 두 시간 사이에 측정값이 얼마나 변화했는지 확인하겠습니 다. 여기서 확인하는 측정값은 두 시간 전과 지난 시간 사이의 이벤트 수입니다. 다음 검색에서는 이전 시간의 호스트별 개수를 현재 시간과 비교하고 개수가 10% 이상 감소한 경우를 필터링합니다. stats count by date_hour,host stats first(count) as previous, last(count) as current by host where current/previous < 0.9 첫 번째 정시에 맞춰(오후 2:01-4:01이 아니라 오후 2-4시) 두 시간 분량의 데이터를 검색합니다. 그런 다음 시간별 및 호스트별 이벤트 수를 계산합니다. 두 시간(두 시간 전 과 한 시간 전)만 있기 때문에 stats first(count)에서는 두 시간 전의 개수를 반환하고 last(count)에서는 한 시간 전의 개수를 반환합니다. where 절은 현재 시간의 개수가 이전 시간의 개수보다 90% 미만인(즉, 10% 이상 감소를 보여주는) 이벤트만을 반환합니다. 한 가지 연습으로서 시간 범위가 자정을 넘을 경우 이 검색에 어떤 문 제가 생기는지 생각해 보십시오. 첫 번째 stats 명령어에 first(_time) 을 추가하고 새 값을 기준으로 정렬하여 문제를 수정하는 방법을 알고 계십니까? 이벤트의 수 대신 평균 지연 시간이나 초당 최소 바이트 수 등 다른 측 정값을 사용하고 일별 등과 같은 다른 시간 범위도 고려해 보십시오. 주간 결과를 차트로 작성 문제 해결책 이번 주의 결과를 지난 주와 비교해야 합니다. 먼저 모든 이벤트에 대해 검색을 실행하고 이벤트가 이번 주 또는 지난 주에 속하는지 표시합니다. 그런 다음 지난 주 이벤트의 시간 값을 이 번 주의 이벤트처럼 보이도록 (그래서 그래프가 동일한 시간 범위에 겹 쳐 표시되도록) 조정합니다. 마지막으로 차트를 만듭니다. 다음과 같이 해당 주의 처음부터 시작하여 지난 두 주의 결과를 가져 오겠습니다. 85

99 Exploring Splunk 변형 이벤트를 지난 주 또는 이번 주의 이벤트로 표시합니다. 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로 변경하여 주 경계에 딱 떨어지지 않고 걸치도록 해보십시오. 데이터의 급등 부분 식별 문제 데이터에서 급등 부분을 찾으려고 합니다. 급등 부분을 보면 일부 측정 값의 급격한 증가 또는 감소를 나타내는 최고점(또는 최저점)이 어디인 지를 알 수 있습니다. 트래픽 급등, 판매 급등, 반품 수 급등, 데이터베 이스 로드 급등 등 주의를 기울이고 있는 급등 현상을 지켜본 다음 적 절한 조치를 취해야 합니다. 86

100 6장: 모니터링 및 경고 방법 해결책 변형 이동 추세선을 사용하면 급등 부분을 찾는 데 도움이 됩니다. 검색을 실행하고 추세선을 만들려고 하는 필드를 사용하여 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 검색 명령어에 대해 자세히 알아보려면 book#trendline를 참조하십시오. 87

101 Exploring Splunk 시간 기반 차트 압축 문제 해결책 변형 데이터의 여러 추세를 작은 공간에 시각화하려고 합니다. 이러한 경우 스파크라인(결과 테이블의 셀 내에 표시되는 작은 시간 기반 차트)을 사용할 수 있습니다. 스파크라인은 Edward Tufte에 의해 개발되었으며 Splunk 4.3에 적용했습니다. 테이블에 스파크라인을 생성하려면 stats 또는 chart 함수를 sparkline() 함수로 둘러싸면 됩니다. 여기서는 웹 액세스 로그의 예를 사용합니다. 각 웹 페이지가 반응하는 데 걸리는 시간을 보여주는 작은 그래프를 만들려고 합니다(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 88

102 6장: 모니터링 및 경고 방법 변형 path 인수 없이 호출하면 spath는 처음 5000자(설정 가능) 내의 모든 필 드를 추출하고 각 경로 요소에 대해 필드를 만듭니다. 경로는 foo.bar. baz와 같은 형태가 됩니다. 각 레벨에 중괄호(예: foo{1}.bar)로 표시되 는 어레이 인덱스(선택사항)를 포함할 수 있습니다. 모든 어레이 인수 는 빈 중괄호(예: foo{})로 표시할 수 있습니다. XML 쿼리의 마지막 레 벨에는 중괄호(예: 앞에 붙은 속성 이름을 포함할 수도 있습니다. 필드를 추출한 후 필드에 대해 보고할 수 있습니다.... 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= : 89

103 Exploring Splunk 변형 결과는 예상한 대로 다음과 같이 나옵니다. 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시간 90

104 6장: 모니터링 및 경고 방법 변형 경고 조건과 작업 빈도를 변경합니다. 웹 서버 성능이 느려질 경우 경고 발생 문제 해결책 웹 서버의 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<

105 Exploring Splunk 다음과 같이 경고를 설정합니다. 경고 조건: 검색 결과가 X개(경고가 발생하도록 설정하고 싶은 호 스트 수) 이상 반환될 때 경고 발생. 경고 작업: 부하 분산 장치로부터 해당 서버를 제거하고 서버를 종 료시키는 스크립트를 트리거합니다. 작업 빈도: 10분 모니터링을 경고로 변환 이 장에서 소개하는 모니터링 방법은 보고서 작업에 유용한 내용들입 니다. 경고 설정 기본사항들을 숙지하면 Splunk를 통해 상황을 모니터 링하는 것이 훨씬 수월해집니다. 여기서는 모니터링을 경고로 변환하는 몇 가지 방법을 간략하게 살펴 보겠습니다. 동시 사용자 모니터링 이 방법은 사용자 지정 경고 조건을 where max(concurrency) > 20 으 로 설정해서 검색하면 경고로 변환됩니다. 이 경고는 너무 많은 사용자 가 동시에 로그인할 때 발생됩니다. 변형: 평균 동시 사용자 수를 계산해서 최대값이 평균의 2배일 경우 경 고. 비활성 호스트 모니터링 where now() - recenttime > 60*60으로 경고 조건을 사용자 지정하 면 한 시간 이상 동안 호스트에 수신되는 요청이 없을 경우 경고가 발 생합니다. 오늘의 최대값과 지난 달의 최대값 비교 where diff < -10으로 경고 조건을 사용자 지정하면 아티스트가 지난 달에는 상위 10위 안에 들지 않았는데 오늘 1위를 한 경우 경고가 발 생됩니다. 변형: 이와 동일한 방법으로 HTTP 상태 코드를 모니터링하여 지난 달 과 비교해 상태 코드(예: 404)가 갑자기 많아지거나 적어지는 경우 이 를 보고합니다. 1시간에 10% 감소한 측정값 찾기 이 방법은 경고를 다루면서 이미 알맞게 설정하였습니다. 이떤 이벤트 가 보일 경우 경고가 발생됩니다. 변형: N 이상의 감소세가 연이어 보일 경우에만 경고가 발생됩니다. 92

106 6장: 모니터링 및 경고 방법 이동 추세선 표시 및 급등 부분 식별 이 방법은 경고를 다루면서 이미 알맞게 설정하였습니다. 이떤 이벤트 가 보일 경우 경고가 발생됩니다. 변형: 일정한 시간 동안(예: 5분)에 N개 이상의 급등 부분이 보일 경우 에만 경고가 발생합니다. 나머지 모니터링 방법을 연습삼아 경고 작업을 해보시기 바랍니 다. 93

107

108 7 이벤트 그룹화 소개 다음의 방법들은 이벤트를 그룹화하면 해결될 수 있는 실제 흔히 접할 수 있는 몇 가지 문제들에 대한 빠른 해결책입니다. 이벤트를 그룹화하는 방법은 여러 가지가 있습니다. 그 중 가장 일반 적인 방법은 transaction 또는 stats 명령어를 사용하는 것입니다. 그 렇다면 어떤 경우에 transaction을 사용하고, 어떤 경우에 stats를 사 용할까요? 기본적으로 stats를 사용할 수 있다면 stats를 사용하십시오. 특히 분 산된 환경에서 transaction보다 훨씬 빠릅니다. 하지만 속도가 빠른 반 면 일부 제약이 있습니다. 이벤트가 최소 하나 이상의 공통 필드 값을 가지고 있고, 다른 어떤 제약 조건도 필요 없는 경우에만 stats로 이 벤트를 그룹화할 수 있습니다. 일반적으로 원시 이벤트 텍스트는 무시 됩니다. stats와 마찬가지로 transaction 명령어도 공통 필드 값을 기반으로 이벤트를 그룹화합니다. 하지만 다른 점은 트랜잭션의 총 시간 범위, 해당 트랜잭션 내에서 이벤트 간 지연, 시작/종료 필수 이벤트와 같은 보다 복잡한 제약 조건을 사용할 수 있다는 점입니다. stats와 달리 transaction은 원시 이벤트 텍스트와 원래 이벤트의 필드 값을 유지합 니다. 하지만 duration(트랜잭션에서 가장 오래된 이벤트와 가장 최신 이벤트 간의 _time 필드 델타 값)과 eventcount(트랜잭션의 전체 이벤 트 수)를 제외한, 그룹화된 이벤트들에 대한 다른 모든 통계값은 계산 하지 않습니다. transaction 명령어는 다음 두 가지 상황에서 가장 유용합니다. 서로 다른 트랜잭션들을 구분하는 데 고유 필드 값(식별자라고도 함)만으로는 충분하지 않은 경우. 이 경우는 예를 들면, 웹 세션을 식별하는데 cookie나 clientip를 사용하는 경우와 같이 식별자가 재사용될 수 있는 경우를 말합니다. 이 경우 트랜잭션을 만들기 위 해서 timespan이나 pause 등을 사용해야 합니다. 또 DHCP 로그에 서와 같이 식별자가 재사용되는 경우, 시작하고 끝 맺는 특정 메시 지를 이용하여 트랜잭션을 식별할 수도 있습니다. 이벤트의 구성 필드에 대한 분석이 아닌, 이벤트의 원시 텍스트를 보는 것이 더 바람직한 경우. 95

109 Exploring Splunk 다시 말해서, 이 두 경우 중 어떤 경우도 해당되지 않을 경우에는 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= 여기서 우리는 sourcetype=x의 모든 이벤트를 검색하려고 합니다. 이 검색 명령어는 트랜잭션을 만든 후 ip= 를 가지고 있지 않은 모 든 이벤트는 버립니다. 모든 이벤트가 동일한 ip 값을 가지고 있는 경 우 이 검색은 다음과 같이 바꿀 수 있습니다. sourcetype=x ip= transaction field=ip maxpause=15s 이 검색은 필요한 이벤트만 검색하기 때문에 훨씬 효율적입니다. 이에 대한 자세한 내용은 나중에 나오는 이 장의 "특정 트랜잭션 찾기"를 참 조하십시오. 96

110 7장: 이벤트 그룹화 방법 필드 이름 통합 문제 해결책 변형 동일한 식별자에 대해 서로 다른 필드 이름을 사용하는 여러 데이터 소 스로부터 트랜잭션을 작성해야 합니다. 일반적으로 다음과 같은 공통 필드로 트랜잭션을 조인할 수 있습니다. 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 함수가 도움이 될 수 있습니다. 불완전한 트랜잭션 찾기 문제 로그인은 했지만 로그아웃하지 않은 사용자와 같이 불완전한 트랜잭션 에 대해 보고해야 합니다. 97

111 Exploring Splunk 해결책 변형 로그인으로 시작해서 로그아웃으로 끝난 사용자 세션을 검색한다고 가 정해 보겠습니다. 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 98

112 7장: 이벤트 그룹화 그런 다음, 각 userid에 대해 stats를 사용하여 userid당 보여지는 action을 추적합니다. 이벤트는 시간 역순으로 정렬되므로 맨 위에 나오 는 작업이 가장 최근 작업입니다. 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 함수가 있습니다. 99

113 Exploring Splunk 변형 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) 최신 이벤트 찾기 문제 고유한 각 필드 값의 최신 이벤트를 찾아야 합니다. 예를 들면, 각 사용 자가 로그인한 마지막 시간이 언제인지 알아야 하는 경우가 될 수 있 습니다. 100

114 7장: 이벤트 그룹화 해결책 변형 아마 처음에는 transaction 또는 stats 명령어를 사용하려는 생각이 들 것입니다. 예를 들어, 이 검색은 다음과 같이 각 필드 첫 번째 값으 로 표시될 고유한 userid를 각각 반환합니다. stats first(*) by userid 이 검색은 동일한 userid를 가지는 이벤트에 해당하는 각 필드의 첫 번 째 값을 반환한다는 점에 유의해야 합니다. 즉, 해당 user ID를 가지는 모든 이벤트 집합을 제공합니다. 이것은 우리가 원하던 결과가 아닙니 다. 우리가 여기서 원하는 결과는 고유한 userid의 첫 번째 이벤트입니 다. 이 값을 얻으려면 dedup 명령어를 사용하면 됩니다. dedup userid 고유한 userid의 가장 오래된(최신이 아님) 이벤트를 얻고 싶다면 dedup 명령어의 sortby 절을 사용합니다. dedup userid sortby + _time 반복 이벤트 찾기 문제 해결책 보고서와 경고에서 무의미한 정보를 제거하기 위해 반복적으로 발생하 는 값을 가진 이벤트를 모두 그룹화하려고 합니다. 다음과 같은 이벤트를 가지고 있다고 가정합니다 :45:23 code= :45:25 code= :45:26 code= :45:27 code= :45:28 code= :45:29 code= :45:30 code= :45:32 code= :45:33 code= :45:35 code= :45:36 code=-1 목표는 7개 이벤트를 얻는 것입니다. 각기 하나의 코드 값이 있습니다. 239, 773, -1, 292, -1, 444, -1. 다음과 같이 transaction 명령어를 사용 하려고 시도할 수도 있습니다. transaction code 101

115 Exploring Splunk 그러나 여기서 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=x T2: start=10:10 end=10:20 clientip=a cookie=x 이 두 트랜잭션 간의 시간 차이는 T1 시작 시간(10:30)과 T2 종료 시간 (10:20)의 차이를 말합니다. 나머지 방법은 이러한 값을 계산하는 방법 을 설명합니다. 먼저, 각 트랜잭션의 종료 시간을 계산해야 합니다. 트랜잭션의 타임 스탬프는 첫 번째 이벤트가 발생한 시간이고, duration은 트랜잭션 내 에서 첫 번째 이벤트와 마지막 이벤트 사이에 경과된 시간(초)을 말합 니다. eval end_time = _time + duration 102

116 7장: 이벤트 그룹화 그 다음에는 이전(예를 들어, 더 최근) 트랜잭션의 시작 시간을 각 트랜 잭션에 더해야 합니다. 이렇게 하면 이전 트랜잭션의 시작 시간과 우리 가 계산한 end_time 사이의 차이를 계산할 수 있습니다. 이렇게 계산하려면, streamstats를 사용하여 변동하는 하나의 트랜잭 션의 간격(global=false and window=1)에서 보여지는 시작 시간(_time) 의 마지막 값을 계산하고, 변동 간격(current=false)의 현재 이벤트는 무시하십시오. 효과적으로 하기 위해 streamstats를 사용해 이전 이벤 트 값만 확인합니다. 마지막으로 이 윈도우는 지정된 사용자(clientipcookie 쌍)에만 적용할 수 있다는 점에 유의해야 합니다. 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 103

117 Exploring Splunk 변형 요구사항이 단순해 질수록 더 간단하게 이벤트 간 차이를 계산할 수 있습니다. 트랜잭션의 유일한 제약 조건이 startswith 및 endswith 인 경우, 즉, 시간 제약 조건(예: maxpause=10m) 또는 필드(예: clientip, 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= _logs transaction userid 104

118 7장: 이벤트 그룹화 하지만 우리는 지금 필드/값 쌍인 to=root와 from=msmith를 가진 이벤 트가 있는 트랜잭션만 식별하려고 합니다. 다음 검색을 사용할 수 있 습니다. sourcetype= _logs transaction userid search to=root from=msmith 이 경우 문제점은 이 sourcetype에서 발생하는 모든 이벤트(수십억 개 가 넘을 수도 있음)를 검색하게 되고, 모든 트랜잭션을 작성한 후에 그 데이터의 99%가 결국 휴지통으로 간다는 점입니다. 이것은 느릴 뿐만 아니라 비효율적인 작업입니다. 그래서 다음과 같이 수신 데이터를 줄이려고 시도할 수도 있습니다. sourcetype= _logs (to=root OR from=msmith) transaction userid search to=root from=msmith 이렇게 하면 지정된 sourcetype에서 발생하는 이벤트를 모두 비효율적 으로 검색하지는 않지만, 이 경우에는 또 다른 두 가지 문제점이 발생 합니다. 첫 번째 문제점은 치명적입니다. 즉, 문제를 해결하는 데 필요 한 이벤트 중에서 일부만 검색된다는 점입니다. 특히, to 또는 from 필 드를 가진 이벤트만 검색하게 됩니다. 이 구문을 사용하면 트랜잭션을 구성하는 다른 모든 이벤트는 누락됩니다. 예를 들어, 전체 트랜잭션이 다음과 같다고 가정하겠습니다. [1] 10/15/ :11:12 userid=123 to=root [2] 10/15/ :11:13 userid=123 from=msmith [3] 10/15/ :11:14 userid=123 subject= serious error [4] 10/15/ :11:15 userid=123 server=mailserver [5] 10/15/ :11:16 userid=123 priority=high 위와 같이 검색하면 subject를 가진 event3 또는 server를 가진 event4 가 누락됩니다. 따라서 완전한 트랜잭션을 반환할 수 없습니다. 두 번째 문제점은 to=root는 매우 흔해서 실제로 너무 많은 이벤트가 검색되어 엄청난 트랜잭션을 작성하게 된다는 점입니다. 그럼 다른 해결책이 있을까요? 두 가지 방법이 있습니다. 하위 검색을 사용하는 방법과 searchtxn 명령어를 사용하는 방법이 있습니다. 105

119 Exploring Splunk 하위 검색 사용 지금 원하는 것은 to=root 또는 from=msmith를 가진 이벤트의 모든 userid 값을 가져오는 것입니다. 최대한 신속하게 후보 userid 값을 가 져올 수 있는 더 흔치 않은 조건을 선택합니다. from=msmith는 더 흔치 않다고 가정하겠습니다. sourcetype= _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= _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 _txn to=root from=msmith 106

120 7장: 이벤트 그룹화 변형 그런데 위의 검색에서 _txn은 무엇일까요? 그것은 Splunk 구성 파일(transactiontype.conf)에 반드시 있어야 하는 트랜잭션 유형의 정의입니다. 이 경우 transactiontype.conf는 다음과 같습니다. [ _txn] fields=userid search = sourcetype= _logs searchtxn 검색을 실행하면 자동으로 다음 검색이 실행됩니다. sourcetype= _logs from=msmith dedup userid 이 검색의 결과는 운영을 위해 userids 리스트를 searchtxn에 제공합 니다. 그런 다음 또 다른 검색을 실행합니다. sourcetype= _logs (userid=123 OR userid=369 OR userid=576...) transaction name= _txn search to=root from=msmith 이 검색은 searchtxn 검색의 반환 결과에서 "건초 더미 속 바늘"과 같 은 트랜잭션을 반환합니다. 참고: transaction 명령어 필드 리스트에 둘 이상의 필드가 있는 경우, searchtxn은 여러 검색을 자동으로 실행해서 필요한 모든 값에 대한 전 이 폐쇄를 가져옵니다. searchtxn 명령어로 여러 필드를 탐색해 봅니다. 관련 이벤트를 가져오 는 데 관심이 있고, 트랜잭션을 실제 작성하는 데 searchtxn을 원하지 않는 경우에는 eventsonly=true를 사용합니다. 다른 이벤트와 가까이 있는 이벤트 찾기 문제 해결책 이벤트 전 후의 다른 이벤트를 찾아야 합니다. 루트별 로그인을 검색한 후, 실패한 루트 로그인에 대해 최대 1분까지 뒤로 검색을 하고, 암호 변경을 위해 최대 1분까지 앞으로 검색합니다. 한 가지 해법은 하위 검색을 사용하고 이 시나리오의 최종 인스턴스를 찾는 것입니다. 루트 로그인을 하위 검색하고 starttimeu 및 endtimeu 를 반환합니다. 이것은 동일한 src_ip에서 failed_login 또는 pass- 107

121 Exploring Splunk 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개 이벤트 확인이 필요한데, 제대로 정의된 종료 이벤트가 없습니다. 108

122 7장: 이벤트 그룹화 해결책 다음과 같이 로그인 작업으로 시작하는 이상적인 트랜잭션이 있다고 가정해 보겠습니다. [1] 10:11:12 src_ip= user=root action=login [2] 10:11:13 src_ip= user=root action= cd / [3] 10:11:14 src_ip= user=root action= rm -rf * [4] 10:11:15 src_ip= 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 필드를 추가합니다. 이렇게 해야 그 다음에 트랜잭션을 추가 필터링할 수 있습니다. 그룹 그룹화 문제 트랜잭션 내에서 값을 변경하는 여러 필드로 트랜잭션을 작성해야 합 니다. 109

123 Exploring Splunk 해결책 다음과 같이 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는 이벤트의 정확한 수가 아니라, 결 합한 트랜잭션 수가 됩니다. 110

124 7장: 이벤트 그룹화 첫 번째 transaction 명령 이후에 정확한 eventcount를 얻으려면 mycount라고 하는 필드를 만들어서 모든 eventcount 값을 저장하고 난 후에, 두 번째 transaction 명령 다음에 모든 mycount 값을 합산해서 real_eventcount를 계산해야 합니다. 마찬가지로 1차 transaction 명 령 후에 각 트랜잭션의 시작 및 종료 시간을 기록한 후 2차 transaction 명령 다음에 최소 시작 시간과 최대 종료 시간을 구한 후 real_duration를 계산합니다. 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) 111

125

126 8 룩업 테이블 소개 lookup 이 룩업 테이블 사용법은 실무에서 접하는 공통적인 문제점에 대한 고 급 해결책을 간략하게 소개합니다. Splunk의 룩업 기능을 사용하면 이 벤트 데이터의 필드와 일치하는 필드를 외부 CSV 파일에서 참조할 수 있습니다. 이러한 일치 기능을 사용해 추가 필드로 이벤트 데이터를 강 화할 수 있습니다. 참고로 여기서는 외부 스크립트 룩업 또는 시간 기 반 룩업은 다루지 않습니다. 이 사용법에서는 lookup, inputlookup, outputlookup 등과 같은 세 개의 룩업 검색 명령어를 광범위하게 사용합니다. 이 명령어는 각 이벤트에 대해 외부 CSV 테이블의 행과 일치하는 항목 을 찾아내 다른 컬럼 값을 반환하면서 이벤트를 강화합니다. 예를 들어, lookup mylookup host라는 명령어는 (host 및 machine_type 컬럼을 가진) 룩업 테이블과 host 필드 값이 있는 이벤트를 매핑하여 host 값 에 해당하는 machine_type 값을 각 이벤트에 추가합니다. 기본적으로 일치 작업은 대소문자를 구분하며 와일드카드 문자는 지원하지 않지만 이러한 옵션을 구성할 수는 있습니다. lookup 명령은 외부 테이블의 값 과 명확하게 값을 일치시킵니다. Splunk 관리자를 사용하여 설정된 자 동 룩업 기능은 암시적으로 값을 일치시킵니다. 자동 룩업 구성에 대한 자세한 내용은 참조하십시오. inputlookup 이 명령어는 전체 룩업 테이블을 검색 결과로 반환합니다. 예를 들어, inputlookup mylookup은 테이블 mylookup의 각 행에 대해 검색 결 과를 반환합니다. 여기에는 두 개의 host 및 machine_type 필드 값이 있습니다. 113

127 Exploring Splunk outputlookup 룩업 테이블을 만드는 방법에 대해 궁금해할 수도 있습니다. 이 명령어 는 디스크의 룩업 테이블에 대한 현재 검색 결과를 출력합니다. 예를 들어, outputlookup mytable.csv saves는 모든 결과를 mytable. csv에 저장합니다. 추가 정보 방법 기본 룩업 값 설정 문제 해결책 이벤트의 값이 룩업 테이블에 없는 경우에는 기본값을 지정하고 싶습니다. 몇 가지 해결책이 있습니다. 명시적 lookup 명령어를 이용하여 다음과 같은 간단한 eval coalesce 를 사용할 수 있습니다. lookup mylookup ip eval domain=coalesce(domain, unkno wn ) 자동 룩업 기능을 사용하기 위한 설정도 있습니다. 관리자 >> 룩업 >> 룩업 정의 >> mylookup으로 이동하여 고급 옵션 체크박스를 선택하 고 다음과 같이 변경합니다. 최소 일치 항목 수 설정: 1 기본 일치 항목 수 설정: 알 수 없음 변경 사항을 저장합니다. 역방향 룩업 사용 문제 룩업 테이블 출력 자료를 기반으로 이벤트 검색이 필요합니다. 114

128 8장: 룩업 테이블 해결책 Splunk에서는 역방향 룩업 검색을 사용하여 자동 룩업의 출력값을 검 색할 수 있으며, 이 출력값을 룩업의 해당 입력 필드에 대한 검색으로 변환할 수 있습니다. 예를 들어, machine_name을 owner에 매핑하는 룩업 테이블이 있다고 가 정해 보겠습니다. machine_name, owner webserver1,erik dbserver7,stephen dbserver8,amrit 이벤트에 machine_name 필드가 있고, 특정 owner인 erik를 검색하고 싶 다면 아래와 같이 비효율적인 검색을 사용할 수도 있습니다. lookup mylookup machine_name search owner=erik 이 검색은 모든 이벤트를 검색하고, owner가 erik이 아닌 모든 값을 필 터링해야 하므로 매우 비효율적입니다. 반대로, 효율적이지만 까다로운 하위 검색 방법도 있습니다. [ inputlookup mylookup search owner=erik fields machine_name] 이 검색은 룩업 테이블의 모든 행을 검색하고, owner가 erik이 아닌 모 든 행을 필터링하여 제외한 후, Splunk가 최종적으로 검색할 장황한 시 스템 이름 OR 표현식을 반환합니다. 하지만 이중 어떤 것도 필요하지 않습니다. 자동 룩업 테이블을 설정했 으면 Splunk에서 간단히 owner=erik를 검색할 수 있습니다. 아주 간단합니다. 효과적인 검색을 위해 Splunk는 보이지 않는 곳에서 하위 검색 솔루션을 사용해 OR 절 검색을 만듭니다. 참고: Splunk에서는 정의된 필드 추출, 태그 및 eventtype에 대한 자동 역방향 검색이 가능합니다.사용자는 추출된 값, 태그를 지정한 값, 유형이 지정된 값을 검색할 수 있고, Splunk는 이를 통해 정확한 이벤트를 검색합니다. 변형 자동 룩업 기능과 내장된 역방향 룩업 기능을 사용하여 Splunk의 태깅 시스템을 재생성할 수 있습니다. 예를 들어, host에서 host_tag라는 필 드에 매핑합니다. 이제 host 값뿐만 아니라, host_tag에 기반하여 이벤 트를 검색할 수 있습니다. 많은 사람들이 Splunk 태그보다 룩업 테이블 을 유지하는 것이 더 쉽다고 알고 있습니다. 115

129 Exploring Splunk 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 흥미로운 점은 이와 같은 연속 구조가 자동으로 발생되는 자동 룩업을 사용할 수 있다는 점입니다. 그러나 반드시 속성 이름을 영숫자순으로 사용하여 올바른 순서대로 룩업을 사용해야 합니다. 116

130 8장: 룩업 테이블 관리자 >> 룩업 >> 자동 룩업으로 이동하여 두 개의 자동 룩업을 만 듭니다. 나중에 실행하는 룩업은 이전 룩업 이름보다 더 큰 값으로, 이 름이 지정된 값을 가져야 합니다. 예: 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분마다 작업을 실행하거나 새 로운 사용자로 룩업 테이블을 업데이트하려고 시도할 수도 있습니다. 117

131 Exploring Splunk 해결책 변형 기본적인 절차는 룩업 테이블에 추가하려는 결과 세트를 가져오고, inputlookup을 사용해 현재의 룩업 내용을 추가하고, 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이 반드시 유지되어야 합 니다. 대용량 룩업 테이블 사용 문제 대용량 룩업 테이블이 있지만 빠른 성능을 원합니다. 118

132 8장: 룩업 테이블 해결책 성능에 영향을 미칠 수 있는 매우 큰 대용량 룩업 테이블의 경우 몇 가 지 해결책이 있습니다. 먼저, 특정 룩업 테이블을 좀 더 적은 용량으로 만들 수 있는지 여부를 파악합니다. 예를 들어, 행과 컬럼의 하위집합만 검색 시 필요한 경우에 는 이러한 검색을 위해 축약된 버전의 룩업을 만드십시오. 다음 검색은 몇 가지 조건(중복 제거, 필요한 입력, 출력 필드만 남기고 모든 컬럼 제 거, 마지막으로 결과를 mylookup2 테이블에 작성)을 충족하는 룩업 테 일블의 행을 줄여서 mylookup 테이블 크기를 줄였습니다. inputlookup mylookup search somecondition dedup someinputfield table someinputfield, someoutputfield outputlookup mylookup2 룩업 테이블의 크기를 줄일 수 없는 경우에는 다른 해결책이 있습니 다. Splunk 설치에 몇 가지 인덱서가 포함된 경우, 해당 인덱서가 자동 으로 룩업 테이블을 복제합니다. 하지만 룩업 파일이 대용량 파일(예: 100MB)일 경우 시간이 많이 소요됩니다. 한가지 해결책은 번들이 자주 업데이트될 경우, 번들 복제를 비활성화 하고, 대신 NFS를 사용하여 번들을 모든 노드에 사용할 수 있도록 하 는 것입니다. 참조: 또 다른 해결책으로, 룩업 테이블이 자주 변경되지 않고 장착된 공유 드 라이브에 의존할 수 없는 경우 로컬 룩업을 사용하면 됩니다. 룩업이 복제 및 분산되는 것을 막으려면 룩업 테이블을 distsearch.conf의 replicationblacklist에 추가합니다. (자세한 내 용 참조: 룩업 테이블 CSV 파일을 다음의 각 인덱서에 복사합니다. $SPLUNK_HOME/etc/system/lookup 검색을 실행할 때 lookup 검색 명령어에 local=true 옵션을 추가 합니다. 참고: 룩업에 대한 정의는 props.conf를 통하여 암묵적으로 실행되도록 정의되어야 하는데, 이것은 룩업의 속성상 로컬이 아니라 인덱스에 분산되어 있어야 하기 때문입니다. 마지막으로, 대용량 CSV파일을 사용하기보다는 외부 룩업(일반적으로 데이터베이스를 조회하는 스크립트 활용)을 고려해 보십시오. 119

133 Exploring Splunk 참고:.csv 룩업 테이블 크기가 10MB(기본 크기)에 다다르면 빠른 액세스를 위해 Splunk는 해당 룩업 테이블을 인덱스합니다. 이렇게.csv 파일을 인덱스함으로써 Splunk는 테이블을 스캔하는 대신 검색을 수행하게 됩니다. 파일이 인덱스되기 전에 크기를 편집하려면 limits.conf의 룩업 스탠자를 편집하고 max_memtable_bytes 값을 변경합니다. 룩업 값과 결과 비교 문제 해결책 변형 I 룩업 리스트 값과 이벤트 리스트 값을 비교하고 싶습니다. 예를 들어, IP 주소를 가진 룩업 테이블이 있는데, 지금 데이터에 어떤 IP 주소가 발생했는지 알고 싶은 경우입니다. 특정 필드 값을 가진 이벤트들의 수가 적은 경우, 하위 검색을 사용하 여 효율적으로 관련 이벤트를 찾을 수 있습니다. 하위 검색에서 inputlookup을 사용하여 룩업 테이블에 표시된 모든 값에 대해 대규모 OR 검색을 만듭니다. 하위 검색으로 반환된 리스트 크기는 10,000개까지 가능합니다(제한량은 limits.conf에서 수정가능). yoursearch [ inputlookup mylookup fields ip ] 결과적으로 실행되는 검색은 다음과 유사합니다. yoursearch AND ( ip= OR ip= OR... ) 하위 검색 안에 있는 검색을 실행하고, format 명령어를 붙이면 하위 검 색에서 반환된 결과를 테스트할 수 있습니다. inputlookup mylookup fields ip format 참조: 유사한 방식으로 룩업 테이블에 없는 값을 가진 이벤트를 검색하려면 다음과 같은 패턴을 사용합니다. yoursearch NOT [ inputlookup mylookup fields ip ] 이 패턴을 사용한 검색은 다음과 같습니다. yoursearch AND NOT ( ip= OR ip= OR... ) 120

134 8장: 룩업 테이블 변형 II 변형 III 반대로, 데이터에서 일치되지 않는 룩업 테이블 값을 원할 경우에는 다 음을 사용합니다. inputlookup mylookup fields ip search NOT [ search yoursearch dedup ip fields ip ] 이것은 룩업 테이블에 있는 모든 값에 대해서 데이터와 일치하는 값을 필터링하여 제외합니다. 대용량 리스트의 경우, 룩업 테이블에도 있는 이벤트의 모든 값을 검색 하는 효율적인 검색 패턴이 있습니다. 이 검색 패턴은 이벤트를 검색한 후 전체 룩업 테이블을 해당 이벤트에 추가합니다. 필드(예: 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을 결합해 장시간에 걸친 룩업 테이블을 점차적으로 업데이트합니다. 이렇게 함으로써 가 장 최근 상태를 볼 수 있는 매우 빠른 리소스가 제공됩니다. 자세한 내 용은 "룩업 테이블에 결과 추가" 방법을 참조하십시오. 121

135 Exploring Splunk 룩업 일치 항목 제어 문제 해결책 변형 IP 일치 문제 해결책 정해진 조합의 입력 필드에 대해 룩업 테이블 상에 여러 항목이 있고, 이 중 일치하는 첫 번째 값을 원합니다. 예를 들어, 룩업 테이블은 여 러 호스트 별칭에 호스트 이름을 매핑시키고, 첫 번째 별칭을 원하는 경우입니다. 기본적으로 Splunk는 시간 요소와 관련 없는 룩업에 대해 최대 100개의 일치 항목을 반환합니다. 하나만 반환하도록 업데이트할 수 있습니다. UI를 사용하여 업데이트하려면 관리자 >> 룩업 >> 룩업 정의로 이동 하여 룩업 정의를 편집하거나 만듭니다. 고급 옵션 체크박스를 선택하 고 최대 일치 항목 수에 1을 입력합니다. 또한 해당되는 transforms.conf를 편집할 수 있습니다. 룩업 스탠자에 max_matches=1을 추가합니다. 참조: 룩업 테이블에 제거하고 싶은 중복 항목이 있는 경우 다음과 유사한 검 색으로 이를 정리할 수 있습니다 inputlookup mylookup dedup host outputlookup mylookup 이렇게 하면 해당 파일에서 첫 번째 나타나는 각 호스트를 제외하고 모 두 제거됩니다. 일치시키고 싶은 IP 주소 범위의 룩업 테이블을 가지고 있습니다. 이벤트에 IP 주소가 있고 IP 범위와 ISP가 있는 테이블이 있다고 가정 하겠습니다. network_range, isp /19, isp_name /19, isp_name2... 사용자는 룩업을 위해 match_type을 지정할 수 있습니다. 단, 이 기능 은 UI 메뉴로는 지정할 수 없고, transforms.conf 구성 파일에서 설정 해야 합니다. 122

136 8장: 룩업 테이블 변형 network_range에 대해 match_type을 CIDR로 설정합니다. transforms.conf에서 다음을 설정합니다. [mylookup] match_type = CIDR(network_range) 참조: 가능한 match_type 값은 WILDCARD, CIDR 및 EXACT입니다. EXACT가 기본 값으로 지정되어 있습니다. 또한 조회할 때 대소문자를 구분할지 여부를 transforms.conf 파일에 지정할 수 있습니다(기본적으로 대소문자 구분). 일치시킬 때 대소문자 를 구분하려면 다음 구문을 사용하십시오. case_sensitive_match = False Matching with Wildcards 문제 해결책 룩업 테이블에 일치하는 와일드카드가 필요합니다. 일치시키고 싶은 URL이 있는 룩업 테이블이 있다고 가정해 보겠습니 다. url, allowed *.google.com/*, True False */img/*jpg, False 룩업 테이블 값에 와일드카드(*) 문자를 삽입하여, Splunk에서 와일드 카드에 일치하는 검색을 수행할 수 있습니다. "IP 일치" 방법에서 설명한 바와 같이 transforms.conf 구성 파일에서 조회를 위해 match_type을 지정할 수 있습니다. [mylookup] match_type = WILDCARD(url) 123

137 Exploring Splunk 참고: 기본적으로 룩업 테이블의 최대 일치 항목 수는 100입니다. 일치하는 여러 행이 있다면 출력 필드에도 여러 값이 생깁니다. 예를 들어, URL www. google.com/img/pix.jpg 는 위의 테이블에서 첫 번째 행 그리고 세 번째 행과 일치하는 경우, 허용된 필드는 True 또는 False 값을 가진 다중값 필드가 됩니다. 일반적으로 이것은 원하는 결과가 아닙니다. 최대 일치 항목 수를 1 로 설정하면 첫 번째 일치 값이 사용되고, 우선 순위를 결정하기 위해 테이블 순서를 사용할 수 있습니다. 고급 옵션 체크박스를 선택한 후 관리자 >> 룩업 >> 룩업 정의 >> mylookup에서 이 설정을 찾을 수 있습니다. 변형 이 장의 첫 번째 방법에서는 룩업 실행 후 일치 항목을 찾지 못할 경우 의 기본값을 처리하는 방법을 다루었습니다. 또 다른 방법으로는 와일 드카드 일치를 이용하는 것입니다. 룩업 테이블의 마지막 항목이 일치 값 *를 가지도록 설정하고 룩업 테이블의 최소/최대 일치 항목 수를 1 로 설정하십시오. 124

138 부록 A: 머신 데이터 기본사항 머신 데이터는 IT 전문가들에 의해 데이터 센터에서 오랫동안 활용되 어 왔지만, 최근에는 다른 부서에서도 활용할 수 있는 소스로 인식되고 있습니다. IT 데이터 또는 운영 데이터라고도 불리는 머신 데이터는 비 즈니스 상에서 애플리케이션, 서버, 네트워크 장치, 보안 장치 등의 시 스템에 의해 생성되는 모든 데이터를 일컫습니다. 보통 머신 데이터의 범주에는 로그 파일보다 훨씬 더 많은 데이터가 포함됩니다. 여기에는 구성, 클릭스트림, 변경 이벤트, 진단, API, 메시지 대기열, 사용자 지정 애플리케이션 등의 데이터가 포함됩니다. 이러한 데이터는 엄격히 정 형화되어 있고 시계열 기반으로 볼륨이 큽니다. IT의 거의 모든 구성요 소에서 생성된다고 할 수 있으며 데이터 형식과 소스 또한 매우 다양 합니다. 사용자 지정 애플리케이션에서 나오는 수많은 로그 형식은 서 비스 문제를 진단하고, 복잡한 보안 위협을 감지하고, 컴플라이언스를 입증하는 데 매우 중요한 역할을 합니다. 또한 연결되는 장치들이 급 증하면서, GPS 장치, RFID 태그, 핸드폰, 유틸리티 장비 등 다양한 종류 의 많은 시스템에서 엄청난 양의 정보들이 쏟아지고 있는 가운데 데이 터 증가 속도는 이러한 정보 처리 및 활용 기술 속도를 빠르게 능가하 고 있습니다. IT 전문가들에게는 머신 데이터의 가치가 새삼스러운 것이 아닙니다. 이미 수년 전부터 활용되던 것입니다. Splunk 사용자들도 Splunk가 자신들의 비즈니스 이슈와 관련하여 유용한 정보를 제공한다는 것을 깨닫고 있습니다. 머신 데이터는 대부분 대용량 파일로 저장되는데, Splunk 사용 이전에는 문제가 발생하여 파일들을 수동으로 검사하기 전까지 머신 데이터는 사용되지 않는 휴면 상태였을 가능성이 높습니 다. 이제 Splunk를 사용하면 이러한 파일들이 인덱스되어 활용 가능하 게 됩니다. 비즈니스 사용자는 비즈니스 프로세스에 관여하는 많은 사람들에 의해 생성되는 데이터를 처리해야 합니다. 이러한 데이터를 흔히 일컫는 트 랜잭션 데이터는 다음의 두 데이터베이스 양식 중 하나로 저장됩니다. 관계형 데이터베이스: 트랜잭션 데이터를 저장하는 데 널리 사용됩니 다. 관계형 데이터베이스는 재무 기록, 인사 기록, 제조 정보, 물류 정보 처럼 주로 정형화된 엔터프라이즈 데이터를 저장합니다. 관계형 데이 터베이스는 설계 상 데이터베이스의 구조를 설명하는 엄격한 스키마 나 공식들의 집합으로 구성되어 있습니다. 이와 같은 스키마를 변경하 게 되면 지연 시간이 길어지고 위험이 동반되어 기능 상 손상이 발생할 125

139 Exploring Splunk 수도 있습니다. 그럼에도 관계형 데이터베이스에서 검색을 구성하려면 일반적으로 실무자는 스키마를 변경해야 합니다. 다차원 데이터베이스(MDB): 대규모 레코드 그룹 분석에 적합하도록 설계되었습니다. OLAP(On-Line Analytical Processing)라는 용어는 "다 차원 데이터베이스"와 거의 동의어가 되었습니다. 사용자는 OLAP 도 구를 통해 다차원 데이터를 서로 다른 차원에서 분석할 수 있습니다. 다 차원 데이터베이스는 실시간 이벤트에는 적합하지 않고 데이터 마이닝 과 월간 보고에 적합합니다. 머신 데이터는 트랜잭션 데이터보다 세부 수준이 훨씬 낮습니다. 트랜 잭션 데이터는 온라인 구매와 관련한 모든 제품, 배송, 결제 데이터를 저장합니다. 이처럼 구매 관련 머신 데이터에는 사용자의 모든 클릭, 로 드한 모든 페이지와 이미지, 요청된 모든 광고 요청 등 수천 개의 레코 드나 이벤트가 포함됩니다. 완성된 결과나 목적지가 아니라 전체 여정 의 한 부분이라고 할 수 있는 머신 데이터는. 매우 세부적이라 아주 다양한 용도로 사용될 수 있습니다. IT 환경에서 머신 데이터는 문제점을 찾아내는데 도움이 되고, 시스템이 허용 성능 범위 내에서 작동되고 있는지를 보여주기도 합니다. 비즈니스 환경에 서 머신 데이터는 소비자 행동을 추적하고, 소비자층을 구분해 마케팅 타겟 메시지를 작성하는데 활용되기도 합니다. 이 부록에서는 머신 데이터 속성을 보다 잘 활용할 수 있도록 사용자들 이 겪을 수 있는 다양한 유형에 대해 간략하게 설명하겠습니다. 애플리케이션 로그 자체 제작한 패키지 애플리케이션 대부분은 주로 로깅 서비스가 내장 된 미들웨어(WebLogic, WebSphere, JBoss,.NET, PHP 및 기타)를 사용하여 로컬 로그 파일을 작성합니다. 로그 파일은 개발자와 애플리 케이션 지원에 필요한 실운영 애플리케이션의 일상적인 디버깅 작업 에 매우 중요합니다. 뿐만 아니라 로그 파일에는 트랜잭션의 모든 세부 정보가 담겨 있기 때문에 비즈니스 활동과 사용자 활동을 보고하고 악 의적 활동을 감지하는 데 가장 좋은 방법이기도 합니다. 개발자가 로그 이벤트에 타이밍 정보를 넣을 경우, 애플리케이션 성능 모니터링과 보 고에도 사용할 수 있습니다. 웹 액세스 로그 웹 액세스 로그는 웹 서버에서 처리되는 모든 요청을 보고합니다. 예 를 들어, 어떤 클라이언트 IP 주소가 수신되었고, 어떤 URL이 요청되었 는지, 참조 URL은 무엇인지, 그리고 요청 성공/실패에 관한 데이터 등 을 보고합니다. 로그 파일은 일일 방문자 수, 가장 많이 요청된 페이지 등과 같이 마케팅을 위한 웹 분석 보고서를 작성하기 위해 일반적으로 처리됩니다. 126

140 부록 A: 머신 데이터 기본사항 또한 실패한 요청에 대한 로그에는 정확한 오류 시점이 나타나므로, 보 고된 문제점을 조사하는 시작점으로써 로그 파일은 매우 가치 있는 데 이터라고 할 수 있습니다. 웹 로그는 표준화되어 있고 구조화되어 있습 니다. 그러나 최대 난제는 일반적으로 하루에 수 십억 건의 방문이 이루 어지는 인기 웹 사이트들의 엄청난 볼륨을 어떻게 다루냐는 것입니다. 웹 프록시 로그 직원, 고객 또는 게스트에 웹 액세스를 제공하는 거의 대부분의 기업, 서비스 제공업체, 기관, 정부 조직 등이 웹 프록시를 사용하여 액세스 를 제어하고 모니터링합니다. 웹 프록시는 프록시를 통한 사용자의 모 든 웹 요청을 기록합니다. 여기에는 회사 사용자 이름 및 URL이 포함 될 수 있습니다. 이러한 로그는 "이용 약관" 악용이나 회사 웹 사이트 이용 정책을 모니터링하고 조사하는데 매우 요긴하게 사용되며, 데이 터 누출에 대한 효과적인 모니터링과 조사에도 핵심적인 구성요소가 되기도 합니다. 통화 내역 기록(CDR) CDR(Call Detail Records, 통화 내역 기록), Charging Data Record(과금 부과 데이터 기록) 및 EDR(Event Data Records, 이벤트 데이터 기록)은 전자통신 및 네트워크 스위치에 의해 기록되는 이벤트에 붙여진 이름 들입니다. CDR에는 스위치를 통과한 통화 또는 서비스의 유용한 세부 정보가 포함됩니다. 즉, 발신번호, 수신번호, 전화 건 시간, 통화한 시간 (양), 통화 유형과 같은 정보가 포함됩니다. 통신 서비스가 인터넷 프로 토콜 기반 서비스로 이동하면서, 이러한 데이터는 IP 주소, 포트 번호 등과 같은 세부정보를 포함하는 IPDR로 참조되기도 합니다. 이러한 파 일의 사양, 형식 및 구조는 매우 다양해 모든 경우의 수를 처리하고 추 적하는 것은 일반적으로 어려운 난제가 되고 있습니다. CDR에 포함되 는 데이터는 과금, 매출 보장, 고객 보장, 파트너 정산, 마케팅 인텔리전 스 등에 매우 중요합니다. Splunk를 사용하면 데이터를 신속하게 인덱 스하여 다른 비즈니스 데이터와 인덱스한 데이터를 결합해 새로운 통 찰력을 얻을 수 있습니다. 클릭스트림 데이터 웹 사이트에서 웹 페이지의 이용은 클릭스트림 데이터로 수집됩니다. 클릭스트림 데이터를 통해 웹 사이트에서의 사용자 활동을 알 수 있고, 이 데이터는 유용성 분석, 마케팅 및 일반 리서치에도 유용하게 사용됩 니다. 클릭스트림 데이터의 형식은 비표준화되어 있고, 다양한 작업들 이 웹 서버, 라우터, 프록시 서버, 광고 서버 등 여러 곳에서 로깅될 수 있습니다. 모니터링 도구는 특정 소스로부터 데이터의 일부분에 대한 뷰만 제공하는 경우가 많습니다. 웹 분석 및 데이터 웨어하우스 제품은 데이터를 샘플링하기 때문에 동작에 대한 전체 뷰를 놓치거나 실시간 분석을 제공하지 못합니다. 127

141 Exploring Splunk 메시지 대기열 TIBCO, JMS, AquaLogic 등의 메시지 대기열 기술은 공개/구독 형태 로 서비스와 애플리케이션 구성요소 간에 데이터와 작업을 전달하는 데 사용됩니다. 이러한 메시지 대기열을 구독하는 것은 복잡한 애플리 케이션에서 문제를 디버깅하는 좋은 방법입니다. 즉, 다음 구성요소가 연이어서 이전 구성요소로부터 받은 것이 무엇인지를 정확히 볼 수 있 습니다. 메시지 대기열은 애플리케이션을 위한 로깅 아키텍처의 백본 으로서 점점 더 많이 사용되고 있습니다. 패킷 데이터 네트워크에서 생성되는 데이터는 tcpdump 및 tcpflow와 같은 도구를 사용하여 처리되며, 이 도구들은 pcaps 데이터와 기타 유용한 패킷 레 벨 및 세션 레벨 정보를 생성합니다. 이 정보는 성능 저하, 시간 초과, 병목현상 또는 네트워크를 손상시킬 수 있는 의심스러운 활동 또는 원 격 공격 개체를 처리하는데 필요합니다. 구성 파일 인프라가 어떻게 설정되었는지 이해하는 데 있어 실제 작동되고 있는 시스템 구성을 대신할 만한 것은 없습니다. 과거 구성은 다시 발생할 수 있는 과거 실패를 디버깅하는 데 필요합니다. 구성이 변경된 경우, 무엇 이 변경되었는지, 언제 변경이 승인되었고, 실제 변경이 승인되었는지, 그리고 성공적인 공격자가 백도어, 시한 폭탄 또는 기타 잠복되어 있 던 위협을 통해 시스템을 손상시켰는지 여부를 아는 것이 중요합니다. 데이터베이스 감사(Audit) 로그 및 테이블 데이터베이스에는 고객 정보, 금융 데이터, 환자 기록 등 민감한 기업 데이터들이 들어 있습니다. 모든 데이터베이스 쿼리의 감사(Audit) 레 코드는 어떤 데이터에 언제 누가 액세스를 했고, 언제 누가 데이터를 변경했는지를 아는데 반드시 필요합니다. 데이터베이스 감사(Audit) 로 그는 애플리케이션이 쿼리를 최적화하는 데 데이터베이스를 어떻게 사 용하는지 이해하는 데도 유용합니다. 일부 데이터베이스는 파일에 감 사(Audit) 레코드를 기록하고, 또 다른 데이터베이스는 SQL을 사용하여 접근 가능한 감사(Audit) 테이블을 유지 관리합니다. 파일 시스템 감사(Audit) 로그 데이터베이스에 없는 민감한 데이터는 파일 시스템에 저장되어 종종 공유됩니다. 의료산업과 같은 일부 산업계에서 가장 큰 데이터 누출 위 험은 공유 파일 시스템에 있는 소비자 관련 데이터입니다. 서로 다른 128

142 부록 A: 머신 데이터 기본사항 운영 체제나 타사의 도구들 그리고 다양한 스토리지 기술이 파일 시스 템 레벨에서 민감한 데이터를 읽는 엑세스를 감사하는데 있어 다양한 옵션을 제공합니다. 이 감사(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에는 네트워크 연결 상태와 중요한 네트워크 구성요소 오류가 기록됩니다. 머신 데이터에 는 단순한 로그 이상의 데이터가 존재할 뿐만 아니라, 기존의 로그 관 리 솔루션들이 지원하는 것보다 훨씬 다양한 범위의 로그가 있습니다. 129

143

144 부록 B: 대소문자 구분 Splunk는 대소문자를 구분하는 것도 있고, 그렇지 않은 것도 있습니다. 표 B-1을 참조하십시오. 표 B-1. 대소문자 구분 구분 구분 안함 예 명령어 이름 X TOP, top, stats 명령어 키워드 X AS used by stats, rename, ; 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 (literal keywords) 필드 이름 X host vs. HOST 필드 값 X host=localhost, host=localhost 정규식 X \d\d\d vs. \D\D\D replace command X error vs. ERROR 131

145

146 부록 C: 주요 명령어 다음은 최종 사용자의 샘플에서 그리고 Splunk 애플리케이션에서 가장 많이 사용되는 검색 명령어들입니다. 최종 사용자의 주요 검색 명령어 Splunk 애플리케이션의 주요 검색 명령어 명령어 비중 명령어 비중 search 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

147 Exploring Splunk makemv 209 outlier 12 rangemap 202 join 9 appendcols 201 replace 9 lookup 157 streamstats 8 replace

148 부록 D: 주요 리소스 본 설명서에서 다룬 내용 이외에도 Splunk에 대해 알아두면 유용한 많 은 정보가 있습니다. 자세한 정보는 아래 웹 사이트를 참조하십시오. 아 래 링크들은 ttp://splunk.com/goto/book#links에도 나와 있습니다. Splunk 다운로드 페이지 Splunk 설명서 및 문서 Splunk 커뮤니티 커뮤니티 기반 문서 교육 비디오 Splunk 비디오 Splunk 블로그 Splunk TV

149

150 부록 E: Splunk 빠른 참조 가이드 개념 개요 이벤트 인덱스-시간 처리: Splunk는 호스트(예: "내 시스템")에서 파일 또는 포트와 같이 소스로부터 데이터를 읽고, 해당 소스를 sourcetype( 예:syslog, access_combined 또는 apache error)으로 분류한 후, 타임스 탬프를 추출하고, 소스를 개별 이벤트(예: 로그 이벤트, 경고)로 나눕니 다. 이러한 개별 이벤트는 한 줄 혹은 여러 줄로 구성될 수 있으며, 각 이벤트를 디스크 상의 인덱스에 작성해 나중에 검색에 사용할 수 있습 니다. 검색-시간 처리: 검색이 시작되면 일치하는, 인덱스된 이벤트가 디 스크로부터 검색되고, 이벤트 텍스트로부터 필드(예: code=404 또는 user=david,...)가 추출됩니다. 그리고 eventtype 정의(예: error 또는 login)에 맞는 일치 작업을 통해 이벤트가 분류됩니다. 검색을 통해 반 환된 이벤트는 SPL을 사용해 강력하게 변환되어 대시보드에 표시되는 보고서를 생성합니다. 이벤트는 한 줄 데이터입니다. 다음은 웹 활동 로그의 이벤트입니다 [01/Jul/2009:12:05: ] GET /trade/ app?action=logout HTTP/ 좀 더 구체적으로 설명하면, 이벤트는 타임스탬프와 관련된 값의 집합 입니다. 대부분의 이벤트가 한두 줄 정도로 짧은데, 전체 텍스트 문서, 구성 파일 또는 전체 Java 스택 트레이스와 같이 긴 이벤트도 있습니다. Splunk는 검색 결과에 표시할 이벤트를 어떻게 나눌지를 결정하기 위 해 줄바꿈 규칙을 사용합니다. 137

151 Exploring Splunk Source 및 Sourcetype Host 인덱스 필드 태그 Source는 이벤트가 발생한 파일, 스트림 또는 기타 입력의 이름입니다. 예: /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를 가질 수 있습니다. host는 이벤트가 발생한 물리적 장치 또는 가상 장치의 이름입니다. Host는 특정 장치에서 발생하는 모든 데이터를 찾는 가장 쉬운 방법 을 제공합니다. Splunk에 데이터를 추가할 때, Splunk는 데이터를 처리하고 데이터를 개별 이벤트, 타임스탬프 및 이벤트로 나누어, 이를 인덱스에 저장해 서 나중에 데이터를 검색하고 분석할 수 있도록 합니다. 기본적으로 Splunk에 제공하는 데이터는 main 인덱스에 저장되지만, 서로 다른 데 이터 입력을 위해 Splunk가 사용하기 위해 다른 인덱스를 만들고 지정 할 수 있습니다. 필드는 이벤트 데이터에서 검색 가능한 이름/값의 쌍입니다. Splunk 는 인덱스 시점 및 검색 시점에 이벤트를 처리하면서 자동으로 필드를 추출합니다. Splunk는 인덱스를 만드는 동안 각 이벤트에 대해 host, source 및 sourcetype을 비롯한 몇 가지의 기본 필드를 추출합니다. 또 한 검색 시점에는 userid=jdoe와 같이 명확한 필드 이름/값 쌍과 사용 자 지정 패턴을 포함하여, 이벤트 데이터로부터 광범위한 종류의 필드 를 추출합니다. 태그는 필드 값에 대한 별칭입니다. 예를 들어, 두 개의 호스트 이름이 동일한 컴퓨터를 참조할 경우 두 호스트 값 모두에 동일한 태그를 제공 할 수 있습니다(예: hal9000). tag=hal9000을 검색하면 Splunk는 두 호 스트 이름 값과 관련된 이벤트를 반환합니다. 138

152 부록 E: Splunk 빠른 참조 안내서 Event Type Event 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로 여러 웹 액세스 이벤트를 생성하므로 이러한 이벤트를 하나의 트랜잭션으로 그룹화하 는 것이 편리합니다. 트랜잭션 이벤트가 하나인 경우 이용자가 쇼핑몰 에 머무른 시간, 구입한 물품 수, 어떤 이용자들이 물품을 구매하고 환 불했는지 등에 대한 통계를 생성하는 것이 더욱 쉬워집니다. 139

153 Exploring Splunk Forwarder/인덱서 Forwarder는 사용자가 중앙 Splunk 인덱서 또는 인덱서 그룹에 데이 터를 전송할 수 있는 Splunk 버전입니다. 인덱서는 로컬/원격 데이터에 대한 인덱싱 기능을 제공합니다. SPL 검색은 일련의 명령어와 인수로, 파이프 문자( )로 연결되어 있습니다. 파이프 문자는 하나의 명령어에서 나온 출력을 다음 명령어에 제공합 니다. search-args cmd1 cmd-args cmd2 cmd-args... 검색 명령어는 인덱스된 데이터를 가져와 원하지 않는 정보를 필터링 하고, 추가 정보를 추출하고, 값을 계산 및 변환하고, 결과를 통계 분석 하는데 사용됩니다. 인덱스로부터 검색된 검색 결과는 동적으로 생성 된 테이블로 간주할 수 있습니다. 각 검색 명령어는 해당 테이블의 모 양을 다시 정의합니다. 인덱스된 각 이벤트는 각 필드 값에 대해 컬럼 140

154 부록 E: Splunk 빠른 참조 안내서 을 가진 행입니다. 컬럼에는 데이터에 대한 기본 정보가 포함되고 검색 시간에 동적으로 추출된 데이터입니다. 각 검색의 헤드에는 암시적인 search-the-index-for-events 명령어가 있습니다. 이 명령어는 키워드(예: error), 부울 식(예: (error OR failure) 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과 동일). 141

155 Exploring Splunk 시간 맞춤: 시간을 내림하여 가장 가까운 최신 시간을 나타냅니다. 정시 맞춤은 지정된 시간을 넘지 않는 가장 최근 시간으로 맞춥니다. 예를 들 어, 11:59:00을 "정시 맞춤"하면 12:00가 아니라 11:00에 맞춰집니다. 요일도 맞출 수 있습니다. 사용하면 됩니다. 공통 검색 명령 명령 chart/timechart dedup eval fields head/tail lookup rename replace rex search sort stats top/rare transaction 테이블 형식의 출력을 (시간 기반) 차트 형식으로 결과를 반환합니다. 반복적으로 발생하는 일치 결과를 제거합니다. 식을 계산합니다. (EVAL 함수 테이블 참조) 검색 결과에서 필드를 제거합니다. 첫 번째/N 번째 결과를 반환합니다. 외부 소스의 필드 값을 추가합니다. 지정된 필드 이름을 변경합니다. 와일드카드를 사 용하여 여러 필드를 지정할 수 있습니다. 지정된 필드의 값을 지정된 새 값으로 대체합니다. 정규식을 지정하여 필드 추출에 사용합니다. 검색 식과 일치하도록 결과를 필터링합니다. 지정된 필드를 기준으로 검색 결과를 정렬합니다. 통계를 제공합니다. 원할 경우 필드별로 그룹화할 수 있습니다. 필드의 가장 흔한 값/드문 값을 보여줍니다. 검색 결과를 트랜잭션으로 그룹화합니다. 검색 최적화 빠른 검색을 하기 위한 방법은 디스크에서 읽는 데이터를 최대한 최소 화하도록 제한한 후 가능한 빨리 데이터를 필터링해서 가장 적은 양의 데이터에서 처리가 이루어지도록 하는 것입니다. 여러 데이터 유형에 걸쳐 검색을 수행하는 경우가 거의 드물다면 데 이터를 개별 인덱스로 파티셔닝하십시오. 예를 들어, 하나의 인덱스에 는 웹 데이터를 넣고, 또 다른 인덱스에는 방화벽 데이터를 넣습니다. 142

156 부록 E: Splunk 빠른 참조 안내서 유용한 팁: 가능한 세부적으로 검색합니다(*error* 대신 fatal_error). 시간 범위를 제한합니다(예: -1w 대신 -1h). 가능한 빨리 불필요한 필드를 필터링하여 제거합니다. 계산 전에 최대한 빨리 결과를 필터링하여 제거합니다. 보고서 생성 검색의 경우, 시간대를 계산하는 시간 표시줄 보기 대 신에 고급 차트 작성 보기를 사용합니다. 필요하지 않을 경우 필드 검색 스위치를 끕니다. 요약 인덱스를 사용하여 흔히 사용하는 값을 미리 계산합니다. 해당 디스크 I/O가 사용 가능한 것 중 가장 빠른지 확인합니다. 검색 예제 결과 필터링 행 텍스트에 fail이 있고 status=0 search fail status=0 인 항목만 결과에 포함되도록 필터 링합니다. 동일한 호스트 값을 가진 중복 결과 dedup host 를 제거합니다. _raw 필드에 라우팅할 수 없는 클래 스 A ( /8)의 IP 주소가 있는 검색 결과만 유지합니다. 클러스터 결과를 cluster_count 값 별로 정렬한 다음 데이터 크기가 가 장 큰 20개 클러스터를 반환합니다. 동일한 호스트와 쿠키가 있으며 각 각 30초 이내에 발생하고 각 이벤트 간 일시 정지 시간이 5초를 넘지 않 는 검색 결과를 트랜잭션으로 그룹 화합니다. 동일한 IP 주소로 결과를 그룹화하고 (clientip), 첫 번째 결과에 로그온 이 포함되고 마지막 결과에 구매가 포함됩니다. 결과 그룹화 regex _raw="(?<!\d)10.\ d{1,3}\.\d{1,3}\.\d{1,3} (?!\d)" cluster t=0.9 showcount=true sort limit=20 -cluster_count transaction host cookie maxspan=30s maxpause=5s transaction clientip startswith="signon" endswith="purchase" 143

157 Exploring Splunk 결과 순서 지정 처음 20개의 결과를 반환합니다. head 20 결과 집합의 순서를 반대로 바꿉니 reverse 다. ip 값을 기준으로 결과를 오름차순 sort ip, -url 으로 정렬한 다음 url 값을 기준으 로 내림차순으로 정렬합니다. 마지막 20개의 결과를 반환합니다( tail 20 역순). 보고 희귀 값을 가진 이벤트를 반환합니다. "size"별로 최대 "delay"를 반환합 니다. 여기서 "size"는 최대 10개의 같은 크기 버킷으로 분할됩니다. bar 값으로 분할된 각 foo 값에 대해 max(delay)를 반환합니다. 각 foo 값에 대해 max(delay)를 반 환합니다. 범위를 벗어난 숫자 값을 모두 제거 합니다. 동일한 호스트 값을 가진 중복 결과 를 제거하고 남은 총 결과 수를 반환 합니다. lay 문자열로 끝나는 고유 필드(예: delay, xdelay, relay)의 매시간 평균 을 반환합니다. 각 호스트의 분당 CPU의 평균값을 계산합니다. 호스트별 웹 소스의 개수에 대한 시 간 차트를 만듭니다. url 필드의 가장 일반적인 20개 값 을 반환합니다. url 필드의 가장 드문 값을 반환합 니다. anomalousvalue action=filter pthresh=0.02 chart max(delay) by size bins=10 chart max(delay) over foo by bar chart max(delay) over foo outlier stats dc(host) stats avg(*lay) by date_ hour timechart span=1m avg(cpu) by host timechart count by host top limit=20 url rare url 144

158 부록 E: Splunk 빠른 참조 안내서 속도를 거리/시간으로 설정합니다. 정규식을 사용하여 from 및 to 필 드를 추출합니다. 원시 이벤트에 From:이 포함된 경우 Susan To: David, 그 다음 from=susan 및 to=david. 총 실행 개수 누계를 total_count 라는 필드에 저장합니다. count가 있는 각 이벤트에 대해 count와 이전 값의 차이를 계산한 후 그 결과를 countdiff에 저장합 니다. 필드 추가 eval velocity=distance/ time rex field=_raw "From: (?<from>.*) To: (?<to>.*)" accum count as total_count delta count as countdiff 필드 필터링 host 및 ip 필드만 유지하고 host, fields + host, ip ip대로 순서대로 표시합니다. host 및 ip 필드를 제거합니다. fields - host, ip host 및 ip 필드만 유지하고 host, ip 순서대로 표시합니다. host 및 ip 필드를 제거합니다. 필드 수정 fields + host, ip fields - host, ip 다중값 필드 recipients 필드의 다중값을 하나 nomv recipients 의 값으로 결합합니다. 상위 수신인을 표시하면서 recipients 필드의 값을 여러 필드 값으로 분리합니다. 다중값 필드 recipients의 각 값에 대해 새 값을 생성합니다. RecordNumber를 제외하고, 동일한 각 결과를 결합시킵니다. Record- Number를 다양한 모든 값을 가진 다 중값 필드로 설정합니다. makemv delim="," recipients top recipients mvexpand recipients fields EventCode, Category, RecordNumber mvcombine delim=, Record- Number recipient 값의 숫자를 찾습니다. eval to_count = mvcount(recipients) recipient 필드에서 첫 번째 이메 일 주소를 검색합니다. eval recipient_first = mvindex(recipient,0) 145

159 Exploring Splunk.net 또는.org로 끝나는 모든 recipient 값을 검색합니다. foo 필드의 값에 "bar"라는 문자 열과 baz 필더의 값을 추가하여 newval 필드를 만듭니다. "\.org$"와 일치하는 첫 번째 수신 인 값의 인덱스를 검색합니다. 룩업 테이블 usertogroup에서 각 이벤트 사용자 필드의 값을 조회하고 이벤트의 그룹 필드를 설정합니다. 검색 결과를 룩업 파일 users.csv 에 작성합니다. 검색 결과로서 룩업 파일 users. csv를 읽습니다. EVAL 함수 eval netorg_recipients = mvfilter(match(recipient, "\.net$") OR match(recipient, "\.org$")) eval newval = mvappend(foo, "bar", baz) 룩업 테이블 eval orgindex = mvfind(recipient, "\.org$") lookup usertogroup user output group outputlookup users.csv inputlookup users.csv 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", error == 200, "OK") ceil(x) 숫자 X 실링 ceil(1.9) cidrmatch("x",y) coalesce(x, ) 서브넷에 속하는 IP 주 소를 식별합니다. null이 아닌 첫 번째 값 을 반환합니다. cidrmatch(" /25",ip) coalesce(null(), "Returned val", null()) 146

160 부록 E: Splunk 빠른 참조 안내서 exact(x) 배정도 부동소수점 연 exact(3.14*num) 산을 사용하여 식 X를 계산합니다. exp(x) ex를 반환합니다. exp(3) floor(x) 숫자 X의 가장 작은 값 을 반환합니다. floor(1.9) if(x,y,z) isbool(x) isint(x) isnotnull(x) isnull(x) isnum(x) isstr() len(x) like(x,"y") ln(x) log(x,y) X가 TRUE로 평가되면 결과는 두 번째 인수 Y 입니다. X가 FALSE로 평 가될 경우 그 결과는 세 번째 인수 Z가 됩니다. X가 부울일 경우 TRUE 를 반환합니다. X가 정수일 경우 TRUE 를 반환합니다. X가 NULL이 아닐 경우 TRUE를 반환합니다. X가 NULL일 경우 TRUE 를 반환합니다. X가 숫자일 경우 TRUE 를 반환합니다. X가 문자열일 경우 TRUE를 반환합니다. 이 함수는 문자열 X의 문자 길이를 반환합니 다. X가 Y의 SQLite 패턴과 유사한 경우(유사한 경 우에만) TRUE를 반환합 니다. 자연 로그 X를 반환합 니다. 두 번째 인수 Y를 기본 으로 사용하여 첫 번째 인수 X에 대한 로그를 반환합니다. Y의 기본값 은 10입니다. if(error==200, "OK", "Error") isbool(field) isint(field) isnotnull(field) isnull(field) isnum(field) isstr(field) len(field) like(field, "foo%") ln(bytes) log(number,2) lower(x) 소문자 X를 반환합니다. lower(username) ltrim(x,y) 왼쪽에서부터 트리밍된 Y에서 해당 문자로 X를 반환합니다. Y는 기본적 으로 공백과 탭으로 지 정됩니다. ltrim(" ZZZabcZZ ", " Z") 147

161 Exploring Splunk match(x,y) max(x, ) md5(x) X가 정규식 패턴 Y와 일 치할 경우 True를 반환 합니다. 두 개의 값보다 큰 값을 반환합니다. 문자열 값 X의 MD5 해 시를 반환합니다. match(field, "^\d{1,3}\.\d$") max(delay, mydelay) md5(field) min(x, ) 분을 반환합니다. min(delay, mydelay) mvcount(x) X 값의 개수를 반환합 mvcount(multifield) 니다. mvfilter(x) 부울 식 X를 기준으로 다중값 필드를 필터링 합니다. mvfilter(match(emai l, "net$")) mvindex(x,y,z) mvjoin(x,y) now() null() nullif(x,y) 시작점(0 기반) Y에서 Z(옵션)로 다중값 필드 X의 하위 집합을 반환 합니다. 다중값 필드 X와 문자 열 구분자 Y가 주어진 경우 Y를 사용하여 X 각 각의 값을 조인합니다. Unix 시계에 표시되는 현재 시간을 반환합니 다. 인수가 없어 NULL을 반 환합니다. 두 개의 인수, 필드 X와 Y가 주어진 상태에서 이 인수들이 서로 다를 경우 X를 반환하고, 그 렇지 않으면 NULL을 반 환합니다. mvindex( multifield, 2) mvjoin(foo, ";") now() null() pi() 상수 pi를 반환합니다. pi() nullif(fielda, fieldb) pow(x,y) XY를 반환합니다. pow(2,10) random() 범위의 random() 유사 랜덤 숫자를 반환 합니다. relative_time(x,y) epochtime 시간 X와 상 대적 시간 지정자 Y가 주어진 경우 X에 적용 된 epochtime 값 Y를 반환합니다. relative_ time(now(),"-1d@d") 148

162 부록 E: Splunk 빠른 참조 안내서 replace(x,y,z) round(x,y) rtrim(x,y) searchmatch(x) split(x,"y") 문자열 X에서 정규식 문자열 Y가 발생할 때 마다 문자열 Z를 치환 해서 구성된 문자열을 반환합니다. Y에 의해 지정된 소수 점 자리만큼 반올림한 X를 반환합니다. 기본 값은 정수로 반올림입 니다. 오른쪽에서부터 트리밍 된 Y에서 해당 문자로 X 를 반환합니다. Y가 지 정되지 않은 경우 공백 과 탭은 잘립니다. 이벤트가 검색 문자열 X와 일치할 경우 true를 반환합니다. 구분자 Y로 분활된 다중값 필드로 X를 반환합니다. sqrt(x) 제곱근 X를 반환합니다. sqrt(9) strftime(x,y) strptime(x,y) substr(x,y,z) time() Y에 의해 지정된 형식 을 사용하여 랜더링된 epochtime 값 X를 반환 합니다. 문자열 X로 표시되는 시간의 경우, 형식 Y로 구문 분석된 값을 반환 합니다. Z(옵션) 문자에 대해 시 작점(1 기반) Y에서 하 위 문자열 필드 X를 반 환합니다. 마이크로초 단위의 wall-clock 시간을 반환 합니다. Returns date with the month and day numbers switched, so if the input is 1/12/2009 the return value is 12/1/2009: replace(date, "^(\d{1,2})/ (\d{1,2})/", "\2/\1/") round(3.5) rtrim(" ZZZZabcZZ ", " Z") searchmatch("foo AND bar") split(foo, ";") strftime(_time, "%H:%M") strptime(timestr, "%H:%M") substr("string", 1, 3) +substr("string", -3) time() 149

163 Exploring Splunk tonumber(x,y) tostring(x,y) trim(x,y) typeof(x) 입력 문자열 X를 숫자 로 변환합니다. 여기서 Y(옵션, 기본값 10)는 변 환될 숫자의 기본값을 정의합니다. 필드 값 X를 문자열로 반환합니다. X가 숫자 인 경우 문자열로 재포 맷합니다. 부울 값일 경 우 "True"이거나 "False" 입니다. X가 숫자인 경 우 두 번째 인수 Y는 옵 션이며, "hex"(x를 16진 수로 변환), "commas"( 콤마와 2자리 소수점 으로 X 형식 지정) 또 는 "duration"(초 X를 HH:MM:SS로 변환) 중 하나가 됩니다. 양쪽에서부터 트리밍된 Y에서 해당 문자로 X를 반환합니다. Y가 지정되 지 않은 경우 공백과 탭 은 잘립니다. 해당 유형의 문자열 표 현을 반환합니다. tonumber("0a4",16) This example returns foo=615 and foo2=00:10:15: eval foo=615 eval foo2=tostring(foo, duration ) trim(" ZZZZabcZZ ", " Z") This example returns: "NumberStringBoolInvalid": typeof(12)+ typeof( string )+ typeof(1==2)+ typeof(badfield) upper(x) 대문자 X를 반환합니다. upper(username) urldecode(x) validate(x,y, ) 디코딩된 URL X를 반환 합니다. 부울 식 X와 문자열 Y 로된 인수 쌍이 있는 경 우, False로 평가되고 모 두 True인 경우 NULL로 기본값이 설정되는 첫 번째 식 X에 해당하는 문자열 Y를 반환합니다. urldecode( http%3a% 2F%2Fwww.splunk. com%2fdownload%3fr% 3Dheader ) validate(isint(port), "ERROR: Port is not an integer", port >= 1 AND port <= 65535, "ERROR: Port is out of range") 150

164 부록 E: Splunk 빠른 참조 안내서 공통 STATS 함수 chart, stats 및 timechart 명령어를 사용하는 일반적인 통계 함수입니 다. 필드 이름에 와일드카드를 사용할 수 있습니다. 따라서 avg(*delay) 는 delay와 xdelay 필드의 평균을 계산할 수 있습니다. 함수 avg(x) count(x) dc(x) first(x) last(x) list(x) max(x) median(x) min(x) mode(x) perc<x>(y) range(x) stdev(x) stdevp(x) sum(x) sumsq(x) values(x) var(x) 설명 필드 X의 값 평균을 반환합니다. 필드 X의 발생횟수를 반환합니다. 일치하는 필드값을 나 타내려면 X 형식을 eval(field="value")로 지정합니다. 필드 X의 개별 값 개수를 반환합니다. 첫 번째 보이는 필드 X 값을 반환합니다. 일반적으로 첫 번째 보이는 필드 값이 시간순으로 가장 최근의 인스턴스 필드입니다. 가장 마지막에 본 필드 X 값을 반환합니다. 이 필드 X의 모든 값 리스트를 다중값 항목으로 반환합니 다. 값의 순서는 입력 이벤트의 순서를 반영합니다. 필드 X의 최대값을 반환합니다. 값 X가 숫자가 아닐 경우 최대값은 사전 순서로 표시됩니다. 필드 X의 가장 중간 값을 반환합니다. 필드 X의 최소값을 반환합니다. 값 X가 숫자가 아닐 경우 최소값은 사전 순서로 표시됩니다. 필드 X의 최빈값을 반환합니다. 필드 Y의 X백분위수를 반환합니다. 예를 들어, perc5(total) 는 필드 전체 값에서 5백분위수 값을 반환합니다. 필드 X의 최대값과 최소값 사이의 차이를 반환합니다. 필드 X의 표본 표준편차를 반환합니다. 필드 X의 모 표준편차를 반환합니다. 필드 X의 값 합계를 반환합니다. 필드 X 값의 제곱 합계를 반환합니다. 필드 X의 모든 개별 값 리스트를 다중값 항목으로 반환합니다. 값 순서는 사전 순서로 정렬됩니다. 필드 X의 표본 분산을 반환합니다. 151

165 Exploring Splunk 정규식 정규식은 regex 및 rex 검색 명령어, eval 함수 match() 및 replace() 그리고 필드 추출 등 많은 영역에서 유용하게 사용됩니다. 정규식 참고사항 예제 설명 \s 공백 \d\s\d 숫자 공백 숫자 \S 공백 아님 \d\s\d 숫자 비공백 숫자 \d 숫자 \d\d\d-\d\d-\d\d\ SSN d\d \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) (?:... ) 논리적 그룹화 (?:\w \d) (?:\ d \w) pull out a SSN and assign to 'ssn' field 단어 문자 다음에 숫자 OR 숫자 다 음에 단어 문자 ^ 줄 시작 ^\d+ 적어도 하나의 숫 자로 줄 시작 $ 줄 종료 \d+$ 적어도 하나의 숫 자로 줄 종료 {...} 반복 수 \d{3,5} 3-5 숫자 사이 \ Escape \[ [ 문자 이스케이프 (?=...) 미리보기(Lookahead) (?=\D)error error must be preceded by a non-digit 152

166 부록 E: Splunk 빠른 참조 안내서 (?!...) 부정적 미리보기 (negative lookahead) (?!\d)error 숫자가 선행할 수 없는 오류 공통적인 SPLUNK STRPTIME 함수 strptime 형식은 eval 함수 strftime() 및 strptime()와 시간스탬프 이 벤트 데이터에 유용합니다. 시간 %H 24시간제(00-23) (선행 0) %I 12시간제(01-12) (선행 0) %M 분(00-59) %S 초( ) %N 간격(%3N = millisecs, %6N = microsecs, %9N = nanosecs)로 하위초 %p AM 또는 PM %Z 시간대(GMT) %s 1/1/1970 이후부터 초( ) 일 %d 한달 중 일 수(01-31) (선행 0) %j 일년 중 일 수( ) %w 일주일 중 일 수(0-6) %a 요일 줄임말(일) %A 요일(일요일) %b 월 줄임말(1) %B 월 이름(1월) %m 월(01-12) %y 두자리 연도(00-99) %Y 연도(2008) %Y-%m-%d %y-%m-%d %b %d, %Y Jan 24, 2003 %B %d, %Y January 24, 2003 q %d %b '%y = %Y-%m-%d q 25 Feb '03 =

167 Exploring Splunk 154

168