Table of Contents Splunk Enterprise 관리 소개 매뉴얼 사용 방법 Splunk 관리: 전체 개요 기타 Splunk 관리자용 매뉴얼 Windows 관리자를 위한 지침 Splunk Free에 대하여 Splunk 작업에서 *nix와 Windows의

Transcription

1 Splunk Enterprise 관리자 매뉴얼 생성일: 오후 4시 53분 Copyright (c) 2015 Splunk Inc. All Rights Reserved

2 Table of Contents Splunk Enterprise 관리 소개 매뉴얼 사용 방법 Splunk 관리: 전체 개요 기타 Splunk 관리자용 매뉴얼 Windows 관리자를 위한 지침 Splunk Free에 대하여 Splunk 작업에서 *nix와 Windows의 차이점 Splunk 설정 방법 Windows에서 Splunk Enterprise 최대한 활용하기 Windows에 Splunk 배포 Splunk를 최고 성능으로 최적화하는 방법 시스템 이미지에 Splunk 배치 유니버설 포워더를 시스템 이미지에 통합 전체 Splunk를 시스템 이미지에 통합 Splunk Web을 사용한 Splunk Enterprise 관리 Splunk Web 실행 Splunk Web 정보 Splunk 기본 대시보드 Splunk Web 배너 메시지 사용자 지정 프록시 서버를 통해 Splunk Web 사용 설정 파일을 사용한 Splunk Enterprise 관리 설정 파일에 대하여 설정 파일 디렉터리 설정 파일 구성 설정 파일 우선 순위 단일 props.conf 파일 내의 속성 우선 순위 설정 파일 복사 및 편집 방법 설정 파일 변경 후에 Splunk를 재시작해야 하는 경우 설정 파일 리스트 설정 매개 변수 및 데이터 파이프라인 설정 정보 백업 명령줄 인터페이스(CLI)를 사용한 Splunk Enterprise 관리 CLI에 대하여 CLI 도움말 보기 관리 CLI 명령 CLI를 사용하여 원격 Splunk 서버 관리 CLI 로그인 배너 사용자 지정 Splunk Enterprise 시작 및 초기 작업 수행 Splunk Enterprise 시작 및 중지 부팅 시 시작하도록 Splunk 설정 라이선스 설치 기본값 변경

3 Splunk를 IP에 바인드 IPv6용 Splunk 설정 설정 보안 Splunk 라이선스 설정 Splunk 라이선싱 방식 Splunk 라이선스 유형 그룹, 스택, 풀 및 기타 용어 라이선스 설치 라이선스 마스터 설정 라이선스 슬레이브 설정 라이선스 풀 만들기 또는 편집 라이선스 풀에 인덱서 추가 CLI를 통해 라이선스 관리 Splunk 라이선스 관리 라이선스 관리 라이선스 위반에 대하여 라이선스 마스터 교체 라이선스 사용량 보고서 뷰 Splunk Enterprise 라이선스 사용량 보고서 뷰에 대하여 라이선스 사용량 보고서 뷰 사용 분산 관리 콘솔로 Splunk Enterprise 모니터링 분산 관리 콘솔 설정 플랫폼 경고 인덱싱 성능: 인스턴스 인덱싱 성능: 배포 검색 작업: 인스턴스 검색 작업: 배포 검색 사용량 통계: 인스턴스 리소스 사용량: 인스턴스 리소스 사용량: 서버 리소스 사용량: 배포 KV 스토어: 인스턴스 KV 스토어: 배포 라이선싱 앱 key value 스토어 관리 앱 key value 스토어에 대하여 Splunk 앱 정보 앱 및 추가 기능 정의 기본 검색 앱 앱에서 열리도록 Splunk Web 설정 더 많은 앱과 추가 기능 찾기 앱 아키텍처 및 개체 소유권 앱 및 추가 기능 개체 관리 앱 및 추가 기능의 설정 및 속성 관리

4 Hunk 정보 Hunk 정보 사용자 관리 사용자 및 역할에 대하여 사용자 언어 및 로케일 설정 사용자 Session timeout 설정 설정 파일 참조 alert_actions.conf app.conf audit.conf authentication.conf authorize.conf collections.conf commands.conf crawl.conf datamodels.conf datatypesbnf.conf default.meta.conf default-mode.conf deployment.conf deploymentclient.conf distsearch.conf eventdiscoverer.conf event_renderers.conf eventtypes.conf fields.conf indexes.conf inputs.conf instance.cfg.conf limits.conf literals.conf macros.conf multikv.conf outputs.conf pdf_server.conf procmon-filters.conf props.conf pubsub.conf restmap.conf savedsearches.conf searchbnf.conf segmenters.conf server.conf serverclass.conf serverclass.seed.xml.conf setup.xml.conf source-classifier.conf sourcetype_metadata.conf sourcetypes.conf splunk-launch.conf tags.conf

5 tags.conf tenants.conf times.conf transactiontypes.conf transforms.conf ui-prefs.conf user-prefs.conf user-seed.conf viewstates.conf web.conf wmi.conf workflow_actions.conf

6 Splunk Enterprise 관리 소개 매뉴얼 사용 방법 이 매뉴얼에서는 Splunk를 관리할 수 있는 여러 가지 방법에 대해 설명하고, Windows 및 *nix에 대한 초기 관리 작업도 몇 가지 소개합니다. 참고: 달리 지정하지 않는 한 이 매뉴얼에서 설명하는 작업 및 프로세스는 Windows 및 *nix 운영 체제에 모두 해당됩니다. 이 매뉴얼에서 설명되지 않은 작업(사용자 설정 또는 데이터 및 보안 설정 등)을 포함하여 Splunk 관리 프로세스를 더 넓은 관점에서 보려면 이 매뉴얼의 "Splunk 관리: 전체 개요"를 참조하십시오. Splunk 사용자에게 제공되는 기타 매뉴얼 리스트와 간단한 설명은 "기타 Splunk 관리자용 매뉴얼"을 참조하십시오. 관리 매뉴얼을 통해 수행 가능한 작업 작업 Splunk 시작 및 일부 초 기 설정 작업 수행 Splunk Web을 사용한 Splunk 설정 및 관리 설정 파일을 사용한 Splunk 설정 및 관리 Splunk 명령줄 인터페이 스(CLI)를 사용한 Splunk 설정 및 관리 Windows에서 Splunk 최적화 Splunk 라이선스에 대해 알아보기 Splunk 앱 소개 사용자 설정 관리 관련 항목 Splunk에서 시작하기 위해 해야 하는 모든 작업. Splunk를 시작하고 라이선스를 설치한 후 Splunk를 IP에 바인딩하는 등의 작업이 모두 포함됩니다. 자세한 내용 은 "선행 작업"을 참조하십시오. Splunk Web 개요와 Splunk Web을 사용하여 Splunk를 관리할 수 있는 방법. 자 세한 내용은 "Splunk Web 사용"을 참조하십시오. 설정 파일에 대한 설명으로, 설정 파일의 위치, 작성 및 편집 방법, 파일 우선 순위 에 대한 몇 가지 중요한 정보. 시작하려면 "설정 파일에 대하여"를 참조하십시오. 명령줄 인터페이스를 사용하여 Splunk를 설정하는 방법에 대한 개요. 자세한 내용 은 "CLI에 대하여"를 참조하십시오. Windows에서 Splunk를 사용하여 작업할 때 알아야 하는 몇 가지 정보. 최적 배포 를 위한 추가 정보와 시스템 이미지를 사용하는 작업 수행에 대한 내용이 포함됩 니다. 자세한 내용은 "Windows 관리자를 위한 지침"을 참조하십시오. 라이선스를 설치한 후 "Splunk 라이선스 관리"로 이동하여 Splunk 라이선스에 대 해 알아야 하는 모든 내용을 확인하십시오. Splunk 앱에 대한 소개 및 개요, Splunk 앱을 Splunk에 설치하는 방법. 자세한 내 용은 "Splunk 앱 정보"를 참조하십시오. 사용자 관리 장에는 사용자에 대한 설정을 관리하는 방법이 나와 있습니다. 사용자 만들기에 대한 자세한 내용은 Splunk Enterprise 보안 매뉴얼에서 사용자 및 역할 기반 액세스 제어를 참조하십시오. Splunk 관리: 전체 개요 이 관리자 매뉴얼에서는 초기 관리 작업에 대한 정보와 Splunk를 관리하기 위해 사용할 수 있는 다양한 방법에 대한 정보를 제공합니다. (관리자 매뉴얼을 사용하여 수행할 수 있는 작업에 대한 보다 구체적인 개요는 매뉴얼 사용 방법을 참조하십시 오.) Splunk 관리는 이 매뉴얼에 언급된 초기 작업보다 훨씬 다양하고 복잡하므로, Splunk에서 제공되는 여러 설명서를 살펴봐야 합니다. 아래에는 초기 설정 후 수행할 수 있는 관리 작업과 자세한 내용을 확인하기 위해 참고할 수 있는 자료가 나와 있습니다. 백업 수행 경고 정의 검색 작업 관리 작업 설정 정보 백업 인덱스된 데이터 백업 폐기 및 아카이브 정책 설정 경고 정의 작업 페이지에서 작업 감독 관련 항목 관리에 대한 추가 도움말은 아래 매뉴얼을 참조하십시오. Splunk 설치 및 업그레이드 설치 매뉴얼에서는 Splunk 설치 및 업그레이드 방법을 설명합니다. 관련 작업에 대한 내용은 다음을 참조하십시오. 6

7 작업 설치 요구 사항 이해 하드웨어 용량 요구 평가 Splunk 설치 Splunk 업그레이드 설치 계획 하드웨어 요구 사항 평가 관련 항목 Windows에 Splunk 설치 Unix, Linux 또는 MacOS에 Splunk 설치 이전 버전에서 업그레이드 Splunk로 데이터 가져오기 데이터 가져오기에서는 Splunk 데이터 입력에 대한 정보, 즉 외부 source에서 가져온 데이터를 활용하는 방법과 데이터의 가치를 높이는 방법을 확인할 수 있습니다. 작업 외부 데이터 사용 방법에 대한 정보 파일 및 디렉터리 입력 설정 네트워크 입력 설정 Windows 입력 설정 기타 입력 설정 데이터 가치 높이기 인덱싱 후 데이터가 어떻게 표시되는지 알아보기 프로세스 개선 관련 항목 Splunk로 데이터를 가져오는 방법 파일 및 디렉터리에서 데이터 가져오기 네트워크 이벤트 가져오기 Windows 데이터 가져오기 데이터를 가져오는 다른 방법 이벤트 처리 설정 타임스탬프 설정 인덱스 필드 추출 설정 host 값 설정 source type 설정 이벤트 세그먼트화 관리 룩업 및 워크플로 작업 사용 데이터 미리 보기 데이터 입력 프로세스 개선 인덱스 관리 인덱서 및 클러스터 관리에서는 인덱스 설정 방법을 설명합니다. 또한 인덱스를 유지 관리하는 구성 요소인 인덱서와 인덱서 의 클러스터를 관리하는 방법에 대해서도 설명합니다. 작업 인덱싱에 대해 알아보기 인덱스 관리 인덱스 저장소 관리 인덱스 백업 인덱스 아카이브 클러스터 및 인덱스 복제에 대해 알아보기 클러스터 배포 클러스터 설정 클러스터 관리 클러스터 아키텍처에 대해 알아보기 관련 항목 인덱싱 개요 인덱스 관리 인덱스 저장소 관리 인덱스 데이터 백업 폐기 및 아카이브 정책 설정 클러스터 및 인덱스 복제에 대하여 클러스터 배포 클러스터 설정 클러스터 관리 클러스터 작동 방식 Splunk 확장 분산 배포 매뉴얼에서는 포워더, 인덱서, 검색 헤드 등의 여러 구성 요소에 Splunk 기능을 분산하는 방법에 대해 설명합니다. 관련 매뉴얼에서는 분산 구성 요소에 대해 자세히 다룹니다. 데이터 포워딩 매뉴얼에서는 포워더에 대해 설명합니다. 분산 검색 매뉴얼에서는 검색 헤드에 대해 설명합니다. Splunk 구성 요소 업데이트 매뉴얼에서는 배포 서버와 포워더 관리를 사용하여 배포를 관리하는 방법에 대해 설명합 니다. 작업 분산 Splunk에 대해 알아보기 분산 Splunk 개요 7 관련 항목

8 Splunk 배포를 위한 용량 계획 수행 데이터 포워딩 방법에 대해 알아보기 다중 인덱서에 검색 분산 배포 업데이트 하드웨어 요구 사항 평가 데이터 포워딩 다중 인덱서에서 검색 업데이트된 설정의 배포 Splunk 보안 Splunk 보안에서는 Splunk 배포에 대한 보안 방법을 설명합니다. 작업 사용자 및 편집 역할 인증 SSL을 사용하여 Splunk 데이터 보안 Splunk 감사(Audit) Splunk에서 SSO(Single Sign-On) 사용 Splunk에서 LDAP 사용 관련 항목 사용자 및 역할 기반 액세스 제어 보안 인증 및 암호화 Splunk 작업 감사(Audit) SSO(Single Sign-On) 설정 LDAP를 사용하는 사용자 인증에 대한 설정 Splunk 문제 해결 문제 해결 매뉴얼에서는 Splunk 문제 해결에 대한 전체적인 가이드를 제공합니다. 또한 다른 매뉴얼의 항목에서도 특정 문제 에 대한 문제 해결 정보를 제공합니다. 작업 Splunk 문제 해결 도구에 대해 알아보기 Splunk 로그 파일에 대해 알아보기 Splunk Support 작업 수행 일반적인 문제 해결 관련 항목 첫 단계 Splunk 로그 파일 Splunk Support 문의 일반 시나리오 참조 및 기타 정보 Splunk 설명서에는 Splunk 관리자에게 필요할 수 있는 다른 source의 정보뿐만 아니라 여러 유용한 참조가 포함되어 있습니 다. 참조 설정 파일 참조 REST API 조회 CLI 도움말 릴리스 정보 Splunk knowledge 관리에 대한 정보 관련 항목 관리자 매뉴얼의 설정 파일 참조 REST API 조회 매뉴얼 Splunk 인스턴스를 설치할 경우 사용할 수 있습니다. 이 도움말의 실행 방법에 대한 자세한 내용은 관리자 매뉴얼의 CLI 도움말 보기에서 확인하십시오. 릴리스 노트 knowledge 관리자 매뉴얼 기타 Splunk 관리자용 매뉴얼 관리자 매뉴얼은 Splunk 관리자에게 중요한 정보와 절차가 수록되어 있는 여러 문서 중 하나입니다. 그러나 이 매뉴얼에 수 록된 내용은 Splunk로 할 수 있는 일의 시작에 불과합니다. 본인이나 다른 사용자를 위해 Splunk를 서비스로 설정 및 실행하고 유지 관리해야 할 경우에는 이 문서를 먼저 읽어보십시 오. Splunk 관리에 대한 자세한 내용은 다음 매뉴얼을 참조하십시오. 매뉴얼 내용 주요 항목 데이터 가져오기 데이터 입력 지정 및 Splunk에서 데이터를 처리하는 방법 개선 Splunk로 데이터를 가져 오는 방법 이벤트 처리 설정 데이터 미리 보기 인덱서 및 클러스터 관리 Splunk 인덱서 및 인덱서의 클러스터 관리 8 인덱싱 및 인덱서에 대하 여 인덱스 관리 인덱스 백업 및 아카이브 클러스터 및 인덱스 복제

9 에 대하여 클러스터 배포 분산 배포 기업의 필요에 맞게 배포 규모 확장 분산 Splunk 개요 데이터 포워딩 Splunk로 데이터 포워딩 데이터 포워딩 분산 검색 검색 헤드를 사용하여 검색을 여러 인덱서에 걸쳐 분산시키는 방법 다중 인덱서에서 검색 Splunk 구성 요소 업데이트 배포 서버와 포워더 관리를 사용하여 포워더와 인덱서 등의 Splunk 구성 요소를 업데이트하는 방법 사용자 환경에 업데이트 배포 Splunk 보안 데이터 보안 및 사용자 인증 사용자 인증 및 역할 SSL을 사용하여 암호화 및 인증 감사(audit) 문제 해결 문제 해결 첫 단계 Splunk 로그 파일 일반 시나리오 설치 Splunk 설치 및 업그레이드 시스템 요구 사항 단계별 설치 절차 이전 버전에서 업그레이 드 "Splunk 관리 방법" 항목에서는 특정 관리 작업에 대해 설명하는 문서에 대한 보다 상세한 가이드를 제공합니다. Splunk 관리자에게 유용한 기타 참조 문서 Splunk 설치 크기와 사용자가 담당하는 작업에 따라 주요 관리 작업에 대한 매뉴얼 외에도 다른 매뉴얼이 때때로 필요할 수 있습니다. 다음은 Splunk 주요 설명서에 포함되는 다른 매뉴얼입니다. Splunk 튜토리얼! 이 매뉴얼에서는 Splunk를 사용한 검색에 대해 소개합니다. Knowledge 관리자. 이 매뉴얼에서는 event type, 태그, 룩업, 필드 추출, 워크플로 작업, 저장된 검색, 뷰 등의 Splunk knowledge 객체를 관리하는 방법에 대해 설명합니다. 경고. 이 매뉴얼에서는 Splunk 경고 및 모니터링 기능에 대해 설명합니다. 데이터 시각화. 이 매뉴얼에서는 Splunk가 제공하는 시각화 범위를 설명합니다. 검색. 이 매뉴얼에서는 검색 방법과 Splunk 검색 언어 사용 방법에 대해 설명합니다. 검색 참조. 이 매뉴얼에는 Splunk 검색 명령어에 대한 상세 카탈로그가 포함되어 있습니다. Splunk Web용 뷰 및 앱 개발. 이 매뉴얼에서는 고급 XML을 사용하여 뷰 및 앱을 개발하는 방법에 대해 설명합니다. 사용자 지정 스크립트와 Splunk 확장과 같은 기타 개발자 항목도 포함되어 있습니다. REST API 조회. 이 매뉴얼에서는 공개적으로 액세스 가능한 모든 REST API endpoint에 대한 정보를 제공합니다. 릴리스 노트. 새로운 기능, 알려진 문제 및 해결된 문제에 대한 정보를 제공합니다. 전체 Splunk 설명서 위에 나열한 매뉴얼을 포함한 Splunk 주요 설명서 전체에 대한 링크는 Splunk 주요 설명서에서 확인하십시오. 앱 매뉴얼을 포함한 모든 Splunk 설명서에 액세스하려면 Splunk 설명서 소개 페이지를 참조하십시오. PDF 만들기 이 매뉴얼의 PDF 버전이 필요할 경우 이 페이지 왼쪽의 목차 아래에 있는 빨간색 관리자 매뉴얼을 PDF로 다운로드 링크를 클릭하십시오. 해당 매뉴얼의 PDF 버전이 즉시 생성됩니다. 생성된 PDF는 나중에 볼 수 있도록 저장하거나 인쇄할 수 있습 니다. Windows 관리자를 위한 지침 환영합니다! Splunk는 Windows 관리자가 Windows 네트워크에서 발생하는 문제를 해결할 수 있는 효과적이고 강력한 도구입니다. Splunk 설치 후 바로 사용할 수 있는 기능은 Windows 관리자에게 아주 유용합니다. 또한 기능을 확장할 수 있는 앱을 추가 할 수 있으며, 이 앱들은 지속적으로 개발되고 있습니다. Windows 사용자를 위한 매뉴얼 사용 방법 이 매뉴얼은 Splunk를 학습 및 배포하고 Splunk 기능을 최대한 이용하는 데 유용한 항목으로 구성되어 있습니다. 별도로 지정하지 않으면 이 매뉴얼에 수록된 내용은 Windows 및 *nix 사용자에게 모두 유용합니다. Windows 또는 *nix 작업 명령에 익숙하지 않은 사용자는 Splunk 작업에서 *nix와 Windows의 차이점을 확인하는 것이 좋습니다. "Windows에서 Splunk 최대한 활용하기" 장에도 몇 가지 추가 정보가 수록되었습니다. 이 장은 Windows 사용자가 Splunk 를 최대한 활용하는 데 도움이 되도록 작성되었으며, 다음과 같은 내용을 포함합니다. Windows에 Splunk 배포에서는 Windows 사용자에게 해당되는 몇 가지 고려사항과 준비사항에 대해 설명합니다. 배포를 9

10 계획할 때 이 항목을 사용하십시오. Splunk를 최고 성능으로 최적화하는 방법에서는 Windows에 배포한 Splunk가 배포 과정 중이나 배포가 완료된 후 계속 올 바르게 실행되도록 하는 방법을 설명합니다. 시스템 이미지에 Splunk 배치 항목은 Splunk를 모든 Windows 시스템 이미지 또는 설치 프로세스의 일부로 만드는 데 도움 이 됩니다. 여기서 Splunk와 Splunk 포워더를 시스템 이미지에 설치하기 위해 필요한 작업을 확인할 수 있습니다. 참고 항목 다른 Splunk 매뉴얼에 추가된 Windows 관련 항목은 다음과 같습니다. 설치된 모든 Splunk for Windows 서비스에 대한 개요(설치 매뉴얼 참조) Splunk의 모니터 대상(데이터 가져오기 매뉴얼 참조) 원격 Windows 데이터를 모니터링하는 방법을 결정할 때 고려할 사항(데이터 가져오기 매뉴얼 참조). 여러 컴퓨터의 데이터를 원격으로 가져오는 방법에 대한 중요한 정보는 이 항목에서 확인하십시오. 여러 컴퓨터의 데이터 통합(데이터 포워딩 매뉴얼 참조) 기타 유용한 정보: 내 데이터는 어디에 있습니까? (데이터 가져오기 매뉴얼 참조) Splunk 명령줄 인터페이스(CLI) 사용(데이터 가져오기 매뉴얼 참조) source, sourcetype 및 필드(데이터 가져오기 매뉴얼 참조) 필드 및 필드 추출(knowledge 관리자 매뉴얼 참조) 실시간 검색(사용자 매뉴얼 참조) 저장된 검색(사용자 매뉴얼 참조) 대시보드 생성(사용자 매뉴얼 참조) 도움이 필요한 경우 Splunk knowledge에 대해 상세히 알려는 경우 많은 교육 프로그램이 준비되어 있습니다. Splunk를 본격적으로 시작하게 되면 이용할 수 있는 대형 무료 지원 인프라가 제공됩니다. Splunk 응답 페이지 Splunk 커뮤니티 위키 Splunk IRC(Internet Relay Chat) 채널(EFNet splunk) (IRC 클라이언트 필수) 질문에 대한 답변이 여전히 없는 경우에는 Splunk 지원 팀에 연락하십시오. 지원 문의 페이지에 문의 방법이 자세히 나와 있 습니다. 참고: 커뮤니티 수준보다 높은 지원 수준을 이용하려면 Enterprise 라이선스가 필요합니다. 이 라이선스를 받으려면 판매 팀 에 문의해야 합니다. Splunk Free에 대하여 Splunk Free는 Splunk의 무료 버전입니다. 하루에 최대 500MB까지 인덱싱할 수 있고 만료 기한이 없습니다. 500MB 제한은 하루에 추가(인덱싱)할 수 있는 새 데이터의 양이지만, 더 많은 데이터를 매일 계속 추가하고 데이터를 원하 는 만큼 저장할 수 있습니다. 예를 들어, 하루에 500MB의 데이터를 추가할 수 있으며 최종적으로 Splunk에 10TB의 데이터 를 저장할 수 있습니다. 하루에 500MB보다 많은 데이터가 필요한 경우 라이선스를 구입해야 합니다. 라이선싱에 대한 자세한 내용은 Splunk 라이 선싱 방식을 참조하십시오. Splunk는 라이선스 위반을 추적하여 라이선스 사용을 규제합니다. 30일 동안 4번 이상 1일 500MB 제한을 초과할 경우, Splunk는 데이터를 계속 인덱싱하지만 30일 동안 3번 이하로 경고 수를 줄일 때까지 검색 기능을 사용할 수 없게 됩니다. Splunk Free 용도 Splunk Free는 IT 데이터의 개인, 임시 검색 및 시각화에 적합합니다. 하루 500MB 미만의 작은 볼륨의 데이터 인덱스가 계 속 있는 경우에는 Splunk Free를 사용할 수 있습니다. 또한 대용량 데이터 집합의 단기간 대량 로드 및 분석에 사용할 수 있 으며, Splunk Free는 30일 동안 최대 3번까지 대용량 데이터의 활용을 허용합니다. 이 기능은 대용량 데이터의 포렌식 검토 에 사용할 수 있습니다. Splunk Free에 포함된 기능 Splunk Free는 단일 사용자 제품으로, 다음을 제외한 모든 Splunk 기능이 지원됩니다. Splunk Free에서는 클러스터나 분산 검색 설정을 설정할 수 없습니다. TCP/HTTP 형식으로 포워딩하는 기능을 사용할 수 없습니다. 즉, 다른 Splunk 인스턴스로 데이터를 포워딩할 수 있지 만 비 Splunk 인스턴스로는 포워딩할 수 없습니다. 배포 관리 기능을 사용할 수 없습니다. 경고/모니터링 기능을 사용할 수 없습니다. 인덱서 클러스터링을 사용할 수 없습니다. 10

11 보고서 가속화 요약을 사용할 수 없습니다. Splunk Free 인스턴스는 (Splunk Enterprise 인덱서로 포워딩하는) 포워더로 사용할 수 있지만 배포 서버의 클라이언 트는 될 수 없습니다. Splunk Free에서는 인증이나 사용자 및 역할 관리 기능을 사용할 수 없습니다. 그 의미는 다음과 같습니다. 로그인 기능이 없기 때문에 명령줄 또는 브라우저에서 별도의 로그인 없이 Splunk Free의 모든 기능을 액세스 하고 제어할 수 있습니다. 모든 액세스는 관리자와 동일하게 가능하고 admin 역할만 있으며 다른 역할은 설정이 불가능합니다. 또한 더 많 은 역할을 추가하거나 사용자 계정을 만들 수 없습니다. 모든 공용 인덱스에서 검색이 실행됩니다('index=*'). 사용자 할당량, 최대 검색별 시간 범위 및 검색 필터와 같은 검색 제한 기능은 지원되지 않습니다. 기능 시스템이 비활성화되어 있지만 Splunk Free에 액세스하는 모든 사용자에 대한 모든 기능은 활성화되어 있 습니다. Enterprise 평가판 라이선스에서 Free 라이선스로 전환 Splunk를 처음 다운로드하고 설치하면 Enterprise 평가판 라이선스를 자동으로 사용하게 됩니다. 사용자의 요구 사항에 따 라 Enterprise 평가판 라이선스가 만료될 때까지 Enterprise 평가판을 계속 사용하거나 Free 라이선스로 전환할 수 있습니 다. Free 라이선스로 전환할 때 알아야 할 사항 Splunk Enterprise 평가판을 사용하면 Splunk Free에서 사용할 수 없는 많은 기능에 액세스할 수 있습니다. Free 라이선스 로 전환할 경우 다음 내용을 참고하십시오. 평가판에서 만든 사용자 계정이나 역할은 더 이상 사용할 수 없습니다. Free 인스턴스로 연결하는 사용자는 모두 '관리자'로 자동 로그인됩니다. 업데이트 확인은 표시되지만 로그인 화면은 더 이상 나타나지 않습니다. '관리자'가 아닌 사용자가 만든 knowledge 객체(예: event type, transaction, source type 정의) 및 전역 공유되지 않은 개체는 사용할 수 없습니다. Splunk Free로 전환한 후에도 이러한 knowledge 객체를 계속 사용하려면 다음 작업 중 하나를 수행하십시오. 이 항목의 내용에 따라 Splunk Web을 이용하여 해당 knowledge 객체를 전체적으로 사용할 수 있도록 권한을 수정합니다. 해당 knowledge 객체의 권한을 수정하려면 여기에 나온 설명대로 설정 파일을 직접 편집합니다. 대시보드 및 요약 인덱싱을 위해 실행할 검색을 계속 예약할 수는 있지만 정의한 경고는 더 이상 작동하지 않습니다. Splunk로부터 더 이상 경고를 수신하지 않게 됩니다. TCP 또는 HTTP 형식으로 타사 애플리케이션에 포워딩할 수 있는 outputs.conf 설정이 작동하지 않습니다. Enterprise 평가판 라이선스를 사용하는 동안 Splunk Web에서 상기 설정을 수정 적용하려고 하면 Splunk Free에서 해당 제한에 대한 경고가 발생합니다. Splunk Free로 전환하는 방법 현재 Splunk Enterprise(평가판 포함)를 사용 중이면 Enterprise 라이선스가 만료될 때까지 기다리거나 언제든지 Free 라이 선스로 전환할 수 있습니다. Free 라이선스로 전환하려면 다음 작업을 수행하십시오. 1. Splunk Web에 관리 권한을 가진 사용자로 로그인하고 설정 > 라이선싱으로 이동합니다. 2. 페이지 상단에 있는 라이선스 그룹 변경을 클릭합니다. 3. Free 라이선스를 선택하고 저장을 클릭합니다. 4. 재시작하라는 메시지가 나타납니다. Splunk 작업에서 *nix와 Windows의 차이점 이 항목에서는 Splunk 작업 시 *nix와 Windows 운영 체제에서 발생하는 기능적 차이점에 대해 명확히 설명합니다. 두 OS에 대한 기술적 비교나 두 OS 중 한쪽을 옹호하는 것이 아니라 특정 OS 관련 Splunk 매뉴얼의 여러 페이지에 여러 방법으로 참 조되는 이유에 대해 설명합니다. 경로 11

12 *nix 운영 체제에서 파일과 디렉터리를 처리하는 방식의 큰 차이점은 경로 이름의 파일 또는 디렉터리를 구분하기 위해 사용 하는 슬래시 유형입니다. *nix 시스템에서는 슬래시("/")를 사용하고, Windows에서는 백슬래시("\")를 사용합니다. *nix 경로의 예: /opt/splunk/bin/splunkd Windows 경로의 예: C:\Program Files\Splunk\bin\splunkd.exe 환경 변수 운영 체제에 따라 환경 변수의 표시 방법이 다릅니다. 두 시스템은 모두 하나 이상의 환경 변수에 데이터를 일시적으로 저장 하는 방식을 사용합니다. *nix 시스템에서는 다음과 같이 환경 변수 이름 앞에 달러 기호("$")를 사용합니다. SPLUNK_HOME=/opt/splunk; export $SPLUNK_HOME Windows에서 환경 변수를 지정하는 방식은 약간 다릅니다. 퍼센트 기호("%")를 사용해야 합니다. 사용할 환경 변수 유형에 따라 환경 변수 이름 앞에, 또는 이름 앞이나 뒤에 한 두 개의 퍼센트 기호를 입력합니다. > set SPLUNK_HOME="C:\Program Files\Splunk" > echo %SPLUNK_HOME% C:\Program Files\Splunk > Windows 환경에서 %SPLUNK_HOME% 변수를 설정하려면 다음 두 가지 방법 중 하나를 사용하십시오. %SPLUNK_HOME%\etc에서 splunk-launch.conf를 편집합니다. "환경 변수" 창에 액세스하여 변수를 설정합니다. 탐색기 창을 열고 왼쪽 창에서 마우스 오른쪽 단추로 "내 컴퓨터"를 클릭한 후 나타나는 창에서 "속성"을 선택합니다. 시스템 속성 창이 나타나면 "고급" 탭을 선택한 후 탭의 창 하단에 나 타나는 "환경 변수" 단추를 클릭합니다. Splunk 설정 방법 Splunk는 여러 설정 파일을 이용하여 설정 정보를 유지 관리합니다. 다음과 같은 방법으로 Splunk를 설정할 수 있습니다. Splunk Web 사용 Splunk 명령줄 인터페이스(CLI) 명령어 사용 Splunk 설정 파일 직접 편집 Splunk REST API를 이용하여 설정을 업데이트하는 앱 설정 방법 기본적으로 설정 파일의 내용을 수정하여 변경합니다. 각 방법은 상황에 따라 다를 수 있습니다. Splunk Web 사용 Splunk Web에서는 일반적인 설정 작업을 대부분 수행할 수 있습니다. Splunk Web은 기본적으로 Splunk가 설치되어 있는 호스트의 포트 8000에서 실행됩니다. 로컬 컴퓨터에서 Splunk를 실행하는 경우, Splunk Web에 액세스하는 URL은 원격 컴퓨터에서 Splunk를 실행하는 경우, Splunk Web에 액세스하는 URL은 여기서 <hostname>은 Splunk가 실행되고 있는 컴퓨터의 이름입니다. 관리 메뉴는 Splunk Web 메뉴 모음의 설정에 있습니다. Splunk 설명서 집합에서는 Splunk Web을 기준으로 대부분의 작업 을 설명합니다. Splunk Web에 대한 자세한 내용은 Splunk Web 정보를 참조하십시오. 설정 파일 편집 Splunk의 설정 정보는 대부분.conf 파일에 저장됩니다. 이러한 파일은 Splunk 설치 디렉터리(설명서에서는 주로 언급되는 $SPLUNK_HOME) 아래 /etc/system에 위치합니다. 대부분의 경우에는 각 파일을 로컬 디렉터리에 복사하고 원하는 텍스트 편집 기를 사용하여 파일을 수정할 수 있습니다. 설정 파일 편집을 시작하기 전에 "설정 파일에 대하여"를 읽어보십시오. Splunk CLI 사용 많은 설정 옵션은 CLI를 통해 사용할 수 있습니다. 각 옵션에 대한 설명은 이 매뉴얼의 CLI 관련 장을 참조하십시오. Splunk 가 실행되는 중에 help 명령어를 사용하여 CLI 도움말을 참조할 수도 있습니다../splunk help 12

13 CLI에 대한 자세한 내용은 이 매뉴얼의 "CLI에 대하여"를 참조하십시오. CLI 명령에 대해 잘 모르거나 Windows 환경에서 작 업을 수행할 경우에는 Splunk 작업에서 *nix와 Windows의 차이점도 참조하십시오. 앱의 설정 화면 개발자는 사용자가 설정 파일을 직접 편집하지 않고도 앱 구성을 설정하는 화면을 구성할 수 있습니다. 설정 화면을 통해 앱 을 다른 환경으로 배포하거나 특별한 용도로 사용하기 위해 앱의 사용자를 등록할 수 있습니다. 설정 화면에서 Splunk REST API를 사용하여 앱 설정 파일을 관리합니다. 설정 화면에 대한 자세한 내용은 Splunk Web용 뷰 및 앱 개발 매뉴얼의 "앱 설정 화면 설정"을 참조하십시오. 분산 환경 관리 Splunk 배포 서버는 분산 환경을 위한 중앙 관리 방법 및 설정을 제공합니다. 이 배포 서버를 사용하여 설정 파일이나 다른 콘 텐츠를 시스템 전체의 Splunk 인스턴스 그룹으로 배포할 수 있습니다. 배포 관리에 대한 내용은 "Splunk 구성 요소 업데이트" 매뉴얼을 참조하십시오. Windows에서 Splunk Enterprise 최대한 활용하기 Windows에 Splunk 배포 여러 가지 방법으로 Windows 환경에 Splunk를 통합할 수 있습니다. 이 항목에서는 몇 가지 시나리오를 설명하고, 엔터프라 이즈에 Splunk for Windows 배포를 최적으로 적용하는 방법에 대한 지침을 제공합니다. 이 항목은 Windows 환경에 Splunk를 배포하는 데 초점을 맞추고 있습니다. 또한 Splunk 자체가 Windows 엔터프라이즈에 Splunk를 통합할 때 배포 기능을 분산합니다. 분산 배포 매뉴얼은 수많은 컴퓨터에 Splunk 서비스를 배포하는 것에 대한 많 은 정보를 제공합니다. 대규모 환경에서 Windows에 Splunk를 배포할 때 자체 배포 유틸리티(예: System Center Configuration Manager 또는 Tivoli/BigFix)를 사용하여 Splunk 및 Splunk 설정을 모두 엔터프라이즈의 컴퓨터에 배포할 수 있습니다. 또는 Splunk를 시스 템 이미지에 통합한 후 Splunk의 배포 서버를 사용하여 Splunk 설정과 앱을 배포할 수 있습니다. 개념 Splunk를 Windows 네트워크에 배포할 경우 Splunk는 컴퓨터에서 데이터를 수집한 후 중앙에 저장합니다. 데이터가 중앙에 저장되어 있으면 인덱스된 데이터를 기반으로 보고서와 대시보드를 검색하고 만들 수 있습니다. 시스템 관리자 입장에서 더 중요한 것은 데이터가 도착할 때 어떤 일이 발생하는지 알 수 있게 Splunk가 경고를 보낼 수 있다는 점입니다. 일반적인 배포에서는 인덱싱 용도로 사용할 전용 하드웨어를 Splunk에 지정한 다음 유니버설 포워더와 WMI(Windows Management Instrumentation)를 함께 사용하여 엔터프라이즈의 다른 컴퓨터에서 데이터를 수집합니다. 고려 사항 Windows 엔터프라이즈에 Splunk를 배포하려면 수많은 계획 단계가 필요합니다. 먼저, 물리적 네트워크에서 시작하여 해당 네트워크의 컴퓨터를 개별적으로 설정하는 방법에 이르기까지 엔터프라이즈를 인 벤토리해야 합니다. 다음과 같은 작업을 수행해야 합니다. 환경에 있는 컴퓨터 개수를 세고 Splunk를 설치해야 하는 컴퓨터의 서브셋을 정의합니다. 이렇게 하면 Splunk 토폴로 지의 초기 프레임워크가 정의됩니다. 기본 사이트 및 원격 또는 외부 사이트에서 모두 네트워크 대역폭을 계산합니다. 이 작업을 수행하면 기본 Splunk 인스 턴스를 설치할 위치와 Splunk 포워더 설치 위치 및 사용 방식이 결정됩니다. 특히, 네트워크가 구분되는 영역에서 네트워크의 현재 상태를 평가합니다. 에지 라우터 및 스위치가 올바르게 작동해 야 배포 중과 배포 후에 네트워크 성능 기준을 설정할 수 있습니다. 다음으로, 배포를 시작하기 전에 다음과 같은 질문에 대한 답을 생각해야 합니다. 컴퓨터의 어떤 데이터를 인덱싱해야 하는가? 검색, 보고, 경고하려는 것이 이 데이터의 어떤 부분인가? 이것은 배포를 고려할 때 가장 중요한 고려 사항일 것입니다. 이러한 질문에 대한 답은 다른 고려 사항을 어떻게 처리할지 결정합니 다. Splunk를 설치할 위치와 이 설치에 사용할 Splunk 유형을 결정하고, Splunk에서 잠재적으로 사용하게 되는 컴퓨팅 및 네트워크 대역폭도 결정합니다. 네트워크가 어떻게 배치되었나? 외부 사이트 링크가 어떻게 설정되었나? 이러한 링크에 어떤 보안이 제공되는가? 네 트워크 토폴로지에 대한 완벽한 이해는 Splunk를 어떤 컴퓨터에 설치하고, 네트워크 관점에서 해당 컴퓨터에 어떤 유 형의 Splunk(인덱서 또는 포워더)를 설치할지 쉽게 결정할 수 있습니다. 씬 타입 LAN 또는 WAN으로 구성되어 있는 사이트의 경우에는 사이트 간에 전송되는 데이터 양을 고려해야 합니다. 예를 들 어, 중앙 사이트가 지사 사이트에 연결된 hub-and-spoke 유형의 네트워크인 경우에는 지사 사이트의 컴퓨터에 포워더를 배 포하는 것이 더 좋을 수도 있습니다. 이렇게 하면 각 지사의 중간 포워더로 데이터가 전송됩니다. 그런 다음, 중간 포워더가 데이터를 중앙 사이트로 다시 보냅니다. 이 방법은 지사 사이트의 모든 컴퓨터에서 중앙 사이트의 인덱서로 데이터를 직접 포워딩하는 것보다 설정이 용이합니다. 13

14 파일, 인쇄 또는 데이터베이스 서비스를 사용하는 외부 사이트인 경우에는 트래픽도 고려해야 합니다. AD(Active Directory)가 어떻게 설정되었나? 도메인 컨트롤러(DC)에서 작업 마스터 역할이 어떻게 정의되었나? 모 든 도메인 컨트롤러가 중앙에 있는가? 또는 위성 사이트에 위치한 컨트롤러를 가지고 있는가? AD가 분산되어 있는 경우 브리지헤드 서버가 올바르게 설정되었는가? ISTG(Inter-site Topology Generator) 역할 서버가 제대로 작동하는 가? Windows Server 2008 R2를 실행 중인 경우 지사 사이트에 RODC(읽기 전용 도메인 컨트롤러)가 있는가? 해당 될 경우 Splunk 및 기타 네트워크 트래픽뿐만 아니라 AD 복제 트래픽의 영향도 고려해야 합니다. 네트워크의 서버들은 어떤 다른 역할을 하는가? Splunk 인덱서는 최고 성능으로 실행하기 위해 리소스가 필요합니다. 다른 리소스 집약 애플리케이션이나 서비스(예: Microsoft Exchange, SQL Server, Active Directory 자체)와 서버를 공유할 경우 해당 컴퓨터에 설치된 Splunk에 잠재적으로 문제가 발생할 수 있습니다. Splunk 인덱서와의 서버 리소스 공유에 대한 자세한 내용은 용량 계획 매뉴얼의 "Splunk Enterprise를 위한 용량 계획 소개"를 참조하십시오. 사용자들과 배포에 대해 어떻게 커뮤니케이션할 것인가? Splunk가 어떻게 설치되어 있는지에 따라서 장비에 설치된 소프트웨어의 환경이 바뀌게 됩니다. 사용자들은 Splunk의 설치 때문에 장비에 문제가 발생했거나 속도가 느려졌다고 생각할 수 있습니다. 이러한 지원 문의를 최소화하기 위해서는 사용자들이 변경 사항에 대해 항상 알 수 있어야 합니 다. Windows 배포에서 Splunk 준비 Splunk를 기존 환경에 어떻게 배치하는지는 Splunk에 대한 요구에 따라 다릅니다. 사용 가능한 컴퓨팅 리소스, 물리적 레이 아웃 및 네트워크 레이아웃 그리고 회사 인프라와의 균형을 맞춰야 합니다. Splunk를 배포하는 방법이 하나만 있는 것이 아 니므로 따라야 할 단계별 지침은 없지만 준수해야 할 일반적인 지침은 있습니다. 성공적인 Splunk 배포를 위한 지침: 네트워크를 준비합니다. Splunk를 환경에 통합하기 전: 네트워크가 올바르게 작동해야 하고 모든 스위치, 라우터 및 배선이 올바르게 설정되어 있어야 합니다. 고장났거나 결함이 있는 장비는 교체합니다. 모든 VLAN(가상 LAN)이 올바르게 설정되어야 합니다. 특히, 씬 네트워크 링크가 있는 사이트 간의 네트워크 처리량을 테스트합니다. Active Directory를 준비합니다. AD가 Splunk를 실행하는 데 필수적인 사항은 아니지만 배포 전에 AD가 올바르게 작동하는지 확인하는 것이 좋습니다. 다음과 같은 작업을 수행해야 합니다. 모든 도메인 컨트롤러 및 작업 마스터 역할 식별. 지사 사이트에 RODC가 있는 경우, 작업 마스터 도메인 컨트롤 러에 최대한 가장 빠른 연결을 제공해야 합니다. AD 복제가 올바르게 작동하고 모든 사이트 링크에는 전역 카탈로그의 복사본이 있는 도메인 컨트롤러가 있어 야 합니다. 포리스트(forest)가 다수일 경우 사이트에 브리지헤드 서버(하나는 기본, 하나는 백업용)를 두 개 이상 할당해야 ISTG 역할 서버가 올바르게 작동합니다. DNS 인프라가 올바르게 작동해야 합니다. 필요한 경우 배포 중에 최고 AD 작업 및 복제 성능을 위해 네트워크의 다른 서브넷에 도메인 컨트롤러를 배치하고 유연한 단 일 마스터 작업(FSMO 또는 작업 마스터) 역할을 수행해야 할 수도 있습니다. Splunk 배포를 정의합니다. Windows 네트워크가 올바르게 준비되었으면 이제 Splunk를 네트워크의 어디에 배치할 지 결정해야 합니다. 다음 사항을 고려하십시오. 각 컴퓨터에서 Splunk가 인덱싱할 데이터 집합을 결정하고, 수집한 데이터에 대한 경고를 Splunk에서 보내야 할지 여부를 결정합니다. 가능하면 Splunk 인덱싱을 처리할 각 네트워크 세그먼트에 하나 이상의 전용 컴퓨터를 지정합니다. 분산 Splunk 배포를 위한 용량 계획에 대한 자세한 내용은 용량 계획 매뉴얼의 "Splunk Enterprise를 위한 용량 계획 소개"를 참조하십시오. AD(특히, FSMO 역할을 보유한 도메인 컨트롤러), Exchange(모든 버전), SQL Server 또는 컴퓨터 가상화 제 품(예: Hyper-V 또는 VMWare)과 같이 리소스 집중 서비스를 실행하는 컴퓨터에는 Splunk의 전체 버전을 설치 하지 마십시오. 대신 유니버설 포워더를 사용하거나 WMI를 통해 이러한 컴퓨터에 연결하십시오. Windows Server 2008/2008 R2 Core를 실행 중인 경우, 컴퓨터에 Splunk를 설치할 때 Splunk Web을 사용하 여 변경할 수 있는 GUI가 없습니다. 특히, 씬 WAN 링크에서 최소한의 네트워크 리소스를 사용하도록 Splunk 레이아웃을 정리합니다. 유니버설 포 워더는 유선을 통한 Splunk 관련 트래픽 양을 크게 줄입니다. 사용자에게 배포 계획을 제대로 알립니다. 배포 과정 중에 배포 상태에 대해 사용자가 알 수 있도록 하는 것이 중요합 니다. 이렇게 하면 나중에 지원 관련 문의를 많이 줄일 수 있습니다. Splunk를 최고 성능으로 최적화하는 방법 다른 많은 서비스와 마찬가지로 Windows에 설치된 Splunk 또한 최고 성능으로 실행하려면 적절한 유지 관리가 필요합니 다. 이 항목에서는 배포 과정에서 또는 배포 완료 후 Windows에 설치된 Splunk 배포를 올바르게 실행하기 위해 적용할 수 있 는 방법에 대해 설명합니다. Splunk의 최고 성능을 유지하려면: 하나 이상의 컴퓨터를 Splunk 작업 전용으로 준비하십시오. Splunk는 수평적으로 확장됩니다. 즉, 단일 컴퓨터에 더 많은 리소스를 지정하는 것이 아니라 Splunk 전용 물리적 컴퓨터를 더 많이 지정하기 때문에 더 나은 성능을 발휘할 수 있습니다. 가능하다면 인덱싱 및 검색 작업을 여러 컴퓨터로 분할하고, 해당 컴퓨터에서는 기본 Splunk 서비스만 실행 하십시오. 다른 서비스를 공유하는 서버에서 Splunk를 실행할 경우 유니버설 포워더를 제외한 다른 성능이 저하됩니 다. 14

15 Splunk 인덱스 전용으로 가장 빠른 디스크를 지정하십시오. 시스템에서 Splunk 인덱싱에 사용 가능한 디스크가 빠를 수록 Splunk도 더 빠르게 실행됩니다. 가능하면 스핀들 속도가 10,000RPM 이상인 디스크를 사용하십시오. Splunk 전용 중복 저장소를 지정할 경우 하드웨어 기반 RAID 1+0(RAID 10으로도 알려짐)을 사용하십시오. 이것은 속도와 중 복에 대한 최적의 균형을 제공합니다. Windows 디스크 관리 유틸리티를 통한 소프트웨어 기반 RAID 설정은 권장하지 않습니다. 바이러스 백신 프로그램이 Splunk 작업에 사용되는 디스크를 스캔하지 않도록 하십시오. Splunk에 대해 바이러스 백 신 프로그램이 바이러스 스캔을 할 경우 성능이 현저히 저하됩니다. 특히 Splunk에서 최근에 인덱스된 데이터를 내부 적으로 에이징할 경우에는 더욱 성능이 저하됩니다. Splunk가 실행되는 서버에서 바이러스 백신 프로그램을 사용해야 할 경우 모든 Splunk 디렉터리와 프로그램을 파일 스캔에서 제외하십시오. 가능하면 여러 인덱스를 사용하십시오. Splunk에서 인덱스된 데이터를 서로 다른 인덱스에 분산하십시오. 모든 데이 터를 기본 인덱스로 보내면 시스템에서 I/O 병목 현상이 발생할 수 있습니다. 해당될 경우 가능하면 시스템의 서로 다 른 물리적 볼륨을 가리키도록 인덱스를 설정하십시오. 인덱스 설정 방법에 대한 내용은 이 매뉴얼의 "인덱스 설정"에 서 확인하십시오. 운영 체제와 동일한 물리적 디스크 또는 파티션에 인덱스를 저장하지 마십시오. Windows OS 디렉터리(%WINDIR%) 또 는 해당 스왑 파일이 있는 디스크는 Splunk 데이터 저장소로 권장되지 않습니다. Splunk 인덱스를 시스템의 다른 디스 크에 저장하십시오. 데이터베이스 버킷 유형, Splunk에서 데이터를 저장하고 에이징하는 방법 등을 포함하여 인덱스가 어떻게 저장되는지 자세 히 알아보려면 이 매뉴얼의 "Splunk에서 인덱스를 저장하는 방법"을 참조하십시오. Splunk 인덱스의 hot/warm 데이터베이스 버킷을 네트워크 볼륨에 저장하지 마십시오. 네트워크 지연으로 인해 성능 이 현저히 저하됩니다. Splunk 인덱스의 hot/warm 버킷용 로컬 고속 디스크를 예약하십시오. 인덱스의 cold/frozen 버 킷을 위해 DFS(Distributed File System) 볼륨 또는 NFS(Network File System) 마운트와 같은 네트워크 공유를 지정 할 수 있습니다. 그러나 cold 데이터베이스 버킷에 저장된 데이터를 포함하는 검색은 더 느려집니다. Splunk 인덱서에 대한 디스크 가용성, 대역폭 및 공간을 유지 관리하십시오. Splunk 인덱스가 저장된 디스크 볼륨의 사용 가능한 공간이 항상 20% 이상을 유지해야 합니다. 디스크 검색 시간이 늘어나므로 사용 가능한 공간과 비례하여 디스크 성능이 저하됩니다. 이는 Splunk가 데이터를 인덱싱하는 속도에 영향을 미치고, 검색 결과, 보고서 및 경고를 얼마나 빨리 반환하는지도 결정합니다. 기본 Splunk 설치에서 인덱스를 포함하는 드라이브의 사용 가능한 공간은 최 소 2048MB(2GB) 이상이어야 합니다. 그렇지 않으면 인덱싱이 일시 중지됩니다. 시스템 이미지에 Splunk 배치 이 항목에서는 Splunk를 모든 Windows 시스템 이미지 또는 설치 프로세스의 일부로 만드는 개념에 대해 설명합니다. 그리 고 사용하는 이미징 유틸리티와 관계 없이 일반적인 통합 프로세스를 안내합니다. Windows 데이터를 Splunk로 가져오는 것과 관련된 내용은 데이터 가져오기 매뉴얼의 "Windows 데이터 및 Splunk 에 대하여"에서 확인하십시오. 분산 Splunk 배포에 대한 내용은 분산 배포 매뉴얼의 "분산 개요"에서 확인하십시오. 이 개요는 사용하는 운영 체제와 관계 없이 Splunk 배포 설정 방법을 이해하는 데 꼭 필요한 내용입니다. Splunk 분산 배포 기능에 대해서도 알 수 있습 니다. 대규모 Splunk 배포 계획에 대한 내용은 용량 계획 매뉴얼의 "Splunk Enterprise를 위한 용량 계획 소개"와 이 매뉴얼 의 "Windows에 Splunk 배포"에서 확인하십시오. Windows에서의 시스템 통합 개념 Splunk를 Windows 시스템 이미지에 통합하는 주요 이유는 엔터프라이즈에서 사용할 컴퓨터를 활성화했을 때 Splunk를 즉 시 사용할 수 있도록 하기 위해서입니다. 이렇게 하면 활성화 후 Splunk를 설치 및 설정해야 할 필요가 없어집니다. 이 시나리오에서는 Windows 시스템을 활성화하고 부팅하면 Splunk가 즉시 실행됩니다. 그런 다음 설치된 Splunk 인스턴스 유형과 지정된 설정에 따라 Splunk가 컴퓨터에서 데이터를 수집하고 수집한 데이터를 인덱서로 포워딩하거나(대부분의 경 우) 또는 다른 Windows 컴퓨터에서 포워딩된 데이터의 인덱싱을 시작합니다. 또한 시스템 관리자는 Splunk 인스턴스를 배포 서버에 접속할 수 있도록 설정하여 추가 설정 및 업데이트 관리를 할 수 있습 니다. 대부분의 일반적인 환경에서 Windows 컴퓨터의 유니버설 포워더는 중앙 인덱서 또는 인덱서 그룹으로 데이터를 전송합니 다. 그러면 특정 요구에 따라 데이터의 검색, 보고 및 경고가 허용됩니다. 시스템 통합 시 고려 사항 Splunk를 Windows 시스템 이미지에 통합하려면 계획이 필요합니다. 대부분의 경우 유니버설 포워더는 Windows 시스템 이미지와의 통합 시 선호되는 Splunk 구성 요소입니다. 유니버설 포워더 는 다른 역할을 수행하는 컴퓨터의 리소스를 공유하며, 훨씬 적은 비용으로 인덱서가 수행할 수 있는 많은 작업을 수행합니 다. 또한 변경하기 위해 Splunk Web을 사용할 필요 없이 Splunk의 배포 서버 또는 엔터프라이즈 범위의 설정 관리자를 사용 하여 유니버설 포워더를 수정할 수 있습니다. 상황에 따라 Splunk의 전체 인스턴스를 시스템 이미지에 통합할 수도 있습니다. 적합한 시기와 위치는 특정 요구와 리소스 가용성에 따라 다릅니다. Splunk는 포워더에 대한 인덱서의 특정 용량 요구가 없는 경우 다른 유형의 역할을 수행하는 서버의 이미지에 Splunk의 전 15

16 체 버전을 포함하는 것을 권장하지 않습니다. 엔터프라이즈에 여러 인덱서를 설치하더라도 인덱싱 성능이나 속도가 추가로 제공되지 않으며 바람직하지 않은 결과로 이어질 수 있습니다. Splunk를 시스템 이미지에 통합하기 전에 다음을 고려하십시오. Splunk에서 인덱싱할 데이터 양, 그리고 해당 데이터를 보낼 위치(있는 경우). 이러한 정보는 디스크 공간 계산에 직 접 사용되며 최우선으로 고려해야 할 사항입니다. 이미지 또는 컴퓨터에 설치할 Splunk 인스턴스의 유형. 유니버설 포워더는 다른 작업을 수행하는 워크스테이션이나 서버에 설치할 경우 상당한 장점이 있지만, 그렇지 않은 경우도 있습니다. 이미징된 컴퓨터의 사용 가능한 시스템 리소스. 이미징된 각 시스템에서 사용할 수 있는 디스크 공간, RAM 및 CPU 리 소스는 얼마나 됩니까? Splunk 설치를 지원합니까? 네트워크의 리소스 요구 사항. WMI를 사용하여 데이터를 수집하기 위해 원격 컴퓨터에 연결하는 데 Splunk를 사용하 든, 각 컴퓨터에 포워더를 설치하고 데이터를 인덱서로 보내기 위해 Splunk를 사용하든 Splunk에는 네트워크 리소스 가 필요합니다. 이미지에 설치된 다른 프로그램의 시스템 요구 사항. Splunk가 다른 서버와 리소스를 공유할 경우 다른 프로그램의 사 용 가능한 리소스가 사용될 수 있습니다. Splunk의 전체 인스턴스를 실행 중인 워크스테이션 또는 서버에 다른 프로그 램을 설치할지 여부를 고려하십시오. 유니버설 포워더는 경량으로 설계되어 있으므로 이러한 경우에 보다 효율적으로 작동합니다. 이미징된 컴퓨터가 현재 환경에서 수행하는 역할. Office와 같은 생산성 애플리케이션을 실행하는 워크스테이션의 역 할만 합니까? 아니면 Active Directory 포리스트를 위한 작업 마스터 도메인 컨트롤러의 역할을 합니까? Splunk를 시스템 이미지에 통합 앞에서 말한 체크리스트의 질문에 대한 답변을 결정했으면 그 다음 단계는 Splunk를 시스템 이미지에 통합하는 것입니다. 나 열된 단계는 선호하는 시스템 이미징 또는 설정 도구를 사용하여 작업을 완료하는 일반적인 단계입니다. 시스템 통합에 대한 다음 옵션 중 하나를 선택하십시오. 유니버설 포워더를 시스템 이미지에 통합 Splunk의 전체 버전을 시스템 이미지에 통합 유니버설 포워더를 시스템 이미지에 통합 이 항목에서는 Splunk 유니버설 포워더를 Windows 시스템 이미지에 통합하는 절차에 대해 설명합니다. Splunk와 이미지 통합에 대한 자세한 내용은 "Splunk를 시스템 이미지에 통합"을 참조하십시오. 유니버설 포워더를 시스템 이미지에 통합하려면: 1. 참조 컴퓨터를 사용하여 필요한 Windows 기능, 패치 및 기타 구성 요소 등과 함께 원하는 위치에 Windows를 설치 및 설 정합니다. 2. Splunk의 시스템 및 하드웨어 용량 요구 사항을 고려하여 필요한 애플리케이션을 설치 및 설정합니다. 3. 명령줄에서 유니버설 포워더를 설치 및 설정하고 최소 LAUNCHSPLUNK=0 명령줄 플래그를 제공합니다. 중요: 설치를 완료한 후 Splunk가 실행되지 않도록 하려면 LAUNCHSPLUNK=0 명령줄 플래그를 지정해야 합니다. 4. 설치에서 그래픽 부분을 수행합니다. 여기서 필요한 입력 정보, 배포 서버 또는 포워더 대상을 선택합니다. 5. 설치가 완료되면 명령 프롬프트를 엽니다. 6. 설치 관리자에서 설정할 수 없는 추가 설정 파일을 이 프롬프트에서 편집합니다. 7. 명령 프롬프트 창을 닫습니다. 8. 서비스 제어판에서 시작 유형을 '자동'으로 설정하여 splunkd 서비스가 자동으로 시작되도록 설정했는지 확인합니다. 9. SYSPREP(Windows XP 및 Windows Server 2003/2003 R2인 경우) 또는 WSIM(Windows 시스템 이미지 관리 자)(Windows Vista, Windows 7 및 Windows Server 2008/2008 R2인 경우)과 같은 유틸리티를 사용하여 도메인 참여를 위한 시스템 이미지를 준비합니다. 참고: Microsoft는 복제하기 전에 컴퓨터 SID(보안 식별자)를 변경하는 방법으로 타사 도구(Ghost Walker 또는 NTSID 등) 를 사용하는 것보다 SYSPREP 및 WSIM을 사용할 것을 권장합니다. 10. 이미지를 위한 시스템 설정을 완료했으면 컴퓨터를 재부팅하고 선호하는 이미징 유틸리티를 사용하여 복제합니다. 이제 배포할 이미지가 준비되었습니다. 전체 Splunk를 시스템 이미지에 통합 이 항목에서는 Splunk의 전체 버전을 Windows 시스템 이미지에 통합하는 절차에 대해 설명합니다. Splunk의 이미지 통합 에 대한 자세한 내용은 이 매뉴얼에서 "시스템 이미지에 Splunk 배치"를 참조하십시오. Splunk의 전체 버전을 시스템 이미지에 통합하려면: 16

17 1. 참조 컴퓨터를 사용하여 필요한 Windows 기능, 패치 및 기타 구성 요소 등과 함께 원하는 위치에 Windows를 설치 및 설 정합니다. 2. Splunk의 시스템 및 하드웨어 용량 요구 사항을 고려하여 필요한 애플리케이션을 설치 및 설정합니다. 3. Splunk를 설치 및 설정합니다. 중요: GUI 설치 관리자를 사용하여 설치할 수도 있지만 명령줄을 통해 패키지를 설치할 경우 더 많은 옵션이 있습니다. 4. Splunk 입력을 설정했으면 명령 프롬프트를 엽니다. 5. 이 프롬프트에서 %SPLUNK_HOME%\bin 디렉터리로 변경하고 다음을 실행하여 Splunk를 중지합니다..\splunk stop 6..\splunk clean eventdata를 실행하여 모든 이벤트 데이터를 정리합니다. 7. 명령 프롬프트 창을 닫습니다. 8. 서비스 제어판에서 시작 유형을 '자동'으로 설정하여 splunkd 및 splunkweb 서비스가 자동으로 시작되도록 설정했는지 확 인합니다. 9. SYSPREP(Windows XP 및 Windows Server 2003/2003 R2인 경우) 또는 WSIM(Windows 시스템 이미지 관리 자)(Windows Vista, Windows 7 및 Windows Server 2008/2008 R2인 경우)과 같은 유틸리티를 사용하여 도메인 참여를 위한 시스템 이미지를 준비합니다. 참고: Microsoft는 복제하기 전에 컴퓨터 SID(보안 식별자)를 변경하는 방법으로 타사 도구(Ghost Walker 또는 NTSID 등) 를 사용하는 것보다 SYSPREP 및 WSIM을 사용할 것을 권장합니다. 10. 이미지를 위한 시스템 설정을 완료했으면 컴퓨터를 재부팅하고 선호하는 이미징 유틸리티를 사용하여 복제합니다. 이제 배포할 이미지가 준비되었습니다. Splunk Web을 사용한 Splunk Enterprise 관리 Splunk Web 실행 Splunk가 실행되면 웹 인터페이스를 실행할 수 있습니다. Splunk Web을 사용하여 수행할 수 있는 작업에 대해 자세히 알아 보려면 "Splunk Web 정보"를 참조하십시오. Splunk Web을 실행하려면 다음으로 이동하십시오. 이 때 설치 시에 선택한 호스트와 포트를 사용하십시오. Enterprise 라이선스를 사용하여 Splunk에 처음 로그인할 때 기본 로그인 정보는 다음과 같습니다. 사용자 이름 - admin 암호 - changeme 참고: 무료 라이선스를 사용하여 Splunk를 실행할 경우 액세스를 제어할 수 없으므로, 로그인 정보를 묻는 창이 나타나지 않 습니다. 참고: Splunk 버전 4.1.4부터 $SPLUNK_HOME/etc/local/server.conf를 편집하고 allowremotelogin을 Always로 설정하기 전에는 원격 브라우저를 통해 Splunk Free에 액세스할 수 없습니다. Splunk Enterprise를 실행할 경우 기본 암호를 변경하기 전까 지 관리자의 원격 로그인을 기본적으로 사용할 수 없습니다(requireSetPassword로 설정되어 있음). Splunk Web 정보 Splunk Web은 Splunk의 브라우저 기반 인터페이스입니다. Splunk Web에서 수행할 수 있는 작업은 다음과 같습니다. 데이터 입력 설정 데이터 검색, 결과 보고 및 시각화 문제 조사 기본 기능 또는 LDAP 전략을 통한 사용자 관리 Splunk 배포 문제 해결 클러스터 및 피어 관리 지원되는 운영 체제 및 브라우저 리스트는 해당 시스템 요구 사항을 참조하십시오. Splunk 홈 Splunk에 처음 로그인하면 Splunk 홈으로 이동합니다. 앱의 모든 항목이 이 페이지에 나타납니다. Splunk 홈에는 Splunk Enterprise 탐색 메뉴, 앱 패널, Splunk Enterprise 패널 탐색 및 사용자 지정 기본 대시보드(여기에는 표시되지 않음)가 포함 됩니다. 17

18 사용자 계정별로 검색 및 보고 앱의 검색 또는 피벗 등 다른 뷰에서 시작하도록 설정되었을 수도 있습니다. 다른 뷰에서 Splunk Web 왼쪽 상단의 Splunk 로고를 클릭하면 Splunk 홈으로 돌아갈 수 있습니다. 앱 앱 패널에는 보기 권한을 가진 Splunk 인스턴스에 설치된 앱이 나열됩니다. 리스트에서 앱을 선택하면 앱이 열립니다. 기본적으로 제공되는 Splunk Enterprise 설치의 경우 작업영역에 하나의 앱 (검색 및 보고)만 표시됩니다. 앱이 두 개 이상인 경우 작업영역 내로 앱을 끌어 놓고 다시 정렬할 수 있습니다. 이 패널에서 다음의 두 가지 작업을 수행할 수 있습니다. 기어 아이콘을 클릭하여 Splunk 인스턴스에 설치된 앱을 보고 관리합니다. 더하기 아이콘을 클릭하여 설치할 더 많은 앱을 찾아봅니다. Splunk Enterprise 탐색 패널 Splunk Enterprise 탐색 패널은 Splunk Enterprise를 사용하여 시작하는 데 도움이 됩니다. 아이콘을 클릭하면 다음을 수행 할 수 있습니다. 데이터 추가 새 앱 찾아보기 Splunk Enterprise 설명서 읽기 Splunk 응답 페이지 탐색 홈 대시보드 드롭다운 메뉴를 사용하여 대시보드를 선택합니다. Splunk 설정 메뉴 정보 Splunk Web은 Splunk 작업의 대부분을 관리할 수 있는 편리한 인터페이스를 제공합니다. 대부분의 기능은 메뉴에서 설정을 클릭하여 액세스할 수 있습니다. 여기서 다음 작업을 수행할 수 있습니다. 데이터 관리 설정 > 데이터에서 다음 작업을 수행할 수 있습니다. 데이터 입력을 통해 데이터 유형 리스트를 보고 설정할 수 있습니다. 입력을 추가하려면 데이터 입력 페이지에서 데이 터 추가 단추를 클릭하십시오. 데이터를 추가하는 방법에 대한 자세한 내용은 데이터 가져오기 매뉴얼을 참조하십시 오. 포워딩 및 수신을 통해 포워더와 수신기를 설정할 수 있습니다. 포워딩 및 수신 설정에 대한 자세한 내용은 데이터 포 워딩 매뉴얼을 참조하십시오. 인덱스를 통해 인덱스를 추가하고 비활성화 및 활성화할 수 있습니다. 보고서 가속화 요약에서는 검색 및 보고 앱으로 이동하여 기존 보고서 요약을 검토할 수 있습니다. 보고서 요약 만들기 에 대한 자세한 내용은 knowledge 관리자 매뉴얼을 참조하십시오. 사용자 및 사용자 인증 관리 설정 > 사용자 및 인증 > 액세스 제어로 이동하여 다음 작업을 수행할 수 있습니다. 사용자 만들기 및 관리 역할 정의 및 할당 LDAP 인증 전략 설정 사용자 및 인증 작업에 대한 자세한 내용은 Splunk 보안 매뉴얼을 참조하십시오. 앱 작업 설치된 앱을 보려면 메뉴 모음에서 앱을 선택하십시오. 18

19 이 페이지에서는 이미 설치되어 현재 사용할 수 있는 앱 리스트에서 앱을 선택할 수 있습니다. 다음 메뉴 옵션에도 액세스할 수 있습니다. 추가 앱 찾기를 통해 추가 앱을 검색하고 설치할 수 있습니다. 앱 관리를 통해 기존 앱을 관리할 수 있습니다. 홈 페이지에서 모든 앱에 액세스할 수도 있습니다. 앱에 대한 자세한 내용은 Splunk Web용 뷰 및 앱 개발을 참조하십시오. 시스템 영역 관리 설정 > 시스템에 있는 옵션을 사용하여 다음 작업을 수행할 수 있습니다. 서버 설정을 통해 포트, 호스트 이름, 인덱스 경로, 이메일 서버, 시스템 로그 및 배포 클라이언트 정보와 같은 Splunk 설정을 관리할 수 있습니다. Splunk Web을 사용한 분산 환경의 설정 및 관리에 대한 자세한 내용은 Splunk 구성 요소 업데이트 매뉴얼을 참조하십시오. 서버 컨트롤을 통해 Splunk를 재시작할 수 있습니다. 라이선싱을 통해 Splunk 라이선스를 관리 및 갱신할 수 있습니다. Splunk 기본 대시보드 Splunk는 일련의 유용한 대시보드와 함께 제공됩니다. 대시보드는 시스템 및 검색 문제를 해결하는 데 유용하며, 대시보드와 뷰를 직접 설계할 방법에 대한 몇 가지 아이디어를 생각해내는 데도 도움이 될 수 있습니다. 작업 대시보드 페이지 상단의 사용자 메뉴 모음에서 작업 > 시스템 작업을 클릭하여 다음 대시보드를 찾을 수 있습니다. 참고: 이러한 대시보드는 관리자 역할 권한을 가진 사용자만 볼 수 있습니다. 사용자 및 역할에 대해 자세한 내용은 Splunk 보안의 "사용자 추가 및 관리" 절을 참조하십시오. 대시보드에 대한 권한 설정에 대한 자세한 내용은 knowledge 관리자 매뉴 얼을 참조하십시오. 검색 작업 - 이 대시보드 컬렉션은 Splunk 인스턴스의 검색 작업에 대한 전체적인 정보를 제공합니다. 검색이 실행되는 시기, 시스템의 로드 양, 가장 일반적인 검색, 가장 자주 사용되는 검색 뷰 및 대시보드 등을 알 수 있습니다. 다음과 같 은 대시보드가 제공됩니다. 검색 작업 개요 검색 세부 정보 사용자 작업 검색 서버 작업 - 이 대시보드 컬렉션은 splunkd 및 Splunk Web 성능과 관련된 메트릭을 제공하며, 문제 해결에 유용합니 다. 보고된 오류 수, 최근 오류 리스트, 타임스탬프 문제 및 처리되지 않은 예외 리스트, 최근 브라우저 사용량을 보여주 는 차트 등이 표시됩니다. 다음과 같은 대시보드가 제공됩니다. 내부 메시지 및 오류 라이선스 사용량 스케줄러 작업 - 이 대시보드 컬렉션은 검색 스케줄러의 작업을 전체적으로 파악할 수 있게 하여 임시 및 예약된 검색 이 시기적절하게 실행되도록 보장합니다. 스케줄러 작업 개요 사용자 또는 앱에 의한 스케줄러 작업 저장된 검색에 의한 스케줄러 작업 스케줄러 오류 요약 대시보드 요약 대시보드는 검색 및 보고 앱에 들어갈 때 처음 표시되는 항목입니다. 요약 대시보드는 초기 검색을 입력하고 실행하기 위해 사용할 수 있는 검색란 및 시간 범위 선택기를 제공합니다. Splunk에 입력 데이터를 추가할 경우 해당 입력은 현재 앱에 상대적으로 추가됩니다. *nix 및 Windows 앱과 같은 일부 앱은 입력 데이터를 특정 인덱스(*nix 및 Windows의 경우 os 인덱스)에 기록합니다. 요약 대시보드를 검토할 때 Splunk에 있는 것이 확실한 데이터가 표시되지 않으면 올바른 인덱스를 보고 있는지 확인하십시오. 앱에서 사용하는 인덱스를 현재 사용 중인 역할에 대한 기본 인덱스 리스트에 추가할 수도 있습니다. 역할에 대한 자세한 내 용은 Splunk 보안 매뉴얼의 역할 관련 항목을 참조하십시오. 요약 대시보드에 대한 자세한 내용은 검색 튜토리얼을 참조하십 시오. 19

20 Splunk Web 배너 메시지 사용자 지정 이 페이지는 현재 작업 중이며, 가까운 시일 내 자주 업데이트될 예정입니다. 사용자가 로그인할 때 사용자 페이지의 상단에 표시되는 알림을 추가 및 편집할 수 있습니다. 알림은 Splunk Web의 메시 지 메뉴에도 표시됩니다. 알림을 추가 또는 편집하려면 관리자 또는 시스템 사용자 권한 수준이 필요합니다. 알림을 변경 또는 추가하는 방법: 1. 설정 > 사용자 인터페이스를 선택합니다. 2. 새로 만들기를 클릭하여 새 메시지를 만들거나, 공지 메시지를 클릭하고 편집할 메시지를 선택합니다. 3. 기존 메시지 텍스트를 편집하거나, 새 메시지에 이름과 메시지 텍스트를 지정합니다. 4. 저장을 클릭합니다. 메시지가 페이지 상단에 노란색 배너로 표시됩니다. 메시지 메뉴에 노트로 표시되기도 합니다. 프록시 서버를 통해 Splunk Web 사용 Splunk Web이 프록시 서버 뒤에 있을 경우 Splunk 웹 사이트에 액세스하는 Splunk Web 링크를 사용할 때 문제가 발생할 수 있습니다. 예를 들어 일부 Splunk Web 페이지는 Splunk 앱 다운로드 사이트에 직접 연결되고 여러 "자세히 알아보기" 링 크는 온라인 문서로 연결됩니다. 이 문제를 해결하려면 간단히 HTTP_PROXY 환경 변수를 설정하십시오. 영구적인 결과를 얻기 위해 *nix 시스템의 경우 $SPLUNK_HOME/etc/, Windows의 경우 %SPLUNK_HOME%\etc\에 있는 splunk-launch.conf 설정 파일에서 해당 설정을 지정할 수 있 습니다. splunk-launch.conf에서 다음 속성/값 쌍을 추가하십시오. HTTP_PROXY = <IP address or host name>:<port number> 예: HTTP_PROXY = :8787 중요: 프록시 서버가 HTTPS 요청만 처리할 경우 다음 속성/값 쌍을 사용해야 합니다. HTTPS_PROXY = <IP address or host name>:<port number> 예: HTTPS_PROXY = :8888 설정 파일을 사용한 Splunk Enterprise 관리 설정 파일에 대하여 Splunk의 설정 정보는 설정 파일에 저장됩니다. 설정 파일은.conf 확장자로 식별되며, 다음과 같은 Splunk 설정의 다양한 측 면에 대한 정보를 포함합니다. 시스템 설정 인증 및 허가 정보 인덱스 매핑 및 설정 배포 및 클러스터 설정 Knowledge 객체와 저장된 검색 설정 파일의 전체 리스트와 각 파일의 기능에 대한 개요는 이 매뉴얼의 설정 파일 리스트를 참조하십시오. 대부분의 설정 파일은 Splunk 설치와 함께 제공되며, $SPLUNK_HOME/etc/default에서 확인할 수 있습니다. Splunk Web을 사용한 설정 파일 관리 Splunk Web에서 설정을 변경하면 해당 설정에 대한 설정 파일의 복사본에 변경 사항이 기록됩니다. Splunk는 이 설정 파일 의 복사본을 (아직 없는 경우) 만들고 변경 사항을 해당 복사본에 기록하며$SPLUNK_HOME/etc/...의 하위 디렉터리에 추가합 니다. 새 파일이 실제로 추가되는 디렉터리는 설정 파일 디렉터리에서 설명하는 몇 가지 요인에 의해 결정됩니다. 가장 일반 적인 디렉터리는 아래 예제와 같이 사용되는 $SPLUNK_HOME/etc/local입니다. 20

21 Splunk Web에서 새 인덱스를 추가할 경우 일반적으로 다음 작업이 수행됩니다. 1. 파일의 복사본이 있는지 확인합니다. 2. 복사본이 없으면 indexes.conf의 복사본을 새로 만들고 $SPLUNK_HOME/etc/local과 같은 디렉터리에 추가합니다. 3. Splunk에서 변경 사항을 inputs.conf의 복사본에 기록합니다. 4. 기본 파일은 변경되지 않고 $SPLUNK_HOME/etc/system/default에 그대로 남아 있습니다. 설정 파일 직접 편집 Splunk Web에서 많은 설정 작업을 수행할 수 있지만, 모든 설정에 대한 설정 파일을 직접 편집할 수도 있습니다. Splunk Web에서 지원되지 않는 일부 고급 사용자 설정의 속성은 Splunk Web에서 액세스할 수 없으며, 해당 설정의 설정 파일을 직 접 편집해야 합니다. 참고: 설정 파일을 편집하면 Splunk Web에서 변경할 때보다 Splunk를 더 자주 재시작해야 합니다. 설정 파일을 편집한 후 Splunk를 재시작하는 방법에 대한 자세한 내용은 "설정 파일 변경 후에 Splunk를 재시작해야 하는 경우"를 참조하십시오..conf 파일은 직접 편집할 때 주의해야 합니다. 기본 설정 파일을 직접 편집하지 마십시오. 대신, Splunk Web과 동일한 방법 으로 복사본을 만들고 다른 디렉터리에 저장하십시오. 기본 파일을 원래 위치에 계속 보관하는 것이 중요합니다. 자세한 내용은 "설정 파일 편집 방법"에서 더 자세히 설명합니다. 설정 파일을 변경하기 전에: 기본 설정 파일 작업과 편집된 복사본을 저장할 위치에 대해 자세히 알아보십시오. "설정 파일 디렉터리"를 참조하십 시오. 설정 파일에 포함된 스탠자의 구조와 편집할 속성이 설정되는 방법에 대해 알아보십시오. "설정 파일 구성"을 참조하 십시오. (복사본을 저장할 가장 좋은 위치를 알기 위해) 서로 다른 디렉터리에 있는 동일한 설정 파일의 다양한 복사본의 계층 구조와 결합 방법에 대해 알아보십시오. "설정 파일 우선 순위"를 참조하십시오. 설정 파일의 내용과 디렉터리 구조에 대해 숙지하고 Splunk의 설정 파일 우선 순위를 활용하는 방법을 이해한 후 "설정 파일 편집 방법"을 읽고 파일을 안전하게 수정하는 방법에 대해 알아보십시오. 설정 파일 디렉터리 단일 Splunk 인스턴스에는 일반적으로 여러 디렉터리에 걸쳐 여러 버전의 설정 파일이 있습니다. 기본, 로컬 및 앱 디렉터리 에 이름이 동일한 설정 파일이 있을 수 있습니다. 이것은 Splunk가 현재 사용자 및 현재 앱과 같은 요인을 기준으로 설정 우 선 순위를 결정하기 위해 사용할 수 있는 계층화 효과를 만들어냅니다. Splunk에서 설정의 우선 순위를 정하는 방법에 대한 자세한 내용은 "설정 파일 우선 순위"를 참조하십시오. 참고: 지정된 설정 파일에서 사용할 수 있는 가장 정확한 설정 리스트는 해당 설정 파일의.spec 파일에 있습니다. "설정 파일 참조" 또는 $SPLUNK_HOME/etc/system/README에서.spec 및.example 파일의 최신 버전을 찾을 수 있습니다. 기본 파일에 대하여 "모든 환경은 /default를 제외하고 사용자의 환경에 따라 다릅니다." -- duckfez, 2010 다음은 $SPLUNK_HOME/etc의 설정 디렉터리 구조입니다. $SPLUNK_HOME/etc/system/default 미리 설정된 설정 파일이 포함됩니다. 이 디렉터리에 있는 파일을 수정하면 안 됩니다. 로컬 또는 앱 디렉터리에 있는 파일의 사본을 대신 편집해야 합니다. 기본 파일은 파일의 변경 사항을 롤백해야 할 경우에도 유용합니다. Splunk는 업그레이드될 때마다 기본 파일을 덮어씁니다. Splunk는 항상 기본 디렉터리를 마지막으로 살펴보므로, 다른 설정 디렉터리 중 하나에서 변경한 속성이나 스탠자가 기본 버전보다 우선합니다. 수정한 설정 파일을 저장하거나 찾을 수 있는 위치 Splunk가 "설정 파일 우선 순위"에 설명되어 있는 계층 구조에 따라 사용하는 다른 속성 값을 통해 설정 파일의 여러 버전을 계층화할 수 있습니다. 기본 디렉터리에 있는 파일을 편집하지 마십시오. 대신, $SPLUNK_HOME/etc/system/local과 같은 설정 디렉터리에서 파일을 만 들거나 편집하십시오. 해당 디렉터리는 업그레이드 도중에 덮어쓰지 않습니다. 대부분의 배포에서는 $SPLUNK_HOME/etc/system/local 디렉터리를 사용하여 설정을 변경할 수 있습니다. 그러나 경우에 따라 다른 디렉터리에 있는 파일을 사용하여 작업을 수행할 수도 있습니다. 다음은 $SPLUNK_HOME/etc의 설정 디렉터리 구조입니다. 21

22 $SPLUNK_HOME/etc/system/local 모든 앱에서 사용 가능한 설정과 같은 사이트 범위의 로컬 변경 사항이 여기에 적용됩니다. 원하는 설정 파일이 아직 이 디렉터리에 없으면 파일을 만들고 쓰기 권한을 부여하십시오. $SPLUNK_HOME/etc/slave-apps/[_cluster <app_name>]/[local default] 클러스터 피어 노드만 해당됨 $SPLUNK_HOME/etc/slave-apps의 하위 디렉터리에는 모든 피어 노드의 공통 설정 파일이 포함됩니다. 클러스터 피어에서 하위 디렉터리의 내용을 변경하지 마십시오. 대신 클러스터 마스터를 사용하여 하위 디렉터 리에 새 파일 또는 수정된 파일을 배포하십시오. _cluster 디렉터리는 실제 앱에 포함되어 있지 않지만 모든 피어에서 동일해야 하는 설정 파일을 포함합니다. 일 반적으로 indexes.conf 파일이 여기에 해당됩니다. 자세한 내용은 인덱서 및 클러스터 관리 매뉴얼의 "공통 피어 설정 업데이트"를 참조하십시오. $SPLUNK_HOME/etc/apps/<app_name>/[local default] 설정을 변경할 때 사용자가 현재 앱에 있을 경우 앱의 /local 디렉터리에 있는 설정 파일에 해당 설정이 적용됩 니다. 예를 들어, 기본 Splunk 검색 앱의 검색 시간 설정에 대한 편집 내용은 다음 위치에 적용됩니다. $SPLUNK_HOME/etc/apps/search/local/. 특정 앱에만 변경 사항이 적용되도록 설정 파일을 편집하려면 설정 파일을 (쓰기 권한이 있는) 앱의 /local 디렉 터리에 복사한 후 변경하십시오. $SPLUNK_HOME/etc/users 사용자별 설정 변경 사항이 여기에 적용됩니다. $SPLUNK_HOME/etc/system/README 이 디렉터리에는 지원 참조 설명서가 포함됩니다. 대부분의 설정 파일에는.spec 및.example의 두 개의 참조 파 일이 있습니다(예: inputs.conf.spec 및 inputs.conf.example)..spec 파일은 사용 가능한 속성 및 변수 리스트를 비롯한 구문을 지정합니다..example 파일에는 실제 환경에서의 사용 예가 포함되어 있습니다. 설정 파일 구성 설정 파일을 편집하기 전에 파일 구조를 알아야 합니다. 스탠자 설정 파일은 하나 이상의 스탠자 또는 섹션으로 구성됩니다. 각 스탠자는 대괄호로 묶은 스탠자 헤더로 시작됩니다. 이 헤더 는 해당 스탠자 내에 저장된 설정을 식별합니다. 각 설정은 특정 구성 설정을 지정하는 속성 값의 쌍입니다. 예를 들어 inputs.conf는 서버 인증서 및 암호 등에 대한 설정이 포함된 [SSL]을 제공합니다. [SSL] servercert = <pathname> password = <password> 스탠자 유형에 따라 속성이 필수적이거나 선택적일 수 있습니다. 새 스탠자 설정 설정 파일을 편집할 때는 위와 같이 기본 스탠자를 변경하거나 완전히 새로운 스탠자를 추가할 수 있습니다. 다음은 기본 패턴입니다. [stanza1_header] <attribute1> = <val1> comment <attribute2> = <val2>... [stanza2_header] <attribute1> = <val1> <attribute2> = <val2>... 중요: 속성은 대소문자를 구분합니다. 예를 들어, sourcetype = my_app은 SOURCETYPE = my_app과 동일하지 않습니다. 하나는 작동하고, 다른 하나는 작동하지 않습니다. 스탠자 범위 설정 파일은 우선 순위를 가진 더 많은 특정 스탠자와 함께 다양한 영역의 스탠자를 가진 경우가 많습니다. 예를 들어, 포워 더를 설정하는 데 사용하는 outputs.conf 설정 파일의 아래 예제를 보십시오. [tcpout] indexandforward=true compressed=true 22

23 [tcpout:my_indexersa] autolb=true compressed=false server=mysplunk_indexer1:9997, mysplunk_indexer2:9997 [tcpout:my_indexersb] autolb=true server=mysplunk_indexer3:9997, mysplunk_indexer4:9997 이 예제 파일에는 다음과 같은 두 가지 수준의 스탠자가 있습니다. 모든 TCP 포워딩에 영향을 미치는 설정이 포함된 전역[tcpout] 설정이 각 대상 그룹에 정의된 인덱서에만 영향을 미치는 두 가지 [tcpout:<target_list>] 스탠자 my_indexersa 대상 그룹의 인덱서인 경우에만 [tcpout:my_indexersa]의 compressed 설정은 [tcpout]의 해당 속성 설정보다 우선합니다. 포워더 및 outputs.conf에 대한 자세한 내용은 "outputs.conf에서 포워더 설정"을 참조하십시오. 설정 파일 우선 순위 설정 파일에 대한 자세한 내용은 "설정 파일에 대하여"를 참조하십시오. Splunk는 설정 파일을 사용하여 동작의 모든 측면을 결정합니다. 단일 Splunk 인스턴스에는 동일한 설정 파일의 여러 복사 본이 있을 수 있습니다. 각 파일 복사본은 일반적으로 사용자 또는 앱이나 전체 시스템에 영향을 미치는 여러 디렉터리에 계 층 구조로 저장됩니다. 설정 파일을 편집할 때는 Splunk가 어떻게 각 파일을 평가하고 어떤 파일이 우선하는지 이해하는 것이 중요합니다. Splunk는 변경 사항을 적용할 때 설정 파일에 대해 다음과 같은 작업을 수행합니다. Splunk는 위치 기반 우선 순위 지정 구조를 사용하여 모든 파일 복사본의 설정을 병합합니다. 서로 다른 복사본에서 속성 값이 충돌할 경우(즉, 동일한 속성에 다른 값이 설정된 경우) Splunk는 가장 높은 우선 순위 파일의 값을 사용합니다. Splunk는 디렉터리 구조에서 파일이 있는 위치를 기준으로 설정 파일의 우선 순위를 시스템, 앱 또는 사용자 디렉터리 순으로 결정합니다. 앱 디렉터리 컬렉션에서 우선 순위를 결정하기 위해 Splunk는 ASCII 정렬 순서를 사용합니다. 앱 디렉터리 이름의 "A" 파일은 앱 디렉터리 이름의 "B" 등의 파일보다 더 높은 우선 순위를 가집니다. 참고: 파일의 여러 복사본의 구성 설정을 해결하는 것 외에도, Splunk가 단일 파일 내의 설정을 해결해야 할 경우가 있습니 다. 단일 props.conf 파일 내에서 우선 순위를 결정하는 방식은 "단일 props.conf 파일 내의 속성 우선 순위"를 참조하십시오. 설정 파일 컨텍스트에 대하여 우선 순위가 결정되는 방법은 파일의 컨텍스트에 따라 다릅니다. 앱 또는 사용자 컨텍스트와 전역 컨텍스트 설정 파일 복사본의 우선 순위를 결정하기 위해 Splunk는 먼저 디렉터리 구조를 파악합니다. Splunk에서 사용하는 디렉터리 우선 순위 결정 방법은 크게 두 가지로 나뉩니다. 앱 또는 사용자: 검색과 같은 일부 작업은 앱/사용자 컨텍스트에서 수행됩니다. 앱/사용자 컨텍스트는 특정 knowledge 객체 또는 작업이 특정 앱의 특정 사용자에게만 유효할 수 있는 검색 시간 처리에 매우 중요합니다. 전역: 인덱싱과 같은 작업은 전역 컨텍스트에서 수행됩니다. 이런 작업은 앱 또는 사용자에 관계 없이 수행됩니다. 예 를 들어 모니터링 동작을 결정하는 설정 파일은 앱/사용자 이외의 컨텍스트에서 발생하며 전체적으로 적용됩니다. 클러스터 피어 설정 컨텍스트 클러스터 피어 노드 전역 설정에 대한 확장된 우선 순위도 있습니다. 그 이유는 indexes.conf와 같은 일부 설정 파일이 전체 피어 노드에서 동일해야 하기 때문입니다. 파일의 일관성을 유지하기 위해 파일은 모든 피어 노드에 파일의 동일한 버전이 포함되도록 하기 위해 파일을 피어 노드에 배포하는 클러스터 마스터에서 관리됩니다. 해당 파일은 다음 절에 설명되어 있는 클러스터 피어 설정에서 우선 순위가 가장 높습니다. 설정이 피어 노드 간에 분산되는 방법에 대한 자세한 내용은 인덱서 및 클러스터 관리 매뉴얼의 "공통 피어 설정 업데이트"를 참조하십시오. Splunk에서 우선 순위를 결정하는 방법 이 하위 절에서는 컨텍스트에 따른 우선 순위 지정 방식에 대해 설명합니다. 디렉터리 이름에 따른 우선 순위 지정 방식에 대 23

24 해서는 이 항목의 뒷부분에 있는 "디렉터리 우선 순위 요약"을 참조하십시오. 전역 컨텍스트 내 우선 순위: 컨텍스트가 전역인 경우(즉, 앱/사용자 컨텍스트가 없는 경우), 디렉터리 우선 순위는 다음과 같은 순서로 내려갑니다. 1. 시스템 로컬 디렉터리 - 가장 높은 우선 순위 2. 앱 로컬 디렉터리 3. 앱 기본 디렉터리 4. 시스템 기본 디렉터리 -- 가장 낮은 우선 순위 inputs.conf 등의 전역 설정을 사용할 때 Splunk는system/local에 있는 해당 파일의 복사본에서 속성을 먼저 사용합니다. 그 런 다음 앱 디렉터리에 있는 파일의 복사본을 찾습니다. 앱 디렉터리에 있는 속성을 추가하지만 시스템/로컬에서 이미 발견 된 속성은 무시합니다. 마지막으로, 시스템 또는 앱 수준에 명시적으로 할당되지 않은 속성에는 system/default 디렉터리에 있는 파일의 기본값이 할당됩니다. 참고: 다음 절에서 설명하는 대로 클러스터 피어 노드에는 확장된 우선 순위가 있습니다. 클러스터 피어 노드의 우선 순위 클러스터 피어 노드의 전역 컨텍스트에는 몇 가지 추가 피어별("slave-app") 디렉터리가 사용됩니다. 이러한 디렉터리에는 모든 피어 노드에서 동일한 앱 및 설정이 포함됩니다. 클러스터 피어의 확장된 우선 순위는 다음과 같습니다. 1. Slave-app 로컬 디렉터리(클러스터 피어만 해당) -- 가장 높은 우선 순위 2. 시스템 로컬 디렉터리 3. 앱 로컬 디렉터리 4. Slave-app 기본 디렉터리(클러스터 피어만 해당) 5. 앱 기본 디렉터리 6. 시스템 기본 디렉터리 -- 가장 낮은 우선 순위 클러스터 피어에서는 모든 피어에 공통인 사용자 지정 설정(slave-app 로컬 디렉터리에 포함)이 가장 높은 우선 순위를 가집 니다. 앱 또는 사용자 컨텍스트 내 우선 순위 앱/사용자 컨텍스트인 경우 디렉터리 우선 순위는 사용자에서 앱, 시스템 순으로 내려갑니다. 1. 현재 사용자의 사용자 디렉터리 - 가장 높은 우선 순위 2. 현재 실행 중인 앱의 앱 디렉터리(로컬, 기본 순서) 3. 다른 모든 앱의 앱 디렉터리(로컬, 기본 순서) - 내보낸 설정만 해당 4. 시스템 디렉터리(로컬, 기본 순서) - 가장 낮은 우선 순위 예를 들어 savedsearches.conf의 속성은 세 가지 수준, 즉 사용자, 앱 및 시스템 수준에서 모두 설정할 수 있습니다. Splunk는 앱 또는 시스템 수준에서 설정된 동일한 속성보다 우선적으로 항상 사용자 수준 속성 값을 사용합니다. 앱 디렉터리 이름이 우선 순위에 미치는 영향 참고: 이 하위 절에 나오는 내용은 중요하다고 볼 수는 없지만, 특정 순서로 평가 또는 문제 해결을 수행해야 할 경우에는 유 용할 수 있습니다. 앱 디렉터리 컬렉션에서 우선 순위를 결정하기 위해 Splunk는 ASCII 정렬 순서를 사용합니다. 앱 디렉터리 이름의 "A" 파일 은 앱 디렉터리 이름의 "B" 등의 파일보다 더 높은 우선 순위를 가집니다. 또한 ASCII 정렬 순서에 따라 대문자로 시작하는 모든 앱이 소문자로 시작하는 앱보다 높은 우선 순위를 가집니다. (즉, "A"는 "Z"보다 우선하고 "Z"는 "a"보다 우선합니다.) 또한 숫자 디렉터리는 알파벳 디렉터리보다 더 높은 우선 순위를 가지며, 숫자가 아닌 사전 순서로 평가됩니다. 예를 들어, 다음은 내림차순으로 평가됩니다. $SPLUNK_HOME/etc/apps/myapp1 $SPLUNK_HOME/etc/apps/myapp10 $SPLUNK_HOME/etc/apps/myapp2 $SPLUNK_HOME/etc/apps/myapp20... $SPLUNK_HOME/etc/apps/myappApple $SPLUNK_HOME/etc/apps/myappBanana $SPLUNK_HOME/etc/apps/myappZabaglione... $SPLUNK_HOME/etc/apps/myappapple $SPLUNK_HOME/etc/apps/myappbanana $SPLUNK_HOME/etc/apps/myappzabaglione... 참고: 앱/사용자 컨텍스트에서 우선 순위를 결정할 때 디렉터리 명명 방식에 상관없이 현재 실행 중인 앱의 디렉터리가 다른 모든 앱의 디렉터리보다 우선합니다. 또한 다른 앱은 내보낸 설정만 검사됩니다. 24

25 디렉터리 우선 순위 요약 디렉터리 우선 순위 순서는 다음과 같습니다. 전역 컨텍스트: $SPLUNK_HOME/etc/system/local/* $SPLUNK_HOME/etc/apps/A/local/*... $SPLUNK_HOME/etc/apps/z/local/* $SPLUNK_HOME/etc/apps/A/default/*... $SPLUNK_HOME/etc/apps/z/default/* $SPLUNK_HOME/etc/system/default/* 전역 컨텍스트 - 클러스터 피어 노드만 해당: $SPLUNK_HOME/etc/slave-apps/A/local/*... $SPLUNK_HOME/etc/slave-apps/z/local/* $SPLUNK_HOME/etc/system/local/* $SPLUNK_HOME/etc/apps/A/local/*... $SPLUNK_HOME/etc/apps/z/local/* $SPLUNK_HOME/etc/slave-apps/A/default/*... $SPLUNK_HOME/etc/slave-apps/z/default/* $SPLUNK_HOME/etc/apps/A/default/*... $SPLUNK_HOME/etc/apps/z/default/* $SPLUNK_HOME/etc/system/default/* 중요: slave-apps/[local default] 디렉터리에서는 특수 _cluster 하위 디렉터리가 소문자(예: anapp)로 시작하는 앱 하위 디 렉터리보다 높은 우선 순위를 가집니다. 그러나 이 디렉터리는 대문자(예:AnApp)로 시작하는 앱 디렉터리보다 낮은 우선 순위 를 가집니다. 그 이유는 ASCII 정렬 순서에서 밑줄("_") 문자의 위치 때문입니다. 앱/사용자 컨텍스트: $SPLUNK_HOME/etc/users/* $SPLUNK_HOME/etc/apps/Current_running_app/local/* $SPLUNK_HOME/etc/apps/Current_running_app/default/* $SPLUNK_HOME/etc/apps/A/local/*, $SPLUNK_HOME/etc/apps/A/default/*,... $SPLUNK_HOME/etc/apps/z/local/*, $SPLUNK_HOME/etc/apps/z/default/* (but see note below) $SPLUNK_HOME/etc/system/local/* $SPLUNK_HOME/etc/system/default/* 중요: 앱/사용자 컨텍스트에서 현재 실행 중인 앱의 모든 설정 파일은 다른 모든 앱의 파일보다 우선합니다. 이러한 우선 순위 는 앱의 로컬 및 기본 디렉터리에 해당됩니다. 따라서 현재 컨텍스트가 앱 C인 경우 Splunk는 다른 앱의 로컬 또는 기본 디렉 터리를 평가하기 전에 $SPLUNK_HOME/etc/apps/C/local/* 및 $SPLUNK_HOME/etc/apps/C/default/*를 모두 평가합니다. 또한 Splunk는 앱 권한 설정에 대해 이 항목에서 설명한 것처럼, 앱의 default.meta 파일을 통해 데이터를 전역으로 내보낸 경우에 는 다른 앱의 설정 데이터만 살펴봅니다. 또한 /etc/users/는 특정 사용자가 로그인하거나 검색을 수행할 때만 평가됩니다. 속성 우선 순위 방식을 보여주는 예 속성 우선 순위를 보여주는 이 예에서는 props.conf를 사용합니다. 이 파일의 컨텍스트는 Splunk의 파일 평가 시기에 따라 전 역 또는 앱/사용자가 되기 때문에 props.conf 파일은 흔하게 볼 수 없습니다. Splunk는 인덱스 시간(전역)과 검색 시간(앱/사 용자)에 모두 props.conf를 평가합니다. $SPLUNK_HOME/etc/system/local/props.conf에 다음 스탠자가 포함된 것으로 가정하고, [source::/opt/locke/logs/error*] sourcetype = fatal-error 25

26 $SPLUNK_HOME/etc/apps/t2rss/local/props.conf에는 이와 동일한 스탠자의 다른 버전이 포함되어 있는 것으로 가정합니다. [source::/opt/locke/logs/error*] sourcetype = t2rss-error SHOULD_LINEMERGE = True BREAK_ONLY_BEFORE_DATE = True t2rss에서 라인 병합 속성 할당은 파일의 해당 버전에서만 발생하므로 항상 적용됩니다. 그러나 sourcetype 속성과 충돌합니 다. /system/local 버전에서 sourcetype은 "fatal-error" 값을 가지고, /apps/t2rss/local 버전에서는 "t2rss-error" 값을 가집니 다. 이것은 인덱스 시간에 적용되는 sourcetype 할당이므로 Splunk는 디렉터리 우선 순위를 결정하는 데 전역 컨텍스트를 사용 합니다. 전역 컨텍스트에서 Splunk는 system/local의 속성 할당에 가장 높은 우선 순위를 제공합니다. 따라서 sourcetype 속 성에는 "fatal-error" 값이 할당됩니다. 내부적으로 병합된 파일의 최종 버전은 다음과 같습니다. [source::/opt/locke/logs/error*] sourcetype = fatal-error SHOULD_LINEMERGE = True BREAK_ONLY_BEFORE_DATE = True 설정 파일 및 컨텍스트 리스트 Splunk는 파일이 전역 또는 앱/사용자 내에서 작동하는 컨텍스트를 기반으로 설정 파일을 어떻게 평가할지 결정합니다. 일반 적으로 데이터 입력, 인덱싱 또는 배포 작업에 영향을 미치는 파일은 전역이고, 검색 작업에 영향을 미치는 파일은 보통 앱/사 용자 컨텍스트를 가집니다. props.conf 및 transforms.conf 파일은 Splunk가 이러한 파일을 인덱스 시간 또는 검색 시간에 사용하는 지에 따라 앱/사용자 또는 전역 컨텍스트로 평가됩니다. 전역 설정 파일 admon.conf authentication.conf authorize.conf crawl.conf deploymentclient.conf distsearch.conf indexes.conf inputs.conf outputs.conf pdf_server.conf procmonfilters.conf props.conf -- global and app/user context pubsub.conf regmonfilters.conf report_server.conf restmap.conf searchbnf.conf segmenters.conf server.conf serverclass.conf serverclass.seed.xml.conf source-classifier.conf sourcetypes.conf sysmon.conf tenants.conf transforms.conf -- global and app/user context user-seed.conf -- special case: Must be located in /system/default web.conf wmi.conf 앱/사용자 설정 파일 alert_actions.conf app.conf audit.conf commands.conf 26

27 eventdiscoverer.conf event_renderers.conf eventtypes.conf fields.conf limits.conf literals.conf macros.conf multikv.conf props.conf -- global and app/user context savedsearches.conf tags.conf times.conf transactiontypes.conf transforms.conf -- global and app/user context user-prefs.conf workflow_actions.conf 설정 우선 순위 및 기타 문제 해결 Splunk의 설정 파일 시스템은 다른 많은 위치에서 많은 설정 파일이 중복되는 것을 지원합니다. 이러한 유연성이 주는 장점 은 Splunk 설치에서 어떤 설정 옵션의 어떤 값이 가끔씩 복잡해지는지 알아낼 수 있다는 것입니다. 지정된 상황에서 어떤 구 성 설정이 사용되는지 쉽게 알 수 있으려면 문제 해결 매뉴얼의 "btool을 사용하여 설정 문제 해결"을 읽어보십시오. 단일 props.conf 파일 내의 속성 우선 순위 파일 간 속성 우선 순위에 대해 잘 알고 있는 동시에 단일 props.conf 파일 내의 속성 우선 순위도 고려해야 할 경우가 있습니 다. 동일한 대상에 영향을 미치는 스탠자 집합 내의 우선 순위 둘 이상의 스탠자가 동일한 항목에 영향을 미치는 동작을 지정할 경우 스탠자의 ASCII 순서에 따라 항목이 평가됩니다. 예를 들어 props.conf에서 다음 스탠자를 지정한다고 가정해 보십시오. [source::.../bar/baz] attr = val1 [source::.../bar/*] attr = val2 attr의 두 번째 스탠자 값이 사용됩니다. 그 이유는 해당 경로가 ASCII 순서에서 더 높은 우선 순위를 가지기 때문입니다. props.conf의 기본 속성 우선 순위 재정의 props.conf의 기본 ASCII 우선 순위를 재정의하는 방법이 있습니다. priority 키를 사용하여 지정된 스탠자에 더 높거나 더 낮은 우선 순위를 지정할 수 있습니다. 예를 들어, 원본이 다음과 같고 source::az 패턴은 다음과 같다고 가정하십시오. [source::...a...] sourcetype = a [source::...z...] sourcetype = z 이 경우 "source::...a..." 패턴에 의해 제공된 설정이 "source::...z..."에 의해 제공된 설정보다 우선되는 것이 기본 동작입니다. 따라서 sourcetype의 값은 "a"가 됩니다. 기본 ASCII 순서를 재정의하려면 priority 키를 사용하십시오. [source::...a...] sourcetype = a priority = 5 [source::...z...] sourcetype = z 27

28 priority = 10 두 번째 스탠자에 더 높은 우선 순위를 할당하면 sourcetype의 값이 "z"가 됩니다. 고려해야 할 또 다른 속성 우선 순위 문제가 있습니다. 기본적으로 문자열이 문자 그대로 일치하는 스탠자("리터럴 일치 스탠 자")는 regex 패턴 일치 스탠자보다 우선합니다. 이것은 priority 키의 기본값 때문입니다. 0은 패턴 일치 스탠자의 기본값입니다. 100은 리터럴 일치 스탠자의 기본값입니다. 따라서 priority 키를 명시적으로 설정하여 이 동작을 변경하지 않을 경우 리터럴 일치 스탠자는 항상 패턴 일치 스탠자보다 우선합니다. priority키를 사용하여 sourcetype 패턴 또는 host 패턴과 같은 동일한 유형의 패턴 간에 발생하는 충돌을 해결할 수 있습니 다. 그러나 priority 키는 spec 유형 전체에서 우선 순위에 영향을 미치지 않습니다. 예를 들어, 우선 순위 키 값에 상관없이 source 패턴은 host 및 sourcetype 패턴보다 우선합니다. 여러 속성 할당에서 이벤트의 우선 순위 props.conf 파일은 host, source 또는 sourcetype(그리고 때로는 event type)에 의해 개별 이벤트를 처리하는 속성을 설정합 니다. 따라서 하나의 이벤트에 기본 필드(source, host 또는 sourcetype)에 따라 다르게 설정된 동일한 속성이 있을 수 있습 니다. 우선 순위는 다음과 같습니다. source host sourcetype 기본 props.conf 설정을 재정의할 수도 있습니다. 예를 들어, mylogfile.xml(기본적으로 sourcetype = xml_file로 레이블이 지 정됨)를 사용자 지정한다고 가정합니다. 이 설정은 source에 의해 속성이 설정되었기 때문에 다른 sourcetype을 수동으로 지정하더라도 설정이 변경될 때마다 전체 파일을 다시 인덱스합니다. 이 작업을 재정의하려면 source별 명시적 설정을 추가 하십시오. [source::/var/log/mylogfile.xml] CHECK_METHOD = endpoint_md5 설정 파일 복사 및 편집 방법 설정 파일을 편집하기 전에 다음 사항에 대해 알아야 합니다. 기본 설정 파일과 해당 파일의 위치, 그리고 편집한 파일을 저장할 위치에 대해 알아보려면 "설정 파일 디렉터리"를 참 조하십시오. 파일 구조와 편집할 속성이 설정되는 방법에 대해 알아보려면 "설정 파일 구성"을 참조하십시오. 설정 파일이 여러 디렉터리에서 계층화되고 결합되는 방법에 대해 알아보려면 "설정 파일 우선 순위"를 참조하십시오. 기본 파일 복사 파일의 속성을 사용자 지정하려는 경우 파일의 복사본을 원하는 디렉터리($SPLUNK_HOME/etc/system/local 등)에 만드십시오. 기본 설정 파일의 전체 콘텐츠를 복사하지 말고 사용자 지정할 속성만 복사하십시오. 이렇게 하는 이유는 기본값에 대한 모 든 Splunk 업데이트를 올바르게 배포하기 위해서입니다. 참고: 파일을 로컬 디렉터리에 복사할 때는 "쓰기" 권한을 부여해야 합니다. 예를 들어, 자체 서명 SSL 인증서를 사용하고 server.conf에서 새 인증서로 연결되는 경로를 재지정해야 하는 경우를 가정 해 보십시오. 이 경우 <SSL> 스탠자를 다른 스탠자와 함께 server.conf의 새로운 복사본에 복사한 후 SSL 스탠자만 편집하 고 나머지 스탠자는 기본값을 사용하십시오. 이후 릴리스에서 Splunk는 복사했지만 편집하지 않은 스탠자 중 하나인 server.conf의 기본 포트 설정 중 하나를 변경합니다. 다음에 Splunk를 업그레이드할 때는 속성 값이 있는 server.conf의 새 버전이 기본 디렉터리에 있는 server.conf 버전을 덮어 씁니다. 그러나 Splunk는 로컬 디렉터리에 있는 버전의 구성 설정에 우선 순위를 부여하기 때문에 기본 디렉터리에 기록된 새 포트는 적용되지 않습니다. 참고: 일부 설정 파일에는 기본 버전이 없습니다. 해당 설정 파일에는 여전히 복사본을 만드는 데 사용되는.spec 및.example 파일이 있습니다. 속성 지우기 속성을 null로 설정하여 속성을 지울 수 있습니다. 예: forwardedindex.0.whitelist = 이렇게 하면 기본 파일에 설정된 값을 포함하여 속성에 저장된 이전 값이 재정의되어 시스템에서 모든 값이 완전히 설정 해 제된 것으로 간주합니다. 28

29 주석 사용 설정 파일에 주석을 삽입할 수 있습니다. 주석을 삽입하려면 기호를 사용하십시오. This stanza forwards some log files. [monitor:///var/log] 중요: 주석은 왼쪽 여백에서 시작합니다. 스탠자 또는 속성과 같은 줄에 주석을 작성하지 마십시오. [monitor:///var/log] This is a really bad place to put your comment. 속성의 경우 예는 다음과 같습니다. a_setting = 5 5 is the best number 이 경우 a_setting 속성에 값 "5 5 is the best number"가 설정되므로 예기치 않은 결과가 발생할 수 있습니다. 비 UTF-8 운영 체제에서 설정 파일 만들기 및 편집 Splunk의 설정 파일은 ASCII/UTF-8 형식입니다. 비 UTF-8인 운영 체제에서 설정 파일을 편집하거나 만들 경우에는 파일을 ASCII/UTF-8로 저장하도록 사용할 편집기를 설정해야 합니다. 설정 파일 변경 후에 Splunk를 재시작해야 하는 경우 이 페이지는 현재 작업 중이며, 가까운 시일 내 자주 업데이트될 예정입니다. 설정 파일을 통해 Splunk에 변경 사항을 적용할 때는 Splunk를 재시작하여 해당 변경 사항이 시스템에 적용되었는지 확인해 야 합니다. 참고: Splunk Web에서 변경을 수행하면 재시작해야 하는 경우가 더 적습니다. 그 이유는 Splunk Web에서 자동으로 기본 설정 파일을 업데이트하고 실행 중인 Splunk 인스턴스(splunkd)에 변경 사항을 알리기 때문입니다. 이 항목에서는 변경 후 재시작할지 여부를 판단하는 데 도움이 되는 지침을 제공합니다. 변경 후 재시작할지 여부는 여러 가 지 요인에 의해 좌우되며, 이 항목에는 모든 요인이 모두 나와 있지 않습니다. 어떤 항목을 변경한 후 재시작 여부를 알려면 항상 설정 파일 또는 해당 참조 항목을 확인하십시오. 설정 파일의 전체 리스트와 각 파일의 기능에 대한 개요는 이 매뉴얼의 설정 파일 리스트를 참조하십시오. 포워더를 재시작해야 하는 상황 설정 파일 변경 사항을 헤비 포워더에 적용할 경우에는 포워더를 재시작해야 하지만 수신 인덱서는 재시작할 필요가 없습니 다. 변경 사항이 변경한 후 재시작하도록 이미 설정되어 있는 배포된 앱의 일부일 경우 포워더가 자동으로 재시작됩니다. Splunk Web을 재시작해야 하는 경우 Splunk Web 액세스를 위해 SSL을 활성화하거나 비활성화하려면 Splunk Web을 재시작해야 합니다. Splunkd를 재시작해야 하는 상황 일반적으로 다음을 수정하는 모든 작업이 해당됩니다. 인덱스 변경 인덱서와 인덱싱 동작에 영향을 미치는 설정 및 속성 사용자와 역할에 영향을 미치는 설정 및 속성 Splunk의 핵심 설정에 영향을 미치는 설정 및 속성 참고: 인덱싱에 영향을 미치는 설정을 UI와 CLI를 통해 변경하면 재시작 없이 즉시 적용됩니다. 인덱스 시간 필드 추출 타임스탬프 속성 사용자 및 역할 변경 설정 파일에서 사용자 및 역할과 관련된 다음과 같은 정보를 변경하면 재시작이 필요합니다. LDAP 설정(Splunk Web에서 이 정보를 변경하면 재시작 없이 변경 사항을 다시 로드할 수 있습니다.) 암호 변경 역할 기능 변경 사용자-역할 매핑과 같은 Splunk 기본 인증 변경 29

30 시스템 변경 시스템 설정이나 서버 상태에 영향을 미치는 정보를 변경하면 재시작이 필요합니다. 라이선싱 변경 웹 서버 설정 업데이트 일반 인덱서 설정 변경(사용 가능한 최소 디스크 공간, 기본 서버 이름 등) 일반 설정(예: 포트 설정) 변경 포워더의 출력 설정 변경 Splunk 서버 OS의 시간대 변경(Splunk는 시작 시 기본 OS에서 현지 표준 시간대를 가져옵니다.) 검색 헤드 풀 만들기 일부 앱을 설치할 경우 재시작해야 합니다. 설치하는 각 앱 문서를 참조하십시오. 재시작이 필요없는 Splunk 변경 사항 검색 시 프로세싱에 적용되는 설정은 즉시 적용되므로 재시작할 필요가 없습니다. 그 이유는 검색이 설정을 다시 로드하는 별도의 프로세스에서 실행되기 때문입니다. 예를 들어 룩업 테이블 및 태그와 event type을 각 검색 시 다시 읽습니다. 다음에 대한 변경 사항이 (제한 없이) 여기에 포함됩니다. 룩업 테이블 필드 추출 knowledge 객체 태그 Event type 검색 시 작업을 포함하는 파일은 다음과 같습니다. macros.conf props.conf. 검색 시 필드 추출에 대한 변경 사항을 검색 시 다시 읽습니다. transforms.conf savedsearches.conf.(변경 사항으로 인해 endpoint가 생성되면 재시작해야 합니다.) 자세히 알아보기 클러스터를 재시작해야 하는 경우와 방법에 대해 자세히 알아보십시오. 설정 파일 리스트 다음은 각 conf 파일에 해당하는 spec 파일과 example 파일의 리스트입니다. spec 또는 example 파일이 함께 제공되지 않 는 conf 파일도 있습니다. 이런 conf 파일을 편집하려면 지원 부서에 문의하십시오. 중요: $SPLUNK_HOME/etc/system/default/에 있는 conf 파일의 기본 복사본은 편집하지 마십시오. $SPLUNK_HOME/etc/system/local/ 또는 $SPLUNK_HOME/etc/apps/<app_name>/local에 있는 파일을 복사한 후 해당 복사본을 편집 하십시오. 파일 alert_actions.conf app.conf audit.conf authentication.conf authorize.conf commands.conf crawl.conf default.meta.conf deploymentclient.conf distsearch.conf eventdiscoverer.conf event_renderers.conf eventtypes.conf 용도 경고를 만듭니다. 사용자 지정 앱을 설정합니다. 감사(audit) 및 이벤트 해시를 설정합니다. Splunk 기본 제공 인증 또는 LDAP로 전환하고 LDAP를 설정합니다. 세분화된 액세스 제어를 포함하여 역할을 설정합니다. 검색 명령어를 사용자 지정 검색 스크립트에 연결합니다. 크롤링을 설정하여 새 데이터 원본을 찾습니다. 앱별 default.meta 파일을 만들 때 사용하는 템플릿 파일입니다. 배포 서버의 클라이언트 동작을 지정합니다. 분산 검색 동작을 지정합니다. typelearner(이벤트 검색)에서 무시하도록 조건을 설정합니다. 이벤트 렌더링 속성을 설정합니다. event type 정의를 만듭니다. 30

31 fields.conf indexes.conf inputs.conf instance.cfg.conf limits.conf literals.conf macros.conf multikv.conf outputs.conf pdf_server.conf procmon-filters.conf props.conf pubsub.conf restmap.conf savedsearches.conf searchbnf.conf segmenters.conf server.conf serverclass.conf serverclass.seed.xml.conf source-classifier.conf sourcetypes.conf tags.conf tenants.conf times.conf transactiontypes.conf transforms.conf user-seed.conf viewstates.conf web.conf wmi.conf workflow_actions.conf 다중값 필드를 만들고 인덱스 필드에 검색 기능을 추가합니다. 인덱스 설정을 관리 및 설정합니다. 데이터 입력을 설정합니다. 특정 Splunk 인스턴스의 설정을 지정 및 관리합니다. 이 파일은 내부 검색용 포워더 등을 식 별할 때 유용합니다. 검색 명령어에 대한 여러 제한(예: 최대 결과 크기 또는 실시간 동시 검색 수)을 설정합니다. Splunk Web에 표시되는 검색 오류 문자열과 같은 텍스트를 사용자 지정합니다. 검색 매크로를 만들고 사용합니다. 테이블 유형의 이벤트(ps, netstat, ls)에 대한 추출 규칙을 설정합니다. 포워딩 동작을 설정합니다. Splunk PDF 서버를 설정합니다. PDF 서버 앱은 Splunk Enterprise 6.0에서 더 이상 지원되 지 않습니다. 이 기능은 Splunk Enterprise 6.2에서 제거되었습니다. Windows 프로세스 데이터를 모니터링합니다. 시간대 오프셋, 사용자 지정 source type 규칙 및 패턴 충돌 우선 순위 등의 인덱싱 속성 구성 을 설정합니다. 또한 이벤트 속성에 대한 변형을 매핑합니다. 배포 서버의 사용자 지정 클라이언트를 정의합니다. 사용자 지정 REST endpoint를 만듭니다. 일반 보고서, 예약 보고서 및 경고를 정의합니다. 검색 길잡이를 설정합니다. 세그먼트화를 설정합니다. Splunk 백엔드(Splunkd와 Splunk Web 간 통신)에 SSL을 사용하도록 설정하고 인증 위치를 지정합니다. 배포 서버에서 사용할 배포 서버 클래스를 정의합니다. 시작 시 앱에서 배포 클라이언트를 시드하는 방법을 설정합니다. source type을 만들 때 무시할 조건(예: 중요한 데이터)입니다. source type 학습 규칙을 저장하는 컴퓨터 생성 파일입니다. 필드 태그를 설정합니다. 멀티테넌트 환경에서 배포를 설정합니다(지원되지 않음). 검색 앱에서 사용할 사용자 지정 시간 범위를 정의합니다. 트랜잭션 검색을 위해 트랜잭션 유형을 추가합니다. 데이터 입력에서 수행할 regex 변형을 설정합니다. props.conf와 함께 사용합니다. 기본 사용자 및 암호를 설정합니다. 이 파일은 Splunk에서 UI 뷰(차트 등)를 설정하기 위해 사용됩니다. Splunk Web을 설정하고 HTTPS를 활성화합니다. WMI(Windows Management Instrumentation) 입력을 설정합니다. 워크플로 작업을 설정합니다. 설정 매개 변수 및 데이터 파이프라인 데이터는 원시 입력 상태에서 검색 가능한 이벤트로 변환되기까지 여러 단계를 거칩니다. 이러한 프로세스를 데이터 파이프 라인이라고 하며, 데이터 파이프라인은 네 단계로 구성됩니다. 입력 파싱 인덱싱 검색 데이터 파이프라인의 각 단계에서는 서로 다른 설정 파일 매개 변수에 의존합니다. 어느 단계에서 특정 매개 변수가 사용되 는지 알면 Splunk 배포 토폴로지에서 매개 변수를 설정해야 할 위치를 파악할 수 있습니다. 31

32 데이터 파이프라인 그림 아래 도표는 데이터 파이프라인을 나타내는 그림입니다. 분산 배포 매뉴얼의 "Splunk를 통해 데이터가 이동되는 방식: 데이터 파이프라인"에는 데이터 파이프라인에 대한 자세한 설 명이 나와 있습니다. Splunk Enterprise 구성 요소와 각 파이프라인 단계의 상관 관계 하나 이상의 Splunk Enterprise 구성 요소가 각 파이프라인 단계를 수행할 수 있습니다. 예를 들어 유니버설 포워더, 헤비 포 워더 또는 인덱서가 입력 단계를 수행할 수 있습니다. 데이터는 각 단계를 한 번만 거치므로, 각 설정은 하나의 구성 요소, 즉 배포에서 해당 단계를 처리하는 첫 구성 요소에만 속 합니다. 예를 들어, 여러 유니버설 포워더를 통해 시스템에 들어오는 데이터가 있고, 이 포워더는 데이터를 중간 헤비 포워더 에 포워딩하고, 이 포워더는 다시 데이터를 인덱서에 포워딩하는 경우가 있을 수 있습니다. 이런 경우에는 해당 데이터의 입 력 단계가 유니버설 포워더에서 수행되고 파싱 단계는 헤비 포워더에서 수행됩니다. 입력 파싱 인덱싱 검색 데이터 파이프라인 단계 인덱서 유니버설 포워더 헤비 포워더 인덱서 헤비 포워더 인덱서 인덱서 검색 헤드 32 이 역할을 수행할 수 있는 구성 요소

33 설정 매개 변수를 설정하는 위치는 특정 배포의 구성 요소에 따라 다릅니다. 예를 들어 파싱 매개 변수는 대부분의 경우 인덱 서에서 설정합니다. 그러나 인덱서에 데이터를 전달하는 헤비 포워더가 있을 경우에는 파싱 매개 변수를 헤비 포워더에서 설 정합니다. 마찬가지로, 검색 매개 변수는 검색 헤드에서 설정합니다(있을 경우). 그러나 전용 검색 헤드를 배포하지 않을 경 우에는 인덱서에서 검색 매개 변수를 설정합니다. 자세한 내용은 분산 배포 매뉴얼의 "구성 요소 및 역할"을 참조하십시오. 설정 매개 변수와 파이프라인 단계의 상관 관계 이것은 설정 매개 변수가 어떤 단계에 사용되는지 보여주는 non-exhaustive 리스트입니다. 이 정보와 함께 특정 배포에서 어 느 Splunk 구성 요소가 각 단계에서 사용되는지 알고 있으면 어느 위치에 각 설정을 구성해야 하는지 판단할 수 있습니다. 예를 들어, 입력을 처리하는 데 유니버설 포워더를 사용할 경우 해당 포워더에서 inputs.conf 매개 변수를 설정해야 합니다. 그러나 인덱서가 직접 네트워크 입력을 처리할 경우에는 인덱서에서 네트워크와 관련된 inputs.conf 매개 변수를 설정해야 합니다. 입력 단계 파싱 단계 inputs.conf props.conf CHARSET NO_BINARY_CHECK CHECK_METHOD sourcetype wmi.conf regmon-filters.conf props.conf LINE_BREAKER, SHOULD_LINEMERGE, BREAK_ONLY_BEFORE_DATE 및 다른 모든 라인 병합 설정 TZ, DATETIME_CONFIG, TIME_FORMAT, TIME_PREFIX 및 다른 모든 시간 추출 설정과 규칙 TRANSFORMS*에는 이벤트당 대기열 필터링, 이벤트당 인덱스 할당, 이벤트당 경로 설정이 포함되고, 정의된 순서대로 적용됩니다. SEDCMD* MORE_THAN*, LESS_THAN* transforms.conf props.conf의 TRANSFORMS* 절에서 참조되는 스탠자 LOOKAHEAD, DEST_KEY, WRITE_META, DEFAULT_VALUE, REPEAT_MATCH datetime.xml 인덱싱 단계 검색 단계 props.conf SEGMENTATION* indexes.conf segmenters.conf props.conf EXTRACT* REPORT* LOOKUP* KV_MODE FIELDALIAS* rename transforms.conf props.conf의 REPORT* 절에서 참조되는 스탠자 filename, external_cmd 및 기타 모든 룩업 관련 설정 FIELDS, DELIMS MV_ADD 룩업 폴더의 룩업 파일 bin 폴더의 검색 및 룩업 스크립트 검색 명령어 및 룩업 스크립트 savedsearches.conf eventtypes.conf tags.conf commands.conf alert_actions.conf macros.conf fields.conf transactiontypes.conf multikv.conf 33

34 기타 구성 설정 분산된 Splunk 환경에서는 제대로 작동하지 않는 설정이 있습니다. 이는 예외적인 경향이 있으며 해당 설정은 다음과 같습니 다. props.conf CHECK_FOR_HEADER, LEARN_MODEL, maxdist. 파싱 단계에서 생성되지만, 생성된 설정을 검색 단계 설정 위치로 이동시켜야 합니다. 설정 정보 백업 Splunk의 모든 설정 정보는 설정 파일에 포함됩니다. 설정 파일 집합을 백업하려면 $SPLUNK_HOME/etc/의 아카이브를 만들거 나 사본을 만드십시오. 이 디렉터리에는 하위 디렉터리와 함께 저장된 검색, 사용자 계정, 태그, 사용자 지정 source type 이 름 및 기타 설정 정보를 비롯하여 Splunk 설치와 기타 모든 앱에 대한 모든 기본 설정과 사용자 지정 설정이 포함됩니다. 복원할 새 Splunk 인스턴스에 이 디렉터리를 복사합니다. 이 작업을 위해 Splunk를 중지하지 않아도 됩니다. 설정 파일에 대한 자세한 내용은 "설정 파일에 대하여"를 참조하십시오. 클러스터 마스터 노드 백업 인덱스 복제를 사용하여 마스터 노드의 정적 설정을 백업할 수 있습니다. 이 기능은 주 마스터의 작동이 중단된 경우 주 마스 터의 역할을 대신할 수 있는 대기 마스터를 설정하는 경우에 특별하게 사용됩니다. 자세한 내용은 인덱서 및 클러스터 관리 매뉴얼의 "마스터 설정"을 참조하십시오. 명령줄 인터페이스(CLI)를 사용한 Splunk Enterprise 관 리 CLI에 대하여 Splunk 명령줄 인터페이스(CLI)를 사용하여 Splunk 서버에서 검색을 모니터링, 설정 및 실행할 수 있습니다. CLI 도움말은 제품에 있으며 터미널이나 셸 인터페이스를 통해 액세스할 수 있습니다. 이 항목에서는 이 정보에 액세스하는 방법과 사용 가능한 명령에 대해 설명합니다. CLI에 액세스하는 방법 Splunk CLI는 $SPLUNK_HOME/bin/splunk에 있습니다. Splunk CLI에 액세스하려면 다음 중 하나가 필요합니다. Splunk 서버에 대한 셸 액세스 원격 Splunk 서버에서 올바른 포트에 액세스할 수 있는 권한 관리자 또는 루트 권한이 있는 경우 Splunk 설치의 최상위 디렉터리를 셸 경로에 추가하여 CLI 액세스를 단순화할 수 있습니 다. $SPLUNK_HOME 변수는 최상위 디렉터리를 나타냅니다. SPLUNK_HOME환경 변수를 설정하고 $SPLUNK_HOME/bin을 셸의 경로에 추가하십시오. 이 예제는 기본 위치에 Splunk를 설치한 Linux/BSD/Solaris 사용자에 해당됩니다. export SPLUNK_HOME=/opt/splunk export PATH=$SPLUNK_HOME/bin:$PATH 이 예제는 기본 위치에 Splunk를 설치한 Mac 사용자에 해당됩니다. export SPLUNK_HOME=/Applications/Splunk export PATH=$SPLUNK_HOME/bin:$PATH 이제 다음을 사용하여 CLI 명령을 호출할 수 있습니다../splunk <command> CLI 도움말 문서 관리자 권한이 있을 경우 CLI를 사용하여 Splunk 서버를 검색할 뿐만 아니라 설정 및 모니터링도 수행할 수 있습니다. Splunk 설정 및 모니터링에 사용되는 CLI 명령은 검색 명령어가 아닙니다. 검색 명령어는 search 및 dispatch CLI 명령에 대 한 인수입니다. 일부 명령을 사용하려면 사용자 이름 및 암호로 인증해야 하거나 대상 Splunk 서버를 지정해야 합니다. CLI에 대한 도움말 정보를 조회하려면 다음 명령어를 입력하십시오. 34

35 ./splunk help 특정 CLI 명령 또는 작업에 대한 도움말에 액세스하는 방법은 이 매뉴얼의 "CLI 도움말 보기" 및 "관리 CLI 명령"을 참조하십 시오. Mac 사용자 참고 사항 Mac OS X에서는 시스템 파일 또는 디렉터리에 액세스하는 명령을 실행하려면 수퍼사용자 수준 액세스가 필요합니다. 새로 운 셸에 대해 루트로 sudo 또는 "su -"를 사용하여 CLI 명령을 실행하십시오. sudo를 사용하는 방법이 권장됩니다. (기본적 으로 사용자 "루트"는 활성화되지 않았지만 관리자는 sudo를 사용할 수 있습니다.) Windows에서 CLI 작업 Windows에서 CLI 명령에 액세스하고 사용하려면 관리자로서 cmd.exe를 먼저 실행하십시오. 또한 Windows를 사용할 경우 Splunk는 CLI 명령을 실행하기 위해 "./"가 필요하지 않습니다. 답변 질문이 있으십니까? Splunk 응답 페이지에 가면 CLI 사용과 관련하여 Splunk 커뮤니티에서 올린 질문과 답변을 볼 수 있습 니다. CLI 도움말 보기 이 항목에서는 CLI 명령과 명령을 사용하는 방법에 대한 정보가 포함되어 있는 Splunk 기본 제공 CLI 도움말 참조에 액세스 하는 방법을 설명합니다. 또한 CLI 명령과 함께 사용할 수 있는 매개 변수인 범용 매개 변수에 대해서도 간략하게 설명합니 다. CLI 도움말 참조 액세스 CLI 명령 또는 CLI 명령 구문을 찾아야 할 경우 Splunk 기본 제공 CLI 도움말 참조를 사용하십시오. help 명령어를 사용하여 기본 도움말 정보에 액세스하면 시작할 수 있습니다../splunk help 이렇게 하면 관리 명령, 클러스터링, 포워딩, 라이선싱, 검색 등 보다 구체적인 CLI 도움말 항목에 쉽게 액세스할 수 있도록 다 양한 개체 리스트가 반환됩니다. 범용 매개 변수 일부 명령을 사용하려면 사용자 이름 및 암호로 인증해야 하거나 대상 호스트 또는 앱을 지정해야 합니다. 이러한 명령에는 범용 매개 변수 auth, app 또는 uri 중 하나를 포함할 수 있습니다../splunk [command] [object] [-parameter <value> <value>]... [-app] [-owner] [-uri] [-auth] 매개 변 수 app auth owner uri 설명 명령을 실행할 앱 또는 네임스페이스를 지정합니다. 검색의 경우 기본값은 검색 앱입니다. 로그인하기 위해 명령을 실행하는 데 필요한 로그인 자격 증명을 지정합니다. 개체와 연관된 소유자/사용자 컨텍스트를 지정합니다. 지정되지 않은 경우 기본값은 현재 로그인되어 있는 사용 자입니다. 지정된(원격) Splunk 서버에서 명령을 실행합니다. app CLI에서 app은 create app 또는 enable app과 같은 많은 명령에서 개체로 사용됩니다. 그러나 특정 앱에서 이 명령을 실행할 경우에는 CLI 명령에 추가할 수 있는 매개 변수로도 사용됩니다. 구문:./splunk command object [-parameter value]... -app appname 예를 들어 CLI에서 검색을 실행하는 경우 기본값은 검색 앱입니다. 다른 앱에서 검색을 실행하려면 다음과 같이 입력하십시 오../splunk search "eventype=error stats count by source" -deatach f -preview t -app unix auth 35

36 CLI 명령에 인증이 필요할 경우, Splunk에서 사용자 이름과 암호를 입력할 것을 요청합니다. 또한 -auth 플래그를 사용하면 이 명령으로 해당 정보를 인라인으로 전달할 수 있습니다. 또한 auth 매개 변수는 현재 로그인한 사용자의 권한이 아닌 다른 권한을 요구하는 명령을 실행해야 할 경우에도 유용합니다. 참고: auth 는 CLI 명령 인수에 지정되는 마지막 매개 변수여야 합니다. 구문:./splunk command object [-parameter value]... -auth username:password uri 원격 Splunk 서버에서 명령을 실행하려면 -uri 플래그를 사용하여 대상 호스트를 지정하십시오. 구문:./splunk command object [-parameter value]... -uri specified-server 다음 형식으로 대상 Splunk 서버를 지정하십시오. [http https]://name_of_server:management_port name_of_server에 대한 IP 주소를 지정할 수 있습니다. IPv4 형식과 IPv6 형식이 모두 지원됩니다. 예를 들어 specifiedserver의 경우 :80 또는 "[2001:db8::1]:80"입니다. 기본적으로 splunkd는 IPv4만 수신 대기합니다. IPv6 지원을 사 용하려면 "IPv6용 Splunk 설정"의 설명을 참조하십시오. 예: 다음 예제는 포트 8089의 원격 "splunkserver"에서 검색 결과를 반환합니다../splunk search "host=fflanda error 404 *.gif" -auth admin -uri 원격 서버에서 실행할 수 있는 CLI 명령에 대한 자세한 내용은 이 장의 다음 항목을 참조하십시오. 유용한 도움말 항목 기본 Splunk CLI 도움말을 실행하면 다음과 같은 개체가 나열됩니다. 관리 CLI 명령 입력 추가 또는 편집, 구성 설정 업데이트, 검색과 같은 관리 기능에 대한 CLI를 사용할 수 있습니다. 관리 CLI 명령 리스트를 보려면 다음 명령을 입력하십시오../splunk help commands 이 명령에 대한 자세한 내용은 이 매뉴얼의 "관리 CLI 명령" 항목을 참조하십시오. 클러스터링에 대한 CLI 도움말 클러스터링이라고도 하는 인덱스 복제는 데이터 가용성, 데이터 충실도 및 재해 허용 범위를 보장하고 검색 성능을 개선하기 위한 목적으로 데이터를 복제하도록 설정된 인덱서 클러스터로 이루어진 Splunk 기능입니다. CLI를 사용하여 클러스터 마스터 또는 클러스터 피어에서 클러스터링 설정을 보고 편집할 수 있습니다. 클러스터링과 관련 된 명령 및 매개 변수 리스트를 보려면 다음 명령을 입력하십시오../splunk help clustering 자세한 내용은 인덱서 및 클러스터 관리 매뉴얼의 "클러스터 및 인덱스 복제에 대하여" 및 "CLI를 사용하여 클러스터 설정"을 참조하십시오. Splunk 컨트롤에 대한 CLI 도움말 CLI를 사용하여 Splunk 서버(splunkd) 및 웹(splunkweb) 프로세스를 시작, 중지 및 재시작할 수 있고 프로세스가 실행되고 있 는지 확인할 수 있습니다. 컨트롤 리스트를 보려면 다음 명령을 입력하십시오../splunk help controls 자세한 내용은 관리자 매뉴얼의 "Splunk 시작 및 중지"에서 확인하십시오. 데이터 관리에 대한 CLI 도움말 Splunk에 데이터를 추가할 때 Splunk는 데이터를 처리하고 인덱스에 저장합니다. 기본적으로 Splunk에 입력하는 데이터는 main 인덱스에 저장되지만, CLI를 사용하여 다른 데이터 입력에 대해 다른 인덱스를 사용하도록 다른 인덱스를 만들고 지정 36

37 할 수 있습니다. 인덱스 및 데이터 저장소를 관리하기 위한 개체 및 명령어 리스트를 보려면 다음 명령을 입력하십시오../splunk help datastore./splunk help index 자세한 내용은 인덱서 및 클러스터 관리 매뉴얼의 "인덱스 관리에 대하여", "다중 인덱스 설정" 및 "Splunk에서 인덱스 및 데 이터 제거"에서 확인하십시오. 분산 검색 배포에 대한 CLI 도움말 CLI를 사용하여 분산 검색 설정을 보고 관리할 수 있습니다. 개체 및 명령어 리스트를 보려면 다음 명령을 입력하십시오../splunk help distributed 분산 Splunk의 작동 방식 및 분산 검색 설정 방법에 대해 자세히 알아보려면 분산 배포 매뉴얼의 "분산 Splunk 개요", "(분산 환경의) 구성 요소 및 역할", "분산 검색에 대하여" 및 "분산 검색 설정"을 참조하십시오. 포워딩 및 수신에 대한 CLI 도움말 Splunk 배포 작업에는 하나 이상의 수신기에 데이터를 포워딩하는 포워더가 수십 대에서 수백 대까지 포함될 수 있습니다. 이 경우 CLI를 사용하여 데이터 포워딩 설정을 보고 관리할 수 있습니다. 포워딩 개체 및 명령어 리스트를 보려면 다음 명령 을 입력하십시오../splunk help forwarding 자세한 내용은 분산 배포 매뉴얼의 "(분산 환경의) 구성 요소 및 역할"과 "포워딩 및 수신에 대하여"를 참조하십시오. 검색 및 실시간 검색에 대한 CLI 도움말 Historical 검색 및 실시간 검색을 실행하는 경우에도 CLI를 사용할 수 있습니다. Splunk 검색 및 실시간 검색에 대한 도움말 페이지에 액세스하려면 다음 명령을 입력하십시오../splunk help search./splunk help rtsearch 또한 search-commands, search-fields 및 search-modifiers 개체를 사용하면 각 도움말에 대한 설명과 구문을 확인할 수 있습 니다../splunk help search-commands./splunk help search-fields./splunk help search-modifiers 참고: Splunk CLI에서는 공백이 구분 기호로 해석됩니다. 둘 이상의 단어로 구성된 항목 이름에서 단어 사이에 대시를 사용 하십시오. CLI를 사용하여 데이터를 검색하는 방법에 대한 자세한 내용은 검색 참조 매뉴얼의 "CLI 검색에 대하여", "CLI 검색 구문" 및 검색 매뉴얼의 "CLI의 실시간 검색 및 보고서"를 참조하십시오. 관리 CLI 명령 이 항목에서는 Splunk 서버와 분산 배포를 관리하거나 설정하는 데 사용되는 명령인 관리 CLI 명령에 대해 설명합니다. CLI에 액세스하는 방법과 CLI 도움말 정보에 대한 내용은 위의 "CLI 도움말 보기" 항목을 참조하십시오. CLI를 통해 검색을 실행하는 방법에 대해 더 자세히 알아보려면 검색 참조 매뉴얼의 "CLI 검색에 대하여"를 참조하십시오. Splunk 역할 설정에는 실행할 수 있는 작업(명령)이 나와 있습니다. 대부분의 작업에는 Splunk 관리자 권한이 필요합니다. Splunk 사용자 및 역할 설정과 관리에 대한 내용은 관리자 매뉴얼의 "사용자 및 역할에 대하여" 항목을 참조하십시오. Splunk CLI 명령 구문 다음은 CLI 명령에 대한 일반 구문입니다../splunk <command> [<object>] [[-<parameter>] <value>]... 다음 사항을 고려하십시오. 일부 명령의 경우 개체 또는 매개 변수가 필요하지 않습니다. 일부 명령의 경우 값 단독으로 지정할 수 있는 기본 매개 변수가 있습니다. 명령 및 개체 명령은 수행하는 작업입니다. 개체는 수행하는 작업의 대상입니다. 명령어 37 개체

38 add apply anonymize clean diag disable display edit enable export import install find help list login, logout package reload remove rolling-restart rtsearch search set show spool start, stop, restart status validate version exec, forward-server, index, licenser-pools, licenses, monitor, oneshot, saved-search, search-server, tcp, udp, user cluster-bundle source all, eventdata, globaldata, userdata, inputdata 없음 app, boot-start, deploy-client, deploy-server, dist-search, index, listen, local-index, perfmon, webserver, web-ssl, wmi app, boot-start, deploy-client, deploy-server, dist-search, index, jobs, listen, local-index app, cluster-config, exec, index, licenser-localslave, licenser-groups, monitor, saved-search, search-server, tcp, udp, user app, boot-start, deploy-client, deploy-server, dist-search, index, listen, local-index, perfmon, webserver, web-ssl, wmi eventdata, userdata userdata app logs 없음 cluster-config, cluster-generation, cluster-peers, cluster-buckets, deploy-clients, exec, forward-server, index, licenser-groups, licenser-localslave, licenser-messages, licenserpools, licenser-slaves, licenser-stacks, licenses, jobs, master-info, monitor, peer-info, peerbuckets, perfmon, saved-search, search-server, tcp, udp, user, wmi 없음 app ad, auth, deploy-server, index, monitor, registry, script, tcp, udp, perfmon, wmi app, exec, forward-server, index, jobs, licenser-pools, licenses, monitor, saved-search, search-server, tcp, udp, user cluster-peers app, batch, detach, earliest_time, header, index_earliest, index_latest, max_time, maxout, output, preview, rt_id, timeout, wrap app, batch, detach, earliest_time, header, id, index_earliest, index_latest, latest_time, max_time, maxout, output, preview, timeout, wrap datastore-dir, deploy-poll, default-hostname, default-index, minfreemb, servername, servertype, splunkd-port, web-port config, cluster-bundle-status, datastore-dir, deploy-poll, default-hostname, default-index, jobs, minfreemb, servername, splunkd-port, web-port 없음 splunkd, splunkweb splunkd, splunkweb index 없음 CLI를 사용하여 문제 해결 Splunk의 CLI에는 Splunk 문제를 해결하는 데 도움이 되는 다양한 도구도 포함되어 있습니다. 이러한 도구는 다음과 같이 Splunk CLI 명령 cmd를 사용하여 호출합니다../splunk cmd <tool> CLI 유틸리티 리스트는 문제 해결 매뉴얼의 "지원에서 사용할 수 있는 명령줄 도구"를 참조하십시오. CLI를 사용하여 원격 Splunk 서버 관리 CLI 명령에서 uri 매개 변수를 사용하여 다른 Splunk 서버로 명령을 전송하고 로컬 서버에서 그 결과를 볼 수 있습니다. 38

39 이 항목에서는 다음에 대해 설명합니다. uri 매개 변수 사용 구문 원격으로 사용할 수 없는 CLI 명령 참고: 4.1.4부터는 기본 암호를 변경하기 전까지 관리자의 원격 CLI 액세스를 기본적으로 사용할 수 없습니다. 원격 액세스 활성화 Splunk Free를 실행할 경우(로그인 자격 증명 필요 없음) $SPLUNK_HOME/etc/system/local/server.conf를 편집하고 값을 설정 할 때까지 기본적으로 원격 액세스를 사용할 수 없습니다. allowremotelogin=always 설정 파일 편집에 대한 자세한 내용은 이 매뉴얼의 설정 파일에 대하여를 참조하십시오. CLI 명령을 원격 서버로 전송 CLI 명령에서 uri 매개 변수를 사용하는 일반 구문은 다음과 같습니다../splunk command object [-parameter <value>]... -uri <specified-server> uri 값인 specified-server 형식은 다음과 같이 지정됩니다. [http https]://name_of_server:management_port 또한 name_of_server는 원격 Splunk 서버의 완전한 도메인 이름이거나 IP 주소입니다. 중요: 이 uri 값은 원격 Splunk 서버의 web.conf에 정의된 mgmthostport 값입니다. 자세한 내용은 이 매뉴얼의 "web.conf 참 조"를 참조하십시오. CLI에 대한 일반적인 내용은 이 매뉴얼의 "CLI에 대하여" 및 "CLI 도움말 보기"를 참조하십시오. 원격 서버 검색 다음 예제는 원격 "splunkserver"의 검색 결과를 반환합니다../splunk search "host=fflanda error 404 *.gif" -uri CLI를 사용한 검색 구문에 대한 자세한 내용은 검색 참조 매뉴얼의 "CLI 검색에 대하여"를 참조하십시오. 원격 서버에 설치된 앱 보기 다음 예제는 원격 "splunkserver"에 설치된 앱 리스트를 반환합니다../splunk display app -uri 기본 URI 값 변경 SPLUNK_URI 환경 변수를 사용하여 기본 URI 값을 설정할 수 있습니다. 이 값이 원격 서버의 URI 값이 되도록 변경할 경우 해당 원격 서버에 액세스할 때마다 uri 매개 변수를 포함할 필요가 없습니다. SPLUNK_URI의 값을 변경하려면 다음과 같이 입력하십시오. $ export SPLUNK_URI=[http https]://name_of_server:management_port For Unix shells C:\> set SPLUNK_URI=[http https]://name_of_server:management_port For Windows shell 위의 예제에서는 다음과 같이 입력하여 SPLUNK_URI 값을 변경할 수 있습니다. $ export SPLUNK_URI= 원격으로 실행할 수 없는 CLI 명령 서버를 제어하는 명령을 제외한 모든 CLI 명령을 원격으로 실행할 수 있습니다. 이러한 서버 제어 명령에는 다음이 포함됩니 다. 시작, 중지, 재시작 상태, 버전 39

40 CLI 도움말 참조에서 모든 CLI 명령을 볼 수 있습니다. 자세한 내용은 이 매뉴얼의 "CLI 도움말 보기"를 참조하십시오. CLI 로그인 배너 사용자 지정 CLI를 통해 데이터 액세스를 제공할 경우에는 사용자에게 모니터링, 사용자의 법적 의무, 그리고 오용에 대한 처벌에 대해 알 리기 위해 로그인 배너를 사용자 지정해야 할 수 있습니다. CLI 로그인을 위한 다른 보안도 (기본 인증 형태로) 추가할 수 있 습니다. 사용자 지정 로그인 배너를 만들고 기본 인증을 추가하려면 다음 스탠자를 로컬 server.conf 파일에 추가하십시오. [httpserver] cliloginbanner = <string> allowbasicauth = true false basicauthrealm = <string> 다음과 같은 경우: cliloginbanner = <string> 사용자에게 인증 자격 증명을 요청하기 전에 Splunk CLI에 표시할 메시지(액세스 정책 정보 등)를 작성합니다. 기본값은 메 시지 없음입니다. 여러 줄로 된 배너를 만들려면 각 줄을 큰따옴표로 묶고 쉼표로 구분된 리스트에 배치하십시오. 예: cliloginbanner="line 1","Line 2","Line 3" 큰따옴표를 배너 텍스트에 포함하려면 따옴표 2개를 연속으로 사용합니다. 예: cliloginbanner="this is a line that ""contains quote characters""!" allowbasicauth = true false의 경우: 클라이언트가 Splunk 서버에 인증된 요청을 할 때 Splunk의 기존(authtoken) 인증 외에 "HTTP Basic" 인증도 사용하도록 하 려면 이 값을 true로 설정합니다. 이 설정은 프로그램을 통해 REST endpoint에 액세스하고 웹 브라우저에서 REST API에 액세스할 수 있도록 허용할 때 유용하며, UI 또는 CLI에서는 필요하지 않습니다. 기본값은 true입니다. basicauthrealm = <string>의 경우: allowbasicauth를 활성화한 경우에는 이 속성을 사용하여 자격 증명이 요청될 때 웹 브라우저에서 제공할 수 있는 텍스트 문 자열을 추가할 수 있습니다. 서버 또는 액세스 정책을 설명하는 짧은 메시지를 표시할 수 있습니다. 기본적으로 표시되는 텍 스트는 "/splunk"입니다. Splunk Enterprise 시작 및 초기 작업 수행 Splunk Enterprise 시작 및 중지 이 항목에서는 Splunk Enterprise를 시작하고 중지하는 방법에 대해 간략히 설명합니다. Windows에서 Splunk Enterprise 시작 Windows에서 Splunk Enterprise는 기본적으로 C:\Program Files\Splunk에 설치됩니다. Splunk 설명서에 나오는 많은 예에 서는 $SPLUNK_HOME을 사용하여 Splunk 설치 디렉터리를 나타냅니다. Splunk Enterprise를 기본 디렉터리에 설치한 경우 이 $SPLUNK_HOME(또는 Windows 계열 %SPLUNK_HOME%) 문자열을 C:\Program Files\Splunk로 바꿀 수 있습니다. Splunk Enterprise가 splunkd 및 splunkweb이라는 두 가지 서비스를 설치합니다. 일반적인 작업에서는 Splunk Web 인터페 이스를 포함한 모든 Splunk Enterprise 작업을 처리하는 splunkd만 실행됩니다. 이를 변경하려면 Splunk Enterprise를 기존 모드로 설정해야 합니다. "기존 모드로 Windows에서 Splunk Enterprise 시작"을 참조하십시오. 다음 방법 중 하나를 사용하여 Windows에서 Splunk를 시작 및 중지할 수 있습니다. 1. Windows 서비스 제어판(Start -> Control Panel -> Administrative Tools -> Services에서 액세스)을 통해 Splunk Enterprise 프로세스를 시작 및 중지합니다. 서버 데몬 및 웹 인터페이스: splunkd 웹 인터페이스(기존 모드에서만): splunkweb. 일반적인 작업에서는 시작 요청을 수신하면 이 서비스가 시작된 후 즉시 중단됩니다. 2. NET START <service> 또는 NET STOP <service> 명령어를 사용하여 명령 프롬프트에서 Splunk Enterprise 서비스를 시작 및 중지합니다. 서버 데몬 및 웹 인터페이스: splunkd 웹 인터페이스(기존 모드에서만): splunkweb. 일반적인 작업에서는 시작 요청을 수신하면 이 서비스가 시작된 후 즉시 중단됩니다. 40

41 3. %SPLUNK_HOME%\bin으로 이동하고 다음 명령어를 입력하여 두 프로세스를 동시에 시작, 중지 또는 재시작합니다. > splunk [start stop restart] 기존 모드로 Windows에서 Splunk Enterprise 시작 splunkd 및 splunkweb이 모두 실행되는 기존 모드로 Splunk Enterprise를 실행하려는 경우 설정 매개 변수를 변경해야 합니 다. 중요: 기존 모드에서 영구적으로 Splunk Web을 실행하지 마십시오. 기존 모드를 사용하면 사용자 인터페이스와 주요 splunkd 서비스가 새롭게 통합되어 발생한 문제를 일시적으로 해결할 수 있습니다. 문제가 해결되면 Splunk Web을 최대한 빨리 일반 모드로 전환하십시오. Splunk Enterprise를 기존 모드로 설정하려면 다음을 수행하십시오. 1. 명령 프롬프트에서 %SPLUNK_HOME%\etc\system\default로 이동합니다. 2. web.conf의 복사본을 만들고 %SPLUNK_HOME%\etc\system\local에 넣습니다. 3. %SPLUNK_HOME%\etc\system\local에서 web.conf를 편집하십시오. 4. web.conf에서 appserverports 및 httpport 속성을 다음과 같이 설정합니다. [settings] appserverports = 0 httpport = 파일을 저장하고 닫습니다. 6. Splunk Enterprise를 재시작합니다. splunkd 및 splunkweb 서비스가 실행을 시작하고 유지합니다 name>:<httpport>로 이동하고 자격 증명을 입력하여 Splunk Enterprise에 로그인합니다. 일반적인 Splunk Enterprise 작업을 복원하려면 %SPLUNK_HOME%\etc\system\local\web.conf를 편집하고 appserverports 및 httpport 속성을 제거합니다. UNIX에서 Splunk Enterprise 시작 Splunk Enterprise는 *nix splunkd에서 하나의 프로세스로 설치합니다. 일반적인 작업에서는 Splunk Web 인터페이스를 포 함한 모든 Splunk Enterprise 작업을 처리하는 splunkd만 실행됩니다. 이를 변경하려면 Splunk Enterprise를 기존 모드로 설 정해야 합니다. "기존 모드로 Unix에서 Splunk Enterprise 시작"을 참조하십시오. Splunk Enterprise 시작 Splunk Enterprise 서버 호스트의 셸 프롬프트에서 다음 명령어를 실행하십시오. splunk start 참고: 부팅 시 Splunk Enterprise를 시작하도록 설정한 경우 서비스 명령어를 사용하여 Splunk Enterprise를 시작해야 합니 다. 이렇게 하면 init.d 스크립트에서 설정된 사용자가 소프트웨어를 시작하게 됩니다. service splunk start 이렇게 하면 splunkd(인덱서 및 Splunk Web 인터페이스)가 시작됩니다. 두 가지 프로세스를 각각 시작하려면 다음 명령어를 입력하십시오. splunk start splunkd 또는 (기존 모드에서만) splunk start splunkweb 참고: startwebserver 속성이 비활성화되었거나 appserverports 속성이 web.conf에서 0 외의 다른 값으로 설정된 경우 수동으 로 splunkweb을 시작하면 아무 작업도 수행되지 않습니다. 두 가지 경우 모두 splunkweb 프로세스가 시작되지 않습니다. 기존 모드로 Unix에서 Splunk Enterprise 시작"을 참조하십시오. Splunk Enterprise(splunkd 또는 splunkweb)를 재시작하려면 다음 명령어를 입력하십시오. splunk restart splunk restart splunkd (기존 모드에서만) splunk restart splunkweb 41

42 기존 모드로 Unix에서 Splunk Enterprise 시작 splunkd 및 splunkweb이 모두 실행되는 방법으로 Splunk Enterprise를 실행하려는 경우 Splunk Enterprise를 기존 모드로 설 정해야 합니다. Splunk Enterprise를 기존 모드로 설정하려면 다음을 수행하십시오. 1. 셸 프롬프트에서 $SPLUNK_HOME/etc/system/default로 이동합니다. 2. web.conf의 복사본을 만들고 $SPLUNK_HOME/etc/system/local에 넣습니다. 3. $SPLUNK_HOME/etc/system/local에서 web.conf를 편집하십시오. 4. web.conf에서 appserverports 및 httpport 속성을 다음과 같이 설정합니다. [settings] appserverports = 0 httpport = 파일을 저장하고 닫습니다. 6. Splunk Enterprise를 재시작합니다("Unix에서 Splunk Enterprise 시작" 참조). splunkd 및 splunkweb 서비스가 실행을 시작 하고 유지합니다 name>:<httpport>로 이동하고 자격 증명을 입력하여 Splunk Enterprise에 로그인합니다. 일반적인 Splunk Enterprise 작업을 복원하려면 %SPLUNK_HOME%\etc\system\local\web.conf를 편집하고 appserverports 및 httpport 속성을 제거합니다. Splunk Enterprise 중지 Splunk Enterprise를 종료하려면 다음 명령을 실행하십시오. splunk stop splunkd 및 Splunk Web을 각각 중지하려면 다음 명령어를 입력하십시오. splunk stop splunkd 또는 (기존 모드에서만) splunk stop splunkweb Splunk가 실행 중인지 확인 Splunk Enterprise가 실행 중인지 확인하려면 서버 호스트의 셸 프롬프트에서 다음 명령어를 입력하십시오. splunk status 다음과 같이 출력됩니다. splunkd is running (PID: 3162). splunk helpers are running (PIDs: 3164). Splunk Enterprise가 기존 모드로 실행되는 경우 출력에 다음과 같은 줄이 추가로 표시됩니다. splunkweb is running (PID: 3216). 참고: Unix 시스템에서는 Splunk Enterprise를 실행하는 사용자로 로그인해야만 splunk status 명령어를 실행할 수 있습니 다. 다른 사용자는 상태 정보를 올바르게 보고하는 필요한 파일을 읽을 수 없습니다. 또한 ps를 사용하여 Splunk Enterprise 프로세스가 실행 중인지 확인할 수 있습니다. ps aux grep splunk grep -v grep Solaris 사용자는 aux 대신 -ef 인수를 ps에 사용해야 합니다. ps -ef grep splunk grep -v grep Splunk Web에서 Splunk Enterprise 재시작 Splunk Web에서 Splunk를 재시작할 수도 있습니다. 42

43 1. 시스템 > 서버 컨트롤로 이동합니다. 2. Splunk 재시작을 클릭합니다. 이렇게 하면 splunkd 및 (기존 모드에서만) splunkweb 프로세스가 재시작됩니다. 부팅 시 시작하도록 Splunk 설정 Windows에서 Splunk는 기본적으로 컴퓨터를 시작할 때 시작됩니다. 이렇게 하지 않으려면 이 항목의 끝 부분에 나오는 "Windows 부팅 시 시작 안 함"을 참조하십시오. *nix 플랫폼에서는 부팅 시 시작하도록 Splunk를 설정해야 합니다. *nix 플랫폼에서 부팅 시 시작 Splunk는 시스템 부팅 시 Splunk가 시작되도록 시스템 부팅 설정을 업데이트하는 유틸리티를 제공합니다. 이 유틸리티는 적 합한 init 스크립트를 생성하거나 OS에 따라 비슷한 설정 변경을 수행합니다. 루트로 다음 명령을 실행하십시오. $SPLUNK_HOME/bin/splunk enable boot-start Splunk를 루트로 시작하지 않으면 어떤 사용자가 Splunk를 시작하는지 지정하는 -user 매개 변수를 통과할 수 있습니다. 예 를 들어, Splunk를 사용자 bob으로 실행할 경우 다음을 루트로 실행하게 됩니다. $SPLUNK_HOME/bin/splunk enable boot-start -user bob 시스템을 시작할 때 Splunk를 실행하지 않으려면 다음 명령을 실행하십시오. $SPLUNK_HOME/bin/splunk disable boot-start 자세한 내용은 $SPLUNK_HOME/etc/init.d/README에서 확인할 수 있으며, 명령줄에서 help boot-start를 입력하여 도움말을 볼 수도 있습니다. Mac 사용자 참고 사항 Splunk는 자동으로 스크립트 및 설정 파일을 /System/Library/StartupItems/System/Library/StartupItems 디렉터리에 생성합 니다. 이 스크립트는 시스템 시작 시 실행되고, 시스템 종료 시 Splunk를 자동으로 중지합니다. 참고: Mac OS를 사용하는 경우 루트 수준 권한이 있거나 sudo를 사용해야 합니다. sudo를 사용하려면 관리자 권한이 필요 합니다. 예: Mac OS에서 시스템 시작 시 Splunk를 시작하도록 다음과 같이 설정하십시오. CLI만 사용:./splunk enable boot-start sudo를 사용하는 CLI 사용: sudo./splunk enable boot-start Windows에서 부팅 시 시작 안 함 기본적으로 Splunk는 Windows 컴퓨터를 시작할 때 자동으로 시작됩니다. Splunk 프로세스(splunkd 및 splunkweb)를 수동으 로 시작하도록 Windows 서비스 제어판에서 설정할 수 있습니다. 라이선스 설치 Splunk를 처음 다운로드하면 등록하라는 메시지가 나타납니다. 등록하면 60일 동안 임시로 사용할 수 있는 Enterprise 평가판 라이선스가 제공되며, 이 라이선스로 사용할 수 있는 1일 최 대 인덱싱 볼륨은 500MB입니다. 이 라이선스는 다운로드에 포함되어 있습니다. Enterprise 라이선스는 다음 기능을 제공합니다. 다중 사용자 계정 및 액세스 제어 분산 검색 및 데이터 경로 설정 43

44 배포 관리 Splunk 라이선싱에 대한 자세한 내용은 이 매뉴얼의 Splunk 라이선싱 방식에서 확인하십시오. 새 라이선스는 어디에 있습니까? 새 라이선스를 요청하면 Splunk에서 보낸 이메일을 통해 라이선스를 받습니다. splunk.com 내 주문 페이지에서 새 라이선스 에 액세스할 수도 있습니다. Splunk Web을 통해 라이선스를 설치하고 업데이트하려면 설정 > 라이선싱으로 이동한 후 관련 지침을 따르십시오. 기본값 변경 현재 환경에 대한 Splunk 설정을 시작하기 전에 다음 기본값 설정을 자세히 확인하고 변경하려는 항목이 있는지 확인하십시 오. 관리자의 기본 암호 변경 Splunk Enterprise 라이선스의 기본 관리 계정 및 암호는 admin/changeme입니다. 이 기본값은 변경하는 것이 좋습니다. Splunk CLI 또는 Splunk Web을 통해 이 작업을 수행할 수 있습니다. Splunk Web 사용 관리자의 기본 암호를 변경하려면: 1. Splunk Web에 관리자로 로그인합니다. 2. 인터페이스의 오른쪽 상단에서 관리자를 클릭합니다. 3. 화면의 사용자 및 인증 섹션에서 액세스 제어를 클릭합니다. 4. 사용자를 클릭합니다. 5. 관리자 사용자를 클릭합니다. 6. 암호를 업데이트하고 저장을 클릭합니다. Splunk CLI 사용 Splunk CLI 명령은 다음과 같습니다. splunk edit user 중요: 암호를 변경하려면 먼저 기존 암호를 인증해야 합니다. CLI를 통해 또는 -auth 매개 변수를 사용하여 Splunk에 로그인 하십시오. 예를 들어, 이 명령은 관리자 암호 changeme를 foo로 변경합니다. splunk edit user admin -password foo -role admin -auth admin:changeme 참고: *nix 운영 체제의 경우 셸에서 일부 특수 문자가 명령 지시문으로 해석됩니다. 이러한 특수 문자를 이스케이프하려면 각 특수 문자 앞에 \를 넣거나 암호를 작은따옴표(')로 묶어야 합니다. 예: splunk edit user admin -password 'fflanda$' -role admin -auth admin:changeme 또는 splunk edit user admin -password fflanda\$ -role admin -auth admin:changeme Windows에서는 캐럿(^)을 사용하여 예약된 셸 문자를 이스케이프하거나 암호를 큰따옴표(")로 묶으십시오. 예: splunk edit user admin -password "fflanda>" -role admin -auth admin:changeme 또는 splunk edit user admin -password fflanda^> -role admin -auth admin:changeme 참고: 여러 서버의 암호를 모두 동시에 재설정할 수도 있습니다. 관련 절차는 "여러 서버에 보안 암호 배포"를 참조하십시오. 네트워크 포트 변경 44

45 Splunk는 설치 시 다음 두 가지 포트를 설정합니다. HTTP/HTTPS 포트. 이 포트는 Splunk Web용 소켓을 제공합니다. 기본값은 8000입니다. 관리 포트: 이 포트는 splunkd 데몬과 통신하는 데 사용됩니다. Splunk Web은 명령줄 인터페이스 및 다른 서버에서 분 산된 연결과 마찬가지로 이 포트를 통해 splunkd와 통신합니다. 이 포트의 기본값은 8089입니다. 중요: 설치할 때 이러한 포트 값을 기본값과 다르게 설정했을 수도 있습니다. 참고: 포워더에서 데이터를 수신하는 Splunk 인스턴스는 추가 포트인 수신기 포트로 설정되어야 합니다. Splunk 인스턴스는 이 포트를 사용하여 포워더에서 들어오는 데이터를 수신합니다. 이 설정은 설치 과정에서 나오지 않습니다. 기본 수신기 포 트는 9997입니다. 자세한 내용은 데이터 포워딩 매뉴얼의 "수신기 활성화"를 참조하십시오. Splunk Web 사용 설치 설정에서 포트를 변경하려면: 1. Splunk Web에 관리자로 로그인합니다. 2. 인터페이스의 오른쪽 상단에서 관리자를 클릭합니다. 3. 화면의 시스템 섹션에서 시스템 설정 링크를 클릭합니다. 4. 일반 설정을 클릭합니다. 5. 관리 포트 또는 웹 포트 값을 변경하고 저장을 클릭합니다. Splunk CLI 사용 Splunk CLI를 통해 포트 설정을 변경하려면 CLI 명령 set를 사용하십시오. 예를 들어, 이 명령은 Splunk Web 포트를 9000 으로 설정합니다. splunk set web-port 9000 이 명령은 splunkd 포트를 9089로 설정합니다. splunk set splunkd-port 9089 기본 Splunk 서버 이름 변경 Splunk 서버 이름 설정은 Splunk Web 내에서 표시되는 이름과 분산 설정으로 다른 Splunk 서버에 전송된 이름을 모두 제어 합니다. 기본 이름은 Splunk 서버 호스트의 DNS 또는 IP 주소에서 가져옵니다. Splunk Web 사용 Splunk 서버 이름을 변경하려면: 1. Splunk Web에 관리자로 로그인합니다. 2. 인터페이스의 오른쪽 상단에서 관리자를 클릭합니다. 3. 화면의 시스템 섹션에서 시스템 설정 링크를 클릭합니다. 4. 일반 설정을 클릭합니다. 5. Splunk 서버 이름 값을 변경하고 저장을 클릭합니다. Splunk CLI 사용 CLI를 통해 서버 이름을 변경하려면 set servername 명령을 사용하십시오. 예를 들어, 이 명령은 서버 이름을 foo로 설정합니 다. splunk set servername foo 데이터 저장소 위치 변경 데이터 저장소는 Splunk 서버가 인덱스된 모든 데이터를 저장하는 최상위 수준 디렉터리입니다. 참고: 이 디렉터리를 변경할 경우 Splunk 서버가 이전 데이터 저장소 파일을 마이그레이션하지 못합니다. 대신 새로운 위치 에서 재시작됩니다. 데이터를 다른 디렉터리로 마이그레이션하려면 "인덱스 이동"의 지침을 따르십시오. 45

46 Splunk Web 사용 데이터 저장소 위치를 변경하려면: 1. Splunk Web에 관리자로 로그인합니다. 2. 인터페이스의 오른쪽 상단에서 관리자를 클릭합니다. 3. 화면의 시스템 섹션에서 시스템 설정 링크를 클릭합니다. 4. 일반 설정을 클릭합니다. 5. 인덱스 경로에서 경로를 변경하고 저장을 클릭합니다. 6. CLI를 사용하여 Splunk를 재시작합니다. $SPLUNK_HOME/bin/(*nix) 또는 %SPLUNK_HOME%\bin(Windows)으로 이동한 후 다음 명령을 실행합니다. splunk restart 중요: 관리자 내에서 재시작 기능을 사용하지 마십시오. 이렇게 하면 인덱스 디렉터리로 인해 수행되는 작업이 변경되지 않 습니다. CLI를 통해 재시작해야 합니다. Splunk CLI 사용 CLI를 통해 데이터 저장소 디렉터리를 변경하려면 set datastore-dir 명령을 사용하십시오. 예를 들어, 이 명령은 데이터 저 장소 디렉터리를 /var/splunk/로 설정합니다. splunk set datastore-dir /var/splunk/ 사용 가능한 최소 디스크 공간 설정 사용 가능한 최소 디스크 공간 설정은 Splunk가 인덱싱을 중지하기 전 데이터 저장소 위치의 사용 가능한 최소 디스크 공간 을 제어합니다. 사용 가능한 공간이 확보되면 인덱싱이 재시작됩니다. Splunk Web 사용 사용 가능한 최소 디스크 공간을 설정하려면: 1. Splunk Web에 관리자로 로그인합니다. 2. 인터페이스의 오른쪽 상단에서 관리자를 클릭합니다. 3. 화면의 시스템 섹션에서 시스템 설정 링크를 클릭합니다. 4. 일반 설정을 클릭합니다. 5. 사용 가능한 디스크 공간이 부족할 경우 인덱스 중지 값을 변경하고 저장을 클릭합니다. Splunk CLI 사용 CLI를 통해 사용 가능한 최소 공간 값을 변경하려면 set minfreemb 명령을 사용하십시오. 예를 들어, 이 명령은 사용 가능한 최소 공간을 2000MB로 설정합니다. splunk set minfreemb 2000 기타 기본 설정 Splunk Web 관리자의 일반 설정 화면에는 변경할 수 있는 기타 기본 설정이 있습니다. 해당 기본 설정의 옵션 범위를 살펴 보십시오. Splunk를 IP에 바인드 지정된 IP 주소 포트에 Splunk를 강제로 바인드할 수 있습니다. 기본적으로 Splunk는 사용 가능한 모든 IP 주소를 의미하는 IP 주소 에 바인드합니다. Splunk의 바인드 IP 변경은 Splunk 데몬(splunkd)에만 적용되며 다음을 수신합니다. TCP 포트 8089(기본값) 다음에 대해 설정된 포트: 46

47 SplunkTCP 입력 TCP 또는 UDP 입력 Splunk Web 프로세스(splunkweb)를 특정 IP에 바인드하려면 web.conf의 server.socket_host 설정을 사용하십시오. 임시 변경 이 값을 임시로 변경하려면 Splunk를 시작하기 전에 환경 변수 SPLUNK_BINDIP=<ipaddress>를 설정하십시오. 영구 변경 이 값을 현재 작동 환경에서 영구적으로 변경하려면 SPLUNK_BINDIP 속성과 <ipaddress> 값을 포함하도록 $SPLUNK_HOME/etc/splunk-launch.conf를 수정하십시오. 예를 들어 Splunk 포트를 (로컬 루프백에만 해당)에 바인드 하려면 splunk-launch.conf가 다음과 같아야 합니다. Modify the following line to suit the location of your Splunk install. If unset, Splunk will use the parent of the directory this configuration file was found in SPLUNK_HOME=/opt/splunk SPLUNK_BINDIP= 중요: web.conf에서 mgmthostport 속성의 기본값은 :8089입니다. SPLUNK_BINDIP를 과 다른 값으로 변경하려 면 동일한 IP 주소를 사용하도록 mgmthostport도 변경해야 합니다. 예를 들어, splunk-launch.conf에서 이렇게 변경하려면: SPLUNK_BINDIP= web.conf에서도 다음과 같이 변경해야 합니다(관리 포트를 8089로 가정한 경우). mgmthostport= :8089 mgmthostport 속성에 대한 자세한 내용은 web.conf를 참조하십시오. IPv6 고려사항 버전 4.3부터는 대괄호로 묶은 경우 IPv6 주소를 사용할 수 있도록 web.conf mgmthostport 설정이 확장되었습니다. 따라서 (이 매뉴얼의 "IPv6용 Splunk 설정"에서 설명한 server.conf 설정을 통해) splunkd가 IPv6만 수신하도록 설정하려면 이 값을 :8089에서 [::1]:8089로 변경해야 합니다. IPv6용 Splunk 설정 이 항목에서는 Splunk의 IPv6 지원과 IPv6을 위한 설정 방법에 대해 설명합니다. 이 항목의 절차를 수행하기 전에 다음 매뉴 얼을 읽어 보시면 도움이 됩니다. Splunk의 설정 파일 작동에 대해 알아보려면 이 매뉴얼의 "설정 파일에 대하여"를 읽어 보십시오. 데이터 가져오기 매뉴얼의 "TCP 및 UDP 포트에서 데이터 가져오기"를 읽어 보십시오. server.conf 설정 파일에서 사용 가능한 옵션 참조를 보려면 이 매뉴얼의 "server.conf"를 읽어 보십시오. inputs.conf 설정 파일에서 사용 가능한 옵션 참조를 보려면 이 매뉴얼의 "inputs.conf"를 읽어 보십시오. Splunk 버전 4.3부터 IPv6이 지원됩니다. IPv6 네트워크를 통해 Splunk Web에 연결하고 CLI를 사용하며 데이터를 포워딩 할 수 있습니다. IPv6 플랫폼 지원 모든 Splunk 지원 OS 플랫폼(설치 매뉴얼의 "지원되는 OS" 참조)은 다음을 제외하고 IPv6 설정을 사용할 수 있도록 지원됩 니다. HPUX PA-RISC Solaris 8 및 9 AIX IPv6 네트워크를 수신하도록 Splunk 설정 IPv6을 수신하도록 Splunk를 설정할 때 몇 가지 옵션이 있습니다. 다음과 같이 Splunk를 설정할 수 있습니다. IPv6 주소에만 연결하고 DNS의 모든 IPv4 결과는 무시 IPv4 및 IPv6 주소에 모두 연결 IPv6 주소 우선 연결 IPv4 주소 우선 연결 IPv4 주소에만 연결하고 DNS의 모든 IPv6 결과는 무시 47

48 Splunk가 IPv6을 수신하는 방법을 설정하려면 다음을 추가하도록 $SPLUNK_HOME/etc/system/local의 server.conf 복사본을 편집하십시오. listenonipv6=[yes no only] yes 는 splunkd가 IPv6 및 IPv4 둘 다로부터 연결을 수신함을 의미합니다. no 는 splunkd가 IPv4만 수신함을 의미합니다. 이 값은 기본 설정입니다. only 는 Splunk가 IPv6에서 들어오는 연결만 수신함을 의미합니다. connectusingipversion=[4-first 6-first 4-only 6-only auto] 4-first 는 IPv4 주소에 우선 연결을 시도하고, 실패할 경우 IPv6을 시도함을 의미합니다. 6-first 는 4-first와 반대입니다. 이것은 웹 브라우저와 같은 대부분의 IPv6 지원 클라이언트 앱에서 사용하는 정책입 니다. 그러나 IPv6 배포의 초기 단계에서는 그 성능이 떨어질 수 있습니다. 4-only 는 splunkd가 DNS의 모든 IPv6 결과를 무시함을 의미합니다. 6-only 는 splunkd가 DNS의 모든 IPv4 결과를 무시함을 의미합니다. auto 는 splunkd가 listenonipv6의 설정에 기반한 합리적인 정책을 선택함을 의미합니다. 이 값은 기본값입니다. splunkd가 IPv4만 수신할 경우 이것은 4-only를 지정한 것처럼 작동합니다. splunkd가 IPv6만 수신할 경우 이것은 6-only를 지정한 것처럼 작동합니다. splunkd가 둘 다 수신할 경우 이것은 6-first를 지정한 것처럼 작동합니다. 중요: 이 설정은 DNS 룩업에만 영향을 미칩니다. 예를 들어, connectusingipversion = 6-first를 설정하면 명시적 IPv4 주소 (예: "server= :9001")가 포함된 스탠자가 작동합니다. 입력이 몇 개 있지만 전체 배포에서 IPv6을 사용하지 않으려는 경우 IPv6을 통해 수신되는 몇 가지 데이터 원본이 있지만 전체 Splunk 배포에서 IPv6을 사용하지 않으려면 위에서 설명한 listenonipv6 설정을 inputs.conf의 모든 [udp], [tcp], [tcp-ssl], [splunktcp] 또는 [splunktcp-ssl] 스탠자에 추가하십시 오. 이 경우 특정 입력에 대한 server.conf의 동일한 이름 설정이 무시됩니다. IPv6을 통해 데이터 포워딩 Splunk 포워더는 IPv6을 통해 포워딩할 수 있습니다. outputs.conf에서 다음과 같이 지원됩니다. [tcpout] 스탠자의 server 설정에는 표준 [host]:port 형식의 IPv6 주소가 포함될 수 있습니다. [tcpout-server] 스탠자는 표준 [host]:port 형식의 IPv6 주소를 사용할 수 있습니다. [syslog] 스탠자의 server 설정에는 표준 [host]:port 형식의 IPv6 주소가 포함될 수 있습니다. IPv6용 분산 검색 설정 Splunk 분산 검색 배포는 IPv6을 사용할 수 있습니다. distsearch.conf에서 다음과 같이 지원됩니다. servers 설정에는 표준 [host]:port 형식의 IPv6 주소가 포함될 수 있습니다. 그러나 heartbeatmcastaddr가 IPv6 주소를 지원하도록 업데이트되지 않았습니다. 이 설정은 Splunk 4.3에서 더 이상 사용되지 않아 이후 릴리스 제품부터 제거될 예정입니다. IPv6을 통해 Splunk Web에 액세스 네트워크 정책이 웹 브라우저에서 IPv6 연결을 허용하거나 요구할 경우 splunkd와 다르게 작동하도록 splunkweb 서비스를 설정할 수 있습니다. web.conf는 4.3부터 listenonipv6 설정을 지원합니다. 이 설정은 위에서 설명한 server.conf의 설정과 동 일하게 작동하지만, Splunk Web에만 적용됩니다. 대괄호로 묶어서 IPv6 주소를 사용할 수 있도록 기존 web.conf mgmthostport 설정이 확장되었습니다. 따라서 (앞에서 설명한 server.conf 설정을 통해) splunkd가 IPv6만 수신하도록 설정할 경우 이 값을 :8089에서 [::1]:8089로 변경해야 합 니다. Splunk CLI 및 IPv6 Splunk CLI는 IPv6을 통해 splunkd와 통신할 수 있습니다. web.conf에 mgmthostport를 설정했거나 $SPLUNK_URI 환경 변수를 정의했거나 -uri 명령줄 옵션을 사용한 경우 이렇게 작동합니다. -uri 옵션을 사용할 경우에는 IPv6 IP 주소를 대괄호로 묶어 야 하고 전체 주소와 포트는 큰따옴표로 묶으십시오. 예: -uri "[2001:db8::1]:80". IPv6 및 SSO SSO와 함께 IPv6을 사용할 경우 아래 예와 같이 trustedip 속성에 대괄호 표기법을 사용하지 마십시오. 이 규칙은 web.conf 및 server.conf에 모두 적용됩니다. 다음 web.conf 예에서 mgmthostport 속성은 대괄호 표기법을 사용했지만 trustedip 속성은 대괄호 표기법을 사용하지 않았습 니다. [settings] mgmthostport = [::1]:

49 startwebserver = 1 listenonipv6=yes trustedip=2620:70:8000:c205:250:56ff:fe92:1c7,::1,2620:70:8000:c205::129 SSOMode = strict remoteuser = X-Remote-User tools.proxy.on = true SSO에 대한 자세한 내용은 Splunk Enterprise 보안 매뉴얼의 "SSO(Single Sign-On) 설정"을 참조하십시오. 설정 보안 아직 Splunk와 데이터가 안전한지 확인하지 않았다면 지금 확인하는 것이 좋습니다. Splunk를 보호하기 위한 적절한 조치를 취하면 공격을 당할 가능성이 줄어들고 대부분의 취약점으로 인한 위험과 영향이 완화됩니다. 설치 후 수행해야 하는 주요 작업 사용자 및 역할 설정. Splunks 기본 인증을 사용하여 사용자를 설정하거나 LDAP를 사용하여 사용자를 관리할 수 있 습니다. "사용자 인증에 대하여"를 참조하십시오. 인증서 인증(SSL) 설정. Splunk는 보안 인증을 위해 교체해야 하는 기본 인증서와 함께 제공됩니다. 당사는 SSL 암호 화 및 인증을 추가하고 보안 인증을 설정하는 방법에 대한 가이드라인과 추가 지침을 제공합니다. Splunk Enterprise 보안 매뉴얼에서는 Splunk를 안전하게 보호할 수 있는 방법에 대해 자세히 설명합니다. 이 매뉴얼에는 설 정을 강화하기 위한 체크리스트가 포함되어 있습니다. 자세한 내용은 "Splunk Enterprise 보안"을 참조하십시오. Splunk 라이선스 설정 Splunk 라이선싱 방식 Splunk는 관리자가 지정한 원본으로부터 데이터를 가져와서 Splunk에서 분석할 수 있도록 데이터를 처리합니다. 이 프로세 스를 인덱싱이라고 합니다. 정확한 인덱싱 프로세스에 대한 내용은 데이터 가져오기 매뉴얼의 "Splunk의 데이터 작업"을 참 조하십시오. Splunk 라이선스는 역일(라이선스 마스터 시계 기준 자정에서 다음 자정까지의 24시간)당 인덱싱할 수 있는 데이터의 양을 지정합니다. 이렇게 하려면 인덱싱을 수행하는 Splunk 인프라의 모든 호스트에 라이선스가 있어야 합니다. 라이선스가 로컬로 설치되어 있는 독립형 인덱서를 실행하거나 또는 Splunk 인스턴스 중 하나를 라이선스 마스터로 설정하고 라이선스 슬레이브로 설정 된 다른 인덱서에서 가져와 사용할 수 있는 라이선스 풀을 설정할 수 있습니다. 볼륨 인덱싱뿐만 아니라 Splunk Enterprise의 일부 기능을 사용하려면 Enterprise 라이선스가 필요합니다. 다양한 유형의 라이선스에 대한 자세한 내용은 이 매뉴얼의 "Splunk 라이선스 유형"을 참조하십시오. 기존 라이선스 업그레이드에 대한 내용은 설치 매뉴얼의 "새로운 Splunk 라이선서로 마이그레이션"을 참조하십시오. 라이선스 마스터와 라이선스 슬레이브 간의 연결에 대하여 라이선스 마스터 인스턴스가 설정되고 라이선스 슬레이브가 추가된 경우 라이선스 슬레이브는 분 단위로 라이선스 마스터 에게 사용을 알립니다. 라이선스 마스터에 연결할 수 없으면 라이선스 슬레이브가 72시간 타이머를 시작합니다. 라이선스 슬레이브가 72시간 동안 라이선스 마스터에 연결할 수 없는 경우 (인덱싱이 계속되더라도) 라이선스 슬레이브에 대한 검색 은 차단됩니다. 슬레이브가 라이선스 마스터에 다시 연결될 때까지 사용자는 라이선스 슬레이브에 있는 인덱스의 데이터를 검색할 수 없습니다. Splunk 라이선스 수명 주기 다운로드한 Splunk 사본을 처음 설치할 경우 Splunk의 해당 인스턴스는 60일 평가판 Enterprise 라이선스를 사용합니다. 이 라이선스로 60일 동안 Splunk의 모든 Enterprise 기능을 사용할 수 있으며 하루에 최대 500MB까지 데이터를 인덱싱할 수 있습니다. 60일 평가 기간이 끝난 후 Enterprise 라이선스를 구입하여 설치하지 않으면 Splunk Free로 전환할 수 있는 옵션이 표시됩 니다. Splunk Free에는 Splunk Enterprise 기능의 하위 집합이 포함되어 있으며, 독립형 배포 및 단기간 포렌식 조사 용도로 사용할 수 있습니다. Splunk Free는 무기한으로 하루에 최대 500 MB의 데이터를 인덱싱할 수 있습니다. 중요: 인증 또는 예약된 검색/경고는 Splunk Free에 포함되지 않습니다. 즉, Splunk Web 또는 CLI를 통해 Splunk 설치에 액 세스하는 사용자는 자격 증명을 제공할 필요가 없습니다. 또한 예약된 저장 검색/경고는 더 이상 실행할 수 없게 됩니다. 60일 평가 기간이 만료된 후 Splunk의 Enterprise 기능을 계속 사용하려면 Enterprise 라이선스를 구입해야 합니다. 자세히 알아보려면 Splunk 판매 담당자에게 문의하십시오. Enterprise 라이선스를 구입하고 다운로드한 후에는 Splunk 인스턴스에 이 라이선스를 설치하고 Splunk Enterprise 기능에 액세스할 수 있습니다. Enterprise 기능에 대한 내용은 이 매뉴얼의 "Splunk 라이선스 유형"을 참조하십시오. Splunk 라이선스 유형 49

50 각 Splunk 인스턴스에는 라이선스가 필요합니다. Splunk 라이선스는 지정된 Splunk 인스턴스가 인덱싱할 수 있는 데이터의 양을 지정하고, 액세스할 수 있는 기능을 지정합니다. 이 항목에서는 다양한 라이선스 유형과 옵션에 대해 설명합니다. 일반적으로 다음 네 가지 라이선스 유형이 있습니다. Enterprise 라이선스는 인증 및 분산 검색 등의 모든 엔터프라이즈 기능을 제공합니다. Free 라이선스는 인덱싱 볼륨이 제한되고, 인증 기능을 사용할 수 없습니다. 포워더 라이선스는 데이터 포워딩 기능과 인증 기능을 제공하지만, 인덱스 기능은 제공하지 않습니다. Beta 라이선스는 일반적으로 엔터프라이즈 기능을 제공하지만, Splunk 베타 릴리스로 제한됩니다. 또한 이 항목에서는 분산 검색 또는 인덱스 복제를 포함하는 배포의 경우 특별 라이선스 고려 사항에 대해서도 다룹니다. 기존 라이선스 업그레이드에 대한 내용은 설치 매뉴얼의 "새로운 Splunk 라이선서로 마이그레이션"을 참조하십시오. Enterprise 라이선스 Splunk Enterprise는 표준 Splunk 라이선스입니다. 이 라이선스를 통해 인증, 분산 검색, 배포 관리, 경고 예약, 역할 기반 액 세스 제어를 포함한 Splunk의 모든 엔터프라이즈 기능을 사용할 수 있습니다. Enterprise 라이선스는 구입해서 사용할 수 있 으며 모든 인덱싱 볼륨이 될 수 있습니다. 자세한 내용은 Splunk 판매부에 문의하십시오. 다음은 Enterprise 라이선스의 추가 유형으로, 동일한 기능이 모두 포함되어 있습니다. Enterprise 평가판 라이선스 Splunk를 처음 다운로드하면 등록하라는 메시지가 나타납니다. 등록하면 Enterprise 평가판 라이선스를 수신하며 이 라이 선스는 하루에 최대 인덱싱 볼륨 500MB를 제공합니다. Enterprise 평가판 라이선스는 Splunk 사용을 시작한 날로부터 60 일 후에 만료됩니다. Enterprise 평가판 라이선스를 사용하다가 만료되면 Splunk Free 라이선스로 전환해야 합니다. Splunk를 설치했으면 Enterprise 평가판 라이선스가 만료될 때까지 평가판 라이선스로 Splunk를 실행할 것인지, Enterprise 라이선스를 구입할지 또는 Free 라이선스로 전환(포함되어 있음)할지 선택할 수 있습니다. 참고: Enterprise 평가판 라이선스를 "다운로드 평가판"이라고도 부릅니다. Sales 평가판 라이선스 Splunk Sales를 사용할 경우 크기와 기간이 다양한 Enterprise 평가판 라이선스를 요청할 수 있습니다. Enterprise 평가판 라이선스는 Splunk 사용을 시작한 날로부터 60일 후에 만료됩니다. 대규모 배포의 파일럿을 준비하고 있으며 평가판 사용 기간에 사용 기간 또는 인덱싱 볼륨을 늘려야 할 경우 Splunk 판매부로 문의해 주십시오. 담당자가 바로 처리해 드립니다. Free 라이선스 Free 라이선스는 하루 500MB의 인덱싱 볼륨을 무료로 만료 기간 없이 제공합니다. Enterprise 라이선스 버전에서 사용할 수 있는 다음 기능은 Splunk Free에서는 사용할 수 없습니다. 다중 사용자 계정 및 역할 기반 액세스 제어 분산 검색 TCP/HTTP 형식으로 포워딩(다른 Splunk 인스턴스로 데이터를 포워딩할 수 있지만 비 Splunk 인스턴스에는 포워딩 할 수 없음) 배포 관리(클라이언트용으로 포함) 경고/모니터링 기본 인증, LDAP 및 스크립트 기반 인증을 포함한 인증과 사용자 관리 로그인 기능이 없기 때문에 명령줄 또는 브라우저에서 별도의 로그인 없이 Splunk의 모든 기능을 액세스하고 제 어할 수 있습니다. 또한 더 많은 역할을 추가하거나 사용자 계정을 만들 수 없습니다. 검색이 모든 공용 인덱스, 즉 'index=*'에 대해 실행되고 사용자 할당량, 검색별 최대 시간 범위, 검색 필터 같은 제약조건은 지원되지 않습니다. 기능 시스템이 비활성화되어 있지만 Splunk에 액세스하는 모든 사용자에 대한 모든 기능은 활성화되어 있습니 다. 이 매뉴얼에서 Splunk 무료 버전에 대해 알아보기를 참조하십시오. 포워더 라이선스 이 라이선스는 데이터의 무제한 포워딩(인덱스 기능은 제공 안 됨)이 가능하고, 사용자 액세스에 사용자 이름 및 암호를 제공 하므로 인스턴스 보안이 가능합니다. (무료 라이선스는 데이터를 무제한으로 포워딩하기 위해 사용할 수도 있지만 보안 기능 이 없습니다.) 포워더 라이선스는 Splunk에 포함되어 있으므로 별도로 구입할 필요가 없습니다. Splunk는 다양한 포워더 옵션을 제공합니다. 유니버설 포워더는 포워더 라이선스가 자동으로 적용되어 있으므로, 설치 후에 추가 작업이 필요하지 않습니다. 라이트 포워더도 동일한 라이선스를 사용하지만, 포워더 라이선스 그룹으로 변경하여 직접 라이선스를 활성화해야 합 50

51 니다. 헤비 포워더도 포워더 라이선스 그룹으로 직접 변환해야 합니다. 인덱싱 작업을 수행할 경우 Enterprise 라이선스 스 택에 대한 액세스가 필요합니다. Splunk 라이선스 용어에 대한 자세한 내용은 이 매뉴얼의 "그룹, 스택, 풀 및 기타 용 어"를 참조하십시오. Beta 라이선스 Splunk Beta 릴리스는 다른 Splunk 릴리스와 호환되지 않는 다른 라이선스가 필요합니다. 또한 Splunk Beta 릴리스를 평가 할 경우 Free 또는 Enterprise 라이선스로는 실행되지 않습니다. Beta 라이선스는 일반적으로 Enterprise 기능을 제공하지 만 그 범위는 Beta 릴리스로 제한됩니다. Splunk Beta 버전을 평가하는 경우 자체 라이선스가 함께 제공됩니다. 검색 헤드(분산 검색)를 위한 라이선스 검색 헤드는 검색을 다른 Splunk 인덱서로 배포하는 Splunk 인스턴스입니다. 검색 헤드는 일반적으로 데이터를 로컬에서 인 덱싱하지 않지만, 여전히 액세스를 제한하기 위해 라이선스를 사용하고자 합니다. 검색 헤드에는 특수 라이선스 유형인 "검색 헤드 라이선스"가 없습니다. 그러나 검색 헤드를 설정하려면 Enterprise 라이선 스가 필요하며 검색 헤드의 라이선싱은 Splunk 버전에 따라 다릅니다. 4.2 이전 버전의 Splunk는 각 검색 헤드에 대한 별도의 포워더 라이선스를 사용할 것을 권장했습니다. 그 이유는 포워 더 라이선스가 인덱스를 허용하지 않고 검색 헤드 액세스에 대한 인증을 요구하기 때문입니다. 4.2 이후 버전의 Splunk는 각 피어에 별도 라이선스를 할당하는 대신 데이터를 인덱싱할 필요가 없는 경우에도 Enterprise 라이선스 풀에 검색 헤드를 추가하는 것을 권장합니다. "그룹, 스택, 풀 및 기타 용어" 및 "라이선스 풀 만들 기 또는 편집"을 참조하십시오. 참고: 기존 검색 헤드에 4.2 이전 버전의 포워더 라이선스가 설치된 경우 업그레이드 후에는 이 포워더 라이선스가 인식되지 않습니다. 클러스터 구성원을 위한 라이선스(인덱스 복제용) Splunk 배포와 마찬가지로 인덱서에서 처리하는 데이터 볼륨에 따라 라이선싱 요구 사항이 결정됩니다. 추가 라이선스 볼륨 을 구입하려면 Splunk 판매부 담당자에게 문의하십시오. 인덱스 복제와 관련된 일부 라이선싱 문제는 다음과 같습니다. 마스터, 피어 및 검색 헤드를 포함한 모든 클러스터 구성원은 데이터를 인덱싱할 필요가 없는 경우에도 Enterprise 라 이선스 풀이 필요합니다. 클러스터 구성원은 동일한 라이선싱 설정을 공유해야 합니다. 수신 데이터만 라이선스로 카운트되고, 복제된 데이터는 카운트되지 않습니다. Free 라이선스에서는 인덱스 복제를 사용할 수 없습니다. 인덱서 및 클러스터 관리 매뉴얼에서 시스템 요구 사항과 기타 배포 고려사항에 대해 자세히 알아보십시오. 그룹, 스택, 풀 및 기타 용어 Splunk의 라이선싱 기능은 4.2 버전부터 많이 변경되었습니다. 호환되는 라이선스를 사용 가능한 라이선스 볼륨 스택에 집 계할 수 있고, 인덱서 풀을 정의하여 지정된 스택의 라이선스 볼륨을 사용할 수 있습니다. Splunk Free 사용자: 이 기능은 Enterprise 라이선스에만 해당됩니다. 독립형 인스턴스 Splunk Free를 사용하는 경우에는 그룹, 풀 및 스택이 필요하지 않습니다. 풀 4.2 버전부터는 지정된 라이선스 스택에서 라이선스 볼륨의 풀을 정의할 수 있으며, 다른 인덱싱 Splunk 인스턴스를 볼륨 사 51

52 용 및 추적을 위한 풀의 구성원으로 지정할 수 있습니다. 라이선스 풀은 단일 라이선스 마스터로 구성되며, Splunk의 0개 이상의 라이선스 슬레이브 인스턴스가 집합 라이선스 또는 라이선스 스택의 라이선싱 볼륨을 사용하도록 설정됩니다. 스택 4.2 버전부터는 특정 유형의 Splunk 라이선스를 함께 집계하거나, 스택으로 쌓아둘 수 있습니다. 따라서 사용 가능한 라이선 스 볼륨은 개별 라이선스 볼륨의 합계가 됩니다. 즉, 시간이 지남에 따라 필요한 경우 라이선스를 바꾸지 않고도 인덱스 볼륨 용량을 늘릴 수 있습니다. 대신 추가 용량을 구입 하여 해당 스택에 추가해야 합니다. 그룹 Enterprise 라이선스와 Sales 평가판 라이선스는 같이 서로 스택할 수 있습니다. 표준 Splunk 다운로드 패키지가 함께 포함되어 있는 Enterprise *평가판* 라이선스는 한 스택에 포함될 수 없습니다. Enterprise 평가판 라이선스는 독립형으로 사용할 수 있으며 자체 그룹입니다. Enterprise 또는 Sales 평가판 라이선 스를 설치하기 전까지 스택을 만들거나 사용할 다른 인덱서의 풀을 정의할 수 없습니다. Splunk Free 라이선스는 Splunk Free 라이선스를 포함하여 다른 라이선스와 함께 스택할 수 없습니다. 포워더 라이선스는 포워더 라이선스를 포함하여 다른 라이선스와 함께 스택할 수 없습니다. 라이선스 그룹에는 하나 이상의 스택이 포함됩니다. 스택은 하나의 그룹에만 속하는 구성원이므로 Splunk를 설치할 때 하나 의 그룹만 "활성" 상태가 될 수 있습니다. 특히 이것은 지정된 라이선스 마스터가 한 번에 하나의 그룹 유형에 속하는 라이선 스 풀만 관리할 수 있음을 의미합니다. 그룹은 다음과 같습니다. Enterprise/Sales 평가판 그룹 - 이 그룹은 구입한 Enterprise 라이선스와 Sales 평가판 라이선스(이것은 만료 기한이 설정된 Enterprise 라이선스이며, 다운로드한 Enterprise 평가판과 동일한 라이선스가 아님)를 스택할 수 있습니다. Enterprise 평가판 그룹 - 이 그룹은 새 Splunk 인스턴스를 처음 설치할 경우 기본 그룹입니다. 여러 Enterprise 평가판 라이선스를 하나의 스택으로 결합하여 풀을 만들 수 없습니다. 다른 그룹으로 전환할 경우 Enterprise 평가판 그룹으 로 다시 전환할 수 없게 됩니다. Free 그룹 - 이 그룹은 Splunk Free 설치를 수용하는 데 필요합니다. Enterprise 평가판 라이선스가 60일 후에 만료될 경우 해당 Splunk 인스턴스는 Free 그룹으로 전환됩니다. 여러 Splunk Free 라이선스를 하나의 스택으로 결합하여 풀 을 만들 수 없습니다. 포워더 그룹 - 이 그룹은 Splunk를 유니버설 포워더 또는 라이트 포워더로 설정하는 데 필요합니다. 이러한 유형의 포 워더는 인덱스를 수행하지 않으므로 관리자의 라이선싱 페이지를 통해 관리되지 않고 라이선스 그룹에 속하게 됩니다. Splunk 인스턴스의 라이선스 그룹을 포워더 그룹으로 변경할 경우 Splunk 인스턴스는 포워더로 설정되고 데이터를 인 덱싱하지 않는다고 가정합니다. 자세한 내용은 포워더 및 "포워더 라이선스"를 참조하십시오. 라이선스 슬레이브 라이선스 슬레이브는 하나 이상의 라이선스 풀의 구성원입니다. 라이선스 슬레이브의 라이선스 볼륨 액세스는 라이선스 마 스터에 의해 제어됩니다. 라이선스 마스터 라이선스 마스터는 하나 이상의 라이선스 슬레이브를 제어합니다. 라이선스 마스터에서 풀을 정의하고 라이선싱 용량을 추 가하며 라이선스 슬레이브를 관리할 수 있습니다. 라이선스 설치 이 항목에서는 새 라이선스 설치에 대해 설명합니다. Splunk 라이선스 마스터에 여러 라이선스를 설치할 수 있습니다. 계속 하기 전에 다음 항목을 참조하십시오. Splunk 라이선싱에 대한 기본적인 내용은 이 매뉴얼의 "Splunk 라이선싱 방식"을 참조하십시오. Splunk 라이선스 용어에 대한 자세한 내용은 이 매뉴얼의 "그룹, 스택, 풀 및 기타 용어"를 참조하십시오. 기존 라이선스 업그레이드에 대한 내용은 설치 매뉴얼의 "새로운 Splunk 라이선서로 마이그레이션"을 참조하십시오. 새 라이선스 추가 새 라이선스를 추가하려면: 1. 설정 > 라이선싱으로 이동합니다. 2. 라이선스 추가를 클릭합니다. 52

53 3. 파일 선택을 클릭하고 라이선스 파일을 찾아서 선택하거나 라이선스 XML을 직접 복사하여 붙여넣습니다...를 클릭하여 라이선스 파일을 제공된 필드에 붙여넣습니다. 4. 설치를 클릭합니다. (Enterprise 라이선스를 처음 설치하는 경우 Splunk를 재시작해야 합니다.) 라이선스가 설치됩니다. 라이선스 마스터 설정 이 항목에서는 Splunk 인스턴스를 라이선스 마스터로 설정하는 것에 대해 설명합니다. 계속하기 전에 다음 항목을 참조하십 시오. Splunk 라이선싱에 대한 기본적인 내용은 이 매뉴얼의 "Splunk 라이선싱 방식"을 참조하십시오. Splunk 라이선스 용어에 대한 자세한 내용은 이 매뉴얼의 "그룹, 스택, 풀 및 기타 용어"를 참조하십시오. 라이선스 마스터 종류 다음과 같은 두 가지 기본 스타일의 라이선스 마스터가 있습니다. 독립형 라이선스 마스터 단일 Splunk 인덱서가 있는 경우 이 인덱서의 라이선스를 관리하려면 이 Splunk 인덱서를 라이선스 마스터로 실행하고 이 Splunk 인덱서에 Enterprise 라이선스를 하나 이상 설치하십시오. 그러면 단일 Splunk 인덱서가 라 이선스 슬레이브로 자체 관리합니다. Splunk Enterprise를 처음 다운로드하고 설치하면 500MB 60일 Enterprise 평가판 라이선스가 포함되어 있습 니다. 이 인스턴스는 독립형 라이선스 마스터로 자동 설정되며 이 유형의 라이선스에 대해서는 풀을 만들거나 라 이선스 슬레이브를 정의할 수 없습니다. 하나 이상의 스택 또는 풀을 만들고 여러 인덱서를 할당하려면 Enterprise 라이선스를 구입하여 설치해야 합니다. 라이선스를 설치하려면 이 매뉴얼의 "라이선스 설치" 설명을 참조하십시오. 중앙 라이선스 마스터 둘 이상의 인덱서가 있으며 구입한 라이선스 용량에 대한 액세스를 중앙 위치에서 관리하려면 중앙 라이선스 마 스터를 설정하고 인덱서를 라이선스 슬레이브로 마스터에 추가해야 합니다. 라이선스 마스터가 인덱서인 경우에도 자체적으로 라이선스 마스터가 되지만, 검색 헤드가 있는 경우에는 검색 헤드를 라이선스 마스터로 지정하는 것이 좋습니다. 검색 헤드가 여러 개인 대규모 환경에서는 다음 두 가지 이유에서 라이선스 마스터가 아닌 일부 또는 전체 검색 헤드가 라이선스 마스터에 검색 분산을 수행하도록 할 수 있습니다. 라이선스 로그에 대해 검색을 실행할 수 있습니다. 시간 기반 라이선스를 가진 상태에서 5일 안에 만료되는 경우와 같은 드문 조건이 검색 헤드에서 발생할 경우, 검색이 실행될 때 검색 결과에 첨부되는 정보 메시지의 일부로 이 조건이 해당 검색 헤드에 표시됩니 다. 중앙 라이선스 마스터 설정 기본적으로 Splunk의 독립형 인스턴스는 자체 라이선스 마스터입니다. 중앙 라이선스 마스터를 설정하려면 하나 이상의 Enterprise 라이선스를 설치하십시오. Enterprise 라이선스를 설치했으면 하나 이상의 스택 및 풀을 생성하여 설치된 라이선스에 액세스할 수 있으며, 라이선스 마 스터에서 이를 관리할 수 있습니다. 라이선스 슬레이브 설정 이 항목에서는 Splunk 인덱서를 라이선스 슬레이브로 설정하는 방법에 대해 설명합니다. 계속하기 전에 다음 항목을 참조하 십시오. Splunk 라이선싱에 대한 기본적인 내용은 이 매뉴얼의 "Splunk 라이선싱 방식"을 참조하십시오. Splunk 라이선스 용어에 대한 자세한 내용은 이 매뉴얼의 "그룹, 스택, 풀 및 기타 용어"를 참조하십시오. 라이선스 마스터를 설정하는 방법은 이 매뉴얼의 "라이선스 마스터 설정"을 참조하십시오. 명령줄에서 해당 작업을 수행하는 데 도움이 필요하면 이 매뉴얼의 "CLI를 통해 라이선스 관리"를 참조하십시오. 1. 라이선스 슬레이브로 설정할 인덱서에서 Splunk Web에 로그인한 후 설정 > 라이선싱으로 이동합니다. 2. 슬레이브로 변경을 클릭합니다. 53

54 3. 이 Splunk 인스턴스 <이 인덱서>을(를) 마스터 라이선스 서버로 지정 라디오 단추를 선택 취소하고 다른 Splunk 인스턴 스를 마스터 라이선스 서버로 지정을 선택합니다. 4. 이 라이선스 슬레이브가 보고할 라이선스 마스터를 지정합니다. IP 주소 또는 호스트 이름과 Splunk 관리 포트를 입력해 야 합니다. 이 관리 포트는 기본적으로 8089입니다. 참고: IP 주소는 IPv4 또는 IPv6 형식으로 지정할 수 있습니다. IPv6 지원에 대한 자세한 내용은 이 매뉴얼의 "IPv6용 Splunk 설정"을 참조하십시오. 5. 저장을 클릭합니다. 이 인스턴스에 Enterprise 라이선스를 아직 설치하지 않은 경우 Splunk를 재시작해야 합니다. 이제 이 인덱서가 라이선스 슬레이브로 설정됩니다. 다시 전환하려면 설정 > 라이선싱으로 이동하고 로컬 마스터로 전환을 클릭합니다. 이 인스턴스에 Enterprise 라이선스를 아 직 설치하지 않은 경우 이 변경 사항을 적용하려면 Splunk를 재시작해야 합니다. 라이선스 풀 만들기 또는 편집 이 항목에서는 설치된 하나 이상의 라이선스에서 라이선스 풀 만들기와 기존 라이선스 풀을 편집하는 방법에 대해 설명합니 다. 계속하기 전에 다음 항목을 참조하십시오. Splunk 라이선싱에 대한 기본적인 내용은 이 매뉴얼의 "Splunk 라이선싱 방식"을 참조하십시오. Splunk 라이선스 용어에 대한 자세한 내용은 이 매뉴얼의 "그룹, 스택, 풀 및 기타 용어"를 참조하십시오. 라이선스 설치에 대한 자세한 내용은 "라이선스 설치"를 참조하십시오. 명령줄에서 해당 작업을 수행하는 데 도움이 필요하면 이 매뉴얼의 "CLI를 통해 라이선스 관리"를 참조하십시오. Splunk를 처음 다운로드하고 설치하면 500MB의 60일 Enterprise 평가판 라이선스가 포함되어 있습니다. Splunk의 이 인 스턴스는 독립형 라이선스 마스터로 자동 설정되며 이 유형의 라이선스에 대해서는 풀을 만들거나 라이선스 슬레이브를 정 의할 수 없습니다. 하나 이상의 스택 또는 풀을 만들고 여러 인덱서를 할당하려면 Enterprise 라이선스를 구입하여 설치해야 합니다. 설정 > 라이선싱의 다음 예제에서는 100MB의 Enterprise 라이선스가 새로운 Splunk 설치에 설치되었습니다. 54

55 새로운 Splunk 서버에 Enterprise 라이선스를 설치할 경우, Splunk는 Enterprise 라이선스 스택(또는 Splunk Enterprise Stack)을 자동으로 만들고 해당 기본 라이선스 풀(auto_generated_pool_enterprise)을 정의합니다. 이 기본 풀에 대한 기본 설정은 이 라이선스 마스터에 연결된 모든 라이선스 슬레이브를 풀에 추가합니다. 풀을 편집하여 이 설정을 변경하거나 풀에 인덱서를 더 많이 추가하거나 이 스택에서 새로운 라이선스 풀을 만들 수 있습니다. 기존 라이선스 풀을 편집하려면 1. 편집할 라이선스 풀 옆의 편집을 클릭합니다. 라이선스 풀 편집 페이지가 나타납니다. 2. 할당을 변경하거나 인덱서가 이 풀에 액세스하는 방식을 변경할 수 있습니다. 풀 이름은 변경할 수 없지만 설명은 변경할 수 있습니다. 3. 제출을 클릭합니다. 새 라이선스 풀을 만드는 방법 중요: 기본 Enterprise 스택에서 새 라이선스 풀을 만들려면 먼저 auto_generated_pool_enterprise 풀을 편집하고 풀 할당을 줄이거나 풀 전체를 삭제하여 사용 가능한 인덱스 볼륨을 확보하십시오. 풀 이름 옆에 있는 삭제를 클릭하여 해당 풀을 삭제 하십시오. 1. 페이지 하단에 있는 를 클릭합니다. 새 라이선스 풀 만들기 페이지가 나타납니다. 2. 풀의 이름을 지정하고 설명(선택 사항)을 입력합니다. 3. 이 풀의 할당을 설정합니다. 이 할당은 전체 스택 라이선싱 볼륨 중에서 이 풀에 속하는 인덱서가 사용할 수 있는 볼륨을 지정합니다. 이 할당은 특정 값으로 지정될 수 있고, 다른 풀에 할당되지 않은 경우에는 해당 스택에서 사용 가능한 전체 인덱 스 볼륨이 이 값이 될 수 있습니다. 4. 인덱서가 이 풀에 액세스하는 방식을 지정합니다. 다음 옵션이 있습니다. 라이선스 슬레이브로 설정된 환경의 인덱서는 이 라이선스 풀에 연결하여 이 풀 내에서 라이선스 할당을 사용할 수 있 습니다. 지정한 인덱서만 이 풀에 연결할 수 있으며 이 풀 내에서 라이선스 할당을 사용할 수 있습니다. 55

56 지정한 인덱서만 이 풀에 연결할 수 있으며 이 풀 내에서 라이선스 할당을 사용할 수 있습니다. 5. 특정 인덱서가 풀을 이용할 수 있도록 허용하려면 사용 가능한 인덱서 리스트에서 인덱서 이름 옆에 있는 더하기 기호를 클릭하여 해당 인덱서를 연결된 인덱서 리스트로 옮깁니다. 라이선스 풀에 인덱서 추가 이 항목에서는 기존 라이선스 풀에 인덱서를 추가하는 방법에 대해 설명합니다. 계속하기 전에 다음 항목을 참조하십시오. Splunk 라이선싱에 대한 기본적인 내용은 이 매뉴얼의 "Splunk 라이선싱 방식"을 참조하십시오. Splunk 라이선스 용어에 대한 자세한 내용은 이 매뉴얼의 "그룹, 스택, 풀 및 기타 용어"를 참조하십시오. 인덱서가 라이선스 풀에 액세스하는 방식 라이선스 풀의 스택에 대한 액세스는 해당 풀의 라이선스 마스터에 의해 제어됩니다. 특정 인덱서에게만 액세스를 허용하도 록 풀을 설정하거나, 라이선스 마스터의 URI와 관리 포트를 지정하여, 이와 연결된 인덱서에 대한 액세스는 모두 허용하도록 설정할 수 있습니다. 특정 인덱서 추가 지정된 라이선스 풀의 스택에 대한 특정 인덱서의 액세스를 허용하려면 다음 기본적인 두 단계를 수행하십시오. 1. 인덱서를 라이선스 슬레이브로 설정하고 인덱서에 라이선스 마스터의 URI와 관리 포트를 지정합니다. 이렇게 하려면 이 매뉴얼의 "라이선스 슬레이브 설정" 설명을 참조하십시오. 2. 인덱서에서 액세스를 허용하도록 라이선스 관리자에서 풀을 설정합니다. 이 작업을 수행하려면 "라이선스 풀 만들기 또는 편집" 지침에 따라 라이선스 풀을 편집하고 특정 인덱서에 대한 액세스만 허용하도록 라디오 단추 옵션을 선택한 후 "사용 가 능한 인덱서" 리스트에서 인덱서 이름 옆의 더하기 기호를 클릭하여 "연결된 인덱서" 리스트로 이동시키십시오. 연결된 모든 인덱서 추가 다음 단계에 따라 이 라이선스 마스터에 연결된 모든 인덱서에 라이선스 풀 스택에 대한 액세스를 제공하십시오. 1. 인덱서를 라이선스 슬레이브로 설정하고 인덱서에 라이선스 마스터의 URI와 관리 포트를 지정합니다. 이렇게 하려면 이 매뉴얼의 "라이선스 슬레이브 설정" 설명을 참조하십시오. 2. 인덱서에서 액세스를 허용하도록 라이선스 마스터에서 풀을 설정합니다. 이 작업을 수행하려면 "라이선스 풀 만들기 또는 편집" 설명에 따라 라이선스 풀을 편집하고 연결하는 임의 인덱서에 대한 액세스를 허용하는 라디오 단추 옵션을 선택하십시 오. CLI를 통해 라이선스 관리 이 항목에서는 Splunk CLI를 사용하여 Splunk 라이선스를 모니터링하고 관리하는 방법에 대해 설명합니다. 계속하기 전에 다음 항목을 검토하십시오. Splunk 라이선싱에 대한 기본적인 내용은 이 매뉴얼의 "Splunk 라이선싱 방식"을 참조하십시오. Splunk 라이선스 용어에 대한 자세한 내용은 이 매뉴얼의 "그룹, 스택, 풀 및 기타 용어"를 참조하십시오. 이 항목에서는 Splunk의 라이선서 관련 개체와 상호작용하는 데 사용할 수 있는 CLI 명령에 대해서만 설명합니다. 해당 명령 중 일부에는 각 개체에 대해 지정할 수 있는 필수/선택적 인수도 있습니다. 전체 구문과 사용 예제를 보려면 Splunk CLI 도움 말을 참조하십시오. Splunk 명령줄 인터페이스 사용에 대한 기본적인 정보는 이 매뉴얼의 "CLI에 대하여"를 참조하십시오. Splunk의 REST API를 통한 라이선스 관리에 대한 내용은 REST API 조회 매뉴얼의 "라이선스"를 참조하십시오. CLI 라이선서 명령 및 개체 Splunk CLI를 사용하여 라이선스 및 라이선서 관련 개체를 추가, 편집, 나열 및 제거할 수 있습니다. 사용 가능한 명령은 다음 과 같습니다. 명령어 개체 설명 add edit list licenses, licenser-pools licenser-localslave, licenser-pools licenser-groups, licenser-localslave, licensermessages, licenser-pools, licenser-slaves, licenser-stacks, licenses 라이선스 또는 라이선스 풀을 라이선스 스택에 추가합니다. 이 명령은 Enterprise 라이선스가 있는 경우에만 사용할 수 있습 니다. 라이선스 스택의 로컬 licenser-slave 노드 또는 라이선스 풀의 속성을 편집합니다. 이 명령은 Enterprise 라이선스가 있는 경 우에만 사용할 수 있습니다. 지정된 라이선서 관련 개체에 따라 해당 개체 속성 또는 개체 구성원을 나열합니다. remove licenser-pools, licenses 라이선스 스택에서 라이선스 또는 라이선스 풀을 제거합니다. 56

57 라이선스 관련 개체는 다음과 같습니다. 개체 licenser-groups licenserlocalslave licensermessages licenser-pools licenser-slaves licenser-stacks licenses 전환할 수 있는 다른 라이선스 그룹입니다. 로컬 인덱서의 설정입니다. 라이선스 상태에 대한 경고입니다. 설명 풀 또는 가상 라이선스입니다. 스택은 각 풀의 할당량을 공유하는 여러 슬레이브와 함께 다양한 풀로 나 눌 수 있습니다. 마스터에 연결된 모든 슬레이브입니다. 이 개체는 라이선스 스택을 나타냅니다. 스택에는 동일한 유형의 라이선스가 포함되며 누적됩니다. 이 Splunk 인스턴스의 모든 라이선스입니다. 공통 라이선서 관련 작업 다음은 공통 라이선서 관련 작업의 예제입니다. 라이선스 관리 라이선스 스택에 새 라이선스를 추가하려면 라이선스 파일에 경로를 지정하십시오../splunk add licenses /opt/splunk/etc/licenses/enterprise/enterprise.lic 라이선스 스택의 모든 라이선스를 나열하려면 다음 작업을 수행하십시오../splunk list licenses 리스트에는 각 라이선스의 속성이 표시됩니다. 예를 들어, 사용할 수 있는 기능(features), 속해 있는 라이선스 그룹 및 스택 (group_id, stack_id), 허용되는 인덱스 할당량(quota), 각 라이선스에 제공되는 고유한 라이선스 키(license_hash) 등이 있 습니다. 라이선스가 만료되면 라이선스 스택에서 해당 라이선스를 제거할 수 있습니다. 라이선스 스택에서 라이선스를 제거하려면 라이선스 해시를 지정하십시오../splunk remove licenses BM+S8VetLnQEb1F+5Gwx9rR4M4Y91AkIE=781882C56833F36D 라이선스 풀 관리 라이선스 스택에 있는 하나 이상의 라이선스에서 라이선스 풀을 만들 수 있습니다(Enterprise 라이선스가 있는 경우). 기본 적으로 라이선스 스택은 여러 라이선서 풀로 분할됩니다. 각 풀은 풀 할당량을 공유하는 둘 이상의 라이선스 슬레이브를 가 집니다. 모든 라이선스 스택의 모든 라이선스 풀을 보려면:./splunk list licenser-pools 라이선스 풀을 스택에 추가하려면, 풀 이름을 지정하고 풀에 추가할 스택과 풀에 할당할 인덱스 볼륨을 지정해야 합니다../splunk add licenser-pools pool01 -quota 10mb -slaves guid1,guid2 -stack_id enterprise 또한 풀에 대한 설명과 풀의 구성원에 속하는 슬레이브에 대한 설명을 지정할 수 있습니다(선택 사항). 라이선스 풀의 설명, 인덱싱 할당량 및 슬레이브를 다음과 같이 편집할 수 있습니다../splunk edit licenser-pools pool01 -description "Test" -quota 15mb -slaves guid3,guid4 -append_slaves true 이는 기본적으로 풀에 대한 설명("Test")을 추가하고, 할당량을 10mb에서 15mb로 변경하고, (guid1 및 guid2를 덮어쓰거나 바꾸는 대신) 슬레이브 guid3 및 guid4를 풀에 추가합니다. 스택에서 라이선스 풀을 제거하려면 다음과 같이 이름을 지정합니다../splunk remove pool01 57

58 라이선스 슬레이브 관리 라이선스 슬레이브는 하나 이상의 라이선스 풀의 구성원입니다. 라이선스 볼륨에 대한 라이선스 슬레이브 액세스는 라이선 스 마스터에 의해 제어됩니다. 라이선스 마스터에 연결된 모든 라이선스 슬레이브를 나열하려면:./splunk list licenser-slaves 로컬 라이선스 슬레이브의 모든 속성을 나열하려면:./splunk list licenser-localslave 라이선스 슬레이브를 추가하고 해당 로컬 라이선스 슬레이브 노드의 속성을 편집하려면(splunkd 라이선스 마스터 인스턴스 의 URI 지정 또는 '자신'):./splunk edit licenser-localslave -master_uri ' 라이선스 상태 모니터링 list 명령어를 사용하여 라이선스 상태에 대한 메시지(경고)를 볼 수 있습니다../splunk list licenser-messages Splunk 라이선스 관리 라이선스 관리 이 항목에서는 Splunk 라이선스 관리에 대해 설명합니다. 계속하기 전에 다음 항목을 참조하십시오. Splunk 라이선싱에 대한 기본적인 내용은 이 매뉴얼의 "Splunk 라이선싱 방식"을 참조하십시오. Splunk 라이선스 용어에 대한 자세한 내용은 이 매뉴얼의 "그룹, 스택, 풀 및 기타 용어"를 참조하십시오. 명령줄에서 해당 작업을 수행하는 데 도움이 필요하면 이 매뉴얼의 "CLI를 통해 라이선스 관리"를 참조하십시오. 기존 라이선스 업그레이드에 대한 내용은 설치 매뉴얼의 "새로운 Splunk 라이선서로 마이그레이션"을 참조하십시오. 라이선스 삭제 라이선스가 만료되면 해당 라이선스를 삭제할 수 있습니다. 하나 이상의 라이선스를 삭제하려면 다음 작업을 수행하십시오. 1. 라이선스 마스터에서 시스템 > 라이선싱으로 이동합니다. 2. 삭제할 라이선스 옆의 삭제를 클릭합니다. 3. 삭제를 다시 클릭하여 확인합니다. 참고: 라이선스 마스터에서 라이선스 리스트 중 마지막 라이선스는 삭제할 수 없습니다. 라이선스 사용량 보기 라이선스 사용량 보고서 뷰를 사용하여 배포 전체의 라이선스 사용량을 모니터링할 수 있습니다. 시스템 > 라이선싱으로 이 동한 후 사용량 보고서를 클릭하여 뷰에 액세스하십시오. 다음 장에서 라이선스 사용량 보고서 뷰에 대해 자세히 알아보십시 오. 라이선스 위반에 대하여 이 항목에서는 라이선스 위반이 어떤 것이며, 어떤 경우에 발생하고 어떻게 해결하는지 설명합니다. 계속하기 전에 다음 항 목을 참조하십시오. Splunk 라이선싱에 대한 기본적인 내용은 이 매뉴얼의 "Splunk 라이선싱 방식"을 참조하십시오. Splunk 라이선스 용어에 대한 자세한 내용은 이 매뉴얼의 "그룹, 스택, 풀 및 기타 용어"를 참조하십시오. 58

59 라이선스 위반 및 경고의 정의 경고 및 위반은 라이선스가 허용하는 최대 인덱스 볼륨을 초과할 때 발생합니다. 역일(자정에서 다음 자정까지의 24시간)의 라이선스 일별 볼륨을 초과할 경우 위반 경고가 발생합니다. 이 메시지는 14일간 나타납니다. 30일 동안 Enterprise 라이선스에서 5개 이상의 경고가 계속 발생하거나 Free 라이선스에서 3개의 경고가 계 속 발생할 경우 라이선스 위반에 해당되며, 위반에 해당되는 풀을 검색할 수 없게 됩니다. 모든 풀의 총 라이선스 사용량이 라 이선스 마스터의 총 라이선스 할당량을 초과하지 않는 한, 나머지 풀은 계속 검색할 수 있고 영향을 받지 않습니다. 이전 30일 동안 경고가 5개보다 적거나(Enterprise), 3개보다 적을 때(Free) 또는 임시 Reset 라이선스(Enterprise만 해당 됨)를 적용할 경우에는 검색 기능을 다시 사용할 수 있습니다. Reset 라이선스를 받으려면 판매 담당자에게 문의하십시오. 적용 방법에 대한 설명은 설치 매뉴얼을 참조하십시오. 참고: 라이선스 위반이 발생하더라도 요약 인덱싱 볼륨은 라이선스에 카운트되지 않습니다. 요약 인덱싱은 내부가 아닌 다른 검색 동작을 중지합니다. 위반 경고가 발생할 경우 라이선스 마스터가 자정까지 이 경고를 해결하면 30일 기간 내에 총 경고 수로 카운트되지 않습니 다. 라이선스 위반 기간 중에는 다음에 유의하십시오. Splunk는 데이터 인덱싱을 중지하지 않습니다. 라이선스를 초과할 경우에만 검색이 차단됩니다. _internal 인덱스는 검색할 수 없습니다. 즉, 인덱스 상태 대시보드에는 계속 액세스할 수 있으며 _internal에 대한 검 색을 통해 라이선스 문제를 진단할 수도 있습니다. 라이선스 경고 표시 풀에 있는 인덱서가 해당 풀에 할당된 라이선스 볼륨을 초과할 경우 Splunk Web 상단에 노란색 경고 배너가 표시됩니다. 배너에 있는 링크를 클릭하면 설정 > 라이선싱이 표시되고 이 페이지의 경고 섹션 아래에 경고가 나타납니다. 경고를 클릭하 면 자세한 정보가 나타납니다. 위반이 발생하면 라이선스 슬레이브에도 비슷한 배너가 표시됩니다. 다음은 라이선싱 경고가 생성되는 몇 가지 조건입니다. 슬레이브가 고아가 되면 경고(자정 전까지는 수정 가능한 일시적 오류)가 발생합니다. 풀이 용량을 초과하면 경고(자정 전까지는 수정 가능한 일시적 오류)가 발생합니다. 스택이 최대 용량을 초과하면 경고(자정 전까지는 수정 가능한 일시적 오류)가 발생합니다. 하나 이상의 슬레이브에 경고가 발생하면 이 경고가 마지막 30일 동안 계속 유효할 경우 경고가 계속 나타납니다. 라이선스 마스터와 라이선스 슬레이브 간의 연결에 대하여 라이선스 마스터 인스턴스를 설정하고 라이선스 슬레이브를 해당 인스턴스에 추가하면 라이선스 슬레이브의 사용량이 분 단위로 라이선스 마스터에 전송됩니다. 라이선스 마스터가 다운되었거나 마스터에 연결할 수 없으면 라이선스 슬레이브가 72시간 타이머를 시작합니다. 라이선스 슬레이브가 72시간 동안 라이선스 마스터에 연결할 수 없는 경우 (인덱싱이 계속되 더라도) 라이선스 슬레이브에 대한 검색은 차단됩니다. 슬레이브가 라이선스 마스터에 다시 연결될 때까지 사용자는 라이선 스 슬레이브에 있는 인덱스의 데이터를 검색할 수 없습니다. 라이선스 슬레이브가 라이선스 마스터에 도달하지 못했는지 알아보려면 splunkd.log에서 failed to transfer rows가 포함된 이벤트를 검색하거나 _internal 인덱스에서 검색하십시오. 라이선스 위반을 방지하는 방법 라이선스 위반을 방지하려면 라이선스 사용량을 모니터링하여 충분한 라이선스 볼륨을 항상 유지해야 합니다. 라이선스 볼 륨이 충분하지 않을 경우 라이선스를 늘리거나 인덱싱 볼륨을 줄여야 합니다. 배포의 인덱스 볼륨에 대한 세부 정보를 보려면 새로운 라이선스 사용량 보고서를 사용하십시오. 다음 장에서 라이선스 사용 량 보고서 뷰에 대해 읽어보십시오. 라이선스 경고 해결 라이선스 경고를 자정 이전에 해결하라는 메시지가 표시될 경우 당일에 할당된 라이선스 용량을 이미 초과한 상태일 수 있습 니다. 이를 "소프트 경고"(soft warning)라고 합니다. 일별 라이선스 할당량은 자정에 재설정되고, 이 때 소프트 경고(soft warning)는 "하드 경고"(hard warning)가 됩니다. 이 때까지 경고를 해결하고 내일도 할당량이 초과되지 않도록 해야 합니다. 데이터를 이미 인덱싱한 상태라면 데이터 인덱싱을 취소하여 라이선스 사용 "재량권"을 다시 획득할 방법이 없습니다. 다음 방법 중에서 선택해야 합니다. 할당량이 더 많은 라이선스를 구입하거나 여유 라이선스 용량이 있는 경우 라이선스 풀을 재정렬하여 라이선스 용량을 늘립니다. 라이선스 사용을 줄입니다. 59

60 할당량에 가장 많은 영향을 미치는 데이터 원본이 무엇인지 알아보려면 라이선스 사용량 보고서 뷰를 확인하십시오. 주요 원인이 되는 데이터를 확인했으면 내보내는 데이터가 모두 필요한지 결정하십시오. 또는 데이터 포워딩 매뉴얼에서 "데 이터 전송 및 필터링"을 읽어보십시오. 답변 질문이 있으십니까? Splunk 응답 페이지에 가면 라이선스 위반과 관련하여 Splunk 커뮤니티에서 올린 질문과 답변을 볼 수 있습니다. 라이선스 마스터 교체 이제 라이선스 풀이 설정되었습니다. 라이선스 슬레이브 중 하나를 풀의 라이선스 마스터로 전환하려면 어떻게 해야 합니 까? 다음 항목에서는 이 작업을 수행하는 절차에 대해 설명합니다. 먼저 슬레이브를 마스터로 승격시켜야 합니다. 그런 다음 이 전 마스터를 슬레이브로 강등시킵니다. 자세한 내용은 다음 항목을 참조하십시오. 1. 새 라이선스 마스터를 라이선싱 풀에서 제거하고 마스터로 설정합니다. (새 마스터가 될) 라이선스 슬레이브에 로그인합니다. 설정 > 라이선싱으로 이동합니다. 프롬프트에 따라 라이선스 슬레이브를 새 라이선스 마스터로 설정합니다. Splunk를 재시작합니다. 2. 새 라이선스 마스터에서 라이선스 키를 추가합니다. 라이선스 키가 이전 라이선스 마스터와 일치하는지 확인합니다. 3. 풀의 나머지 라이선스 슬레이브를 새 라이선스 마스터로 지정합니다. 각 슬레이브에서 설정 > 라이선싱으로 이동합니다. 새 라이선스 마스터를 나타내도록 마스터 라이선스 서버 URI를 변경하고 저장을 클릭합니다. 항목을 업데이트한 라이선스 슬레이브에서 Splunk를 재시작합니다. 4. 라이선스 슬레이브 중 하나가 새 라이선스 마스터에 연결되었는지 확인합니다. 5. 이전 라이선스 마스터를 슬레이브로 강등합니다. 이전 라이선스 마스터에서 설정 > 라이선싱 > 슬레이브로 변경으로 이동합니다. 재시작 프롬프트는 무시합니다. "슬레이브로 변경" 화면에서 새 슬레이브를 새 라이선스 마스터로 지정합니다("다른 Splunk 인스턴스를 마스터 라이 선스 서버로 지정"). 6. 새 라이선스 슬레이브에서 Splunk를 중지하고 /opt/splunk/etc/licenses/enterprise/ 폴더에서 이전 라이선스 파일을 삭제 합니다. 그렇지 않으면 중복 라이선스가 생성되고 오류 또는 경고가 나타납니다. 7. 새 라이선스 슬레이브에서 Splunk를 시작하고 슬레이브가 새 라이선스 마스터에 연결되는지 확인합니다. 라이선스 사용량 보고서 뷰 Splunk Enterprise 라이선스 사용량 보고서 뷰에 대하여 라이선스 사용량 보고서 뷰 소개 라이선스 사용량 보고서 뷰(LURV)는 라이선스 용량과 인덱싱 볼륨 관련 문의에 대한 답을 제시하는 Splunk의 새로운 통합 리소스입니다. LURV는 Splunk 라이선스 사용량을 쉽고 빠르게 파악할 수 있는 방법입니다. Splunk 라이선싱 페이지에서 직 접 일별 Splunk 인덱싱 용량과 모든 라이선스 경고를 즉시 파악할 수 있으며, 다양한 보고 옵션을 사용하여 지난 30일 간의 Splunk 사용량을 종합적으로 볼 수도 있습니다. LURV는 라이선스 풀에 대해 자세한 라이선스 사용량 정보를 표시합니다. 대시보드는 논리적으로 두 부분으로 나뉩니다. 하 나는 오늘의 라이선스 사용량에 대한 정보와 모든 경고 정보를 현재 롤링 윈도우에 표시하고, 다른 하나는 지난 30일 간의 라 이선스 사용량 기록을 보여줍니다. LURV의 모든 패널 왼쪽 하단에 있는 "검색에서 열기"를 클릭하면 검색 작업을 원하는 대로 수행할 수 있습니다. 라이선스 사용량 보고서 뷰 액세스 시스템 > 라이선싱 > 사용량 보고서에서 LURV를 찾습니다. 60

61 배포 환경의 라이선스 마스터에서 LURV에 액세스합니다. 배포 환경이 하나만 있는 경우 해당 배포 환경이 자체 라이선스 마 스터가 됩니다. 오늘 탭 LURV를 처음 열면 "오늘" 탭에 패널 5개가 있음을 볼 수 있습니다. 각 패널에는 라이선스 사용 상태와 당일에 아직 해결되지 않은 경고가 표시됩니다. 라이선서의 하루는 라이선스 마스터가 설정된 시간대의 자정에 종료됩니다. "오늘" 탭의 모든 패널은 Splunk REST API를 쿼리합니다. 오늘의 라이선스 사용량 패널 이 패널에서는 오늘의 라이선스 사용량과 일별 라이선스의 총 할당량을 모든 풀에 걸쳐 측정합니다. 오늘의 풀별 라이선스 사용량 패널 이 패널에는 각 풀에 대해 라이선스 사용량과 일별 라이선스 할당량이 표시됩니다. 오늘 풀별로 사용된 일별 라이선스 할당량의 비율(%) 패널 이 패널에는 각 풀에서 인덱싱된 일별 라이선스 할당량의 비율(%)이 표시됩니다. 비율은 로그 스케일에 표시됩니다. 풀 사용량 경고 패널 이 패널에는 각 풀에서 지난 30일 동안 (또는 마지막으로 라이선스 재설정 키를 적용한 이후) 수신한 소프트 경고와 하드 경 고가 모두 표시됩니다. 소프트 경고 및 하드 경고와 라이선스 위반에 대한 자세한 내용은 이 매뉴얼의 "라이선스 위반에 대하 여"를 참조하십시오. 슬레이브 사용량 경고 패널 각 라이선스 슬레이브에 대해 이 패널에는 경고 수, 풀 구성원 자격 및 슬레이브 위반 여부가 표시됩니다. 이전 30일 탭 "이전 30일" 탭을 클릭하면 추가 패널 5개와 여러 드롭다운 옵션이 나타납니다. 각 패널에서 시각화되는 정보는 모두 차트에 표시되는 host, source, source type, index, pool(분할 기준 필드)의 수를 제한 합니다. 상이한 값이 10개보다 많은 필드가 있을 경우 10번째 값 이후의 값은 "기타"로 표시됩니다. Splunk에서는 timechart를 사용하여 차트에 표시되는 값의 최대 수를 10개로 설정했습니다. 대부분의 경우 이 설정으로 시각화 자료를 쉽 게 읽을 수 있고 충분한 정보를 제공합니다. 각 패널에는 모두 license_usage.log, type=rolloversummary(일별 합계)에서 수집된 데이터가 사용됩니다. 현지 시간으로 자정 에 라이선스 마스터 작동이 중단된 경우에는 당일의 RolloverSummary 이벤트가 생성되지 않고 각 패널에 당일 데이터가 표 시되지 않습니다. 분할 기준: 분할 없음, 인덱서, 풀 이 세 가지 분할 기준 옵션은 별도의 설명이 필요하지 않습니다. 라이선스 풀에 인덱서 추가 및 라이선스 풀에 대한 자세한 내 용은 이 매뉴얼의 앞부분에 있는 관련 장을 참조하십시오. 분할 기준: source, source type, host, index 이 네 가지 분할 기준 필드에 관해서는 보고서 가속화와 스쿼싱이라는 두 가지 사항을 알아야 합니다. 보고서 가속화 source, source type, host 기준 분할에는 실시간 사용량 통계를 1분 간격으로 제공하는license_usage.log type=usage 가 사 용됩니다. 각 분할 기준 옵션을 지원하는 보고서는 라이선스 마스터에서 가속화하는 것이 좋습니다. (가속화를 사용하지 않 으면 분당 하나의 이벤트 속도로 생성되는 30일 분량의 (엄청나게 많은 이벤트의) 데이터를 검색하므로 검색 속도가 매우 느 릴 수 있습니다.) 61

62 이 보고서의 가속화 기능은 기본적으로 사용할 수 없습니다. 보고서를 가속화하려면 이 분할 기준 값 중 하나를 선택할 때 정 보 메시지에 표시되는 링크를 클릭하십시오. 가속화 워크플로는 설정 > 검색 및 보고서 > 라이선스 사용량 데이터 큐브에서 도 찾을 수 있습니다. 보고 매뉴얼의 "보고서 가속화"를 참조하십시오. 보고서 가속화를 처음 선택한 후 실제로 가속화가 시작되려면 최대 10분의 시간이 걸릴 수 있습니다. 그런 다음 Splunk가 가 속화 요약을 작성하는 데도 요약 데이터 양에 따라 일반적으로 몇 분에서 몇십 분의 시간이 걸립니다. 가속화 요약 작성이 완 료되어야 각 분할 기준 옵션의 성능이 개선됩니다. 그러나 가속화를 처음 실행한 후 후속 보고서는 기존 정보를 토대로 하여 최신 상태로 유지되며 보고 속도도 빨라집니다. 따 라서 보고서 가속화를 처음 켰을 때만 시간이 많이 소요됩니다. 중요: 보고서 가속화는 라이선스 마스터에서만 사용하십시오. 가속화 실행 빈도는 savedsearches.conf에서 auto_summarize를 사용하여 설정하십시오. 기본 간격은 10분입니다. 빈도를 높게 설정하여 워크로드를 작고 안정적으로 유지하십시오. 10분 간격으로 3분째 되는 시점에 크론이 삽입되어 있습니다. 이 설정은 auto_summarize.cron_schedule에서 설정할 수 있습니다. 스쿼싱(Squashing) 모든 인덱서는 인덱싱한 데이터에 대한 통계를 source, source type, host 및 인덱스별로 나눠 라이선스 관리자에 주기적으 로 보고합니다. 고유한 (source, source type, host, index) 튜플의 수가 증가하여 squash_threshold를 초과하면 Splunk가 {host, source} 값을 스쿼싱(squashing)하고 {sourcetype, index}를 기준으로 분석된 통계만 보고합니다. 그 이유는 메모리 사용량과 license_usage.log의 행 수가 폭발적으로 증가하는 것을 방지하기 위해서입니다. 다른 필드의 값이 스쿼싱(squashing)되기 때문에 source type 및 index 기준 분할을 사용해야만 완전한 (전체 바이트) 보고 가 보장됩니다. source 및 host 기준 분할을 사용하면 두 필드가 여러 고유 값을 나타낼 경우 완전히 보고되지 않을 수 있습 니다. Splunk는 인덱싱된 전체 수량을 보고하지만, 이름은 보고하지 않습니다. 따라서 해당 수량을 누가 사용했는 지와 같은 세부 정보는 알 수 없지만 사용량은 알 수 있습니다. 스쿼싱(squashing)은 server.conf 또는 [license] 스탠자에서 squash_threshold 설정을 통해 설정할 수 있습니다. 값을 더 높 게 설정할 수 있지만, 그러면 메모리 사용량이 증가할 수 있으므로 변경하기 전에 Splunk Support 엔지니어와 상의하십시오. LURV는 (UI의 경고 메시지를 통해) 스쿼싱(squashing)이 수행되었는지 항상 알려줍니다. 세부 정보가 필요하면per_host_thruput을 사용하여 metrics.log에서 얻을 수 있습니다. 평균 일일 용량 기준 상위 5개 값 "상위 5개" 패널에는 각 분할 기준 메뉴에서 선택된 분할 기준 필드에 대한 상위 5개 값의 일별 평균 및 최대 사용량이 표시됩 니다. 여기서는 상위 5개의 (최대가 아닌) 평균 값이 선택됩니다. 그러므로 5가지가 넘는 source type이 있고 일반적으로 Source type F는 나머지 값보다 훨씬 더 작지만 순간적으로 최고치에 도달하는 경우입니다. Source type F의 최고 일일 사용량은 매 우 높지만, (사용량이 매우 적은 날이 많아서 평균이 낮아지므로) 평균 사용량은 여전히 매우 낮을 수 있습니다. 이 패널에는 상위 5개 평균 값이 선택되므로, source type F는 이 뷰에 표시되지 않을 수 있습니다. LURV 사용 LURV 패널을 기준으로 경고 설정에 대한 정보는 다음 항목을 참조하십시오. 라이선스 사용량 보고서 뷰 사용 이 항목에서는 라이선스 사용량 보고서 뷰(LURV) 사용에 대해 설명합니다. 이 뷰에 대해 자세히 알려면 이전 항목 "Splunk 의 라이선스 사용량 보고서 뷰에 대하여"를 참조하십시오. 경고 설정 모든 LURV 패널을 경고로 전환할 수 있습니다. 예를 들어 라이선스 사용량이 할당량의 80%에 도달할 때 경고가 생성되도 록 설정하는 경우를 가정해 보십시오. 오늘 사용된 일일 라이선스 사용 할당량의 비율(%) 패널에서 시작합니다. 패널의 왼쪽 하단에 있는 "검색창에서 열기"를 클 릭합니다. where '% used' > 80 을 추가한 다음 다른 이름으로 저장 > 경고를 선택하고 경고 마법사를 따라 진행합니다. 경고에 대한 자세한 내용은 경고 매뉴얼을 참조하십시오. LURV 문제 해결: 30일 패널에 결과 없음 라이선스 사용량 보고서 뷰의 "지난 30일" 뷰 패널에 결과가 없다면 해당 페이지를 확인하기 위해 사용한 라이선스 마스터 인스턴스에서 검색 시 $SPLUNK_HOME/var/log/splunk/license_usage.log 파일에서 이벤트를 찾을 수 없었음을 의미합니다. 이것에 대한 이유는 일반적으로 두 가지입니다. 62

63 라이선스 마스터가 이벤트를 인덱서에 포워딩하도록 설정되었지만(이 모범 사례에 대한 자세한 내용은 분산 검색 매 뉴얼 참조) 검색 헤드로 설정되지 않았습니다. 이 문제는 라이선스 마스터에서 이벤트를 포워딩하는 모든 인덱서를 검 색 피어로 추가함으로써 쉽게 교정할 수 있습니다. 라이선스 마스터는 자체 $SPLUNK_HOME/var/log/splunk 디렉터리에서 이벤트를 읽지 않습니다(그러므로 인덱싱도 하지 않습니다). 특정 이유로 [monitor://$splunk_home/var/log/splunk] 기본 데이터 입력이 비활성화된 경우 이렇게 될 수 있습니다. 라이선스 마스터가 자정에 다운된 경우에도 데이터에 공백이 발생할 수 있습니다. 분산 관리 콘솔로 Splunk Enterprise 모니터링 분산 관리 콘솔 설정 분산 관리 콘솔이란 무엇입니까? 분산 관리 콘솔을 통해 Splunk Enterprise 배포에 대한 자세한 성능 정보를 볼 수 있습니다. 이 장의 항목에서는 사용 가능한 대시보드 및 경고에 대해 설명합니다. 사용 가능한 대시보드를 통해 배포 인덱싱 성능, 검색 성능, 운영 체제 리소스 사용량, Splunk Enterprise 앱 key value 스토 어 성능 및 라이선스 사용량을 파악할 수 있습니다. 분산 관리 콘솔 찾기 Splunk Web에서 설정을 클릭한 다음 왼쪽의 분산 관리 콘솔 아이콘을 클릭합니다. 관리자만 분산 관리 콘솔(DMC)을 볼 수 있습니다. Splunk Enterprise 인스턴스에서 DMC를 독립형 모드로 남겨둘 수 있습니다. 이것은 배포에서 개별 인스턴스의 DMC로 이 동할 수 있으며 특정 인스턴스 성능을 확인할 수 있음을 의미합니다. 아니면 분산 모드에 필요한 설정 단계를 수행할 수도 있 습니다. 분산 모드를 통해 하나의 인스턴스에 로그인하고 배포에서 모든 인스턴스에 대한 성능 정보를 확인할 수 있습니다. 설정 단계(독립형 모드에 있는 경우에도)를 거쳐 기본 플랫폼 경고에 액세스할 수도 있습니다. 어떤 인스턴스가 콘솔을 호스트해야 합니까? 분산 모드로 DMC를 설정한 후 배포에서 하나의 인스턴스에서만 DMC로 이동할 수 있으며 전체 배포에 대한 콘솔 정보를 볼 수 있습니다. 분산 관리 콘솔을 호스트할 위치에는 몇 가지 옵션이 있습니다. 선택한 인스턴스는 검색 헤드로 설정되어야 합니다. 용량 계 획 매뉴얼의 "참조 하드웨어"를 참조하십시오. 보안 및 일부 성능상의 이유로 Splunk Enterprise 관리자만 이 인스턴스에 액 세스해야 합니다. 배포 서버에서 분산 모드로 DMC를 호스트하지 마십시오. 인덱서 클러스터에서: 기본적으로 클러스터 마스터에 인덱서 클러스터에서는 분산 관리 콘솔을 클러스터 마스터에 호스트하십시오. 인덱스 및 클러스터 관리 매뉴얼의 "시스템 요 구 사항"을 참조하십시오. 대안은 클러스터 내의 전용 검색 헤드입니다. 새로운 전용 검색 헤드는 다른 검색 헤드를 확인해야 합니다. 즉 검색 헤드는 "검색 헤드의 검색 헤드"여야 합니다. 클러스터 마스터를 실행하는 컴퓨터에 추가 용량이 없거나 Splunk Enterprise 6.2로 업그레이드하지 않으려는 경우 이 옵션을 사용할 수 있습니다. 클러스터 마스터에 DMC를 호스트하면 해당 대시보드를 확인 63

64 하는 데 사용한 동일한 인스턴스에서 인덱서 클러스터 관리에 액세스할 수 있습니다. 두 개 이상의 클러스터가 있는 경우 클러스터별로 하나의 분산 관리 콘솔을 활성화하십시오. 비인덱서 클러스터 환경에서 옵션 1: 라이선스 마스터에 다음이 true인 경우 라이선스 마스터에 모니터링 콘솔을 설정할 수 있습니다. 라이선스 마스터는 검색 워크로드를 처리할 수 있습니다. 즉 검색 헤드 참조 하드웨어 요구 사항을 충족하거나 초과할 수 있습니다. 용량 계획 매뉴얼의 "참조 하드웨어"를 참조하십시오. Splunk Enterprise 관리자만 전용 라이선스 마스터에 액세스할 수 있습니다. 비인덱서 클러스터 환경에서 옵션2: 새 인스턴스에 다른 옵션은 새 인스턴스를 프로비저닝하고 새 인스턴스를 검색 헤드의 검색 헤드 및 인덱서의 검색 헤드로 설정하고 여기에 서 DMC를 분산 모드로 설정하는 것입니다. 검색 헤드 클러스터 환경에서 DMC를 호스팅하는 데 주 배포 노드 또는 전용 라이선스 마스터를 사용하십시오. DMC는 검색 헤드 클러스터 구성원이 될 수 없습니다. 분산 검색 매뉴얼의 "검색 헤드 클러스터에 대한 시스템 요구 사항 및 기타 배포 고려 사항"을 참조하십시오. 분산 관리 콘솔은 검색 헤드 풀링 환경에서 지원되지 않습니다. DMC를 설정하여 배포 모니터링 전제 조건 기능적 Splunk Enterprise 배포가 있어야 합니다. 분산 배포 매뉴얼의 "분산 Splunk Enterprise 개요"를 참조하십시오. 모니터링할 모든 인스턴스는 Splunk Enterprise 6.1 이상에서 실행되어야 합니다. 배포가 양호한지, 즉 모든 피어가 작동 상태인지 확인합니다. 배포의 각 인스턴스(각 검색 헤드, 라이선스 마스터 등)가 고유한 server.conf servername 값 및 inputs.conf host 값을 가지는지 확인합니다. 내부 로그($SPLUNK_HOME/var/log/splunk 및 $SPLUNK_HOME/var/log/introspection 모두)를 다른 모든 인스턴스 유형에서 인덱서로 포워딩합니다. 분산 검색 매뉴얼에서 "검색 헤드 데이터 포워딩"을 참조하십시오. 이 단계를 수행하지 않으 면 많은 대시보드에 데이터가 부족하게 됩니다. 다른 인스턴스 유형에는 다음이 포함됩니다. 검색 헤드 라이선스 마스터 클러스터 마스터 배포 서버 검색 피어로 인스턴스 추가 1. 분산 관리 콘솔을 설정하려는 인스턴스에 로그인합니다. 2. Splunk Web에서 설정 > 분산 검색 > 검색 피어를 선택합니다. 3. 각 검색 헤드, 배포 서버, 라이선스 마스터 및 독립형 인덱서를 분산 관리 콘솔을 호스팅하는 인스턴스에 분산 검색 피어로 추가합니다. 클러스터된 인덱서를 추가할 필요는 없지만 클러스터된 검색 헤드는 추가해야 합니다. 분산 모드로 DMC 설정 1. 분산 관리 콘솔을 설정하려는 인스턴스에 로그인합니다. 기본적으로 독립형 모드에서 인스턴스는 설정되어 있지 않습니 다. 64

65 2. Splunk Web에서 분산 관리 콘솔 > 설정을 선택합니다. 3. 왼쪽 상단에서 분산 모드를 설정합니다. 4. 다음을 확인합니다. 인스턴스 및 컴퓨터 레이블이 표시된 컬럼이 올바르게 채워지고 컬럼 내의 고유한 값으로 채워져 있는지 확인합니다. 참고: 배포에 Splunk Enterprise 6.1.x( 대신)를 실행하는 노드가 있는 경우 해당 인스턴스(호스트) 및 컴퓨터 값 은 채워지지 않습니다. 컴퓨터의 값을 찾으려면 6.1.x 인스턴스에 로그인하고 *nix 또는 Windows에서 hostname을 실행하십시오. 여기 서 컴퓨터는 컴퓨터의 FQDN을 나타냅니다. 인스턴스(호스트)의 값을 찾으려면 다음 btool( splunk cmd btool inputs list default)을 사용하십시오. 해당 값을 알고 있는 경우 설정 페이지에서 편집 > 인스턴스 편집을 클릭합니다. 팝업에 입력해야 하는 두 개의 필드 즉, 인스턴스(호스트) 이름 및 컴퓨터 이름 필드가 나타납니다. 서버 역할(기본 또는 주요 역할)이 올바른지 확인합니다. 예를 들어, 라이선스 마스터인 검색 헤드에는 두 역할이 모두 표시되어 있어야 합니다. 그렇지 않으면 편집을 클릭하여 수정하십시오. 인덱서 클러스터링을 사용하는 경우 클러스터 마스터가 식별되는지 확인합니다. 그렇지 않으면 편집을 클릭하여 수정 하십시오. 주의: 인덱서로 표시된 모든 항목이 실제로 인덱서인지 확인하십시오. 5. (선택 사항) 사용자 지정 그룹을 설정합니다. 사용자 지정 그룹은 분산 검색 그룹에 직접 매핑하는 태그입니다. DMC 설정 을 처음 수행하는 경우(또는 그 이전)에는 그룹을 추가할 필요가 없습니다. 예를 들어, 멀티사이트 인덱서 클러스터링(각 그 룹이 하나의 위치에서 인덱서로 구성될 수 있음) 또는 인덱서 클러스터와 독립형 피어를 가진 경우, 그룹이 유용한 것을 알 수 있을 것입니다. 사용자 지정 그룹은 중복이 허용됩니다. 즉, 하나의 인덱서가 여러 그룹에 속할 수 있습니다. 분산 검색 매뉴 얼의 분산 검색 그룹을 참조하십시오. 6. 저장을 클릭합니다. 7. (선택 사항) 플랫폼 경고를 설정합니다. 이후에 다른 노드를 배포에 추가하는 경우 설정으로 돌아가 4단계의 항목이 정확한지 확인합니다. 단일 인스턴스에 설정 자체로 작동되는 단일 Splunk Enterprise 인스턴스에서는 플랫폼 경고를 사용하기 전에 독립형 모드를 설정해야 합니다. 설정하려면 다음 작업을 수행하십시오. 1. DMC에서 설정 페이지로 이동합니다. 2. 검색 헤드, 라이선스 마스터 및 인덱서가 서버 역할 아래에 나열되어 있고 다른 역할에는 나열되어 있지 않음을 확인합니 다. 그렇지 않은 경우 편집을 클릭합니다. 3. 변경 사항 적용을 클릭하여 설정을 완료합니다. 플랫폼 경고 플랫폼 경고란 무엇입니까? 플랫폼 경고는 분산 관리 콘솔(DMC)에 포함된, 저장된 검색입니다. 플랫폼 경고는 Splunk Enterprise 환경을 저해할 수 있 는 조건을 Splunk Enterprise 관리자에게 알립니다. 포함된 플랫폼 경고는 REST endpoint에서 해당 데이터를 가져옵니다. 플랫폼 경고는 기본적으로 비활성화되어 있습니다. 플랫폼 경고 활성화 전제 조건 분산 관리 콘솔을 설정하고 DMC에서 설정을 클릭합니다. "분산 관리 콘솔 설정"을 참조하십시오. 배포에서 경고에 대한 경고 알림을 설정합니다. 1. DMC 개요 페이지에서 경고 > 활성화 또는 비활성화를 클릭합니다. 2. 활성화하려는 경고 옆에 있는 사용 가능 확인란을 클릭합니다. 경고가 트리거된 후 개요 > 경고 > 트리거된 경고 관리로 이동하여 경고 및 경고의 결과를 볼 수 있습니다. 65

66 이메일 알림과 같이 설정할 수 있는 경고 작업에 대해 플랫폼 경고 설정을 참조하십시오. 플랫폼 경고 설정 DMC에서 개요 > 경고 > 활성화 또는 비활성화로 이동합니다. 설정할 경고를 찾은 후 편집을 클릭합니다. 기본 설정을 보고 다음과 같은 매개 변수를 변경할 수 있습니다. 경고 예약 제거 시간 경고 작업(예: 이메일) 경고 매뉴얼의 "경고 작업 설정" 및 모든 경고 옵션을 참조하십시오. $SPLUNK_HOME/etc/apps/splunk_management_console/default/savedsearches.conf에서 플랫폼 경고에 대한 기본 매개 변수의 전 체 리스트를 볼 수도 있습니다. 직접 설정 파일을 편집하도록 선택하는 경우 기본값 대신 로컬 디렉터리에서 새로운 설정을 지정합니다. 어떤 경고가 포함됩니까? 플랫폼 경고로 배포 모니터링을 시작하려면 원하는 개별 경고를 활성화해야 합니다. "플랫폼 경고 활성화"를 참조하십시오. 경 고 이 름 인덱 서 프 로세 서의 비정 상적 인 상 태 설명 하나 이상의 인덱서가 비정상적인 상태를 보고할 때 발생합 니다. 이 비정상적인 상태는 조절 또는 중단될 수 있습니다. 참고 항목 어떤 인덱서가 어떤 비정상적인 상태인지에 대한 자세한 내용을 확인하고 원인을 조사하려면 DMC 인덱싱 성능: 배포 대시보드의 인스턴스별 인덱싱 성능 패널을 참조하십시오. 대시보드에 대한 내용 은 "인덱싱 성능: 배포" 및 "인덱싱 작동 방식"을 참조하십시오. 심각 한 시 스템 물리 적 메 모리 사용 량 하나 이상의 인스턴스가 90%의 메모리 사용량을 초과할 때 발생합니다. 대부분의 Linux 배포에서 OS가 버퍼 및 파일 시 스템 캐시 작업을 수행하고 있는 경우 이 경고는 트리거될 수 있습니다. 다른 프로세스에 메모리가 필요한 경우 OS가 이 메모리를 릴리스하므로 이것이 항상 심각한 문제를 나타내는 것은 아닙니다. 인스턴스 메모리 사용량에 대한 자세한 내용은 DMC 리소스 사용량: 배포 대시보드로 이동하여 이 매뉴얼의 "리소스 사용량: 배포"를 참조하십시 오. 심각 에 가 까운 디스 크 사 용량 디스크 용량의 80%를 사용할 때 발생합니다. 디스크 사용량에 대한 자세한 내용은 세 개의 DMC 리소스 사용량 대시보드로 이동하여 이 매 뉴얼의 해당 항목을 읽으십시오. 포화 상태 의 이 벤트 처리 대기 열 하나 이상의 인덱서 대기열이 지난 15분간 평균이 90% 이상 인 적재 백분율을 보고할 때 발생합니다. 이 경고를 통해 잠재 적인 인덱싱 대기 시간을 알 수 있습니다. 인덱서 대기열에 대한 자세한 내용은 두 개의 DMC 인덱싱 성능 대시보드로 이동하여 이 매뉴 얼의 해당 항목을 읽으십시오. 응답 하지 않는 검색 피어 일별 할당 량에 가까 운 총 라이 선스 사용 량 검색 피어(인덱서)의 모든 항목이 응답하지 않을 때 발생합니 다. 전체 일별 라이선스 할당량의 90%를 사용할 때 발생합니다. 모든 인스턴스 상태에 대한 내용은 DMC 인스턴 스 뷰를 참조하십시오. 라이선스 사용량에 대한 자세한 내용은 DMC에서 라이선싱을 클릭합니다. 검색 아티팩트에 대하여 66

67 savedsearches.conf에서 dispatch.ttl 설정은 플랫폼 경고에서 검색이 4시간 동안 검색 아티팩트를 유지하도록 지시합니 다. 그러나 경고가 트리거되는 경우 해당 검색 아티팩트가 7일 동안 유지됩니다. 이는 트리거된 경고의 검색 결과를 검사하도록 이메일에 전송된 링크가 7일(기본값) 후에 만료됨을 의미합니다. 인덱싱 성능: 인스턴스 이 뷰에는 무엇이 표시됩니까? 배포에서 잠재적으로 여러 개인 인스턴스 중 하나에서 인덱싱 성능에 대한 여러 개의 패널이 표시됩니다. 이 뷰에서 결과 해석 Splunk Enterprise 데이터 파이프라인이라는 스냅샷 패널은 대기열 크기에 대한 감속 평균을 표시합니다. 평균은 이전 15 분간의 데이터를 사용합니다. 데이터 처리 대기열의 중간값 Fill Ratio historical 패널과 함께 이 패널을 사용하여 특정 대기 열에 대한 인덱싱 대기 시간의 원본 범위를 좁힐 수 있습니다. 데이터는 파싱에서 시작하고 데이터 파이프라인을 통해 인덱 싱까지 이동합니다. 인덱서 프로세서 작업당 소요된 CPU Seconds 집계 패널을 통해 "하위 작업별 인덱스 서비스 분할"을 수행할 수 있습니다. 여러 개의 인덱스 서비스는 인덱싱 후의 준비 및 정리와 관련된 하위 작업입니다. 이 뷰에서 주의할 사항 데이터 처리 대기열의 중간값 Fill Ratio historical 패널과 함께 Splunk Enterprise 데이터 파이프라인 패널을 사용하여 특 정 대기열에 대한 인덱싱 대기 시간의 원본 범위를 좁힐 수 있습니다. 데이터는 파싱에서 시작하고 데이터 파이프라인을 통 해 인덱싱까지 이동합니다. 다음은 양호하지 않은 대기열을 가진 인스턴스에 있는 패널의 예제입니다. 이 예제에서는 파싱 및 aggregator 대기열의 매우 높은 fill ratio에도 불구하고 입력 대기열에서의 처리가 문제일 수 있습니 다. 입력 대기열이 속도가 저하되는 첫 번째 대기열이며 데이터가 입력 대기열로 가져오기를 기다리는 동안 다른 두 개의 대 기열로 백업됩니다. 이 뷰 문제 해결 스냅샷 패널은 인트로스펙션을 위해 Splunk REST endpoint에서 데이터를 가져옵니다. 스냅샷 패널에 데이터가 부족한 경 우 플랫폼 계측에 필요한 시스템 요구 사항을 확인하십시오. 이 뷰에 대한 historical 패널은 metrics.log에서 데이터를 가져옵니다. 인덱싱 성능: 배포 이 뷰에는 무엇이 표시됩니까? Splunk Enterprise 배포에서 인덱싱 성능에 대한 여러 개의 패널이 표시됩니다. 이 뷰에서 결과 해석 인덱싱 성능의 개요 패널에서 전체 인덱싱 속도는 모든 인덱서에 걸쳐 집계됩니다. 예상 인덱싱 속도별 인스턴스 패널에서 인덱싱 속도는 기본적으로 각 유형에 대해 상위 10개의 결과만 얻는 metrics.log를 사용하므로 이를 예상할 수 있습니다. 문제 해결 매뉴얼의 "metrics.log에 대하여"를 참조하십시오. 이 뷰 문제 해결 스냅샷 패널은 인트로스펙션을 위해 Splunk REST endpoint에서 데이터를 가져옵니다. 스냅샷 패널에 데이터가 부족한 경 우 플랫폼 계측에 필요한 시스템 요구 사항을 확인하십시오. 이 뷰에 대한 historical 패널은 metrics.log에서 데이터를 가져옵니다. 67

68 검색 작업: 인스턴스 이 뷰에는 무엇이 표시됩니까? 검색 작업에 대한 여러 개의 패널이 표시됩니다. 이 뷰에서 결과 해석 검색의 중간값 리소스 사용량 패널에서 다음을 참조하십시오. 리소스 사용량은 모든 검색에 대해 집계됩니다. 메모리 사용량은 물리적 메모리를 나타냅니다. 이 차트에서 CPU 사용량은 시스템 전체 CPU 사용량이 아닌 하나의 코어의 백분율로 표시됩니다. 결과적으로 여기에 서는 100%보다 큰 값을 보게 되지만 분산 관리 콘솔에 있는 CPU 사용량의 다른 예제는 그렇지 않습니다. 검색 실행 시간 집계 패널에서 다음을 참조하십시오. 차트에서 각 시간 빈의 경우 DMC는 해당 시간 범위 동안 실행된 모든 검색의 실행 시간을 합산합니다. 따라서 예를 들 면 5분 이내에 1000초의 검색을 볼 수 있습니다. 이는 다중 검색이 5분 동안 실행되었음을 의미합니다. Historical batch 및 RT indexed 모드에 대해 historical batch는 Splunk Enterprise(예: 스케줄러) 내의 특정 기능에 의 해서만 발송될 수 있습니다. RT indexed는 인덱스된 실시간을 의미합니다. 메모리를 많이 사용하는 상위 10개 검색 패널에서 SID는 검색 ID를 의미합니다. 저장된 검색에 대한 정보를 찾는 경우 audit.log는 저장된 검색(savedsearch_name)을 해당 검색 ID(search_id), 사용자 및 시간의 이름과 일치시킵니다. search_id로 Splunk 검색 로그("Splunk가 Splunk에 대해 로깅하는 내용" 참조)에서와 같이 다른 곳에서 해당 검색을 조회할 수 있습니다. 이 뷰에서 조회할 항목 시스템 제한과 비교하여 검색 동시성 및 리소스 사용량을 고려하십시오. 참고 항목: 검색 매뉴얼의 "보다 효율적인 검색 작성" 검색 매뉴얼의 "검색에 대하여" 보고 매뉴얼의 "예약된 보고서의 우선 순위 설정" Knowledge 관리자 매뉴얼의 "요약 기반 검색 및 피벗 가속화 개요" 이 뷰 문제 해결 검색 작업 패널에서 스냅샷은 기본적으로 매 10초마다 측정됩니다. 그래서 현재 실행되는 검색이 없거나 검색이 매우 짧게 실행되는 경우, 스냅샷 패널이 공백으로 표시되고 "결과를 찾을 수 없습니다."라는 메시지가 나타납니다. Historical 패널은 인트로스펙션 로그에서 데이터를 가져옵니다. 패널이 공백으로 표시되거나 비인덱서에서 정보를 누락한 경우 다음 항목을 확인하십시오. 인덱서에 인트로스펙션 로그를 포워딩하고 있는지 여부 플랫폼 계측에 필요한 시스템 요구 사항 검색 작업: 배포 이 뷰에는 무엇이 표시됩니까? Splunk Enterprise 배포에서 검색 작업에 대한 여러 개의 검색 패널이 표시됩니다. 이 뷰에서 결과 해석 여기에 표시된 메모리 및 CPU 사용량은 검색 전용입니다. 모든 Splunk Enterprise 리소스 사용량에 대한 리소스 사용량 대 시보드를 참조하십시오. 중간값 CPU 사용량별 인스턴스 패널에서 CPU는 다중 코어로 인해 100%보다 클 수 있습니다. 중간값 메모리 사용량별 인스턴스 패널에서 메모리는 물리적입니다. Historical batch 및 RT indexed 모드의 경우 historical batch는 Splunk Enterprise(예: 스케줄러) 내의 특정 기능에 의해서만 발송될 수 있습니다. RT indexed는 인덱스된 실시간을 의미합니다. 이 뷰에서 조회할 항목 컴퓨터에서 제한 초과에 근접한 항목을 검색합니다. 참고 항목: 68

69 검색 매뉴얼의 "보다 효율적인 검색 작성" 검색 매뉴얼의 "검색에 대하여" 보고 매뉴얼의 "예약된 보고서의 우선 순위 설정" 용량 계획 매뉴얼의 "여러 동시 검색 지원" 이 뷰 문제 해결 Historical 패널은 인트로스펙션 로그에서 데이터를 가져옵니다. 패널이 공백으로 표시되거나 비인덱서에서 정보를 누락한 경우 다음 항목을 확인하십시오. 인덱서에 인트로스펙션 로그를 포워딩하고 있는지 여부 플랫폼 계측에 필요한 시스템 요구 사항 검색 사용량 통계: 인스턴스 이 뷰에는 무엇이 표시됩니까? 검색 사용량 통계에 대한 여러 개의 패널이 표시됩니다. 이 뷰에서 결과 해석 오래 걸리는 검색 패널에서: ZERO_TIME의 시작 시간은 검색이 epoch까지 실행됨을 의미합니다. ZERO_TIME의 종료 시간은 검색이 발생한 순간까지 검색이 수행됨을 의미합니다. 시작 시간과 종료 시간이 모두 ZERO_TIME으로 나열된 경우에는 전체 시간 검색을 나타냅니다. 공통 검색 명령어 패널에서 실행 시간은 초로 표시됩니다. 이 뷰에서 주의할 사항 오래 걸리는 검색을 살펴보는 것은 좋은 방법입니다. 최적화할 수 있는 검색을 찾을 수도 있기 때문입니다. 자세한 내용은 검색 매뉴얼의 "보다 효율적인 검색 작성"을 참조하십시오. 이 뷰 문제 해결 이 뷰에서 historical 패널은 audit.log에서 해당 데이터를 가져옵니다. 패널이 공백으로 표시되거나 비인덱서에서 정보를 누 락한 경우 인덱서에 인트로스펙션 로그를 포워딩하고 있는지 여부를 확인하십시오. 오래 걸리는 검색 패널도 REST endpoint의 정보를 사용합니다. 리소스 사용량: 인스턴스 이 뷰에는 무엇이 표시됩니까? 검색 작업에 대한 여러 개의 패널이 표시됩니다. 이 뷰에서 결과 해석 두 개의 "프로세스 클래스" 패널에서 프로세스 클래스는 splunkd 서버, 검색, Splunk Web, 인덱스 서비스, 스크립트 기반 입 력, KV 스토어 또는 다른 항목일 수 있습니다. 프로세스 클래스는 하나의 클래스 내에서 프로세스를 집계하는 것을 의미합니다. 참고 항목: splunkd의 경우, 설치 매뉴얼의 "Splunk Enterprise 아키텍처 및 프로세스"를 참조하십시오. 검색의 경우, 검색 매뉴얼의 "검색에 대하여" 및 "보다 효율적인 검색 작성"을 참조하십시오. splunkweb의 경우, 설치 매뉴얼의 "Splunk Enterprise 아키텍처 및 프로세스"를 참조하십시오. 스크립트 기반 입력의 경우, 데이터 가져오기 매뉴얼의 "스크립트 기반 입력을 통해 API 및 기타 원격 데이터 인터페이 스에서 데이터 가져오기"를 참조하십시오. KV 스토어의 경우, DMC의 "KV 스토어: 인스턴스" 뷰를 참조하십시오. 인덱스 서비스는 인덱싱과 관련한 하우스키핑 작업으로 구성됩니다. 하우스키핑 작업은 인덱싱 파이프라인의 끝에 실행되지 만 비동기입니다. 이러한 프로세스는 splunkd를 통해서 실행되지 않고 자체적으로 실행됩니다. 디스크 사용량 및 중간값 디스크 사용량 패널에는 Splunk Enterprise가 사용하는 파티션만 나열됩니다. 이 뷰에서 주의할 사항 많은 리소스를 사용하는 프로세스 클래스가 검색으로 판명되는 경우 검색 작업: 인스턴스 대시보드로 이동합니다. 오래 걸리는 프로세스의 경우 주의깊게 살펴봐야 할 문제점은 시간이 지남에 따라 메모리 사용량이 계속 늘어난다는 것입니 다. 69

70 이 뷰 문제 해결 Historical 패널은 인트로스펙션 로그에서 데이터를 가져옵니다. 패널이 공백으로 표시되거나 비인덱서에서 정보를 누락한 경우 다음 항목을 확인하십시오. 인덱서에 인트로스펙션 로그를 포워딩하고 있는지 여부 플랫폼 계측에 필요한 시스템 요구 사항 리소스 사용량: 서버 이 뷰에는 무엇이 표시됩니까? 검색 작업에 대한 여러 개의 패널이 표시됩니다. 이 뷰에서 결과 해석 이 뷰는 용량 계획은 물론 작동상의 사후 분석에도 유용할 수 있습니다. 자세한 내용은 용량 계획 매뉴얼을 참조하십시오. 이 뷰에서의 물리적 메모리 사용량에 대하여: Linux에서 OS는 파일 시스템 리소스를 캐시하기 위해 사용 가능한 물리적 메 모리를 사용하기 시작합니다. 그러나 메모리의 경계가 고정되어 있지 않으므로, 더 높은 우선 순위의 프로세스에서 메모리를 필요로 하는 경우 필요한 메모리를 해당 프로세스에서 우선적으로 확보할 수 있습니다. 그러므로 DMC 보고에서는 이러한 방식으로 고정된 대략적인 메모리의 양을 파악할 수 없습니다. 중간값 CPU 사용량 패널에서 100%는 여러 코어가 있는 전체 시스템을 의미하지만 이는 검색 작업 대시보드에 반대되며 여 기서 100%는 하나의 코어를 의미합니다. 이 뷰에서의 디스크 공간은 Splunk가 있는 파티션만을 나타냅니다. 이 뷰에서 주의할 사항 오래 걸리는 프로세스의 경우 주의깊게 살펴봐야 할 문제점은 시간이 지남에 따라 메모리 사용량이 계속 늘어난다는 것입니 다. 이 뷰 문제 해결 Historical 패널은 인트로스펙션 로그에서 데이터를 가져옵니다. 패널이 공백으로 표시되거나 비인덱서에서 정보를 누락한 경우 다음 항목을 확인하십시오. 인덱서에 인트로스펙션 로그를 포워딩하고 있는지 여부 플랫폼 계측에 필요한 시스템 요구 사항 리소스 사용량: 배포 이 뷰에는 무엇이 표시됩니까? 검색 작업에 대한 여러 개의 패널이 표시됩니다. 이 뷰에서 결과 해석 이 뷰에서의 물리적 메모리 사용량에 대하여: Linux에서 OS는 파일 시스템 리소스를 캐시하기 위해 사용 가능한 물리적 메 모리를 사용하기 시작합니다. 그러나 메모리의 경계가 고정되어 있지 않으므로, 더 높은 우선 순위의 프로세스에서 메모리를 필요로 하는 경우 필요한 메모리를 해당 프로세스에서 우선적으로 확보할 수 있습니다. 그러므로 DMC 보고에서는 이러한 방식으로 고정된 대략적인 메모리의 양을 파악할 수 없습니다. 배포 전역에서의 중간값 디스크 사용량 패널은 각 Splunk Enterprise 인스턴스에 의해 사용 중인 모든 파티션을 고려합니다. 이 뷰에서 주의할 사항 이 뷰의 공통 테마는 인스턴스가 값 범위별로 그룹화되었다는 것입니다. 한 가지 흥미로운 것은 다른 인스턴스와 비슷하지 않은 이상값: 인스턴스입니다. 시간이 지남에 따라 표시되는 패턴도 살펴봐야 합니다. 이 뷰 문제 해결 Historical 패널은 인트로스펙션 로그에서 데이터를 가져옵니다. 패널이 공백으로 표시되거나 비인덱서에서 정보를 누락한 경우 다음 항목을 확인하십시오. 인덱서에 인트로스펙션 로그를 포워딩하고 있는지 여부 플랫폼 계측에 필요한 시스템 요구 사항 KV 스토어: 인스턴스 70

71 이 뷰에는 무엇이 표시됩니까? DMC의 인스턴스 수준 KV 스토어 뷰는 앱 key-value 스토어를 실행하는 단일 Splunk Enterprise 인스턴스에 대한 성능 정보 를 표시합니다. 분산 배포로 DMC를 설정한 경우 배포에서 표시될 인스턴스를 선택할 수 있습니다. 성능 메트릭 컬렉션 메트릭은 /services/server/introspection/kvstore/collectionstats REST endpoint에서 데이터의 historical 레코드 인 _introspection 인덱스의 KVStoreCollectionStats 구성 요소에서 발생합니다. 메트릭은 다음과 같습니다. 애플리케이션. 컬렉션이 속한 애플리케이션입니다. 컬렉션. KV 스토어에서의 컬렉션 이름입니다. 개체 수. 컬렉션에 저장된 데이터 개체 수입니다. 가속화. 컬렉션에 설정된 가속화 수입니다. 참고: 이것은 성능 및 검색 가속화에 사용된 기존의 데이터베이스 스타일 인덱스입니다. 가속화 크기. 컬렉션에 설정된 인덱스 크기(MB)입니다. 컬렉션 크기. 컬렉션에 저장된 모든 데이터 크기(MB)입니다. 스냅샷은 관련 인트로스펙션 구성 요소에서 가장 최근 정보를 전송하는 REST endpoint를 통해 수집됩니다. KV 스토어 인 스턴스 스냅샷은 endpoint /services/server/introspection/kvstore/serverstatus를 사용합니다. Historical 잠금 백분율 - 시스템에서 전역 읽기 또는 쓰기 잠금을 유지하는 KV 스토어 가동 시간의 백분율입니다. 잠금 백분율이 높으면 전반적으로 영향을 미칩니다. 이로 인해 복제가 필요하거나 애플리케이션 호출이 느려지고 시간이 초과되거나 실패할 수도 있습니다. 페이지 오류 백분율 - 페이지 오류가 발생한 KV 스토어 작업의 백분율입니다. 1에 가까운 백분율은 시스템 성능 저하 를 의미하며 KV 스토어가 메모리에서 효율적으로 데이터 스토어에 액세스하지 않고 디스크 I/O에서 강제로 폴백하므 로 지속적인 지연을 나타내는 선행 지표가 됩니다. 메모리 사용량 - KV 스토어에서 사용 중인 매핑된 상주 가상 메모리의 양입니다. 가상 메모리 사용량은 일반적으로 KV 스토어에 대해 매핑된 메모리 사용량의 2배입니다. 3배를 초과하는 가상 메모리 사용량은 메모리 부족을 나타냅니 다. 네트워크 트래픽 - KV 스토어 네트워크 트래픽의 총 유입량(MB) 및 총 유출량(MB)입니다. 플러시 백분율- KV 스토어에서 모든 디스크 쓰기를 플러시하는 데 소요되는 시간(분)의 백분율입니다. 1에 가까울수 록 디스크 쓰기가 어렵거나 많은 양의 쓰기 작업이 지속적으로 수행되고 있음을 나타냅니다. 일부 OS에서는 60초보 다 빠르게 데이터를 플러시할 수 있습니다. 이러한 경우 이 숫자는 쓰기 병목 현상이 있더라도 작을 수 있습니다. 작업 수 - KV 스토어에 대해 실행한 작업 수입니다. 명령, 업데이트, 쿼리, 삭제, getmore, 삽입이 여기에 포함됩니다. 인트로스펙션 프로세스는 KV 스토어 통계를 전달하도록 명령을 보내므로 명령 카운터는 일반적으로 대부분의 작업보 다 높습니다. 현재 연결 수 - KV 스토어에 열려 있는 연결 수입니다. 총 대기열 수 - 잠금을 기다리는 대기열에 있는 총 작업 수입니다. 총 Assert(어설트) 수 - KV 스토어에서 발생한 총 Assert(어설트) 수입니다. 음수가 아닌 수는 KV 스토어 로그를 확인 할 필요가 있음을 나타냅니다. 이 절의 통계 중 많은 항목이 스냅샷 섹션에 있습니다. Historical 뷰는 시간 간격 집합의 메트릭에 대한 동향 정보를 나타냅 니다. 이러한 통계는 KVStoreServerStats에 수집됩니다. 기본적으로 Historical 패널은 지난 4시간 동안의 정보를 표시합 니다. 이 섹션에 있는 그래프의 모든 공백은 일반적으로 KV 스토어 또는 Splunk Enterprise가 연결할 수 없는 점을 나타냅니 다. 메모리 사용량 - 위 내용 참조 복제 지연. 기본 OpLog에 기록된 마지막 작업과 보조 노드에 적용된 마지막 작업 간의 시간 간격입니다. 기본 oplog 창을 초과하는 복제 지연으로 인해 데이터가 올바르게 복제 집합의 모든 노드에 복제되지 않을 수 있습니다. 복제 기능 이 없는 독립형 인스턴스에서 이 패널은 어떠한 결과도 반환하지 않습니다. 참고: 복제 지연은 _introspection 인덱스 의 KVStoreReplicaSetStats 구성 요소에 수집됩니다. 작업 수(분별 평균) - 위 내용 참조 이 패널은 개별 작업 유형(예를 들어, 명령, 업데이트, 삭제) 또는 모든 작업 유형을 보여줍니다. Assert(어설트) 수 - 위 내용 참조 이 패널을 통해 Assert(어설트) 유형(메시지, 정규, 롤오버, 사용자, 경고)에 기반하여 필터링을 수행할 수 있습니다. 잠금 백분율 - 위 내용 참조 잠금 유형별로 이 패널을 필터링할 수 있습니다. 읽기. 읽기 작업 잠김 쓰기. 쓰기 작업 잠김. KV 스토어 잠금은 "writer greedy"입니다. 쓰기 잠금은 컬렉션에 있는 총 잠금 수의 대부 분을 차지할 수 있습니다. 전역. 전역 시스템으로 인해 잠김. 컬렉션 수준을 구현하는 KV 스토어는 전역 잠금의 공격적인 사용에 대한 필요 성을 줄여줍니다. 전체 작업의 페이지 오류(백분율로 표시) - 위 내용 참조 네트워크 트래픽 - 위 내용 참조 이 패널에 추가된 항목은 KV 스토어에 대한 요청 수입니다. 시간에 따른 대기열. 다음 기준으로 구분된 대기열 수: 합계 - 위 내용 참조 읽기 - 읽기가 허용되기를 기다리는 읽기 작업 수 쓰기 - 쓰기가 허용되기를 기다리는 쓰기 작업 수 시간에 따른 연결 수 - 위 내용 참조 디스크 플러싱에 소요되는 각 분의 퍼센트 - 위 내용 참조 가장 느린 작업. 선택된 시간 범위에서 KV 스토어에 기록된 가장 느린 10개의 작업입니다. 모든 컬렉션에 대해 프로파 일링하는 경우 매우 느리게 작업을 실행하더라도 아무런 결과를 얻을 수 없습니다. collections.conf에서 컬렉션별로 프로파일링을 활성화하십시오. 71

72 이 뷰는 어디에서 데이터를 수집합니까? KV 스토어는 _introspection 인덱스에서 데이터를 수집합니다. 이러한 통계는 다음 구성 요소로 나뉩니다. KVStoreServerStats - KV 스토어 프로세스가 전체적으로 수행되는 방법에 대한 정보입니다 (KV 스토어 서버). 27초 간격으로 폴링됩니다. KVStoreCollectionStats - KV 스토어 내의 컬렉션에 대한 정보입니다. 10분 간격으로 폴링됩니다. KVStoreReplicaSetStats - KV 스토어 인스턴스의 복제 데이터에 대한 정보입니다. 60초 간격으로 폴링됩니다. KVProfilingStats - 느린 작업에 대한 정보입니다. 5초 간격으로 폴링되며, 프로파일링이 활성화된 경우에만 사용할 수 있습니다. 참고: 개발 시스템에서만 프로파일을 활성화하거나 기본 패널에서 사용 가능한 성능 이외의 KV 스토어 성 능 관련 문제를 해결하기 위해 프로파일을 활성화하십시오. 프로파일링은 시스템 성능에 부정적인 영향을 미칠 수 있 으므로 운영 중인 환경에서는 활성화하지 않아야 합니다. 또한 KV 스토어는 Splunk Enterprise에서 수집된 많은 내부 로그에서 항목을 생성합니다. 이 뷰에서 결과 해석 성능 표시기 및 빨간색 플래그에 대한 내용은 이 매뉴얼의 "KV 스토어: 배포"를 참조하십시오. 이 뷰 문제 해결 Historical 패널은 인트로스펙션 로그에서 데이터를 가져옵니다. 이 섹션에 있는 그래프의 시간 차이는 일반적으로 KV 스토 어 또는 Splunk Enterprise가 연결할 수 없는 점을 나타냅니다. 패널이 완전히 공백으로 표시되거나 특정 Splunk Enterprise 인스턴스에서 데이터를 누락한 경우 다음 항목을 확인하십시오. 인덱서에 인트로스펙션 로그를 포워딩하고 있는지 여부 플랫폼 계측에 필요한 시스템 요구 사항 KV 스토어: 배포 이 뷰에는 무엇이 표시됩니까? 분산 관리 콘솔(DMC)의 KV 스토어: 배포 뷰에서는 Splunk Enterprise 배포에서 모든 KV 스토어에 걸쳐 집계된 정보를 제 공합니다. 이 뷰에 포함될 인스턴스의 경우 해당 인스턴스는 KV 스토어의 서버 역할로 설정되어야 합니다. DMC 설정 페이 지에서 이를 수행하십시오. 이 뷰 및 KV 스토어: 인스턴스 뷰는 대부분 동일한 정보를 추적합니다. 이 배포 뷰는 KV 스토어에서 통계를 수집하고 다른 메트릭의 값을 기준으로 그룹화된 인스턴스를 표시하는 것이 다른 점입니다. 개별 대시보드 및 메트릭에 대한 정의 및 컨텍스트는 이 장의 "KV 스토어: 인스턴스"를 참조하십시오. 성능 메트릭 배포 스냅샷 배포 스냅샷 통계는 /services/server/introspection/kvstore/serverstatus REST endpoint에 액세스합니다. 배포에서 각 KV 스토어 인스턴스에 대해 배포 스냅샷은 다음 정보를 제공합니다. 인스턴스. Splunk Enterprise 인스턴스 이름입니다. 메모리 사용량 전체 대기 현재 연결 수 작업당 페이지 오류 잠금(%) 마지막 플러시(ms) 네트워크 트래픽(MB) 가동 시간(시간). 현재 인스턴스가 재시작 없이 실행되는 시간입니다. 복제 역할. 인스턴스가 복제 집합에서 수행하는 역할입니다. 인스턴스가 복제 집합의 부분이 아닌 경우 "N/A"가 반환 됩니다. 이 뷰는 어디에서 데이터를 수집합니까? 이 장의 "KV 스토어: 인스턴스"를 참조하십시오. "스냅샷"이 측정된 시간 범위는 언제입니까? 이 장의 "KV 스토어: 인스턴스"를 참조하십시오. 이 뷰 해석 72

73 패널 심각함 경고 보통 해석 작업 당 페이 지 오류 1.3 이상 읽기에 많은 양의 디스크 I/O가 필요합니다. 이는 더 많은 RAM이 필요함을 나 타낼 수 있습니다 읽기에 정 기적으로 디스크 I/O 가 필요합 니다 읽기에 디 스크 I/O가 거의 필요 하지 않습 니다. 읽기 요청이 Splunk Enterprise의 메모리에 있는 것으로 충 족되지 않는 빈도를 측정하고 Splunk Enterprise가 디스크 에 컨택하는 것을 요청합니다. 잠금 백분 율 네트 워크 트래 픽 복제 대기 시간 기본 작업 로그 윈도 우 플러 싱 비율 50% 이상 30% 50% 0 30% N/A N/A N/A >30초 10 30초 0 10초 N/A N/A N/A 50% 100% 10% 50% 0 10% 잠금 백분율이 높으면 복제가 필요하고 애플리케이션 호출 이 느려지고 시간이 초과되거나 실패할 수 있습니다. 잠금 백분율이 높으면 일반적으로 노드에서 많은 양의 쓰기 작 업이 실행되고 있음을 의미합니다. 네트워크 트래픽은 시스템 사용 및 애플리케이션 기대값에 비례해야 합니다. 기본 임계값이 적용되지 않습니다. 복제 필요성은 시스템에 따라 다릅니다. 일반적으로 복제 집합 구성원은 KV 캡틴 뒤에 현저히 감소하지 않아야 합니 다. 30초를 넘는 복제 대기 시간은 마운팅 복제 문제를 나 타낼 수 있습니다. 참조용으로 제공됩니다. 이는 시스템이 복원을 위해 작업 로그에 저장한 시간 측면에서의 데이터 양입니다. 높은 플러시 비율은 많은 양의 쓰기 작업 또는 시스템 성능 저하를 나타냅니다. 이 뷰 문제 해결 Historical 패널은 _introspection 및 _internal 인덱스에서 데이터를 가져옵니다. 이러한 패널의 시간 차이는 KV 스토어 또는 Splunk Enterprise가 연결할 수 없는 점을 나타냅니다. 패널이 완전히 공백으로 표시되거나 특정 Splunk Enterprise 인스턴 스에서 데이터를 누락한 경우 다음 항목을 확인하십시오. 인덱서에 로그를 포워딩하고 있는지 여부 플랫폼 계측에 필요한 시스템 요구 사항 라이선싱 분산 관리 콘솔(DMC)의 라이선싱 뷰에는 라이선스 사용량 보고서 뷰와 동일한 정보가 표시됩니다. 라이선스 마스터 대신 DMC를 통해 이 뷰에 액세스하면 배포에 여러 개의 라이선스 마스터가 있는 경우 보려는 라이선스 마스터 정보를 DMC 뷰 에서 선택할 수 있다는 장점이 있습니다. 이 뷰의 정보에 대한 자세한 내용은 이 매뉴얼의 "Splunk Enterprise 라이선스 사용량 보고서 뷰에 대하여"를 참조하십시오. 앱 key value 스토어 관리 앱 key value 스토어에 대하여 앱 key value 스토어(또는 KV 스토어)에서는 Splunk 앱 내에서 데이터를 저장하고 검색하는 방법을 제공하여 애플리케이션 의 상태를 관리하고 유지할 수 있습니다. Splunk 앱에서 KV 스토어를 사용할 수 있는 방법은 다음과 같습니다. 하나의 사용자에서 다른 사용자로 문제를 이동시키는 인시던트-리뷰 시스템의 워크플로 추적 사용자가 제공한 환경 자산 리스트 유지 작업 대기열 제어 사용자가 앱과 상호작용할 때 사용자 또는 애플리케이션 상태를 저장하여 UI 세션 관리 사용자 메타데이터 저장 Splunk 또는 외부 데이터 저장소별 검색 쿼리에서 결과 캐싱 모듈러 입력에 대한 체크포인트 데이터 저장 KV 스토어 사용에 대한 자세한 내용은 Splunk 앱 개발자용 앱 key value 스토어 설명서를 참조하십시오. KV 스토어가 배포에서 작동하는 방법 73

74 KV 스토어는 데이터를 컬렉션에서 키 값 쌍으로 저장합니다. 주요 개념은 다음과 같습니다. 컬렉션은 데이터베이스 테이블과 유사한 데이터용 컨테이너이며 제공된 앱의 컨텍스트 내에 있습니다. 레코드에는 데이터베이스 테이블의 행과 유사한 데이터의 각 항목이 포함됩니다. 필드는 데이터베이스 테이블의 컬럼과 유사한 키 이름에 해당하며 데이터 값을 JSON 파일로 포함합니다. 이것이 필 요하지 않더라도 필드 값에 대한 데이터 유형(숫자, 부울, 시간 및 문자열)을 강제 적용할 수 있습니다. _key는 각 레코드에 대해 고유한 ID를 포함하는 예약된 필드입니다. _key 값을 명시적으로 지정하지 않는 경우 앱은 _key 값을 자동 생성합니다. _user는 각 레코드에 대한 사용자 ID를 포함하는 예약된 필드입니다. 이 필드는 재정의될 수 없습니다. 가속화는 가속화된 필드를 포함하는 검색을 더 빨리 반환하도록 하여 검색 성능을 향상시킵니다. 가속화는 컬렉션의 데이터 집합 중 일부분을 쉽게 트래버스할 수 있는 양식에 저장합니다. KV 스토어 파일은 검색 헤드에 위치합니다. 검색 헤드 클러스터에서 임의의 노드가 쓰기를 수신하는 경우 KV 스토어는 KV 스토어 캡틴에 쓰기를 위임합니다. 그러나 KV 스토어는 읽기를 로컬로 유지합니다. 시스템 요구 사항 KV 스토어는 모든 Splunk Enterprise 64비트 빌드에서 사용 가능 및 지원되며 32비트 Splunk Enterprise 빌드에서는 사용 할 수 없습니다. KV 스토어는 또한 유니버설 포워더에서 사용할 수 없습니다. Splunk Enterprise 시스템 요구 사항을 참조하 십시오. 기본적으로 KV 스토어는 8191 포트를 사용합니다. 분산 검색 매뉴얼의 "검색 헤드 클러스터에 대한 시스템 요구 사항 및 기 타 배포 고려 사항"을 참조하십시오. 앱의 KV 스토어 사용 여부 결정 KV 스토어는 기본적으로 Splunk Enterprise 6.2+에서 사용할 수 있습니다. KV 스토어를 사용하는 앱은 일반적으로 $SPLUNK_HOME/etc/apps/<app name>/default에서 정의된 collections.conf가 있습니 다. 또한 transforms.conf에는 external_type = kvstore인 컬렉션에 대한 참조가 있습니다. KV 스토어 사용 KV 스토어를 사용하려면 다음을 수행하십시오. 1. 컬렉션을 만들고 설정 파일 또는 REST API를 사용하여 데이터 유형이 있는 필드 리스트를 선택적으로 정의합니다. 2. 검색 룩업 명령어 및 Splunk REST API를 사용하여 작성-읽기-업데이트-삭제(CRUD) 작업을 수행합니다. 3. REST API를 사용하여 컬렉션을 관리합니다. Splunk Enterprise 배포에서 해당 효과를 모니터링하는 방법과 이유 분산 관리 콘솔에서 두 개의 뷰를 통해 KV 스토어 성능을 모니터링할 수 있습니다. 하나의 뷰에서는 전체 배포 환경(이 매뉴 얼의 "KV 스토어: 배포" 참조)에 대한 통찰력을 제공합니다. 다른 뷰에서는 각 검색 헤드("KV 스토어: 인스턴스" 참조)의 KV 스토어 작업에 대한 정보를 제공합니다. 데이터 백업 방법 표준 백업 및 복원 도구와 조직에서 사용된 절차를 사용하여 KV 스토어 데이터를 백업하고 복원합니다. KV 스토어 데이터를 백업하려면 server.conf 파일에 있는 [kvstore] 스탠자의 dbpath 매개 변수에 지정된 경로에 모든 파일을 백업합니다. Splunk Enterprise의 백업 전략에 대한 일반적인 내용은 인덱서 및 인덱서 클러스터 관리 매뉴얼의 "백업 전략 선택"을 참조 하십시오. Splunk 앱 정보 앱 및 추가 기능 정의 Splunk를 설치하고 처음 로그인하면 Splunk 홈으로 이동합니다. 이 인터페이스에는 Getting Started 앱과 검색 앱을 포함한 사전 설치된 앱이 표시됩니다. 사용자가 생성한 앱과 추가 기능을 설치하고 개발할 수도 있습니다. 앱 앱은 특정 비즈니스 요구를 지원하거나 특정 사용 사례나 문제를 해결하기 위해 사용하는 대시보드, 뷰 및 검색의 집합입니 다. 앱에는 고급 데이터 컬렉션에 대한 추가 기능을 통합할 수 있는 기능이 포함되어 있습니다. 앱을 사용하려면 일부 설정을 변경해야 할 수 있으며 앱을 필요에 따라 사용자 지정할 수 있습니다. 그러나 일반적으로 앱의 콘텐츠는 미리 지정된 설정이나 데이터 유형과 함께 "즉시" 사용할 수 있습니다. 앱의 예로는 Splunk App for Enterprise 74

75 Security, Splunk App for VMware, Splunk 배포 모니터 앱 및 Splunk App for Microsoft Exchange 등이 있습니다. Splunk를 사용할 경우 대부분 앱을 항상 사용하며, 일반적으로 앱 "내부"에 있는 것으로 참조합니다. 기본 앱은 검색 앱입니 다. 추가 기능 추가 기능은 데이터 피드, 모듈식 입력, 스크립트, 또는 기타 데이터 컬렉션 메커니즘을 말합니다. 추가 기능의 예로는 Splunk Add-on for Checkpoint OPSEC LEA, Splunk Add-on for Rapid7 Metasploit, 그리고 Splunk Add-on for Riverbed Stingray Application Firewall 등이 있습니다. 앱 및 추가 기능을 이용해서 단일 Splunk 인스턴스 위에 서로 다른 환경을 구축할 수 있습니다. 조직 내 다른 Splunk 사용자 커뮤니티를 위한 개별 인터페이스를 만들 수 있습니다. 예를 들어 단일 Splunk 인스턴스에 다음 항목들이 있을 수 있습니다. 이메일 서버의 웹 분석 문제를 해결하는 앱 일선 지원 팀이 사용할 룩업 테이블을 연결하는 추가 기능 이렇게 하면 모든 사용자가 동일한 Splunk 인스턴스를 사용하지만 각자 관심 있는 관련 데이터와 도구만 볼 수 있습니다. 추가 기능은 몇 가지 일반적인 범주로 분류됩니다. 도메인 추가 기능 일부 앱에는 도메인에 대한 대시보드와 뷰를 제공합니다. 지원되는 추가 기능 도메인 추가 기능에서 저장된 검색 및 매크로처럼 모듈과 도구들을 제공합니다. 기타 추가 기능 이 추가 기능들은 별도의 source에서 가져온 데이터를 활용할 수 있도록 도움을 줍니다. 예: 맵핑 정보. 기본 검색 앱 Splunk를 처음 설치하고 로그인하면 Splunk 홈으로 이동합니다. 홈 페이지는 자동으로 미리 설치된 앱에 앱 클릭(Click on Apps)을 표시합니다. 기본적으로 Splunk는 검색 및 보고 앱을 제공합니다. 이 인터페이스는 Splunk의 핵심 기능을 제공하며, 일반적인 용도에 사 용되도록 설계되었습니다. 이 앱은 처음 로그인할 때 홈 페이지 상단에 표시되고, 즉시 사용할 수 있도록 검색 필드를 제공합 니다. (홈 페이지에서 검색을 실행하거나 앱을 클릭하여) 검색 및 보고 앱으로 이동하면 메뉴 모음 옵션을 사용하여 다음 항목을 선 택할 수 있습니다. 검색: 인덱스를 검색합니다. 자세한 내용은 검색 튜토리얼에서 "Splunk 검색 사용"을 참조하십시오. 피벗: 데이터 모델을 사용하여 데이터에 대한 테이블, 차트 및 시각화 자료를 빠르게 설계하고 생성합니다. 자세한 내 용은 피벗 매뉴얼을 참조하십시오. 보고서: 검색을 보고서로 변환합니다. 자세한 내용은 검색 튜토리얼에서 "보고서 저장 및 공유"를 참조하십시오. 경고: Splunk 검색 및 보고서에 대한 경고를 설정합니다. 자세한 내용은 경고 매뉴얼을 참조하십시오. 대시보드: 미리 정의된 대시보드를 사용하거나 대시보드를 직접 만듭니다. 대시보드 및 시각화 매뉴얼을 참조하십시 오. 앱에서 열리도록 Splunk Web 설정 75

76 Splunk Web이 Splunk 홈이 아닌 선택한 앱에서 열리도록 설정할 수 있습니다. 모든 사용자가 Splunk Web을 특정 앱에서 열 수 있도록 하거나 특정 사용자만 Splunk Web을 앱에서 열 수 있도록 지정할 수 있습니다. 단일 사용자에 대해 Splunk 홈 무시 사용자가 로그인하면 Splunk 홈이 아닌 선택한 앱으로 직접 이동하도록 Splunk Web을 설정할 수 있습니다. 검색 앱을 기본 시작 앱으로 설정하려면: 1. 사용자의 로컬 디렉터리에 user-prefs.conf 파일을 만듭니다. etc/users/<user>/user-prefs/local/user-prefs.conf admin 사용자인 경우 다음 위치에 이 파일이 생성됩니다. etc/users/admin/user-prefs/local/user-prefs.conf test 사용자인 경우 다음 위치에 이 파일이 생성됩니다. etc/users/test/user-prefs/local/user-prefs.conf 2. user-prefs.conf 파일에 다음 줄을 입력합니다. default_namespace = search 모든 사용자에 대해 Splunk 홈을 건너뜀 로그인하면 처음 표시되는 모든 사용자용 기본 앱을 지정할 수 있습니다. 예를 들어, 검색 앱을 전역 기본값으로 지정하려면 $SPLUNK_HOME/etc/apps/user-prefs/local/user-prefs.conf를 편집 및 지정하십시오. [general_default] default_namespace = search 참고: 검색 앱에 액세스할 수 있는 권한이 없는 사용자에게는 오류가 표시됩니다. 더 많은 앱과 추가 기능 찾기 새 앱과 추가 기능은 찾을 수 있습니다. Splunk 사용자 메뉴 모음에서 Splunk 앱에 액세스하고 Splunk에서 앱을 직접 다운로드하거나 설치할 수 있습니다. 앱 메뉴 를 클릭하고 추가 앱 찾기를 선택하십시오. Splunk Web에 로그인하면 기본적으로 Splunk 홈이 표시됩니다. 페이지 상단(왼쪽)에서 Splunk 로고를 클릭하여 언제든지 Splunk 홈으로 돌아갈 수 있습니다. 인터넷에 연결된 경우 Splunk 서버 또는 클라이언트 컴퓨터가 인터넷에 연결되어 있으면 Splunk 홈에서 앱과 추가 기능을 직접 다운로드할 수 있 습니다. 1. 사용자 메뉴 모음에서 앱 메뉴를 클릭하고 추가 앱 찾기를 선택합니다. 2. 앱 및 추가 기능 리스트에서 원하는 앱이나 추가 기능을 선택한 다음 앱 다운로드를 선택합니다. 76

77 3. splunk.com 사용자 이름과 암호(사용자의 Splunk 사용자 이름/암호가 아님)로 splunk.com에 로그인하라는 메시지가 나 타납니다. 4. 선택한 항목이 설치됩니다. Web GUI 구성 요소(대부분의 추가 기능에는 event type 정의와 같은 knowledge 객체만 포함 되고 GUI 컨텍스트는 없음)가 있는 경우에는 Splunk 홈에서 이 구성 요소로 이동할 수 있습니다. 중요: Splunk Web이 프록시 서버 뒤에 있을 경우 Splunk 앱에 액세스할 때 문제가 발생할 수 있습니다. 이 문제를 해결하려 면 "프록시 서버 지정"에서 설명한 대로 http_proxy 환경 변수를 설정해야 합니다. 인터넷에 연결되지 않은 경우 Splunk 서버 및 클라이언트가 인터넷에 연결되어 있지 않은 경우 Splunk 앱 페이지에서 앱을 다운로드하여 서버에 복사해야 합니다. 1. 인터넷에 연결된 컴퓨터에서 원하는 앱 또는 추가 기능을 Splunk 앱에서 찾아봅니다. 앱을 보려면 페이지 상단의 찾아보 기를 클릭합니다. 추가 기능을 찾으려면 사이드바에서 추가 기능을 콘텐츠 유형으로 선택합니다. 2. 앱 또는 추가 기능을 다운로드합니다. 3. 다운로드한 앱 또는 추가 기능을 Splunk 서버에 복사합니다. 4. 해당 앱 또는 추가 기능을 $SPLUNK_HOME/etc/apps 디렉터리에 저장합니다. 5. tar -xvf(*nix의 경우) 또는 WinZip(Windows의 경우)과 같은 도구를 사용하여 앱 또는 추가 기능 파일의 압축을 풉니다. Splunk 앱 및 추가 기능은 tar 및 gzip을 사용할 경우에도.SPL 확장자로 압축됩니다. 사용자의 도구가 이 확장자를 인식할 수 있도록 설정해야 할 수도 있습니다. 6. 앱 또는 추가 기능의 내용에 따라 Splunk를 재시작해야 할 경우가 있습니다. 7. 앱 또는 추가 기능이 설치되었으며 Splunk 홈(웹 UI 구성 요소가 있는 경우)에서 사용할 수 있습니다. 77

78 앱 아키텍처 및 개체 소유권 앱은 일반적으로 Splunk knowledge 객체를 사용하여 제작됩니다. Splunk knowledge 객체에는 Splunk 배포를 풍부하게 해주는 데이터 유형, 예를 들어 저장된 검색, event type, 태그 등의 개체가 포함되며, 사용자가 필요로 하는 것을 쉽게 알 수 있게 해줍니다. 참고: 개체를 추가 기능에 저장할 수는 있지만, 일반적인 방법은 아닙니다. 앱과 추가 기능은 모두 앱 디렉터리에 저장됩니 다. 드물지만 개체를 추가 기능에 저장해야 할 경우에는 추가 기능을 이 항목에서 설명하는 앱 관리 방법과 동일하게 관리합 니다. Splunk Web에 로그인한 사용자는 (필요한 권한이 있다고 가정할 경우) 사용자가 "위치한" 앱의 사용자 디렉터리에 knowledge 객체를 만들고 저장할 수 있습니다. 이것은 사용자가 개체를 저장할 때마다 발생하는 기본 동작으로, 현재 실행 중인 앱의 사용자 디렉터리에 적용됩니다. 사용자 디렉터리는$SPLUNK_HOME/etc/users/<user_name>/<app_name>/local에 있습 니다. 사용자가 앱에 개체를 저장하면 이 개체는 해당 앱에 있는 사용자만 사용할 수 있습니다. 다른 사용자도 사용할 수 있게 하려면 다음 작업 중 하나를 수행해야 합니다. 액세스 권한이 있는 모든 사용자가 사용할 수 있도록 개체 승격 개체를 (여전히 앱 컨텍스트에 있는) 특정 역할 또는 사용자로 제한 모든 앱 및 추가 기능과 사용자가 사용할 수 있도록 개체를 전역으로 표시(역할/사용자별로 분명히 제한하지 않은 경 우) 참고: 사용자가 개체를 해당 수준으로 승격하려면 앱 또는 추가 기능에 대한 쓰기 권한이 있어야 합니다. Splunk knowledge 승격 및 공유 사용자는 권한 대화 상자를 통해 다른 사용자와 Splunk knowledge 객체를 공유할 수 있습니다. 즉, 앱 또는 추가 기능에서 읽기 권한을 갖고 있는 사용자는 공유 개체를 보거나 사용할 수 있습니다. 예를 들어, 사용자가 저장된 검색을 공유할 경우 다 른 사용자도 이 저장된 검색을 볼 수 있지만 해당 검색이 생성된 앱 내에서만 볼 수 있습니다. "Fflanda" 앱에서 저장된 검색 을 만들고 이 검색을 공유할 경우 Fflanda에 대한 읽기 권한이 있는 다른 사용자는 이 저장된 검색을 볼 수 있습니다. 쓰기 권한이 있는 사용자는 개체를 앱 수준으로 승격할 수 있습니다. 즉, 사용자 디렉터리에서 앱 디렉터리로 개체가 복사됩 니다. 원본 위치: $SPLUNK_HOME/etc/users/<user_name>/<app_name>/local/ 대상 위치: $SPLUNK_HOME/etc/apps/<app_name>/local/ 사용자에게 앱에 쓰기 권한이 있는 경우에만 이 작업을 수행할 수 있습니다. Splunk knowledge 객체 전역 설정 마지막으로, 승격 시 사용자는 개체를 전역으로 사용할지 여부를 결정할 수 있습니다. 전역으로 설정하면 모든 앱에서 해당 개체를 볼 수 있습니다. 다시 말하면 이 작업을 수행하려면 사용자에게 원본 앱에 대한 쓰기 권한이 있어야 합니다. Splunk Web에서 이 작업을 수행하는 것이 가장 쉽지만, 원하는 디렉터리로 관련 개체를 이동하여 나중에 이 작업을 수행할 수도 있 습니다. 앱 "D"에서 사용자 "C"에 속한 개체 "A"("B.conf"에 정의됨)를 전역으로 설정하려면: 1. 개체 A를 정의하는 스탠자를 $SPLUNK_HOME/etc/users/C/D/B.conf에서 $SPLUNK_HOME/etc/apps/D/local/B.conf로 이동합니 다. 2. 앱의 local.meta 파일에 있는 개체 A의 스탠자에 export = system 설정을 추가합니다. 개체의 스탠자가 아직 없는 경우에 는 하나를 추가할 수 있습니다. 예를 들어, *Nix 앱에서 "fflanda" 이름의 사용자가 생성한 event type "rhallen"을 전역으로 사용할 수 있게 승격하려면 다음 작업을 수행하십시오. 1. $SPLUNK_HOME/etc/users/fflanda/unix/local/eventtypes.conf에서 $SPLUNK_HOME/etc/apps/unix/local/eventtypes.conf로 [rhallen] 스탠자를 이동합니다. 2. 다음 스탠자를 추가합니다. [eventtypes/rhallen] export = system 대상 위치: $SPLUNK_HOME/etc/apps/unix/metadata/local.meta 참고: 기본적으로 모든 이벤트를 전역으로 내보내기 때문에 검색 앱에서 event type을 공유할 때 export = system 설정을 local.meta에 추가할 필요가 없습니다. 적용되는 개체 78

79 여기서 설명하는 knowledge 객체는 액세스 제어에 따라 제한됩니다. knowledge 객체는 앱 수준 개체라고도 하며 사용자 메 뉴 모음에서 앱 > 앱 관리를 선택하여 볼 수 있습니다. 이 페이지는 생성 및 공유된 개체를 관리하는 모든 사용자에게 제공됩 니다. 이러한 개체에는 다음이 포함됩니다. 저장된 검색 및 보고서 Event type 뷰 및 대시보드 필드 추출 그리고 관리 권한(특정 개체에 대한 읽기/쓰기 권한)을 가진 사용자만 사용할 수 있는 시스템 수준개체가 있습니다. 이러한 개체에는 다음이 포함됩니다. 사용자 역할 인증 분산 검색 입력 출력 배포 라이선스 서버 설정(예: 호스트 이름, 포트 등) 중요: 입력을 추가하면 Splunk가 실행 중인 앱에 속하는 inputs.conf의 복사본에 해당 입력을 추가합니다. 즉, 검색에서 앱으 로 바로 이동한 경우에는 입력이 $SPLUNK_HOME/etc/apps/search/local/inputs.conf에 추가되는 원치 않는 동작이 실행될 수 있습니다. 앱 설정 및 knowledge 우선 순위 Splunk에 knowledge를 추가하면 knowledge를 추가할 때 사용자가 위치한 앱의 컨텍스트에 knowledge가 추가됩니다. Splunk가 설정 및 knowledge를 평가할 때는 어떤 컨텍스트에서 어떤 knowledge 정의와 설정이 사용되는지 제어할 수 있도 록 특정 우선 순위에 따라 설정과 knowledge를 평가합니다. Splunk 설정 파일과 우선 순위에 대한 자세한 내용은 "설정 파일 에 대하여"를 참조하십시오. 앱 및 추가 기능 개체 관리 Splunk 사용자가 앱 또는 추가 기능을 만든 경우 앱 또는 추가 기능을 구성하는 개체 컬렉션이 생성됩니다. 이러한 개체에는 뷰, 명령, 탐색 항목, event type, 저장된 검색, 보고서 등이 포함될 수 있습니다. 이러한 각 개체에는 개체를 보거나 변경할 수 있는 사용자를 결정하기 위한 개체와 연결된 권한이 있습니다. 기본적으로 관리자에게는 Splunk 시스템의 모든 개체를 바 꿀 수 있는 권한이 있습니다. 자세한 내용은 다음 항목을 참조하십시오. 앱 및 추가 기능에 대한 개요는 이 매뉴얼의 "앱 및 추가 기능 정의"를 참조하십시오. 앱 및 추가 기능 권한에 대한 자세한 내용은 이 매뉴얼의 "앱 아키텍처 및 개체 소유권"을 참조하십시오. 앱 및 추가 기능을 직접 만드는 방법에 대해 자세히 알아보려면 Splunk Web용 뷰 및 앱 개발 매뉴얼을 참조하십시오. Splunk Web에서 앱/추가 기능 개체 보기 및 관리 Splunk를 배포할 때 다음과 같은 방법으로 Splunk Web을 사용하여 개체를 볼 수 있습니다. 시스템의 모든 앱/추가 기능에 대한 개체를 모두 보려면 설정 > 모든 설정을 선택합니다. 저장된 검색 및 보고서 개체를 모두 보려면 설정 > 검색 및 보고서를 선택합니다. 모든 event type을 보려면 설정 > Event type을 선택합니다. 모든 필드 추출을 보려면 설정 > 필드를 선택합니다. 다음 작업을 수행할 수 있습니다. 정렬 화살표 뷰를 선별하여 앱 컨텍스트 창에서 지정한 앱 또는 추가 기능의 개체, 특정 사용자가 소유한 개체 또는 특정 문자열을 포함하는 개체만 볼 수 있습니다. 앱 컨텍스트 창의 검색 필드를 사용하여 필드 문자열을 검색합니다. 기본적으로 Splunk는 사용 가능한 모든 필드의 문자열을 검색합니다. 특정 필드 내에서 검색하려면 필드를 지정하십시오. 와일드카드가 지원됩니다. 참고: 검색 명령어 페이지에서 개별 검색 명령어에 대한 자세한 내용은 검색 참조 매뉴얼을 참조하십시오. CLI에서 앱 또는 추가 기능 업데이트 CLI를 사용하여 Splunk 인스턴스에서 기존 앱을 업데이트하려면:./splunk install app <app_package_filename> -update 1 -auth <username>:<password> Splunk는 설치 패키지에 있는 정보를 기준으로 앱 또는 추가 기능을 업데이트합니다. 79

80 CLI를 사용한 앱 또는 추가 기능 비활성화 CLI를 통해 앱을 비활성화하려면:./splunk disable app [app_name] -auth <username>:<password> 참고: Splunk Free를 실행할 경우 사용자 이름과 암호를 제공할 필요가 없습니다. 앱 또는 추가 기능 제거 Splunk 설치에서 설치된 앱을 제거하려면: 1. (선택 사항) 앱 또는 추가 기능의 인덱스 데이터를 제거합니다. 일반적으로 Splunk는 삭제된 앱 또는 추가 기능에서 인덱 스 데이터에 액세스하지 않습니다. 그러나 앱을 삭제하기 전에 Splunk CLI 정리 명령어를 사용하여 앱에서 인덱스된 데이터 를 제거할 수 있습니다. CLI 명령을 사용하여 인덱스에서 데이터 제거를 참조하십시오. 2. 앱과 앱 디렉터리를 삭제합니다. 디렉터리 위치는 $SPLUNK_HOME/etc/apps/<appname>입니다. CLI에서 다음 명령을 실행할 수 있습니다../splunk remove app [appname] -auth <username>:<password> 3. 다음 위치에 파일이 있을 경우 해당 파일을 삭제하여 앱 또는 추가 기능에 대해 생성된 사용자별 디렉터리를 제거해야 할 수 있습니다. $SPLUNK_HOME/splunk/etc/users/*/<appname> 4. Splunk를 재시작합니다. 앱 및 추가 기능의 설정 및 속성 관리 앱 메뉴에서 Splunk 인스턴스에 설치된 앱의 설정 및 속성을 관리할 수 있습니다. 사용자 메뉴 모음에서 앱을 클릭하여 설치 된 앱 중 하나를 선택하거나 앱을 관리하십시오. 앱 관리 페이지에서 다음 작업을 수행할 수 있습니다. 앱 또는 추가 기능에 대한 권한 편집 앱 또는 추가 기능 활성화 또는 비활성화 앱 실행, 속성 편집 및 앱 개체 보기와 같은 작업 수행 앱 및 추가 기능의 속성 편집 앱의 소유자인지 사용자인지 여부에 따라 설정 또는 속성에서 편집할 수 있는 내용이 달라집니다. 앱 > 앱 관리를 선택한 다음 편집할 앱 또는 추가 기능에 대해 속성 편집을 클릭하십시오. Splunk 인스턴스에 설치된 앱의 다 음 요소를 편집할 수 있습니다. 이름: Splunk Web에서 앱 또는 추가 기능의 표시 이름을 변경합니다. 업데이트 확인: 업데이트 확인은 기본적으로 활성화되어 있습니다. 기본값을 재정의하고 업데이트 확인을 비활성화할 수 있습니다. 자세한 내용은 아래 앱 및 추가 기능 업데이트 확인을 참조하십시오. 표시 여부: 뷰가 있는 앱을 볼 수 있습니다. 대부분 뷰가 없는 추가 기능의 표시 여부 속성은 비활성화해야 합니다. 자산 업로드: 앱 또는 추가 기능에서 액세스할 수 있는 HTML, JavaScript 또는 CSS 파일과 같은 로컬 파일 자산 파일 을 이 필드에서 선택할 수 있습니다. 이 패널에서 한 번에 하나의 파일만 업로드할 수 있습니다. 앱 및 추가 기능 참조: 앱 및 추가 기능의 설정 및 속성 정보에 대한 설명을 제공합니다. 80

81 앱 및 추가 기능 참조: 앱 및 추가 기능의 설정 및 속성 정보에 대한 설명을 제공합니다. 업데이트 확인 Splunk 4.2부터 Splunk 앱이 앱 또는 추가 기능 업데이트를 확인할지 여부를 설정할 수 있습니다. 기본적으로 업데이트 확인 기능은 활성화되어 있습니다. 설정 > 앱 > 속성 편집에서 이 속성을 편집하여 앱의 업데이트 확인을 비활성화할 수 있습니다. 그러나 Splunk Web에서 이 속성을 사용할 수 없는 경우, 앱의 app.conf 파일을 수동으로 편집하여 업데이트 확인을 비활성 화할 수도 있습니다. 업데이트 확인을 비활성화하려면 $SPLUNK_HOME/etc/apps/<app_name>/local/app.conf에서 다음 스탠자를 만들거나 편집하십시오. [package] check_for_updates = 0 참고: app.conf의 로컬 버전(기본 버전이 아님)을 편집하십시오. 이렇게 하면 앱의 다음 업데이트로 현재 설정이 덮어쓰기되 지 않습니다. Hunk 정보 Hunk 정보 Hunk에서는 Splunk가 Hadoop에 상주하는 데이터에 대해 기본적으로 보고할 수 있도록 원격 HDFS 데이터 저장소를 가상 인덱스로 설정할 수 있습니다. 가상 인덱스를 적절하게 설정하면 원격 Hadoop 데이터 저장소에 상주하는 데이터를 보고서 화하고 시각화할 수 있습니다. 다음 링크는 Hunk 사용자 매뉴얼의 각 항목으로 연결됩니다. Hunk 매뉴얼 소개 Hunk 개념 Hunk 정보 Hunk 6.1의 새로운 기능 FAQ 자세히 알아보고 도움 받기 가상 인덱스에 대하여 외부 데이터 제공에 대하여 스트리밍 형태의 자원에 대한 라이브러리에 대하여 Splunk가 Hadoop 데이터에 대한 보고서를 반환하는 방법 통과 인증에 대하여 Hunk의 설치 Hunk의 설치 및 설정에 대하여 시스템 및 소프트웨어 요구 사항 Splunk의 다운로드 및 설치 Hunk 업그레이드 Splunk 시작 Hunk 라이선스 Hunk와 Splunk를 함께 사용 Hunk의 제거 Hunk Amazon Machine Image를 이용하여 Hunk 다운로드 설정 파일을 활용한 Hunk 관리 Splunk 검색 헤드 인스턴스 설정 설정 파일에서 공급자와 가상 인덱스의 설정 스트리밍 라이브러리 설정 sourcetype의 추가 하이브 데이터 관리 하이브 프리프로세서 설정 Parquet용 하이브 프리프로세서 설정 보고서를 다른 사용자가 실행하게 하기 위한 Hunk 설정 보고서 가속화 설정 통과 인증 설정 Kerberos 인증 설정 사용자 인터페이스에서 Hunk에 대한 관리 Hunk 사용자 인터페이스에 대하여 HDFS 공급자의 추가 또는 편집 가상 인덱스의 추가 또는 편집 통과 인증 설정 81

82 가상 인덱스 검색 참조 가상 인덱스에 검색 명령어 사용 보고서 가속화에 대한 작업 Hunk 문제 해결 우수 사례에서의 성능 설정 변수에 대한 제공 YARN에 필요한 설정 변수 REST API 조회 공급자 인덱스 릴리스 노트 튜토리얼 알려진 문제 Hunk 튜토리얼 소개 1단계: Hadoop 가상 머신 인스턴스 설정 2단계: 데이터 설정 3단계: Hunk 액세스용 HDFS 디렉터리 설정 4단계: Hunk 설치 및 라이선스 5단계: HDFS 공급자 설정 6단계: 가상 인덱스 설정 7단계: 간단한 데이터 검색 실습 8단계: 보고서 저장 자세히 알아보기 사용자 관리 사용자 및 역할에 대하여 Splunk Enterprise를 실행할 경우 암호와 함께 사용자를 만들고 이 사용자에게 역할을 할당할 수 있습니다. Splunk Free는 사용자 인증을 지원하지 않습니다. Splunk에는 단일 기본 사용자인 admin 사용자가 포함되어 있습니다. admin 사용자의 기본 암호는 changeme입니다. 이 암호는 Splunk를 설치한 후에 바로 변경해야 합니다. 사용자 만들기 Splunk는 세 가지 유형의 인증 시스템에 대한 지원을 제공하며, 보안 매뉴얼에서 이 내용에 대해 설명합니다. Splunk 기본 제공 시스템. 자세한 내용은 "Splunk 기본 제공 시스템을 통한 사용자 인증에 대하여"를 참조하십시오. LDAP. Splunk는 내부 인증 서비스 또는 기존 LDAP 서버를 이용한 인증을 지원합니다. 자세한 내용은 "LDAP를 사용 하여 사용자 인증 설정"을 참조하십시오. 스크립트 기반 인증 API. 스크립트 기반 인증을 사용하여 Splunk 인증을 RADIUS, PAM과 같은 외부 인증 시스템과 연결합니다. 자세한 내용은 "외부 시스템을 사용하여 사용자 인증 설정"을 참조하십시오. 역할에 대하여 사용자마다 역할이 할당되고, 역할에는 기능 집합이 포함됩니다. 기능은 역할에 해당하는 작업을 지정합니다. 예를 들어, 기 능은 특정 역할을 가진 사용자에게 입력 추가 또는 저장된 검색 편집을 허용할지 여부를 결정합니다. Splunk Enterprise 보 안 매뉴얼의 "기능을 가진 역할 정의에 대하여"에 다양한 기능이 나열되어 있습니다. 기본적으로 Splunk는 다음 역할이 미리 정의된 상태로 제공됩니다. admin -- 관리자에게 할당되는 대부분의 기능을 가집니다. power -- 모든 공유 개체(저장된 검색 등)와 경고, 태그 이벤트 및 기타 유사한 작업을 편집할 수 있습니다. user -- 자체 소유한 저장된 검색을 만들거나 편집할 수 있고, 검색을 실행할 수 있으며, 자체 기본 설정을 편집할 수 있 고, event type을 만들거나 편집할 수 있으며 기타 유사한 작업을 수행할 수 있습니다. 역할과 역할에 사용자를 할당하는 방법은 보안 매뉴얼의 "사용자 및 역할 기반 액세스 제어" 장을 참조하십시오. 기존 사용자 및 역할 찾기 82

83 Splunk Web에서 기존 사용자 또는 역할을 찾으려면 설정 >액세스 제어를 선택하여 액세스 제어 섹션에서 사용자 또는 역할 페이지의 상단에 있는 검색란을 사용하십시오. 와일드카드가 지원됩니다. 기본적으로 Splunk는 사용 가능한 모든 필드에 입 력된 문자열을 검색합니다. 특정 필드를 검색하려면 필드를 지정하십시오. 예를 들어, 이메일 주소만 검색하려면 " =< address or address fragment>:를 입력하십시오. 또는 "이름" 필드만 검색하려면 "realname=<name or name fragment>를 입력하십시오. 지정된 역할의 사용자를 검색하려면 "roles="를 사용하십시오. 사용자 언어 및 로케일 설정 사용자가 로그인하면 Splunk는 자동으로 사용자의 브라우저에 설정된 언어를 사용합니다. 언어를 바꾸려면 브라우저의 로 케일 설정을 변경하십시오. 로케일 설정은 브라우저와 관련되어 있습니다. Splunk는 로케일 문자열을 탐지합니다. 로케일 문자열은 언어 지정자와 현지화 지정자의 두 가지 요소로 구성됩니다. 이것은 일반적으로 두 개의 소문자와 두 개의 대문자를 밑줄로 연결하여 표시합니다. 예를 들어, "en_us"는 미국 영어를 의미하고, "en_gb"는 영국 영어를 의미합니다. 국가마다 날짜, 시간, 숫자 엔터티의 형식 지정에 다른 표준을 사용하므로 사용자의 로케일은 날짜, 시간, 숫자 등의 형식에도 영향을 미칩니다. Splunk는 이러한 로케일에 대해 기본적인 지원을 제공합니다. en_gb en_us ja_jp zh_cn zh_tw 추가 언어에 대한 현지화를 추가하려면 개발자 매뉴얼의 "Splunk 번역"을 참조하십시오. 그런 다음 사용자의 브라우저에서 적합한 로케일을 지정하도록 할 수 있습니다. 브라우저 로케일이 타임스탬프 형식 지정에 미치는 영향 기본적으로 Splunk의 타임스탬프 형식은 브라우저 로케일에 따라 결정됩니다. 브라우저가 미국 영어로 설정된 경우 타임스 탬프는 다음과 같이 미국 방식으로 표시됩니다. MM/DD/YYYY:HH:MM:SS. 브라우저가 영국 영어로 설정된 경우 타임스탬프는 다 음과 같이 유럽 날짜 표기 방식으로 표시됩니다. DD/MM/YYYY:HH:MM:SS. 타임스탬프 형식 지정에 대한 자세한 내용은 데이터 가져오기 매뉴얼의 "타임스탬프 인식 설정"을 참조하십시오. 브라우저 로케일 재정의 Splunk에 액세스하는 데 사용하는 URL을 수정하여 지정된 세션에 대해 Splunk가 사용하는 로케일을 변경할 수 있습니다. Splunk URL은 형식을 따릅니다. 예를 들어, Splunk에 로그인하기 위해 액세스할 때 URL이 미 국 영어 로케일인 경우 나타납니다. 영국 영어 설정을 사용하려면 이 로케일 문자열을 변경하십시오. 그러면 이 세션 중에는 영국 영어 형식으로 타임스탬 프가 제공되고 허용됩니다. Splunk 인터페이스를 현지화한 로케일이 아닌 다른 로케일을 요청할 경우 다음과 같은 메시지가 표시됩니다. Invalid language Specified. Splunk 현지화에 대한 자세한 내용은 개발자 매뉴얼의 "Splunk 번역"을 참조하십시오. 사용자 Session timeout 설정 Splunk 사용자 세션이 제한 시간에 도달하기까지 걸리는 시간은 다음 세 가지 제한 시간 설정 간의 상호 작용에 따라 다릅니 다. splunkweb Session timeout splunkd Session timeout 브라우저 Session timeout splunkweb 및 splunkd 제한 시간은 브라우저와 Splunk 간의 상호 작용에서 최대 유휴 시간을 결정합니다. 브라우저 Session timeout은 사용자와 브라우저 간의 상호 작용에서 최대 유휴 시간을 결정합니다. splunkweb 및 splunkd 제한 시간 값은 일반적으로 모두 동일한 필드에서 설정되기 때문에 동일합니다. Splunk Web에서 제한 시간을 설정하려면: 1. Splunk Web의 오른쪽 상단 모서리에서 설정을 클릭합니다. 2. 시스템에서 서버 설정을 클릭합니다. 83

84 3. 일반 설정을 클릭합니다. 4. Session timeout 필드에 제한 시간 값을 입력합니다. 5. 저장을 클릭합니다. 이렇게 하면 splunkweb 및 splunkd의 모든 사용자 Session timeout 값이 설정됩니다. 처음에는 모두 동일한 값(60분)을 공유 하며, Splunk Web을 통해 이 값을 변경할 경우 모두 동일한 값을 계속 유지하게 됩니다. 경우에 따라 splunkweb 및 splunkd의 제한 시간을 서로 다른 값으로 설정해야 할 경우 기본 설정 파일 web.conf(tools.sessions.timeout 속성)와 server.conf(sessiontimeout 속성)를 편집하여 설정할 수 있습니다. 실제로 값들을 서로 다르게 주어야 할 이유가 없습니다. 사용자가 SplunkWeb(splunkweb)을 사용하여 Splunk 인스턴스(splunkd)에 액세스 할 경우 두 개의 제한 시간 속성 중에서 더 짧은 시간이 우선합니다. 따라서 web.conf에서 tools.sessions.timeout의 값이 "90"(분)이고 server.conf에서 sessiontimeout의 값이 "1h"(1시간 또는 60분)일 경우 이 세션의 제한 시간은 60분이 됩니다. splunkweb/splunkd 세션 값 설정뿐만 아니라 web.conf에서 ui_inactivity_timeout 값을 편집하여 사용자 브라우저의 세션에 대 한 제한 시간을 지정할 수도 있습니다. 이 값에 도달하면 Splunk 브라우저 세션은 끊기게 됩니다. 기본값은 60분입니다. ui_inactivity_timeout을 1 미만으로 설정하면 제한 시간이 없게 되므로, 브라우저가 열려 있는 동안 계속 연결이 유지됩니 다. splunkweb/splunkd Session timeout은 브라우저 세션이 제한 시간 값에 도달하기 전까지는 카운트다운이 시작되지 않습니다. 따라서 제한 시간 전에 사용자가 얼마나 있는지 결정하려면 splunkweb 및 splunkd의 제한 시간 값 중에서 더 적은 값에 ui_inactivity_timeout의 값을 추가하십시오. 예를 들어, 다음을 가정해 보십시오. splunkweb 제한 시간: 15m splunkd 제한 시간: 20m 브라우저(ui_inactivity_timeout) 제한 시간: 10m 이 사용자 세션은 25분(15분+10분) 동안 활성 상태를 유지합니다. 25분이 지나서도 사용하지 않으면 다시 로그인하라는 메 시지가 나타납니다. 참고: Splunk Web 또는 설정 파일에서 제한 시간 값을 변경할 경우 변경 사항을 적용하려면 Splunk를 재시작해야 합니다. 설정 파일 참조 alert_actions.conf 다음은 alert_actions.conf의 사양 및 예제 파일입니다. alert_actions.conf.spec Version This file contains possible attributes and values for configuring global saved search actions in alert_actions.conf. Saved searches are configured in savedsearches.conf. There is an alert_actions.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place an alert_actions.conf in $SPLUNK_HOME/etc/system/local/. For examples, see alert_actions.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. maxresults = <integer> * Set the global maximum number of search results sent via alerts. * Defaults to 100. hostname = [protocol]<host>[:<port>] * Sets the hostname used in the web link (url) sent in alerts. 84

85 * This value accepts two forms. * hostname examples: splunkserver, splunkserver.example.com * protocol://hostname:port examples: * When this value is a simple hostname, the protocol and port which are configured within splunk are used to construct the base of the url. * When this value begins with ' it is used verbatim. NOTE: This means the correct port must be specified if it is not the default port for http or https. * This is useful in cases when the Splunk server is not aware of how to construct an externally referenceable url, such as SSO environments, other proxies, or when the Splunk server hostname is not generally resolvable. * Defaults to current hostname provided by the operating system, or if that fails, "localhost". * When set to empty, default behavior is used. ttl = <integer>[p] * optional argument specifying the minimum time to live (in seconds) of the search artifacts, if this action is triggered. * if p follows integer, then integer is the number of scheduled periods. * If no actions are triggered, the artifacts will have their ttl determined by the "dispatch.ttl" attribute in savedsearches.conf. * Defaults to 10p * Defaults to (24 hours) for: , rss * Defaults to 600 (10 minutes) for: script * Defaults to 120 (2 minutes) for: summary_index, populate_lookup maxtime = <integer>[m s h d] * The maximum amount of time that the execution of an action is allowed to take before the action is aborted. * Use the d, h, m and s suffixes to define the period of time: d = day, h = hour, m = minute and s = second. For example: 5d means 5 days. * Defaults to 5m for everything except rss. * Defaults to 1m for rss. track_alert = [1 0] * indicates whether the execution of this action signifies a trackable alert. * Defaults to 0 (false). command = <string> * The search command (or pipeline) which is responsible for executing the action. * Generally the command is a template search pipeline which is realized with values from the saved search - to reference saved search field values wrap them in dollar signs ($). * For example, to reference the savedsearch name use $name$. To reference the search, use $search$ these settings are prefaced by the [ ] stanza name [ ] * Set notification options under this stanza name. * Follow this stanza name with any number of the following attribute/value pairs. * If you do not specify an entry for each attribute, Splunk will use the default value. from = <string> * address from which the alert originates. * Defaults to splunk@$localhost. to = <string> * to address receiving alert. 85

86 cc = <string> * cc address receiving alert. bcc = <string> * bcc address receiving alert. message.report = <string> * Specify a custom message for scheduled reports. * Includes the ability to reference attributes from * result, saved search, job message.alert = <string> * Specify a custom message for alerts. * Includes the ability to reference attributes from * result, saved search, job subject = <string> * Specify an alternate subject if usenssubject is false. * Defaults to SplunkAlert-<savedsearchname>. subject.alert = <string> * Specify an alternate subject for an alert. * Defaults to SplunkAlert-<savedsearchname>. subject.report = <string> * Specify an alternate subject for a scheduled report. * Defaults to SplunkReport-<savedsearchname>. usenssubject = [1 0] * Specify whether to use the namespaced subject (i.e subject.report) * or subject. footer.text = <string> * Specify an alternate footer. * Defaults to If you believe you've received this in error, please see your * Splunk administrator.\r\n\r\nsplunk > the engine for machine data. format = [table raw csv] * Specify the format of inline results in the . * Acceptable values: table, raw, and csv. * Previously accepted values plain and html are no longer respected * and equate to table. * All s are sent as HTML messages with an alternative plain text version. include.results_link = [1 0] * Specify whether to include a link to the results. include.search = [1 0] * Specify whether to include the search that cause * an to be sent. include.trigger = [1 0] * Specify whether to show the trigger condition that * caused the alert to fire. include.trigger_time = [1 0] * Specify whether to show the time that the alert * was fired. include.view_link = [1 0] * Specify whether to show the title and a link to * enable the user to edit the saved search. sendresults = [1 0] * Specify whether the search results are included in the . The results can be attached or inline, see inline (action. .inline) * Defaults to 0 (false). inline = [1 0] * Specify whether the search results are contained in the body of the alert . * Defaults to 0 (false). 86

87 priority = [ ] * Set the priority of the as it appears in the client. * Value mapping: 1 to highest, 2 to high, 3 to normal, 4 to low, 5 to lowest. * Defaults to 3. mailserver = <host>[:<port>] * You must have a Simple Mail Transfer Protocol (SMTP) server available to send . This is not included with Splunk. * The SMTP mail server to use when sending s. * <host> can be either the hostname or the IP address. * Optionally, specify the SMTP <port> that Splunk should connect to. * When the "use_ssl" attribute (see below) is set to 1 (true), you must specify both <host> and <port>. (Example: "example.com:465") * Defaults to $LOCALHOST:25. use_ssl = [1 0] * Whether to use SSL when communicating with the SMTP server. * When set to 1 (true), you must also specify both the server name or IP address and the TCP port in the "mailserver" attribute. * Defaults to 0 (false). use_tls = [1 0] * Specify whether to use TLS (transport layer security) when communicating with the SMTP server (starttls) * Defaults to 0 (false). auth_username = <string> * The username to use when authenticating with the SMTP server. If this is not defined or is set to an empty string, no authentication is attempted. NOTE: your SMTP server might reject unauthenticated s. * Defaults to empty string. auth_password = <string> * The password to use when authenticating with the SMTP server. Normally this value will be set when editing the settings, however you can set a clear text password here and it will be encrypted on the next Splunk restart. * Defaults to empty string. sendpdf = [1 0] * Specify whether to create and send the results as a PDF. * Defaults to 0 (false). sendcsv = [1 0] * Specify whether to create and send the results as a csv file. * Defaults to 0 (false). pdfview = <string> * Name of view to send as a PDF reportserverenabled = [1 0] * Specify whether the PDF server is enabled. * Defaults to 0 (false). reportserverurl = <url> * The URL of the PDF report server, if one is set up and available on the network. * For a default locally installed report server, the URL is reportpapersize = [letter legal ledger a2 a3 a4 a5] * Default paper size for PDFs * Acceptable values: letter, legal, ledger, a2, a3, a4, a5 * Defaults to "letter". reportpaperorientation = [portrait landscape] * Paper orientation: portrait or landscape * Defaults to "portrait". reportincludesplunklogo = [1 0] 87

88 * Specify whether to include a Splunk logo in Integrated PDF Rendering * Defaults to 1 (true) reportcidfontlist = <string> * Specify the set (and load order) of CID fonts for handling Simplified Chinese(gb), Traditional Chinese(cns), Japanese(jp), and Korean(kor) in Integrated PDF Rendering. * Specify in space separated list * If multiple fonts provide a glyph for a given character code, the glyph from the first font specified in the list will be used * To skip loading any CID fonts, specify the empty string * Defaults to "gb cns jp kor" width_sort_columns = <bool> * Whether columns should be sorted from least wide to most wide left to right. * Valid only if format=text * Defaults to true preprocess_results = <search-string> * Supply a search string to Splunk to preprocess results before ing them. Usually the preprocessing consists of filtering out unwanted internal fields. * Defaults to empty string (no preprocessing) RSS: these settings are prefaced by the [rss] stanza [rss] * Set RSS notification options under this stanza name. * Follow this stanza name with any number of the following attribute/value pairs. * If you do not specify an entry for each attribute, Splunk will use the default value. items_count = <number> * Number of saved RSS feeds. * Cannot be more than maxresults (in the global settings). * Defaults to 30. script: Used to configure any scripts that the alert triggers. [script] filename = <string> * The filename, with no path, of the script to trigger. * The script should be located in: $SPLUNK_HOME/bin/scripts/ * For system shell scripts on Unix, or.bat or.cmd on windows, there are no further requirements. * For other types of scripts, the first line should begin with a! marker, followed by a path to the interpreter that will run the script. * Example:!C:\Python27\python.exe * Defaults to empty string. summary_index: these settings are prefaced by the [summary_index] stanza [summary_index] inline = [1 0] * Specifies whether the summary index search command will run as part of the scheduled search or as a follow-on action. This is useful when the results of the scheduled search are expected to be large. * Defaults to 1 (true). _name = <string> * The name of the summary index where Splunk will write the events. * Defaults to "summary". populate_lookup: these settings are prefaced by the [populate_lookup] stanza 88

89 [populate_lookup] dest = <string> * the name of the lookup table to populate (stanza name in transforms.conf) or the lookup file path to where you want the data written. If a path is specified it MUST be relative to $SPLUNK_HOME and a valid lookups directory. For example: "etc/system/lookups/<file-name>" or "etc/apps/<app>/lookups/<file-name>" * The user executing this action MUST have write permissions to the app for this action to work properly. alert_actions.conf.example Version This is an example alert_actions.conf. Use this file to configure alert actions for saved searches. To use one or more of these configurations, copy the configuration block into alert_actions.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [ ] keep the search artifacts around for 24 hours ttl = if is found in the address the hostname of the current machine is appended from = splunk format = html reportserverurl = inline = false sendresults = true hostname = CanAccessFromTheWorld.com command = send "to=$action. .to$" "server=$action. .mailserver{default=localhost}$" "from=$action. .from{default=splunk@localhost}$" "subject=$action. .subject{recurse=yes}$" "format=$action. .format{default=csv}$" "sssummary=saved Search [$name$]: $counttype$($results.count$)" "sslink=$results.url$" "ssquery=$search$" "ssname=$name$" "inline=$action. .inline{default=false}$" "sendresults=$action. .sendresults{default=false}$" "sendpdf=$action. .sendpdf{default=false}$" "pdfview=$action. .pdfview$" "searchid=$search_id$" "graceful=$graceful{default=true}$" maxinputs="$maxinputs{default=1000}$" maxtime="$action. .maxtime{default=5m}$" _validate-1 = action. .sendresults, validate( is_bool('action. .sendresults'), "Value of argument 'action. .sendresults' must be a boolean") [rss] at most 30 items in the feed items_count=30 keep the search artifacts around for 24 hours ttl = command = createrss "path=$name$.xml" "name=$name$" "link=$results.url$" "descr=alert trigger: $name$, results.count=$results.count$ " "count=30" "graceful=$graceful{default=1}$" maxtime="$action.rss.maxtime{default=1m}$" [summary_index] don't need the artifacts anytime after they're in the summary index ttl = 120 make sure the following keys are not added to marker (command, ttl, maxresults, _*) command = summaryindex addtime=true index="$action.summary_index._name{required=yes}$" file="$name$_$random$.stash" name="$name$" marker="$action.summary_index*{format=$key=\\\"$val\\\", key_regex="action.summary_index.(?!(?:command maxresults ttl (?:_.*))$)(.*)"}$" 89

90 app.conf 다음은 app.conf의 사양 및 예제 파일입니다. app.conf.spec Version This file maintains the state of a given app in Splunk. It may also be used to customize certain aspects of an app. There is no global, default app.conf. Instead, an app.conf may exist in each app in Splunk. You must restart Splunk to reload manual changes to app.conf. To learn more about configuration files (including precedence) please see the documentation located at Settings for how this app appears in Launcher (and online on SplunkApps) [launcher] global setting remote_tab = <bool> * Set whether the Launcher interface will connect to apps.splunk.com. * This setting only applies to the Launcher app and should be not set in any other app * Defaults to true. per-application settings version = <version string> * Version numbers are a number followed by a sequence of numbers or dots. * Pre-release versions can append a space and a single-word suffix like "beta2". Examples: * 1.2 * * 2.0 beta * 1.3 beta2 * 1.0 b2 * 12.4 alpha * description = <string> * Short explanatory string displayed underneath the app's title in Launcher. * Descriptions should be 200 characters or less because most users won't read long descriptions! author = <name> * For apps you intend to post to SplunkApps, enter the username of your splunk.com account. * For internal-use-only apps, include your full name and/or contact info (e.g. ). Your app can include an icon which will show up next to your app in Launcher and on SplunkApps. You can also include a screenshot, which will show up on SplunkApps when the user views info about your app before downloading it. Icons are recommended, although not required. Screenshots are optional. There is no setting in app.conf for these images. Instead, icon and screenshot images should be placed in the appserver/static dir of your app. They will automatically be detected by Launcher and SplunkApps. For example: <app_directory>/appserver/static/appicon.png (the capital "I" is required!) <app_directory>/appserver/static/screenshot.png 90

91 An icon image must be a 36px by 36px PNG file. An app screenshot must be 623px by 350px PNG file. [package] defines upgrade-related metadata, and will be used in future versions of Splunk to streamline app upgrades. [package] id = <appid> * id should be omitted for internal-use-only apps which are not intended to be uploaded to SplunkApps * id is required for all new apps uploaded to SplunkApps. Future versions of Splunk will use appid to correlate locally-installed apps and the same app on SplunkApps (e.g. to notify users about app updates) * id must be the same as the folder name in which your app lives in $SPLUNK_HOME/etc/apps * id must adhere to cross-platform folder-name restrictions: - must contain only letters, numbers, "." (dot), and "_" (underscore) characters - must not end with a dot character - must not be any of the following names: CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 check_for_updates = <bool> * Set whether Splunk should check SplunkApps for updates to this app. * Defaults to true. Set install settings for this app [install] state = disabled enabled * Set whether app is disabled or enabled. * If an app is disabled, its configs are ignored. * Defaults to enabled. state_change_requires_restart = true false * Set whether changing an app's state ALWAYS requires a restart of Splunk. * State changes include enabling or disabling an app. * When set to true, changing an app's state always requires a restart. * When set to false, modifying an app's state may or may not require a restart depending on what the app contains. This setting cannot be used to avoid all restart requirements! * Defaults to false. is_configured = true false * Stores indication of whether the application's custom setup has been performed * Defaults to false build = <integer> * Required. * Must be a positive integer. * Increment this whenever you change files in appserver/static. * Every release must change both "version" and "build" settings. * Ensures browsers don't use cached copies of old static files in new versions of your app. * Build is a single integer, unlike version which can be a complex string like allows_disable = true false * Set whether an app allows itself to be disabled. * Defaults to true. install_source_checksum = <string> * Optional. * Records a checksum of the tarball from which a given app was installed. * Splunk will automatically populate this value upon install; there is no need 91

92 to set it explicitly within your app. Handle reloading of custom.conf files (4.2+ versions only) [triggers] reload.<conf_file_name> = [ simple rest_endpoints access_endpoints <handler_url> ] * Splunk will reload app configuration after every app-state change: install, update, enable, and disable. * If your app does not use a custom config file (e.g. myconffile.conf) then it won't need a [triggers] stanza, because $SPLUNK_HOME/etc/system/default/app.conf already includes a [triggers] stanza which automatically reloads config files normally used by Splunk. * If your app uses a custom config file (e.g. myconffile.conf) and you want to avoid unnecessary Splunk restarts, you'll need to add a reload value in the [triggers] stanza. * If you don't include [triggers] settings and your app uses a custom config file, a Splunk restart will be required after every state change. * Specifying "simple" implies that Splunk will take no special action to reload your custom conf file. * Specify "access_endpoints" and a URL to a REST endpoint, and Splunk will call its _reload() method at every app state change. * "rest_endpoints" is reserved for Splunk's internal use for reloading restmap.conf. * Examples: [triggers] Do not force a restart of Splunk for state changes of MyApp Do not run special code to tell MyApp to reload myconffile.conf Apps with custom config files will usually pick this option reload.myconffile = simple Do not force a restart of Splunk for state changes of MyApp. Splunk calls the /admin/myendpoint/_reload method in my custom EAI handler. Use this advanced option only if MyApp requires custom code to reload its configuration when its state changes reload.myotherconffile = access_endpoints /admin/myendpoint Set UI-specific settings for this app [ui] is_visible = true false * Indicates if this app should be visible/navigable as a UI app * Apps require at least 1 view to be available from the UI is_manageable = true false * This setting is deprecated. It no longer has any effect. label = <string> * Defines the name of the app shown in the Splunk GUI and Launcher * Recommended length between 5 and 80 characters. * Must not include "Splunk For" prefix. * Label is required. * Examples of good labels: IMAP Monitor SQL Server Integration Services FISMA Compliance docs_section_override = <string> * Defines override for auto-generated app-specific documentation links * If not specified, app-specific documentation link will include [<app-name>:<app-version>] * If specified, app-specific documentation link will include [<docs_section_override>] * This only applies to apps with documentation on Splunk's documentation site Credential-verification scripting (4.2+ versions only) 92

93 [credentials_settings] verify_script = <string> * Optional setting. * Command line to invoke to verify credentials used for this app. * For scripts, the command line should include both the interpreter and the script for it to run. * Example: "$SPLUNK_HOME/bin/python" "$SPLUNK_HOME/etc/apps/<myapp>/bin/$MY_SCRIPT" * The invoked program is communicated with over standard in / standard out via the same protocol as splunk scripted auth. * Paths incorporating variable expansion or explicit spaces must be quoted. * For example, a path including $SPLUNK_HOME should be quoted, as likely will expand to C:\Program Files\Splunk [credential:<realm>:<username>] password = <string> * Password that corresponds to the given username for the given realm. Note that realm is optional * The password can be in clear text, however when saved from splunkd the password will always be encrypted app.conf.example Version The following are example app.conf configurations. Configure properties for your custom application. There is NO DEFAULT app.conf. To use one or more of these configurations, copy the configuration block into props.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [launcher] author=<author of app> description=<textual description of app> version=<version of app> audit.conf 다음은 audit.conf의 사양 및 예제 파일입니다. audit.conf.spec Version This file contains possible attributes and values you can use to configure auditing and event signing in audit.conf. There is NO DEFAULT audit.conf. To set custom configurations, place an audit.conf in $SPLUNK_HOME/etc/system/local/. For examples, see audit.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. 93

94 EVENT HASHING: turn on SHA256 event hashing. [eventhashing] * This stanza turns on event hashing -- every event is SHA256 hashed. * The indexer will encrypt all the signatures in a block. * Follow this stanza name with any number of the following attribute/value pairs. filters=mywhitelist,myblacklist... * (Optional) Filter which events are hashed. * Specify filtername values to apply to events. * NOTE: The order of precedence is left to right. Two special filters are provided by default: blacklist_all and whitelist_all, use them to terminate the list of your filters. For example if your list contains only whitelists, then terminating it with blacklist_all will result in signing of only events that match any of the whitelists. The default implicit filter list terminator is whitelist_all. FILTER SPECIFICATIONS FOR EVENT HASHING [filterspec:<event_whitelist event_blacklist>:<filtername>] * This stanza turns on whitelisting or blacklisting for events. * Use filternames in "filters" entry (above). * For example [filterspec:event_whitelist:foofilter]. all=[true false] * The 'all' tag tells the blacklist to stop 'all' events. * Defaults to 'false.' source=[string] host=[string] sourcetype=[string] Optional list of blacklisted/whitelisted sources, hosts or sourcetypes (in order from left to right). * Exact matches only, no wildcarded strings supported. * For example: source=s1,s2,s3... host=h1,h2,h3... sourcetype=st1,st2,st3... KEYS: specify your public and private keys for encryption. [audittrail] * This stanza turns on cryptographic signing for audit trail events (set in inputs.conf) and hashed events (if event hashing is enabled above). privatekey=/some/path/to/your/private/key/private_key.pem publickey=/some/path/to/your/public/key/public_key.pem * You must have a private key to encrypt the signatures and a public key to decrypt them. * Set a path to your own keys * Generate your own keys using openssl in $SPLUNK_HOME/bin/. queueing=[true false] * Turn off sending audit events to the indexqueue -- tail the audit events instead. * If this is set to 'false', you MUST add an inputs.conf stanza to tail the audit log in order to have the events reach your index. * Defaults to true. audit.conf.example Version This is an example audit.conf. Use this file to configure auditing and event hashing. There is NO DEFAULT audit.conf. 94

95 To use one or more of these configurations, copy the configuration block into audit.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [audittrail] privatekey=/some/path/to/your/private/key/private_key.pem publickey=/some/path/to/your/public/key/public_key.pem If this stanza exists, audit trail events will be cryptographically signed. You must have a private key to encrypt the signatures and a public key to decrypt them. Generate your own keys using openssl in $SPLUNK_HOME/bin/. EXAMPLE 1 - hash all events: [eventhashing] This performs a SHA256 hash on every event other than ones going the _audit index (which are handled their own way). NOTE: All you need to enable hashing is the presence of the stanza 'eventhashing'. EXAMPLE 2 - simple blacklisting [filterspec:event_blacklist:myblacklist] host=somehost.splunk.com, , [eventhashing] filters=myblacklist Splunk does NOT hash any events from the hosts listed - they are 'blacklisted'. All other events are hashed. EXAMPLE 3 - multiple blacklisting [filterspec:event_blacklist:myblacklist] host=somehost.splunk.com, source=/some/source sourcetype=syslog, apache.error [eventhashing] filters=myblacklist DO NOT hash all events with the following, sources, sourcetypes and hosts - they are all blacklisted. All other events are hashed. EXAMPLE 4 - whitelisting [filterspec:event_whitelist:mywhitelist] sourcetype=syslog source=aa, bb (these can be added as well) host=xx, yy [filterspec:event_blacklist:nothingelse] The 'all' tag is a special boolean (defaults to false) that says match *all* events all=true [eventsigning] filters=mywhitelist, nothingelse Hash ONLY those events which are of sourcetype 'syslog'. All other events are NOT hashed. Note that you can have a list of filters and they are executed from left to right for every event. 95

96 If an event passed a whitelist, the rest of the filters do not execute. Thus placing the whitelist filter before the 'all' blacklist filter says "only hash those events which match the whitelist". authentication.conf 다음은 authentication.conf의 사양 및 예제 파일입니다. authentication.conf.spec Version This file contains possible attributes and values for configuring authentication via authentication.conf. There is an authentication.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place an authentication.conf in $SPLUNK_HOME/etc/system/local/. For examples, see authentication.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [authentication] * Follow this stanza name with any number of the following attribute/value pairs. authtype = [Splunk LDAP Scripted] * Specify which authentication system to use. * Supported values: Splunk, LDAP, Scripted. * Defaults to Splunk. authsettings = <authsettings-key>,<authsettings-key>,... * Key to look up the specific configurations of chosen authentication system. * <authsettings-key> is the name of a stanza header that specifies attributes for an LDAP strategy or for scripted authentication. Those stanzas are defined below. * For LDAP, specify the LDAP strategy name(s) here. If you want Splunk to query multiple LDAP servers, enter a comma-separated list of all strategies. Each strategy must be defined in its own stanza. The order in which you specify the strategy names will be the order Splunk uses to query their servers when looking for a user. * For scripted authentication, <authsettings-key> should be a single stanza name. passwordhashalgorithm = [SHA512-crypt SHA256-crypt SHA512-crypt-<num_rounds> SHA256-crypt-<num_rounds> MD5-crypt] * For the default "Splunk" authtype, this controls how hashed passwords are stored in the $SPLUNK_HOME/etc/passwd file. * "MD5-crypt" is an algorithm originally developed for FreeBSD in the early 1990's which became a widely used standard among UNIX machines. It was also used by Splunk up through the 5.0.x releases. MD5-crypt runs the salted password through a sequence of 1000 MD5 operations. * "SHA256-crypt" and "SHA512-crypt" are newer versions that use 5000 rounds of the SHA256 or SHA512 hash functions. This is slower than MD5-crypt and therefore more resistant to dictionary attacks. SHA512-crypt is used for system passwords on many versions of Linux. * These SHA-based algorithm can optionally be followed by a number of rounds to use. For example, "SHA512-crypt-10000" will use twice as many rounds of hashing as the default implementation. The number of rounds must be at least If you specify a very large number of rounds (i.e. more than 20x the default value of 5000), splunkd may become unresponsive and connections to splunkd (from splunkweb or CLI) will time out. * This setting only affects new password settings (either when a user is added or a user's password is changed) Existing passwords will continue to work but retain their previous hashing algorithm. * The default is "SHA512-crypt". 96

97 LDAP settings [<authsettings-key>] * Follow this stanza name with the attribute/value pairs listed below. * For multiple strategies, you will need to specify multiple instances of this stanza, each with its own stanza name and a separate set of attributes. * The <authsettings-key> must be one of the values listed in the authsettings attribute, specified above in the [authentication] stanza. host = <string> * REQUIRED * This is the hostname of LDAP server. * Be sure that your Splunk server can resolve the host name. SSLEnabled = [0 1] * OPTIONAL * Defaults to disabled (0) * See the file $SPLUNK_HOME/etc/openldap/openldap.conf for SSL LDAP settings port = <integer> * OPTIONAL * This is the port that Splunk should use to connect to your LDAP server. * Defaults to port 389 for non-ssl and port 636 for SSL binddn = <string> * OPTIONAL, leave this blank to retrieve your LDAP entries using anonymous bind (must be supported by the LDAP server) * Distinguished name of the user that will be retrieving the LDAP entries * This user must have read access to all LDAP users and groups you wish to use in Splunk. binddnpassword = <string> * OPTIONAL, leave this blank if anonymous bind is sufficient * Password for the binddn user. userbasedn = <string> * REQUIRED * This is the distinguished names of LDAP entries whose subtrees contain the users * Enter a ';' delimited list to search multiple trees. userbasefilter = <string> * OPTIONAL * This is the LDAP search filter you wish to use when searching for users. * Highly recommended, especially when there are many entries in your LDAP user subtrees * When used properly, search filters can significantly speed up LDAP queries * Example that matches users in the IT or HR department: * userbasefilter = ( (department=it)(department=hr)) * See RFC 2254 for more detailed information on search filter syntax * This defaults to no filtering. usernameattribute = <string> * REQUIRED * This is the user entry attribute whose value is the username. * NOTE: This attribute should use case insensitive matching for its values, and the values should not contain whitespace * Users are case insensitive in Splunk * In Active Directory, this is 'samaccountname' * A typical attribute for this is 'uid' realnameattribute = <string> * REQUIRED * This is the user entry attribute whose value is their real name (human readable). * A typical attribute for this is 'cn' attribute = <string> * OPTIONAL * This is the user entry attribute whose value is their address. * Defaults to 'mail' groupmappingattribute = <string> * OPTIONAL * This is the user entry attribute whose value is used by group entries to declare membership. 97

98 * Groups are often mapped with user DN, so this defaults to 'dn' * Set this if groups are mapped using a different attribute * Usually only needed for OpenLDAP servers. * A typical attribute used to map users to groups is 'uid' * For example, assume a group declares that one of its members is 'splunkuser' * This implies that every user with 'uid' value 'splunkuser' will be mapped to that group groupbasedn = [<string>;<string>;...] * REQUIRED * This is the distinguished names of LDAP entries whose subtrees contain the groups. * Enter a ';' delimited list to search multiple trees. * If your LDAP environment does not have group entries, there is a configuration that can treat each user as its own group * Set groupbasedn to the same as userbasedn, which means you will search for groups in the same place as users * Next, set the groupmemberattribute and groupmappingattribute to the same attribute as usernameattribute * This means the entry, when treated as a group, will use the username value as its only member * For clarity, you should probably also set groupnameattribute to the same value as usernameattribute as well groupbasefilter = <string> * OPTIONAL * The LDAP search filter Splunk uses when searching for static groups * Like userbasefilter, this is highly recommended to speed up LDAP queries * See RFC 2254 for more information * This defaults to no filtering dynamicgroupfilter = <string> * OPTIONAL * The LDAP search filter Splunk uses when searching for dynamic groups * Only configure this if you intend to retrieve dynamic groups on your LDAP server * Example: '(objectclass=groupofurls)' dynamicmemberattribute = <string> * OPTIONAL * Only configure this if you intend to retrieve dynamic groups on your LDAP server * This is REQUIRED if you want to retrieve dynamic groups * This attribute contains the LDAP URL needed to retrieve members dynamically * Example: 'memberurl' groupnameattribute = <string> * REQUIRED * This is the group entry attribute whose value stores the group name. * A typical attribute for this is 'cn' (common name) * Recall that if you are configuring LDAP to treat user entries as their own group, user entries must have this attribute groupmemberattribute = <string> * REQUIRED * This is the group entry attribute whose values are the groups members * Typical attributes for this are 'member' and 'memberuid' * For example, consider the groupmappingattribute example above using groupmemberattribute 'member' * To declare 'splunkuser' as a group member, its attribute 'member' must have the value 'splunkuser' nestedgroups = <bool> * OPTIONAL * Controls whether Splunk will expand nested groups using the 'memberof' extension. * Set to 1 if you have nested groups you want to expand and the 'memberof' extension on your LDAP server. charset = <string> * OPTIONAL * ONLY set this for an LDAP setup that returns non-utf-8 encoded data. LDAP is supposed to always return UTF-8 encoded data (See RFC 2251), but some tools incorrectly return other encodings. * Follows the same format as CHARSET in props.conf (see props.conf.spec) * An example value would be "latin-1" anonymous_referrals = <bool> * OPTIONAL * Set this to 0 to turn off referral chasing * Set this to 1 to turn on anonymous referral chasing * IMPORTANT: We only chase referrals using anonymous bind. We do NOT support rebinding using credentials. 98

99 * If you do not need referral support, we recommend setting this to 0 * If you wish to make referrals work, set this to 1 and ensure your server allows anonymous searching * Defaults to 1 sizelimit = <integer> * OPTIONAL * Limits the amount of entries we request in LDAP search * IMPORTANT: The max entries returned is still subject to the maximum imposed by your LDAP server * Example: If you set this to 5000 and the server limits it to 1000, you'll still only get 1000 entries back * Defaults to 1000 timelimit = <integer> * OPTIONAL * Limits the amount of time in seconds we will wait for an LDAP search request to complete * If your searches finish quickly, you should lower this value from the default * Defaults to 15 network_timeout = <integer> * OPTIONAL * Limits the amount of time a socket will poll a connection without activity * This is useful for determining if your LDAP server cannot be reached * IMPORTANT: As a connection could be waiting for search results, this value must be higher than 'timelimit' * Like 'timelimit', if you have a fast connection to your LDAP server, we recommend lowering this value * Defaults to 20 Map roles [rolemap_<authsettings-key>] * The mapping of Splunk roles to LDAP groups for the LDAP strategy specified by <authsettings-key> * IMPORTANT: this role mapping ONLY applies to the specified strategy. * Follow this stanza name with several Role-to-Group(s) mappings as defined below. <Splunk RoleName> = <LDAP group string> * Maps a Splunk role (from authorize.conf) to LDAP groups * This LDAP group list is semicolon delimited (no spaces). * List several of these attribute value pairs to map several Splunk roles to LDAP Groups Scripted authentication [<authsettings-key>] * Follow this stanza name with the following attribute/value pairs: scriptpath = <string> * REQUIRED * This is the full path to the script, including the path to the program that runs it (python) * For example: "$SPLUNK_HOME/bin/python" "$SPLUNK_HOME/etc/system/bin/$MY_SCRIPT" * Note: If a path contains spaces, it must be quoted. The example above handles the case where $SPLUNK_HOME contains a space scriptsearchfilters = [1 0] * OPTIONAL - Only set this to 1 to call the script to add search filters. * 0 disables (default) [cachetiming] * Use these settings to adjust how long Splunk will use the answers returned from script functions before calling them again. userloginttl = <time range string> * Timeout for the userlogin script function. * These return values are cached on a per-user basis. * The default is '0' (no caching) getuserinfottl = <time range string> * Timeout for the getuserinfo script function. * These return values are cached on a per-user basis. * The default is '10s' getusersttl = <time range string> 99

100 * Timeout for the getusers script function. * There is only one global getusers cache (it is not tied to a specific user). * The default is '10s' * All timeouts can be expressed in seconds or as a search-like time range * Examples include '30' (30 seconds), '2mins' (2 minutes), '24h' (24 hours), etc. * You can opt to use no caching for a particular function by setting the value to '0' * Be aware that this can severely hinder performance as a result of heavy script invocation * Choosing the correct values for cache timing involves a tradeoff between new information latency and general performance * High values yield better performance from calling the script less, but introduces a latency in picking up changes * Low values will pick up changes in your external auth system more quickly, but may slow down performance due to increased script invocations Settings for Splunk Authentication mode [splunk_auth] * Settings for Splunk's internal authentication system. minpasswordlength = <positive integer> * Specifies the minimum permitted password length in characters when passwords are set or modified. * This setting is optional. * If 0, there is no required minimum. In other words there is no constraint. * Password modification attempts which do not meet this requirement will be explicitly rejected. * Defaults to 0 (disabled). authentication.conf.example Version This is an example authentication.conf. authentication.conf is used to configure LDAP and Scripted authentication in addition to Splunk's native authentication. To use one of these configurations, copy the configuration block into authentication.conf in $SPLUNK_HOME/etc/system/local/. You must reload auth in manager or restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Use just Splunk's built-in authentication (default): [authentication] authtype = Splunk LDAP examples Basic LDAP configuration example [authentication] authtype = LDAP authsettings = ldaphost [ldaphost] host = ldaphost.domain.com port = 389 SSLEnabled = 0 binddn = cn=directory Manager binddnpassword = password userbasedn = ou=people,dc=splunk,dc=com userbasefilter = (objectclass=splunkusers) groupbasedn = ou=groups,dc=splunk,dc=com groupbasefilter = (objectclass=splunkgroups) usernameattribute = uid realnameattribute = givenname groupmappingattribute = dn groupmemberattribute = uniquemember groupnameattribute = cn timelimit =

101 network_timeout = 15 This stanza maps roles you have created in authorize.conf to LDAP Groups [rolemap_ldaphost] admin = SplunkAdmins Example using the same server as 'ldaphost', but treating each user as their own group [authentication] authtype = LDAP authsettings = ldaphost_usergroups [ldaphost_usergroups] host = ldaphost.domain.com port = 389 SSLEnabled = 0 binddn = cn=directory Manager binddnpassword = password userbasedn = ou=people,dc=splunk,dc=com userbasefilter = (objectclass=splunkusers) groupbasedn = ou=people,dc=splunk,dc=com groupbasefilter = (objectclass=splunkusers) usernameattribute = uid realnameattribute = givenname groupmappingattribute = uid groupmemberattribute = uid groupnameattribute = uid timelimit = 10 network_timeout = 15 [rolemap_ldaphost_usergroups] admin = admin_user1;admin_user2;admin_user3;admin_user4 power = power_user1;power_user2 user = user1;user2;user3 Sample Configuration for Active Directory (AD) [authentication] authsettings = AD authtype = LDAP [AD] SSLEnabled = 1 binddn = [email protected] binddnpassword = ldap_bind_user_password groupbasedn = CN=Groups,DC=splunksupport,DC=kom groupbasefilter = groupmappingattribute = dn groupmemberattribute = member groupnameattribute = cn host = ADbogus.splunksupport.kom port = 636 realnameattribute = cn userbasedn = CN=Users,DC=splunksupport,DC=kom userbasefilter = usernameattribute = samaccountname timelimit = 15 network_timeout = 20 anonymous_referrals = 0 [rolemap_ad] admin = SplunkAdmins power = SplunkPowerUsers user = SplunkUsers Sample Configuration for Sun LDAP Server [authentication] authsettings = SunLDAP authtype = LDAP [SunLDAP] SSLEnabled = 0 binddn = cn=directory Manager binddnpassword = Directory_Manager_Password 101

102 groupbasedn = ou=groups,dc=splunksupport,dc=com groupbasefilter = groupmappingattribute = dn groupmemberattribute = uniquemember groupnameattribute = cn host = ldapbogus.splunksupport.com port = 389 realnameattribute = givenname userbasedn = ou=people,dc=splunksupport,dc=com userbasefilter = usernameattribute = uid timelimit = 5 network_timeout = 8 [rolemap_sunldap] admin = SplunkAdmins power = SplunkPowerUsers user = SplunkUsers Sample Configuration for OpenLDAP [authentication] authsettings = OpenLDAP authtype = LDAP [OpenLDAP] binddn = uid=directory_bind,cn=users,dc=osx,dc=company,dc=com binddnpassword = directory_bind_account_password groupbasefilter = groupnameattribute = cn SSLEnabled = 0 port = 389 userbasedn = cn=users,dc=osx,dc=company,dc=com host = hostname_or_ip userbasefilter = usernameattribute = uid groupmappingattribute = uid groupbasedn = dc=osx,dc=company,dc=com groupmemberattribute = memberuid realnameattribute = cn timelimit = 5 network_timeout = 8 dynamicgroupfilter = (objectclass=groupofurls) dynamicmemberattribute = memberurl nestedgroups = 1 [rolemap_openldap] admin = SplunkAdmins power = SplunkPowerUsers user = SplunkUsers Scripted Auth examples The following example is for RADIUS authentication: [authentication] authtype = Scripted authsettings = script [script] scriptpath = "$SPLUNK_HOME/bin/python" "$SPLUNK_HOME/share/splunk/authScriptSamples/radiusScripted.py" Cache results for 1 second per call [cachetiming] userloginttl = 1 getuserinfottl = 1 getusersttl = 1 The following example works with PAM authentication: [authentication] authtype = Scripted authsettings = script 102

103 [script] scriptpath = "$SPLUNK_HOME/bin/python" "$SPLUNK_HOME/share/splunk/authScriptSamples/pamScripted.py" Cache results for different times per function [cachetiming] userloginttl = 30s getuserinfottl = 1min getusersttl = 5mins authorize.conf 다음은 authorize.conf의 사양 및 예제 파일입니다. authorize.conf.spec Version This file contains possible attribute/value pairs for creating roles in authorize.conf. You can configure roles and granular access controls by creating your own authorize.conf. There is an authorize.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place an authorize.conf in $SPLUNK_HOME/etc/system/local/. For examples, see authorize.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [capability::<capability>] * DO NOT edit, remove, or add capability stanzas. The existing capabilities are the full set of Splunk system capabilities. * Splunk adds all of its capabilities this way * For the default list of capabilities and assignments, see authorize.conf under the 'default' directory * Descriptions of specific capabilities are listed below. [role_<rolename>] <capability> = <enabled> * A capability that is enabled for this role. * You can list many of these. * Note that 'enabled' is the only accepted value here, as capabilities are disabled by default. * Roles inherit all capabilities from imported roles, and inherited capabilities cannot be disabled. * Role names cannot have uppercase characters. User names, however, are case-insensitive. importroles = <string> * Semicolon delimited list of other roles and their associated capabilities that should be imported. * Importing other roles also imports the other aspects of that role, such as allowed indexes to search. * By default a role imports no other roles. grantableroles = <string> * Semicolon delimited list of roles that can be granted when edit_user capability is present. * By default, a role with edit_user capability can create/edit a user and assign any role to them. But when grantableroles is present, the roles that can be assigned will be restricted to the ones provided. * For a role that has no edit_user capability, grantableroles has no effect. * Defaults to not present. * Example: grantableroles = role1;role2;role3 srchfilter = <string> * Semicolon delimited list of search filters for this Role. * By default we perform no search filtering. * To override any search filters from imported roles, set this to '*', as the 'admin' role does. 103

104 srchtimewin = <number> * Maximum time span of a search, in seconds. * This time window limit is applied backwards from the latest time specified in a search. * By default, searches are not limited to any specific time window. * To override any search time windows from imported roles, set this to '0' (infinite), as the 'admin' role does. * -1 is a special value that implies no search window has been set for this role * This is equivalent to not setting srchtimewin at all, which means it can be easily overridden by an imported role srchdiskquota = <number> * Maximum amount of disk space (MB) that can be used by search jobs of a user that belongs to this role * Defaults to '100', for 100 MB. srchjobsquota = <number> * Maximum number of concurrently running historical searches a member of this role can have. * This excludes real-time searches, see rtsrchjobsquota. * Defaults to 3. rtsrchjobsquota = <number> * Maximum number of concurrently running real-time searches a member of this role can have. * Defaults to 6. srchmaxtime = <number><unit> * Maximum amount of time that searches of users from this role will be allowed to run. * Once the search has been ran for this amount of time it will be auto finalized, If the role * inherits from other roles, the maximum srchmaxtime value specified in the included roles. * This maximum does not apply to real-time searches. * Examples: 1h, 10m, 2hours, 2h, 2hrs, 100s etc... * Defaults to 100days srchindexesdefault = <string> * Semicolon delimited list of indexes to search when no index is specified * These indexes can be wildcarded, with the exception that '*' does not match internal indexes * To match internal indexes, start with '_'. All internal indexes are represented by '_*' * Defaults to none, but the UI will automatically populate this with 'main' in manager srchindexesallowed = <string> * Semicolon delimited list of indexes this role is allowed to search * Follows the same wildcarding semantics as srchindexesdefault * Defaults to none, but the UI will automatically populate this with '*' in manager cumulativesrchjobsquota = <number> * Maximum number of concurrently running historical searches that all members of this role can have. * NOTE: if a user belongs to multiple roles then s/he will first consume searches from the roles with * the largest cumulative search quota, when the quota of a role is completely used up then roles * with lower quotas will be examined. cumulativertsrchjobsquota = <number> * Maximum number of concurrently running real-time searches that all members of this role can have. * NOTE: if a user belongs to multiple roles then s/he will first consume searches from the roles with * the largest cumulative search quota, when the quota of a role is completely used up then roles * with lower quotas will be examined. Descriptions of Splunk system capabilities [capability::accelerate_datamodel] * Required to accelerate a datamodel. [capability::admin_all_objects] * A role with this capability has access to objects in the system (user objects, search jobs, etc.) * This bypasses any ACL restrictions (similar to root access in a *nix environment) * We check this capability when accessing manager pages and objects [capability::change_authentication] * Required to change authentication settings through the various authentication endpoints. * Also controls whether authentication can be reloaded [capability::change_own_password] * Self explanatory. Some auth systems prefer to have passwords be immutable for some users. 104

105 [capability::delete_by_keyword] * Required to use the 'delete' search operator. Note that this does not actually delete the raw data on disk. * Delete merely masks the data (via the index) from showing up in search results. [capability::edit_deployment_client] * Self explanatory. The deployment client admin endpoint requires this cap for edit. [capability::list_deployment_client] * Self explanatory. [capability::edit_deployment_server] * Self explanatory. The deployment server admin endpoint requires this cap for edit. * Required to change/create remote inputs that get pushed to the forwarders. [capability::list_deployment_server] * Self explanatory. [capability::edit_dist_peer] * Required to add and edit peers for distributed search. [capability::edit_forwarders] * Required to edit settings for forwarding data. * Used by TCP and Syslog output admin handlers * Includes settings for SSL, backoff schemes, etc. [capability::edit_httpauths] * Required to edit and end user sessions through the httpauth-tokens endpoint [capability::edit_input_defaults] * Required to change the default hostname for input data in the server settings endpoint. [capability::edit_monitor] * Required to add inputs and edit settings for monitoring files. * Used by the standard inputs endpoint as well as the one-shot input endpoint. [capability::edit_roles] * Required to edit roles as well as change the mappings from users to roles. * Used by both the users and roles endpoint. [capability::edit_scripted] * Required to create and edit scripted inputs. [capability::edit_search_server] * Required to edit general distributed search settings like timeouts, heartbeats, and blacklists [capability::edit_server] * Required to edit general server settings such as the server name, log levels, etc. [capability::edit_search_head_clustering] * Required to edit and manage search head clustering. [capability::edit_splunktcp] * Required to change settings for receiving TCP input from another Splunk instance. [capability::edit_splunktcp_ssl] * Required to list or edit any SSL specific settings for Splunk TCP input. [capability::edit_tcp] * Required to change settings for receiving general TCP inputs. [capability::edit_udp] * Required to change settings for UDP inputs. [capability::edit_user] * Required to create, edit, or remove users. * Note that Splunk users may edit certain aspects of their information without this capability. * Also required to manage certificates for distributed search. [capability::edit_view_html] * Required to create, edit, or otherwise modify HTML-based views. 105

106 [capability::edit_web_settings] * Required to change the settings for web.conf through the system settings endpoint. [capability::get_diag] * Required to use the /streams/diag endpoint to get remote diag from an instance [capability::get_metadata] * Required to use the 'metadata' search processor. [capability::get_typeahead] * Required for typeahead. This includes the typeahead endpoint and the 'typeahead' search processor. [capability::input_file] * Required for inputcsv (except for dispatch=t mode) and inputlookup [capability::indexes_edit] * Required to change any index settings like file size and memory limits. [capability::license_tab] * Required to access and change the license. [capability::list_forwarders] * Required to show settings for forwarding data. * Used by TCP and Syslog output admin handlers. [capability::list_httpauths] * Required to list user sessions through the httpauth-tokens endpoint. [capability::list_inputs] * Required to view the list of various inputs. * This includes input from files, TCP, UDP, Scripts, etc. [capability::list_search_head_clustering] * Required to list search head clustering objects like artifacts, delegated jobs, members, captain, etc. [capability::output_file] * Required for outputcsv (except for dispatch=t mode) and outputlookup [capability::request_remote_tok] * Required to get a remote authentication token. * Used for distributing search to old 4.0.x Splunk instances. * Also used for some distributed peer management and bundle replication. [capability::rest_apps_management] * Required to edit settings for entries and categories in the python remote apps handler. * See restmap.conf for more information [capability::rest_apps_view] * Required to list various properties in the python remote apps handler. * See restmap.conf for more info [capability::rest_properties_get] * Required to get information from the services/properties endpoint. [capability::rest_properties_set] * Required to edit the services/properties endpoint. [capability::restart_splunkd] * Required to restart Splunk through the server control handler. [capability::rtsearch] * Required to run a realtime search. [capability::run_debug_commands] * Required to run debugging commands like 'summarize' [capability::schedule_search] * Required to schedule saved searches. [capability::schedule_rtsearch] * Required to schedule real time saved searches. Note that scheduled_search capability is also required to be enabled 106

107 [capability::search] * Self explanatory - required to run a search. [capability::use_file_operator] * Required to use the 'file' search operator. [capability::accelerate_search] * Required to save an accelerated search * All users have this capability by default authorize.conf.example Version This is an example authorize.conf. Use this file to configure roles and capabilities. To use one or more of these configurations, copy the configuration block into authorize.conf in $SPLUNK_HOME/etc/system/local/. You must reload auth or restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [role_ninja] rtsearch = enabled importroles = user srchfilter = host=foo srchindexesallowed = * srchindexesdefault = mail;main srchjobsquota = 8 rtsrchjobsquota = 8 srchdiskquota = 500 This creates the role 'ninja', which inherits capabilities from the 'user' role. ninja has almost the same capabilities as power, except cannot schedule searches. The search filter limits ninja to searching on host=foo. ninja is allowed to search all public indexes (those that do not start with underscore), and will search the indexes mail and main if no index is specified in the search. ninja is allowed to run 8 search jobs and 8 real time search jobs concurrently (these counts are independent). ninja is allowed to take up 500 megabytes total on disk for all their jobs. collections.conf 다음은 collections.conf의 사양 및 예제 파일입니다. collections.conf.spec Version This file configures the KV Store collections for a given app in Splunk. To learn more about configuration files (including precedence) please see the documentation located at [<collection-name>] enforcetypes = true false * Indicates whether to enforce data types when inserting data into the collection. * When set to true, invalid insert operations fail. * When set to false, invalid insert operations drop only the invalid field. * Defaults to false. field.<name> = number bool string time * Field type for a field called <name>. * If the data type is not provided, it is inferred from the provided JSON data type. 107

108 accelerated_fields.<name> = <json> * Acceleration definition for an acceleration called <name>. * Must be a valid JSON document (invalid JSON is ignored). * Example: 'acceleration.foo={"a":1, "b":-1}' is a compound acceleration that first sorts 'a' in ascending order and then 'b' in descending order. * If multiple accelerations with the same definition are in the same collection, the duplicates are skipped. * If the data within a field is too large for acceleration, you will see a warning when you try to create an accelerated field and the acceleration will not be created. * An acceleration is always created on the _key. * The order of accelerations is important. For example, an acceleration of { "a":1, "b":1 } speeds queries on "a" and "a" + "b", but not on "b" alone. * Multiple separate accelerations also speed up queries. For example, separate accelerations { "a":1 } and { "b": 1 } will speed up queries on "a" + "b", but not as well as a combined acceleration { "a":1, "b":1 }. * Defaults to nothing (no acceleration). profilingenabled = true false * Indicates whether to enable logging of slow-running operations, as defined in 'profilingthresholdms'. * Defaults to false. profilingthresholdms = <zero or positive integer> * The threshold for logging a slow-running operation, in milliseconds. * When set to 0, all operations are logged. * This setting is only used when 'profilingenabled' is true. * This setting impacts the performance of the collection. * Defaults to 100. collections.conf.example Version The following is an example collections.conf configuration. To use one or more of these configurations, copy the configuration block into collections.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [mycollection] field.foo = number field.bar = string accelerated_fields.myacceleration = {"foo": 1, "bar": -1} commands.conf 다음은 commands.conf의 사양 및 예제 파일입니다. commands.conf.spec Version This file contains possible attribute/value pairs for creating search commands for any custom search scripts created. Add your custom search script to $SPLUNK_HOME/etc/searchscripts/ or $SPLUNK_HOME/etc/apps/MY_APP/bin/. For the latter, put a custom commands.conf in $SPLUNK_HOME/etc/apps/MY_APP. For the former, put your custom commands.conf in $SPLUNK_HOME/etc/system/local/. There is a commands.conf in $SPLUNK_HOME/etc/system/default/. For examples, see commands.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS 108

109 Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<STANZA_NAME>] * Each stanza represents a search command; the command is the stanza name. * The stanza name invokes the command in the search language. * Set the following attributes/values for the command. Otherwise, Splunk uses the defaults. type = <string> * Type of script: python, perl * Defaults to python. filename = <string> * Name of script file for command. * <script-name>.pl for perl. * <script-name>.py for python. local = [true false] * If true, specifies that the command should be run on the search head only * Defaults to false perf_warn_limit = <integer> * Issue a performance warning message if more than this many input events are passed to this external command (0 = never) * Defaults to 0 (disabled) streaming = [true false] * Specify whether the command is streamable. * Defaults to false. maxinputs = <integer> * Maximum number of events that can be passed to the command for each invocation. * This limit cannot exceed the value of maxresultrows in limits.conf. * 0 for no limit. * Defaults to passauth = [true false] * If set to true, passes an authentication token on the start of input. * Defaults to false. run_in_preview = [true false] * Specify whether to run this command if generating results just for preview rather than final output. * Defaults to true enableheader = [true false] * Indicate whether or not your script is expecting header information or not. * Currently, the only thing in the header information is an auth token. * If set to true it will expect as input a head section + '\n' then the csv input * NOTE: Should be set to true if you use splunk.intersplunk * Defaults to true. retainsevents = [true false] * Specify whether the command retains events (the way the sort/dedup/cluster commands do) or whether it transforms them (the way the stats command does). * Defaults to false. generating = [true false] * Specify whether your command generates new events. If no events are passed to the command, will it generate events? * Defaults to false. generates_timeorder = [true false] * If generating = true, does command generate events in descending time order (latest first) * Defaults to false. overrides_timeorder = [true false] 109

110 * If generating = false and streaming=true, does command change the order of events with respect to time? * Defaults to false. requires_preop = [true false] * Specify whether the command sequence specified by the 'streaming_preop' key is required for proper execution or is it an optimization only * Default is false (streaming_preop not required) streaming_preop = <string> * A string that denotes the requested pre-streaming search string. required_fields = <string> * A comma separated list of fields that this command may use. * Informs previous commands that they should retain/extract these fields if possible. No error is generated if a field specified is missing. * Defaults to '*' supports_multivalues = [true false] * Specify whether the command supports multivalues. * If true, multivalues will be treated as python lists of strings, instead of a flat string (when using Intersplunk to interpret stdin/stdout). * If the list only contains one element, the value of that element will be returned, rather than a list (for example, isinstance(val, basestring) == True). supports_getinfo = [true false] * Specifies whether the command supports dynamic probing for settings (first argument invoked == GETINFO or EXECUTE ). supports_rawargs = [true false] * Specifies whether the command supports raw arguments being passed to it or if it prefers parsed arguments (where quotes are stripped). * If unspecified, the default is false undo_scheduler_escaping = [true false] * Specifies whether the commands raw arguments need to be unesacped. * This is perticularly applies to the commands being invoked by the scheduler. * This applies only if the command supports raw arguments(supports_rawargs). * If unspecified, the default is false requires_srinfo = [true false] * Specifies if the command requires information stored in SearchResultsInfo. If true, requires that enableheader be set to true, and the full pathname of the info file (a csv file) will be emitted in the header under the key 'infopath' * If unspecified, the default is false needs_empty_results = [true false] * Specifies whether or not this search command needs to be called with intermediate empty search results * If unspecified, the default is true changes_colorder = [true false] * Specify whether the script output should be used to change the column ordering of the fields. * Default is true outputheader = <true/false> * If set to true, output of script should be a header section + blank line + csv output * If false, script output should be pure csv only * Default is false clear_required_fields = [true false] * If true, required_fields represents the *only* fields required. If false, required_fields are additive to any fields that may be required by subsequent commands. * In most cases, false is appropriate for streaming commands and true for reporting commands * Default is false stderr_dest = [log message none] * What do to with the stderr output from the script * 'log' means to write the output to the job's search.log. * 'message' means to write each line as an search info message. The message level can be set to adding that level (in ALL CAPS) to the start of the line, e.g. "WARN my warning message." * 'none' means to discard the stderr output * Defaults to log 110

111 commands.conf.example Version Configuration for external search commands defaults for all external commands, exceptions are below in individual stanzas type of script: 'python', 'perl' TYPE = python default FILENAME would be <stanza-name>.py for python, <stanza-name>.pl for perl and <stanza-name> otherwise is command streamable? STREAMING = false maximum data that can be passed to command (0 = no limit) MAXINPUTS = end defaults [crawl] FILENAME = crawl.py [createrss] FILENAME = createrss.py [diff] FILENAME = diff.py [gentimes] FILENAME = gentimes.py [head] FILENAME = head.py [loglady] FILENAME = loglady.py [marklar] FILENAME = marklar.py [runshellscript] FILENAME = runshellscript.py [send ] FILENAME = send .py [translate] FILENAME = translate.py [transpose] FILENAME = transpose.py [uniq] FILENAME = uniq.py [windbag] filename = windbag.py supports_multivalues = true [xmlkv] FILENAME = xmlkv.py [xmlunescape] FILENAME = xmlunescape.py 111

112 crawl.conf 다음은 crawl.conf의 사양 및 예제 파일입니다. crawl.conf.spec Version This file contains possible attribute/value pairs for configuring crawl. There is a crawl.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a crawl.conf in $SPLUNK_HOME/etc/system/local/. For help, see crawl.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Set of attribute-values used by crawl. If attribute, ends in _list, the form is: attr = val, val, val, etc. The space after the comma is necessary, so that "," can be used, as in BAD_FILE_PATTERNS's use of "*,v" GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [default] [files] * Sets file crawler-specific attributes under this stanza header. * Follow this stanza name with any of the following attributes. root = <semi-colon separate list of directories> * Set a list of directories this crawler should search through. * Defaults to /;/Library/Logs bad_directories_list = <comma-separated list of bad directories> * List any directories you don't want to crawl. * Defaults to: bin, sbin, boot, mnt, proc, tmp, temp, dev, initrd, help, driver, drivers, share, bak, old, lib, include, doc, docs, man, html, images, tests, js, dtd, org, com, net, class, java, resource, locale, static, testing, src, sys, icons, css, dist, cache, users, system, resources, examples, gdm, manual, spool, lock, kerberos,.thumbnails, libs, old, manuals, splunk, splunkpreview, mail, resources, documentation, applications, library, network, automount, mount, cores, lost\+found, fonts, extensions, components, printers, caches, findlogs, music, volumes, libexec, bad_extensions_list = <comma-separated list of file extensions to skip> * List any file extensions and crawl will skip files that end in those extensions. * Defaults to: 0t, a, adb, ads, ali, am, asa, asm, asp, au, bak, bas, bat, bmp, c, cache, cc, cg, cgi, class, clp, com, conf, config, cpp, cs, css, csv, cxx, dat, doc, dot, dvi, dylib, ec, elc, eps, exe, f, f77, f90, for, ftn, gif, h, hh, hlp, hpp, hqx, hs, htm, html, hxx, icns, ico, ics, in, inc, jar, java, jin, jpeg, jpg, js, jsp, kml, la, lai, lhs, lib, license, lo, m, m4, mcp, mid, mp3, mpg, msf, nib, nsmap, o, obj, odt, ogg, old, ook, opt, os, os2, pal, pbm, pdf, pdf, pem, pgm, php, php3, php4, pl, plex, plist, plo, plx, pm, png, po, pod, ppd, ppm, ppt, prc, presets, ps, psd, psym, py, pyc, pyd, pyw, rast, rb, rc, rde, rdf, rdr, res, rgb, ro, rsrc, s, sgml, sh, shtml, so, soap, sql, ss, stg, strings, tcl, tdt, template, tif, tiff, tk, uue, v, vhd, wsdl, xbm, xlb, xls, xlw, xml, xsd, xsl, xslt, jame, d, ac, properties, pid, del, lock, md5, rpm, pp, deb, iso, vim, lng, list bad_file_matches_list = <comma-separated list of regex> * Crawl applies the specified regex and skips files that match the patterns. 112

113 * There is an implied "$" (end of file name) after each pattern. * Defaults to: *~, *, *,v, *readme*, *install, (/ ^).*, *passwd*, *example*, *makefile, core.* packed_extensions_list = <comma-separated list of extensions> * Specify extensions of compressed files to exclude. * Defaults to: bz, bz2, tbz, tbz2, Z, gz, tgz, tar, zip collapse_threshold = <integer> * Specify the minimum number of files a source must have to be considered a directory. * Defaults to days_sizek_pairs_list = <comma-separated hyphenated pairs of integers> * Specify a comma-separated list of age (days) and size (kb) pairs to constrain what files are crawled. * For example: days_sizek_pairs_list = 7-0, tells Splunk to crawl only files last modified within 7 days and at least 0kb in size, or modified within the last 30 days and at least 1000kb in size. * Defaults to big_dir_filecount = <integer> * Skip directories with files above <integer> * Defaults to index = <$INDEX> * Specify index to add crawled files to. * Defaults to main. max_badfiles_per_dir = <integer> * Specify how far to crawl into a directory for files. * Crawl excludes a directory if it doesn't find valid files within the specified max_badfiles_per_dir. * Defaults to 100. [network] * Sets network crawler-specific attributes under this stanza header. * Follow this stanza name with any of the following attributes. host = <host or ip> * default host to use as a starting point for crawling a network * Defaults to 'localhost'. subnet = <int> * default number of bits to use in the subnet mask. Given a host with IP , a subnet value of 32, would scan only that host, and a value or 24 would scan *. * Defaults to 32. crawl.conf.example Version The following are example crawl.conf configurations. Configure properties for crawl. To use one or more of these configurations, copy the configuration block into crawl.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [files] bad_directories_list= bin, sbin, boot, mnt, proc, tmp, temp, home, mail,.thumbnails, cache, old bad_extensions_list= mp3, mpg, jpeg, jpg, m4, mcp, mid bad_file_matches_list= *example*, *makefile, core.* packed_extensions_list= gz, tgz, tar, zip collapse_threshold= 10 days_sizek_pairs_list= 3-0,7-1000, big_dir_filecount=

114 index=main max_badfiles_per_dir=100 [network] host = myserver subnet = 24 datamodels.conf 다음은 datamodels.conf의 사양 및 예제 파일입니다. datamodels.conf.spec Version This file contains possible attribute/value pairs for configuring datamodels. To configure a datamodel for an app, put your custom datamodels.conf in $SPLUNK_HOME/etc/apps/MY_APP/local/ For examples, see datamodels.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<datamodel_name>] * Each stanza represents a datamodel; the datamodel name is the stanza name. acceleration = <bool> * Set this to true to enable automatic acceleration of this datamodel * Automatic acceleration will create auxiliary column stores for the fields and values in the events for this datamodel on a per-bucket basis. * These column stores take additional space on disk so be sure you have the proper amount of disk space. Additional space required depends on the number of events, fields, and distinct field values in the data. * These column stores are created and maintained on a schedule you can specify with 'acceleration.cron_schedule', and can be later queried with the 'tstats' command acceleration.earliest_time = <relative-time-str> * Specifies how far back in time Splunk should keep these column stores (and create if acceleration.backfill_time is not set) * Specified by a relative time string, e.g. '-7d' accelerate data within the last 7 days * Defaults to the empty string, meaning keep these stores for all time acceleration.backfill_time = <relative-time-str> * ADVANCED: Specifies how far back in time Splunk should create these column stores * ONLY set this parameter if you want to backfill less data than your retention period set by 'acceleration.earliest_time'. You may want to use this to limit your time window for creation in a large environment where initially creating all of the stores is an expensive operation. * WARNING: If one of your indexers is down for a period longer than this backfill time, you may miss accelerating a window of your incoming data. It is for this reason we do not recommend setting this to a small window. * MUST be set to a more recent time than acceleration.earliest_time. For example, if earliest time is set to '-1y' to keep the stores for a 1 year window, you could set backfill to '-20d' to only create stores for data from the last 20 days. However, you could not set backfill to '-2y', as that's farther back in time than '-1y' * If empty or unset (default), Splunk will always backfill fully to acceleration.earliest_time 114

115 acceleration.max_time = <unsigned int> * The maximum amount of time that the column store creation search is allowed to run (in seconds) * Note that this is an approximate time, as the 'summarize' search will only finish on clean bucket boundaries to avoid wasted work * Defaults to: 3600 * 0 implies no limit acceleration.cron_schedule = <cron-string> * Cron schedule to be used to probe/generate the column stores for this datamodel acceleration.manual_rebuilds = <bool> * This is an ADVANCED command. * Normally, the 'summarize' command will automatically rebuild summaries during the creation phase that are considered to be out of-date, such as when the configuration backing the data model changes. * A summary being out of date implies that the datamodel search stored in the metadata for this summary no longer matches the current datamodel search, OR the search in the metadata can no longer be parsed. * If set to true, out-of-date summaries are not rebuilt by the 'summarize' command. * NOTE: If we find a partial summary be out of date, we will always rebuild that summary so that a bucket summary only has results corresponding to one datamodel search. * Defaults to false datamodels.conf.example Version Configuration for example datamodels An example of accelerating data for the 'mymodel' datamodel for the past five days, generating and checking the column stores every 10 minutes [mymodel] acceleration = true acceleration.earliest_time = -5d acceleration.cron_schedule = */10 * * * * datatypesbnf.conf 다음은 datatypesbnf.conf의 사양 및 예제 파일입니다. datatypesbnf.conf.spec Version This file effects how the search assistant (typeahead) shows the syntax for search commands [<syntax-type>] * The name of the syntax type you're configuring. * Follow this field name with one syntax= definition. * Syntax type can only contain a-z, and -, but cannot begin with - syntax = <string> * The syntax for you syntax type. * Should correspond to a regular expression describing the term. * Can also be a <field> or other similar value. datatypesbnf.conf.example No example default.meta.conf 115

116 다음은 default.meta.conf의 사양 및 예제 파일입니다. default.meta.conf.spec Version *.meta files contain ownership information, access controls, and export settings for Splunk objects like saved searches, event types, and views. Each app has its own default.meta file. Interaction of ACLs across app-level, category level, and specific object configuration: * To access/use an object, users must have read access to: * the app containing the object * the generic category within the app (eg [views]) * the object itself * If any layer does not permit read access, the object will not be accessible. * To update/modify an object, such as to edit a saved search, users must have: * read and write access to the object * read access to the app, to locate the object * read access to the generic category within the app (eg. [savedsearches]) * If object does not permit write access to the user, the object will not be modifiable. * If any layer does not permit read access to the user, the object will not be accessible in order to modify * In order to add or remove objects from an app, users must have: * write access to the app * If users do not have write access to the app, an attempt to add or remove an object will fail. * Objects that are exported to other apps or to system context have no change to their accessibility rules. Users must still have read access to the containing app, category, and object, despite the export. Set access controls on the app containing this metadata file. [] access = read : [ * ], write : [ admin, power ] * Allow all users to read this app's contents. Unless overridden by other metadata, allow only admin and power users to share objects into this app. Set access controls on this app's views. [views] access = read : [ * ], write : [ admin ] * Allow all users to read this app's views. Allow only admin users to create, * remove, share, or unshare views in this app. Set access controls on a specific view in this app. [views/index_status] access = read : [ admin ], write : [ admin ] * Allow only admin users to read or modify this view. Make this view available in all apps. export = system * To make this view available only in this app, set 'export = none' instead. owner = admin * Set admin as the owner of this view. default.meta.conf.example Version This file contains example patterns for the metadata files default.meta and local.meta 116

117 This example would make all of the objects in an app globally accessible to all apps [] export=system default-mode.conf 다음은 default-mode.conf의 사양 및 예제 파일입니다. default-mode.conf.spec Version This file documents the syntax of default-mode.conf for comprehension and troubleshooting purposes. default-mode.conf is a file that exists primarily for Splunk Support and Services to configure splunk. CAVEATS: DO NOT make changes to default-mode.conf without coordinating with Splunk Support or Services. End-user changes to default-mode.conf are not supported. default-mode.conf *will* be removed in a future version of Splunk, along with the entire configuration scheme that it affects. Any settings present in default-mode.conf files will be completely ignored at this point. Any number of seemingly reasonable configurations in default-mode.conf might fail to work, behave bizarrely, corrupt your data, iron your cat, cause unexpected rashes, or order unwanted food delivery to your house. Changes here alter the way that pieces of code will communicate which are only intended to be used in a specific configuration. INFORMATION: The main value of this spec file is to assist in reading these files for troubleshooting purposes. default-mode.conf was originally intended to provide a way to describe the alternate setups used by the Splunk Light Forwarder and Splunk Universal Forwarder. The only reasonable action is to re-enable input pipelines that are disabled by default in those forwarder configurations. However, keep the prior caveats in mind. Any future means of enabling inputs will have a different form when this mechanism is removed. SYNTAX: [pipeline:<string>] disabled = true false disabled_processors = <string> [pipeline:<string>] * Refers to a particular Splunkd pipeline. * The set of named pipelines is a splunk-internal design. That does not mean that the Splunk design is a secret, but it means it is not external for the purposes of configuration. * Useful information on the data processing system of splunk can be found in the external documentation, for example disabled = true false * If set to true on a specific pipeline, the pipeline will not be loaded in the system. disabled_processors = <processor1>, <processor2> 117

118 * Processors which normally would be loaded in this pipeline are not loaded if they appear in this list * The set of named procoessors is again a splunk-internal design component. default-mode.conf.example No example deployment.conf 다음은 deployment.conf의 사양 및 예제 파일입니다. deployment.conf.spec Version *** DEPRECATED *** This configuration has been deprecated in favor of the following: 1.) deploymentclient.conf - for configuring Deployment Clients. 2.) serverclass.conf - for Deployment Server service class configuration. 3.) tenants.conf - for launching multiple Deployment Servers from the same Splunk instance. Compatibility: Splunk 4.x Deployment Server is NOT compatible with Splunk 3.x Deployment Clients. deployment.conf.example No example deploymentclient.conf 다음은 deploymentclient.conf의 사양 및 예제 파일입니다. deploymentclient.conf.spec Version This file contains possible attributes and values for configuring a deployment client to receive content (apps and configurations) from a deployment server. To customize the way a deployment client behaves, place a deploymentclient.conf in $SPLUNK_HOME/etc/system/local/ on that Splunk instance. Configure what apps or configuration content is deployed to a given deployment client in serverclass.conf. Refer to serverclass.conf.spec and serverclass.conf.example for more information. You must restart Splunk for changes to this configuration file to take effect. To learn more about configuration files (including precedence) please see the documentation located at *************************************************************************** Configure a Splunk deployment client. Note: At a minimum the [deployment-client] stanza is required in deploymentclient.conf for deployment client to be enabled. *************************************************************************** GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. 118

119 * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [deployment-client] disabled = [false true] * Defaults to false * Enable/Disable deployment client. clientname = deploymentclient * Defaults to deploymentclient. * A name that the deployment server can filter on. * Takes precedence over DNS names. workingdir = $SPLUNK_HOME/var/run * Temporary folder used by the deploymentclient to download apps and configuration content. repositorylocation = $SPLUNK_HOME/etc/apps * The location into which content is installed after being downloaded from a deployment server. * Apps and configuration content must be installed into the default location ($SPLUNK_HOME/etc/apps) or it will not be recognized by the Splunk instance on the deployment client. * Note: Apps and configuration content to be deployed may be located in an alternate location on the deployment server. Set both repositorylocation and serverrepositorylocationpolicy explicitly to ensure that the content is installed into the correct location ($SPLUNK_HOME/etc/apps) on the deployment client. * The deployment client uses the 'serverrepositorylocationpolicy' defined below to determine which value of repositorylocation to use. serverrepositorylocationpolicy = [acceptsplunkhome acceptalways rejectalways] * Defaults to acceptsplunkhome. * acceptsplunkhome - accept the repositorylocation supplied by the deployment server, only if it is rooted by $SPLUNK_HOME. * acceptalways - always accept the repositorylocation supplied by the deployment server. * rejectalways - reject the server supplied value and use the repositorylocation specified in the local deploymentclient.conf. endpoint=$deploymentserveruri$/services/streams/deployment?name=$serverclassname$:$appname$ * The HTTP endpoint from which content should be downloaded. * Note: The deployment server may specify a different endpoint from which to download each set of content (individual apps, etc). * The deployment client will use the serverendpointpolicy defined below to determine which value to use. * $deploymentserveruri$ will resolve to targeturi defined in the [target-broker] stanza below. * $serverclassname$ and $appname$ mean what they say. serverendpointpolicy = [acceptalways rejectalways] * defaults to acceptalways * acceptalways - always accept the endpoint supplied by the server. * rejectalways - reject the endpoint supplied by the server. Always use the 'endpoint' definition above. phonehomeintervalinsecs = <integer in seconds> * Defaults to 60. * This determines how frequently this deployment client should check for new content. handshakeretryintervalinsecs = <integer in seconds> * Defaults to phonehomeintervalinsecs * This sets the handshake retry frequency. * Could be used to tune the initial connection rate on a new server Advanced! You should use this property only when you have a hierarchical deployment server installation, and have a Splunk instance that behaves as both a DeploymentClient and a DeploymentServer. reloaddsonappinstall = [false true] * Defaults to false * Setting this flag to true will cause the deploymentserver on this Splunk instance to be reloaded whenever an app is installed by this deploymentclient. 119

120 The following stanza specifies deployment server connection information [target-broker:deploymentserver] targeturi= <deploymentserver>:<mgmtport> * URI of the deployment server. phonehomeintervalinsecs = <nonnegative integer> * see phonehomeintervalinsecs above deploymentclient.conf.example Version Example 1 Deployment client receives apps and places them into the same repositorylocation (locally, relative to $SPLUNK_HOME) as it picked them up from. This is typically $SPLUNK_HOME/etc/apps. There is nothing in [deployment-client] because the deployment client is not overriding the value set on the deployment server side. [deployment-client] [target-broker:deploymentserver] targeturi= deploymentserver.splunk.mycompany.com:8089 Example 2 Deployment server keeps apps to be deployed in a non-standard location on the server side (perhaps for organization purposes). Deployment client receives apps and places them in the standard location. Note: Apps deployed to any location other than $SPLUNK_HOME/etc/apps on the deployment client side will not be recognized and run. This configuration rejects any location specified by the deployment server and replaces it with the standard client-side location. [deployment-client] serverrepositorylocationpolicy = rejectalways repositorylocation = $SPLUNK_HOME/etc/apps [target-broker:deploymentserver] targeturi= deploymentserver.splunk.mycompany.com:8089 Example 3 Deployment client should get apps from an HTTP server that is different from the one specified by the deployment server. [deployment-client] serverendpointpolicy = rejectalways endpoint = [target-broker:deploymentserver] targeturi= deploymentserver.splunk.mycompany.com:8089 Example 4 Deployment client should get apps from a location on the file system and not from a location specified by the deployment server [deployment-client] serverendpointpolicy = rejectalways endpoint = file:/<some_mount_point>/$serverclassname$/$appname$.tar [target-broker:deploymentserver] targeturi= deploymentserver.splunk.mycompany.com:8089 handshakeretryintervalinsecs=20 120

121 distsearch.conf 다음은 distsearch.conf의 사양 및 예제 파일입니다. distsearch.conf.spec Version This file contains possible attributes and values you can use to configure distributed search. There is NO DEFAULT distsearch.conf. To set custom configurations, place a distsearch.conf in $SPLUNK_HOME/etc/system/local/. For examples, see distsearch.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at These attributes are all configured on the search head, with the exception of the optional attributes listed under the SEARCH HEAD BUNDLE MOUNTING OPTIONS heading, which are configured on the search peers. GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [distributedsearch] * Set distributed search configuration options under this stanza name. * Follow this stanza name with any number of the following attribute/value pairs. * If you do not set any attribute, Splunk uses the default value (if there is one listed). disabled = [true false] * Toggle distributed search off (true) and on (false). * Defaults to false (your distributed search stanza is enabled by default). heartbeatmcastaddr = <IP address> * This setting is deprecated heartbeatport = <port> * This setting is deprecated ttl = <integer> * This setting is deprecated heartbeatfrequency = <int, in seconds> * This setting is deprecated statustimeout = <int, in seconds> * Set connection timeout when gathering a search peer's basic info (/services/server/info). * Note: Read/write timeouts are automatically set to twice this value. * Defaults to 10. removedtimedoutservers = [true false] * This setting is no longer supported, and will be ignored. checktimedoutserversfrequency = <integer, in seconds> * This setting is no longer supported, and will be ignored. autoaddservers = [true false] * This setting is deprecated besteffortsearch = [true false] * Whether to remove a peer from search when it does not have any of our bundles. * If set to true searches will never block on bundle replication, even when a peer is first adde - the * peers that don't have any common bundles will simply not be searched. 121

122 * Defaults to false skipourselves = [true false] * This setting is deprecated servers = <comma separated list of servers> * Initial list of servers. disabled_servers = <comma separated list of servers> * A list of configured but disabled search peers. sharebundles = [true false] * Indicates whether this server will use bundle replication to share search time configuration with search peers. * If set to false, the search head assumes that all the search peers can access the correct bundles via share storage and have configured the options listed under "SEARCH HEAD BUNDLE MOUNTING OPTIONS". * Defaults to true. useshpbundlereplication = <bool> always * Relevant only in search head pooling environments. Whether the search heads in the pool should compete * with each other to decide which one should handle the bundle replication (every time bundle replication * needs to happen) or whether each of them should individually replicate the bundles. * When set to always and bundle mounting is being used then use the search head pool guid rather than * each individual server name to identify bundles (and search heads to the remote peers). * Defaults to true trysslfirst = <bool> * Controls whether the search head attempts HTTPS or HTTP connection when a new peer is added, or * during a restart. If value is missing true is assumed. * Defaults to true peerresolutionthreads = <int> * Controls how many threads to use to resolve peers during a restart. Or forced bundle syncronization. * Defaults 0 (Use no threads) servertimeout = <int, in seconds> * DEPRECATED, please use connectiontimeout, sendtimeout, receivetimeout connectiontimeout = <int, in seconds> * Amount of time in seconds to use as a timeout during search peer connection establishment. sendtimeout = <int, in seconds> * Amount of time in seconds to use as a timeout while trying to write/send data to a search peer. receivetimeout = <int, in seconds> * Amount of time in seconds to use as a timeout while trying to read/receive data from a search peer. authtokenconnectiontimeout = <int, in seconds> * Maximum number of seconds to connect to a remote search peer, when getting its auth token * Default is 5 authtokensendtimeout = <int, in seconds> * Maximum number of seconds to send a request to the remote peer, when getting its auth token * Default is 10 authtokenreceivetimeout = <int, in seconds> * Maximum number of seconds to receive a response from a remote peer, when getting its auth token * Default is 10 ****************************************************************************** DISTRIBUTED SEARCH KEY PAIR GENERATION OPTIONS ****************************************************************************** [tokenexchkeys] certdir = <directory> * This directory contains the local Splunk instance's distributed search key pair. * This directory also contains the public keys of servers that distribute searches to this Splunk instance. publickey = <filename> * Name of public key file for this Splunk instance. 122

123 privatekey = <filename> * Name of private key file for this Splunk instance. genkeyscript = <command> * Command used to generate the two files above. ****************************************************************************** REPLICATION SETTING OPTIONS ****************************************************************************** [replicationsettings] connectiontimeout = <int, in seconds> * The maximum number of seconds to wait before timing out on initial connection to a peer. sendrcvtimeout = <int, in seconds> * The maximum number of seconds to wait for the sending of a full replication to a peer. replicationthreads = <int> * The maximum number of threads to use when performing bundle replication to peers. * Must be a positive number * Defaults to 5. maxmemorybundlesize = <int> * The maximum size (in MB) of bundles to hold in memory. If the bundle is larger than this * the bundles will be read and encoded on the fly for each peer the replication is taking place. * Defaults to 10 maxbundlesize = <int> * The maximum size (in MB) of the bundle for which replication can occur. If the bundle is larger than this * bundle replication will not occur and an error message will be logged. * Defaults to: 1024 (1GB) concerningreplicatedfilesize = <int> * Any individual file within a bundle that is larger than this value (in MB) will trigger a splunkd.log message. * Where possible, avoid replicating such files, e.g. by customizing your blacklists. * Defaults to: 50 allowstreamupload = auto true false * Whether to enable streaming bundle replication for peers. * If set to auto, streaming bundle replication will be used when connecting to peers with a complete implementation of this feature (Splunk 6.0 or higher). * If set to true, streaming bundle replication will be used when connecting to peers with a complete or experimental implementation of this feature (Splunk or higher). * If set to false, streaming bundle replication will never be used. * Whatever the value of this setting, streaming bundle replication will not be used for peers that completely lack support for this feature. * Defaults to: auto allowskipencoding = <bool> * Whether to avoid URL-encoding bundle data on upload. * Defaults to: true allowdeltaupload = <bool> * Whether to enable delta-based bundle replication. * Defaults to: true sanitizemetafiles = <bool> * Whether to sanitize or filter *.meta files before replication. * This feature can be used to avoid unnecessary replications triggered by writes to *.meta files that have no real effect on search behavior. * The types of stanzas that "survive" filtering are configured via the replicationsettings:refineconf stanza. * The filtering process removes comments and cosmetic whitespace. * Defaults to: true [replicationsettings:refineconf] replicate.<conf_file_name> = <bool> * Controls whether Splunk replicates a particular type of *.conf file, along with any associated permissions in *.meta files. * These settings on their own do not cause files to be replicated. A file must still be whitelisted (via replicationwhitelist) to be eligible for inclusion via these settings. 123

124 * In a sense, these settings constitute another level of filtering that applies specifically to *.conf files and stanzas with *.meta files. * Defaults to: false ****************************************************************************** REPLICATION WHITELIST OPTIONS ****************************************************************************** [replicationwhitelist] <name> = <whitelist_pattern> * Controls Splunk's search-time conf replication from search heads to search nodes. * Only files that match a whitelist entry will be replicated. * Conversely, files which are not matched by any whitelist will not be replicated. * Only files located under $SPLUNK_HOME/etc will ever be replicated in this way. * The regex will be matched against the filename, relative to $SPLUNK_HOME/etc. Example: for a file "$SPLUNK_HOME/etc/apps/fancy_app/default/inputs.conf" this whitelist should match "apps/fancy_app/default/inputs.conf" * Similarly, the etc/system files are available as system/... user-specific files are available as users/username/appname/... * The 'name' element is generally just descriptive, with one exception: if <name> begins with "refine.", files whitelisted by the given pattern will also go through another level of filtering configured in the replicationsettings:refineconf stanza. * The whitelist_pattern is the Splunk-style pattern matching, which is primarily regex-based with special local behavior for '...' and '*'. *... matches anything, while * matches anything besides directory separators. See props.conf.spec for more detail on these. * Note '.' will match a literal dot, not any character. * Note that these lists are applied globally across all conf data, not to any particular app, regardless of where they are defined. Be careful to pull in only your intended files. ****************************************************************************** REPLICATION BLACKLIST OPTIONS ****************************************************************************** [replicationblacklist] <name> = <blacklist_pattern> * All comments from the replication whitelist notes above also apply here. * Replication blacklist takes precedence over the whitelist, meaning that a file that matches both the whitelist and the blacklist will NOT be replicated. * This can be used to prevent unwanted bundle replication in two common scenarios: * Very large files, which part of an app may not want to be replicated, especially if they are not needed on search nodes. * Frequently updated files (for example, some lookups) will trigger retransmission of all search head data. * Note that these lists are applied globally across all conf data. Especially for blacklisting, be careful to constrain your blacklist to match only data your application will not need. ****************************************************************************** BUNDLE ENFORCER WHITELIST OPTIONS ****************************************************************************** [bundleenforcerwhitelist] <name> = <whitelist_pattern> * Peers uses this to make sure knowledge bundle sent by search heads and masters do not contain alien files. * If this stanza is empty, the receiver accepts the bundle unless it contains files matching the rules specified in [bundleenforcerblacklist]. Hence, if both [bundleenforcerwhitelist] and [bundleenforcerblacklist] are empty (which is the default), then the receiver accepts all bundles. * If this stanza is not empty, the receiver accepts the bundle only if it contains only files that match the rules specified here but not those in [bundleenforcerblacklist]. * All rules are regexs. * This stanza is empty by default. ****************************************************************************** BUNDLE ENFORCER BLACKLIST OPTIONS ****************************************************************************** 124

125 [bundleenforcerblacklist] <name> = <blacklist_pattern> * Peers uses this to make sure knowledge bundle sent by search heads and masters do not contain alien files. * This list overrides [bundleenforcewhitelist] above. That means the receiver rejects (i.e. removes) the bundle if it contains any file that matches the rules specified here even if that file is allowed by [bundleenforcerwhitelist]. * If this stanza is empty, then only [bundleenforcerwhitelist] matters. * This stanza is empty by default. ****************************************************************************** SEARCH HEAD BUNDLE MOUNTING OPTIONS You set these attributes on the search peers only, and only if you also set sharebundles=false in [distributedsearch] on the search head. Use them to achieve replication-less bundle access. The search peers use a shared storage mountpoint to access the search head bundles ($SPLUNK_HOME/etc). ****************************************************************************** [searchhead:<searchhead-splunk-server-name>] * <searchhead-splunk-server-name> is the name of the related searchhead installation. * This setting is located in server.conf, servername = <name> mounted_bundles = [true false] * Determines whether the bundles belong to the search head specified in the stanza name are mounted. * You must set this to "true" to use mounted bundles. * Default is "false". bundles_location = <path_to_bundles> * The path to where the search head's bundles are mounted. This must be the mountpoint on the search peer, * not on the search head. This should point to a directory that is equivalent to $SPLUNK_HOME/etc/. It must * contain at least the following subdirectories: system, apps, users. ****************************************************************************** DISTRIBUTED SEARCH GROUP DEFINITIONS These are the definitions of the distributed search groups. A search group is a set of search peers as identified by thier host:management-port. Searches may be directed to a search group using the splunk_server_group arguments.the searches will be defined only against the members of that group. ****************************************************************************** [distributedsearch:<splunk-server-group-name>] * <splunk-server-group-name> is the name of the splunk-server-group that is * defined in this stanza servers = <comma separated list of servers> * List of search peers that are members of this group. Comma serparated list * of hot:port in the same format as the servers field of the distributedsearch * stanza default = [true false] * Will set this as the default group of peers against which all searches are run * unless a server-group is not explicitly specified. distsearch.conf.example Version These are example configurations for distsearch.conf. Use this file to configure distributed search. For all available attribute/value pairs, see distsearch.conf.spec. There is NO DEFAULT distsearch.conf. To use one or more of these configurations, copy the configuration block into distsearch.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at 125

126 [distributedsearch] servers = :8059, :8059 This entry distributes searches to :8059, :8059. Attributes not set here will use the defaults listed in distsearch.conf.spec. this stanza controls the timing settings for connecting to a remote peer and the send timeout [replicationsettings] connectiontimeout = 10 sendrcvtimeout = 60 this stanza controls what files are replicated to the other peer each is a regex [replicationwhitelist] allconf = *.conf Mounted bundles example. This example shows two distsearch.conf configurations, one for the search head and another for each of the search head's search peers. It shows only the attributes necessary to implement mounted bundles. On a search head whose Splunk server name is "searcher01": [distributedsearch]... sharebundles = false On each search peer: [searchhead:searcher01] mounted_bundles = true bundles_location = /opt/shared_bundles/searcher01 eventdiscoverer.conf 다음은 eventdiscoverer.conf의 사양 및 예제 파일입니다. eventdiscoverer.conf.spec Version This file contains possible attributes and values you can use to configure event discovery through the search command "typelearner." There is an eventdiscoverer.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place an eventdiscoverer.conf in $SPLUNK_HOME/etc/system/local/. For examples, see eventdiscoverer.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. ignored_keywords = <comma-separated list of terms> * If you find that event types have terms you do not want considered (for example, "mylaptopname"), add that term to this list. * Terms in this list are never considered for defining an event type. * For more details, refer to $SPLUNK_HOME/etc/system/default/eventdiscoverer.conf). * Default = "sun, mon, tue,..." ignored_fields = <comma-separated list of fields> * Similar to ignored_keywords, except these are fields as defined in Splunk instead of terms. * Defaults include time-related fields that would not be useful for defining an event type. important_keywords = <comma-separated list of terms> * When there are multiple possible phrases for generating an eventtype search, those phrases with 126

127 important_keyword terms are favored. For example, "fatal error" would be preferred over "last message repeated", as "fatal" is an important keyword. * Default = "abort, abstract, accept,..." (see $SPLUNK_HOME/etc/system/default/eventdiscoverer.conf). eventdiscoverer.conf.example Version This is an example eventdiscoverer.conf. These settings are used to control the discovery of common eventtypes used by the typelearner search command. To use one or more of these configurations, copy the configuration block into eventdiscoverer.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Terms in this list are never considered for defining an eventtype. ignored_keywords = foo, bar, application, kate, charlie Fields in this list are never considered for defining an eventtype. ignored_fields = pid, others, directory event_renderers.conf 다음은 event_renderers.conf의 사양 및 예제 파일입니다. event_renderers.conf.spec Version This file contains possible attribute/value pairs for configuring event rendering properties. Beginning with version 6.0, Splunk Enterprise does not support the customization of event displays using event renderers. There is an event_renderers.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place an event_renderers.conf in $SPLUNK_HOME/etc/system/local/, or your own custom app directory. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<name>] * Stanza name. This name must be unique. eventtype = <event type> * Specify event type name from eventtypes.conf. priority = <positive integer> * Highest number wins!! template = <valid Mako template> * Any template from the $APP/appserver/event_renderers directory. css_class = <css class name suffix to apply to the parent event element class attribute> * This can be any valid css class value. * The value is appended to a standard suffix string of "splevent-". A css_class value of foo would 127

128 result in the parent element of the event having an html attribute class with a value of splevent-foo (for example, class="splevent-foo"). You can externalize your css style rules for this in $APP/appserver/static/application.css. For example, to make the text red you would add to application.css:.splevent-foo { color:red; } event_renderers.conf.example Version DO NOT EDIT THIS FILE! Please make all changes to files in $SPLUNK_HOME/etc/system/local. To make changes, copy the section/stanza you want to change from $SPLUNK_HOME/etc/system/default into../local and edit there. This file contains mappings between Splunk eventtypes and event renderers. Beginning with version 6.0, Splunk Enterprise does not support the customization of event displays using event renderers. [event_renderer_1] eventtype = hawaiian_type priority = 1 css_class = EventRenderer1 [event_renderer_2] eventtype = french_food_type priority = 1 template = event_renderer2.html css_class = EventRenderer2 [event_renderer_3] eventtype = japan_type priority = 1 css_class = EventRenderer3 eventtypes.conf 다음은 eventtypes.conf의 사양 및 예제 파일입니다. eventtypes.conf.spec Version This file contains all possible attributes and value pairs for an eventtypes.conf file. Use this file to configure event types and their properties. You can also pipe any search to the "typelearner" command to create event types. Event types created this way will be written to $SPLUNK_HOME/etc/systems/local/eventtypes.conf. There is an eventtypes.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place an eventtypes.conf in $SPLUNK_HOME/etc/system/local/. For examples, see eventtypes.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<$EVENTTYPE>] * Header for the event type * $EVENTTYPE is the name of your event type. 128

129 * You can have any number of event types, each represented by a stanza and any number of the following attribute/value pairs. * NOTE: If the name of the event type includes field names surrounded by the percent character (for example "%$FIELD%") then the value of $FIELD is substituted into the event type name for that event. For example, an event type with the header [cisco-%code%] that has "code=432" becomes labeled "cisco-432". disabled = [1 0] * Toggle event type on or off. * Set to 0 to disable. search = <string> * Search terms for this event type. * For example: error OR warn. priority = <integer, 1 through 10> * Value used to determine the order in which the matching eventtypes of an event are displayed. * 1 is the highest and 10 is the lowest priority. description = <string> * Optional human-readable description of this saved search. tags = <string> * DEPRECATED - see tags.conf.spec eventtypes.conf.example Version This file contains an example eventtypes.conf. Use this file to configure custom eventtypes. To use one or more of these configurations, copy the configuration block into eventtypes.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at The following example makes an eventtype called "error" based on the search "error OR fatal." [error] search = error OR fatal The following example makes an eventtype template because it includes a field name surrounded by the percent character (in this case "%code%"). The value of "%code%" is substituted into the event type name for that event. For example, if the following example event type is instantiated on an event that has a "code=432," it becomes "cisco-432". [cisco-%code%] search = cisco fields.conf 다음은 fields.conf의 사양 및 예제 파일입니다. fields.conf.spec Version This file contains possible attribute and value pairs for: * Telling Splunk how to handle multi-value fields. * Distinguishing indexed and extracted fields. * Improving search performance by telling the search processor how to handle field values. 129

130 Use this file if you are creating a field at index time (not advised). There is a fields.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a fields.conf in $SPLUNK_HOME/etc/system/local/. For examples, see fields.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<field name>] * Name of the field you're configuring. * Follow this stanza name with any number of the following attribute/value pairs. * Field names can only contain a-z, A-Z, 0-9, and _, but cannot begin with a number or _ TOKENIZER indicates that your configured field's value is a smaller part of a token. For example, your field's value is "123" but it occurs as "foo123" in your event. TOKENIZER = <regular expression> * Use this setting to configure multivalue fields (refer to the online documentation for multivalue fields). * A regular expression that indicates how the field can take on multiple values at the same time. * If empty, the field can only take on a single value. * Otherwise, the first group is taken from each match to form the set of values. * This setting is used by the "search" and "where" commands, the summary and XML outputs of the asynchronous search API, and by the top, timeline and stats commands. * Tokenization of indexed fields (INDEXED = true) is not supported so this attribute is ignored for indexed fields. * Default to empty. INDEXED = [true false] * Indicate whether a field is indexed or not. * Set to true if the field is indexed. * Set to false for fields extracted at search time (the majority of fields). * Defaults to false. INDEXED_VALUE = [true false <sed-cmd> <simple-substitution-string>] * Set this to true if the value is in the raw text of the event. * Set this to false if the value is not in the raw text of the event. * Setting this to true expands any search for key=value into a search of value AND key=value (since value is indexed). * For advanced customization, this setting supports sed style substitution. For example, 'INDEXED_VALUE=s/foo/bar/g' would take the value of the field, replace all instances of 'foo' with 'bar,' and use that new value as the value to search in the index. * This setting also supports a simple substitution based on looking for the literal string '<VALUE>' (including the '<' and '>' characters). For example, 'INDEXED_VALUE=source::*<VALUE>*' would take a search for 'myfield=myvalue' and search for 'source::*myvalue*' in the index as a single term. * For both substitution constructs, if the resulting string starts with a '[', Splunk interprets the string as a Splunk LISPY expression. For example, 'INDEXED_VALUE=[OR <VALUE> source::*<value>]' would turn 'myfield=myvalue' into applying the LISPY expression '[OR myvalue source::*myvalue]' (meaning it matches either 'myvalue' or 'source::*myvalue' terms). * Defaults to true. * NOTE: You only need to set indexed_value if indexed = false. fields.conf.example Version This file contains an example fields.conf. Use this file to configure dynamic field extractions. To use one or more of these configurations, copy the configuration block into fields.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to 130

131 enable configurations. To learn more about configuration files (including precedence) please see the documentation located at These tokenizers result in the values of To, From and Cc treated as a list, where each list element is an address found in the raw string of data. [To] TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w) [From] TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w) [Cc] TOKENIZER = (\w[\w\.\-]*@[\w\.\-]*\w) indexes.conf 다음은 indexes.conf의 사양 및 예제 파일입니다. indexes.conf.spec Version This file contains all possible options for an indexes.conf file. Use this file to configure Splunk's indexes and their properties. There is an indexes.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place an indexes.conf in $SPLUNK_HOME/etc/system/local/. For examples, see indexes.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at CAUTION: You can drastically affect your Splunk installation by changing these settings. Consult technical support ( if you are not sure how to configure this file. DO NOT change the attribute QueryLanguageDefinition without consulting technical support. GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. sync = <nonnegative integer> * The index processor syncs events every <integer> number of events. * Set to 0 to disable. * Defaults to 0. * Highest legal value is defaultdatabase = <index name> * If no index is specified during search, Splunk searches the default index. * The specified index displays as the default in Splunk Manager settings. * Defaults to "main". querylanguagedefinition = <path to file> * DO NOT EDIT THIS SETTING. SERIOUSLY. * The path to the search language definition file. * Defaults to $SPLUNK_HOME/etc/searchLanguage.xml. blocksignaturedatabase = <index name> * This is the index that stores block signatures of events. * Defaults to "_blocksignature". 131

132 mempoolmb = <positive integer> auto * Determines how much memory is given to the indexer memory pool. This restricts the number of outstanding events in the indexer at any given time. * Must be greater than 0; maximum value is (which corresponds to 1 TB) * Setting this too high can lead to splunkd memory usage going up substantially. * Setting this too low can degrade splunkd indexing performance. * Setting this to "auto" or an invalid value will cause Splunk to autotune this parameter. * Defaults to "auto". * The values derived when "auto" is seen are as follows: * System Memory Available less than... mempoolmb 1 GB 64 MB 2 GB 128 MB 8 GB 128 MB 8 GB or higher 512 MB * Only set this value if you are an expert user or have been advised to by Splunk Support. * CARELESSNESS IN SETTING THIS MAY LEAD TO PERMANENT BRAIN DAMAGE OR LOSS OF JOB. indexthreads = <nonnegative integer> auto * Determines the number of threads to use for indexing. * Must be at least 1 and no more than 16. * This value should not be set higher than the number of processor cores in the box. * If splunkd is also doing parsing and aggregation, the number should be set lower than the total number of processors minus two. * Setting this to "auto" or an invalid value will cause Splunk to autotune this parameter. * Defaults to "auto". * Only set this value if you are an expert user or have been advised to by Splunk Support. * CARELESSNESS IN SETTING THIS MAY LEAD TO PERMANENT BRAIN DAMAGE OR LOSS OF JOB. assureutf8 = true false * Verifies that all data retrieved from the index is proper UTF8. * Will degrade indexing performance when enabled (set to true). * Can only be set globally, by specifying in the [default] stanza. * Defaults to false. enablerealtimesearch = true false * Enables real-time searches. * Defaults to true. suppressbannerlist = <comma-separated list of strings> * suppresses index missing warning banner messages for specified indexes * Defaults to empty maxrunningprocessgroups = <positive integer> * splunkd fires off helper child processes like splunk-optimize, recover-metadata, etc. This param limits how many child processes can be running at any given time. * This maximum applies to entire splunkd, not per index. If you have N indexes, there will be at most maxrunningprocessgroups child processes, not N*maxRunningProcessGroups * Must maintain maxrunningprocessgroupslowpriority < maxrunningprocessgroups * This is an advanced parameter; do NOT set unless instructed by Splunk Support * Defaults to 8 (note: up until 5.0 it defaulted to 20) * Highest legal value is maxrunningprocessgroupslowpriority = <positive integer> * Of the maxrunningprocessgroups (q.v.) helper child processes, at most maxrunningprocessgroupslowpriority may be low-priority (e.g. fsck) ones. * This maximum applies to entire splunkd, not per index. If you have N indexes, there will be at most maxrunningprocessgroupslowpriority low-priority child processes, not N*maxRunningProcessGroupsLowPriority * Must maintain maxrunningprocessgroupslowpriority < maxrunningprocessgroups * This is an advanced parameter; do NOT set unless instructed by Splunk Support * Defaults to 1 * Highest legal value is bucketrebuildmemoryhint = <positive integer>[kb MB GB] auto * Suggestion for the bucket rebuild process for the size (bytes) of tsidx file it will try to build. * Larger files use more memory in rebuild, but rebuild will fail if there is not enough. * Smaller files make the rebuild take longer during the final optimize step. * Note: this value is not a hard limit on either rebuild memory usage or tsidx size. * This is an advanced parameter, do NOT set this unless instructed by Splunk Support. * Defaults to "auto", which varies by the amount of physical RAM on the host * less than 2GB RAM = (64MB) tsidx * 2GB to 8GB RAM = (128MB) tsidx 132

133 * more than 8GB RAM = (256MB) tsidx * If not "auto", then must be 16MB-1GB. * Value may be specified using a size suffix: " " or "16MB" are equivalent. * Inappropriate use of this parameter will cause splunkd to not start if rebuild is required. * Highest legal value (in bytes) is inplaceupdates = true false * If true, metadata updates are written to the.data files directly * If false, metadata updates are written to a temporary file and then moved into place * Intended for advanced debugging of metadata issues * Setting this parameter to false (to use a temporary file) will impact indexing performance, particularly with large numbers of hosts, sources, or sourcetypes (~1 million, across all indexes.) * This is an advanced parameter; do NOT set unless instructed by Splunk Support * Defaults to true serviceonlyasneeded = true false * Causes index service (housekeeping tasks) overhead to be incurred only after index activity. * Indexer module problems may be easier to diagnose when this optimization is disabled (set to false). * Defaults to true. servicesubtasktimingperiod = <positive integer> * Subtasks of indexer service task will be timed on every Nth execution, where N = value of this parameter. * Smaller values will give greater accuracy; larger values will lessen timer overhead. * Timer measurements will be found in metrics.log, marked "group=subtask_seconds, task=indexer_service" * In seconds. * Defaults to 30 * Highest legal value is * We strongly suggest value of this parameter divide evenly into value of 'rotateperiodinsecs' parameter. processtrackerserviceinterval = <nonnegative integer> * Controls how often indexer checks status of the child OS processes it had launched to see if it can launch new processes for queued requests. * In seconds. * If set to 0, indexer will check child process status every second. * Defaults to 15 * Highest legal value is maxbucketsizecacheentries = <nonnegative integer> * This value is not longer needed and its value is ignored. tsidxstatshomepath = <path on server> * An absolute path that specifies where Splunk creates namespace data with 'tscollect' command * If the directory does not exist, we attempt to create it * Optional. If this is unspecified, we default to the 'tsidxstats' directory under $SPLUNK_DB hotbuckettimerefreshinterval = <positive integer> * Controls how often each index refreshes the available hot bucket times used by the indexes REST endpoint. * Refresh will occur every N times service is performed for each index. * For busy indexes, this is a mutiple of seconds. * For idle indexes, this is a multiple of the second-long-periods in which data is received. * This tunable is only intended to relax the frequency of these refreshes in the unexpected case that it adversely affects performance in unusual production scenarios. * This time is tracked on a per-index basis, and thus can be adjusted on a per-index basis if needed. * If, for some reason, you want have the index information refreshed with every service (and accept minor performance overhead), you can use the value 1. * Defaults to 10 (services). ****************************************************************************** PER INDEX OPTIONS These options may be set under an [<index>] entry. Index names must consist of only numbers, letters, periods, underscores, and hyphens. ****************************************************************************** disabled = true false * Toggles your index entry off and on. 133

134 * Set to true to disable an index. * Defaults to false. deleted = true * If present, means that this index has been marked for deletion: if splunkd is running, deletion is in progress; if splunkd is stopped, deletion will re-commence on startup. * Normally absent, hence no default. * Do NOT manually set, clear, or modify value of this parameter. * Seriously: LEAVE THIS PARAMETER ALONE. homepath = <path on index server> * An absolute path that contains the hotdb and warmdb for the index. * Splunkd keeps a file handle open for warmdbs at all times. * May contain a volume reference (see volume section below). * CAUTION: Path MUST be writable. * Required. Splunk will not start if an index lacks a valid homepath. * Must restart splunkd after changing this parameter; index reload will not suffice. coldpath = <path on index server> * An absolute path that contains the colddbs for the index. * Cold databases are opened as needed when searching. * May contain a volume reference (see volume section below). * CAUTION: Path MUST be writable. * Required. Splunk will not start if an index lacks a valid coldpath. * Must restart splunkd after changing this parameter; index reload will not suffice. thawedpath = <path on index server> * An absolute path that contains the thawed (resurrected) databases for the index. * May NOT contain a volume reference. * Required. Splunk will not start if an index lacks a valid thawedpath. * Must restart splunkd after changing this parameter; index reload will not suffice. bloomhomepath = <path on index server> * Location where the bloomfilter files for the index are stored. * If specified, MUST be defined in terms of a volume definition (see volume section below) * If bloomhomepath is not specified, bloomfilter files for index will be stored inline, inside bucket directories. * CAUTION: Path must be writable. * Must restart splunkd after changing this parameter; index reload will not suffice. createbloomfilter = true false * Controls whether to create bloomfilter files for the index. * TRUE: bloomfilter files will be created. FALSE: not created. * Defaults to true. summaryhomepath = <path on index server> * An absolute path where transparent summarization results for data in this index should be stored. Must be different for each index and may be on any disk drive. * May contain a volume reference (see volume section below). * Volume reference must be used if data retention based on data size is desired. * If not specified it defaults to a directory 'summary' in the same location as homepath * For example, if homepath is "/opt/splunk/var/lib/splunk/index1/db", then summaryhomepath would be "/opt/splunk/var/lib/splunk/index1/summary". * CAUTION: Path must be writable. * Must restart splunkd after changing this parameter; index reload will not suffice. tstatshomepath = <path on index server> * Location where datamodel acceleration TSIDX data for this index should be stored * If specified, MUST be defined in terms of a volume definition (see volume section below) * If not specified it defaults to volume:_splunk_summaries/$_index_name/datamodel_summary, where $_index_name is the name of the index * CAUTION: Path must be writable. * Must restart splunkd after changing this parameter; index reload will not suffice. maxbloombackfillbucketage = <nonnegative integer>[smhd] infinite * If a (warm or cold) bloomfilter-less bucket is older than this, we shall not create its bloomfilter when we come across it * Defaults to 30d. * When set to 0, bloomfilters are never backfilled * When set to "infinite", bloomfilters are always backfilled * NB that if createbloomfilter=false, bloomfilters are never backfilled regardless of the value of this parameter 134

135 * Highest legal value in computed seconds is 2 billion, or , which is approximately 68 years. enableonlinebucketrepair = true false * Controls asynchronous "online fsck" bucket repair, which runs concurrently with Splunk * When enabled, you do not have to wait until buckets are repaired, to start Splunk * When enabled, you might observe a slight performance degradation * Defaults to true. The following options can be set either per index or globally (as defaults for all indexes). Defaults set globally are overridden if set on a per-index basis. maxwarmdbcount = <nonnegative integer> * The maximum number of warm buckets. * Warm buckets are located in the <homepath> for the index. * If set to zero, it will not retain any warm buckets (will roll them to cold as soon as it can) * Defaults to 300. * Highest legal value is maxtotaldatasizemb = <nonnegative integer> * The maximum size of an index (in MB). * If an index grows larger than the maximum size, the oldest data is frozen. * This parameter only applies to hot, warm, and cold buckets. It does not apply to thawed buckets. * Defaults to * Highest legal value is rotateperiodinsecs = <positive integer> * Controls the service period (in seconds): how often splunkd performs certain housekeeping tasks. Among these tasks are: * * Check if a new hotdb needs to be created. * * Check if there are any cold DBs that should be frozen. * * Check whether buckets need to be moved out of hot and cold DBs, due to respective size constraints (i.e., homepath.maxdatasizemb and coldpath.maxdatasizemb) * This value becomes the default value of the rotateperiodinsecs attribute for all volumes (see rotateperiodinsecs in the Volumes section) * Defaults to 60. * Highest legal value is frozentimeperiodinsecs = <nonnegative integer> * Number of seconds after which indexed data rolls to frozen. * If you do not specify a coldtofrozenscript, data is deleted when rolled to frozen. * IMPORTANT: Every event in the DB must be older than frozentimeperiodinsecs before it will roll. Then, the DB will be frozen the next time splunkd checks (based on rotateperiodinsecs attribute). * Defaults to (6 years). * Highest legal value is warmtocoldscript = <script path> * Specifies a script to run when moving data from warm to cold. * This attribute is supported for backwards compatibility with versions older than 4.0. Migrating data across filesystems is now handled natively by splunkd. * If you specify a script here, the script becomes responsible for moving the event data, and Splunk-native data migration will not be used. * The script must accept two arguments: * First: the warm directory (bucket) to be rolled to cold. * Second: the destination in the cold path. * Searches and other activities are paused while the script is running. * Contact Splunk Support ( if you need help configuring this setting. * The script must be in $SPLUNK_HOME/bin or a subdirectory thereof. * Defaults to empty. coldtofrozenscript = [path to script interpreter] <path to script> * Specifies a script to run when data will leave the splunk index system. * Essentially, this implements any archival tasks before the data is deleted out of its default location. * Add "$DIR" (quotes included) to this setting on Windows (see below for details). * Script Requirements: * The script must accept one argument: * An absolute path to the bucket directory to archive. 135

136 * Your script should work reliably. * If your script returns success (0), Splunk will complete deleting the directory from the managed index location. * If your script return failure (non-zero), Splunk will leave the bucket in the index, and try calling your script again several minutes later. * If your script continues to return failure, this will eventually cause the index to grow to maximum configured size, or fill the disk. * Your script should complete in a reasonable amount of time. * If the script stalls indefinitely, it will occupy slots. * These slots will not be available for other freeze scripts. * This means that a stalling script for index1 may prevent freezing of index2. * If the string $DIR is present in this setting, it will be expanded to the absolute path to the directory. * If $DIR is not present, the directory will be added to the end of the invocation line of the script. * This is important for Windows. * For historical reasons, the entire string is broken up by shell-pattern expansion rules. * Since windows paths frequently include spaces, and the windows shell breaks on space, the quotes are needed for the script to understand the directory. * If your script can be run directly on your platform, you can specify just the script. * Examples of this are: *.bat and.cmd files on Windows * scripts set executable on UNIX with a! shebang line pointing to a valid interpreter. * You can also specify an explicit path to an interpreter and the script. * Example: /path/to/my/installation/of/python.exe path/to/my/script.py * Splunk ships with an example archiving script in that you SHOULD NOT USE $SPLUNK_HOME/bin called coldtofrozenexample.py * DO NOT USE the example for production use, because: * 1 - It will be overwritten on upgrade. * 2 - You should be implementing whatever requirements you need in a script of your creation. If you have no such requirements, use coldtofrozendir * Example configuration: * If you create a script in bin/ called our_archival_script.py, you could use: UNIX: coldtofrozenscript = "$SPLUNK_HOME/bin/python" "$SPLUNK_HOME/bin/our_archival_script.py" Windows: coldtofrozenscript = "$SPLUNK_HOME/bin/python" "$SPLUNK_HOME/bin/our_archival_script.py" "$DIR" * The example script handles data created by different versions of splunk differently. Specifically data from before 4.2 and after are handled differently. See "Freezing and Thawing" below: * The script must be in $SPLUNK_HOME/bin or a subdirectory thereof. coldtofrozendir = <path to frozen archive> * An alternative to a coldtofrozen script - simply specify a destination path for the frozen archive * Splunk will automatically put frozen buckets in this directory * For information on how buckets created by different versions are handled, see "Freezing and Thawing" below. * If both coldtofrozendir and coldtofrozenscript are specified, coldtofrozendir will take precedence * Must restart splunkd after changing this parameter; index reload will not suffice. * May NOT contain a volume reference. Freezing and Thawing (this should move to web docs 4.2 and later data: * To archive: remove files except for the rawdata directory, since rawdata contains all the facts in the bucket. * To restore: run splunk rebuild <bucket_dir> on the archived bucket, then atomically move the bucket to thawed for that index 4.1 and earlier data: * To archive: gzip the.tsidx files, as they are highly compressable but not recreateable * To restore: unpack the tsidx files within the bucket, then atomically move the bucket to thawed for that index 136

137 compressrawdata = true false * This parameter is ignored. The splunkd process always compresses raw data. maxconcurrentoptimizes = <nonnegative integer> * The number of concurrent optimize processes that can run against the hot DB. * This number should be increased if: * There are always many small tsidx files in the hot DB. * After rolling, there are many tsidx files in warm or cold DB. * Must restart splunkd after changing this parameter; index reload will not suffice. * Defaults to 6 * Highest legal value is maxdatasize = <positive integer> auto auto_high_volume * The maximum size in MB for a hot DB to reach before a roll to warm is triggered. * Specifying "auto" or "auto_high_volume" will cause Splunk to autotune this parameter (recommended). * You should use "auto_high_volume" for high-volume indexes (such as the main index); otherwise, use "auto". A "high volume index" would typically be considered one that gets over 10GB of data per day. * Defaults to "auto", which sets the size to 750MB. * "auto_high_volume" sets the size to 10GB on 64-bit, and 1GB on 32-bit systems. * Although the maximum value you can set this is MB, which corresponds to 1 TB, a reasonable number ranges anywhere from 100 to Before proceeding with any higher value, please seek approval of Splunk Support. * If you specify an invalid number or string, maxdatasize will be auto tuned. * NOTE: The maximum size of your warm buckets may slightly exceed 'maxdatasize', due to post-processing and timing issues with the rolling policy. rawfilesizebytes = <positive integer> * Deprecated in version 4.2 and later. We will ignore this value. * Rawdata chunks are no longer stored in individual files. * If you really need to optimize the new rawdata chunks (highly unlikely), edit rawchunksizebytes rawchunksizebytes = <positive integer> * Target uncompressed size in bytes for individual raw slice in the rawdata journal of the index. * Defaults to (128KB). * If 0 is specified, rawchunksizebytes will be set to the default value. * NOTE: rawchunksizebytes only specifies a target chunk size. The actual chunk size may be slightly larger by an amount proportional to an individual event size. * WARNING: This is an advanced parameter. Only change it if you are instructed to do so by Splunk Support. * Must restart splunkd after changing this parameter; index reload will not suffice. * Highest legal value is minrawfilesyncsecs = <nonnegative decimal> disable * How frequently we force a filesystem sync while compressing journal slices. During this interval, uncompressed slices are left on disk even after they are compressed. Then we force a filesystem sync of the compressed journal and remove the accumulated uncompressed files. * If 0 is specified, we force a filesystem sync after every slice completes compressing. * Specifying "disable" disables syncing entirely: uncompressed slices are removed as soon as compression is complete * Defaults to "disable". * Some filesystems are very inefficient at performing sync operations, so only enable this if you are sure it is needed * Must restart splunkd after changing this parameter; index reload will not suffice. * No exponent may follow the decimal. * Highest legal value is maxmemmb = <nonnegative integer> * The amount of memory to allocate for indexing. * This amount of memory will be allocated PER INDEX THREAD, or, if indexthreads is set to 0, once per index. * IMPORTANT: Calculate this number carefully. splunkd will crash if you set this number higher than the amount of memory available. * Defaults to 5. * The default is recommended for all environments. * Highest legal value is blocksignsize = <nonnegative integer> * Controls how many events make up a block for block signatures. * If this is set to 0, block signing is disabled for this index. * Defaults to 0. * A recommended value is 100. * Highest legal value is

138 maxhotspansecs = <positive integer> * Upper bound of timespan of hot/warm buckets in seconds. * Defaults to seconds (90 days). * NOTE: If you set this too small, you can get an explosion of hot/warm buckets in the filesystem. * If you set this parameter to less than 3600, it will be automatically reset to 3600, which will then activate snapping behavior (see below). * This is an advanced parameter that should be set with care and understanding of the characteristics of your data. * If set to 3600 (1 hour), or (1 day), becomes also the lower bound of hot bucket timespans. Further, snapping behavior (i.e. ohsnap) is activated, whereby hot bucket boundaries will be set at exactly the hour or day mark, relative to local midnight. * Highest legal value is maxhotidlesecs = <nonnegative integer> * Provides a ceiling for buckets to stay in hot status without receiving any data. * If a hot bucket receives no data for more than maxhotidlesecs seconds, Splunk rolls it to warm. * This setting operates independently of maxhotbuckets, which can also cause hot buckets to roll. * A value of 0 turns off the idle check (equivalent to infinite idle time). * Defaults to 0. * Highest legal value is maxhotbuckets = <positive integer> * Maximum hot buckets that can exist per index. * When maxhotbuckets is exceeded, Splunk rolls the least recently used (LRU) hot bucket to warm. * Both normal hot buckets and quarantined hot buckets count towards this total. * This setting operates independently of maxhotidlesecs, which can also cause hot buckets to roll. * Defaults to 3. * Highest legal value is quarantinepastsecs = <positive integer> * Events with timestamp of quarantinepastsecs older than "now" will be dropped into quarantine bucket. * Defaults to (900 days). * This is a mechanism to prevent the main hot buckets from being polluted with fringe events. * Highest legal value is quarantinefuturesecs = <positive integer> * Events with timestamp of quarantinefuturesecs newer than "now" will be dropped into quarantine bucket. * Defaults to (30 days). * This is a mechanism to prevent main hot buckets from being polluted with fringe events. * Highest legal value is maxmetaentries = <nonnegative integer> * Sets the maximum number of unique lines in.data files in a bucket, which may help to reduce memory consumption * If exceeded, a hot bucket is rolled to prevent further increase * If your buckets are rolling due to Strings.data hitting this limit, the culprit may be the 'punct' field in your data. If you do not use punct, it may be best to simply disable this (see props.conf.spec) * There is a delta between when maximum is exceeded and bucket is rolled. This means a bucket may end up with epsilon more lines than specified, but this is not a major concern unless excess is significant * If set to 0, this setting is ignored (it is treated as infinite) * Highest legal value is syncmeta = true false * When "true", a sync operation is called before file descriptor is closed on metadata file updates. * This functionality was introduced to improve integrity of metadata files, especially in regards to operating system crashes/machine failures. * Defaults to true. * NOTE: Do not change this parameter without the input of a Splunk support professional. * Must restart splunkd after changing this parameter; index reload will not suffice. servicemetaperiod = <positive integer> * Defines how frequently metadata is synced to disk, in seconds. * Defaults to 25 (seconds). * You may want to set this to a higher value if the sum of your metadata file sizes is larger than many 138

139 tens of megabytes, to avoid the hit on I/O in the indexing fast path. * Highest legal value is partialservicemetaperiod = <positive integer> * Related to servicemetaperiod. If set, it enables metadata sync every <integer> seconds, but only for records where the sync can be done efficiently in-place, without requiring a full re-write of the metadata file. Records that require full re-write will be synced at servicemetaperiod. * <integer> specifies how frequently it should sync. Zero means that this feature is turned off and servicemetaperiod is the only time when metadata sync happens. * If the value of partialservicemetaperiod is greater than servicemetaperiod, this setting will have no effect. * By default it is turned off (zero). * This parameter is ignored if serviceonlyasneeded = true (the default). * Highest legal value is throttlecheckperiod = <positive integer> * Defines how frequently Splunk checks for index throttling condition, in seconds. * In seconds; defaults to 15 * NOTE: Do not change this parameter without the input of a Splunk Support professional. * Highest legal value is maxtimeunreplicatedwithacks = <nonnegative decimal> * Important if you have enabled acks on forwarders and have replication enabled (via Clustering) * This parameter puts an upper limit on how long events can sit unacked in a raw slice * In seconds; defaults to 60 * To disable this, you can set to 0, but this is NOT recommended!!! * NOTE: This is an advanced parameter; make sure you understand the settings on all your forwarders before changing this. This number should not exceed ack timeout configured on any forwarders, and should indeed be set to at most half of the minimum value of that timeout. You can find this setting in outputs.conf readtimeout setting, under tcpout stanza. * Highest legal value is maxtimeunreplicatednoacks = <nonnegative decimal> * Important only if replication is enabled for this index, otherwise ignored * This parameter puts an upper limit on how long an event can sit in raw slice. * if there are any ack''d events sharing this raw slice, this paramater will not apply (maxtimeunreplicatedwithacks will be used instead) * In seconds; defaults to 60 * Highest legal value is * To disable this, you can set to 0; please be careful and understand the consequences before changing this parameter isreadonly = true false * Set to true to make an index read-only. * If true, no new events can be added to the index, but the index is still searchable. * Defaults to false. * Must restart splunkd after changing this parameter; index reload will not suffice. homepath.maxdatasizemb = <nonnegative integer> * Specifies the maximum size of homepath (which contains hot and warm buckets). * If this size is exceeded, Splunk will move buckets with the oldest value of latest time (for a given bucket) into the cold DB until homepath is below the maximum size. * If this attribute is missing or set to 0, Splunk will not constrain size of homepath. * Defaults to 0. * Highest legal value is coldpath.maxdatasizemb = <nonnegative integer> * Specifies the maximum size of coldpath (which contains cold buckets). * If this size is exceeded, Splunk will freeze buckets with the oldest value of latest time (for a given bucket) until coldpath is below the maximum size. * If this attribute is missing or set to 0, Splunk will not constrain size of coldpath * If we freeze buckets due to enforcement of this policy parameter, and coldtofrozenscript and/or coldtofrozendir archiving parameters are also set on the index, these parameters *will* take into effect * Defaults to 0. * Highest legal value is disableglobalmetadata = true false 139

140 * NOTE: This option was introduced in 4.3.3, but as of 5.0 it is obsolete and ignored if set. * It used to disable writing to the global metadata. In 5.0 global metadata was removed. repfactor = <nonnegative integer> auto * Only relevant if this instance is a clustering slave (but see note about "auto" below). * See server.conf spec for details on clustering configuration. * Value of 0 turns off replication for this index. * If set to "auto", slave will use whatever value the master is configured with * Highest legal value is minstreamgroupqueuesize = <nonnegative integer> * Minimum size of the queue that stores events in memory before committing them to a tsidx file. As Splunk operates, it continually adjusts this size internally. Splunk could decide to use a small queue size and thus generate tiny tsidx files under certain unusual circumstances, such as file system errors. The danger of a very low minimum is that it can generate very tiny tsidx files with one or very few events, making it impossible for splunk-optimize to catch up and optimize the tsidx files into reasonably sized files. * Defaults to * Only set this value if you have been advised to by Splunk Support. * Highest legal value is streamingtargettsidxsyncperiodmsec = <nonnegative integer> * Period we force sync tsidx files on streaming targets. This setting is needed for multi-site clustering where streaming targets may be primary. * if set to 0, we never sync (equivalent to infinity) ****************************************************************************** Volume settings. This section describes settings that affect the volume- optional and volume-mandatory parameters only. All volume stanzas begin with "volume:". For example: [volume:volume_name] path = /foo/bar These volume stanzas can then be referenced by individual index parameters, e.g. homepath or coldpath. To refer to a volume stanza, use the "volume:" prefix. For example, to set a cold DB to the example stanza above, in index "hiro", use: [hiro] coldpath = volume:volume_name/baz This will cause the cold DB files to be placed under /foo/bar/baz. If the volume spec is not followed by a path (e.g. "coldpath=volume:volume_name"), then the cold path would be composed by appending the index name to the volume name ("/foo/bar/hiro"). Note: thawedpath may not be defined in terms of a volume. Thawed allocations are manually controlled by Splunk administrators, typically in recovery or archival/review scenarios, and should not trigger changes in space automatically used by normal index activity. ****************************************************************************** path = <path on server> * Required. * Points to the location on the file system where all databases that use this volume will reside. You must make sure that this location does not overlap with that of any other volume or index database. maxvolumedatasizemb = <nonnegative integer> * Optional. * If set, this attribute limits the total size of all databases that reside on this volume to the maximum size specified, in MB. Note that this it will act only on those indexes which reference this volume, not on the total size of the path set in the path attribute of this volume. * If the size is exceeded, Splunk will remove buckets with the oldest value of latest time (for a given bucket) across all indexes in the volume, until the volume is below the maximum size. This is the trim operation. Note that this can cause buckets to be chilled [moved to cold] directly from a hot DB, if those buckets happen to have the least value of latest-time (LT) across all indexes in the volume. * Highest legal value is

141 rotateperiodinsecs = <nonnegative integer> * Optional. * Specifies period of trim operation for this volume. * If not set, the value of global rotateperiodinsecs attribute is inherited. * Highest legal value is indexes.conf.example Version This file contains an example indexes.conf. Use this file to configure indexing properties. To use one or more of these configurations, copy the configuration block into indexes.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at The following example defines a new high-volume index, called "hatch", and sets this to be the default index for both incoming data and search. Note that you may want to adjust the indexes that your roles have access to when creating indexes (in authorize.conf) defaultdatabase = hatch [hatch] homepath = $SPLUNK_DB/hatchdb/db coldpath = $SPLUNK_DB/hatchdb/colddb thawedpath = $SPLUNK_DB/hatchdb/thaweddb maxdatasize = maxhotbuckets = 10 The following example changes the default amount of space used on a per-index basis. [default] maxtotaldatasizemb = The following example changes the time data is kept around by default. It also sets an export script. NOTE: You must edit this script to set export location before running it. [default] maxwarmdbcount = 200 frozentimeperiodinsecs = rotateperiodinsecs = 30 coldtofrozenscript = "$SPLUNK_HOME/bin/python" "$SPLUNK_HOME/bin/myColdToFrozenScript.py" This example freezes buckets on the same schedule, but lets Splunk do the freezing process as opposed to a script [default] maxwarmdbcount = 200 frozentimeperiodinsecs = rotateperiodinsecs = 30 coldtofrozendir = "$SPLUNK_HOME/myfrozenarchive" This example demonstrates the use of volumes volume definitions; prefixed with "volume:" [volume:hot1] path = /mnt/fast_disk maxvolumedatasizemb =

142 [volume:cold1] path = /mnt/big_disk maxvolumedatasizemb not specified: no data size limitation on top of the existing ones [volume:cold2] path = /mnt/big_disk2 maxvolumedatasizemb = index definitions [idx1] homepath = volume:hot1/idx1 coldpath = volume:cold1/idx1 thawedpath must be specified, and cannot use volume: syntax choose a location convenient for reconstitition from archive goals For many sites, this may never be used. thawedpath = $SPLUNK_DB/idx1/thaweddb [idx2] note that the specific indexes must take care to avoid collisions homepath = volume:hot1/idx2 coldpath = volume:cold2/idx2 thawedpath = $SPLUNK_DB/idx2/thaweddb [idx3] homepath = volume:hot1/idx3 coldpath = volume:cold2/idx3 thawedpath = $SPLUNK_DB/idx3/thaweddb Indexes may be allocated space in effective groups by sharing volumes perhaps we only want to keep 100GB of summary data and other low-volume information [volume:small_indexes] path = /mnt/splunk_indexes maxvolumedatasizemb = and this is our main event series, allowing 50 terabytes [volume:large_indexes] path = /mnt/splunk_indexes maxvolumedatasizemb = summary and rare_data together will be limited to 100GB [summary] homepath=volume:small_indexes/summary/db coldpath=volume:small_indexes/summary/colddb thawedpath=$splunk_db/summary/thaweddb low-volume indexes probably don't want a lot of hot buckets maxhotbuckets = 2 if the volume is quite low, and you have data sunset goals you may want to have smaller buckets maxdatasize = 500 [rare_data] homepath=volume:small_indexes/rare_data/db coldpath=volume:small_indexes/rare_data/colddb thawedpath=$splunk_db/rare_data/thaweddb maxhotbuckets = 2 main, and any other large volume indexes you add sharing large_indexes will be together be constrained to 50TB, separately from the 100GB of the small_indexes [main] homepath=volume:large_indexes/main/db coldpath=volume:large_indexes/main/colddb thawedpath=$splunk_db/main/thaweddb large buckets and more hot buckets are desirable for higher volume indexes, and ones where the variations in the timestream of events is hard to predict. maxdatasize = auto_high_volume 142

143 maxhotbuckets = 10 [idx1_large_vol] homepath=volume:large_indexes/idx1_large_vol/db coldpath=volume:large_indexes/idx1_large_vol/colddb homepath=$splunk_db/idx1_large/thaweddb this index will exceed the default of.5tb requiring a change to maxtotaldatasizemb maxtotaldatasizemb = maxdatasize = auto_high_volume maxhotbuckets = 10 but the data will only be retained for about 30 days frozentimeperiodinsecs = This example demonstrates database size constraining In this example per-database constraint is combined with volumes. While a central volume setting makes it easy to manage data size across multiple indexes, there is a concern that bursts of data in one index may significantly displace data from others. The homepath.maxdatasizemb setting can be used to assure that no index will ever take more than certain size, therefore alleviating the concern. global settings will be inherited by all indexes: no database will exceed 1TB homepath.maxdatasizemb = volumes [volume:caliente] path = /mnt/fast_disk maxvolumedatasizemb = [volume:frio] path = /mnt/big_disk maxvolumedatasizemb = and this is our main event series, allowing about 50 terabytes [volume:large_indexes] path = /mnt/splunk_indexes maxvolumedatasizemb = indexes [i1] homepath = volume:caliente/i1 homepath.maxdatasizemb is inherited coldpath = volume:frio/i1 coldpath.maxdatasizemb not specified: no limit - old-style behavior thawedpath = $SPLUNK_DB/i1/thaweddb [i2] homepath = volume:caliente/i2 overrides the default maxdatasize homepath.maxdatasizemb = 1000 coldpath = volume:frio/i2 limits the cold DB's coldpath.maxdatasizemb = thawedpath = $SPLUNK_DB/i2/thaweddb [i3] homepath = /old/style/path homepath.maxdatasizemb = 1000 coldpath = volume:frio/i3 coldpath.maxdatasizemb = thawedpath = $SPLUNK_DB/i3/thaweddb main, and any other large volume indexes you add sharing large_indexes will together be constrained to 50TB, separately from the rest of the indexes [main] 143

144 homepath=volume:large_indexes/main/db coldpath=volume:large_indexes/main/colddb thawedpath=$splunk_db/main/thaweddb large buckets and more hot buckets are desirable for higher volume indexes maxdatasize = auto_high_volume maxhotbuckets = 10 inputs.conf 다음은 inputs.conf의 사양 및 예제 파일입니다. inputs.conf.spec Version This file contains possible attributes and values you can use to configure inputs, distributed inputs such as forwarders, and file system monitoring in inputs.conf. There is an inputs.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place an inputs.conf in $SPLUNK_HOME/etc/system/local/. For examples, see inputs.conf.example. You must restart Splunk to enable new configurations. To learn more about configuration files (including precedence), see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. ******* GENERAL SETTINGS: The following attribute/value pairs are valid for all input types (except file system change monitor, which is described in a separate section in this file). You must first enter a stanza header in square brackets, specifying the input type. See further down in this file for examples. Then, use any of the following attribute/value pairs. ******* host = <string> * Sets the host key/field to a static value for this stanza. * Primarily used to control the host field, which will be used for events coming in via this input stanza. * Detail: Sets the host key's initial value. The key is used during parsing/indexing, in particular to set the host field. It is also the host field used at search time. * As a convenience, the chosen string is prepended with 'host::'. * WARNING: Do not quote the <string> value: host=foo, not host="foo". * If set to '$decideonstartup', will be interpreted as hostname of executing machine; such interpretation will occur on each splunkd startup. This is the default. * If you are running multiple instances of splunk on the same system (hardware or VM), you should probably choose unique values for host to differentiate your data, e.g. myhost-sh-1 or myhost-idx-2. index = <string> * Sets the index to store events from this input. * Primarily used to specify the index to store events coming in via this input stanza. * Detail: Sets the index key's initial value. The key is used when selecting an index to store the events. * Defaults to "main" (or whatever you have set as your default index). source = <string> * Sets the source key/field for events from this input. * NOTE: Overriding the source key is generally not recommended. Typically, the 144

145 input layer will provide a more accurate string to aid problem analysis and investigation, accurately recording the file from which the data was retreived. Please consider use of source types, tagging, and search wildcards before overriding this value. * Detail: Sets the source key's initial value. The key is used during parsing/indexing, in particular to set the source field during indexing. It is also the source field used at search time. * As a convenience, the chosen string is prepended with 'source::'. * WARNING: Do not quote the <string> value: source=foo, not source="foo". * Defaults to the input file path. sourcetype = <string> * Sets the sourcetype key/field for events from this input. * Primarily used to explicitly declare the source type for this data, as opposed to allowing it to be determined via automated methods. This is typically important both for searchability and for applying the relevant configuration for this type of data during parsing and indexing. * Detail: Sets the sourcetype key's initial value. The key is used during parsing/indexing, in particular to set the source type field during indexing. It is also the source type field used at search time. * As a convenience, the chosen string is prepended with 'sourcetype::'. * WARNING: Do not quote the <string> value: sourcetype=foo, not sourcetype="foo". * If unset, Splunk picks a source type based on various aspects of the data. There is no hard-coded default. queue = [parsingqueue indexqueue] * Specifies where the input processor should deposit the events it reads. * Set queue to "parsingqueue" to apply props.conf and other parsing rules to your data. For more information about props.conf and rules for timestamping and linebreaking, refer to props.conf and the online documentation at * Set queue to "indexqueue" to send your data directly into the index. * Defaults to parsingqueue. Pipeline Key defaulting. * Pipeline keys in general can be defaulted in inputs stanzas. * The list of user-available modifiable pipeline keys is described in transforms.conf.spec, See transforms.conf.spec for further information on these keys. * The currently-defined keys which are available literally in inputs stanzas are as follows: queue = <value> _raw = <value> _meta = <value> _time = <value> * Inputs have special support for mapping host, source, sourcetype, and index to their metadata names such as host -> Metadata:Host * Defaulting these values is not recommended, and is generally only useful as a workaround to other product issues. * Defaulting these keys in most cases will override the default behavior of input processors; but this behavior is not guaranteed in all cases. * Values defaulted here, as with all values provided by inputs, may be altered by transforms at parse-time. *********** This section contains options for routing data using inputs.conf rather than outputs.conf. Note concerning routing via inputs.conf: This is a simplified set of routing options you can use as data is coming in. For more flexible options or details on configuring required or optional settings, refer to outputs.conf.spec. _TCP_ROUTING = <tcpout_group_name>,<tcpout_group_name>,<tcpout_group_name>,... * Comma-separated list of tcpout group names. * Using this, you can selectively forward the data to specific indexer(s). * Specify the tcpout group the forwarder should use when forwarding the data. The tcpout group names are defined in outputs.conf with [tcpout:<tcpout_group_name>]. * Defaults to groups specified in "defaultgroup" in [tcpout] stanza in outputs.conf. * To forward data from the "_internal" index, _TCP_ROUTING must explicitly be set to either "*" or a specific splunktcp target group. _SYSLOG_ROUTING = <syslog_group_name>,<syslog_group_name>,<syslog_group_name>,... * Comma-separated list of syslog group names. * Using this, you can selectively forward the data to specific destinations as syslog events. 145

146 * Specify the syslog group to use when forwarding the data. The syslog group names are defined in outputs.conf with [syslog:<syslog_group_name>]. * Defaults to groups present in "defaultgroup" in [syslog] stanza in outputs.conf. * The destination host must be configured in outputs.conf, using "server=[<ip> <servername>]:<port>". _INDEX_AND_FORWARD_ROUTING = <string> * Only has effect if using selectiveindexing feature in outputs.conf. * If set for any input stanza, should cause all data coming from that input stanza to be labeled with this setting. * When selectiveindexing is in use on a forwarder: * data without this label will not be indexed by that forwarder. * data with this label will be indexed in addition to any forwarding. * This setting does not actually cause data to be forwarded or not forwarded in any way, nor does it control where the data is forwarded in multiple-forward path cases. * Defaults to not present. ************ Blacklist ************ [blacklist:<path>] * Protect files on the filesystem from being indexed or previewed. * Splunk will treat a file as blacklisted if it starts with any of the defined blacklisted <paths>. * The preview endpoint will return and error when asked to preview a blacklisted file. * The oneshot endpoint and command will also return an error. * When a blacklisted file is monitored (monitor:// or batch://), filestatus endpoint will show an error. * For fschange with sendfullevent option enabled, contents of backlisted files will not be indexed. ******* Valid input types follow, along with their input-specific attributes: ******* ******* MONITOR: ******* [monitor://<path>] * This directs Splunk to watch all files in <path>. * <path> can be an entire directory or just a single file. * You must specify the input type and then the path, so put three slashes in your path if you are starting at the root (to include the slash that goes before the root directory). Additional attributes: host_regex = <regular expression> * If specified, <regular expression> extracts host from the path to the file for each input file. * Detail: This feature examines the source key; if source is set explicitly in the stanza, that string will be matched, not the original filename. * Specifically, the first group of the regex is used as the host. * If the regex fails to match, the default "host =" attribute is used. * If host_regex and host_segment are both set, host_regex will be ignored. * Defaults to unset. host_segment = <integer> * If set to N, the Nth "/"-separated segment of the path is set as host. If host_segment=3, for example, the third segment is used. * If the value is not an integer or is less than 1, the default "host =" attribute is used. * Defaults to unset. whitelist = <regular expression> * If set, files from this input are monitored only if their path matches the specified regex. * Takes precedence over the deprecated _whitelist attribute, which functions the same way. blacklist = <regular expression> * If set, files from this input are NOT monitored if their path matches the specified regex. * Takes precedence over the deprecated _blacklist attribute, which functions the same way. Note concerning wildcards and monitor: * You can use wildcards to specify your input path for monitored input. Use "..." for recursive directory matching and "*" for wildcard matching in a single directory segment. 146

147 * "..." recurses through directories. This means that /foo/.../bar will match foo/bar, foo/1/bar, foo/1/2/bar, etc. * You can use multiple "..." specifications in a single input path. For example: /foo/.../bar/... * The asterisk (*) matches anything in a single path segment; unlike "...", it does not recurse. For example, /foo/*/bar matches the files /foo/bar, /foo/1/bar, /foo/2/bar, etc. However, it does not match /foo/1/2/bar. A second example: /foo/m*r/bar matches /foo/mr/bar, /foo/mir/bar, /foo/moor/bar, etc. * You can combine "*" and "..." as needed: foo/.../bar/* matches any file in the bar directory within the specified path. crcsalt = <string> * Use this setting to force Splunk to consume files that have matching CRCs (cyclic redundancy checks). (Splunk only performs CRC checks against the first few lines of a file. This behavior prevents Splunk from indexing the same file twice, even though you may have renamed it -- as, for example, with rolling log files. However, because the CRC is based on only the first few lines of the file, it is possible for legitimately different files to have matching CRCs, particularly if they have identical headers.) * If set, <string> is added to the CRC. * If set to the literal string <SOURCE> (including the angle brackets), the full directory path to the source file is added to the CRC. This ensures that each file being monitored has a unique CRC. When crcsalt is invoked, it is usually set to <SOURCE>. * Be cautious about using this attribute with rolling log files; it could lead to the log file being re-indexed after it has rolled. * Defaults to empty. initcrclength = <integer> * This setting adjusts how much of a file Splunk reads before trying to identify whether it is a file that has already been seen. You may want to adjust this if you have many files with common headers (comment headers, long CSV headers, etc) and recurring filenames. * CAUTION: Improper use of this setting will cause data to be reindexed. You may wish to consult with Splunk Support before adjusting this value - the default is fine for most installations. * Defaults to 256 (bytes). * Must be in the range ignoreolderthan = <nonnegative integer>[s m h d] * Causes the monitored input to stop checking files for updates if their modtime has passed this threshold. This improves the speed of file tracking operations when monitoring directory hierarchies with large numbers of historical files (for example, when active log files are colocated with old files that are no longer being written to). * As a result, do not select a cutoff that could ever occur for a file you wish to index. Take downtime into account! Suggested value: 14d, which means 2 weeks * A file whose modtime falls outside this time window when seen for the first time will not be indexed at all. * Default: 0, meaning no threshold. followtail = [0 1] * WARNING: Use of followtail should be considered an advanced administrative action. * Treat this setting as an 'action'. That is, bring splunk up with this setting enabled. Wait enough time for splunk to identify the related files, then disable the setting and restart splunk without it. * DO NOT leave followtail enabled in an ongoing fashion. * Do not use for rolling log files, or files whose names or paths vary. * Can be used to force splunk to skip past all current data for a given stanza. * In more detail: this is intended to mean that if you start up splunk with a stanza configured this way, all data in the file at the time it is first encountered will not be read. Only data arriving after that first encounter time will be read. * This can be used to "skip over" data from old log files, or old portions of log files, to get started on current data right away. * If set to 1, monitoring begins at the end of the file (like tail -f). * If set to 0, Splunk will always start at the beginning of the file. * Defaults to 0. alwaysopenfile = [0 1] * Opens a file to check whether it has already been indexed. * Only useful for files that do not update modtime. * Only needed when monitoring files on Windows, mostly for IIS logs. * This flag should only be used as a last resort, as it increases load and slows down indexing. * Defaults to 0. time_before_close = <integer> * Modtime delta required before Splunk can close a file on EOF. * Tells the system not to close files that have been updated in past <integer> seconds. * Defaults to

148 recursive = [true false] * If false, Splunk will not monitor subdirectories found within a monitored directory. * Defaults to true. followsymlink = [true false] * Tells Splunk whether or not to follow any symbolic links within a directory it is monitoring. * If set to false, Splunk will ignore symbolic links found within a monitored directory. * If set to true, Splunk will follow symbolic links and monitor files at the symbolic link's destination. * Additionally, any whitelists or blacklists defined for the stanza also apply to files at the symbolic link's destination. * Defaults to true. _whitelist =... * This setting is deprecated. It is still honored, unless "whitelist" attribute also exists. _blacklist =... * This setting is deprecated. It is still honored, unless "blacklist" attribute also exists. dedicatedfd =... * This setting has been removed. It is no longer needed. **************************************** BATCH ("Upload a file" in Splunk Web): **************************************** NOTE: Batch should only be used for large archives of historic data. If you want to continuously monitor a directory or index small archives, use monitor (see above). Batch reads in the file and indexes it, and then deletes the file from the Splunk instance. [batch://<path>] * One time, destructive input of files in <path>. * For continuous, non-destructive inputs of files, use monitor instead. Additional attributes: move_policy = sinkhole * IMPORTANT: This attribute/value pair is required. You *must* include "move_policy = sinkhole" when defining batch inputs. * This loads the file destructively. * Do not use the batch input type for files you do not want to consume destructively. * As long as this is set, Splunk won't keep track of indexed files. Without the "move_policy = sinkhole" setting, it won't load the files destructively and will keep a track of them. host_regex = see MONITOR, above. host_segment = see MONITOR, above. crcsalt = see MONITOR, above. IMPORTANT: The following attribute is not used by batch: source = <string> followsymlink = [true false] * Works similarly to monitor, but will not delete files after following a symlink out of the monitored directory. The following settings work identically as for [monitor::] stanzas, documented above host_regex = <regular expression> host_segment = <integer> crcsalt = <string> recursive = [true false] whitelist = <regular expression> blacklist = <regular expression> initcrclength = <integer> ******* TCP: ******* [tcp://<remote server>:<port>] * Configure Splunk to listen on a specific port. * If a connection is made from <remote server>, this stanza is used to configure the input. * If <remote server> is empty, this stanza matches all connections on the specified port. 148

149 * Will generate events with source set to tcp:portnumber, for example: tcp:514 * If sourcetype is unspecified, will generate events with set sourcetype to tcp-raw. Additional attributes: connection_host = [ip dns none] * "ip" sets the host to the IP address of the system sending the data. * "dns" sets the host to the reverse DNS entry for IP address of the system sending the data. * "none" leaves the host as specified in inputs.conf, typically the splunk system hostname. * Defaults to "dns". queuesize = <integer>[kb MB GB] * Maximum size of the in-memory input queue. * Defaults to 500KB. persistentqueuesize = <integer>[kb MB GB TB] * Maximum size of the persistent queue file. * Defaults to 0 (no persistent queue). * If set to some value other than 0, persistentqueuesize must be larger than the in-memory queue size (set by queuesize attribute in inputs.conf or maxsize settings in [queue] stanzas in server.conf). * Persistent queues can help prevent loss of transient data. For information on persistent queues and how the queuesize and persistentqueuesize settings interact, see the online documentation. requireheader = <bool> * Require a header be present at the beginning of every stream. * This header may be used to override indexing settings. * Defaults to false. listenonipv6 = <no yes only> * Toggle whether this listening port will listen on IPv4, IPv6, or both * If not present, the setting in the [general] stanza of server.conf will be used acceptfrom = <network_acl>... * Lists a set of networks or addresses to accept connections from. These rules are separated by commas or spaces * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept from anywhere) rawtcpdonetimeout = <seconds> * Specifies timeout value for sending Done-key. * If a connection over this port remains idle after receiving data for specified seconds, it adds a Done-key, thus declaring the last event has been completely received. * Defaults to 10 second. ******* Data distribution: ******* Global settings for splunktcp. Used on the receiving side for data forwarded from a forwarder. [splunktcp] route = [has_key absent_key:<key>:<queuename>;...] * Settings for the light forwarder. * Splunk sets these parameters automatically -- you DO NOT need to set them. * The property route is composed of rules delimited by ';'. * Splunk checks each incoming data payload via cooked tcp port against the route rules. * If a matching rule is found, Splunk sends the payload to the specified <queuename>. * If no matching rule is found, Splunk sends the payload to the default queue specified by any queue= for this stanza. If no queue= key is set in the stanza or globally, the events will be sent to the parsingqueue. enables2sheartbeat = [true false] * This specifies the global keepalive setting for all splunktcp ports. * This option is used to detect forwarders which may have become unavailable due to network, firewall, etc., problems. 149

150 * Splunk will monitor each connection for presence of heartbeat, and if the heartbeat is not seen for s2sheartbeattimeout seconds, it will close the connection. * Defaults to true (heartbeat monitoring enabled). s2sheartbeattimeout = <seconds> * This specifies the global timeout value for monitoring heartbeats. * Splunk will close a forwarder connection if heartbeat is not seen for s2sheartbeattimeout seconds. * Defaults to 600 seconds (10 minutes). inputshutdowntimeout = <seconds> * Used during shutdown to minimize data loss when forwarders are connected to a receiver. During shutdown, the tcp input processor waits for the specified number of seconds and then closes any remaining open connections. If, however, all connections close before the end of the timeout period, shutdown proceeds immediately, without waiting for the timeout. stopacceptorafterqblock = <seconds> * Specifies seconds to wait before closing splunktcp port. * If splunk is unable to insert received data into the configured queue for more than the specified number of seconds, it closes the splunktcp port. * This action prevents forwarders establishing new connections to this indexer, and existing forwarders will notice the port is closed upon test-connections and migrate to other indexers. * Once the queue unblocks, and TCP Input can continue processing data, Splunk starts listening on the port again. * This setting should not be adjusted lightly; extreme values may interact poorly with other defaults. * Defaults to 300 seconds (5 minutes). listenonipv6 = <no yes only> * Toggle whether this listening port will listen on IPv4, IPv6, or both * If not present, the setting in the [general] stanza of server.conf will be used acceptfrom = <network_acl>... * Lists a set of networks or addresses to accept connections from. These rules are separated by commas or spaces * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept from anywhere) negotiatenewprotocol = [true false] * If set to true, allow forwarders that connect to this indexer (or specific port) to send data using the new forwarder protocol. * If set to false, deny the use of the new forwarder protocol during connection negotation. * Defaults to true. concurrentchannellimit = <unsigned integer> * Each forwarder that connects to this indexer may use up to <concurrentchannellimit> unique channel codes. * In other words, each forwarder may have up to <concurrentchannellimit> channels in flight concurrently. * Splunk will close a forwarder connection if a forwarder attempts to exceed this value. * This setting only applies when the new forwarder protocol is in use. * Defaults to 300. Forwarder-specific settings for splunktcp. [splunktcp://[<remote server>]:<port>] * This input stanza is used with Splunk instances receiving data from forwarders ("receivers"). See the topic for more information. * This is the same as TCP, except the remote server is assumed to be a Splunk instance, most likely a forwarder. * <remote server> is optional. If specified, will only listen for data from <remote server>. connection_host = [ip dns none] * For splunktcp, the host or connection_host will be used if the remote Splunk instance does not set a host, or if the host is set to "<host>::<localhost>". * "ip" sets the host to the IP address of the system sending the data. * "dns" sets the host to the reverse DNS entry for IP address of the system sending the data. * "none" leaves the host as specified in inputs.conf, typically the splunk system hostname. 150

151 * Defaults to "ip". compressed = [true false] * Specifies whether receiving compressed data. * Applies to non-ssl receiving only. There is no compression setting required for SSL. * If set to true, the forwarder port(s) should also have compression turned on; otherwise, the receiver will reject the connection. * Defaults to false. enables2sheartbeat = [true false] * This specifies the keepalive setting for the splunktcp port. * This option is used to detect forwarders which may have become unavailable due to network, firewall, etc., problems. * Splunk will monitor the connection for presence of heartbeat, and if the heartbeat is not seen for s2sheartbeattimeout seconds, it will close the connection. * This overrides the default value specified at the global [splunktcp] stanza. * Defaults to true (heartbeat monitoring enabled). s2sheartbeattimeout = <seconds> * This specifies the timeout value for monitoring heartbeats. * Splunk will will close the forwarder connection if heartbeat is not seen for s2sheartbeattimeout seconds. * This overrides the default value specified at global [splunktcp] stanza. * Defaults to 600 seconds (10 minutes). queuesize = <integer>[kb MB GB] * Maximum size of the in-memory input queue. * Defaults to 500KB. negotiatenewprotocol = [true false] * See comments for [splunktcp]. concurrentchannellimit = <unsigned integer> * See comments for [splunktcp]. [splunktcp:<port>] * This input stanza is same as [splunktcp://[<remote server>]:<port>] but without any remote server restriction * Please see documentation for [splunktcp://[<remote server>]:<port>] for following supported settings: connection_host = [ip dns none] compressed = [true false] enables2sheartbeat = [true false] s2sheartbeattimeout = <seconds> queuesize = <integer>[kb MB GB] negotiatenewprotocol = [true false] concurrentchannellimit = <unsigned integer> SSL settings for data distribution: [splunktcp-ssl:<port>] * Use this stanza type if you are receiving encrypted, parsed data from a forwarder. * Set <port> to the port on which the forwarder is sending the encrypted data. * Forwarder settings are set in outputs.conf on the forwarder. * Compression for SSL is enabled by default. On forwarder you can still specify compression using 'useclientsslcompression' setting in outputs.conf. 'compressed' setting is used for non-ssl. However, if 'compressed' is still specified for SSL, ensure that 'compressed' setting is same as forwarder, as splunktcp protocol expects same 'compressed' setting from forwarder as well. connection_host = [ip dns none] * For SplunkTCP, the host or connection_host will be used if the remote Splunk instance does not set a host, or if the host is set to "<host>::<localhost>". * "ip" sets the host to the IP address of the system sending the data. * "dns" sets the host to the reverse DNS entry for IP address of the system sending the data. * "none" leaves the host as specified in inputs.conf, typically the splunk system hostname. * Defaults to "ip". enables2sheartbeat = true false * See comments for [splunktcp:<port>]. s2sheartbeattimeout = <seconds> * See comments for [splunktcp:<port>]. listenonipv6 = <no yes only> 151

152 * Toggle whether this listening port will listen on IPv4, IPv6, or both * If not present, the setting in the [general] stanza of server.conf will be used acceptfrom = <network_acl>... * Lists a set of networks or addresses to accept connections from. These rules are separated by commas or spaces * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept from anywhere) negotiatenewprotocol = [true false] * See comments for [splunktcp]. concurrentchannellimit = <unsigned integer> * See comments for [splunktcp]. [tcp-ssl:<port>] * Use this stanza type if you are receiving encrypted, unparsed data from a forwarder or third-party system. * Set <port> to the port on which the forwarder/third-party system is sending unparsed, encrypted data. listenonipv6 = <no yes only> * Toggle whether this listening port will listen on IPv4, IPv6, or both * If not present, the setting in the [general] stanza of server.conf will be used acceptfrom = <network_acl>... * Lists a set of networks or addresses to accept connections from. These rules are separated by commas or spaces * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept from anywhere) [SSL] * Set the following specifications for SSL underneath this stanza name: servercert = <path> * Full path to the server certificate. password = <string> * Server certificate password, if any. rootca = <string> * Certificate authority list (root file). requireclientcert = [true false] * Determines whether a client must authenticate. * Defaults to false. sslversions = <string> * Comma-separated list of SSL versions to support * The versions available are "ssl2", "ssl3", "tls1.0", "tls1.1", and "tls1.2" * The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer * If a version is prefixed with "-" it is removed from the list * When configured in FIPS mode ssl2 and ssl3 are always disabled regardless of this configuration * Defaults to "*,-ssl2". (anything newer than SSLv2) supportsslv3only = [true false] * DEPRECATED. SSLv2 is now always disabled by default. The exact set of SSL versions allowed is now configurable via the "sslversions" setting above 152

153 ciphersuite = <cipher suite string> * If set, uses the specified cipher string for the input processors. * If not set, the default cipher string is used. * Provided by OpenSSL. This is used to ensure that the server does not accept connections using weak encryption protocols. ecdhcurvename = <string> * ECDH curve to use for ECDH key negotiation * We only support named curves specified by their SHORT name. * The list of valid named curves by their short/long names * can be obtained by executing this command: * $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves * Default is empty string. allowsslrenegotiation = true false * In the SSL protocol, a client may request renegotiation of the connection settings from time to time. * Setting this to false causes the server to reject all renegotiation attempts, breaking the connection. This limits the amount of CPU a single TCP connection can use, but it can cause connectivity problems especially for long-lived connections. * Defaults to true. sslquietshutdown = [true false] * Enables quiet shutdown mode in SSL * Defaults to false ******* UDP: ******* [udp://<remote server>:<port>] * Similar to TCP, except that it listens on a UDP port. * Only one stanza per port number is currently supported. * Configure Splunk to listen on a specific port. * If <remote server> is specified, the specified port will only accept data from that server. * If <remote server> is empty - [udp://<port>] - the port will accept data sent from any server. * Will generate events with source set to udp:portnumber, for example: udp:514 * If sourcetype is unspecified, will generate events with set sourcetype to udp:portnumber. Additional attributes: connection_host = [ip dns none] * "ip" sets the host to the IP address of the system sending the data. * "dns" sets the host to the reverse DNS entry for IP address of the system sending the data. * "none" leaves the host as specified in inputs.conf, typically the splunk system hostname. * Defaults to "ip". _rcvbuf = <integer> * Specifies the receive buffer for the UDP port (in bytes). * If the value is 0 or negative, it is ignored. * Defaults to 1,572,864. * Note: If the default value is too large for an OS, Splunk will try to set the value to /2. If that value also fails, Splunk will retry with /(2*2). It will continue to retry by halving the value until it succeeds. no_priority_stripping = [true false] * Setting for receiving syslog data. * If this attribute is set to true, Splunk does NOT strip the <priority> syslog field from received events. * NOTE: Do NOT include this attribute if you want to strip <priority>. * Default is false. no_appending_timestamp = [true false] * If this attribute is set to true, Splunk does NOT append a timestamp and host to received events. * NOTE: Do NOT include this attribute if you want to append timestamp and host to received events. * Default is false. queuesize = <integer>[kb MB GB] * Maximum size of the in-memory input queue. * Defaults to 500KB. 153

154 persistentqueuesize = <integer>[kb MB GB TB] * Maximum size of the persistent queue file. * Defaults to 0 (no persistent queue). * If set to some value other than 0, persistentqueuesize must be larger than the in-memory queue size (set by queuesize attribute in inputs.conf or maxsize settings in [queue] stanzas in server.conf). * Persistent queues can help prevent loss of transient data. For information on persistent queues and how the queuesize and persistentqueuesize settings interact, see the online documentation. listenonipv6 = <no yes only> * Toggle whether this port will listen on IPv4, IPv6, or both * If not present, the setting in the [general] stanza of server.conf will be used acceptfrom = <network_acl>... * Lists a set of networks or addresses to accept data from. These rules are separated by commas or spaces * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept from anywhere) [udp:<port>] * This input stanza is same as [udp://<remote server>:<port>] but without any remote server restriction * Please see the documentation for [udp://<remote server>:<port>] to follow supported settings: connection_host = [ip dns none] _rcvbuf = <integer> no_priority_stripping = [true false] no_appending_timestamp = [true false] queuesize = <integer>[kb MB GB] persistentqueuesize = <integer>[kb MB GB TB] listenonipv6 = <no yes only> acceptfrom = <network_acl>... ******* FIFO: ******* [fifo://<path>] * This directs Splunk to read from a FIFO at the specified path. queuesize = <integer>[kb MB GB] * Maximum size of the in-memory input queue. * Defaults to 500KB. persistentqueuesize = <integer>[kb MB GB TB] * Maximum size of the persistent queue file. * Defaults to 0 (no persistent queue). * If set to some value other than 0, persistentqueuesize must be larger than the in-memory queue size (set by queuesize attribute in inputs.conf or maxsize settings in [queue] stanzas in server.conf). * Persistent queues can help prevent loss of transient data. For information on persistent queues and how the queuesize and persistentqueuesize settings interact, see the online documentation. ******* Scripted Input: ******* [script://<cmd>] * Runs <cmd> at a configured interval (see below) and indexes the output. * The <cmd> must reside in one of * $SPLUNK_HOME/etc/system/bin/ * $SPLUNK_HOME/etc/apps/$YOUR_APP/bin/ * $SPLUNK_HOME/bin/scripts/ * Script path can be an absolute path, make use of an environment variable such as $SPLUNK_HOME, or use the special pattern of an initial '.' as the first directory to indicate a location inside the current app. Note that the '.' must be followed by a platform-specific directory separator. * For example, on UNIX: 154

155 [script://./bin/my_script.sh] Or on Windows: [script://.\bin\my_program.exe] This '.' pattern is strongly recommended for app developers, and necessary for operation in search head pooling environments. * Splunk on Windows ships with several Windows-only scripted inputs. Check toward the end of the inputs.conf.example for examples of the stanzas for specific Windows scripted inputs that you must add to your inputs.conf file. * <cmd> can also be a path to a file that ends with a ".path" suffix. A file with this suffix is a special type of pointer file that points to a command to be executed. Although the pointer file is bound by the same location restrictions mentioned above, the command referenced inside it can reside anywhere on the file system. This file must contain exactly one line: the path to the command to execute, optionally followed by command line arguments. Additional empty lines and lines that begin with '' are also permitted and will be ignored. interval = [<number> <cron schedule>] * How often to execute the specified command (in seconds), or a valid cron schedule. * NOTE: when a cron schedule is specified, the script is not executed on start-up. * If specified as a number, may have a fractional component; e.g., 3.14 * Splunk's cron implementation does not currently support names of months/days. * Defaults to 60.0 seconds. * The special value 0 will force this scripted input to be executed non-stop; that is, as soon as script exits, we shall re-start it. passauth = <username> * User to run the script as. * If you provide a username, Splunk generates an auth token for that user and passes it to the script via stdin. queuesize = <integer>[kb MB GB] * Maximum size of the in-memory input queue. * Defaults to 500KB. persistentqueuesize = <integer>[kb MB GB TB] * Maximum size of the persistent queue file. * Defaults to 0 (no persistent queue). * If set to some value other than 0, persistentqueuesize must be larger than the in-memory queue size (set by queuesize attribute in inputs.conf or maxsize settings in [queue] stanzas in server.conf). * Persistent queues can help prevent loss of transient data. For information on persistent queues and how the queuesize and persistentqueuesize settings interact, see the online documentation. index = <index name> * The index to which the output will be indexed to. * Note: this parameter will be passed as a command-line argument to <cmd> in the format: -index <index name>. If the script does not need the index info, it can simply ignore this argument. * If no index is specified, the default index will be used for the script output. send_index_as_argument_for_path = [true false] * Defaults to true and we will pass the index as an argument when specified for stanzas that begin with 'script://' * The argument is passed as '-index <index name>'. * To avoid passing the index as a command line argument, set this to false start_by_shell = [true false] * If set to true, the specified command will be run via the OS's shell ("/bin/sh -c" on UNIX, "cmd.exe /c" on Windows) * If set to false, the program will be run directly without attempting to expand shell metacharacters. * Defaults to true on UNIX, false on Windows. * Usually the default is fine, but you may want to explicitly set this to false for scripts that you know do not need UNIX shell metacharacter expansion. ******* File system change monitor (fschange monitor) ******* NOTE: You cannot simultaneously watch a directory using both fschange monitor and monitor (described above). [fschange:<path>] * Monitors all add/update/deletes to this directory and its subdirectories. * NOTE: <path> is the direct path. You do not need to preface it with // like other inputs. * Sends an event for every change. Additional attributes: 155

156 NOTE: fschange does not use the same attributes as other input types (described above). Use only the following attributes: index = <indexname> * The index in which to store all generated events. * Defaults to _audit, unless you do not set signedaudit (below) or set signedaudit = false, in which case events go into the default index. signedaudit = [true false] * Send cryptographically signed add/update/delete events. * If set to true, events are *always* sent to the _audit index and will *always* have the source type "audittrail". * If set to false, events are placed in the default index and the source type is whatever you specify (or "fs_notification" by default). * You must set signedaudit to false if you want to set the index. * NOTE: You must also enable auditing in audit.conf. * Defaults to false. filters = <filter1>,<filter2>,... * Each filter is applied left to right for each file or directory found during the monitor poll cycle. * See "File System Monitoring Filters" below for help defining a filter. recurse = [true false] * If true, recurse directories within the directory specified in [fschange]. * Defaults to true. followlinks = [true false] * If true, follow symbolic links. * It is recommended that you do not set this to true; file system loops can occur. * Defaults to false. pollperiod = <integer> * Check this directory for changes every <integer> seconds. * Defaults to 3600 seconds (1 hour). hashmaxsize = <integer> * Calculate a SHA256 hash for every file that is less than or equal to <integer> bytes. * This hash is used as an additional method for detecting changes to the file/directory. * Defaults to -1 (disabled). fullevent = [true false] * Set to true to send the full event if an add or update change is detected. * Further qualified by the sendeventmaxsize attribute. * Defaults to false. sendeventmaxsize = <integer> * Only send the full event if the size of the event is less than or equal to <integer> bytes. * This limits the size of indexed file data. * Defaults to -1, which is unlimited. sourcetype = <string> * Set the source type for events from this input. * "sourcetype=" is automatically prepended to <string>. * Defaults to audittrail (if signedaudit=true) or fs_notification (if signedaudit=false). host = <string> * Set the host for events from this input. * Defaults to whatever host sent the event. filesperdelay = <integer> * Injects a delay specified by delayinmills after processing <integer> files. * This is used to throttle file system monitoring so it consumes less CPU. * Defaults to 10. delayinmills = <integer> * The delay in milliseconds to use after processing every <integer> files, as specified in filesperdelay. * This is used to throttle file system monitoring so it consumes less CPU. * Defaults to 100. ******* File system monitoring filters: ******* 156

157 [filter:<filtertype>:<filtername>] * Define a filter of type <filtertype> and name it <filtername>. * <filtertype>: * Filter types are either 'blacklist' or 'whitelist.' * A whitelist filter processes all file names that match the regex list. * A blacklist filter skips all file names that match the regex list. * <filtername> * The filter name is used in the comma-separated list when defining a file system monitor. regex<integer> = <regex> * Blacklist and whitelist filters can include a set of regexes. * The name of each regex MUST be 'regex<integer>', where <integer> starts at 1 and increments. * Splunk applies each regex in numeric order: regex1=<regex> regex2=<regex>... ******* WINDOWS INPUTS: ******* * Windows platform specific input processor. *********** Splunk for Windows ships with several Windows-only scripted inputs. They are defined in the default inputs.conf. * This is a list of the Windows scripted input stanzas: [script://$splunk_home\bin\scripts\splunk-wmi.path] [script://$splunk_home\bin\scripts\splunk-regmon.path] [script://$splunk_home\bin\scripts\splunk-admon.path] * By default, some of the scripted inputs are enabled and others are disabled. * Use the "disabled=" parameter to enable/disable any of them. * Here's a short summary of the inputs: * WMI: Retrieves event logs remotely and locally. It can also gather performance data remotely, as well as receive various system notifications. * RegMon: Uses a driver to track and report any changes that occur in the local system's Registry. * ADMon: Indexes existing AD objects and listens for AD changes. The following Windows input specifications are for parsing on non-windows platforms. Performance Monitor [perfmon://<name>] * This section explains possible attribute/value pairs for configuring Splunk's Windows Performance Monitor. * Each perfmon:// stanza represents an individually configured performance monitoring input. If you configure the input through Splunk Web, then the value of "$NAME" will match what was specified there. While you can add performance monitor inputs manually, Splunk recommends that you use Splunk Web to configure them, because it is easy to mistype the values for Performance Monitor objects, counters and instances. * Note: The perfmon stanza is for local systems ONLY. To define performance monitor inputs for remote machines, use wmi.conf. object = <string> * This is a valid Performance Monitor object as defined within Performance Monitor (for example, "Process," "Server," "PhysicalDisk.") * You can specify a single valid Performance Monitor object, or use a regular expression to specify multiple objects. * This attribute is required, and the input will not run if the attribute is not present. * The object name can be a regular expression (regex). * There is no default. counters = <semicolon-separated strings> 157

158 * This can be a single counter, or multiple valid Performance Monitor counters. * This attribute is required, and the input will not run if the attribute is not present. * '*' is equivalent to all available counters for a given Performance Monitor object. * There is no default. instances = <semicolon-separated strings> * This can be a single instance, or multiple valid Performance Monitor instances. * '*' is equivalent to all available instances for a given Performance Monitor counter. * If applicable instances are available for a counter and this attribute is not present, then the input logs data for all available instances (this is the same as setting 'instances = *'). * If there are no applicable instances for a counter, then this attribute can be safely omitted. * There is no default. interval = <integer> * How often, in seconds, to poll for new data. * This attribute is required, and the input will not run if the attribute is not present. * The recommended setting depends on the Performance Monitor object, counter(s) and instance(s) that you define in the input, and how much performance data you require. Objects with numerous instantaneous or per-second counters, such as "Memory," "Processor" and "PhysicalDisk" should have shorter interval times specified (anywhere from 1-3 seconds). Less volatile counters such as "Terminal Services," "Paging File" and "Print Queue" can have longer times configured. * Default is 300 seconds. mode = <output mode> * Specifies output mode. * Possible values: single, multikv samplinginterval = <sampling interval in ms> * Advanced setting. How often, in milliseconds, to poll for new data. * Enables high-frequency performance sampling. The input collects performance data every sampling interval. It then reports averaged data and other statistics at every interval. * The minimum legal value is 100, and the maximum legal value must be less than what the 'interval' attribute to. * If not specified, high-frequency sampling does not take place. * Defaults to not specified (disabled). stats = <average;count;dev;min;max> * Advanced setting. Reports statistics for high-frequency performance sampling. * Allows values: average, count, dev, min, max. * Can be specified as a semicolon separated list. * If not specified, the input does not produce high-frequency sampling statistics. * Defaults to not specified (disabled). disabled = [0 1] * Specifies whether or not the input is enabled. * 1 to disable the input, 0 to enable it. * Defaults to 0 (enabled). index = <string> * Specifies the index that this input should send the data to. * This attribute is optional. * If no value is present, defaults to the default index. showzerovalue = [0 1] * Specfies whether or not zero value event data should be collected. * 1 captures zero value event data, 0 ignores zero value event data. * Defaults to 0 (ignores zero value event data) useenglishonly = [true false] * Controls which Windows perfmon API is used. * If true, PdhAddEnglishCounter() is used to add the counter string. * If false, PdhAddCounter() is used to add the counter string. * Note: if set to true, object regular expression is disabled on non-english language hosts. 158

159 * Defaults to false. Direct Access File Monitor (does not use file handles) For Windows systems only. [MonitorNoHandle://<path>] * This stanza directs Splunk to intercept file writes to the specific file. * <path> must be a fully qualified path name to a specific file. * There can be more than one stanza. disabled = [0 1] * Tells Splunk whether or not the input is enabled. * Defaults to 0 (enabled). index = <string> * Tells Splunk which index to store incoming data into for this stanza. * This field is optional. * Defaults to the default index. Windows Event Log Monitor [WinEventLog://<name>] * This section explains possible attribute/value pairs for configuring Splunk's Windows event log Monitor. * Each WinEventLog:// stanza represents an individually configured WinEventLog monitoring input. If you you configure the input through Splunk Web, the value of "$NAME" will match what was specified there. While you can add event log monitor inputs manually, Splunk recommends that you use the Manager interface to configure Windows event log monitor inputs because it is easy to mistype the values for event log channels. * Note: The WinEventLog stanza is for local systems ONLY. To define event log monitor inputs for remote machines, use wmi.conf. start_from = <string> * Specifies how Splunk should chronologically read the event log channels. * Setting this attribute to 'oldest' tells Splunk to start reading Windows event logs from oldest to newest. * Setting this attribute to 'newest' tells Splunk to start reading Windows event logs in reverse, from newest to oldest. Once the input consumes the backlog of events, it will stop. * 'newest' is not supported in combination with current_only = 1 (This combination does not make much sense.) * Defaults to oldest. current_only = [0 1] * If set to 1, the input will only acquire events that arrive while Splunk is running and the input is enabled. Data which was stored in the Windows Event Log while splunk was not running will not be read. This means that there will be gaps in data if splunk is restarted, or experiences downtime. * current_only = 1 is not supported with start_from = 'newest'. (It would not really make sense.) * If set to 0, the input will first get all existing events already stored in the log which have higher event IDs (arrived more recently) than the most recent events acquired, and then continue to monitor events arriving in real time. * Defaults to 0 (false), gathering stored events first before monitoring live events. checkpointinterval = <integer> * Sets how frequently the Windows Event Log input should save a checkpoint. * Checkpoints store the eventid of acquired events. This allows Splunk to continue monitoring at the correct event after a shutdown or outage. * The default value is 5. disabled = [0 1] * Specifies whether or not the input is enabled. 159

160 * 1 to disable the input, 0 to enable it. * The default is 0 (enabled). evt_resolve_ad_obj = [1 0] * Specifies how Splunk should interact with Active Directory while indexing Windows Event Log events. * A value of 1 tells Splunk to resolve the Active Directory Security IDentifier (SID) objects to their canonical names for a specific Windows event log channel. * When you set this value to 1, you can optionally specify the Domain Controller name and/or DNS name of the domain to bind to with the 'evt_dc_name' attribute. Splunk connects to that server to resolve the AD objects. * A value of 0 tells Splunk not to attempt any resolution. * By default, this attribute is disabled (0) for all channels. * If you enable it, you can negatively impact the rate at which Splunk Enterprise reads events on high-traffic Event Log channels. You can also cause Splunk Enterprise to experience high latency when acquiring these events. This is due to the overhead involved in performing translations. evt_dc_name = <string> * Tells Splunk which Active Directory domain controller it should bind to in order to resolve AD objects. * Optional. This parameter can be left empty. * This name can be the NetBIOS name of the domain controller or the fullyqualified DNS name of the domain controller. Either name type can, optionally, be preceded by two backslash characters. The following examples represent correctly formatted domain controller names: * "FTW-DC-01" * "\\FTW-DC-01" * "FTW-DC-01.splunk.com" * "\\FTW-DC-01.splunk.com" evt_dns_name = <string> * Tells Splunk the fully-qualified DNS name of the domain it should bind to in order to resolve AD objects. * Optional. This parameter can be left empty. index = <string> * Specifies the index that this input should send the data to. * This attribute is optional. * If no value is present, defaults to the default index. EventLog filtering Filtering at the input layer is desirable to reduce the total processing load in network transfer and computation on the Splunk nodes acquiring and processing the data. whitelist = <list of eventids> key=regex [key=regex] blacklist = <list of eventids> key=regex [key=regex] whitelist1 = key=regex [key=regex] whitelist2 = key=regex [key=regex] whitelist3 = key=regex [key=regex] whitelist4 = key=regex [key=regex] whitelist5 = key=regex [key=regex] whitelist6 = key=regex [key=regex] whitelist7 = key=regex [key=regex] whitelist8 = key=regex [key=regex] whitelist9 = key=regex [key=regex] blacklist1 = key=regex [key=regex] blacklist2 = key=regex [key=regex] blacklist3 = key=regex [key=regex] blacklist4 = key=regex [key=regex] blacklist5 = key=regex [key=regex] blacklist6 = key=regex [key=regex] blacklist7 = key=regex [key=regex] blacklist8 = key=regex [key=regex] blacklist9 = key=regex [key=regex] * These settings are optional. * The base unumbered whitelist and blacklist support two formats, a list of 160

161 integer event IDs, and a list of key=regex pairs. * Numbered whitelist/blacklist settings such as whitelist1 do not support the Event ID list format. * These two formats cannot be combined, only one may be used in a specific line. * Numbered whitelist settings are permitted from 1 to 9, so whitelist1 through whitelist9 and blacklist1 through blacklist9 are supported. * If no white or blacklist rules are present, all events will be read. Formats: * Event ID list format: * A comma-seperated list of terms. * Terms may be a single event ID (e.g. 6) or range of event IDs (e.g ) * Example: 4,5,7, * This would apply to events with IDs 4, 5, 7, or any event ID between 100 and 200, inclusive. * Provides no additional functionality over the key=regex format, but may be easier to understand than the equivalent: List format: 4,5,7, Regex equivalent: EventCode=%^( )$% * key=regex format * A whitespace-separated list of event log components to match, and regexes to match against against them. * There can be one match expression or multiple per line. * The key must belong to the set of valid keys provided below. * The regex consists of a leading delimiter, the regex expression, and a trailing delimeter. Examples: %regex%, *regex*, "regex" * When multiple match expressions are present, they are treated as a logical AND. In other words, all expressions must match for the line to apply to the event. * If the value represented by the key does not exist, it is not considered a match, regardless of the regex. * Example: whitelist = EventCode=%^200$% User=%jrodman% * Include events only if they have EventCode 200 and relate to User jrodman Valid keys for the regex format: * The following keys are equivalent to the fields which appear in the text of the acquired events: Category CategoryString ComputerName EventCode EventType Keywords LogName Message OpCode RecordNumber Sid SidType SourceName TaskCategory Type User * There are two special keys that do not appear literally in the event. * $TimeGenerated : The time that the computer generated the event * $Timestamp: The time that the event was received and recorded by the Event Log service. * EventType is only available on Server 2003 / XP and earlier * Type is only available on Server 2008 / Vista and later * For a more full definition of these keys, see the web documentation: suppress_text = [0 1] * Tells Splunk whether or not to include the description of the event text for a given Event Log event. * Optional. This parameter can be left empty. * A value of 1 suppresses the inclusion of the event text description. * A value of 0 includes the event text description. * If no value is present, defaults to 0. renderxml= [true false] * Controls if the Event data is returned as XML or plain text * Defaults to false. Active Directory Monitor 161

162 [admon://<name>] * This section explains possible attribute/value pairs for configuring Splunk's Active Directory Monitor. * Each admon:// stanza represents an individually configured Active Directory monitoring input. If you configure the input with Splunk Web, then the value of "$NAME" will match what was specified there. While you can add Active Directory monitor inputs manually, Splunk recommends that you use the Manager interface to configure Active Directory monitor inputs because it is easy to mistype the values for Active Directory monitor objects. targetdc = <string> * Specifies a fully qualified domain name of a valid, network-accessible Active Directory domain controller. * If not specified, Splunk obtains the local computer's DC by default, and binds to its root Distinguished Name (DN). startingnode = <string> * Tells Splunk where in the Active Directory directory tree to start monitoring. * If not specified, Splunk attempts to start at the root of the directory tree. * The user that you configure Splunk to run as at installation determines where Splunk starts monitoring. monitorsubtree = [0 1] * Tells Splunk whether or not to monitor the subtree(s) of a given Active Directory tree path. * Defaults to 1 (monitor subtrees of a given directory tree path). disabled = [0 1] * Tells Splunk whether or not the input is enabled. * Defaults to 0 (enabled.) index = <string> * Tells Splunk which index to store incoming data into for this input. * This field is optional. * Defaults to the default index. printschema = [0 1] * Tells Splunk whether or not to print the Active Directory schema. * Defaults to 1 (print schema of Active Directory). baseline = [0 1] * Tells Splunk whether or not to query baseline objects. * Baseline objects are objects which currently reside in Active Directory. * Baseline objects also include previously deleted objects. * Defaults to 0 (do not query baseline objects). Windows Registry Monitor [WinRegMon://<name>] * This section explains possible attribute/value pairs for configuring Splunk's Windows Registry Monitor. * Each WinRegMon:// stanza represents an individually configured WinRegMon monitoring input. If you configure the inputs with Splunk Web, the value of "$NAME" will match what was specified there. While you can add event log monitor inputs manually, recommends that you use the Manager interface to configure Windows registry monitor inputs because it is easy to mistype the values for Registry hives and keys. * Note: WinRegMon is for local systems ONLY. proc = <string> * Tells Splunk which processes this input should monitor for Registry access. * If set, matches against the process name which performed the Registry access. * Events generated by processes that do not match the regular expression get filtered out. * Events generated by processes that match the regular expression pass through. * There is no default. 162

163 hive = <string> * Tells Splunk the Registry hive(s) that this input should monitor for Registry access. * If set, matches against the Registry key which was accessed. * Events that contain hives that do not match the regular expression get filtered out. * Events that contain hives that match the regular expression pass through. * There is no default. type = <string> * A regular expression that specifies the type(s) of Registry event(s) that you want Splunk to monitor. * There is no default. baseline = [0 1] * Specifies whether or not Splunk should get a baseline of Registry events when it starts. * If set to 1, the input will capture a baseline for the specified hive when the input starts for the first time. * Defaults to 0 (do not baseline the specified hive first before monitoring live events). baseline_interval = <integer> * Specifies how often, in seconds, that the Registry Monitor input should capture a baseline for a specific Registry hive or key. * Defaults to 0 (do not establish a baseline). disabled = [0 1] * Specifies whether or not the input is enabled. * 1 to disable the input, 0 to enable it. * Defaults to 0 (enabled). index = <string> * Specifies the index that this input should send the data to. * This attribute is optional. * If no value is present, defaults to the default index. Windows Host Monitoring [WinHostMon://<name>] * This section explains possible attribute/value pairs for configuring Splunk's Windows host monitor. * Each WinHostMon:// stanza represents an WinHostMon monitoring input. If you configure the input in SPlunk web, the value of "$NAME" will match what was specified there. * Note: WinHostMon is for local Windows systems ONLY. You can not monitor Windows host information remotely. type = <semicolon-separated strings> * An expression that specifies the type(s) of host inputs that you want Splunk to monitor. * Type can be Computer;Process;Processor;Application;NetworkAdapter;Service;OperatingSystem;Disk;Driver;Roles interval = <integer> * Specifies the interval, in seconds, between when the input runs to gather Windows host information. disabled = [0 1] * Specifies whether or not the input is enabled. * 1 to disable the input, 0 to enable it. * Defaults to 0 (enabled). index = <string> * Specifies the index that this input should send the data to. * This attribute is optional. * If no value is present, defaults to the default index. [WinPrintMon://<name>] * This section explains possible attribute/value pairs for configuring Splunk's Windows print Monitor. 163

164 * Each WinPrintMon:// stanza represents an WinPrintMon monitoring input. The value of "$NAME" will match what was specified in Splunk Web. * Note: WinPrintMon is for local systems ONLY. type = <semicolon-separated strings> * An expression that specifies the type(s) of print inputs that you want Splunk to monitor. baseline = [0 1] * If set to 1, the input will baseline the current print objects when the input is turned on for the first time. * Defaults to 0 (false), not baseline. disabled = [0 1] * Specifies whether or not the input is enabled. * 1 to disable the input, 0 to enable it. * Defaults to 0 (enabled). index = <string> * Specifies the index that this input should send the data to. * This attribute is optional. * If no value is present, defaults to the default index. [WinNetMon://<name>] * This section explains possible attribute/value pairs for configuring Splunk's Network Monitor. * Each WinNetMon:// stanza represents an individually configured network monitoring input. The value of "$NAME" will match what was specified in Splunk Web. Splunk recommends that you use the Manager interface to configure Network Monitor inputs because it is easy to mistype the values for Network Monitor monitor objects, counters and instances. remoteaddress = <regular expression> * If set, matches against the remote address. * Events with remote addresses that do not match the regular expression get filtered out. * Events with remote addresses that match the regular expression pass through. * Example: 192\.163\..* * Default (missing or empty setting) includes all events process = <regular expression> * If set, matches against the process/application name which performed network access * Events generated by processes that do not match the regular expression are filtered out. * Events generated by processes that match the regular expression are passed through. * Default (missing or empty proc setting) includes all processes/applications user = <regular expression> * If set, matches against the user name which performed network access * Events generated by users that do not match the regular expression are filtered out. * Events generated by users that match the regular expression are passed through. * Default (missing or empty user setting) includes access by all users addressfamily = ipv4;ipv6 * If set, matches against address family. * Accepts semicolon separated values, e.g. ipv4;ipv6 * Default (missing or empty address family setting) includes ipv4 and ipv6 traffic packettype = connect;accept;transport. * If set, matches against packet type * Accepts semicolon separated values, e.g. connect;transport * Default (missing or empty setting) includes all types direction = inbound;outbound * If set, matches against direction. * Accepts semicolon separated values, e.g. incoming;outgoing 164

165 * Default (missing or empty setting) includes all types protocol = tcp;udp * If set, matches against protocol ids. * Accepts semicolon separated values * Protocol are defined in * Example of protocol ids: tcp;udp * Default (missing or empty setting) includes all types readinterval = <integer> * Read network driver every readinterval milliseconds. * Advanced option. We recommend that the default value is used unless there is a problem with input performance. * Allows adjusting frequency of calls into kernel driver driver. Higher frequencies may affect network performance, while lower frequencies can cause event loss. * Default value: 100 msec * Minumum: 10 msec, maximum: 1 sec driverbuffersize = <integer> * Keep maximum number of network packets in network driver buffer. * Advanced option. We recommend that the default value is used unless there is a problem with input performance. * Controls amount of packets cached in the driver. Lower values may result in event loss. Higher values may increase the size of non-paged memory. * Default: packets. * Minumum: 128 packets, maximum: packets userbuffersize = <integer> * Maximum size in MB of user mode event buffer. * Advanced option. We recommend that the default value is used unless there is a problem with input performance. * Controls amount of packets cached in the the usre mode. Lower values may result in event loss. Higher values may increase the size of Splunk network monitor memory. * Default: 20 MB. * Minumum: 5 MB, maximum: 500 MB. mode = single,multikv * Specifies output mode. Output each event individually or in multikv format. * Default: single. multikvmaxeventcount = <integer> * Advanced option. When multikv mode is used output at most multikvmaxeventcount events. * Default: 100 events * Minumum: 10 events, maximum: 500 events multikvmaxtimems = <integer> * Advanced option. When multikv mode is used output no later than multikvmaxtimems milliseconds. * Default: 1000 ms * Minumum: 100 ms, maximum: 5000 ms disabled = [0 1] * Tells Splunk whether or not the input is enabled. * Defaults to 0 (enabled.) index = <string> * Tells Splunk which index to store incoming data into for this stanza. * This field is optional. * Defaults to the default index. inputs.conf.example Version This is an example inputs.conf. Use this file to configure data inputs. To use one or more of these configurations, copy the configuration block into inputs.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at 165

166 The following configuration directs Splunk to read all the files in the directory /var/log. [monitor:///var/log] The following configuration directs Splunk to read all the files under /var/log/httpd and classify them as sourcetype::access_common. When checking a file for new data, if the file's modtime is from before seven days ago, the file will no longer be checked for changes. [monitor:///var/log/httpd] sourcetype = access_common ignoreolderthan = 7d The following configuration directs Splunk to read all the files under /mnt/logs. When the path is /mnt/logs/<host>/... it sets the hostname (by file) to <host>. [monitor:///mnt/logs] host_segment = 3 The following configuration directs Splunk to listen on TCP port 9997 for raw data from ANY remote server (not just a Splunk instance). The host of the data is set to the IP address of the remote server. [tcp://:9997] The following configuration directs Splunk to listen on TCP port 9995 for raw data from ANY remote server. The host of the data is set as the host name of the remote server. All data will also be assigned the sourcetype "log4j" and the source "tcp:9995". [tcp://:9995] connection_host = dns sourcetype = log4j source = tcp:9995 The following configuration directs Splunk to listen on TCP port 9995 for raw data from All data is assigned the host "webhead-1", the sourcetype "access_common" and the the source "// /var/log/apache/access.log". [tcp:// :9995] host = webhead-1 sourcetype = access_common source = // /var/log/apache/access.log The following configuration sets a global default for data payloads sent from the light forwarder. The route parameter is an ordered set of rules that is evaluated in order for each payload of cooked data. [splunktcp] route=has_key:_utf8:indexqueue;has_key:_linebreaker:indexqueue;absent_key:_utf8:parsingqueue;absent_key:_linebreaker:parsingqueue; The following configuration directs Splunk to listen on TCP port 9996 for splunk cooked event data from ANY splunk forwarder. The host of the data is set to the host name of the remote server ONLY IF the remote data has no host set, or if it is set to "localhost". [splunktcp://:9996] connection_host = dns The following configuration directs Splunk to listen on TCP port 9996 for distributed search data from The data is processed the same as locally indexed data. [splunktcp:// :9996] The following configuration directs Splunk to listen on TCP port 514 for data from syslog.corp.company.net. The data is assigned the sourcetype "syslog" and the host is set to the host name of the remote server. 166

167 [tcp://syslog.corp.company.net:514] sourcetype = syslog connection_host = dns Set up SSL: [SSL] servercert=$splunk_home/etc/auth/server.pem password=password rootca=$splunk_home/etc/auth/cacert.pem requireclientcert=false [splunktcp-ssl:9996] Enable Windows Registry monitoring (Windows only) This example shows how to enable Windows Registry monitoring as a scripted input. Because the Windows Registry can generate a high volume of events, Windows Registry monitoring is also affected by two other configuration files, sysmon.conf and regmon.conf: * sysmon.conf contains global settings for which event types (adds, deletes, renames, and so on) to monitor, which regular expression filters from the regmon-filters.conf file to use, and whether or not Windows registry events are monitored at all. * regmon-filters.conf contains the specific regular expressions you create to refine and filter the hive key paths you want Splunk to monitor. Splunk recommends that you refer to the documentation about Windows Registry monitoring at for more details. You must make the change shown below in inputs.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. [script://$splunk_home\bin\scripts\splunk-regmon.path] interval = 60 sourcetype = WinRegistry source = WinRegistry disabled = 0 Enable WMI input (Windows only) This example shows how to enable WMI input as a scripted input. WMI input is also affected by configurations in wmi.conf. Splunk recommends that you refer to the documentation about WMI input at for more details. You must make this change in inputs.conf in $SPLUNK_HOME/etc/apps/windows/local/. You must restart Splunk to enable configurations. [script://$splunk_home\bin\scripts\splunk-wmi.path] disabled = 0 Use file system change monitor: [fschange:/etc/] fullevent=true pollperiod=60 recurse=true sendeventmaxsize= index=main Monitor Windows event logs Security, getting the most recent events first, then older, and finally continuing to gather newly arriving events [WinEventLog:Security] disabled = 0 start_from = newest evt_dc_name = evt_dns_name = evt_resolve_ad_obj = 1 checkpointinterval = 5 Monitor Windows event logs ForwardedEvents, this time only gathering the 167

168 events happening after first starting to monitor, going forward in time. [WinEventLog:ForwardedEvents] disabled = 0 start_from = oldest current_only = 1 checkpointinterval = 5 [tcp://9994] queuesize=50kb persistentqueuesize=100mb Perfmon: Windows performance monitoring examples Important: You must specify the names of objects, counters and instances exactly as they are shown in the Performance Monitor application. Splunk Web is the recommended interface to use to configure performance monitor inputs. Important: These stanzas gather performance data from the local system only. Use wmi.conf for performance monitor metrics on remote systems. Query the PhysicalDisk performance object and gather disk access data for all physical drives installed in the system. Store this data in the "perfmon" index. Note: If the interval attribute is set to 0, Splunk will reset the interval to 1. [perfmon://localphysicaldisk] interval = 0 object = PhysicalDisk counters = Disk Bytes/sec; % Disk Read Time; % Disk Write Time; % Disk Time instances = * disabled = 0 index = PerfMon Gather common memory statistics using the Memory performance object, every 5 seconds. Store the data in the "main" index. Since none of the counters specified have applicable instances, the instances attribute is not required. [perfmon://localmainmemory] interval = 5 object = Memory counters = Committed Bytes; Available Bytes; % Committed Bytes In Use disabled = 0 index = main Gather data on USB activity levels every 10 seconds. Store this data in the default index. [perfmon://usbchanges] interval = 10 object = USB counters = Usb Control Data Bytes/Sec instances = * disabled = 0 Admon: Windows Active Directory monitoring examples Monitor the default domain controller for the domain that the computer running Splunk belongs to. Start monitoring at the root node of Active Directory. [admon://nearestdc] targetdc = startingnode = Monitor a specific DC, with a specific starting node. Store the events in the "admon" Splunk index. Do not print Active Directory schema. Do not index baseline events. [admon://defaulttargetdc] targetdc = pri01.eng.ad.splunk.com startingnode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com index = admon printschema = 0 baseline = 0 168

169 Monitor two different DCs with different starting nodes. [admon://defaulttargetdc] targetdc = pri01.eng.ad.splunk.com startingnode = OU=Computers,DC=eng,DC=ad,DC=splunk,DC=com [admon://secondtargetdc] targetdc = pri02.eng.ad.splunk.com startingnode = OU=Computers,DC=hr,DC=ad,DC=splunk,DC=com instance.cfg.conf 다음은 instance.cfg.conf의 사양 및 예제 파일입니다. instance.cfg.conf.spec Version This file contains the set of attributes and values you can expect to find in the SPLUNK_HOME/etc/instance.cfg file; the instance.cfg file is not to be modified or removed by user. LEAVE THE instance.cfg FILE ALONE. GLOBAL SETTINGS The [general] stanza defines global settings. [general] guid = <GUID in all-uppercase> * This setting formerly (before 5.0) belonged in the [general] stanza of server.conf file. * Splunk expects that every Splunk instance will have a unique string for this value, independent of all other Splunk instances. By default, Splunk will arrange for this without user intervention. * Currently used by (not exhaustive): * Clustering environments, to identify participating nodes. * Splunk introspective searches (Splunk on Splunk, Deployment Monitor, etc.), to identify forwarders. * At startup, the following happens: * If server.conf has a value of 'guid' AND instance.cfg has no value of 'guid', then the value will be erased from server.conf and moved to instance.cfg file. * If server.conf has a value of 'guid' AND instance.cfg has a value of 'guid' AND these values are the same, the value is erased from server.conf file. * If server.conf has a value of 'guid' AND instance.cfg has a value of 'guid' AND these values are different, startup halts and error is shown. Operator must resolve this error. We recommend erasing the value from server.conf file, and then restarting. * If you are hitting this error while trying to mass-clone Splunk installs, please look into the command 'splunk clone-prep-clear-config'; 'splunk help' has help. * See for how a GUID (a.k.a. UUID) is constructed. 9A-F]{12}". * The standard regexp to match an all-uppercase GUID is "[0-9A-F]{8}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{4}-[0- instance.cfg.conf.example Version This file contains an example SPLUNK_HOME/etc/instance.cfg file; the instance.cfg file 169

170 is not to be modified or removed by user. LEAVE THE instance.cfg FILE ALONE. [general] guid = B58A86D9-DF3D-4BF8-A426-DB85C231B699 limits.conf 다음은 limits.conf의 사양 및 예제 파일입니다. limits.conf.spec Version This file contains possible attribute/value pairs for configuring limits for search commands. There is a limits.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a limits.conf in $SPLUNK_HOME/etc/system/local/. For examples, see limits.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at limits.conf settings and DISTRIBUTED SEARCH Unlike most settings which affect searches, limits.conf settings are not provided by the search head to be used by the search peers. This means that if you need to alter search-affecting limits in a distributed environment, typically you will need to modify these settings on the relevant peers and search head for consistent results. GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. CAUTION: Do not alter the settings in limits.conf unless you know what you are doing. Improperly configured limits may result in splunkd crashes and/or memory overuse. * Each stanza controls different parameters of search commands. max_mem_usage_mb = <non-negative integer> * Provides a limitation to the amount of RAM a batch of events or results will use in the memory of search processes. * Operates on an estimation of memory use which is not exact. * The limitation is applied in an unusual way; if the number of results or events exceeds maxresults, AND the estimated memory exceeds this limit, the data is spilled to disk. * This means, as a general rule, lower limits will cause a search to use more disk I/O and less RAM, and be somewhat slower, but should cause the same results to typically come out of the search in the end. * This limit is applied currently to a number, but not all search processors. However, more will likely be added as it proves necessary. * The number is thus effectively a ceiling on batch size for many components of search for all searches run on this system. * 0 will specify the size to be unbounded. In this case searches may be allowed to grow to arbitrary sizes. * The 'mvexpand' command uses this value in a different way. * mvexpand has no combined logic with maxresults * If the memory limit is exceeded, output is truncated, not spilled to disk. * This value is not exact. The estimation can deviate by an order of magnitude or so to both the smaller and larger sides. * Defaults to 200 (MB) 170

171 min_batch_size_bytes = <integer> * Specifies the size of the file/tar after which the file is handled by the batch reader instead of the trailing processor. * Global parameter, cannot be configured per input. * Note configuring this to a very small value could lead to backing up of jobs at the tailing processor. * defaults to 20 MB [searchresults] * This stanza controls search results for a variety of Splunk search commands. maxresultrows = <integer> * Configures the maximum number of events are generated by search commands which grow the size of your result set (such as multikv) or that create events. Other search commands are explicitly controlled in specific stanzas below. * This limit should not exceed Setting this limit higher than causes instability. * Defaults to tocsv_maxretry = <integer> * Maximum number of times to retry the atomic write operation. * 1 = no retries. * Defaults to 5. tocsv_retryperiod_ms = <integer> * Period of time to wait before each retry. * Defaults to 500. * These setting control logging of error messages to info.csv All messages will be logged to search.log regardless of these settings. compression_level = <integer> * Compression level to use when writing search results to.csv.gz files * Defaults to 1 [search_info] * This stanza controls logging of messages to the info.csv file * Messages logged to info.csv are available in to REST api clients, and the Splunk UI, something something, so limiting the messages added to info.csv will mean that these messages will not be available in the UI and/or the REST api something something. max_infocsv_messages = <positive integer> * If more than max_infocsv_messages log entries are generated, additional entries will not be logged in info.csv. All entries will still be logged in search.log. infocsv_log_level = [DEBUG INFO WARN ERROR] * Limits the messages which are added to info.csv to the stated level and above. * For example, if log_level is WARN, messages of type WARN and higher will be added to info.csv [subsearch] * This stanza controls subsearch results. * NOTE: This stanza DOES NOT control subsearch results when a subsearch is called by commands such as join, append, or appendcols. * Read more about subsearches in the online documentation: maxout = <integer> * Maximum number of results to return from a subsearch. * This value cannot be greater than or equal to * Defaults to maxtime = <integer> * Maximum number of seconds to run a subsearch before finalizing * Defaults to 60. ttl = <integer> * Time to cache a given subsearch's results, in seconds. * Do not set this below 120 seconds. * See definition in [search] ttl for more details on how the ttl is computed * Defaults to

172 [anomalousvalue] maxresultrows = <integer> * Configures the maximum number of events that can be present in memory at one time. * Defaults to searchresults::maxresultsrows (which is by default 50000). maxvalues = <integer> * Maximum number of distinct values for a field. * Defaults to maxvaluesize = <integer> * Maximum size in bytes of any single value (truncated to this size if larger). * Defaults to [associate] maxfields = <integer> * Maximum number of fields to analyze. * Defaults to maxvalues = <integer> * Maximum number of values for any field to keep track of. * Defaults to maxvaluesize = <integer> * Maximum length of a single value to consider. * Defaults to [autoregress] maxp = <integer> * Maximum valid period for auto regression * Defaults to maxrange = <integer> * Maximum magnitude of range for p values when given a range. * Defaults to [concurrency] max_count = <integer> * Maximum number of detected concurrencies. * Defaults to [ctable] * This stanza controls the contingency, ctable, and counttable commands. maxvalues = <integer> * Maximum number of columns/rows to generate (the maximum number of distinct values for the row field and column field). * Defaults to [correlate] maxfields = <integer> * Maximum number of fields to correlate. * Defaults to [discretize] * This stanza set attributes for bin/bucket/discretize. default_time_bins = <integer> * When discretizing time for timechart or explicitly via bin, the default bins to use if no span or bins is specified. * Defaults to 100 maxbins = <integer> * Maximum number of buckets to discretize into. 172

173 * If maxbins is not specified or = 0, it defaults to searchresults::maxresultrows (which is by default 50000). [export] add_timestamp = <bool> * Add a epoch time timestamp to JSON streaming output that reflects the time the results were generated/retrieved * Defaults to false add_offset = <bool> * Add an offset/row number to JSON streaming output * Defaults to true [extern] perf_warn_limit = <integer> * Warn when external scripted command is applied to more than this many events * set to 0 for no message (message is always INFO level) * Defaults to [inputcsv] mkdir_max_retries = <integer> * Maximum number of retries for creating a tmp directory (with random name as subdir of SPLUNK_HOME/var/run/splunk) * Defaults to 100. [indexpreview] max_preview_bytes = <integer> * Maximum number of bytes to read from each file during preview * Defaults to (2 MB) max_results_perchunk = <integer> * Maximum number of results to emit per call to preview data generator * Defaults to 2500 soft_preview_queue_size = <integer> * Loosely-applied maximum on number of preview data objects held in memory * Defaults to 100 [join] subsearch_maxout = <integer> * Maximum result rows in output from subsearch to join against. * Defaults to subsearch_maxtime = <integer> * Maximum search time (in seconds) before auto-finalization of subsearch. * Defaults to 60 subsearch_timeout = <integer> * Maximum time to wait for subsearch to fully finish (in seconds). * Defaults to 120 [kmeans] maxdatapoints = <integer> * Maximum data points to do kmeans clusterings for. * Defaults to maxkvalue = <integer> * Maximum number of clusters to attempt to solve for. * Defaults to 1000 maxkrange = <integer> * Maximum number of k values to iterate over when specifying a range. * Defaults to 100 [kv] maxcols = <integer> * When non-zero, the point at which kv should stop creating new fields. * Defaults to 512. limit = <integer> * Maximum number of keys auto kv can generate. * Defaults to

174 maxchars = <integer> * Truncate _raw to this size and then do auto KV. * Defaults to characters. max_extractor_time = <integer> * Maximum amount of CPU time, in milliseconds, that a key-value pair extractor will be allowed to * take before warning. If the extractor exceeds this execution time on any event a warning will be issued * Defaults to 1000 avg_extractor_time = <integer> * Maximum amount of CPU time, in milliseconds, that the average (over search results) execution time of * a key-value pair extractor will be allowed to take before warning. Once the average becomes larger * than this amount of time a warning will be issued * Defaults to 500 [lookup] max_memtable_bytes = <integer> * Maximum size of static lookup file to use an in-memory index for. * Defaults to in bytes (10MB max_matches = <integer> * maximum matches for a lookup * range * Defaults to 1000 max_reverse_matches = <integer> * maximum reverse lookup matches (for search expansion) * Defaults to 50 batch_index_query = <bool> * Should non-memory file lookups (files that are too large) use batched queries to possibly improve performance? * Defaults to true batch_response_limit = <integer> * When doing batch requests, the maximum number of matches to retrieve * if more than this limit of matches would otherwise be retrieve, we will fall back to non-batch mode matching * Defaults to max_lookup_messages = <positive integer> * If more than "max_lookup_messages" log entries are generated, additional entries will not be logged in info.csv. All entries will still be logged in search.log. [metrics] maxseries = <integer> * The number of series to include in the per_x_thruput reports in metrics.log. * Defaults to 10. interval = <integer> * Number of seconds between logging splunkd metrics to metrics.log. * Minimum of 10. * Defaults to 30. [metrics:tcpin_connections] aggregate_metrics = [true false] * For each splunktcp connection from forwarder, splunk logs metrics information every metrics interval. * When there are large number of forwarders connected to indexer, the amount of information logged can take * log of space in metrics.log. When set to true, it will aggregate information across each connection and * report only once per metrics interval. * Defaults to false suppress_derived_info = [true false] * For each forwarder connection, _tcp_bps, _tcp_kbps, _tcp_avg_thruput, _tcp_kprocessed is logged in metrics.log. * This can be derived from kb. When set to true, the above derived info will not be emitted. * Defaults to true [rare] maxresultrows = <integer> 174

175 * Maximum number of result rows to create. * If not specified, defaults to searchresults::maxresultrows (which is by default 50000). maxvalues = <integer> * Maximum number of distinct field vector values to keep track of. * Defaults maxvaluesize = <integer> * Maximum length of a single value to consider. * Defaults to [restapi] maxresultrows = <integer> * Maximum result rows to be returned by /events or /results getters from REST API. * Defaults to time_format_reject = <regular expression> * HTTP parameters for time_format and output_time_format which match this regex will be rejected (blacklisted). * The regex will be satisfied by a substring match anywhere in the paramater. * Intended as defense-in-depth against XSS style attacks against browser users by crafting specially encoded URLS for them to access splunkd. * If unset, all parameter strings will be accepted. * To disable this check entirely, set the value to empty. Example of disabling: time_format_reject = * Defaults to [<>!], which means that the less-than '<', greater-than '>', and exclaimation point '!' are not allowed. jobscontentmaxcount = <integer> * Maximum length of a property in the contents dictionary of an entry from /jobs getter from REST API * Value of 0 disables truncation * Defaults to 0 [search_metrics] debug_metrics = <bool> * This indicates whether we should output more detailed search metrics for debugging. * This will do things like break out where the time was spent by peer, and may add additional deeper levels of metrics. * This is NOT related to "metrics.log" but to the "Execution Costs" and "Performance" fields in the Search inspector, or the count_map in info.csv. * Defaults to false [search] summary_mode = [all only none] * Controls if precomputed summary are to be used if possible? * all: use summary if possible, otherwise use raw data * only: use summary if possible, otherwise do not use any data * none: never use precomputed summary data * Defaults to 'all' result_queue_max_size = <integer> * Controls the size of the search results queue in dispatch * Default size is set to 100MB * Use caution while playing with this parameter use_bloomfilter = <bool> * Control whether to use bloom filters to rule out buckets max_id_length = <integer> * Maximum length of custom search job id when spawned via REST api arg id= ttl = <integer> * How long search artifacts should be stored on disk once completed, in seconds. The ttl is computed * relative to the modtime of status.csv of the job if such file exists or the modtime of the search * job's artifact directory. If a job is being actively viewed in the Splunk UI then the modtime of * status.csv is constantly updated such that the reaper does not remove the job from underneath. * Defaults to 600, which is equivalent to 10 minutes. default_save_ttl = <integer> * How long the ttl for a search artifact should be extended in response to the save control action, in second. 0 = indefinitely. 175

176 * Defaults to (1 week) remote_ttl = <integer> * How long artifacts from searches run in behalf of a search head should be stored on the indexer after completion, in seconds. * Defaults to 600 (10 minutes) status_buckets = <integer> * The approximate maximum number buckets to generate and maintain in the timeline. * Defaults to 0, which means do not generate timeline information. max_bucket_bytes = <integer> * This setting has been deprecated and has no effect max_count = <integer> * The number of events that can be accessible in any given status bucket. * The last accessible event in a call that takes a base and bounds. * Defaults to max_events_per_bucket = <integer> * For searches with status_buckets>0 this will limit the number of events retrieved per timeline bucket. * Defaults to 1000 in code. truncate_report = [1 0] * Specifies whether or not to apply the max_count limit to report output. * Defaults to false (0). min_prefix_len = <integer> * The minimum length of a prefix before a * to ask the index about. * Defaults to 1. cache_ttl = <integer> * The length of time to persist search cache entries (in seconds). * Defaults to 300. max_results_perchunk = <integer> * Maximum results per call to search (in dispatch), must be less than or equal to maxresultrows. * Defaults to 2500 min_results_perchunk = <integer> * Minimum results per call to search (in dispatch), must be less than or equal to max_results_perchunk. * Defaults to 100 max_rawsize_perchunk = <integer> * Maximum raw size of results per call to search (in dispatch). * 0 = no limit. * Defaults to (100MB) * Not affected by chunk_multiplier target_time_perchunk = <integer> * Target duration of a particular call to fetch search results in ms. * Defaults to 2000 long_search_threshold = <integer> * Time in seconds until a search is considered "long running". * Defaults to 2 chunk_multiplier = <integer> * max_results_perchunk, min_results_perchunk, and target_time_perchunk are multiplied by this for a long running search. * Defaults to 5 min_freq = <number> * Minimum frequency of a field required for including in the /summary endpoint as a fraction (>=0 and <=1). * Defaults is 0.01 (1%) reduce_freq = <integer> * Attempt to reduce intermediate results every how many chunks (0 = never). * Defaults to 10 reduce_duty_cycle = <number> * the maximum time to spend doing reduce, as a fraction of total search time 176

177 * Must be > 0.0 and < 1.0 * Defaults to 0.25 preview_duty_cycle = <number> * the maximum time to spend generating previews, as a fraction of total search time * Must be > 0.0 and < 1.0 * Defaults to 0.25 results_queue_min_size = <integer> * The minimum size for the queue of results that will be kept from peers for processing on the search head. * The queue will be the max of this and the number of peers providing results. * Defaults to 10 dispatch_quota_retry = <integer> * The maximum number of times to retry to dispatch a search when the quota has been reached. * Defaults to 4 dispatch_quota_sleep_ms = <integer> * Milliseconds between retrying to dispatch a search if a quota has been reached. * Retries the given number of times, with each successive wait 2x longer than the previous. * Defaults to 100 base_max_searches = <int> * A constant to add to the maximum number of searches, computed as a multiplier of the CPUs. * Defaults to 6 max_searches_per_cpu = <int> * The maximum number of concurrent historical searches per CPU. The system-wide limit of historical searches is computed as: max_hist_searches = max_searches_per_cpu x number_of_cpus + base_max_searches * Note: the maximum number of real-time searches is computed as: max_rt_searches = max_rt_search_multiplier x max_hist_searches * Defaults to 1 max_rt_search_multiplier = <decimal number> * A number by which the maximum number of historical searches is multiplied to determine the maximum * number of concurrent real-time searches * Note: the maximum number of real-time searches is computed as: max_rt_searches = max_rt_search_multiplier x max_hist_searches * Defaults to 1 max_macro_depth = <int> * Max recursion depth for macros. * Considered a search exception if macro expansion doesn't stop after this many levels. * Must be greater than or equal to 1. * Default is 100 realtime_buffer = <int> * Maximum number of accessible events to keep for real-time searches from Splunk Web. * Acts as circular buffer once this limit is reached * Must be greater than or equal to 1 * Default is stack_size = <int> * The stack size (in bytes) of the thread executing the search. * Defaults to (4 MB) status_cache_size = <int> * The number of search job status data splunkd can cache in RAM. This cache improves performance of the jobs endpoint * Defaults to 2000 timeline_freq = <timespan> or <ratio> * Minimum amount of time between timeline commits. * If specified as a number < 1 (and > 0), minimum time between commits is computed as a ratio of the amount of time that the search has been running. * defaults to 0 seconds preview_freq = <timespan> or <ratio> * Minimum amount of time between results preview updates. * If specified as a number < 1 (and > 0), minimum time between previews is computed as a ratio of the amount of time that the search has been running, or as a ratio of the length of the time window 177

178 for real-time windowed searches. * Defaults to ratio of 0.05 max_combiner_memevents = <int> * Maximum size of in-memory buffer for search results combiner, in terms of number of events. * Defaults to events. replication_period_sec = <int> * The minimum amount of time in seconds between two successive bundle replications. * Defaults to 60 replication_file_ttl = <int> * The TTL (in seconds) of bundle replication tarballs, i.e. *.bundle files. * Defaults to 600 (10m) sync_bundle_replication = [0 1 auto] * Flag indicating whether configuration file replication blocks searches or is run asynchronously * When setting this flag to auto Splunk will choose to use asynchronous replication if and only if all the peers * support async bundle replication, otherwise it will fall back into sync replication. * Defaults to auto multi_threaded_setup = [0 1] * Flag indicating whether to use multiple threads when setting up distributed search to multiple peers. * Defaults to false (0) rr_min_sleep_ms = <int> * Minimum time to sleep when reading results in round-robin mode when no data is available. * Defaults to 10. rr_max_sleep_ms = <int> * Maximum time to sleep when reading results in round-robin mode when no data is available. * Defaults to 1000 rr_sleep_factor = <int> * If no data is available even after sleeping, increase the next sleep interval by this factor. * defaults to 2 fieldstats_update_freq = <number> * How often to update the field summary statistics, as a ratio to the elapsed run time so far. * Smaller values means update more frequently. 0 means as frequently as possible. * Defaults to 0 fieldstats_update_maxperiod = <int> * Maximum period for updating field summary statistics in seconds * 0 means no maximum, completely dictated by current_run_time * fieldstats_update_freq * defaults to 60 remote_timeline = [0 1] * If true, allows the timeline to be computed remotely to enable better map/reduce scalability. * defaults to true (1). remote_timeline_prefetch = <int> * Each peer should proactively send at most this many full events at the beginning * Defaults to 100. remote_timeline_parallel_fetch = <bool> * Connect to multiple peers at the same time when fetching remote events? * Defaults to true remote_timeline_min_peers = <int> * Minimum search peers for enabling remote computation of timelines. * Defaults to 1 (1). remote_timeline_fetchall = [0 1] * If true, fetches all events accessible through the timeline from the remote peers before the job is considered done. * Defaults to true (1). remote_timeline_thread = [0 1] * If true, uses a separate thread to read the full events from remote peers if remote_timeline is used and remote_timeline_fetchall is set to true. (Has no effect if remote_timeline or remote_timeline_fetchall is false). 178

179 * Defaults to true (1). remote_timeline_max_count = <int> * Maximum number of events to be stored per timeline bucket on each search peer, * Defaults to remote_timeline_max_size_mb = <int> * Maximum size of disk that remote timeline events should take on each peer * If limit is reached, a DEBUG message is emitted (and should be visible from job inspector/messages * Defaults to 100 remote_timeline_touchperiod = <int> * How often to touch remote timeline artifacts to keep them from being deleted by the remote peer, while a search is running. * In seconds, 0 means never. * Defaults to 300. remote_timeline_connection_timeout = <int> * Connection timeout in seconds for fetching events processed by remote peer timeliner. * Defaults to 5. remote_timeline_send_timeout = <int> * Send timeout in seconds for fetching events processed by remote peer timeliner. * Defaults to 10. remote_timeline_receive_timeout = <int> * Receive timeout in seconds for fetching events processed by remote peer timeliner. * Defaults to 10. default_allow_queue = [0 1] * Unless otherwise specified via REST api argument should an async job spawning request be queued on quota violation (if not, an http error of server too busy is returned) * Defaults to true (1). queued_job_check_freq = <int> * Frequency with which to check queued jobs to see if they can be started, in seconds * Defaults to 1. enable_history = <bool> * Enable keeping track of searches? * Defaults to true max_history_length = <int> * Max number of searches to store in history (per user/app) * Defaults to 1000 allow_inexact_metasearch = <bool> * Should a metasearch that is inexact be allow. If so, an INFO message will be added to the inexact metasearches. If not, a fatal exception will occur at search parsing time. * Defaults to false indexed_as_exact_metasearch = <bool> * Should we allow a metasearch to treat <field>=<value> the same as <field>::<value> if <field> is an indexed field. Allowing this will allow a larger set of metasearches when allow_inexact_metasearch is set to false. However, some of these searches may be inconsistent with the results of doing a normal search. * Defaults to false dispatch_dir_warning_size = <int> * The number of jobs in the dispatch directory when to issue a bulletin message warning that performance could be impacted * Defaults to 2000 allow_reuse = <bool> * Allow normally executed historical searches to be implicitly re-used for newer requests if the newer request allows it? * Defaults to true track_indextime_range = <bool> * Track the _indextime range of returned search results? * Defaults to true reuse_map_maxsize = <int> 179

180 * Maximum number of jobs to store in the reuse map * Defaults to 1000 status_period_ms = <int> * The minimum amout of time, in milliseconds, between successive status/info.csv file updates * This ensures search does not spend significant time just updating these files. * This is typically important for very large number of search peers. * It could also be important for extremely rapid responses from search peers, when the search peers have very little work to do. * Defaults to 1000 (1 second) search_process_mode = auto traditional debug <debugging-command> [debugging-args...] * Control how search processes are started * When set to "traditional", Splunk initializes each search process completely from scratch * When set to a string beginning with "debug", Splunk routes searches through the given command, allowing the user the to "plug in" debugging tools * The <debugging-command> must reside in one of * $SPLUNK_HOME/etc/system/bin/ * $SPLUNK_HOME/etc/apps/$YOUR_APP/bin/ * $SPLUNK_HOME/bin/scripts/ * Splunk will pass <debugging-args>, followed by the search command it would normally run, to <debuggingcommand> * For example, given: search_process_mode = debug $SPLUNK_HOME/bin/scripts/search-debugger.sh 5 Splunk will run a command that looks generally like: $SPLUNK_HOME/bin/scripts/search-debugger.sh 5 splunkd search --id=... --maxbuckets=... --ttl=... [...] * Defaults to "auto" fetch_remote_search_log = [enabled disabledsavedsearches disabled] * enabled: all remote search logs will be downloaded barring the oneshot search * disabledsavedsearches: download all remote logs other than saved search logs and oneshot search logs * disabled: irrespective of the search type all remote search log download functionality will be disabled * Defaults to disabledsavedsearches * The previous values:[true false] are still supported but not recommended for use * The previous value of true maps to the current value of enabled * The previous value of false maps to the current value of disabled load_remote_bundles = <bool> * On a search peer, allow remote (search head) bundles to be loaded in splunkd. * Defaults to false. use_dispatchtmp_dir = <bool> * Whether to use the dispatchtmp directory for temporary search time files (write temporary files to a different directory from a job's dispatch directory). * Temp files would be written to $SPLUNK_HOME/var/run/splunk/dispatchtmp/<sid>/ * In search head pooling performance can be improved by mounting disaptchtmp to the * local file system. * Defaults to true if search head pooling is enabled, false otherwise check_splunkd_period = <int> * Amount of time, in seconds, that determines how frequently the search process * (when running a real-time search) checks whether it's parent process (splunkd) is running or not. * Defaults to 60 allow_batch_mode = <bool> * Whether or not to allow the use of batch mode which searches in disk based batches in a time insensitive manner. * In distributed search environments, this setting is used on the search head. * Defaults to true batch_search_max_index_values = <int> * When using batch mode this limits the number of event entries read from the index file. These entries are small * approximately 72 bytes. However batch mode is more efficient when it can read more entries at once. * Setting this value to a smaller number can lead to slower search performance. A balance needs to be struck * between more efficient searching in batch mode and running out of memory on the system with concurrently running searches. * Defaults to * These settings control the periodicity of retries to search peers in the event of failure. (Connection * errors, and others.) The interval exists between failure and first retry, as well as successive * retries in the event of further failures. 180

181 batch_retry_min_interval = <int> * When batch mode attempts to retry the search on a peer that failed wait at least this many seconds * Default to 5 batch_retry_max_interval = <int> * When batch mode attempts to retry the search on a peer that failed wait at most this many seconds * Default to 300 batch_retry_scaling = <double> * After a retry attempt fails increase the time to wait before trying again by this scaling factor (Value should be > 1.0) * Default 1.5 batch_wait_after_end = <int> * Batch mode considers the search ended(finished) when all peers without communication failure * have expicitly indicated that they are complete; eg have delivered the complete answer. * After the search is at an end, batch mode will continue to retry with lost-connection peers * for this many seconds. * Default 900 write_multifile_results_out = <bool> * at the end of the search if results are in multiple files, write out the multiple * files to results_dir directory, under the search results directory. * This will speed up post-processing search, since the results will already be * split into appropriate size files. * Default true enable_cumulative_quota = <bool> * whether to enforce cumulative role based quotas * Default false remote_reduce_limit = <unsigned long> * the number of results processed by a streaming search before we force a reduce * Note: this option applies only if the search is ran with --runreduce=true (currently on Hunk does this) * Note: a value of 0 is interpreted as unlimited * Defaults to: max_workers_searchparser = <int> * the number of worker threads in processing search result when using round robin policy. * default 5 max_chunk_queue_size = <int> * the maximum size of the chunk queue * default max_tolerable_skew = <positive integer> * Absolute value of the largest timeskew in seconds that we will tolerate between the native clock on the searchhead and the natic clock on the peer (independant of time-zone). * If this timeskew is exceeded we will log a warning. This estimate is approximate and tries to account for network delays. -- Unsupported [search] settings: -- enable_status_cache = <bool> * This is not a user tunable setting. Do not use this setting without working in tandem with Splunk personnel. This setting is not tested at non-default. * This controls whether the status cache is used, which caches information about search jobs (and job artifacts) in memory in main splunkd. * Normally this cacheing is enabled and assists performance. However, when using Search Head Pooling, artifacts in the shared storage location will be changed by other serach heads, so this cacheing is disabled. * Explicit requests to jobs endpoints, eg /services/search/jobs/<sid> are always satisfied from disk, regardless of this setting. * Defaults to true; except in Search Head Pooling environments where it defaults to false. status_cache_in_memory_ttl = <positive integer> * This setting has no effect unless search head pooling is enabled, AND enable_status_cache has been set to true. * This is not a user tunable setting. Do not use this setting without working in tandem with Splunk personnel. This setting is not tested at non-default. 181

182 * If set, controls the number of milliseconds which a status cache entry may be used before it expires. * Defaults to 60000, or 60 seconds. [realtime] Default options for indexer support of real-time searches These can all be overriden for a single search via REST API arguments local_connect_timeout = <int> * Connection timeout for an indexer's search process when connecting to that indexer's splunkd (in seconds) * Defaults to 5 local_send_timeout = <int> * Send timeout for an indexer's search process when connecting to that indexer's splunkd (in seconds) * Defaults to 5 local_receive_timeout = <int> * Receive timeout for an indexer's search process when connecting to that indexer's splunkd (in seconds) * Defaults to 5 queue_size = <int> * Size of queue for each real-time search (must be >0). * Defaults to blocking = [0 1] * Specifies whether the indexer should block if a queue is full. * Defaults to false max_blocking_secs = <int> * Maximum time to block if the queue is full (meaningless if blocking = false) * 0 means no limit * Default to 60 indexfilter = [0 1] * Specifies whether the indexer should prefilter events for efficiency. * Defaults to true (1). default_backfill = <bool> * Specifies if windowed real-time searches should backfill events * Defaults to true enforce_time_order = <bool> * Specifies if real-time searches should ensure that events are sorted in ascending time order (the UI will automatically reverse the order that it display events for real-time searches so in effect the latest events will be first) * Defaults to true disk_usage_update_period = <int> * Specifies how frequently (in seconds) should the search process estimate the artifact disk usage. * Defaults to 10 indexed_realtime_use_by_default = <bool> * Should we use the indexedrealtime mode by default * Precedence: SearchHead * Defaults to false indexed_realtime_disk_sync_delay = <int> * After indexing there is a non-deterministic period where the files on disk when opened by other * programs might not reflect the latest flush to disk, particularly when a system is under heavy load. * This settings controls the number of seconds to wait for disk flushes to finish when using * indexed/continuous/psuedo realtime search so that we see all of the data. * Precedence: SearchHead overrides Indexers * Defaults to 60 indexed_realtime_default_span = <int> * An indexed realtime search is made up of many component historical searches that by default will * span this many seconds. If a component search is not completed in this many seconds the next * historical search will span the extra seconds. To reduce the overhead of running an indexed realtime * search you can change this span to delay longer before starting the next component historical search. * Precendence: Indexers * Defaults to 1 182

183 indexed_realtime_maximum_span = <int> * While running an indexed realtime search, if the component searches regularly take longer than * indexed_realtime_default_span seconds, then indexed realtime search can fall more than * indexed_realtime_disk_sync_delay seconds behind realtime. Use this setting to set a limit * afterwhich we will drop data to return back to catch back up to the specified delay from * realtime, and only search the default span of seconds. * Precedence: API overrides SearchHead overrides Indexers * Defaults to 0 (unlimited) indexed_realtime_cluster_update_interval = <int> * While running an indexed realtime search, if we are on a cluster we need to update the list * of allowed primary buckets. This controls the interval that we do this. And it must be less * than the indexed_realtime_disk_sync_delay. If your buckets transition from Brand New to warm * in less than this time indexed realtime will lose data in a clustered environment. * Precendence: Indexers * Default: 30 alerting_period_ms = <int> * This limits the frequency that we will trigger alerts during a realtime search * 0 means unlimited and we will trigger an alert for every batch of events we read * in dense realtime searches with expensive alerts this can overwhelm the alerting * system. * Precedence: Searchhead * Default: 0 [slc] maxclusters = <integer> * Maximum number of clusters to create. * Defaults to [findkeywords] maxevents = <integer> * Maximum number of events used by findkeywords command and the Patterns tab. * Defaults to [sort] maxfiles = <integer> * Maximum files to open at once. Multiple passes are made if the number of result chunks exceeds this threshold. * Defaults to 64. [stats sistats] maxmem_check_freq = <integer> * How frequently to check to see if we are exceeding the in memory data structure size limit as specified by max_mem_usage_mb, in rows * Defaults to rows maxresultrows = <integer> * Maximum number of rows allowed in the process memory. * When the search process exceeds max_mem_usage_mb and maxresultrows, data is spilled out to the disk * If not specified, defaults to searchresults::maxresultrows (which is by default 50000). maxvalues = <integer> * Maximum number of values for any field to keep track of. * Defaults to 0 (unlimited). maxvaluesize = <integer> * Maximum length of a single value to consider. * Defaults to 0 (unlimited). rdigest is a data structure used to compute approximate order statistics (such as median and percentiles) using sublinear space. rdigest_k = <integer> * rdigest compression factor * Lower values mean more compression * After compression, number of nodes guaranteed to be greater than or equal to 11 times k. * Defaults to 100, must be greater than or equal to 2 183

184 rdigest_maxnodes = <integer> * Maximum rdigest nodes before automatic compression is triggered. * Defaults to 1, meaning automatically configure based on k value max_stream_window = <integer> * For streamstats command, the maximum allow window size * Defaults to max_valuemap_bytes = <integer> * For sistats command, the maximum encoded length of the valuemap, per result written out * If limit is exceeded, extra result rows are written out as needed. (0 = no limit per row) * Defaults to perc_method = nearest-rank interpolated * Which method to use for computing percentiles (and medians=50 percentile). * nearest-rank picks the number with 0-based rank R = floor((percentile/100)*count) * interpolated means given F = (percentile/100)*(count-1), pick ranks R1 = floor(f) and R2 = ceiling(f). Answer = (R2 * (F - R1)) + (R1 * (1 - (F - R1))) * See wikipedia percentile entries on nearest rank and "alternative methods" * Defaults to interpolated approx_dc_threshold = <integer> * When using approximate distinct count (i.e. estdc(<field>) in stats/chart/timechart), do not use approximated results if the actual number of distinct values is less than this number * Defaults to 1000 dc_digest_bits = <integer> * 2^<integer> bytes will be size of digest used for approximating distinct count. * Defaults to 10 (equivalent to 1KB) * Must be >= 8 (128B) and <= 16 (64KB) natural_sort_output = <bool> * Do a natural sort on the output of stats if output size is <= maxresultrows * Natural sort means that we sort numbers numerically and non-numbers lexicographically * Defaults to true list_maxsize = <int> * Maximum number of list items to emit when using the list() function stats/sistats * Defaults to 100 sparkline_maxsize = <int> * Maximum number of elements to emit for a sparkline * Defaults to value of list_maxsize setting default_partitions = <int> * Number of partitions to split incoming data into for parallel/multithreaded reduce * Defaults to 1 partitions_limit = <int> * Maximum number of partitions to split into that can be specified via the 'partitions' option. * When exceeded, the number of partitions is reduced to this limit. * Defaults to 100 [thruput] maxkbps = <integer> * If specified and not zero, this limits the speed through the thruput processor to the specified rate in kilobytes per second. * To control the CPU load while indexing, use this to throttle the number of events this indexer processes to the rate (in KBps) you specify. [journal_compression] threads = <integer> * Specifies the maximum number of indexer threads which will be work on compressing hot bucket journal data. * Defaults to the number of CPU threads of the host machine * This setting does not typically need to be modified. [top] maxresultrows = <integer> 184

185 * Maximum number of result rows to create. * If not specified, defaults to searchresults::maxresultrows (usually 50000). maxvalues = <integer> * Maximum number of distinct field vector values to keep track of. * Defaults to maxvaluesize = <integer> * Maximum length of a single value to consider. * Defaults to [summarize] hot_bucket_min_new_events = <integer> * The minimum number of new events that need to be added to the hot bucket (since last summarization) * before a new summarization can take place. To disable hot bucket summarization set this value to a * large positive number. * Defaults to sleep_seconds = <integer> * The amount of time to sleep between polling of summarization complete status. * Default to 5 stale_lock_seconds = <integer> * The amount of time to have elapse since the mod time of a.lock file before summarization considers * that lock file stale and removes it * Default to 600 max_summary_ratio = <float> * A number in the [0-1) range that indicates the maximum ratio of summary data / bucket size at which * point the summarization of that bucket, for the particual search, will be disabled. Use 0 to disable. * Defaults to 0 max_summary_size = <int> * Size of summary, in bytes, at which point we'll start applying the max_summary_ratio. Use 0 to disable. * Defaults to 0 max_time = <int> * The maximum amount of time, seconds, that a summary search process is allowed to run. Use 0 to disable. * Defaults to 0 indextime_lag = <unsigned int> * The amount of lag time to give indexing to ensure that it has synced any received events to disk. Effectively, * the data that has been received in the past indextime_lag will NOT be summarized. * Do not change this value unless directed by Splunk support. * Defaults to 90 [transactions] maxopentxn = <integer> * Specifies the maximum number of not yet closed transactions to keep in the open pool before starting to evict transactions. * Defaults to maxopenevents = <integer> * Specifies the maximum number of events (which are) part of open transactions before transaction eviction starts happening, using LRU policy. * Defaults to [inputproc] max_fd = <integer> * Maximum number of file descriptors that Splunk will keep open, to capture any trailing data from files that are written to very slowly. * Defaults to 100. time_before_close = <integer> * MOVED. This setting is now configured per-input in inputs.conf. * Specifying this setting in limits.conf is DEPRECATED, but for now will override the setting for all monitor inputs. tailing_proc_speed = <integer> * REMOVED. This setting is no longer used. 185

186 file_tracking_db_threshold_mb = <integer> * this setting controls the trigger point at which the file tracking db (also commonly known as the "fishbucket" or btree) rolls over. A new database is created in its place. Writes are targetted at new db. Reads are first targetted at new db, and we fall back to old db for read failures. Any reads served from old db successfully will be written back into new db. * MIGRATION NOTE: if this setting doesn't exist, the initialization code in splunkd triggers an automatic migration step that reads in the current value for "maxdatasize" under the "_thefishbucket" stanza in indexes.conf and writes this value into etc/system/local/limits.conf. [scheduler] max_searches_perc = <integer> * The maximum number of searches the scheduler can run, as a percentage of the maximum number of concurrent searches, see [search] max_searches_per_cpu for how to set the system wide maximum number of searches. * Defaults to 50. auto_summary_perc = <integer> * The maximum number of concurrent searches to be allocated for auto summarization, as a percentage of the concurrent searches that the scheduler can run. * Auto summary searches include: * Searches which generate the data for the Report Acceleration feature. * Searches which generate the data for Data Model acceleration. * Note: user scheduled searches take precedence over auto summary searches. * Defaults to 50. max_action_results = <integer> * The maximum number of results to load when triggering an alert action. * Defaults to action_execution_threads = <integer> * Number of threads to use to execute alert actions, change this number if your alert actions take a long time to execute. * This number is capped at 10. * Defaults to 2 actions_queue_size = <integer> * The number of alert notifications to queue before the scheduler starts blocking, set to 0 for infinite size. * Defaults to 100 actions_queue_timeout = <integer> * The maximum amount of time, in seconds to block when the action queue size is full. * Defaults to 30 alerts_max_count = <integer> * Maximum number of unexpired alerts information to keep for the alerts manager, when this number is reached Splunk will start discarding the oldest alerts. * Defaults to alerts_expire_period = <integer> * The amount of time between expired alert removal * This period controls how frequently the alerts list is scanned, the only benefit from reducing this is better resolution in the number of alerts fired at the savedsearch level. * Change not recommended. * Defaults to 120. persistance_period = <integer> * The period (in seconds) between scheduler state persistance to disk. The scheduler currently persists the suppression and fired-unexpired alerts to disk. * This is relevant only in search head pooling mode. * Defaults to 30. max_lock_files = <int> * The number of most recent lock files to keep around. * This setting only applies in search head pooling. max_lock_file_ttl = <int> * Time (in seconds) that must pass before reaping a stale lock file. * Only applies in search head pooling. max_per_result_alerts = <int> * Maximum number of alerts to trigger for each saved search instance (or real-time results preview for RT alerts) * Only applies in non-digest mode alerting. Use 0 to disable this limit 186

187 * Defaults to 500 max_per_result_alerts_time = <int> * Maximum number of time to spend triggering alerts for each saved search instance (or real-time results preview for RT alerts) * Only applies in non-digest mode alerting. Use 0 to disable this limit. * Defaults to 300 scheduled_view_timeout = <int>[s m h d] * The maximum amount of time that a scheduled view (pdf delivery) would be allowed to render * Defaults to 60m shp_dispatch_to_slave = <bool> * by default the scheduler should distribute jobs throughout the pool. * Defaults to true [auto_summarizer] cache_timeout = <integer> * The amount of time, in seconds, to cache auto summary details and search hash codes * Defaults to minutes search_2_hash_cache_timeout = <integer> * The amount of time, in seconds, to cache search hash codes * Defaults to the value of cache_timeout i.e minutes maintenance_period = <integer> * The period of time, in seconds, that the auto summarization maintenance happens * Defaults to 1800 (30 minutes) allow_event_summarization = <bool> * Whether auto summarization of searches whose remote part returns events rather than results will be allowed. * Defaults to false max_verify_buckets = <int> * When verifying buckets, stop after verifying this many buckets if no failures have been found * 0 means never * Defaults to 100 max_verify_ratio = <number> * Maximum fraction of data in each bucket to verify * Defaults to 0.1 (10%) max_verify_bucket_time = <int> * Maximum time to spend verifying each bucket, in seconds * Defaults to 15 (seconds) verify_delete = <bool> * Should summaries that fail verification be automatically deleted? * Defaults to false max_verify_total_time = <int> * Maximum total time in seconds to spend doing verification, regardless if any buckets have failed or not * Defaults to 0 (no limit) max_run_stats = <int> * Maximum number of summarization run statistics to keep track and expose via REST. * Defaults to 48 return_actions_with_normalized_ids = [yes no fromcontext] * Report acceleration summaries are stored under a signature/hash which can be regular or normalized. * Normalization improves the re-use of pre-built summaries but is not supported before 5.0. This config * will determine the default value of how normalization works (regular/normalized) * Default value is "fromcontext", which would mean the end points and summaries would be operating based on context. * normalization strategy can also be changed via admin/summarization REST calls with the "use_normalization" * parameter which can take the values "yes"/"no"/"fromcontext" normalized_summaries = <bool> * Turn on/off normalization of report acceleration summaries. * Default = false and will become true in 6.0 detailed_dashboard = <bool> * Turn on/off the display of both normalized and regular summaries in the Report 187

188 * acceleration summary dashboard and details. * Default = false shc_accurate_access_counts = <bool> * Only relevant if you are using search head clustering * Turn on/off to make acceleration summary access counts accurate on the captain. * by centralizing the access requests on the captain. * Default = false [show_source] max_count = <integer> * Maximum number of events accessible by show_source. * The show source command will fail when more than this many events are in the same second as the requested event. * Defaults to max_timebefore = <timespan> * Maximum time before requested event to show. * Defaults to '1day' (86400 seconds) max_timeafter = <timespan> * Maximum time after requested event to show. * Defaults to '1day' (86400 seconds) distributed = <bool> * Controls whether we will do a distributed search for show source to get events from all servers and indexes * Turning this off results in better performance for show source, but events will only come from the initial server and index * NOTE: event signing and verification is not supported in distributed mode * Defaults to true distributed_search_limit = <unsigned int> * Sets a limit on the maximum events we will request when doing the search for distributed show source * As this is used for a larger search than the initial non-distributed show source, it is larger than max_count * Splunk will rarely return anywhere near this amount of results, as we will prune the excess results * The point is to ensure the distributed search captures the target event in an environment with many events * Defaults to [typeahead] maxcount = <integer> * Maximum number of typeahead results to find. * Defaults to 1000 use_cache = [0 1] * Specifies whether the typeahead cache will be used if use_cache is not specified in the command line or endpoint. * Defaults to true. fetch_multiplier = <integer> * A multiplying factor that determines the number of terms to fetch from the index, fetch = fetch_multiplier x count. * Defaults to 50 cache_ttl_sec = <integer> * How long the typeahead cached results are valid, in seconds. * Defaults to 300. min_prefix_length = <integer> * The minimum string prefix after which to provide typeahead. * Defaults to 1. max_concurrent_per_user = <integer> * The maximum number of concurrent typeahead searches per user. Once this maximum is reached only cached * typeahead results might be available * Defaults to 3. [typer] maxlen = <int> * In eventtyping, pay attention to first <int> characters of any attribute (such as _raw), including individual tokens. Can be overridden by supplying the typer operator with the argument maxlen (for example, " typer maxlen=300"). * Defaults to [authtokens] 188

189 expiration_time = <integer> * Expiration time of auth tokens in seconds. * Defaults to 3600 [sample] maxsamples = <integer> * Defaults to maxtotalsamples = <integer> * Defaults to [metadata] maxresultrows = <integer> * the maximum number of results in a single chunk fetched by the metadata command * a smaller value will require less memory on the search head in setups with large number of peers and many metadata results, though, setting this too small will decrease the search performance * default is * do not change unless instructed to do so by Splunk Support maxcount = <integer> * the total number of metadata search results returned by the search head; after the maxcount is reached, any addtional metadata results received from the search peers will be ignored (not returned) * a larger number incurs additional memory usage on the search head * default is [set] maxresultrows = <integer> * the maximum number of results the set command will use from each resultset to compute the required set operation [input_channels] max_inactive = <integer> * internal setting, do not change unless instructed to do so by Splunk Support lowater_inactive = <integer> * internal setting, do not change unless instructed to do so by Splunk Support inactive_eligibility_age_seconds = <integer> * internal setting, do not change unless instructed to do so by Splunk Support [ldap] max_users_to_precache = <unsigned integer> * The maximum number of users we will attempt to precache from LDAP after reloading auth * Set this to 0 to turn off precaching allow_multiple_matching_users = <bool> * This controls whether we allow login when we find multiple entries with the same value for the username attribute * When multiple entries are found, we choose the first user DN lexicographically * Setting this to false is more secure as it does not allow any ambiguous login, but users with duplicate entries will not be able to login. * Defaults to true [spath] extraction_cutoff = <integer> * For extract-all spath extraction mode, only apply extraction to the first <integer> number of bytes * Defaults to 5000 extract_all = <boolean> * Controls whether we respect automatic field extraction when spath is invoked manually. * If true, we extract all fields regardless of settings. If false, we only extract fields used by later splunk commands. [reversedns] rdnsmaxdutycycle = <integer> * generate diagnostic WARN in splunkd.log if reverse dns lookups are taking * more than this percent of time * range * default 10 [viewstates] 189

190 enable_reaper = <boolean> * Controls whether the viewstate reaper runs * Defaults to true reaper_freq = <integer> * Controls how often the viewstate reaper runs * Defaults to (1 day) reaper_soft_warn_level = <integer> * Controls what the reaper considers an acceptable number of viewstates * Defaults to 1000 ttl = <integer> * Controls the age at which a viewstate is considered eligible for reaping * Defaults to (1 day) [geostats] maxzoomlevel = <integer> * contols the number of zoom levels that geostats will cluster events on zl_0_gridcell_latspan = <float> * contols what is the grid spacing in terms of latitude degrees at the lowest zoom level, which is zoom-level 0 * grid-spacing at other zoom levels are auto created from this value by reducing by a factor of 2 at each zoomlevel. zl_0_gridcell_longspan = <float> * contols what is the grid spacing in terms of longitude degrees at the lowest zoom level, which is zoom-level 0 * grid-spacing at other zoom levels are auto created from this value by reducing by a factor of 2 at each zoomlevel. filterstrategy = <integer> * controls the selection strategy on the geoviz map. Allowed values are 1 and 2 [iplocation] db_path = <path> * Location of GeoIP database in MMDB format * If not set, defaults to database included with splunk [tscollect] squashcase = <boolean> * The default value of the 'squashcase' argument if not specified by the command * Defaults to false keepresults = <boolean> * The default value of the 'keepresults' argument if not specified by the command * Defaults to false optimize_max_size_mb = <unsigned int> * The maximum size in megabytes of files to create with optimize * Specify 0 for no limit (may create very large tsidx files) * Defaults to 1024 [tstats] apply_search_filter = <boolean> * Controls whether we apply role-based search filters when users run tstats on normal index data * Note: we never apply search filters to data collected with tscollect or datamodel acceleration * Defaults to true summariesonly = <boolean> * The default value of 'summariesonly' arg if not specified by the command * When running tstats on an accelerated datamodel, summariesonly=false implies a mixed mode where we will fall back to search for missing TSIDX data * summariesonly=true overrides this mixed mode to only generate results from TSIDX data, which may be incomplete * Defaults to false allow_old_summaries = <boolean> * The default value of 'allow_old_summaries' arg if not specified by the command * When running tstats on an accelerated datamodel, allow_old_summaries=false ensures we check that the datamodel search in each bucket's summary metadata is considered up to date with the current datamodel search. Only summaries 190

191 that are considered up to date will be used to deliver results. * allow_old_summaries=true overrides this behavior and will deliver results even from bucket summaries that are considered out of date with the current datamodel. * Defaults to false chunk_size = <unsigned int> * ADVANCED: The default value of 'chunk_size' arg if not specified by the command * This argument controls how many events are retrieved at a time within a single TSIDX file when answering queries * Consider lowering this value if tstats queries are using too much memory (cannot be set lower than 10000) * Larger values will tend to cause more memory to be used (per search) and might have performance benefits. * Smaller values will tend to reduce performance and might reduce memory used (per search). * Altering this value without careful measurement is not advised. * Defaults to [pdf] max_rows_per_table = <unsigned int> * The maximum number of rows that will be rendered for a table within integrated PDF rendering * Defaults to 1000 render_endpoint_timeout = <unsigned int> * The number of seconds after which the pdfgen render endpoint will timeout if it has not yet finished rendering the PDF output * Defaults to 3600 [kvstore] max_accelerations_per_collection = <unsigned int> * The maximum number of accelerations that can be assigned to a single collection * Valid values range from 0 to 50 * Defaults to 10 max_fields_per_acceleration = <unsigned int> * The maximum number of fields that can be part of a compound acceleration (i.e. an acceleration with multiple keys) * Valid values range from 0 to 50 * Defaults to 10 max_rows_per_query = <unsigned int> * The maximum number of rows that will be returned for a single query to a collection. * If the query returns more rows than the specified value, then returned result set will contain the number of rows specified in this value. * Defaults to max_queries_per_batch = <unsigned int> * The maximum number of queries that can be run in a single batch * Defaults to 1000 max_size_per_result_mb = <unsigned int> * The maximum size of the result that will be returned for a single query to a collection in MB. * Defaults to 50 MB max_size_per_batch_save_mb = <unsigned int> * The maximum size of a batch save query in MB * Defaults to 50 MB max_documents_per_batch_save = <unsigned int> * The maximum number of documents that can be saved in a single batch * Defaults to 1000 max_size_per_batch_result_mb = <unsigned int> * The maximum size of the result set from a set of batched queries * Defaults to 100 MB limits.conf.example Version CAUTION: Do not alter the settings in limits.conf unless you know what you are doing. Improperly configured limits may result in splunkd crashes and/or memory overuse. [searchresults] maxresultrows =

192 maximum number of times to try in the atomic write operation (1 = no retries) tocsv_maxretry = 5 retry period is 1/2 second (500 milliseconds) tocsv_retryperiod_ms = 500 [subsearch] maximum number of results to return from a subsearch maxout = 100 maximum number of seconds to run a subsearch before finalizing maxtime = 10 time to cache a given subsearch's results ttl = 300 [anomalousvalue] maxresultrows = maximum number of distinct values for a field maxvalues = maximum size in bytes of any single value (truncated to this size if larger) maxvaluesize = 1000 [associate] maxfields = maxvalues = maxvaluesize = 1000 for the contingency, ctable, and counttable commands [ctable] maxvalues = 1000 [correlate] maxfields = 1000 for bin/bucket/discretize [discretize] maxbins = if maxbins not specified or = 0, defaults to searchresults::maxresultrows [inputcsv] maximum number of retries for creating a tmp directory (with random name in SPLUNK_HOME/var/run/splunk) mkdir_max_retries = 100 [kmeans] maxdatapoints = [kv] when non-zero, the point at which kv should stop creating new columns maxcols = 512 [rare] maxresultrows = maximum distinct value vectors to keep track of maxvalues = maxvaluesize = 1000 [restapi] maximum result rows to be returned by /events or /results getters from REST API maxresultrows = [search] how long searches should be stored on disk once completed ttl = the approximate maximum number of timeline buckets to maintain status_buckets = 300 the last accessible event in a call that takes a base and bounds max_count = the minimum length of a prefix before a * to ask the index about min_prefix_len = 1 the length of time to persist search cache entries (in seconds) 192

193 cache_ttl = 300 [slc] maximum number of clusters to create maxclusters = [findkeywords] events to use in findkeywords command (and patterns UI) maxevents = [stats] maxresultrows = maxvalues = maxvaluesize = 1000 [top] maxresultrows = maximum distinct value vectors to keep track of maxvalues = maxvaluesize = 1000 literals.conf 다음은 literals.conf의 사양 및 예제 파일입니다. literals.conf.spec Version This file contains attribute/value pairs for configuring externalized strings in literals.conf. There is a literals.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a literals.conf in $SPLUNK_HOME/etc/system/local/. For examples, see literals.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at For the full list of all literals that can be overridden, check out $SPLUNK_HOME/etc/system/default/literals.conf. CAUTION: - You can destroy Splunk's performance by editing literals.conf incorrectly. - Only edit the attribute values (on the right-hand side of the '='). DO NOT edit the attribute names (left-hand side of the '='). - When strings contain "%s", do not add or remove any occurrences of %s, or reorder their positions. - When strings contain HTML tags, take special care to make sure that all tags and quoted attributes are properly closed, and that all entities such as & are escaped. literals.conf.example Version This file contains an example literals.conf, which is used to 193

194 configure the externalized strings in Splunk. For the full list of all literals that can be overwritten, consult the far longer list in $SPLUNK_HOME/etc/system/default/literals.conf [ui] PRO_SERVER_LOGIN_HEADER = Login to Splunk (guest/guest) INSUFFICIENT_DISK_SPACE_ERROR = The server's free disk space is too low. Indexing will temporarily pause until more disk space becomes available. SERVER_RESTART_MESSAGE = This Splunk Server's configuration has been changed. The server needs to be restarted by an administrator. UNABLE_TO_CONNECT_MESSAGE = Could not connect to splunkd at %s. macros.conf 다음은 macros.conf의 사양 및 예제 파일입니다. macros.conf.spec Version This file contains possible attribute/value pairs for search language macros. To learn more about configuration files (including precedence) please see the documentation located at [<STANZA_NAME>] * Each stanza represents a search macro that can be referenced in any search. * The stanza name is the name of the macro if the macro takes no arguments. Otherwise, the stanza name is the macro name appended with "(<numargs>)", where <numargs> is the number of arguments that this macro takes. * Macros can be overloaded. In other words, they can have the same name but a different number of arguments. If you have [foobar], [foobar(1)], [foobar(2)], etc., they are not the same macro. * Macros can be used in the search language by enclosing the macro name and any argument list within tick marks, for example:`foobar(arg1,arg2)` or `footer`. * Splunk does not expand macros when they are inside of quoted values, for example: "foo`bar`baz". args = <string>,<string>,... * A comma-delimited string of argument names. * Argument names can only contain alphanumeric characters, underscores '_', and hyphens '-'. * If the stanza name indicates that this macro takes no arguments, this attribute will be ignored. * This list cannot contain any repeated elements. definition = <string> * The string that the macro will expand to, with the argument substitutions made. (The exception is when iseval = true, see below.) * Arguments to be substituted must be wrapped by dollar signs ($), for example: "the last part of this string will be replaced by the value of argument foo $foo$". * Splunk replaces the $<arg>$ pattern globally in the string, even inside of quotes. validation = <string> * A validation string that is an 'eval' expression. This expression must evaluate to a boolean or a string. * Use this to verify that the macro's argument values are acceptable. * If the validation expression is boolean, validation succeeds when it returns true. If it returns false or is NULL, validation fails, and Splunk returns the error message defined by the attribute, errormsg. * If the validation expression is not boolean, Splunk expects it to return a string or NULL. If it returns NULL, validation is considered a success. Otherwise, the string returned is the error string. errormsg = <string> * The error message to be displayed if validation is a boolean expression and it does not evaluate to true. 194

195 iseval = <true/false> * If true, the definition attribute is expected to be an eval expression that returns a string that represents the expansion of this macro. * Defaults to false. description = <string> * OPTIONAL. Simple english description of what the macro does. macros.conf.example Version Example macros.conf macro foobar that takes no arguments can be invoked via `foobar` [foobar] the defintion of a macro can invoke another macro. nesting can be indefinite and cycles will be detected and result in an error definition = `foobar(foo=defaultfoo)` macro foobar that takes one argument, invoked via `foobar(someval)` [foobar(1)] args = foo note this is definition will include the leading and trailing quotes, i.e. something `foobar(someval)` would expand to something "foo = someval" definition = "foo = $foo$" macro that takes two arguments note that macro arguments can be named so this particular macro could be invoked equivalently as `foobar(1,2)` `foobar(foo=1,bar=2)` or `foobar(bar=2,foo=1)` [foobar(2)] args = foo, bar definition = "foo = $foo$, bar = $bar$" macro that takes one argument that does validation [foovalid(1)] args = foo definition = "foovalid = $foo$" the validation eval function takes any even number of arguments (>=2) where the first argument is a boolean expression, the 2nd a string, the third boolean, 4th a string, etc etc etc validation = validate(foo>15,"foo must be greater than 15",foo<=100,"foo must be <= 100") macro showing simple boolean validation, where if foo > bar is not true, errormsg is displayed [foovalid(2)] args = foo, bar definition = "foo = $foo$ and bar = $bar$" validation = foo > bar errormsg = foo must be greater than bar example of an eval-based definition. For example in this case `fooeval(10,20)` would get replaced by [fooeval(2)] args = foo, bar definition = if (bar > 0, "$foo$ + $bar$", "$foo$ - $bar$") iseval = true multikv.conf 다음은 multikv.conf의 사양 및 예제 파일입니다. multikv.conf.spec Version

196 This file contains possible attribute and value pairs for creating multikv rules. Multikv is the process of extracting events from table-like events, such as the output of top, ps, ls, netstat, etc. There is NO DEFAULT multikv.conf. To set custom configurations, place a multikv.conf in $SPLUNK_HOME/etc/system/local/. For examples, see multikv.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) see the documentation located at NOTE: Only configure multikv.conf if Splunk's default multikv behavior does not meet your needs. A table-like event includes a table consisting of four sections: Section Name Description pre optional: info/description (for example: the system summary output in top) header optional: if not defined, fields are named Column_N body required: the body of the table from which child events are constructed post optional: info/description NOTE: Each section must have a definition and a processing component. See below. [<multikv_config_name>] * Name of the stanza to use with the multikv search command, for example: '... multikv conf=<multikv_config_name> rmorig=f...' * Follow this stanza name with any number of the following attribute/value pairs. Section Definition Define where each section begins and ends. <Section Name>.start = <regex> * A line matching this regex denotes the start of this section (inclusive). OR <Section Name>.start_offset = <int> * Line offset from the start of an event or the end of the previous section (inclusive). * Use this if you cannot define a regex for the start of the section. <Section Name>.member = <regex> * A line membership test. * Member if lines match the regex. <Section Name>.end = <regex> * A line matching this regex denotes the end of this section (exclusive). OR <Section Name>.linecount = <int> * Specify the number of lines in this section. * Use this if you cannot specify a regex for the end of the section. Section processing Set processing for each section. <Section Name>.ignore = [_all_ _none_ _regex_ <regex-list>] * Determines which member lines will be ignored and not processed further. <Section Name>.replace = <quoted-str> = <quoted-str>, <quoted-str> = <quoted-str>,... * List of the form: "toreplace" = "replacewith". * Can have any number of quoted string pairs. * For example: "%" = "_", "" = "_" 196

197 <Section Name>.tokens = [<chopper> <tokenizer> <aligner> <token-list>] * See below for definitions of each possible token: chopper, tokenizer, aligner, token-list. <chopper> = _chop_, <int-list> * Transform each string into a list of tokens specified by <int-list>. * <int-list> is a list of (offset, length) tuples. <tokenizer> = _tokenize_ <max_tokens (int)> <delims> (<consume-delims>)? * Tokenize the string using the delim characters. * This generates at most max_tokens number of tokens. * Set max_tokens to: * -1 for complete tokenization. * 0 to inherit from previous section (usually header). * A non-zero number for a specific token count. * If tokenization is limited by the max_tokens, the rest of the string is added onto the last token. * <delims> is a comma-separated list of delimiting chars. * <consume-delims> - boolean, whether to consume consecutive delimiters. Set to false/0 if you want * consecutive delimiters to be treated as empty values. Defaults to true. <aligner> = _align_, <header_string>, <side>, <max_width> * Generates tokens by extracting text aligned to the specified header fields. * header_string: a complete or partial header field value the columns are aligned with. * side: either L or R (for left or right align, respectively). * max_width: the maximum width of the extracted field. * Set max_width to -1 for automatic width. This expands the field until any of the following delimiters are found: " ", "\t" <token_list> = _token_list_ <comma-separated list> * Defines a list of static tokens in a section. * This is useful for tables with no header, for example: the output of 'ls -lah' which misses a header altogether. multikv.conf.example Version This file contains example multi key/value extraction configurations. To use one or more of these configurations, copy the configuration block into multikv.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at This example breaks up the output from top: Sample output: Processes: 56 total, 2 running, 54 sleeping threads 10:14:07... PID COMMAND %CPU TIME TH PRTS MREGS RPRVT RSHRD RSIZE VSIZE mdimport 0.0% 0: M 2.55M 3.54M 38.7M pickup 0.0% 0: K 832K 764K 26.7M... [top_mkv] pre table starts at "Process..." and ends at line containing "PID" pre.start = "Process" pre.end = "PID" pre.ignore = _all_ specify table header location and processing header.start = "PID" header.linecount = 1 197

198 header.replace = "%" = "_", "" = "_" header.tokens = _tokenize_, -1," " table body ends at the next "Process" line (ie start of another top) tokenize and inherit the number of tokens from previous section (header) body.end = "Process" body.tokens = _tokenize_, 0, " " This example handles the output of 'ls -lah' command: total drwxr-xr-x 88 john john 2K Jan 30 07:56. drwxr-xr-x 15 john john 510B Jan 30 07:49.. -rw john john 2K Jan 28 11:25.hiden_file drwxr-xr-x 20 john john 680B Jan 30 07:49 my_dir -r--r--r-- 1 john john 3K Jan 11 09:00 my_file.txt [ls-lah-cpp] pre.start = "total" pre.linecount = 1 the header is missing, so list the column names header.tokens = _token_list_, mode, links, user, group, size, date, name The ends when we have a line starting with a space body.end = "^\s*$" This filters so that only lines that contain with.cpp are used body.member = "\.cpp" concatenates the date into a single unbreakable item body.replace = "(\w{3})\s+(\d{1,2})\s+(\d{2}:\d{2})" ="\1_\2_\3" ignore dirs body.ignore = _regex_ "^drwx.*", body.tokens = _tokenize_, 0, " " outputs.conf 다음은 outputs.conf의 사양 및 예제 파일입니다. outputs.conf.spec Version Forwarders require outputs.conf; non-forwarding Splunk instances do not use it. It determines how the forwarder sends data to receiving Splunk instances, either indexers or other forwarders. To configure forwarding, create an outputs.conf file in $SPLUNK_HOME/etc/system/local/. For examples of its use, see outputs.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at NOTE: To learn more about forwarding, see the documentation at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. 198

199 TCP Output stanzas There are three levels of TCP Output stanzas: * Global: [tcpout] * Target group: [tcpout:<target_group>] * Single server: [tcpout-server://<ip address>:<port>] Settings at more specific levels override settings at higher levels. For example, an attribute set for a single server overrides the value of that attribute, if any, set at that server's target group stanza. See the online documentation on configuring forwarders for details. This spec file first describes the three levels of stanzas (and any attributes unique to a particular level). It then describes the optional attributes, which can be set at any of the three levels. ----TCP Output Global Configuration The global configurations specified here in the [tcpout] stanza can be overwritten in stanzas for specific target groups, as described later. Note that the defaultgroup and indexandforward attributes can only be set here, at the global level. Starting with 4.2, the [tcpout] stanza is no longer required. [tcpout] defaultgroup = <target_group>, <target_group>,... * Comma-separated list of one or more target group names, specified later in [tcpout:<target_group>] stanzas. * The forwarder sends all data to the specified groups. * If you don't want to forward data automatically, don't set this attribute. * Can be overridden by an inputs.conf _TCP_ROUTING setting, which in turn can be overridden by a props.conf/transforms.conf modifier. * Starting with 4.2, this attribute is no longer required. indexandforward = [true false] * Index all data locally, in addition to forwarding it. * This is known as an "index-and-forward" configuration. * This attribute is only available for heavy forwarders. * This attribute is available only at the top level [tcpout] stanza. It cannot be overridden in a target group. * Defaults to false. ----Target Group Configuration If multiple servers are specified in a target group, the forwarder performs auto load-balancing, sending data alternately to each available server in the group. For example, assuming you have three servers (server1, server2, server3) and autolbfrequency=30, the forwarder sends all data to server1 for 30 seconds, then it sends all data to server2 for the next 30 seconds, then all data to server3 for the next 30 seconds, finally cycling back to server1. You can have as many target groups as you want. If more than one target group is specified, the forwarder sends all data to each target group. This is known as "cloning" the data. [tcpout:<target_group>] server = [<ip> <servername>]:<port>, [<ip> <servername>]:<port>,... * Required. * Takes a comma separated list of one or more systems to send data to over a tcp socket. * Typically used to specify receiving splunk systems, although it can be used to send data to non-splunk systems (see sendcookeddata setting). * For each mentioned system, the following are required: * IP or servername where one or system is listening. * Port on which syslog server is listening. blockwarnthreshold = <integer> * Optional * Default value is 100 * Sets the output pipleline send failure count threshold after which a failure message will be displayed as banner on UI * To disable any warnings to be sent to UI on blocked output queue condition, set this 199

200 to a large value (2 million for example) ----Single server configuration You can define specific configurations for individual indexers on a server-by-server basis. However, each server must also be part of a target group. [tcpout-server://<ip address>:<port>] * Optional. There is no requirement to have any tcpout-server stanzas. ----TCPOUT ATTRIBUTES---- These attributes are optional and can appear in any of the three stanza levels. [tcpout<any of above>] ----General Settings---- sendcookeddata = [true false] * If true, events are cooked (have been processed by Splunk). * If false, events are raw and untouched prior to sending. * Set to false if you are sending to a third-party system. * Defaults to true. heartbeatfrequency = <integer> * How often (in seconds) to send a heartbeat packet to the receiving server. * Heartbeats are only sent if sendcookeddata=true. * Defaults to 30 seconds. blockoncloning = [true false] * If true, TcpOutputProcessor blocks till at least one of the cloned group gets events. This will not drop events when all the cloned groups are down. * If false, TcpOutputProcessor will drop events when all the cloned groups are down and queues for the cloned groups are full. When at least one of the cloned groups is up and queues are not full, the events are not dropped. * Defaults to true. compressed = [true false] * Applies to non-ssl forwarding only. For SSL useclientsslcompression setting is used. * If true, forwarder sends compressed data. * If set to true, the receiver port must also have compression turned on (in its inputs.conf file). * Defaults to false. negotiatenewprotocol = [true false] * When setting up a connection to an indexer, try to negotiate the use of the new forwarder protocol. * If set to false, the forwarder will not query the indexer for support for the new protocol, and the connection will fall back on the traditional protocol. * Defaults to true. channelreapinterval = <integer> * Controls how often, in milliseconds, channel codes are reaped, i.e. made available for re-use. * This value sets the minimum time between reapings; in practice, consecutive reapings may be separated by greater than <channelreapinterval> milliseconds. * Defaults to (1 minute) channelttl = <integer> * Controls how long, in milliseconds, a channel may remain "inactive" before it is reaped, i.e. before its code is made available for re-use by a different channel. * Defaults to (5 minutes) channelreaplowater = <integer> * If the number of active channels is above <channelreaplowater>, we reap old channels in order to make their channel codes available for re-use. * If the number of active channels is below <channelreaplowater>, we do not reap channels, no matter how old they are. * This value essentially determines how many active-but-old channels we keep "pinned" in memory on both sides of a splunk-to-splunk connection. * A non-zero value helps ensure that we do not waste network resources by "thrashing" channels in the case of a forwarder sending a trickle of data. * Defaults to

201 ----Queue Settings---- maxqueuesize = [<integer> <integer>[kb MB GB] auto] * This attribute sets the maximum size of the forwarder's output queue. * The size can be limited based on the number of entries, or on the total memory used by the items in the queue. * If specified as a lone integer (for example, maxqueuesize=100), maxqueuesize indicates the maximum count of queued items. * If specified as an integer followed by KB, MB, or GB (for example, maxqueuesize=100mb), maxqueuesize indicates the maximum RAM size of all the items in the queue. * If set to auto, chooses a value depending on whether useack is enabled. * If useack=false, uses 500KB * If useack=true, uses 7MB * If the useack setting is enabled, the maximum size of the wait queue is set to to 3x this value. * Although the wait queue and the output queue sizes are both controlled by this attribute, they are separate. * Limiting the queue sizes by quantity is largely historical. However, should you choose to configure queues based on quantity, keep the following in mind: * Queued items can be events or blocks of data. * Non-parsing forwarders, such as universal forwarders, will send blocks, which may be up to 64KB. * Parsing forwarders, such as heavy forwarders, will send events, which will be the size of the events. For some events these are as small as a few hundred bytes. In unusual cases (data dependent), customers may arrange to produce events that are multiple megabytes. * Defaults to auto * If useack is enabled, effectively defaults the wait queue to 21MB dropeventsonqueuefull = <integer> * If set to a positive number, wait <integer> seconds before throwing out all new events until the output queue has space. * Setting this to -1 or 0 will cause the output queue to block when it gets full, causing further blocking up the processing chain. * If any target group's queue is blocked, no more data will reach any other target group. * Using auto load-balancing is the best way to minimize this condition, because, in that case, multiple receivers must be down (or jammed up) before queue blocking can occur. * Defaults to -1 (do not drop events). * DO NOT SET THIS VALUE TO A POSITIVE INTEGER IF YOU ARE MONITORING FILES! dropclonedeventsonqueuefull = <integer> * If set to a positive number, do not block completely, but wait up to <integer> seconds to queue events to a group. If it cannot enqueue to a group for more than <integer> seconds, begin dropping events for the group. It makes sure that at least one group in the cloning configuration will get events. It blocks if event cannot be delivered to any of the cloned groups. * If set to -1, the TcpOutputProcessor will make sure that each group will get all of the events. If one of the groups is down, then Splunk will block everything. * Defaults to Backoff Settings When Unable To Send Events to Indexer---- The settings in this section determine forwarding behavior when there are repeated failures in sending events to an indexer ("sending failures"). maxfailuresperinterval = <integer> * Specifies the maximum number failures allowed per interval before backoff takes place. The interval is defined below. * Defaults to 2. secsinfailureinterval = <integer> * Number of seconds in an interval. If the number of write failures exceeds maxfailuresperinterval in the specified secsinfailureinterval seconds, the forwarder applies backoff. The backoff time period range is 1-10 * autolbfrequency. * Defaults to 1. backoffonfailure = <positive integer> * Number of seconds a forwarder will wait before attempting another connection attempt. * Defaults to 30 maxconnectionsperindexer = <integer> * Maximum number of allowed connections per indexer. In presence of failures, the max number of connection 201

202 attempt per indexer at any point in time. * Defaults to 2. connectiontimeout = <integer> * Time out period if connection establishment does not finish in <integer> seconds. * Defaults to 20 seconds. readtimeout = <integer> * Time out period if read from socket does not finish in <integer> seconds. * This timeout is used to read acknowledgment when indexer acknowledgment is used (useack=true). * Defaults to 300 seconds. writetimeout = <integer> * Time out period if write on socket does not finish in <integer> seconds. * Defaults to 300 seconds. dnsresolutioninterval = <integer> * Specifies base time interval in seconds at which indexer dns names will be resolved to ip address. This is used to compute runtime dnsresolutioninterval as follows: runtime interval = dnsresolutioninterval + (number of indexers in server settings - 1)*30. DNS resolution interval is extended by 30 second for each additional indexer in server setting. * Defaults to 300 seconds. forcetimebasedautolb = [true false] * Will force existing streams to switch to newly elected indexer every AutoLB cycle. * Defaults to false ----Index Filter Settings. These attributes are only applicable under the global [tcpout] stanza. This filter does not work if it is created under any other stanza. forwardedindex.<n>.whitelist = <regex> forwardedindex.<n>.blacklist = <regex> * These filters determine which events get forwarded, based on the indexes they belong to. * This is an ordered list of whitelists and blacklists, which together decide if events should be forwarded to an index. * The order is determined by <n>. <n> must start at 0 and continue with positive integers, in sequence. There cannot be any gaps in the sequence. (For example, forwardedindex.0.whitelist, forwardedindex.1.blacklist, forwardedindex.2.whitelist,...). * The filters can start from either whitelist or blacklist. They are tested from forwardedindex.0 to forwardedindex.<max>. * If both forwardedindex.<n>.whitelist and forwardedindex.<n>.blacklist are present for the same value of n, then forwardedindex.<n>.whitelist is honored. forwardedindex.<n>.blacklist is ignored in this case. * You should not normally need to change these filters from their default settings in $SPLUNK_HOME/system/default/outputs.conf. * Filtered out events are not indexed if local indexing is not enabled. forwardedindex.filter.disable = [true false] * If true, disables index filtering. Events for all indexes are then forwarded. * Defaults to false. ----Automatic Load-Balancing autolb = true * Automatic load balancing is the only way to forward data. Round-robin method is not supported anymore. * Defaults to true. autolbfrequency = <seconds> * Every autolbfrequency seconds, a new indexer is selected randomly from the list of indexers provided in the server attribute of the target group stanza. * Defaults to 30 (seconds). ----SSL Settings---- To set up SSL on the forwarder, set the following attribute/value pairs. If you want to use SSL for authentication, add a stanza for each receiver that must be certified. sslpassword = <password> * The password associated with the CAcert. * The default Splunk CAcert uses the password "password". * There is no default value. 202

203 sslcertpath = <path> * If specified, this connection will use SSL. * This is the path to the client certificate. * There is no default value. ecdhcurvename = <string> * ECDH curve to use for ECDH key negotiation * We only support named curves specified by their SHORT name. * (see struct ASN1_OBJECT in asn1.h) * The list of valid named curves by their short/long names * can be obtained by executing this command: * $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves * Default is empty string. sslrootcapath = <path> * The path to the root certificate authority file (optional). * There is no default value. sslverifyservercert = [true false] * If true, you must make sure that the server you are connecting to is a valid one (authenticated). * Both the common name and the alternate name of the server are then checked for a match. * Defaults to false. sslcommonnametocheck = <string> * Check the common name of the server's certificate against this name. * If there is no match, assume that Splunk is not authenticated against this server. * You must specify this setting if sslverifyservercert is true. sslaltnametocheck = <string> * Check the alternate name of the server's certificate against this name. * If there is no match, assume that Splunk is not authenticated against this server. * You must specify this setting if sslverifyservercert is true. useclientsslcompression = [true false] * Enables compression on SSL. * Defaults to value of useclientsslcompression from [sslconfig] stanza in server.conf. sslquietshutdown = [true false] * Enables quiet shutdown mode in SSL * Defaults to false ----Indexer Acknowledgment ---- Indexer acknowledgment ensures that forwarded data is reliably delivered to the receiver. If the receiver is an indexer, it indicates that the indexer has received the data, indexed it, and written it to the file system. If the receiver is an intermediate forwarder, it indicates that the intermediate forwarder has successfully forwarded the data to the terminating indexer and has received acknowledgment from that indexer. Important: Indexer acknowledgment is a complex feature that requires careful planning. Before using it, read the online topic describing it in the Distributed Deployment manual. useack = [true false] * When set to true, the forwarder will retain a copy of each sent event, until the receiving system sends an acknowledgement. * The receiver will send an acknowledgement when it has fully handled it (typically written it to disk in indexing) * In the event of receiver misbehavior (acknowledgement is not received), the data will be re-sent to an alternate receiver. * Note: the maximum memory used for the outbound data queues will increase significantly by default (500KB -> 28MB) when useack is enabled. This is intended for correctness and performance. * When set to false, the forwarder will consider the data fully processed when it finishes writing it to the network socket. * This attribute can be set at the [tcpout] or [tcpout:<target_group>] stanza levels. You cannot set it for individual servers at the [tcpout-server:...] stanza level. * Defaults to false. ----Syslog output---- The syslog output processor is not available for universal or light forwarders. 203

204 The following configuration is used to send output using syslog: [syslog] defaultgroup = <target_group>, <target_group>,... [syslog:<target_group>] ----REQUIRED SETTINGS---- Required settings for a syslog output group: server = [<ip> <servername>]:<port> * IP or servername where syslog server is running. * Port on which server is listening. You must specify the port. Syslog, by default, uses OPTIONAL SETTINGS---- Optional settings for syslog output: type = [tcp udp] * Protocol used. * Default is udp. priority = <priority_value> NO_PRI * The priority_value should specified as "<integer>" (an integer surrounded by angle brackets). For example, specify a priority of 34 like this: <34> * The integer must be one to three digits in length. * The value you enter will appear in the syslog header. * Mimics the number passed via syslog interface call, documented via man syslog. * The integer can be computed as (<facility> * 8) + <severity>. For example, if <facility> is 4 (security/authorization messages) and <severity> is 2 (critical conditions), the priority will be 34 = (4 * 8) + 2. Set the attribute to: <34> * The table of facility and severity (and their values) can be referenced in RFC3164, eg section * Defaults to <13>, or a facility of "user" or typically unspecified application, and severity of "Notice". * If you do not wish to add priority, set 'NO_PRI' as priority value. * Example: priority = NO_PRI * The table is reproduced briefly here, some of these are archaic. Facility: 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) Severity: 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages 204

205 syslogsourcetype = <string> * Specifies an additional rule for handling data, in addition to that provided by the 'syslog' source type. * This string is used as a substring match against the sourcetype key. For example, if the string is set to 'syslog', then all source types containing the string 'syslog' will receive this special treatment. * To match a source type explicitly, use the pattern "sourcetype::sourcetype_name". * Example: syslogsourcetype = sourcetype::apache_common * Data which is 'syslog' or matches this setting is assumed to already be in syslog format. * Data which does not match the rules has a header, potentially a timestamp, and a hostname added to the front of the event. This is how Splunk causes arbitrary log data to match syslog expectations. * Defaults to unset. timestampformat = <format> * If specified, the formatted timestamps are added to the start of events forwarded to syslog. * As above, this logic is only applied when the data is not syslog, or the syslogsourcetype. * The format is a strftime-style timestamp formatting string. This is the same implementation used in the 'eval' search command, splunk logging, and other places in splunkd. * For example: %b %e %H:%M:%S * %b - Abbreviated month name (Jan, Feb,...) * %e - Day of month * %H - Hour * %M - Minute * %s - Second * For a more exhaustive list of the formatting specifiers, refer to the online documentation. * Note that the string is not quoted. * Defaults to unset, which means that no timestamp will be inserted into the front of events. dropeventsonqueuefull = <integer> * If set to a positive number, wait <integer> seconds before throwing out all new events until the output queue has space. * Setting this to -1 or 0 will cause the output queue to block when it gets full, causing further blocking up the processing chain. * If any target group's queue is blocked, no more data will reach any other target group. * Defaults to -1 (do not drop events). maxeventsize = <integer> * If specified, sets the maximum size of an event that splunk will transmit. * All events excedding this size will be truncated. * Defaults to 1024 bytes Routing Data to Syslog Server To route data to syslog server: 1) Decide which events to route to which servers. 2) Edit the props.conf, transforms.conf, and outputs.conf files on the forwarders. Edit $SPLUNK_HOME/etc/system/local/props.conf and set a TRANSFORMS-routing attribute as shown here: [<spec>] TRANSFORMS-routing=<unique_stanza_name> * <spec> can be: * <sourcetype>, the source type of an event * host::<host>, where <host> is the host for an event * source::<source>, where <source> is the source for an event * Use the <unique_stanza_name> when creating your entry in transforms.conf. Edit $SPLUNK_HOME/etc/system/local/transforms.conf and set rules to match your props.conf stanza: [<unique_stanza_name>] REGEX=<your_regex> DEST_KEY=_SYSLOG_ROUTING FORMAT=<unique_group_name> * <unique_stanza_name> must match the name you created in props.conf. * Enter the regex rules in <your_regex> to determine which events get conditionally routed. * DEST_KEY should be set to _SYSLOG_ROUTING to send events via SYSLOG. * Set FORMAT to <unique_group_name>. This should match the syslog group name you create in outputs.conf. 205

206 ----IndexAndForward Processor----- The IndexAndForward processor determines the default behavior for indexing data on full Splunk. It has the "index" property, which determines whether indexing occurs. When Splunk is not configured as a forwarder, "index" is set to "true". That is, the Splunk instance indexes data by default. When Splunk is configured as a forwarder, the processor turns "index" to "false". That is, the Splunk instance does not index data by default. The IndexAndForward processor has no effect on the universal forwarder, which can never index data. If the [tcpout] stanza configures the indexandforward attribute, the value of that attribute overrides the default value of "index". However, if you set "index" in the [indexandforward] stanza, described below, it supersedes any value set in [tcpout]. [indexandforward] index = [true false] * If set to true, data is indexed. * If set to false, data is not indexed. * Default depends on whether the Splunk instance is configured as a forwarder, modified by any value configured for the indexandforward attribute in [tcpout]. selectiveindexing = [true false] * When index is 'true', all events are indexed. Setting selectiveindexing to 'true' allows you to index only specific events that has key '_INDEX_AND_FORWARD_ROUTING' set. * '_INDEX_AND_FORWARD_ROUTING' can be set in inputs.conf as: [<input_stanza>] _INDEX_AND_FORWARD_ROUTING = local * Defaults to false. outputs.conf.example Version This file contains an example outputs.conf. Use this file to configure forwarding in a distributed set up. To use one or more of these configurations, copy the configuration block into outputs.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Specify a target group for an IP:PORT which consists of a single receiver. This is the simplest possible configuration; it sends data to the host at on port [tcpout:group1] server= :9997 Specify a target group for a hostname which consists of a single receiver. [tcpout:group2] server=myhost.splunk.com:9997 Specify a target group made up of two receivers. In this case, the data will be distributed using AutoLB between these two receivers. You can specify as many receivers as you wish here. You can combine host name and IP if you wish. 206

207 NOTE: Do not use this configuration with SplunkLightForwarder. [tcpout:group3] server=myhost.splunk.com:9997, :6666 You can override any of the global configuration values on a per-target group basis. All target groups that do not override a global config will inherit the global config. Send every event to a receiver at foo.splunk.com:9997 with a maximum queue size of 100,500 events. [tcpout:group4] server=foo.splunk.com:9997 heartbeatfrequency=45 maxqueuesize= Clone events to groups indexer1 and indexer2. Also, index all this data locally as well. [tcpout] indexandforward=true [tcpout:indexer1] server=y.y.y.y:9997 [tcpout:indexer2] server=x.x.x.x:6666 Clone events between two data balanced groups. [tcpout:indexer1] server=a.a.a.a:1111, B.B.B.B:2222 [tcpout:indexer2] server=c.c.c.c:3333, D.D.D.D:4444 Syslout output configuration This example sends only events generated by the splunk daemon to a remote syslog host: [syslog:syslog-out1] disabled = false server = X.X.X.X:9099 type = tcp priority = <34> timestampformat = %b %e %H:%M:%S New in 4.0: Auto Load Balancing This example balances output between two indexers running on :4433 and :4433. To achieve this you'd create a DNS entry for splunklb pointing to the two IP addresses of your indexers: $ORIGIN example.com. splunklb A splunklb A [tcpout] defaultgroup = lb [tcpout:lb] server = splunklb.example.com:4433 autolb = true Alternatively, you can autolb sans DNS: [tcpout] defaultgroup = lb 207

208 [tcpout:lb] server = :4433, :4433 autolb = true Compression This example sends compressed events to the remote indexer. NOTE: Compression can be enabled TCP or SSL outputs only. The receiver input port should also have compression enabled. [tcpout] server = splunkserver.example.com:4433 compressed = true SSL This example sends events to an indexer via SSL using splunk's self signed cert: [tcpout] server = splunkserver.example.com:4433 sslpassword = password sslcertpath = $SPLUNK_HOME/etc/auth/server.pem sslrootcapath = $SPLUNK_HOME/etc/auth/ca.pem The following example shows how to route events to syslog server This is similar to tcpout routing, but DEST_KEY is set to _SYSLOG_ROUTING 1. Edit $SPLUNK_HOME/etc/system/local/props.conf and set a TRANSFORMS-routing attribute: [default] TRANSFORMS-routing=errorRouting [syslog] TRANSFORMS-routing=syslogRouting 2. Edit $SPLUNK_HOME/etc/system/local/transforms.conf and set errorrouting and syslogrouting rules: [errorrouting] REGEX=error DEST_KEY=_SYSLOG_ROUTING FORMAT=errorGroup [syslogrouting] REGEX=. DEST_KEY=_SYSLOG_ROUTING FORMAT=syslogGroup 3. Edit $SPLUNK_HOME/etc/system/local/outputs.conf and set which syslog outputs go to with servers or groups: [syslog] defaultgroup=everythingelsegroup [syslog:sysloggroup] server = :9997 [syslog:errorgroup] server= :9999 [syslog:everythingelsegroup] server= :6666 Perform selective indexing and forwarding With a heavy forwarder only, you can index and store data locally, as well as forward the data onwards to a receiving indexer. There are two ways to do this: 1. In outputs.conf: [tcpout] defaultgroup = indexers [indexandforward] 208

209 index=true selectiveindexing=true [tcpout:indexers] server = :9997, : In inputs.conf, Add _INDEX_AND_FORWARD_ROUTING for any data that you want index locally, and _TCP_ROUTING=<target_group> for data to be forwarded. [monitor:///var/log/messages/] _INDEX_AND_FORWARD_ROUTING=local [monitor:///var/log/httpd/] _TCP_ROUTING=indexers pdf_server.conf 다음은 pdf_server.conf의 사양 및 예제 파일입니다. pdf_server.conf.spec Version This file contains possible attributes and values you can use to configure Splunk's pdf server. There is a pdf_server.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a pdf_server.conf in $SPLUNK_HOME/etc/system/local/. For examples, see pdf_server.conf.example. You must restart the pdf server to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [settings] * Set general Splunk Web configuration options under this stanza name. * Follow this stanza name with any number of the following attribute/value pairs. * If you do not specify an entry for each attribute, Splunk will use the default value. startwebserver = [0 1] * Set whether or not to start the server. * 0 disables Splunk Web, 1 enables it. * Defaults to 1. httpport = <port_number> * Must be present for the server to start. * If omitted or 0 the server will NOT start an http listener. * If using SSL, set to the HTTPS port number. * Defaults to enablesplunkwebssl = [True False] * Toggle between http or https. * Set to true to enable https and SSL. * Defaults to False. privkeypath = /certs/privkey.pem cacertpath = /certs/cert.pem * Specify paths and names for Web SSL certs. * Path is relative to $SPLUNK_HOME/share/splunk. supportsslv3only = [True False] 209

210 * Allow only SSLv3 connections if true. * NOTE: Enabling this may cause some browsers problems. root_endpoint = <URI_prefix_string> * Defines the root URI path on which the appserver will listen. * Default setting is '/'. * For example: if you want to proxy the splunk UI at then set root_endpoint = /splunkui static_endpoint = <URI_prefix_string> * Path to static content. * The path here is automatically appended to root_endpoint defined above. * Default is /static. static_dir = <relative_filesystem_path> * The directory that actually holds the static content. * This can be an absolute URL if you want to put it elsewhere. * Default is share/splunk/search_mrsparkle/exposed. enable_gzip = [True False] * Determines if web server applies gzip compression to responses. * Defaults to True. cherrypy HTTP server config server.thread_pool = <integer> * Specifies the numbers of threads the app server is allowed to maintain. * Defaults to 10. server.socket_host = <ip_address> * Host values may be any IPv4 or IPv6 address, or any valid hostname. * The string 'localhost' is a synonym for ' ' (or '::1', if your hosts file prefers IPv6). The string ' ' is a special IPv4 entry meaning "any active interface" (INADDR_ANY), and '::' is the similar IN6ADDR_ANY for IPv6. * The empty string or None are not allowed. * Defaults to log.access_file = <filename> * Specifies the HTTP access log filename. * Stored in default Splunk /var/log directory. * Defaults to pdf_access.log log.error_file = <filename> * Specifies the HTTP error log filename. * Stored in default Splunk /var/log directory. * Defaults to pdf_service.log log.screen = [True False] * Indicates if runtime output is displayed inside an interactive tty. * Defaults to True request.show_tracebacks = [True False] * Indicates if an exception traceback is displayed to the user on fatal exceptions. * Defaults to True engine.autoreload_on = [True False] * Indicates if the app server will auto-restart if it detects a python file has changed. * Defaults to False tools.sessions.on = True * Indicates if user session support is enabled. * Should always be True tools.sessions.timeout = <integer> * Specifies the number of minutes of inactivity before a user session expires. * Defaults to 60 response.timeout = <integer> 210

211 * Specifies the number of seconds to wait for the server to complete a response. * Some requests such as uploading large files can take a long time. * Defaults to 7200 tools.sessions.storage_type = [file] tools.sessions.storage_path = <filepath> * Specifies the session information storage mechanisms. * Comment out these two lines to use RAM based sessions instead. * Use an absolute path to store sessions outside of the Splunk directory tree. * Defaults to storage_type=file, storage_path=var/run/splunk tools.decode.on = [True False] * Indicates if all strings that come into CherryPy controller methods are decoded as unicode (assumes UTF-8 encoding). * WARNING: Disabling this will likely break the application, as all incoming strings are assumed to be unicode. * Defaults to True tools.encode.on = [True False] * Encodes all controller method response strings into UTF-8 str objects in Python. * WARNING: Disabling this will likely cause high byte character encoding to fail. * Defaults to True tools.encode.encoding = <codec> * Force all outgoing characters to be encoded into UTF-8. * This only works with tools.encode.on set to True. * By setting this to utf-8, CherryPy's default behavior of observing the Accept-Charset header is overwritten and forces utf-8 output. Only change this if you know a particular browser installation must receive some other character encoding (Latin-1, iso , etc.). * WARNING: Change this at your own risk. * Defaults to utf-8 pid_path = <filepath> * Specifies the path to the PID file. * Defaults to var/run/splunk/splunkweb.pid. firefox_cmdline = <cmdline> * Specifies additional arguments to pass to Firefox. * This should normally not be set. max_queue = <integer> * Specifies the maximum size of the backlog of pending report requests. * Once the backlog is reached the server will return an error on receiving additional requests. * Defaults to 10. max_concurrent = <integer> * Specifies the maximum number of copies of Firefox that the report server will use concurrently to render reports. * Increase only if the host machine has multiple cores and plenty of spare memory. * Defaults to 2. Xvfb = <path> * Pathname to the Xvfb program. * Defaults to searching the PATH. xauth = <path> * Pathname to the xauth program. * Defaults to searching the PATH. mcookie = <path> * Pathname to the mcookie program. * Defaults to searching the PATH. appserver_ipaddr = <ip_networks> * If set, the PDF server will only query Splunk app servers on IP addresses within the IP networks specified here. * Networks can be specified as a prefix ( /16) or using a netmask ( / ). * IPv6 addresses are also supported. * Individual IP addresses can also be listed ( ). * Multiple networks should be comma separated. * Defaults to accepting any IP address. 211

212 client_ipaddr = <ip_networks> * If set, the PDF server will only accept requests from hosts whose IP address falls within the IP networks specified here. * Generally this setting should match the appserver_ipaddr setting. * Format matches appserver_ipaddr. * Defaults to accepting any IP address. screenshot_enabled = [True False] * If enabled allows screenshots of the X server to be taken for debugging purposes. * Enabling this is a potential security hole as anyone on an IP address matching client_ipaddr will be able to see reports in progress. * Defaults to False. pdf_server.conf.example Version This is an example pdf_server.conf. Use this file to configure pdf server process settings. To use one or more of these configurations, copy the configuration block into pdf_server.conf in $SPLUNK_HOME/etc/system/local/. You must restart the pdf server to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at This stanza heading must precede any changes. [settings] Change the default port number: httpport = Lock down access to the IP address of specific appservers that will utilize the pdf server appserver_ipaddr = /24, client_ipaddr = /24, procmon-filters.conf 다음은 procmon-filters.conf의 사양 및 예제 파일입니다. procmon-filters.conf.spec Version *** DEPRECATED *** This file contains potential attribute/value pairs to use when configuring Windows registry monitoring. The procmon-filters.conf file contains the regular expressions you create to refine and filter the processes you want Splunk to monitor. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at find out if this file is still being used. [<stanza name>] * Name of the filter being defined. proc = <string> * Regex specifying process image that you want Splunk to monitor. type = <string> 212

213 * Regex specifying the type(s) of process event that you want Splunk to monitor. hive = <string> * Not used in this context, but should always have value ".*" procmon-filters.conf.example Version This file contains example registry monitor filters. To create your own filter, use the information in procmon-filters.conf.spec. To use one or more of these configurations, copy the configuration block into procmon-filters.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [default] hive =.* [not-splunk-optimize] proc = (?<!splunk-optimize.exe)$ type = create exit image props.conf 다음은 props.conf의 사양 및 예제 파일입니다. props.conf.spec This file contains possible attribute/value pairs for configuring Splunk's processing properties via props.conf. Props.conf is commonly used for: * Configuring linebreaking for multiline events. * Setting up character set encoding. * Allowing processing of binary files. * Configuring timestamp recognition. * Configuring event segmentation. * Overriding Splunk's automated host and source type matching. You can use props.conf to: * Configure advanced (regex-based) host and source type overrides. * Override source type matching for data from a particular source. * Set up rule-based source type recognition. * Rename source types. * Anonymizing certain types of sensitive incoming data, such as credit card or social security numbers, using sed scripts. * Routing specific events to a particular index, when you have multiple indexes. * Creating new index-time field extractions, including header-based field extractions. NOTE: We do not recommend adding to the set of fields that are extracted at index time unless it is absolutely necessary because there are negative performance implications. * Defining new search-time field extractions. You can define basic search-time field extractions entirely through props.conf. But a transforms.conf component is required if you need to create search-time field extractions that involve one or more of the following: * Reuse of the same field-extracting regular expression across multiple sources, source types, or hosts. * Application of more than one regex to the same source, source type, or host. * Delimiter-based field extractions (they involve field-value pairs that are separated by commas, colons, semicolons, bars, or something similar). * Extraction of multiple values for the same field (multivalued field extraction). * Extraction of fields with names that begin with numbers or underscores. * Setting up lookup tables that look up fields from external sources. * Creating field aliases. 213

214 NOTE: Several of the above actions involve a corresponding transforms.conf configuration. You can find more information on these topics by searching the Splunk documentation ( There is a props.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a props.conf in $SPLUNK_HOME/etc/system/local/. For help, see props.conf.example. You can enable configurations changes made to props.conf by typing the following search string in Splunk Web: extract reload=t To learn more about configuration files (including precedence) please see the documentation located at For more information about using props.conf in conjunction with distributed Splunk deployments, see the Distributed Deployment Manual. GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<spec>] * This stanza enables properties for a given <spec>. * A props.conf file can contain multiple stanzas for any number of different <spec>. * Follow this stanza name with any number of the following attribute/value pairs, as appropriate for what you want to do. * If you do not set an attribute for a given <spec>, the default is used. <spec> can be: 1. <sourcetype>, the source type of an event. 2. host::<host>, where <host> is the host, or host-matching pattern, for an event. 3. source::<source>, where <source> is the source, or source-matching pattern, for an event. 4. rule::<rulename>, where <rulename> is a unique name of a source type classification rule. 5. delayedrule::<rulename>, where <rulename> is a unique name of a delayed source type classification rule. These are only considered as a last resort before generating a new source type based on the source seen. **[<spec>] stanza precedence:** For settings that are specified in multiple categories of matching [<spec>] stanzas, [host::<host>] settings override [<sourcetype>] settings. Additionally, [source::<source>] settings override both [host::<host>] and [<sourcetype>] settings. **Considerations for Windows file paths:** When you specify Windows-based file paths as part of a [source::<source>] stanza, you must escape any backslashes contained within the specified file path. Example: [source::c:\\path_to\\file.txt] **[<spec>] stanza patterns:** When setting a [<spec>] stanza, you can use the following regex-type syntax:... recurses through directories until the match is met or equivalently, matches any number of characters. * matches anything but the path separator 0 or more times. The path separator is '/' on unix, or '\' on windows. Intended to match a partial or complete directory or filename. is equivalent to 'or' ( ) are used to limit scope of. \\ = matches a literal backslash '\'. 214

215 Example: [source::...(?<!tar.)(gz tgz)] This matches any file ending with '.gz' or '.bz2', provided this is not preceded by 'tar.', so tar.bz2 and tar.gz would not be matched. **[source::<source>] and [host::<host>] stanza match language:** Match expressions must match the entire name, not just a substring. If you are familiar with regular expressions, match expressions are based on a full implementation of PCRE with the translation of..., * and. Thus. matches a period, * matches non-directory separators, and... matches any number of any characters. For more information see the wildcards section at: **[<spec>] stanza pattern collisions:** Suppose the source of a given input matches multiple [source::<source>] patterns. If the [<spec>] stanzas for these patterns each supply distinct settings, Splunk applies all of these settings. However, suppose two [<spec>] stanzas supply the same setting. In this case, Splunk chooses the value to apply based on the ASCII order of the patterns in question. For example, take this source: source::az and the following colliding patterns: [source::...a...] sourcetype = a [source::...z...] sourcetype = z In this case, the settings provided by the pattern [source::...a...] take precedence over those provided by [source::...z...], and sourcetype ends up with "a" as its value. To override this default ASCII ordering, use the priority key: [source::...a...] sourcetype = a priority = 5 [source::...z...] sourcetype = z priority = 10 Assigning a higher priority to the second stanza causes sourcetype to have the value "z". **Case-sensitivity for [<spec>] stanza matching:** By default, [source::<source>] and [<sourcetype>] stanzas match in a case-sensitive manner, while [host::<host>] stanzas match in a case-insensitive manner. This is a convenient default, given that DNS names are case-insensitive. To force a [host::<host>] stanza to match in a case-sensitive manner use the "(?-i)" option in its pattern. For example: [host::foo] FIELDALIAS-a = a AS one [host::(?-i)bar] FIELDALIAS-b = b AS two The first stanza will actually apply to events with host values of "FOO" or "Foo". The second stanza, on the other hand, will not apply to events with host values of "BAR" or "Bar". 215

216 **Building the final [<spec>] stanza:** The final [<spec>] stanza is built by layering together (1) literal-matching stanzas (stanzas which match the string literally) and (2) any regex-matching stanzas, according to the value of the priority field. If not specified, the default value of the priority key is: * 0 for pattern-matching stanzas. * 100 for literal-matching stanzas. NOTE: Setting the priority key to a value greater than 100 causes the pattern-matched [<spec>] stanzas to override the values of the literal-matching [<spec>] stanzas. The priority key can also be used to resolve collisions between [<sourcetype>] patterns and [host::<host>] patterns. However, be aware that the priority key does *not* affect precedence across <spec> types. For example, [<spec>] stanzas with [source::<source>] patterns take priority over stanzas with [host::<host>] and [<sourcetype>] patterns, regardless of their respective priority key values. ****************************************************************************** The possible attributes/value pairs for props.conf, and their default values, are: ****************************************************************************** International characters and character encoding. CHARSET = <string> * When set, Splunk assumes the input from the given [<spec>] is in the specified encoding. * Can only be used as the basis of [<sourcetype>] or [source::<spec>], not [host::<spec>]. * A list of valid encodings can be retrieved using the command "iconv -l" on most *nix systems. * If an invalid encoding is specified, a warning is logged during initial configuration and further input from that [<spec>] is discarded. * If the source encoding is valid, but some characters from the [<spec>] are not valid in the specified encoding, then the characters are escaped as hex (for example, "\xf3"). * When set to "AUTO", Splunk attempts to automatically determine the character encoding and convert text from that encoding to UTF-8. * For a complete list of the character sets Splunk automatically detects, see the online documentation. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to ASCII. ****************************************************************************** Line breaking ****************************************************************************** Use the following attributes to define the length of a line. TRUNCATE = <non-negative integer> * Change the default maximum line length (in bytes). * Although this is in bytes, line length is rounded down when this would otherwise land mid-character for multi-byte characters. * Set to 0 if you never want truncation (very long lines are, however, often a sign of garbage data). * Defaults to bytes. LINE_BREAKER = <regular expression> * Specifies a regex that determines how the raw text stream is broken into initial events, before line merging takes place. (See the SHOULD_LINEMERGE attribute, below) * Defaults to ([\r\n]+), meaning data is broken into an event for each line, delimited by any number of carriage return or newline characters. * The regex must contain a capturing group -- a pair of parentheses which defines an identified subcomponent of the match. * Wherever the regex matches, Splunk considers the start of the first capturing group to be the end of the previous event, and considers the end of the first capturing group to be the start of the next event. * The contents of the first capturing group are discarded, and will not be present in any event. You are telling Splunk that this text comes between lines. 216

217 * NOTE: You get a significant boost to processing speed when you use LINE_BREAKER to delimit multiline events (as opposed to using SHOULD_LINEMERGE to reassemble individual lines into multiline events). * When using LINE_BREAKER to delimit events, SHOULD_LINEMERGE should be set to false, to ensure no further combination of delimited events occurs. * Using LINE_BREAKER to delimit events is discussed in more detail in the web documentation at the following url: ** Special considerations for LINE_BREAKER with branched expressions ** When using LINE_BREAKER with completely independent patterns separated by pipes, some special issues come into play. EG. LINE_BREAKER = pattern1 pattern2 pattern3 Note, this is not about all forms of alternation, eg there is nothing particular special about example: LINE_BREAKER = ([\r\n])+(one two three) where the top level remains a single expression. A caution: Relying on these rules is NOT encouraged. Simpler is better, in both regular expressions and the complexity of the behavior they rely on. If possible, it is strongly recommended that you reconstruct your regex to have a leftmost capturing group that always matches. It may be useful to use non-capturing groups if you need to express a group before the text to discard. EG. LINE_BREAKER = (?:one two)([\r\n]+) * This will match the text one, or two, followed by any amount of newlines or carriage returns. The one-or-two group is non-capturing via the?: prefix and will be skipped by LINE_BREAKER. * A branched expression can match without the first capturing group matching, so the line breaker behavior becomes more complex. Rules: 1: If the first capturing group is part of a match, it is considered the linebreak, as normal. 2: If the first capturing group is not part of a match, the leftmost capturing group which is part of a match will be considered the linebreak. 3: If no capturing group is part of the match, the linebreaker will assume that the linebreak is a zero-length break immediately preceding the match. Example 1: LINE_BREAKER = end(\n)begin end2(\n)begin2 begin3 * A line ending with 'end' followed a line beginning with 'begin' would match the first branch, and the first capturing group would have a match according to rule 1. That particular newline would become a break between lines. * A line ending with 'end2' followed by a line beginning with 'begin2' would match the second branch and the second capturing group would have a match. That second capturing group would become the linebreak according to rule 2, and the associated newline would become a break between lines. * The text 'begin3' anywhere in the file at all would match the third branch, and there would be no capturing group with a match. A linebreak would be assumed immediately prior to the text 'begin3' so a linebreak would be inserted prior to this text in accordance with rule 3. This means that a linebreak will occur before the text 'begin3' at any point in the text, whether a linebreak character exists or not. Example 2: Example 1 would probably be better written as follows. This is not equivalent for all possible files, but for most real files would be equivalent. LINE_BREAKER = end2?(\n)begin(2 3)? LINE_BREAKER_LOOKBEHIND = <integer> * When there is leftover data from a previous raw chunk, LINE_BREAKER_LOOKBEHIND indicates the number of bytes before the end of the raw chunk (with the next chunk concatenated) that Splunk applies the LINE_BREAKER regex. You may want to increase this value from its default if you are dealing with especially large or multiline events. * Defaults to 100 (bytes). 217

218 Use the following attributes to specify how multiline events are handled. SHOULD_LINEMERGE = [true false] * When set to true, Splunk combines several lines of data into a single multiline event, based on the following configuration attributes. * Defaults to true. When SHOULD_LINEMERGE is set to true, use the following attributes to define how Splunk builds multiline events. BREAK_ONLY_BEFORE_DATE = [true false] * When set to true, Splunk creates a new event only if it encounters a new line with a date. * Note, when using DATETIME_CONFIG = CURRENT or NONE, this setting is not meaningful, as timestamps are not identified. * Defaults to true. BREAK_ONLY_BEFORE = <regular expression> * When set, Splunk creates a new event only if it encounters a new line that matches the regular expression. * Defaults to empty. MUST_BREAK_AFTER = <regular expression> * When set and the regular expression matches the current line, Splunk creates a new event for the next input line. * Splunk may still break before the current line if another rule matches. * Defaults to empty. MUST_NOT_BREAK_AFTER = <regular expression> * When set and the current line matches the regular expression, Splunk does not break on any subsequent lines until the MUST_BREAK_AFTER expression matches. * Defaults to empty. MUST_NOT_BREAK_BEFORE = <regular expression> * When set and the current line matches the regular expression, Splunk does not break the last event before the current line. * Defaults to empty. MAX_EVENTS = <integer> * Specifies the maximum number of input lines to add to any event. * Splunk breaks after the specified number of lines are read. * Defaults to 256 (lines). ****************************************************************************** Timestamp extraction configuration ****************************************************************************** DATETIME_CONFIG = <filename relative to $SPLUNK_HOME> * Specifies which file configures the timestamp extractor, which identifies timestamps from the event text. * This configuration may also be set to "NONE" to prevent the timestamp extractor from running or "CURRENT" to assign the current system time to each event. * "CURRENT" will set the time of the event to the time that the event was merged from lines, or worded differently, the time it passed through the aggregator processor. * "NONE" will leave the event time set to whatever time was selected by the input layer * For data sent by splunk forwarders over the splunk protocol, the input layer will be the time that was selected on the forwarder by its input behavior (as below). * For file-based inputs (monitor, batch) the time chosen will be the modification timestamp on the file being read. * For other inputs, the time chosen will be the current system time when the event is read from the pipe/socket/etc. * Both "CURRENT" and "NONE" explicitly disable the per-text timestamp identification, so the default event boundary detection (BREAK_ONLY_BEFORE_DATE = true) is likely to not work as desired. When using these settings, use SHOULD_LINEMERGE and/or the BREAK_ONLY_*, MUST_BREAK_* settings to control event merging. * Defaults to /etc/datetime.xml (for example, $SPLUNK_HOME/etc/datetime.xml). TIME_PREFIX = <regular expression> * If set, splunk scans the event text for a match for this regex in event text before attempting to extract a timestamp. * The timestamping algorithm only looks for a timestamp in the text following the end of the first regex match. 218

219 * For example, if TIME_PREFIX is set to "abc123", only text following the first occurrence of the text abc123 will be used for timestamp extraction. * If the TIME_PREFIX cannot be found in the event text, timestamp extraction will not occur. * Defaults to empty. MAX_TIMESTAMP_LOOKAHEAD = <integer> * Specifies how far (in characters) into an event Splunk should look for a timestamp. * This constraint to timestamp extraction is applied from the point of the TIME_PREFIX-set location. * For example, if TIME_PREFIX positions a location 11 characters into the event, and MAX_TIMESTAMP_LOOKAHEAD is set to 10, timestamp extraction will be constrained to characters 11 through 20. * If set to 0, or -1, the length constraint for timestamp recognition is effectively disabled. This can have negative performance implications which scale with the length of input lines (or with event size when LINE_BREAKER is redefined for event splitting). * Defaults to 150 (characters). TIME_FORMAT = <strptime-style format> * Specifies a strptime format string to extract the date. * strptime is an industry standard for designating time formats. * For more information on strptime, see "Configure timestamp recognition" in the online documentation. * TIME_FORMAT starts reading after the TIME_PREFIX. If both are specified, the TIME_PREFIX regex must match up to and including the character before the TIME_FORMAT date. * For good results, the <strptime-style format> should describe the day of the year and the time of day. * Defaults to empty. TZ = <timezone identifier> * The algorithm for determining the time zone for a particular event is as follows: * If the event has a timezone in its raw text (for example, UTC, -08:00), use that. * If TZ is set to a valid timezone string, use that. * If the event was forwarded, and the forwarder-indexer connection is using the 6.0+ forwarding protocol, use the timezone provided by the forwarder. * Otherwise, use the timezone of the system that is running splunkd. * Defaults to empty. TZ_ALIAS = <key=value>[,<key=value>]... * Provides splunk admin-level control over how timezone strings extracted from events are interpreted. * For example, EST can mean Eastern (US) Standard time, or Eastern (Australian) Standard time. There are many other three letter timezone acronyms with many expansions. * There is no requirement to use TZ_ALIAS if the traditional Splunk default mappings for these values have been as expected. For example, EST maps to the Eastern US by default. * Has no effect on TZ value; this only affects timezone strings from event text, either from any configured TIME_FORMAT, or from pattern-based guess fallback. * The setting is a list of key=value pairs, separated by commas. * The key is matched against the text of the timezone specifier of the event, and the value is the timezone specifier to use when mapping the timestamp to UTC/GMT. * The value is another TZ specifier which expresses the desired offset. * Example: TZ_ALIAS = EST=GMT+10:00 (See props.conf.example for more/full examples) * Defaults to unset. MAX_DAYS_AGO = <integer> * Specifies the maximum number of days past, from the current date, that an extracted date can be valid. * For example, if MAX_DAYS_AGO = 10, Splunk ignores dates that are older than 10 days ago. * Defaults to 2000 (days), maximum * IMPORTANT: If your data is older than 2000 days, increase this setting. MAX_DAYS_HENCE = <integer> * Specifies the maximum number of days in the future from the current date that an extracted date can be valid. * For example, if MAX_DAYS_HENCE = 3, dates that are more than 3 days in the future are ignored. * The default value includes dates from one day in the future. * If your servers have the wrong date set or are in a timezone that is one day ahead, increase this value to at least 3. * Defaults to 2 (days), maximum * IMPORTANT:False positives are less likely with a tighter window, change with caution. MAX_DIFF_SECS_AGO = <integer> * If the event's timestamp is more than <integer> seconds BEFORE the previous timestamp, only 219

220 accept the event if it has the same exact time format as the majority of timestamps from the source. * IMPORTANT: If your timestamps are wildly out of order, consider increasing this value. * Note: if the events contain time but not date (date determined another way, such as from a filename) this check will only consider the hour. (No one second granularity for this purpose.) * Defaults to 3600 (one hour), maximum MAX_DIFF_SECS_HENCE = <integer> * If the event's timestamp is more than <integer> seconds AFTER the previous timestamp, only accept the event if it has the same exact time format as the majority of timestamps from the source. * IMPORTANT: If your timestamps are wildly out of order, or you have logs that are written less than once a week, consider increasing this value. * Defaults to (one week), maximum ****************************************************************************** Structured Data Header Extraction and configuration ****************************************************************************** * This feature and all of its settings apply at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. Special characters for Structured Data Header Extraction: Some unprintable characters can be described with escape sequences. The attributes that can use these characters specifically mention that capability in their descriptions below. \f : form feed byte: 0x0c \s : space byte: 0x20 \t : horizontal tab byte: 0x09 \v : vertical tab byte: 0x0b INDEXED_EXTRACTIONS = < CSV W3C TSV PSV JSON > * Tells Splunk the type of file and the extraction and/or parsing method Splunk should use on the file. CSV - Comma separated value format TSV - Tab-separated value format PSV - pipe " " separated value format W3C - W3C Extended Extended Log File Format JSON - JavaScript Object Notation format * These settings default the values of the remaining settings to the appropriate values for these known formats. * Defaults to unset. PREAMBLE_REGEX = <regex> * Some files contain preamble lines. This attribute specifies a regular expression which allows Splunk to ignore these preamble lines, based on the pattern specified. FIELD_HEADER_REGEX = <regex> * A regular expression that specifies a pattern for prefixed headers. Note that the actual header starts after the pattern and it is not included in the header field. * This attribute supports the use of the special characters described above. HEADER_FIELD_LINE_NUMBER = <integer> * Tells Splunk the line number of the line within the file that contains the header fields. If set to 0, Splunk attempts to locate the header fields within the file automatically. * The default value is set to 0. FIELD_DELIMITER = <character> * Tells Splunk which character delimits or separates fields in the specified file or source. * This attribute supports the use of the special characters described above. HEADER_FIELD_DELIMITER = <character> * Tells Splunk which character delimits or separates header fields in the specified file or source. * This attribute supports the use of the special characters described above. FIELD_QUOTE = <character> * Tells Splunk the character to use for quotes in the specified file or source. * This attribute supports the use of the special characters described above. HEADER_FIELD_QUOTE = <character> * Specifies Splunk the character to use for quotes in the header of the specified file or source. * This attribute supports the use of the special characters described above. 220

221 TIMESTAMP_FIELDS = [ <string>,..., <string>] * Some CSV and structured files have their timestamp encompass multiple fields in the event separated by delimiters. This attribue tells Splunk to specify all such fields which constitute the timestamp in a comma-separated fashion. * If not specified, Splunk tries to automatically extract the timestamp of the event. FIELD_NAMES = [ <string>,..., <string>] * Some CSV and structured files might have missing headers. This attribute tells Splunk to specify the header field names directly. MISSING_VALUE_REGEX = <regex> * Tells Splunk the placeholder to use in events where no value is present. ****************************************************************************** Field extraction configuration ****************************************************************************** NOTE: If this is your first time configuring field extractions in props.conf, review the following information first. There are three different "field extraction types" that you can use to configure field extractions: TRANSFORMS, REPORT, and EXTRACT. They differ in two significant ways: 1) whether they create indexed fields (fields extracted at index time) or extracted fields (fields extracted at search time), and 2), whether they include a reference to an additional component called a "field transform," which you define separately in transforms.conf. **Field extraction configuration: index time versus search time** Use the TRANSFORMS field extraction type to create index-time field extractions. Use the REPORT or EXTRACT field extraction types to create search-time field extractions. NOTE: Index-time field extractions have performance implications. Creating additions to Splunk's default set of indexed fields is ONLY recommended in specific circumstances. Whenever possible, extract fields only at search time. There are times when you may find that you need to change or add to your set of indexed fields. For example, you may have situations where certain search-time field extractions are noticeably impacting search performance. This can happen when the value of a search-time extracted field exists outside of the field more often than not. For example, if you commonly search a large event set with the expression company_id=1 but the value 1 occurs in many events that do *not* have company_id=1, you may want to add company_id to the list of fields extracted by Splunk at index time. This is because at search time, Splunk will want to check each instance of the value 1 to see if it matches company_id, and that kind of thing slows down performance when you have Splunk searching a large set of data. Conversely, if you commonly search a large event set with expressions like company_id!=1 or NOT company_id=1, and the field company_id nearly *always* takes on the value 1, you may want to add company_id to the list of fields extracted by Splunk at index time. For more information about index-time field extraction, search the documentation for "index-time extraction." For more information about search-time field extraction, search the online documentation for "search-time extraction." **Field extraction configuration: field transforms vs. "inline" (props.conf only) configs** The TRANSFORMS and REPORT field extraction types reference an additional component called a field transform, which you define separately in transforms.conf. Field transforms contain a field-extracting regular expression and other attributes that govern the way that the transform extracts fields. Field transforms are always created in conjunction with field extraction stanzas in props.conf; they do not stand alone. The EXTRACT field extraction type is considered to be "inline," which means that it does not reference a field transform. It contains the regular expression that Splunk uses to extract fields at search time. You can use EXTRACT to define a field extraction entirely within props.conf--no transforms.conf component is required. **Search-time field extractions: Why use REPORT if EXTRACT will do?** It's a good question. And much of the time, EXTRACT is all you need for search-time field extraction. But when you build search-time field extractions, there are specific cases that require the use of REPORT and the field transform that it references. Use REPORT if you want 221

222 to: * Reuse the same field-extracting regular expression across multiple sources, source types, or hosts. If you find yourself using the same regex to extract fields across several different sources, source types, and hosts, set it up as a transform, and then reference it in REPORT extractions in those stanzas. If you need to update the regex you only have to do it in one place. Handy! * Apply more than one field-extracting regular expression to the same source, source type, or host. This can be necessary in cases where the field or fields that you want to extract from a particular source, source type, or host appear in two or more very different event patterns. * Use a regular expression to extract fields from the values of another field (also referred to as a "source key"). * Set up delimiter-based field extractions. Useful if your event data presents field-value pairs (or just field values) separated by delimiters such as commas, spaces, bars, and so on. * Configure extractions for multivalued fields. You can have Splunk append additional values to a field as it finds them in the event data. * Extract fields with names beginning with numbers or underscores. Ordinarily, Splunk's key cleaning functionality removes leading numeric characters and underscores from field names. If you need to keep them, configure your field transform to turn key cleaning off. * Manage formatting of extracted fields, in cases where you are extracting multiple fields, or are extracting both the field name and field value. **Precedence rules for TRANSFORMS, REPORT, and EXTRACT field extraction types** * For each field extraction, Splunk takes the configuration from the highest precedence configuration stanza (see precedence rules at the beginning of this file). * If a particular field extraction is specified for a source and a source type, the field extraction for source wins out. * Similarly, if a particular field extraction is specified in../local/ for a <spec>, it overrides that field extraction in../default/. TRANSFORMS-<class> = <transform_stanza_name>, <transform_stanza_name2>,... * Used for creating indexed fields (index-time field extractions). * <class> is a unique literal string that identifies the namespace of the field you're extracting. **Note:** <class> values do not have to follow field name syntax restrictions. You can use characters other than a-z, A-Z, and 0-9, and spaces are allowed. <class> values are not subject to key cleaning. * <transform_stanza_name> is the name of your stanza from transforms.conf. * Use a comma-separated list to apply multiple transform stanzas to a single TRANSFORMS extraction. Splunk applies them in the list order. For example, this sequence ensures that the [yellow] transform stanza gets applied first, then [blue], and then [red]: [source::color_logs] TRANSFORMS-colorchange = yellow, blue, red REPORT-<class> = <transform_stanza_name>, <transform_stanza_name2>,... * Used for creating extracted fields (search-time field extractions) that reference one or more transforms.conf stanzas. * <class> is a unique literal string that identifies the namespace of the field you're extracting. **Note:** <class> values do not have to follow field name syntax restrictions. You can use characters other than a-z, A-Z, and 0-9, and spaces are allowed. <class> values are not subject to key cleaning. * <transform_stanza_name> is the name of your stanza from transforms.conf. * Use a comma-separated list to apply multiple transform stanzas to a single REPORT extraction. Splunk applies them in the list order. For example, this sequence insures that the [yellow] transform stanza gets applied first, then [blue], and then [red]: [source::color_logs] REPORT-colorchange = yellow, blue, red EXTRACT-<class> = [<regex> <regex> in <src_field>] * Used to create extracted fields (search-time field extractions) that do not reference transforms.conf stanzas. * Performs a regex-based field extraction from the value of the source field. * <class> is a unique literal string that identifies the namespace of the field you're extracting. **Note:** <class> values do not have to follow field name syntax restrictions. You can use characters other than a-z, A-Z, and 0-9, and spaces are allowed. <class> values are not subject to key cleaning. * The <regex> is required to have named capturing groups. When the <regex> matches, the named capturing groups and their values are added to the event. 222

223 * Use '<regex> in <src_field>' to match the regex against the values of a specific field. Otherwise it just matches against _raw (all raw event data). * NOTE: <src_field> can only contain alphanumeric characters and underscore (a-z, A-Z, 0-9, and _). * If your regex needs to end with 'in <string>' where <string> is *not* a field name, change the regex to end with '[i]n <string>' to ensure that Splunk doesn't try to match <string> to a field name. KV_MODE = [none auto auto_escaped multi json xml] * Used for search-time field extractions only. * Specifies the field/value extraction mode for the data. * Set KV_MODE to one of the following: * none: if you want no field/value extraction to take place. * auto: extracts field/value pairs separated by equal signs. * auto_escaped: extracts fields/value pairs separated by equal signs and honors \" and \\ as escaped sequences within quoted values, e.g field="value with \"nested\" quotes" * multi: invokes the multikv search command to expand a tabular event into multiple events. * xml : automatically extracts fields from XML data. * json: automatically extracts fields from JSON data. * Setting to 'none' can ensure that one or more user-created regexes are not overridden by automatic field/value extraction for a particular host, source, or source type, and also increases search performance. * Defaults to auto. * The 'xml' and 'json' modes will not extract any fields when used on data that isn't of the correct format (JSON or XML). KV_TRIM_SPACES = true false * Modifies the behavior of KV_MODE when set to auto, and auto_escaped. * Traditionally, automatically identified fields have leading and trailing whitespace removed from their values. * Example event: :10:45 myfield=" apples " would result in a field called 'myfield' with a value of 'apples'. * If this value is set to false, then external whitespace then this outer space is retained. * Example: :10:45 myfield=" apples " would result in a field called 'myfield' with a value of ' apples '. * The trimming logic applies only to space characters, not tabs, or other whitespace. * NOTE: The Splunk UI currently has limitations with displaying and interactively clicking on fields that have leading or trailing whitespace. Field values with leading or trailing spaces may not look distinct in the event viewer, and clicking on a field value will typically insert the term into the search string without its embedded spaces. * These warts are not specific to this feature. Any such embedded spaces will behave this way. * The Splunk search language and included commands will respect the spaces. * Defaults to true. CHECK_FOR_HEADER = [true false] * Used for index-time field extractions only. * Set to true to enable header-based field extraction for a file. * If the file has a list of columns and each event contains a field value (without field name), Splunk picks a suitable header line to use to for extracting field names. * If the file has a list of columns and each event contains a field value (without a field name), Splunk picks a suitable header line to use for field extraction. * Can only be used on the basis of [<sourcetype>] or [source::<spec>], not [host::<spec>]. * Disabled when LEARN_SOURCETYPE = false. * Will cause the indexed source type to have an appended numeral; for example, sourcetype-2, sourcetype-3, and so on. * The field names are stored in etc/apps/learned/local/props.conf. * Because of this, this feature will not work in most environments where the data is forwarded. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to false. SEDCMD-<class> = <sed script> * Only used at index time. * Commonly used to anonymize incoming data at index time, such as credit card or social security numbers. For more information, search the online documentation for "anonymize data." * Used to specify a sed script which Splunk applies to the _raw field. * A sed script is a space-separated list of sed commands. Currently the following subset of 223

224 sed commands is supported: * replace (s) and character substitution (y). * Syntax: * replace - s/regex/replacement/flags * regex is a perl regular expression (optionally containing capturing groups). * replacement is a string to replace the regex match. Use \n for back references, where "n" is a single digit. * flags can be either: g to replace all matches, or a number to replace a specified match. * substitute - y/string1/string2/ * substitutes the string1[i] with string2[i] FIELDALIAS-<class> = (<orig_field_name> AS <new_field_name>)+ * Use this to apply aliases to a field. The original field is not removed. This just means that the original field can be searched on using any of its aliases. * You can create multiple aliases for the same field. * <orig_field_name> is the original name of the field. * <new_field_name> is the alias to assign to the field. * You can include multiple field alias renames in the same stanza. * Field aliasing is performed at search time, after field extraction, but before calculated fields (EVAL-* statements) and lookups. This means that: * Any field extracted at search time can be aliased. * You can specify a lookup based on a field alias. * You cannot alias a calculated field. EVAL-<fieldname> = <eval statement> * Use this to automatically run the <eval statement> and assign the value of the output to <fieldname>. This creates a "calculated field." * When multiple EVAL-* statements are specified, they behave as if they are run in parallel, rather than in any particular sequence. For example say you have two statements: EVAL-x = y*2 and EVAL-y=100. In this case, "x" will be assigned the original value of "y * 2," not the value of "y" after it is set to 100. * Splunk processes calculated fields after field extraction and field aliasing but before lookups. This means that: * You can use a field alias in the eval statement for a calculated field. * You cannot use a field added through a lookup in an eval statement for a calculated field. LOOKUP-<class> = $TRANSFORM (<match_field> (AS <match_field_in_event>)?)+ (OUTPUT OUTPUTNEW (<output_field> (AS <output_field_in_event>)? )+ )? * At search time, identifies a specific lookup table and describes how that lookup table should be applied to events. * <match_field> specifies a field in the lookup table to match on. * By default Splunk looks for a field with that same name in the event to match with (if <match_field_in_event> is not provided) * You must provide at least one match field. Multiple match fields are allowed. * <output_field> specifies a field in the lookup entry to copy into each matching event, where it will be in the field <output_field_in_event>. * If you do not specify an <output_field_in_event> value, Splunk uses <output_field>. * A list of output fields is not required. * If they are not provided, all fields in the lookup table except for the match fields (and the timestamp field if it is specified) will be output for each matching event. * If the output field list starts with the keyword "OUTPUTNEW" instead of "OUTPUT", then each outputfield is only written out if it did not previous exist. Otherwise, the output fields are always overridden. Any event that has all of the <match_field> values but no matching entry in the lookup table clears all of the output fields. NOTE that OUTPUTNEW behavior has changed since 4.1.x (where *none* of the output fields were written to if *any* of the output fields previously existed). * Splunk processes lookups after it processes field extractions, field aliases, and calculated fields (EVAL-* statements). This means that you can use extracted fields, aliased fields, and calculated fields to specify lookups. But you can't use fields discovered by lookups in the configurations of extracted fields, aliased fields, or calculated fields. * The LOOKUP- prefix is actually case-insensitive. Acceptable variants include: LOOKUP_<class> = [...] LOOKUP<class> = [...] lookup_<class> = [...] lookup<class> = [...] ****************************************************************************** Binary file configuration 224

225 ****************************************************************************** NO_BINARY_CHECK = [true false] * When set to true, Splunk processes binary files. * Can only be used on the basis of [<sourcetype>], or [source::<source>], not [host::<host>]. * Defaults to false (binary files are ignored). * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. detect_trailing_nulls = [auto true false] * When enabled, Splunk will try to avoid reading in null bytes at the end of a file. * When false, splunk will assume that all the bytes in the file should be read and indexed. * Set this value to false for UTF-16 and other encodings (CHARSET) values that can have null bytes as part of the character text. * Subtleties of 'true' vs 'auto': * 'true' is the splunk-on-windows historical behavior of trimming all null bytes. * 'auto' is currently a synonym for true but will be extended to be sensitive to the charset selected (ie quantized for multi-byte encodings, and disabled for unsafe variable-width encdings) * This feature was introduced to work around programs which foolishly pre-allocate their log files with nulls and fill in data later. The well-known case is Internet Information Server. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to false on *nix, true on windows. ****************************************************************************** Segmentation configuration ****************************************************************************** SEGMENTATION = <segmenter> * Specifies the segmenter from segmenters.conf to use at index time for the host, source, or sourcetype specified by <spec> in the stanza heading. * Defaults to indexing. SEGMENTATION-<segment selection> = <segmenter> * Specifies that Splunk Web should use the specific segmenter (from segmenters.conf) for the given <segment selection> choice. * Default <segment selection> choices are: all, inner, outer, raw. For more information see the Admin Manual. * Do not change the set of default <segment selection> choices, unless you have some overriding reason for doing so. In order for a changed set of <segment selection> choices to appear in Splunk Web, you will need to edit the Splunk Web UI. ****************************************************************************** File checksum configuration ****************************************************************************** CHECK_METHOD = [endpoint_md5 entire_md5 modtime] * Set CHECK_METHOD endpoint_md5 to have Splunk checksum of the first and last 256 bytes of a file. When it finds matches, Splunk lists the file as already indexed and indexes only new data, or ignores it if there is no new data. * Set CHECK_METHOD = entire_md5 to use the checksum of the entire file. * Set CHECK_METHOD = modtime to check only the modification time of the file. * Settings other than endpoint_md5 cause Splunk to index the entire file for each detected change. * Important: this option is only valid for [source::<source>] stanzas. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to endpoint_md5. initcrclength = <integer> * See documentation in inputs.conf.spec. ****************************************************************************** Small file settings ****************************************************************************** PREFIX_SOURCETYPE = [true false] * NOTE: this attribute is only relevant to the "[too_small]" sourcetype. * Determines the source types that are given to files smaller than 100 lines, and are therefore not classifiable. 225

226 * PREFIX_SOURCETYPE = false sets the source type to "too_small." * PREFIX_SOURCETYPE = true sets the source type to "<sourcename>-too_small", where "<sourcename>" is a cleaned up version of the filename. * The advantage of PREFIX_SOURCETYPE = true is that not all small files are classified as the same source type, and wildcard searching is often effective. * For example, a Splunk search of "sourcetype=access*" will retrieve "access" files as well as "access-too_small" files. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to true. ****************************************************************************** Sourcetype configuration ****************************************************************************** sourcetype = <string> * Can only be set for a [source::...] stanza. * Anything from that <source> is assigned the specified source type. * Is used by file-based inputs, at input time (when accessing logfiles) such as on a forwarder, or indexer monitoring local files. * sourcetype assignment settings on a system receiving forwarded splunk data will not be applied to forwarded data. * For logfiles read locally, data from logfiles matching <source> is assigned the specified source type. * Defaults to empty. The following attribute/value pairs can only be set for a stanza that begins with [<sourcetype>]: rename = <string> * Renames [<sourcetype>] as <string> at search time * With renaming, you can search for the [<sourcetype>] with sourcetype=<string> * To search for the original source type without renaming it, use the field _sourcetype. * Data from a a renamed sourcetype will only use the search-time configuration for the target sourcetype. Field extractions (REPORTS/EXTRACT) for this stanza sourcetype will be ignored. * Defaults to empty. invalid_cause = <string> * Can only be set for a [<sourcetype>] stanza. * Splunk does not read any file sources of a sourcetype with invalid_cause set. * Set <string> to "archive" to send the file to the archive processor (specified in unarchive_cmd). * Set to any other string to throw an error in the splunkd.log if you are running Splunklogger in debug mode. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to empty. is_valid = [true false] * Automatically set by invalid_cause. * This setting applies at input time, when data is first read by Splunk, such as on a forwarder. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * DO NOT SET THIS. * Defaults to true. unarchive_cmd = <string> * Only called if invalid_cause is set to "archive". * This field is only valid on [source::<source>] stanzas. * <string> specifies the shell command to run to extract an archived source. * Must be a shell command that takes input on stdin and produces output on stdout. * Use _auto for Splunk's automatic handling of archive files (tar, tar.gz, tgz, tbz, tbz2, zip) * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to empty. unarchive_sourcetype = <string> * Sets the source type of the contents of the matching archive file. Use this field instead of the sourcetype field to set the source type of archive files that have the following extensions: gz, bz, bz2, Z. 226

227 * If this field is empty (for a matching archive file props lookup) Splunk strips off the archive file's extension (.gz, bz etc) and lookup another stanza to attempt to determine the sourcetype. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to empty. LEARN_SOURCETYPE = [true false] * Determines whether learning of known or unknown sourcetypes is enabled. * For known sourcetypes, refer to LEARN_MODEL. * For unknown sourcetypes, refer to the rule:: and delayedrule:: configuration (see below). * Setting this field to false disables CHECK_FOR_HEADER as well (see above). * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to true. LEARN_MODEL = [true false] * For known source types, the file classifier adds a model file to the learned directory. * To disable this behavior for diverse source types (such as sourcecode, where there is no good exemplar to make a sourcetype) set LEARN_MODEL = false. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to false. maxdist = <integer> * Determines how different a source type model may be from the current file. * The larger the maxdist value, the more forgiving Splunk will be with differences. * For example, if the value is very small (for example, 10), then files of the specified sourcetype should not vary much. * A larger value indicates that files of the given source type can vary quite a bit. * If you're finding that a source type model is matching too broadly, reduce its maxdist value by about 100 and try again. If you're finding that a source type model is being too restrictive, increase its maxdist value by about 100 and try again. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to 300. rule:: and delayedrule:: configuration MORE_THAN<optional_unique_value>_<number> = <regular expression> (empty) LESS_THAN<optional_unique_value>_<number> = <regular expression> (empty) * These settingg apply at input time, when data is first read by Splunk, such as on a forwarder. An example: [rule::bar_some] sourcetype = source_with_lots_of_bars if more than 80% of lines have "----", but fewer than 70% have "" declare this a "source_with_lots_of_bars" MORE_THAN_80 = ---- LESS_THAN_70 = A rule can have many MORE_THAN and LESS_THAN patterns, and all are required for the rule to match. ****************************************************************************** Annotation Processor configured ****************************************************************************** ANNOTATE_PUNCT = [true false] * Determines whether to index a special token starting with "punct::" * The "punct::" key contains punctuation in the text of the event. It can be useful for finding similar events * If it is not useful for your dataset, or if it ends up taking too much space in your index it is safe to disable it * Defaults to true. ****************************************************************************** Header Processor configuration ****************************************************************************** 227

228 HEADER_MODE = <empty> always firstline none * Determines whether to use the inline ***SPLUNK*** directive to rewrite index-time fields. * If "always", any line with ***SPLUNK*** can be used to rewrite index-time fields. * If "firstline", only the first line can be used to rewrite index-time fields. * If "none", the string ***SPLUNK*** is treated as normal data. * If <empty>, scripted inputs take the value "always" and file inputs take the value "none". * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Defaults to <empty>. ****************************************************************************** Internal settings ****************************************************************************** NOT YOURS. DO NOT SET. _actions = <string> * Internal field used for user-interface control of objects. * Defaults to "new,edit,delete". pulldown_type = <bool> * Internal field used for user-interface control of source types. * Defaults to empty. given_type = <string> * Internal field used by the CHECK_FOR_HEADER feature to remember the original sourcetype. * This setting applies at input time, when data is first read by Splunk. The setting is used on a Splunk system that has configured inputs acquiring the data. * Default to unset. ****************************************************************************** Sourcetype Category and Descriptions ****************************************************************************** description = <string> * Field used to describe the sourcetype. Does not affect indexing behaviour. * Defaults to unset. category = <string> * Field used to classify sourcetypes for organization in the front end. Case sensitive. Does not affect indexing behaviour. * Defaults to unset. props.conf.example Version The following are example props.conf configurations. Configure properties for your data. To use one or more of these configurations, copy the configuration block into props.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Line merging settings The following example linemerges source data into multi-line events for apache_error sourcetype. [apache_error] SHOULD_LINEMERGE = True Settings for tuning 228

229 The following example limits the amount of characters indexed per event from host::small_events. [host::small_events] TRUNCATE = 256 The following example turns off DATETIME_CONFIG (which can speed up indexing) from any path that ends in /mylogs/*.log. In addition, the default splunk behavior of finding event boundaries via per-event timestamps can't work with NONE, so we disable SHOULD_LINEMERGE, essentially declaring that all events in this file are single-line. [source::.../mylogs/*.log] DATETIME_CONFIG = NONE SHOULD_LINEMERGE = false Timestamp extraction configuration The following example sets Eastern Time Zone if host matches nyc*. [host::nyc*] TZ = US/Eastern The following example uses a custom datetime.xml that has been created and placed in a custom app directory. This sets all events coming in from hosts starting with dharma to use this custom file. [host::dharma*] DATETIME_CONFIG = <etc/apps/custom_time/datetime.xml> Timezone alias configuration The following example uses a custom alias to disambiguate the Australian meanings of EST/EDT TZ_ALIAS = EST=GMT+10:00,EDT=GMT+11:00 The following example gives a sample case wherein, one timezone field is being replaced by/interpreted as another. TZ_ALIAS = EST=AEST,EDT=AEDT Transform configuration The following example creates a search field for host::foo if tied to a stanza in transforms.conf. [host::foo] TRANSFORMS-foo=foobar The following example creates an extracted field for sourcetype access_combined if tied to a stanza in transforms.conf. [eventtype::my_custom_eventtype] REPORT-baz = foobaz The following stanza extracts an ip address from _raw [my_sourcetype] EXTRACT-extract_ip = (?<ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) The following example shows how to configure lookup tables [my_lookuptype] LOOKUP-foo = mylookuptable userid AS myuserid OUTPUT username AS myusername 229

230 The following shows how to specify field aliases FIELDALIAS-foo = user AS myuser id AS myid Sourcetype configuration The following example sets a sourcetype for the file web_access.log for a unix path. [source::.../web_access.log] sourcetype = splunk_web_access The following example sets a sourcetype for the Windows file iis6.log. Note: Backslashes within Windows file paths must be escaped. [source::...\\iis\\iis6.log] sourcetype = iis_access The following example untars syslog events. [syslog] invalid_cause = archive unarchive_cmd = gzip -cd - The following example learns a custom sourcetype and limits the range between different examples with a smaller than default maxdist. [custom_sourcetype] LEARN_MODEL = true maxdist = 30 rule:: and delayedrule:: configuration The following examples create sourcetype rules for custom sourcetypes with regex. [rule::bar_some] sourcetype = source_with_lots_of_bars MORE_THAN_80 = ---- [delayedrule::baz_some] sourcetype = my_sourcetype LESS_THAN_70 = File configuration Binary file configuration The following example eats binary files from the sourcetype "imported_records". [imported_records] NO_BINARY_CHECK = true File checksum configuration The following example checks the entirety of every file in the web_access dir rather than skipping files that appear to be the same. [source::.../web_access/*] CHECK_METHOD = entire_md5 pubsub.conf 다음은 pubsub.conf의 사양 및 예제 파일입니다. 230

231 pubsub.conf.spec Version This file contains possible attributes and values for configuring a client of the PubSub system (broker). To set custom configurations, place a pubsub.conf in $SPLUNK_HOME/etc/system/local/. For examples, see pubsub.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. ****************************************************************** Configure the physical location where deploymentserver is running. This configuration is used by the clients of the pubsub system. ****************************************************************** [pubsub-server:deploymentserver] disabled = <false or true> * defaults to 'false' targeturi = <IP:Port> <hostname:port> direct * specify either the url of a remote server in case the broker is remote, or just the keyword "direct" when broker is in-process. * It is usually a good idea to co-locate the broker and the Deployment Server on the same Splunk. In such a configuration, all * deployment clients would have targeturi set to deploymentserver:port. ****************************************************************** The following section is only relevant to Splunk developers. ****************************************************************** This "direct" configuration is always available, and cannot be overridden. [pubsub-server:direct] disabled = false targeturi = direct [pubsub-server:<logicalname>] * It is possible for any Splunk to be a broker. If you have multiple brokers, assign a logicalname that is used by the clients to refer to it. disabled = <false or true> * defaults to 'false' targeturi = <IP:Port> <hostname:port> direct * The Uri of a Splunk that is being used as a broker. * The keyword "direct" implies that the client is running on the same Splunk instance as the broker. pubsub.conf.example Version [pubsub-server:deploymentserver] disabled=false targeturi=somehost:8089 [pubsub-server:internalbroker] disabled=false 231

232 targeturi=direct restmap.conf 다음은 restmap.conf의 사양 및 예제 파일입니다. restmap.conf.spec Version This file contains possible attribute and value pairs for creating new Representational State Transfer (REST) endpoints. There is a restmap.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a restmap.conf in $SPLUNK_HOME/etc/system/local/. For help, see restmap.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at NOTE: You must register every REST endpoint via this file to make it available. Global stanza [global] * This stanza sets global configurations for all REST endpoints. * Follow this stanza name with any number of the following attribute/value pairs. allowgetauth=[true false] * Allow user/password to be passed as a GET parameter to endpoint services/auth/login. * Setting this to true, while convenient, may result in user/password getting logged as cleartext in Splunk's logs *and* any proxy servers in between. * Defaults to false. pythonhandlerpath=<path> * Path to 'main' python script handler. * Used by the script handler to determine where the actual 'main' script is located. * Typically, you should not need to change this. * Defaults to $SPLUNK_HOME/bin/rest_handler.py. Applicable to all REST stanzas Stanza definitions below may supply additional information for these. [<rest endpoint name>:<endpoint description string>] match=<path> * Specify the URI that calls the handler. * For example if match=/foo, then calls this handler. * NOTE: You must start your path with a /. requireauthentication=[true false] * This optional attribute determines if this endpoint requires authentication. * Defaults to 'true'. authkeystanza=<stanza> * This optional attribute determines the location of the pass4symmkey in the server.conf to be used for endpoint authentication. * Defaults to 'general' stanza. * Only applicable if the requireauthentication is set true. capability=<capabilityname> capability.<post delete get put>=<capabilityname> * Depending on the HTTP method, check capabilities on the authenticated session user. * If you use 'capability.post delete get put,' then the associated method is checked against the authenticated user's role. 232

233 * If you just use 'capability,' then all calls get checked against this capability (regardless of the HTTP method). acceptfrom=<network_acl>... * Lists a set of networks or addresses to allow this endpoint to be accessed from. * This shouldn't be confused with the setting of the same name in the [httpserver] stanza of server.conf which controls whether a host can make HTTP requests at all * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept from anywhere) includeinaccesslog=[true false] * If this is set to false, requests to this endpoint will not appear in splunkd_access.log * Defaults to 'true'. Per-endpoint stanza Specify a handler and other handler-specific settings. The handler is responsible for implementing arbitrary namespace underneath each REST endpoint. [script:<uniquename>] * NOTE: The uniquename must be different for each handler. * Call the specified handler when executing this endpoint. * The following attribute/value pairs support the script handler. scripttype=python * Tell the system what type of script to execute when using this endpoint. * Defaults to python. * Python is currently the only option for scripttype. handler=<script>.<classname> * The name and class name of the file to execute. * The file *must* live in an application's bin subdirectory. * For example, $SPLUNK_HOME/etc/apps/<APPNAME>/bin/TestHandler.py has a class called MyHandler (which, in the case of python must be derived from a base class called 'splunk.rest.baseresthandler'). The tag/value pair for this is: "handler=testhandler.myhandler". xsl=<path to XSL transform file> * Optional. * Perform an optional XSL transform on data returned from the handler. * Only use this if the data is XML. script=<path to a script executable> * Optional. * Execute a script which is *not* derived from 'splunk.rest.baseresthandler'. * Put the path to that script here. * This is rarely used. * Do not use this unless you know what you are doing. output_modes=<csv list> * Specifies which output formats can be requested from this endpoint. * Valid values are: json, xml. * Defaults to xml. 'admin' The built-in handler for the Extensible Administration Interface. Exposes the listed EAI handlers at the given URL. [admin:<uniquename>] match=<partial URL> 233

234 * URL which, when accessed, will display the handlers listed below. members=<csv list> * List of handlers to expose at this URL. * See for a list of all possible handlers. 'admin_external' Register Python handlers for the Extensible Administration Interface. Handler will be exposed via its "uniquename". [admin_external:<uniquename>] handlertype=<script type> * Currently only the value 'python' is valid. handlerfile=<unique filename> * Script to execute. * For bin/myawesomeapphandler.py, specify only myawesomeapphandler.py. handleractions=<comma separated list> * List of EAI actions supported by this handler. * Valid values are: create, edit, list, delete, _reload. Validation stanzas Add stanzas using the following definition to add arg validation to the appropriate EAI handlers. [validation:<handler-name>] <field> = <validation-rule> * <field> is the name of the field whose value would be validated when an object is being saved. * <validation-rule> is an eval expression using the validate() function to evaluate arg correctness and return an error message. If you use a boolean returning function, a generic message is displayed. * <handler-name> is the name of the REST endpoint which this stanza applies to handler-name is what is used to access the handler via /servicesns/<user>/<app/admin/<handler-name>. * For example: * action. .sendresult = validate( isbool('action. .sendresults'), "'action. .sendresults' must be a boolean value"). * NOTE: use ' or $ to enclose field names that contain non alphanumeric characters. 'eai' Settings to alter the behavior of EAI handlers in various ways. These should not need to be edited by users. [eai:<eai handler name>] showindirsvc = [true false] * Whether configurations managed by this handler should be enumerated via the directory service, used by SplunkWeb's "All Configurations" management page. Defaults to false. desc = <human readable string> * Allows for renaming the configuration type of these objects when enumerated via the directory service. Miscellaneous The un-described parameters in these stanzas all operate according to the descriptions listed under "script:", above. These should not need to be edited by users - they are here only to quiet down the configuration checker. [input:...] dynamic = [true false] 234

235 * If set to true, listen on the socket for data. * If false, data is contained within the request body. * Defaults to false. [peerupload:...] path = <directory path> * Path to search through to find configuration bundles from search peers. untar = [true false] * Whether or not a file should be untarred once the transfer is complete. restmap.conf.example Version This file contains example REST endpoint configurations. To use one or more of these configurations, copy the configuration block into restmap.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at The following are default REST configurations. To create your own endpoints, modify the values by following the spec outlined in restmap.conf.spec. ///////////////////////////////////////////////////////////////////////////// global settings ///////////////////////////////////////////////////////////////////////////// [global] indicates if auths are allowed via GET params allowgetauth=false The default handler (assuming that we have PYTHONPATH set) pythonhandlerpath=$splunk_home/bin/rest_handler.py ///////////////////////////////////////////////////////////////////////////// internal C++ handlers NOTE: These are internal Splunk-created endpoints. 3rd party developers can only use script or search can be used as handlers. (Please see restmap.conf.spec for help with configurations.) ///////////////////////////////////////////////////////////////////////////// [SBA:sba] match=/properties capability=get_property_map [asyncsearch:asyncsearch] match=/search capability=search savedsearches.conf 다음은 savedsearches.conf의 사양 및 예제 파일입니다. savedsearches.conf.spec Version This file contains possible attribute/value pairs for saved search entries in savedsearches.conf. You can configure saved searches by creating your own savedsearches.conf. 235

236 There is a default savedsearches.conf in $SPLUNK_HOME/etc/system/default. To set custom configurations, place a savedsearches.conf in $SPLUNK_HOME/etc/system/local/. For examples, see savedsearches.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. ******* The possible attribute/value pairs for savedsearches.conf are: ******* [<stanza name>] * Create a unique stanza name for each saved search. * Follow the stanza name with any number of the following attribute/value pairs. * If you do not specify an attribute, Splunk uses the default. disabled = [0 1] * Disable your search by setting to 1. * If set to 1, this saved search is not visible in Splunk Web. * Defaults to 0. search = <string> * Actual search terms of the saved search. * For example, search = index::sampledata http NOT 500. * Your search can include macro searches for substitution. * To learn more about creating a macro search, search the documentation for "macro search." * Multi-line search strings currently have some limitations. For example use with the search command ' savedseach' does not currently work with multi-line search strings. * Defaults to empty string. dispatchas = [user owner] * When the saved search is dispatched via the "saved/searches/{name}/dispatch" endpoint, this setting controls, what user that search is dispatched as. * This setting is only meaningful for shared saved searches. * When dispatched as user it will be executed as if the requesting user owned the search. * When dispatched as owner it will be executed as if the owner of the search dispatched it no matter what user requested it. * Defaults to owner ******* Scheduling options ******* enablesched = [0 1] * Set this to 1 to run your search on a schedule. * Defaults to 0. cron_schedule = <cron string> * The cron schedule used to execute this search. * For example: */5 * * * * causes the search to execute every 5 minutes. * Cron lets you use standard cron notation to define your scheduled search interval. In particular, cron can accept this type of notation: 00,20,40 * * * *, which runs the search every hour at hh:00, hh:20, hh:40. Along the same lines, a cron of 03,23,43 * * * * runs the search every hour at hh:03, hh:23, hh:43. * Splunk recommends that you schedule your searches so that they are staggered over time. This reduces system load. Running all of them every 20 minutes (*/20) means they would all launch at hh:00 (20, 40) and might slow your system every 20 minutes. * Splunk's cron implementation does not currently support names of months/days. * Defaults to empty string. schedule = <cron-style string> 236

237 * This field is DEPRECATED as of 4.0. * For more information, see the pre-4.0 spec file. * Use cron_schedule to define your scheduled search interval. max_concurrent = <int> * The maximum number of concurrent instances of this search the scheduler is allowed to run. * Defaults to 1. realtime_schedule = [0 1] * Controls the way the scheduler computes the next execution time of a scheduled search. * If this value is set to 1, the scheduler bases its determination of the next scheduled search execution time on the current time. * If this value is set to 0, the scheduler bases its determination of the next scheduled search on the last search execution time. This is called continuous scheduling. * If set to 1, the scheduler might skip some execution periods to make sure that the scheduler is executing the searches running over the most recent time range. * If set to 0, the scheduler never skips scheduled execution periods. However, the execution of the saved search might fall behind depending on the scheduler's load. Use continuous scheduling whenever you enable the summary index option. * The scheduler tries to execute searches that have realtime_schedule set to 1 before it executes searches that have continuous scheduling (realtime_schedule = 0). * Defaults to 1 ******* Notification options ******* counttype = number of events number of hosts number of sources always * Set the type of count for alerting. * Used with relation and quantity (below). * NOTE: If you specify "always," do not set relation or quantity (below). * Defaults to always. relation = greater than less than equal to not equal to drops by rises by * Specifies how to compare against counttype. * Defaults to empty string. quantity = <integer> * Specifies a value for the counttype and relation, to determine the condition under which an alert is triggered by a saved search. * You can think of it as a sentence constructed like this: <counttype> <relation> <quantity>. * For example, "number of events [is] greater than 10" sends an alert when the count of events is larger than by 10. * For example, "number of events drops by 10%" sends an alert when the count of events drops by 10%. * Defaults to an empty string. alert_condition = <search string> * Contains a conditional search that is evaluated against the results of the saved search. Alerts are triggered if the specified search yields a non-empty search result list. * NOTE: If you specify an alert_condition, do not set counttype, relation, or quantity. * Defaults to an empty string. ******* generic action settings. For a comprehensive list of actions and their arguments, refer to alert_actions.conf. ******* action.<action_name> = 0 1 * Indicates whether the action is enabled or disabled for a particular saved search. * The action_name can be: populate_lookup script summary_index * For more about your defined alert actions see alert_actions.conf. * Defaults to an empty string. action.<action_name>.<parameter> = <value> * Overrides an action's parameter (defined in alert_actions.conf) with a new <value> for this saved search only. * Defaults to an empty string. 237

238 ****** Settings for action ****** action. = 0 1 * Enables or disables the action. * Defaults to 0. action. .to = < list> * REQUIRED. This setting is not defined in alert_actions.conf. * Set a comma-delimited list of recipient addresses. * Defaults to empty string. action. .from = < address> * Set an address to use as the sender's address. * Defaults to splunk@<localhost> (or whatever is set in alert_actions.conf). action. .subject = <string> * Set the subject of the delivered to recipients. * Defaults to SplunkAlert-<savedsearchname> (or whatever is set in alert_actions.conf). action. .mailserver = <string> * Set the address of the MTA server to be used to send the s. * Defaults to <LOCALHOST> (or whatever is set in alert_actions.conf). action. .maxresults = <integer> * Set the maximum number of results to be ed. * Any alert-level results threshold greater than this number will be capped at this level. * This value affects all methods of result inclusion by alert: inline, CSV and PDF. * Note that this setting is affected globally by "maxresults" in the [ ] stanza of alert_actions.conf. * Defaults to ****** Settings for script action ****** action.script = 0 1 * Enables or disables the script action. * 1 to enable, 0 to disable. * Defaults to 0 action.script.filename = <script filename> * The filename, with no path, of the shell script to execute. * The script should be located in: $SPLUNK_HOME/bin/scripts/ * For system shell scripts on Unix, or.bat or.cmd on windows, there are no further requirements. * For other types of scripts, the first line should begin with a! marker, followed by a path to the interpreter that will run the script. * Example:!C:\Python27\python.exe * Defaults to empty string. ******* Settings for summary index action ******* action.summary_index = 0 1 * Enables or disables the summary index action. * Defaults to 0. action.summary_index._name = <index> * Specifies the name of the summary index where the results of the scheduled search are saved. * Defaults to summary. action.summary_index.inline = <bool> * Determines whether to execute the summary indexing action as part of the scheduled search. 238

239 * NOTE: This option is considered only if the summary index action is enabled and is always executed (in other words, if counttype = always). * Defaults to true. action.summary_index.<field> = <string> * Specifies a field/value pair to add to every event that gets summary indexed by this search. * You can define multiple field/value pairs for a single summary index search. ******* Settings for lookup table population parameters ******* action.populate_lookup = 0 1 * Enables or disables the lookup population action. * Defaults to 0. action.populate_lookup.dest = <string> * Can be one of the following two options: * A lookup name from transforms.conf. * A path to a lookup.csv file that Splunk should copy the search results to, relative to $SPLUNK_HOME. * NOTE: This path must point to a.csv file in either of the following directories: * etc/system/lookups/ * etc/apps/<app-name>/lookups * NOTE: the destination directories of the above files must already exist * Defaults to empty string. run_on_startup = true false * Toggles whether this search runs when Splunk starts or any edit that changes search related args happen * (which includes: search and dispatch.* args). * If set to true the search is ran as soon as possible during startup or after edit * otherwise the search is ran at the next scheduled time. * We recommend that you set run_on_startup to true for scheduled searches that populate lookup * tables or generate artifacts used by dashboards. * Defaults to false. ******* dispatch search options ******* dispatch.ttl = <integer>[p] * Indicates the time to live (in seconds) for the artifacts of the scheduled search, if no actions are triggered. * If the integer is followed by the letter 'p' Splunk interprets the ttl as a multiple of the scheduled search's execution period (e.g. if the search is scheduled to run hourly and ttl is set to 2p the ttl of the artifacts will be set to 2 hours). * If an action is triggered Splunk changes the ttl to that action's ttl. If multiple actions are triggered, Splunk applies the largest action ttl to the artifacts. To set the action's ttl, refer to alert_actions.conf.spec. * For more info on search's ttl please see limits.conf.spec [search] ttl * Defaults to 2p (that is, 2 x the period of the scheduled search). dispatch.buckets = <integer> * The maximum number of timeline buckets. * Defaults to 0. dispatch.max_count = <integer> * The maximum number of results before finalizing the search. * Defaults to dispatch.max_time = <integer> * Indicates the maximum amount of time (in seconds) before finalizing the search. * Defaults to 0. dispatch.lookups = 1 0 * Enables or disables lookups for this search. * Defaults to 1. dispatch.earliest_time = <time-str> * Specifies the earliest time for this search. Can be a relative or absolute time. 239

240 * If this value is an absolute time, use the dispatch.time_format to format the value. * Defaults to empty string. dispatch.latest_time = <time-str> * Specifies the latest time for this saved search. Can be a relative or absolute time. * If this value is an absolute time, use the dispatch.time_format to format the value. * Defaults to empty string. dispatch.index_earliest= <time-str> * Specifies the earliest index time for this search. Can be a relative or absolute time. * If this value is an absolute time, use the dispatch.time_format to format the value. * Defaults to empty string. dispatch.index_latest= <time-str> * Specifies the latest index time for this saved search. Can be a relative or absolute time. * If this value is an absolute time, use the dispatch.time_format to format the value. * Defaults to empty string. dispatch.time_format = <time format str> * Defines the time format that Splunk uses to specify the earliest and latest time. * Defaults to %FT%T.%Q%:z dispatch.spawn_process = 1 0 * Specifies whether Splunk spawns a new search process when this saved search is executed. * Default is 1. dispatch.auto_cancel = <int> * If specified, the job automatically cancels after this many seconds of inactivity. (0 means never auto-cancel) * Default is 0. dispatch.auto_pause = <int> * If specified, the search job pauses after this many seconds of inactivity. (0 means never auto-pause.) * To restart a paused search job, specify unpause as an action to POST search/jobs/{search_id}/control. * auto_pause only goes into effect once. Unpausing after auto_pause does not put auto_pause into effect again. * Default is 0. dispatch.reduce_freq = <int> * Specifies how frequently Splunk should run the MapReduce reduce phase on accumulated map values. * Defaults to 10. dispatch.rt_backfill = <bool> * Specifies whether to do real-time window backfilling for scheduled real time searches * Defaults to false. dispatch.indexedrealtime = <bool> * Specifies whether to use indexed-realtime mode when doing realtime searches. * Defaults to false restart_on_searchpeer_add = 1 0 * Specifies whether to restart a real-time search managed by the scheduler when a search peer becomes available for this saved search. * NOTE: The peer can be a newly added peer or a peer that has been down and has become available. * Defaults to 1. ******* auto summarization options ******* auto_summarize = <bool> * Whether the scheduler should ensure that the data for this search is automatically summarized * Defaults to false. auto_summarize.command = <string> * A search template to be used to construct the auto summarization for this search. * DO NOT change unles you know what you're doing auto_summarize.timespan = <time-specifier> (, <time-specifier>)* * Comma delimite list of time ranges that each summarized chunk should span. This comprises the list * of available granularity levels for which summaries would be available. For example a timechart over * the last month whose granuality is at the day level should set this to 1d. If you're going to need the * same data summarized at the hour level because you need to have weekly charts then use: 1h,1d 240

241 auto_summarize.cron_schedule = <cron-string> * Cron schedule to be used to probe/generate the summaries for this search auto_summarize.dispatch.<arg-name> = <string> * Any dispatch.* options that need to be overridden when running the summary search. auto_summarize.suspend_period = <time-specifier> * Amount of time to suspend summarization of this search if the summarization is deemed unhelpful * Defaults to 24h auto_summarize.max_summary_size = <unsigned int> * The minimum summary size when to start testing it's helpfulness * Defaults to (5MB) auto_summarize.max_summary_ratio = <positive float> * The maximum ratio of summary_size/bucket_size when to stop summarization and deem it unhelpful for a bucket * NOTE: the test is only performed if the summary size is larger than auto_summarize.max_summary_size * Defaults to: 0.1 auto_summarize.max_disabled_buckets = <unsigned int> * The maximum number of buckets with the suspended summarization before the summarization search is completely * stopped and the summarization of the search is suspended for auto_summarize.suspend_period * Defaults to: 2 auto_summarize.max_time = <unsigned in> * The maximum amount of time that the summary search is allowed to run. Note that this is an approximate time * and the summarize search will be stopped at clean bucket boundaries. * Defaults to: 3600 auto_summarize.hash = <string> auto_summarize.normalized_hash = <string> * These are auto generated settings. ******* alert suppression/severity/expiration/tracking/viewing settings ******* alert.suppress = 0 1 * Specifies whether alert suppression is enabled for this scheduled search. * Defaults to 0. alert.suppress.period = <time-specifier> * Sets the suppression period. Use [number][time-unit] to specify a time. * For example: 60 = 60 seconds, 1m = 1 minute, 1h = 60 minutes = 1 hour etc * Honored if and only if alert.suppress = 1 * Defaults to empty string. alert.suppress.fields = <comma-delimited-field-list> * List of fields to use when suppressing per-result alerts. This field *must* be specified * if the digest mode is disabled and suppression is enabled. * Defaults to empty string. alert.severity = <int> * Sets the alert severity level. * Valid values are: 1-debug, 2-info, 3-warn, 4-error, 5-severe, 6-fatal * Defaults to 3. alert.expires = <time-specifier> * Sets the period of time to show the alert in the dashboard. Use [number][time-unit] to specify a time. * For example: 60 = 60 seconds, 1m = 1 minute, 1h = 60 minutes = 1 hour etc * Defaults to 24h. alert.digest_mode = true false * Specifies whether Splunk applies the alert actions to the entire result set or on each * individual result. * Defaults to true. alert.track = true false auto * Specifies whether to track the actions triggered by this scheduled search. * auto - determine whether to track or not based on the tracking setting of each action, * do not track scheduled searches that always trigger actions. * true - force alert tracking. 241

242 * false - disable alert tracking for this search. * Defaults to auto. alert.display_view = <string> * Name of the UI view where the ed link for per result alerts should point to. * If not specified, the value of request.ui_dispatch_app will be used, if that * is missing then "search" will be used * Defaults to empty string ******* UI-specific settings ******* displayview =<string> * Defines the default UI view name (not label) in which to load the results. * Accessibility is subject to the user having sufficient permissions. * Defaults to empty string. vsid = <string> * Defines the viewstate id associated with the UI view listed in 'displayview'. * Must match up to a stanza in viewstates.conf. * Defaults to empty string. is_visible = true false * Specifies whether this saved search should be listed in the visible saved search list. * Defaults to true. description = <string> * Human-readable description of this saved search. * Defaults to empty string. request.ui_dispatch_app = <string> * Specifies a field used by Splunk UI to denote the app this search should be dispatched in. * Defaults to empty string. request.ui_dispatch_view = <string> * Specifies a field used by Splunk UI to denote the view this search should be displayed in. * Defaults to empty string. ****** Display Formatting Options ****** General options display.general.enablepreview = 0 1 display.general.type = [events statistics visualizations] display.general.timerangepicker.show = 0 1 display.general.migratedfromviewstate = 0 1 Event options display.events.fields = [<string>(, <string>)*] display.events.type = [raw list table] display.events.rownumbers = 0 1 display.events.maxlines = <int> display.events.raw.drilldown = [inner outer full none] display.events.list.drilldown = [inner outer full none] display.events.list.wrap = 0 1 display.events.table.drilldown = 0 1 display.events.table.wrap = 0 1 Statistics options display.statistics.rownumbers = 0 1 display.statistics.wrap = 0 1 display.statistics.overlay = [none heatmap highlow] display.statistics.drilldown = [row cell none] Visualization options display.visualizations.show = 0 1 display.visualizations.type = [charting singlevalue mapping] display.visualizations.chartheight = <int> display.visualizations.charting.chart = [line area column bar pie scatter bubble radialgauge fillergauge markergauge] 242

243 display.visualizations.charting.chart.stackmode = [default stacked stacked100] display.visualizations.charting.chart.nullvaluemode = [gaps zero connect] display.visualizations.charting.chart.overlayfields = <string> display.visualizations.charting.drilldown = [all none] display.visualizations.charting.chart.style = [minimal shiny] display.visualizations.charting.layout.splitseries = 0 1 display.visualizations.charting.legend.placement = [right bottom top left none] display.visualizations.charting.legend.labelstyle.overflowmode = [ellipsisend ellipsismiddle ellipsisstart] display.visualizations.charting.axistitlex.text = <string> display.visualizations.charting.axistitley.text = <string> display.visualizations.charting.axistitley2.text = <string> display.visualizations.charting.axistitlex.visibility = [visible collapsed] display.visualizations.charting.axistitley.visibility = [visible collapsed] display.visualizations.charting.axistitley2.visibility = [visible collapsed] display.visualizations.charting.axisx.scale = linear log display.visualizations.charting.axisy.scale = linear log display.visualizations.charting.axisy2.scale = linear log inherit display.visualizations.charting.axislabelsx.majorlabelstyle.overflowmode = [ellipsismiddle ellipsisnone] display.visualizations.charting.axislabelsx.majorlabelstyle.rotation = [ ] display.visualizations.charting.axislabelsx.majorunit = <float> auto display.visualizations.charting.axislabelsy.majorunit = <float> auto display.visualizations.charting.axislabelsy2.majorunit = <float> auto display.visualizations.charting.axisx.minimumnumber = <float> auto display.visualizations.charting.axisy.minimumnumber = <float> auto display.visualizations.charting.axisy2.minimumnumber = <float> auto display.visualizations.charting.axisx.maximumnumber = <float> auto display.visualizations.charting.axisy.maximumnumber = <float> auto display.visualizations.charting.axisy2.maximumnumber = <float> auto display.visualizations.charting.axisy2.enabled = 0 1 display.visualizations.charting.chart.slicecollapsingthreshold = <float> display.visualizations.charting.gaugecolors = [<hex>(, <hex>)*] display.visualizations.charting.chart.rangevalues = [<string>(, <string>)*] display.visualizations.charting.chart.bubblemaximumsize = <int> display.visualizations.charting.chart.bubbleminimumsize = <int> display.visualizations.charting.chart.bubblesizeby = [area diameter] display.visualizations.singlevalue.beforelabel = <string> display.visualizations.singlevalue.afterlabel = <string> display.visualizations.singlevalue.underlabel = <string> display.visualizations.mapheight = <int> display.visualizations.mapping.drilldown = [all none] display.visualizations.mapping.map.center = (<float>,<float>) display.visualizations.mapping.map.zoom = <int> display.visualizations.mapping.markerlayer.markeropacity = <float> display.visualizations.mapping.markerlayer.markerminsize = <int> display.visualizations.mapping.markerlayer.markermaxsize = <int> display.visualizations.mapping.data.maxclusters = <int> display.visualizations.mapping.tilelayer.url = <string> display.visualizations.mapping.tilelayer.minzoom = <int> display.visualizations.mapping.tilelayer.maxzoom = <int> Patterns options display.page.search.patterns.sensitivity = <float> Page options display.page.search.mode = [fast smart verbose] display.page.search.timeline.format = [hidden compact full] display.page.search.timeline.scale = [linear log] display.page.search.showfields = 0 1 display.page.search.tab = [events statistics visualizations patterns] Deprecated display.page.pivot.datamodel = <string> ******* Other settings ******* embed.enabled = 0 1 * Specifies whether a saved search is shared for access with a guestpass. * Search artifacts of a search can be viewed via a guestpass only if: * A token has been generated that is associated with this saved search. The token is asociated with a particular user and app context. * The user to whom the token belongs has permissions to view that search. 243

244 * The saved search has been scheduled and there are artifacts available. Only artifacts are available via guestpass: we never dispatch a search. * The save search is not disabled, it is scheduled, it is not real-time, and it is not an alert. ******* deprecated settings ******* sendresults = <bool> * use action. .sendresult action_rss = <bool> * use action.rss action_ = <string> * use action. and action. .to role = <string> * see saved search permissions userid = <string> * see saved search permissions query = <string> * use search nextrun = <int> * not used anymore, the scheduler maintains this info internally qualifiedsearch = <string> * not used anymore, Splunk computes this value during runtime savedsearches.conf.example Version This file contains example saved searches and alerts. To use one or more of these configurations, copy the configuration block into savedsearches.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at The following searches are example searches. To create your own search, modify the values by following the spec outlined in savedsearches.conf.spec. [Daily indexing volume by server] search = index=_internal todaysbytesindexed LicenseManager-Audit NOT source=*web_service.log NOT source=*web_access.log eval Daily _Indexing_Volume_in_MBs = todaysbytesindexed/1024/1024 timechart avg(daily_indexing_volume_in_mbs) by host dispatch.earliest_time = -7d [Errors in the last 24 hours] search = error OR failed OR severe OR ( sourcetype=access_* ( 404 OR 500 OR 503 ) ) dispatch.earliest_time = -1d [Errors in the last hour] search = error OR failed OR severe OR ( sourcetype=access_* ( 404 OR 500 OR 503 ) ) dispatch.earliest_time = -1h [KB indexed per hour last 24 hours] search = index=_internal metrics group=per_index_thruput NOT debug NOT sourcetype=splunk_web_access timechart fixedrange=t span=1h sum(kb) rename sum(kb) as totalkb dispatch.earliest_time = -1d 244

245 [Messages by minute last 3 hours] search = index=_internal eps "group=per_source_thruput" NOT filetracker eval events=eps*kb/kbps timechart fixedrange=t span=1m s um(events) by series dispatch.earliest_time = -3h [Splunk errors last 24 hours] search = index=_internal " error " NOT debug source=*/splunkd.log* dispatch.earliest_time = -24h searchbnf.conf 다음은 searchbnf.conf의 사양 및 예제 파일입니다. searchbnf.conf.spec Version This file contain descriptions of stanzas and attribute/value pairs for configuring search-assistant via searchbnf.conf There is a searchbnf.conf in $SPLUNK_HOME/etc/system/default/. It should not be modified. If your application has its own custom python search commands, your application can include its own searchbnf.conf to describe the commands to the search-assistant. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<search-commandname>-command] * This stanza enables properties for a given <search-command>. * A searchbnf.conf file can contain multiple stanzas for any number of commands. * Follow this stanza name with any number of the following attribute/value pairs. * If you do not set an attribute for a given <spec>, the default is used. The default values are empty. * An example stanza name might be "geocode-command", for a "geocode" command. * Search command stanzas can refer to definitions defined in others stanzas, and they do not require "-command", appended to them. For example: [geocode-command] syntax = geocode <geocode-option>*... [geocode-option] syntax = (maxcount=<int>) (maxhops=<int>)... ****************************************************************************** The possible attributes/value pairs for searchbnf.conf ****************************************************************************** 245

246 SYNTAX = <string> * Describes the syntax of the search command. See the head of searchbnf.conf for details. * Required SIMPLESYNTAX = <string> * Optional simpler version of the syntax to make it easier to understand at the expense of completeness. Typically it removes rarely used options or alternate ways of saying the same thing. * For example, a search command might accept values such as "m min mins minute minutes", but that would unnecessarily clutter the syntax description for the user. In this can, the simplesyntax can just pick the one (e.g., "minute"). ALIAS = <commands list> * Alternative names for the search command. This further cleans up the syntax so the user does not have to know that 'savedsearch' can also be called by 'macro' or 'savedsplunk'. DESCRIPTION = <string> * Detailed text description of search command. Description can continue on the next line if the line ends in "\" * Required SHORTDESC = <string> * A short description of the search command. The full DESCRIPTION may take up too much screen real-estate for the search assistant. * Required EXAMPLE = <string> COMMENT = <string> * 'example' should list out a helpful example of using the search command, and 'comment' should describe that example. * 'example' and 'comment' can be appended with matching indexes to allow multiple examples and corresponding comments. * For example: example2 = geocode maxcount=4 command2 = run geocode on up to four values example3 = geocode maxcount=-1 comment3 = run geocode on all values USAGE = public private deprecated * Determines if a command is public, private, depreciated. The search assistant only operates on public commands. * Required TAGS = <tags list> * List of tags that describe this search command. Used to find commands when the use enters a synonym (e.g. "graph" -> "chart") RELATED = <commands list> * List of related commands to help user when using one command to learn about others. ****************************************************************************** Optional attributes primarily used internally at Splunk ****************************************************************************** maintainer, appears-in, note, supports-multivalue, appears-in searchbnf.conf.example Version The following are example stanzas for searchbnf.conf configurations. 246

247 selfjoin [selfjoin-command] syntax = selfjoin (<selfjoin-options>)* <field-list> shortdesc = Join results with itself. description = Join results with itself. Must specify at least one field to join on. usage = public example1 = selfjoin id comment1 = Joins results with itself on 'id' field. related = join tags = join combine unite [selfjoin-options] syntax = overwrite=<bool> max=<int> keepsingle=<int> description = The selfjoin joins each result with other results that\ have the same value for the join fields. 'overwrite' controls if\ fields from these 'other' results should overwrite fields of the\ result used as the basis for the join (default=true). max indicates\ the maximum number of 'other' results each main result can join with.\ (default = 1, 0 means no limit). 'keepsingle' controls whether or not\ results with a unique value for the join fields (and thus no other\ results to join with) should be retained. (default = false) segmenters.conf 다음은 segmenters.conf의 사양 및 예제 파일입니다. segmenters.conf.spec Version This file contains possible attribute/value pairs for configuring segmentation of events in segementers.conf. There is a default segmenters.conf in $SPLUNK_HOME/etc/system/default. To set custom configurations, place a segmenters.conf in $SPLUNK_HOME/etc/system/local/. For examples, see segmenters.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<SegmenterName>] * Name your stanza. * Follow this stanza name with any number of the following attribute/value pairs. * If you don't specify an attribute/value pair, Splunk will use the default. MAJOR = <space separated list of breaking characters> * Set major breakers. * Major breakers are words, phrases or terms in your data that are surrounded by set breaking characters. * By default, major breakers are set to most characters and blank spaces. * Typically, major breakers are single characters. * Default is [ ] < > ( ) { }! ;, ' " * \n \r \s \t &? + %21 %26 %2526 %3B %7C %20 %2B %3D -- %2520 %5D %5B %3A %0A %2C %28 %29 * Please note: \s represents a space; \n, a newline; \r, a carriage return; and \t, a tab. MINOR = <space separated list of strings> * Set minor breakers. 247

248 * In addition to the segments specified by the major breakers, for each minor breaker found, Splunk indexes the token from the last major breaker to the current minor breaker and from the last minor breaker to the current minor breaker. * Default is / : - $ % \\ _ INTERMEDIATE_MAJORS = true false * Set this to "true" if you want an IP address to appear in typeahead as a, a.b, a.b.c, a.b.c.d * The typical performance hit by setting to "true" is 30%. * Default is "false". FILTER = <regular expression> * If set, segmentation will only take place if the regular expression matches. * Furthermore, segmentation will only take place on the first group of the matching regex. * Default is empty. LOOKAHEAD = <integer> * Set how far into a given event (in characters) Splunk segments. * LOOKAHEAD applied after any FILTER rules. * To disable segmentation, set to 0. * Defaults to -1 (read the whole event). MINOR_LEN = <integer> * Specify how long a minor token can be. * Longer minor tokens are discarded without prejudice. * Defaults to -1. MAJOR_LEN = <integer> * Specify how long a major token can be. * Longer major tokens are discarded without prejudice. * Defaults to -1. MINOR_COUNT = <integer> * Specify how many minor segments to create per event. * After the specified number of minor tokens have been created, later ones are discarded without prejudice. * Defaults to -1. MAJOR_COUNT = <integer> * Specify how many major segments are created per event. * After the specified number of major segments have been created, later ones are discarded without prejudice. * Default to -1. segmenters.conf.example Version The following are examples of segmentation configurations. To use one or more of these configurations, copy the configuration block into segmenters.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Example of a segmenter that doesn't index the date as segments in syslog data: [syslog] FILTER = ^.*?\d\d:\d\d:\d\d\s+\s+\s+(.*)$ Example of a segmenter that only indexes the first 256b of events: [limited-reach] LOOKAHEAD = 256 Example of a segmenter that only indexes the first line of an event: 248

249 [first-line] FILTER = ^(.*?)(\n $) Turn segmentation off completely: [no-segmentation] LOOKAHEAD = 0 server.conf 다음은 server.conf의 사양 및 예제 파일입니다. server.conf.spec Version This file contains the set of attributes and values you can use to configure server options in server.conf. There is a server.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a server.conf in $SPLUNK_HOME/etc/system/local/. For examples, see server.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. General Server Configuration [general] servername = <ASCII string> * The name used to identify this Splunk instance for features such as distributed search. * Defaults to <hostname>-<user running splunk>. * May not be an empty string * May contain environment variables * After any environment variables have been expanded, the server name (if not an IPv6 address) can only contain letters, numbers, underscores, dots, and dashes; and it must start with a letter, number, or an underscore. hostnameoption = <ASCII string> * The option used to specify the detail in the server name used to identify this Splunk instance. * Can be one of fullyqualifiedname, clustername, shortname * Is applicable to Windows only * May not be an empty string sessiontimeout = <nonnegative integer>[smhd] * The amount of time before a user session times out, expressed as a search-like time range * Examples include '24h' (24 hours), '3d' (3 days), '7200s' (7200 seconds, or two hours) * Defaults to '1h' (1 hour) trustedip = <IP address> * All logins from this IP address are trusted, meaning password is no longer required * Only set this if you are using Single Sign On (SSO) allowremotelogin = always never requiresetpassword * Controls remote management by restricting general login. Note that this does not apply to trusted SSO logins from trustedip. * If 'always', enables authentication so that all remote login attempts are allowed. * If 'never', only local logins to splunkd will be allowed. Note that this will still allow remote management through splunkweb if splunkweb is on the same server. * If 'requiresetpassword' (default): * In the free license, remote login is disabled. * In the pro license, remote login is only disabled for "admin" user if default password of "admin" has not been changed. access_logging_for_phonehome = true false * Enables/disables logging to splunkd_access.log for client phonehomes * defaults to true (logging enabled) hangup_after_phonehome = true false * Controls whether or not the (deployment) server hangs up the connection after the phonehome is done. * By default we use persistent HTTP 1.1 connections with the server to handle phonehomes. This may show higher memory usage for a large number of clients. * In case we have more than maximum concurrent tcp connection number of deployment clients, persistent connections don't help with the reuse of connections anyway, so setting this to false helps bring down memory usage. * defaults to false (persistent connections for phonehome) pass4symmkey = <passphrase string> * Authenticates traffic between: * License master and its license slaves. * Members of a cluster; see Note 1 below. * Deployment server (DS) and its deployment clients (DCs); see Note 2 below. * Note 1: Clustering may override the passphrase specified here, in the [clustering] stanza. A clustering searchhead connecting to multiple masters may further override in the [clustermaster:stanza1] stanza. * Note 2: By default, DS- DCs passphrase auth is disabled. To enable DS-DCs passphrase auth, you must *also* add the following line to the [broker:broker] stanza in restmap.conf: requireauthentication = true * In all scenarios, *every* node involved must set the same passphrase in the same stanza(s) (i.e. [general] and/or [clustering]); otherwise, respective communication (licensing and deployment in case of [general] stanza, clustering in case of [clustering] stanza) will not proceed. listenonipv6 = no yes only * By default, splunkd will listen for incoming connections (both REST and TCP inputs) using IPv4 only * To enable IPv6 support in splunkd, set this to 'yes'. splunkd will simultaneously listen for connections on both IPv4 and IPv6 * To disable IPv4 entirely, set this to 'only', which will cause splunkd to exclusively accept connections over IPv6. You will probably also need to change mgmthostport in web.conf (use '[::1]' instead of ' ') * Note that any setting of SPLUNK_BINDIP in your environment or splunklaunch.conf will override this value. In that case splunkd will listen on the exact address specified. connectusingipversion = auto 4-first 6-first 4-only 6-only * When making outbound TCP connections (for forwarding eventdata, making distributed search requests, etc) this controls whether the connections will be made via IPv4 or IPv6. * If a host is available over both IPv4 and IPv6 and this is set to '4-first', then we will connect over IPv4 first and fallback to IPv6 if the connection fails. * If it is set to '6-first' then splunkd will try IPv6 first and fallback to IPv4 on failure * If this is set to '4-only' then splunkd will only attempt to make connections over IPv4. * Likewise, if this is set to '6-only', then splunkd will only attempt to connect to the IPv6 address. * The 249

250 default value of 'auto' will select a reasonable value based on listenonipv6 setting If that value is set to 'no' it will act like '4-only'. If it is set to 'yes' it will act like '6-first' and if it is set to 'only' it will act like '6-only'. * Note that connections to literal addresses are unaffected by this. For example, if a forwarder is configured to connect to " " the connection will be made over IPv4 regardless of this setting. guid = <globally unique identifier for this instance> * This setting now (as of 5.0) belongs in the [general] stanza of SPLUNK_HOME/etc/instance.cfg file; please see specfile of instance.cfg for more information. usehttpservercompression = true false * Whether splunkd HTTP server should support gzip content encoding. For more info on how content encoding works, see (section 14.3). * Defaults to true. defaulthttpservercompressionlevel = <integer> * If usehttpservercompression is enabled, this setting constrols the compression "level" we attempt * This number must be in the range 1 through 9 * Higher numbers produce smaller compressed results but require more CPU usage * The default value of 6 is appropriate for most environments skiphttpcompressionacl = <network_acl> * Lists a set of networks or addresses to skip compressing data for. These are addresses that are considered so close that network speed is never an issue, so any CPU time spent compressing a response is wasteful. * Note that the server may still respond with compressed data if it already has a compressed version of the data available. * These rules are separated by commas or spaces * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to negate their meaning. * Defaults to localhost addresses. site = <site-id> * Specifies the site that this splunk instance belongs to when multisite is enabled. * Valid values for site-id include site1 to site63 usehttpclientcompression = true false on-http on-https * Whether gzip compression should be supported when Splunkd acts as a client (including distributed searches). Note that in order for the content to be compressed, the HTTP server that the client is connecting to should also support compression. * If the connection is being made over https and useclientsslcompression=true (see below), then setting this option to true would result in double compression work without much compression gain. It is recommended that this value be set to on-http (or to true, and useclientsslcompression to false). * Defaults to false. embedsecret = <string> * When using report embedding, normally the generated URLs can only be used on the search head they were generated on * If "embedsecret" is set, then the token in the URL will be encrypted with this key. Then other search heads with the exact same setting can also use the same URL. * This is needed if you want to use report embedding across multiple nodes on a search head pool. instancetype = <string> * Should not be modified by users. * Informs components (such as the SplunkWeb Manager section) which environment Splunk is running in, to allow for more customized behaviors. * Defaults to "splunk", meaning no special behaviors. SSL Configuration details [sslconfig] * Set SSL for communications on Splunk back-end under this stanza name. * NOTE: To set SSL (eg HTTPS) for Splunk Web and the browser, use web.conf. * Follow this stanza name with any number of the following attribute/value pairs. * If you do not specify an entry for each attribute, Splunk will use the default value. enablesplunkdssl = true false * Enables/disables SSL on the splunkd management port (8089) and KV store port (8191). * Defaults to true. * Note: Running splunkd without SSL is not generally recommended. * Distributed search will often perform better with SSL enabled. useclientsslcompression = true false * Turns on HTTP client compression. * Server-side compression is turned on by default; setting this on the client side enables compression between server and client. * Enabling this potentially gives you much faster distributed searches across multiple Splunk instances. * Defaults to true. usesplunkdclientsslcompression = true false * Controls whether SSL compression would be used when splunkd is acting as an HTTP client, usually during certificate exchange, bundle replication, remote calls etc. * NOTE: this setting is effective if, and only if, useclientsslcompression is set to true * NOTE: splunkd is not involved in data transfer in distributed search, the search in a separate process is. * Defaults to true. sslversions = <versions_list> * Comma-separated list of SSL versions to support * The versions available are "ssl2", "ssl3", "tls1.0", "tls1.1", and "tls1.2" * The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer * If a version is prefixed with "-" it is removed from the list * When configured in FIPS mode ssl2 and ssl3 are always disabled regardless of this configuration * Defaults to "*,-ssl2". (anything newer than SSLv2) supportsslv3only = true false * DEPRECATED. SSLv2 is now always disabled by default. The exact set of SSL versions allowed is now configurable via the "sslversions" setting above sslverifyservercert = true false * Used by distributed search: when making a search request to another server in the search cluster. * Used by distributed deployment clients: when polling a deployment server. * If this is set to true, you should make sure that the server that is being connected to is a valid one (authenticated). Both the common name and the alternate name of the server are then checked for a match if they are specified in this configuration file. A certificiate is considered verified if either is matched. * Default is false. sslcommonnametocheck = <commonname> * If this value is set, and 'sslverifyservercert' is set to true, splunkd will limit most outbound HTTPS connections to hosts which use a cert with this common name. * 'sslcommonnamelist' is a multivalue extension of this setting, certs which match 'sslcommonnamelist' or 'sslcommonnametocheck' will be accepted. * The most important scenario is distributed search. * This feature does not work with the deployment server and client communication over SSL. * Optional. Defaults to no common name checking. sslcommonnamelist = <commonname1>, <commonname2>,... * If this value is set, and 'sslverifyservercert' is set to true, splunkd will limit most outbound HTTPS connections to hosts which use a cert with one of the listed common names. * The most important scenario is distributed search. * Optional. Defaults to no common name checking. sslaltnametocheck = <alternatename1>, <alternatename2>,... * If this value is set, and 'sslverifyservercert' is set to true, splunkd will also be willing to verify certificates which have a so-called "Subject Alternate Name" that matches any of the alternate names in this list. * Subject Alternate Names are effectively extended descriptive fields in SSL certs beyond the commonname. A common practice for HTTPS certs is to use these values to store additional valid hostnames or domains where the cert should be considered valid. * Accepts a comma-separated list of Subject Alternate Names to consider valid. * Items in this list are never validated against the SSL Common Name. * This feature does not work with the deployment server and client communication over SSL. * Optional. Defaults to no alternate name checking requireclientcert = true false * Requires that any HTTPS 250

251 client that connects to splunkd internal HTTPS server has a certificate that was signed by our CA (certificate authority). * Used by distributed search: Splunk indexing instances must be authenticated to connect to another splunk indexing instance. * Used by distributed deployment: the deployment server requires that deployment clients are authenticated before allowing them to poll for new configurations/applications. * If true, a client can connect ONLY if a certificate created by our certificate authority was used on that client. * Default is false. ciphersuite = <cipher suite string> * If set, Splunk uses the specified cipher string for the HTTP server. * If not set, Splunk uses the default cipher string provided by OpenSSL. This is used to ensure that the server does not accept connections using weak encryption protocols. ecdhcurvename = <string> * ECDH curve to use for ECDH key negotiation * We only support named curves specified by their SHORT name. * The list of valid named curves by their short/long names * can be obtained by executing this command: * $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves * Default is empty string. sslkeysfile = <filename> * Server certificate file. * Certificates are auto-generated by splunkd upon starting Splunk. * You may replace the default cert with your own PEM format file. * Certs are stored in capath (see below). * Default is server.pem. sslkeysfilepassword = <password> * Server certificate password. * Default is password. cacertfile = <filename> * Public key of the signing authority. * Default is cacert.pem. capath = <path> * Path where all these certs are stored. * Default is $SPLUNK_HOME/etc/auth. certcreatescript = <script name> * Creation script for generating certs on startup of Splunk. sendstricttransportsecurityheader = true false * If set to true, the REST interface will send a "Strict-Transport-Security" header with all responses to requests made over SSL. * This can help avoid a client being tricked later by a Man-In-The-Middle attack to accept a non-ssl request. However, this requires a commitment that no non-ssl web hosts will ever be run on this hostname on any port. For example, if splunkweb is in default non-ssl mode this can break the ability of browser to connect to it. Enable with caution. * Defaults to false allowsslcompression = true false * If set to true, the server will allow clients to negotiate SSL-layer data compression. * Defaults to true. allowsslrenegotiation = true false * In the SSL protocol, a client may request renegotiation of the connection settings from time to time. * Setting this to false causes the server to reject all renegotiation attempts, breaking the connection. This limits the amount of CPU a single TCP connection can use, but it can cause connectivity problems especially for long-lived connections. * Defaults to true. Splunkd HTTP server configuration [httpserver] * Set standalone HTTP settings for Splunk under this stanza name. * Follow this stanza name with any number of the following attribute/value pairs. * If you do not specify an entry for each attribute, Splunk uses the default value. atomfeedstylesheet = <string> * Defines the stylesheet relative URL to apply to default Atom feeds. * Set to 'none' to stop writing out xsl-stylesheet directive. * Defaults to /static/atom.xsl. max-age = <nonnegative integer> * Set the maximum time (in seconds) to cache a static asset served off of the '/static' directory. * This value is passed along in the 'Cache-Control' HTTP header. * Defaults to follow-symlinks = true false * Toggle whether static file handler (serving the '/static' directory) follow filesystem symlinks when serving files. * Defaults to false. disabledefaultport = true false * If true, turns off listening on the splunkd management port (8089 by default) * This setting is not recommended: * This is the general communication path to splunkd. If it is disabled, there is no way to communicate with a running splunk. * This means many command line splunk invocations cannot function, splunkweb cannot function, the REST interface cannot function, etc. * If you choose to disable the port anyway, understand that you are selecting reduced Splunk functionality. * Default value is 'false'. acceptfrom = <network_acl>... * Lists a set of networks or addresses to accept data from. These rules are separated by commas or spaces * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept from anywhere) streaminwritetimeout = <positive number> * When uploading data to http server, if http server is unable to write data to * receiver for configured streaminwritetimeout seconds, it aborts write operation. * Defaults to 5 seconds. max_content_length = <int> * Measured in bytes * HTTP requests over this size will rejected. * Exists to avoid allocating an unreasonable amount of memory from web requests * Defaulted to or 800MB * In environments where indexers have enormous amounts of RAM, this number can be reasonably increased to handle large quantities of bundle data. maxthreads = <int> * Number of threads that can be used by active HTTP transactions. This can be limited to constrain resource usage. * If set to 0 (the default) a limit will be automatically picked based on estimated server capacity. * If set to a negative number, no limit will be enforced. maxsockets = <int> * Number of simultaneous HTTP connections that we accept simultaneously. This can be limited to constrain resource usage. * If set to 0 (the default) a limit will be automatically picked based on estimated server capacity. * If set to a negative number, no limit will be enforced. forcehttp10 = auto never always * When set to "always", the REST HTTP server will not use some HTTP 1.1 features such as persistent connections or chunked transfer encoding. * When set to "auto" it will do this only if the client sent no User-Agent header, or if the user agent is known to have bugs in its HTTP/1.1 support. * When set to "never" it always will allow HTTP 1.1, even to clients it suspects may be buggy. * Defaults to "auto" crossoriginsharingpolicy = <origin_acl>... * List of HTTP Origins to return Access-Control-Allow-* (CORS) headers for * These headers tell browsers that we trust web applications at those sites to make requests to the REST interface * The origin is passed as a URL without a path component (for example " * This setting can take a list of acceptable origins, separated by spaces and/or commas * Each origin can also contain wildcards for any part. Examples: *://app.example.com:* (either HTTP or HTTPS on any port) (any host under example.com, including example.com itself) * An address can be prefixed with a '!' to negate the match, with the first matching origin taking precedence. For example, "!*://evil.example.com:* *://*.example.com:*" to not avoid matching one host in a domain * A single "*" can also be used to match all origins * By default the list is empty x_frame_options_sameorigin = true false * adds a X-Frame-Options header set to "SAMEORIGIN" to every response served by splunkd * Defaults to true allowembedtokenauth = true false * If set to false, splunkd will not allow any access to artifacts that previously had been explicitly shared to anonymous users. * This effectively disables all use of 251

252 the "embed" feature. * Defaults to true cliloginbanner = <string> * Sets a message which will be added to the HTTP reply headers of requests for authentication, and to the "server/info" endpoint * This will be printed by the Splunk CLI before it prompts for authentication credentials. This can be used to print access policy information. * If this string starts with a '"' character, it is treated as a CSV-style list with each line comprising a line of the message. For example: "Line 1","Line 2","Line 3" * Defaults to empty (no message) allowbasicauth = true false * Allows clients to make authenticated requests to the splunk server using "HTTP Basic" authentication in addition to the normal "authtoken" system * This is useful for programmatic access to REST endpoints and for accessing the REST API from a web browser. It is not required for the UI or CLI. * Defaults to true basicauthrealm = <string> * When using "HTTP Basic" authenitcation, the 'realm' is a human-readable string describing the server. Typically, a web browser will present this string as part of its dialog box when asking for the username and password. * This can be used to display a short message describing the server and/or its access policy. * Defaults to "/splunk" allowcookieauth = true false * Allows clients to request an HTTP cookie from the /services/server/auth endpoint which can then be used to authenticate future requests * Defaults to true cookieauthhttponly = true false * When using cookie based authentication, mark returned cookies with the "httponly" flag to tell the client not to allow javascript code to access its value * Defaults to true * NOTE: has no effect if allowcookieauth=false cookieauthsecure = true false * When using cookie based authentication, mark returned cookies with the "secure" flag to tell the client never to send it over an unencrypted HTTP channel * Defaults to true * NOTE: has no effect if allowcookieauth=false OR the splunkd REST interface has SSL disabled dedicatediothreads = <int> * If set to zero, HTTP I/O will be performed in the same thread that accepted the TCP connection. * If set set to a non-zero value, separate threads will be run to handle the HTTP I/O, including SSL encryption. * Defaults to "0" * Typically this does not need to be changed. For most usage scenarios using the same the thread offers the best performance. Splunkd HTTPServer listener configuration [httpserverlistener:<ip>:<port>] * Enable the splunkd http server to listen on a network interface (NIC) specified by <ip> and a port number specified by <port>. If you leave <ip> blank (but still include the ':'), splunkd will listen on the kernel picked NIC using port <port>. ssl = true false * Toggle whether this listening ip:port will use SSL or not. * Default value is 'true'. listenonipv6 = no yes only * Toggle whether this listening ip:port will listen on IPv4, IPv6, or both * If not present, the setting in the [general] stanza will be used acceptfrom = <network_acl>... * Lists a set of networks or addresses to accept data from. These rules are separated by commas or spaces * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to the setting in the [httpserver] stanza above Static file handler MIME-type map [mimetypeextension-map] * Map filename extensions to MIME type for files served from the static file handler under this stanza name. <file-extension> = <MIME-type> * Instructs the HTTP static file server to mark any files ending in 'file-extension' with a header of 'Content-Type: <MIME-type>'. * Defaults to: [mimetype-extension-map] gif = image/gif htm = text/html jpg = image/jpg png = image/png txt = text/plain xml = text/xml xsl = text/xml Remote applications configuration (e.g. SplunkBase) [applicationsmanagement] * Set remote applications settings for Splunk under this stanza name. * Follow this stanza name with any number of the following attribute/value pairs. * If you do not specify an entry for each attribute, Splunk uses the default value. allowinternetaccess = true false * Allow Splunk to access the remote applications repository. url = <URL> * Applications repository. * Defaults to loginurl = <URL> * Applications repository login. * Defaults to detailsurl = <URL> * Base URL for application information, keyed off of app ID. * Defaults to useragent = <splunk-version>- <splunk-build-num>-<platform> * User-agent string to use when contacting applications repository. * <platform> includes information like operating system and CPU architecture. updatehost = <URL> * Host section of URL to check for app updates, e.g. updatepath = <URL> * Path section of URL to check for app updates, e.g. /api/apps:resolve/checkforupgrade updatetimeout = <time range string> * The minimum amount of time Splunk will wait between checks for app updates * Examples include '24h' (24 hours), '3d' (3 days), '7200s' (7200 seconds, or two hours) * Defaults to '24h' Misc. configuration [scripts] initialnumberofscriptprocesses = <num> * The number of pre-forked script processes that are launched when the system comes up. These scripts are reused when script REST endpoints *and* search scripts are executed. The idea is to eliminate the performance overhead of launching the script interpreter every time it is invoked. These processes are put in a pool. If the pool is completely busy when a script gets invoked, a new processes is fired up to handle the new invocation - but it disappears when that invocation is finished. Disk usage settings (for the indexer, not for Splunk log files) [diskusage] minfreespace = <num> * Specified in megabytes. * The default setting is 5000 (approx 5GB) * Specifies a safe amount of space that must exist for splunkd to continue operating. * Note that this affects search and indexing * This is how the searching is affected: * For search: * Before attempting to launch a search, splunk will require this amount of free space on the filesystem where the dispatch directory is stored, $SPLUNK_HOME/var/run/splunk/dispatch * Applied similarly to the search quota values in authorize.conf and limits.conf. * For indexing: * Periodically, the indexer will check space on all partitions that contain splunk indexes as specified by indexes.conf. Indexing will be paused 252

253 and a ui banner + splunkd warning posted to indicate need to clear more disk space. pollingfrequency = <num> * After every pollingfrequency events indexed, the disk usage is checked. * The default frequency is every events. pollingtimerfrequency = <num> * After every pollingtimerfrequency seconds, the disk usage is checked * The default value is 10 seconds Queue settings [queue] maxsize = [<integer> <integer>[kb MB GB]] * Specifies default capacity of a queue. * If specified as a lone integer (for example, maxsize=1000), maxsize indicates the maximum number of events allowed in the queue. * If specified as an integer followed by KB, MB, or GB (for example, maxsize=100mb), it indicates the maximum RAM allocated for queue. * The default is 500KB. cntr_1_lookback_time = [<integer>[s m]] * The lookback counters are used to track the size and count (number of elements in the queue) variation of the queues using an exponentially moving weighted average technique. Both size and count variation has 3 sets of counters each. The set of 3 counters is provided to be able to track short, medium and long term history of size/count variation. The user can customize the value of these counters or lookback time. * Specifies how far into history should the size/count variation be tracked for counter 1. * It needs to be specified via an integer followed by [s m] which stands for seconds and minutes respectively. * The default value for counter 1 is set to 60 seconds. cntr_2_lookback_time = [<integer>[s m]] * See above for explanation and usage of the lookback counter. * Specifies how far into history should the size/count variation be tracked for counter 2. * The default value for counter 2 is set to 600 seconds. cntr_3_lookback_time = [<integer>[s m]] * See above for explanation and usage of the lookback counter.. * Specifies how far into history should the size/count variation be tracked for counter 3. * The default value for counter 3 is set to 900 seconds. sampling_interval = [<integer>[s m]] * The lookback counters described above collects the size and count measurements for the queues. This specifies at what interval the measurement collection will happen. Note that for a particular queue all the counters sampling interval is same. * It needs to be specified via an integer followed by [s m] which stands for seconds and minutes respectively. * The default sampling_interval value is 1 second. [queue=<queuename>] maxsize = [<integer> <integer>[kb MB GB]] * Specifies the capacity of a queue. It overrides the default capacity specified in [queue]. * If specified as a lone integer (for example, maxsize=1000), maxsize indicates the maximum number of events allowed in the queue. * If specified as an integer followed by KB, MB, or GB (for example, maxsize=100mb), it indicates the maximum RAM allocated for queue. * The default is inherited from maxsize value specified in [queue] cntr_1_lookback_time = [<integer>[s m]] * Same explanation as mentioned in [queue]. * Specifies the lookback time for the specific queue for counter 1. * The default value is inherited from cntr_1_lookback_time value specified in [queue]. cntr_2_lookback_time = [<integer>[s m]] * Specifies the lookback time for the specific queue for counter 2. * The default value is inherited from cntr_2_lookback_time value specified in [queue]. cntr_3_lookback_time = [<integer>[s m]] * Specifies the lookback time for the specific queue for counter 3. * The default value is inherited from cntr_3_lookback_time value specified in [queue]. sampling_interval = [<integer>[s m]] * Specifies the sampling interval for the specific queue. * The default value is inherited from sampling_interval value specified in [queue]. PubSub server settings for the http endpoint. [pubsubsvr-http] disabled = true false * If disabled, then http endpoint is not registered. Set this value to 'false' to expose PubSub server on http. * Defaults to 'true' stateintervalinsecs = <seconds> * The number of seconds before a connection is flushed due to inactivity. The connection is not closed, only messages for that connection are flushed. * Defaults to 300 seconds (5 minutes). General file input settings. [fileinput] outputqueue = <queue name> * The queue that input methods should send their data to. Most users will not need to change this value. * Defaults to parsingqueue. Settings controlling the behavior of 'splunk diag', the diagnostic tool [diag] These settings provide defaults for invocations of the splunk diag command. Generally these can be further modified by command line flags to the diag command. EXCLUDE-<class> = <glob expression> * Specifies a glob / shell pattern to be excluded from diags generated on this Splunk instance. * Example: */etc/secret_app/local/*.conf * Further excludes can be added at the splunk diag command line, but there is no facility to disable configuration-based excludes at the command line. * There is one exclude by default, for the splunk.secret file. the following commands can be overridden entirely by their command-line equivalents. components = <comma separated list> * Specifies which components of the diag should be gathered. * This allows the disabling and enabling, categorically, of entire portions of diag functionality. * All of these components are further subject to the exclude feature (see above), and component-specific filters (see below). * Currently, with no configuration, all components except 'rest' are enabled by default. * Available components are: * index_files : Files from the index that indicate their health (Hosts Sources Sourcetypes.data and bucketmanifests). User data is not collected. * index_listing : Directory listings of the index contents are gathered, in order to see filenames, directory names, sizes, timestamps and the like. * etc : The entire contents of the $SPLUNK_HOME/etc directory. In other words, the configuration files. * log : The contents of $SPLUNK_HOME/var/log/... * pool : If search head pooling is enabled, the contents of the pool dir. * dispatch : Search artifacts, without the actual results, In other words var/run/splunk/dispatch, but not the results or events files * searchpeers : Directory listings of knowledge bundles replicated for distributed search In other words: $SPLUNK_HOME/var/run/searchpeers * consensus : Consensus protocol files produced by search head clustering In other words: $SPLUNK_HOME/var/run/splunk/_raft * conf_replication_summary : Directory listing of configuration replication summaries produced by search head clustering In other words: $SPLUNK_HOME/var/run/splunk/snapshot * rest : The contents of a variety of splunkd endpoints Includes server status messages (system banners), licenser banners, configured monitor inputs & tailing file status (progress reading input files). On cluster masters, also gathers master info, fixups, current peer list, clustered index info, current generation, & buckets in bad stats On cluster slaves, also gathers local buckets & local slave info, and the master information remotely from the configured master. * kvstore : Directory listings of the KV Store data directory 253

254 contents are gathered, in order to see filenames, directory names, sizes, and timestamps. * The special value 'all' is also supported, enabling everything explicitly. * Further controlling the components from the command line: * The switch --collect replaces this list entirely. * Example: --collect log,etc This would set the componets to log and etc only, regardless of config * The switch --enable adds a specific component to this list. * Example: --enable pool This would ensure that pool data is collected, regardles of config * The switch --disable removes a specific component from this list. * Example: --disable pool This would ensure that pool data is *NOT* collected, regardles of config * Currently, the default is to collect all components. * In the future there many be additional components which are not in the default set. * This may occur for new components that are expensive (large and/or slow) * This may occur for new components that are preceived as sensitive Data filters; these further refine what is collected most of the existing ones are designed to limit the size and collection time to pleasant values. note that most values here use underscores '_' while the command line uses hyphens '-' all_dumps = <bool> * This setting currently is irrelevant on Unix platforms. * Affects the 'log' component of diag. (dumps are written to the log dir on Windows) * Can be overridden with the --all-dumps command line flag. * Normally, Splunk diag will gather only three.dmp (crash dump) files on Windows to limit diag size. * If this is set to true, splunk diag will collect *all*.dmp files from the log directory. * Defaults to unset / false (equivalent). index_files = [full manifests] * Selects a detail level for the 'index_files' component. * Can be overridden with the --index-files command line flag. * 'manifests' limits the index file-content collection to just.bucketmanifest files which give some information about Splunks idea of the general state of buckets in an index. * 'full' adds the collection of Hosts.data, Sources.data, and Sourcetypes.data which indicate the breakdown of count of items by those categories per-bucket, and the timespans of those category entries * 'full' can take quite some time on very large index sizes, especially when slower remote storage is involved. * Defaults to 'manifests' index_listing = [full light] * Selects a detail level for the 'index_listing' component. * Can be overridden with the --index-listing command line flag. * 'light' gets directory listings (ls, or dir) of the hot/warm and cold container directory locations of the indexes, as well as listings of each hot bucket. * 'full' gets a recursive directory listing of all the contents of every index location, which should mean all contents of all buckets. * 'full' may take significant time as well with very large bucket counts, espeically on slower storage. * Defaults to 'light' etc_filesize_limit = <non-negative integer in kilobytes> * This filters the 'etc' component * Can be overridden with the --etc-filesize-limit command line flag * This value is specified in kilobytes. * Example: this would be approximately 2MB. * Files in the $SPLUNK_HOME/etc directory which are larger than this limit will not be collected in the diag. * Diag will produce a message stating that a file has been skipped for size to the console. (In practice we found these large files are often a surprise to the administrator and indicate problems). * If desired, this filter may be entirely disabled by setting the value to 0. * Defaults to or 10MB. log_age = <non-negative integer in days> * This filters the 'log' component * Can be overridden with the --log-age command line flag * This value is specified in days * Example: 75 - this would be 75 days, or about 2.5 months. * If desired, this filter may be entirely disabled by setting the value to 0. * The idea of this default filter is that data older than this is rarely helpful in troubleshooting cases in any event. * Defaults to 60, or approximately 2 months. License manager settings for configuring the license pool(s) [license] master_uri = [self <uri>] * An example of <uri>: <scheme>://<hostname>:<port> active_group = Enterprise Trial Forwarder Free these timeouts only matter if you have a master_uri set to remote master connection_timeout = 30 * Maximum time (in seconds) to wait before connection to master times out send_timeout = 30 * Maximum time (in seconds) to wait before sending data to master times out receive_timeout = 30 * Maximum time (in seconds) to wait before receiving data from master times out squash_threshold = <positive integer> * Advanced setting. Periodically the indexer must report to license manager the data indexed broken down by source, sourcetype, host, and index. If the number of distinct (source,sourcetype,host,index) tuples grows over the squash_threshold, we squash the {host,source} values and only report a breakdown by {sourcetype,index}. This is to prevent explosions in memory + license_usage.log lines. Set this only after consulting a Splunk Support engineer. * Default: 2000 report_interval = <nonnegative integer>[s m h] * Selects a time period for reporting in license usage to the license master. * This value is intended for very large deployments (hundreds of indexers) where a large number of indexers may overwhelm the license server. * The maximum permitted interval is 1 hour, and the minimum permitted interval is 1 minute. * May be expressed as a positive number of seconds, minutes or hours. * If no time unit is provided, seconds will be assumed. * Defaults to 1 minute, or 1m. strict_pool_quota = <boolean> * Toggles strict pool quota enforcement * If set to true, members of pools will receive warnings for a given day if usage exceeds pool size regardless of whether overall stack quota was exceeded * If set to false, members of pool will only receive warnings if both pool usage exceeds pool size AND overall stack usage exceeds stack size * Defaults to true pool_suggestion = <string> * Defaults to empty, which means this feature is disabled * Suggest a pool to the master for this slave. * The master will use this suggestion if the master doesn't have an explicit rule mapping the slave to a given pool (ie...no slave list for the relevant license stack contains this slave explictly) * If the pool name doesn't match any existing pool, it will be ignored, no error will be generated * This setting is intended to give an alternative management option for pool/slave mappings. When onboarding an indexer, it may be easier to manage the mapping on the indexer itself via this setting rather than having to update server.conf on master for every addition of new indexer * NOTE: if you have multiple stacks and a slave maps to multiple pools, this feature is limitted in only allowing a suggestion of a single pool; This is not a common scenario however. [lmpool:auto_generated_pool_forwarder] * This is the auto generated pool for the forwarder stack description = <textual description of this license pool> quota = MAX <maximum amount allowed by this license> * MAX indicates the total capacity of the license. You may have only 1 pool with MAX size in a stack * The quota can also be specified as a specific size eg. 20MB, 1GB etc slaves = * <slave list> * An asterix(*) indicates that any slave can connect to this pool * You can also specifiy a comma separated slave guid list stack_id = forwarder * the stack to which this pool belongs [lmpool:auto_generated_pool_free] * This is the auto generated pool for the free stack * field descriptions are the same as that for the "lmpool:auto_generated_pool_forwarder" [lmpool:auto_generated_pool_enterprise] * This is the auto generated pool for the enterprise stack * field descriptions are the same as that for the 254

255 "lmpool:auto_generated_pool_forwarder" [lmpool:auto_generated_pool_fixed-sourcetype_<sha256 hash of srctypes>] * This is the auto generated pool for the enterprise fixed srctype stack * field descriptions are the same as that for the "lmpool:auto_generated_pool_forwarder" [lmpool:auto_generated_pool_download_trial] * This is the auto generated pool for the download trial stack * field descriptions are the same as that for the "lmpool:auto_generated_pool_forwarder" Search head pooling configuration Changes to a search head's pooling configuration must be made to: $SPLUNK_HOME/etc/system/local/server.conf In other words, you may not deploy the [pooling] stanza via an app, either on local disk or on shared storage. This is because these values are read before the configuration system itself has been completely initialized. Take the value of "storage", for example. This value cannot be placed within an app on shared storage because Splunk must use this value to find shared storage in the first place! [pooling] state = [enabled disabled] * Enables or disables search head pooling. * Defaults to disabled. storage = <path to shared storage> * All members of a search head pool must have access to shared storage. * Splunk will store configurations and search artifacts here. * On *NIX, this should be an NFS mount. * On Windows, this should be a UNC path to a Samba/CIFS share. app_update_triggers = true false silent * Should this search head run update triggers for apps modified by other search heads in the pool? * For more information about update triggers specifically, see the [triggers] stanza in $SPLUNK_HOME/etc/system/README/app.conf.spec. * If set to true, this search head will attempt to reload inputs, indexes, custom REST endpoints, etc. stored within apps that are installed, updated, enabled, or disabled by other search heads. * If set to false, this search head will not run any update triggers. Note that this search head will still detect configuration changes and app state changes made by other search heads. It simply will not reload any components within Splunk that might care about those changes, like input processors or the HTTP server. * Setting a value of "silent" is like setting a value of "true", with one difference: update triggers will never result in restart banner messages or restart warnings in the UI. Any need to restart will instead by signaled only by messages in splunkd.log. * Defaults to true. lock.timeout = <time range string> * Timeout for acquiring file-based locks on configuration files. * Splunk will wait up to this amount of time before aborting a configuration write. * Defaults to '10s' (10 seconds). lock.logging = true false * When acquiring a file-based lock, log information into the locked file. * This information typically includes: * Which host is acquiring the lock * What that host intends to do while holding the lock * There is no maximum filesize or rolling policy for this logging. If you enable this setting, you must periodically truncate the locked file yourself to prevent unbounded growth. * The information logged to the locked file is intended for debugging purposes only. Splunk makes no guarantees regarding the contents of the file. It may, for example, write padding NULs to the file or truncate the file at any time. * Defaults to false. The following two intervals interelate; the longest possible time for a state change to travel from one search pool member to the rest should be approximately the sum of these two timers. poll.interval.rebuild = <time range string> * Rebuild or refresh in-memory configuration data structures at most this often. * Defaults to '1m' (1 minute). poll.interval.check = <time range string> * Check on-disk configuration files for changes at most this often. * Defaults to '1m' (1 minute). poll.blacklist.<name> = <regex> * Do not check configuration files for changes if they match this regular expression. * Example: Do not check vim swap files for changes --.swp$ High availability clustering configuration [clustering] mode = [master slave searchhead disabled] * Sets operational mode for this cluster node. * Only one master may exist per cluster. * Defaults to disabled. master_uri = [<uri> clustermaster:stanzaname1, clustermaster:stanzaname2] * Only valid for mode=slave or searchhead * uri of the cluster master that this slave or searchhead should connect to. * An example of <uri>: <scheme>://<hostname>:<port> * Only for mode=searchhead - If the searchhead is a part of multiple clusters, * the master uris can be specified by a comma separated list. pass4symmkey = <string> * Secret shared among the nodes in the cluster to prevent any arbitrary node from connecting to the cluster. If a slave or searchhead is not configured with the same secret as the master, it will not be able to communicate with the master. * Not set by default. * If it is not set in the clustering stanza, the key will be looked in the general stanza service_interval = <positive integer> * Only valid for mode=master * Specifies, in seconds, how often the master runs its service loop. In its service loop, the master checks the state of the peers and the buckets in the cluster and also schedules corrective action, if possible, for buckets that are not in compliance with replication policies. * Defaults to 1 multisite = [true false] * Turns on the multisite feature for this master. * Make sure you set site parameters on the peers when you turn this to true. * Defaults to false. cxn_timeout = <seconds> * Lowlevel timeout for establishing connection between cluster nodes. * Defaults to 60s. send_timeout = <seconds> * Lowlevel timeout for sending data between cluster nodes. * Defaults to 60s. rcv_timeout = <seconds> * Lowlevel timeout for receiving data between cluster nodes. * Defaults to 60s. rep_cxn_timeout = <seconds> * Lowlevel timeout for establishing connection for replicating data. * Defaults to 5s. rep_send_timeout = <seconds> * Lowlevel timeout for sending replication slice data between cluster nodes. * This is a soft timeout. When this timeout is triggered on source peer, it tries to determine if target is still alive. If it is still alive, it reset the timeout for another rep_send_timeout interval and continues. If target has failed or cumulative timeout has exceeded rep_max_send_timeout, replication fails. * Defaults to 5s. rep_rcv_timeout = <seconds> * Lowlevel timeout for receiving acknowledgement data from peers. * This is a soft timeout. When this timeout is triggered on source peer, it tries to determine if target is still alive. If it is still alive, it reset the timeout for another rep_send_timeout interval and continues. If target has failed or cumulative timeout has exceeded rep_max_rcv_timeout, replication fails. * Defaults to 10s. search_files_retry_timeout = <seconds> * Timeout after which request for search files from a peer is aborted. * To make a bucket searchable, search specific files are copied from another source peer with search files. If search files on source peers are undergoing chances, it asks requesting peer to retry after some time. If cumulative retry period exceeds specified timeout, the requesting peer aborts the request and requests search files from another peer in the cluster that may have search files. * Defaults to 600s. rep_max_send_timeout = <seconds> * Maximum send timeout for sending replication slice data between cluster nodes. * On rep_send_timeout source peer determines if total send timeout has exceeded rep_max_send_timeout. If so, 255

256 replication fails. * If cumulative rep_send_timeout exceeds rep_max_send_timeout, replication fails. * Defaults to 600s. rep_max_rcv_timeout = <seconds> * Maximum cumulative receive timeout for receiving acknowledgement data from peers. * On rep_rcv_timeout source peer determines if total receive timeout has exceeded rep_max_rcv_timeout. If so, replication fails. * Defaults to 600s. replication_factor = <positive integer> * Only valid for mode=master. * Determines how many copies of rawdata are created in the cluster. * Use site_replication_factor instead of this in case multisite is turned on. * Must be greater than 0. * Defaults to 3 site_replication_factor = <comma-separated string> * Only valid for mode=master and is only used if multisite is true. * This specifies the per-site replication policy for any given bucket represented as a comma-separated list of per-site entries. * Currently specified globally and applies to buckets in all indexes. * Each entry is of the form <site-id>:<positive integer> which represents the number of copies to make in the specified site * Valid site-ids include two mandatory keywords and optionally specific site-ids from site1 to site63 * The mandatory keywords are: - origin: Every bucket has a origin site which is the site of the peer that originally created this bucket. The notion of 'origin' makes it possible to specify a policy that spans across multiple sites without having to enumerate it per-site. - total: The total number of copies we want for each bucket. * When a site is the origin, it could potentially match both the origin and a specific site term. In that case, the max of the two is used as the count for that site. * The total must be greater than or equal to sum of all the other counts (including origin). * The difference between total and the sum of all the other counts is distributed across the remaining sites. * Example 1: site_replication_factor = origin:2, total:3 Given a cluster of 3 sites, all indexing data, every site has 2 copies of every bucket ingested in that site and one rawdata copy is put in one of the other 2 sites. * Example 2: site_replication_factor = origin:2, site3:1, total:3 Given a cluster of 3 sites, 2 of them indexing data, every bucket has 2 copies in the origin site and one copy in site3. So site3 has one rawdata copy of buckets ingested in both site1 and site2 and those two sites have 2 copies of their own buckets. * Defaults to origin:2, total:3 search_factor = <positive integer> * Only valid for mode=master * Determines how many buckets will have index structures pre-built. * Must be less than or equal to replication_factor and greater than 0. * Defaults to 2. site_search_factor = <comma-separated string> * Only valid for mode=master and is only used if multisite is true. * This specifies the per-site policy for searchable copies for any given bucket represented as a comma-separated list of per-site entries. * This is similar to site_replication_factor. Please see that entry for more information on the syntax. * Defaults to origin:1, total:2 available_sites = <comma-separated string> * Only valid for mode=master and is only used if multisite is true. * This is a comma-separated list of all the sites in the cluster. * Defaults to an empty string. So if multisite is turned on this needs to be explicitly set heartbeat_timeout = <positive integer> * Only valid for mode=master * Determines when the master considers a slave down. Once a slave is down, the master will initiate fixup steps to replicate buckets from the dead slave to its peers. * Defaults to 60s. access_logging_for_heartbeats = <bool> * Only valid for mode=master * Enables/disables logging to splunkd_access.log for peer heartbeats * defaults to false (logging disabled) * NOTE: you do not have to restart master to set this config parameter. Simply run the cli command on master: % splunk edit cluster-config -access_logging_for_heartbeats <true false> restart_timeout = <positive integer> * Only valid for mode=master * This is the amount of time the master waits for a peer to come back when the peer is restarted (to avoid the overhead of trying to fixup the buckets that were on the peer). * Note that currently this only works if the peer is restarted vi the UI. quiet_period = <positive integer> * Only valid for mode=master * This determines the amount of time for which the master is quiet right after it starts. During this period the master does not initiate any action but is instead waiting for the slaves to register themselves. At the end of this time period, it builds its view of the cluster based on the registered information and starts normal processing. * Defaults to 60s. generation_poll_interval = <positive integer> * Only valid if mode=master or mode=searchhead * Determines how often the searchhead polls the master for generation information. * Defaults to 60s. max_peer_build_load = <integer> * This is the maximum number of concurrent tasks to make buckets searchable that can be assigned to a peer. * Defaults to 2. max_peer_rep_load = <integer> * This is the maximum number of concurrent non-streaming replications that a peer can take part in as a target. * Defaults to 5. max_replication_errors = <integer> * Currently only valid for mode=slave * This is the maximum number of consecutive replication errors (currently only for hot bucket replication) from a source peer to a specific target peer. Until this limit is reached, the source continues to roll hot buckets on streaming failures to this target. After the limit is reached, the source will no longer roll hot buckets if streaming to this specific target fails. This is reset if at least one successful (hot bucket) replication occurs to this target from this source. * Defaults to 3. * The special value of 0 turns off this safeguard; so the source always rolls hot buckets on streaming error to any target. searchable_targets = true false * Only valid for mode=master * Tells the master to make some replication targets searchable even while the replication is going on. This only affects hot bucket replication for now. * Defaults to true searchable_target_sync_timeout = <integer> * Only valid for mode=slave * If a hot bucket replication connection is inactive for this time (in seconds), a searchable target flushes out any pending search related in-memory files. * Note that regular syncing - when the data is flowing through regularly and the connection is not inactive - happens at a faster rate (default of 5 secs controlled by streamingtargettsidxsyncperiodmsec in indexes.conf). * The special value of 0 turns off this timeout behaviour. * Defaults to 60 (seconds) target_wait_time = <positive integer> * Only valid for mode=master. * Specifies the time that the master waits for the target of a replication to register itself before it services the bucket again and potentially schedules another fixup. * Defaults to 150s commit_retry_time = <positive integer> * Only valid for mode=master * Specifies the interval after which, if the last generation commit failed, the master forces a retry. A retry is usually automatically kicked off after the appropriate events. This is just a backup to make sure that the master does retry no matter what. * Defaults to 300s percent_peers_to_restart = <integer between 0-100> * suggested percentage of maximum peers to restart for rolling-restart * actual percentage may vary due to lack of granularity for smaller peer sets * regardless of setting, a minimum of 1 peer will be restarted per round auto_rebalance_primaries = <bool> * Only valid for mode=master * Specifies if the master should automatically rebalance bucket primaries on certain triggers. Currently the only defined trigger is when a peer registers with the master. When a peer registers, the master redistributes the bucket primaries so the cluster can make use of any copies in the incoming peer. * Defaults to true. idle_connections_pool_size = <int> * Only valid for mode=master * Specifies how many idle http(s) connections we should keep alive to reuse. Reusing connections improves the time it takes to send messages to peers 256

257 in the cluster. * -1 (default) corresponds to "auto", letting the master determine the number of connections to keep around based on the number of peers in the cluster. use_batch_mask_changes = <bool> * Only valid for mode=master * Specifies if the master should process bucket mask changes in batch or inidividually one by one. * Defaults to true. * Set to false when there are 6.1 peers in the cluster for backwards compatibility. service_jobs_msec = <positive integer> * Only valid for mode=master * Max time in milliseconds cluster master spends in servicing finished jobs per service call. Increase this if metrics.log has very high current_size values. * Defaults to 100ms. register_replication_address = <IP address, or fully qualified machine/domain name> * Only valid for mode=slave * This is the address on which a slave will be available for accepting replication data. This is useful in the cases where a slave host machine has multiple interfaces and only one of them can be reached by another splunkd instance register_forwarder_address = <IP address, or fully qualified machine/domain name> * Only valid for mode=slave * This is the address on which a slave will be available for accepting data from forwarder.this is useful in the cases where a splunk host machine has multiple interfaces and only one of them can be reached by another splunkd instance. register_search_address = <IP address, or fully qualified machine/domain name> * Only valid for mode=slave * This is the address on which a slave will be available as search head. This is useful in the cases where a splunk host machine has multiple interfaces and only one of them can be reached by another splunkd instance. executor_workers = <positive integer> * Only valid if mode=master or mode=slave * Number of threads that can be used by the clustering threadpool. * Defaults to 10. A value of 0 will default to 1. heartbeat_period = <non-zero positive integer> * Only valid for mode=slave * Controls the frequency the slave attempts to send heartbeats enables2sheartbeat = true false * Only valid for mode=slave * Splunk will monitor each replication connection for presence of heartbeat, and if the heartbeat is not seen for s2sheartbeattimeout seconds, it will close the connection. * Defaults to true. s2sheartbeattimeout = <seconds> * This specifies the global timeout value for monitoring heartbeats on replication connections. * Splunk will will close a replication connection if heartbeat is not seen for s2sheartbeattimeout seconds. * Defaults to 600 seconds (10 minutes). Replication source sends heartbeat every 30 second. [clustermaster:stanza1] * Only valid for mode=searchhead when the searchhead is a part of multiple clusters. master_uri = <uri> * Only valid for mode=searchhead when present in this stanza. * uri of the cluster master that this searchhead should connect to. pass4symmkey = <string> * Secret shared among the nodes in the cluster to prevent any arbitrary node from connecting to the cluster. If a searchhead is not configured with the same secret as the master, it will not be able to communicate with the master. * Not set by default. * If it is not present here, the key in the clustering stanza will be used. If it is not present in the clustering stanza, the value in the general stanza will be used. site = <site-id> * Specifies the site this searchhead belongs to for this particular master when multisite is enabled (see below). * Valid values for site-id include site1 to site63. multisite = [true false] * Turns on the multisite feature for this master_uri for the searchhead. * Make sure the master has the multisite feature turned on. * Make sure you specify the site in case this is set to true. If no configuration is found in the clustermaster stanza, we default to any value for site that might be defined in the [general] stanza. * Defaults to false. [replication_port://<port>] Configure Splunk to listen on a given TCP port for replicated data from another cluster member. If mode=slave is set in the [clustering] stanza at least one replication_port must be configured and not disabled. disabled = true false * Set to true to disable this replication port stanza. * Defaults to false. listenonipv6 = no yes only * Toggle whether this listening port will listen on IPv4, IPv6, or both. * If not present, the setting in the [general] stanza will be used. acceptfrom = <network_acl>... * Lists a set of networks or addresses to accept connections from. These rules are separated by commas or spaces * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept replication data from anywhere) [replication_port-ssl://<port>] * This configuration is same as replication_port stanza above but uses SSL. disabled = true false * Set to true to disable this replication port stanza. * Defaults to false. listenonipv6 = no yes only * Toggle whether this listening port will listen on IPv4, IPv6, or both. * If not present, the setting in the [general] stanza will be used. acceptfrom = <network_acl>... * This setting is same as setting in replication_port stanza defined above. servercert = <path> * Full path to file containing private key and server certificate. * There is no default value. password = <string> * Server certificate password, if any. * There is no default value. rootca = <string> * The path to the file containing the SSL certificate for root certifying authority. * The file may also contain root and intermediate certificates, if required. * There is no default value. ciphersuite = <cipher suite string> * If set, uses the specified cipher string for the SSL connection. * If not set, uses the default cipher string. * provided by OpenSSL. This is used to ensure that the server does not accept connections using weak encryption protocols. supportsslv3only = true false * If true, it only accept connections from SSLv3 clients. * Default is false. compressed = true false * If true, it enables compression on SSL. * Default is true. requireclientcert = true false * Requires that any peer that connects to replication port has a certificate that can be validated by certificate authority specified in rootca. * Default is false. allowsslrenegotiation = true false * In the SSL protocol, a client may request renegotiation of the connection settings from time to time. * Setting this to false causes the server to reject all renegotiation attempts, breaking the connection. This limits the amount of CPU a single TCP connection can use, but it can cause connectivity problems especially for long-lived connections. * Defaults to true. Introspection settings [introspection:generator:disk_objects] * For 'introspection_generator_addon', packaged with Splunk; provides the data ("i-data") consumed, and reported on, by 'introspection_viewer_app' (due to ship with a future release). * This stanza controls the collection of i-data about: indexes; bucket superdirectories (homepath, coldpath,...); volumes; search dispatch artifacts. acquireextra_i_data = true false * If true, extra Disk Objects i-data is emitted; you can gain more insight into your site, but at the cost of greater resource consumption both directly (the collection itself) and indirectly (increased disk and bandwidth utilization, to store the produced i-data). * Please consult documentation for list of regularly emitted Disk Objects i-data, and extra Disk Objects i-data, appropriate to your 257

258 release. * Defaults to: false. collectionperiodinsecs = <positive integer> * Controls frequency of Disk Objects i- data collection; higher frequency (hence, smaller period) gives a more accurate picture, but at the cost of greater resource consumption both directly (the collection itself) and indirectly (increased disk and bandwidth utilization, to store the produced i-data). * Defaults to: 600 (10 minutes). [introspection:generator:disk_objects fishbucket] * This stanza controls the collection of i-data about: $SPLUNK_DB/fishbucket, where we persist per-input status of file-based inputs. * Inherits the values of 'acquireextra_i_data' and 'collectionperiodinsecs' attributes from the 'introspection:generator:disk_objects' stanza, but may be enabled/disabled independently of it. [introspection:generator:disk_objects partitions] * This stanza controls the collection of i-data about: disk partition space utilization. * Inherits the values of 'acquireextra_i_data' and 'collectionperiodinsecs' attributes from the 'introspection:generator:disk_objects' stanza, but may be enabled/disabled independently of it. [introspection:generator:resource_usage] * For 'introspection_generator_addon', packaged with Splunk; provides the data ("i-data") consumed, and reported on, by 'introspection_viewer_app' (due to ship with a future release). * "Resource Usage" here refers to: CPU usage; scheduler overhead; main (physical) memory; virtual memory; pager overhead; swap; I/O; process creation (a.k.a. forking); file descriptors; TCP sockets; receive/transmit networking bandwidth. ** Resource Usage i-data is collected at both hostwide and per-process levels; the latter, only for processes associated with this SPLUNK_HOME. *** Per-process i-data for Splunk search processes will include additional, search-specific, information. acquireextra_i_data = true false * If true, extra Resource Usage i-data is emitted; you can gain more insight into your site, but at the cost of greater resource consumption both directly (the collection itself) and indirectly (increased disk and bandwidth utilization, to store the produced i-data). * Please consult documentation for list of regularly emitted Resource Usage i-data, and extra Resource Usage i-data, appropriate to your release. * Defaults to: false. collectionperiodinsecs = <positive integer> * Controls frequency of Resource Usage i-data collection; higher frequency (hence, smaller period) gives a more accurate picture, but at the cost of greater resource consumption both directly (the collection itself) and indirectly (increased disk and bandwidth utilization, to store the produced i-data). * Defaults to: 600 (10 minutes) on UFs, 10 (1/6th of a minute) on non-ufs. [introspection:generator:kvstore] * For 'introspection_generator_addon', packaged with Splunk; * "KV Store" here refers to: statistics information about KV Store process.\ serverstatscollectionperiodinsecs = <positive integer> * Controls frequency of KV Store server status collection; * Defaults to: 27 seconds. collectionstatscollectionperiodinsecs = <positive integer> * Controls frequency of KV Store db statistics collection; * Defaults to: 600 seconds. profilingstatscollectionperiodinsecs = <positive integer> * Controls frequency of KV Store profiling data collection; * Defaults to: 5 seconds rsstatscollectionperiodinsecs = <positive integer> * Controls frequency of KV Store replica set stats collection; * Defaults to: 60 seconds Settings used to control commands started by Splunk [commands:user_configurable] prefix = <path> * All non-internal commands started by splunkd will be prefixed with this string, allowing for "jailed" command execution. * Should be only one word. In other words, commands are supported, but commands and arguments are not. * Applies to commands such as: search scripts, scripted inputs, SSL certificate generation scripts. (Any commands that are user-configurable). * Does not apply to trusted/nonconfigurable command executions, such as: splunk search, splunk-optimize, gunzip. * Default is empty (no prefix). search head clustering configuration [shclustering] disabled = true false * Disables or enables search head clustering on this instance. * Defaults to true; that is, disabled. * When enabled, the captain needs to be selected via a bootstrap mechanism. Once bootstrapped, further captain selections are made via a dynamic election mechanism. * When enabled, you will also need to specify the cluster member's own server address / management uri for identification purpose. This can be done in 2 ways: by specifying the mgmt_uri attribute individually on each member or by specifying pairs of 'GUID, mgmt-uri' strings in the servers_list attribute. mgmt_uri = [ mgmt-uri ] * The management uri is used to identify the cluster member's own address to itself. * Either mgmt_uri or servers_list is necessary. * mgmt_uri is simpler to author but is unique for each member. * servers_list is more involved, but can be copied as a config string to all members in the cluster. servers_list = [ <(GUID, mgmt-uri);>+ ] * A semicolon separated list of instance GUIDs and management URIs. * Each member will use its GUID to identify its own management URI. adhoc_searchhead = <bool> * This setting configures a member as an adhoc searchhead; i.e., the member will not run any scheduled jobs. * Use the setting captain_is_adhoc_searchhead to reduce compute load on the captain. * Defaults to false. captain_is_adhoc_searchhead = <bool> * This setting prohibits the captain from running scheduled jobs. Captain will be dedicated to controlling the activities of the cluster, but can also run adhoc search jobs from clients. * Defaults to false. replication_factor = <positive integer> * Determines how many copies of search artifacts are created in the cluster. * This must be set to the same value on all members. * Defaults to 3. pass4symmkey = <string> * Secret shared among the members in the search head cluster to prevent any arbitrary instance from connecting to the cluster. * All members must use the same value. * If set in the [shclustering] stanza, it takes precedence over any setting in the [general] stanza. * Defaults to 'changeme' from the [general] stanza in the default server.conf. async_replicate_on_proxy = <bool> * If the jobs/${sid}/results REST endpoint had to be proxied to a different member due to missing local replica, this attribute will automatically schedule an async replication to that member when set to true. * Default is true. master_dump_service_periods = <int> * if SHPMaster info is switched on in log.cfg, then captain statistics will be dumped in splunkd.log after the specified number of service periods. Purely a debugging aid. * Default is 500. long_running_jobs_poll_period = <int> * Long running delegated jobs will be polled by the captain every "long_running_jobs_poll_period" seconds to ascertain whether they are still running, in order to account for potential node/member failure. * Default is 600, i.e. 10 minutes scheduling_heuristic = <string> * This setting configures the job distribution heuristic on the captain. * There are currently two supported strategies: 'round_robin' or 'scheduler_load_based'. * Default is 'scheduler_load_based'. id = <GUID> * Unique identifier for this cluster as a whole, shared across all cluster members. * By default, Splunk will arrange for a unique value to be generated and shared across all members. cxn_timeout = <seconds> * Low-level timeout for establishing connection between cluster members. * Defaults to 60s. send_timeout = <seconds> * Low-level 258

259 timeout for sending data between search head cluster members. * Defaults to 60s. rcv_timeout = <seconds> * Low-level timeout for receiving data between search head cluster members. * Defaults to 60s. cxn_timeout_raft = <seconds> * Low-level timeout for establishing connection between search head cluster members for the raft protocol. * Defaults to 2s. send_timeout_raft = <seconds> * Low-level timeout for sending data between search head cluster members for the raft protocol. * Defaults to 5s. rcv_timeout_raft = <seconds> * Low-level timeout for receiving data between search head cluster members for the raft protocol. * Defaults to 5s. rep_cxn_timeout = <seconds> * Low-level timeout for establishing connection for replicating data. * Defaults to 5s. rep_send_timeout = <seconds> * Low-level timeout for sending replication slice data between cluster members. * This is a soft timeout. When this timeout is triggered on source peer, it tries to determine if target is still alive. If it is still alive, it reset the timeout for another rep_send_timeout interval and continues. If target has failed or cumulative timeout has exceeded rep_max_send_timeout, replication fails. * Defaults to 5s. rep_rcv_timeout = <seconds> * Low-level timeout for receiving acknowledgement data from members. * This is a soft timeout. When this timeout is triggered on source member, it tries to determine if target is still alive. If it is still alive, it reset the timeout for another rep_send_timeout interval and continues. If target has failed or cumulative timeout has exceeded rep_max_rcv_timeout, replication fails. * Defaults to 10s. rep_max_send_timeout = <seconds> * Maximum send timeout for sending replication slice data between cluster members. * On rep_send_timeout source peer determines if total send timeout has exceeded rep_max_send_timeout. If so, replication fails. * If cumulative rep_send_timeout exceeds rep_max_send_timeout, replication fails. * Defaults to 600s. rep_max_rcv_timeout = <seconds> * Maximum cumulative receive timeout for receiving acknowledgement data from members. * On rep_rcv_timeout source member determines if total receive timeout has exceeded rep_max_rcv_timeout. If so, replication fails. * Defaults to 600s. log_heartbeat_append_entries = <bool> * Default is false. * Toggles the logging in splunkd_access.log of the lowlevel heartbeats between * members. These heartbeats are used to maintain the captain's authority over other members. election_timeout_ms = <positive_integer> * The amount of time that a member will wait before trying to become the captain. * Half of this value is the heartbeat period. * A very low value of election_timeout_ms can lead to unnecessary captain elections. * The default is 60000ms, or 1 minute. election_timeout_2_hb_ratio = <positive_integer> * The ratio between the election timeout and the heartbeat time. * A typical ratio between 5-20 is desirable. Default is 12 to keep the heartbeat time at 5s. * This ratio determines the number of heartbeat attempts that would fail * before a member starts to timeout and tries to become the captain. heartbeat_timeout = <positive integer> * Determines when the captain considers a member down. Once a member is down, the captain will initiate fixup steps to replicate artifacts from the dead member to its peers. * Defaults to 60s. access_logging_for_heartbeats = <bool> * Only valid on captain * Enables/disables logging to splunkd_access.log for member heartbeats * defaults to false (logging disabled) * NOTE: you do not have to restart captain to set this config parameter. Simply run the cli command on master: % splunk edit shcluster-config - access_logging_for_heartbeats <true false> restart_timeout = <positive integer> * This is the amount of time the captain waits for a member to come back when the instance is restarted (to avoid the overhead of trying to fixup the artifacts that were on the peer). quiet_period = <positive integer> * This determines the amount of time for which a newly elected captain waits for members to join. During this period the captain does not initiate any fixups but instead waits for the members to register themselves. Job scheduling and conf replication still happen as usual during this time. At the end of this time period, the captain builds its view of the cluster based on the registered peers and starts normal processing. * Defaults to 60s. max_peer_rep_load = <integer> * This is the maximum number of concurrent replications that a member can take part in as a target. * Defaults to 5. target_wait_time = <positive integer> * Specifies the time that the captain waits for the target of a replication to register itself before it services the artifact again and potentially schedules another fixup. * Defaults to 150s. percent_peers_to_restart = <integer between 0-100> * The percentage of members to restart at one time during rolling restarts. * Actual percentage may vary due to lack of granularity for smaller peer sets * regardless of setting, a minimum of 1 peer will be restarted per round. * Do not set this attribute to a value greater than 20%. Otherwise, issues can arise during the captain election process. register_replication_address = <IP address, or fully qualified machine/domain name> * This is the address on which a member will be available for accepting replication data. This is useful in the cases where a member host machine has multiple interfaces and only one of them can be reached by another splunkd instance executor_workers = <positive integer> * Number of threads that can be used by the search head clustering threadpool. * Defaults to 10. A value of 0 will be interpreted as 1. heartbeat_period = <non-zero positive integer> * Controls the frequency with which the member attempts to send heartbeats. enables2sheartbeat = true false * Splunk will monitor each replication connection for presence of heartbeat. If the heartbeat is not seen for s2sheartbeattimeout seconds, it will close the connection. * Defaults to true. s2sheartbeattimeout = <seconds> * This specifies the global timeout value for monitoring heartbeats on replication connections. * Splunk will will close a replication connection if heartbeat is not seen for s2sheartbeattimeout seconds. * Defaults to 600 seconds (10 minutes). Replication source sends heartbeat every 30 second. proxying related sid_proxying = <bool> * Enable or disable search artifact proxying. Changing this will impact the proxying of search results, * and jobs feed will not be cluster-aware. Only for internal/expert use. * Defaults to true. ss_proxying = <bool> * Enable or disable saved search proxying to captain. Changing this will impact the behavior of Searches and Reports Page. * Only for internal/expert use. * Defaults to true. ra_proxying = <bool> * Enable or disable saved report acceleration summaries proxying to captain. Changing this will impact the * behavior of report acceleration summaries page. Only for internal/expert use. * Defaults to true. alert_proxying = <bool> * Enable or disable alerts proxying to captain. Changing this will impact the behavior of alerts, and essentially * make them not cluster-aware. Only for internal/expert use. * Defaults to true. conf_replication_period = <int> * Controls how often a cluster member replicates configuration changes. * A value of 0 disables automatic replication of configuration changes. conf_replication_max_pull_count = <int> * Controls the maximum number of configuration changes a member will replicate from the captain at one time. * A value of 0 disables any size limits. * Defaults to conf_replication_max_push_count = <int> * Controls the maximum number of configuration changes a member will replicate to the captain at one time. * A value of 0 disables any size limits. * Defaults to 100. conf_replication_include.<conf_file_name> = <bool> * Controls whether Splunk replicates changes to a particular type of *.conf file, along with any associated permissions in *.meta files. * Defaults to false. 259

260 conf_replication_summary.whitelist.<name> = <whitelist_pattern> * Whitelist files to be included in configuration replication summaries. conf_replication_summary.blacklist.<name> = <blacklist_pattern> * Blacklist files to be excluded from configuration replication summaries. conf_replication_summary.concerning_file_size = <int> * Any individual file within a configuration replication summary that is larger than this value (in MB) will trigger a splunkd.log warning message. * Defaults to 50. conf_replication_summary.period = <timespan> * Controls how often configuration replication summaries are created. * Defaults to '1m' (1 minute). conf_replication_purge.eligibile_count = <int> * Controls how many configuration changes must be present before any become eligible for purging. * In other words: controls the minimum number of configuration changes Splunk will remember for replication purposes. * Defaults to conf_replication_purge.eligibile_age = <timespan> * Controls how old a configuration change must be before it is eligible for purging. * Defaults to '1d' (1 day). conf_replication_purge.period = <timespan> * Controls how often configuration changes are purged. * Defaults to '1h' (1 hour). conf_deploy_repository = <path> * Full path to directory containing configurations to deploy to cluster members. conf_deploy_staging = <path> * Full path to directory where preprocessed configurations may be written before being deployed cluster members. conf_deploy_concerning_file_size = <int> * Any individual file within <conf_deploy_repository> that is larger than this value (in MB) will trigger a splunkd.log warning message. * Defaults to: 50 conf_deploy_fetch_url = <URL> * Specifies the location of the deployer from which members fetch the configuration bundle. * This value must be set to a <URL> in order for the configuration bundle to be fetched. * Defaults to empty. conf_deploy_fetch_mode = auto replace none * Controls configuration bundle fetching behavior when the member starts up. * When set to "replace", a member checks for a new configuration bundle on every startup. * When set to "none", a member does not fetch the configuration bundle on startup. * Regarding "auto": * If no configuration bundle has yet been fetched, "auto" is equivalent to "replace". * If the configuration bundle has already been fetched, "auto" is equivalent to "none". * Defaults to "replace". [replication_port://<port>] Configures the member to listen on a given TCP port for replicated data from another cluster member. * At least one replication_port must be configured and not disabled. disabled = true false * Set to true to disable this replication port stanza. * Defaults to false. listenonipv6 = no yes only * Toggle whether this listening port will listen on IPv4, IPv6, or both. * If not present, the setting in the [general] stanza will be used. acceptfrom = <network_acl>... * Lists a set of networks or addresses to accept connections from. These rules are separated by commas or spaces. * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept replication data from anywhere) [replication_port-ssl://<port>] * This configuration is same as replication_port stanza above but uses SSL. disabled = true false * Set to true to disable this replication port stanza. * Defaults to false. listenonipv6 = no yes only * Toggle whether this listening port will listen on IPv4, IPv6, or both. * If not present, the setting in the [general] stanza will be used. acceptfrom = <network_acl>... * This setting is same as setting in replication_port stanza defined above. servercert = <path> * Full path to file containing private key and server certificate. * There is no default value. password = <string> * Server certificate password, if any. * There is no default value. rootca = <string> * The path to the file containing the SSL certificate for root certifying authority. * The file may also contain root and intermediate certificates, if required. * There is no default value. ciphersuite = <cipher suite string> * If set, uses the specified cipher string for the SSL connection. * If not set, uses the default cipher string. * provided by OpenSSL. This is used to ensure that the server does not accept connections using weak encryption protocols. supportsslv3only = true false * If true, it only accept connections from SSLv3 clients. * Default is false. compressed = true false * If true, it enables compression on SSL. * Default is true. requireclientcert = true false * Requires that any peer that connects to replication port has a certificate that can be validated by certificate authority specified in rootca. * Default is false. allowsslrenegotiation = true false * In the SSL protocol, a client may request renegotiation of the connection settings from time to time. * Setting this to false causes the server to reject all renegotiation attempts, breaking the connection. This limits the amount of CPU a single TCP connection can use, but it can cause connectivity problems especially for long-lived connections. * Defaults to true. KV Store configuration [kvstore] disabled = true false * Set to true to disable this replication port stanza. * Defaults to false. port = <port> * Port to connect to the KV Store server. * Defaults to replicaset = <replset> * Replicaset name. * Defaults to splunkrs. distributedlookuptimeout = <seconds> * Timeout in seconds used for distributed environment when a lookup is executed from the indexer to the search head. * Defaults to 30 seconds. shutdowntimeout = <seconds> * Time in seconds to wait for a clean shutdown of the KV Store. If this time is reached after signaling for a shutdown, KV Store will be terminated forcibly. * Defaults to 10 seconds. initattempts = <int> * The maximum number of attempts to initialize the KV Store when starting splunkd. * Defaults to 300. replication_host = <host> * The host name to access the KV Store. * This setting has no effect on a single Splunk instance. * In search head clustering, if you don't specify a value for "kvstore/replication_host", the host you specify for "shclustering/register_replication_address" is used for KV Store connection strings and replication. * In search head pooling, this host value is a requirement for using KV Store. * This is the address on which a kvstore will be available for accepting remotely. verbose = true false * Set to true to enable verbose logging. * Defaults to false. dbpath = <path> * Path where KV Store data is stored. * Changing this directory after initial startup does not move existing data. The contents of the directory should be manually moved to the new location. * Defaults to $SPLUNK_DB/kvstore. oplogsize = <int> * The size of the replication operation log in MB. * Defaults to 1000MB (1GB). * Once the KV Store has created the oplog for the first time, changing this setting will NOT affect the size of the oplog. A full backup and restart of the KV Store will be required. * Do not change this setting without first consulting with Splunk Support. replicationwritetimeout = <int> * Timeout in seconds indicating when to save KV Store operations. * Used for replication environments (search head clustering or search head pooling). * Defaults to 1800 seconds (30 minutes). 260

261 server.conf.example Version This file contains an example server.conf. Use this file to configure SSL and HTTP server options. To use one or more of these configurations, copy the configuration block into server.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Allow users 8 hours before they time out [general] sessiontimeout=8h pass4symmkey = changeme Listen on IPv6 in addition to IPv4... listenonipv6 = yes...but make all outgoing TCP connections on IPv4 exclusively connectusingipversion = 4-only Turn on SSL: [sslconfig] enablesplunkdssl = true useclientsslcompression = true sslkeysfile = server.pem sslkeysfilepassword = password cacertfile = cacert.pem capath = $SPLUNK_HOME/etc/auth certcreatescript = genmyservercert.sh SSO Example This example trusts all logins from the splunk web server and localhost Note that a proxy to the splunk web server should exist to enforce authentication [general] trustedip = Set this node to be a cluster master. [clustering] mode = master replication_factor = 3 pass4symmkey = somesecret search_factor = 2 Set this node to be a slave to cluster master "SplunkMaster01" on port [clustering] mode = slave master_uri = pass4symmkey = somesecret Set this node to be a searchhead to cluster master "SplunkMaster01" on port [clustering] mode = searchhead master_uri = pass4symmkey = somesecret Set this node to be a searchhead to multiple cluster masters - "SplunkMaster01" with pass4symmkey set to 'somesecret and "SplunkMaster02" with no pass4symmkey set here. [clustering] mode = searchhead master_uri = clustermaster:east, clustermaster:west [clustermaster:east] master_uri= pass4symmkey=somesecret [clustermaster:west] master_uri= serverclass.conf 다음은 serverclass.conf의 사양 및 예제 파일입니다. serverclass.conf.spec Version This file contains possible attributes and values for defining server classes to which deployment clients can belong. These attributes and values specify what content a given server class member will receive from the deployment server. For examples, see serverclass.conf.example. You must reload deployment server ("splunk reload deploy-server"), or restart splunkd, for changes to this file to take effect. To learn more about configuration files (including precedence) please see the documentation located at *************************************************************************** Configure the server classes that are used by a deployment server instance. Server classes are essentially categories. They use filters to control what clients they apply to, contain a set of applications, and may define deployment server behavior for the management of those applications. The filters can be based on DNS name, IP address, build number of client machines, platform, and the so-called clientname. If a target machine matches the filter, then the apps and configuration content that make up the server class will be deployed to it. Property Inheritance Stanzas in serverclass.conf go from general to more specific, in the following order: [global] -> [serverclass:<name>] -> [serverclass:<scname>:app:<appname>] Some properties defined at a general level (say [global]) can be 261

262 overridden by a more specific stanza as it applies to them. All overridable properties are marked as such. FIRST LEVEL: global Global stanza that defines properties for all server classes. [global] disabled = true false * Toggles deployment server component off and on. * Set to true to disable. * Defaults to false. excludefromupdate = <path>[,<path>]... * Specifies paths to one or more top-level files or directories (and their contents) to exclude from being touched during app update. Note that each comma-separated entry MUST be prefixed by "$app_root$/" (otherwise a warning will be generated). repositorylocation = <path> * The repository of applications on the server machine. * Can be overridden at the serverclass level. * Defaults to $SPLUNK_HOME/etc/deployment-apps targetrepositorylocation = <path> * The location on the deployment client where to install the apps defined for this Deployment Server. * If this value is unset, or set to empty, the repositorylocation path is used. * Useful only with complex (for example, tiered) deployment strategies. * Defaults to $SPLUNK_HOME/etc/apps, the live configuration directory for a Splunk instance. tmpfolder = <path> * Working folder used by deployment server. * Defaults to $SPLUNK_HOME/var/run/tmp continuematching = true false * Controls how configuration is layered across classes and server-specific settings. * If true, configuration lookups continue matching server classes, beyond the first match. * If false, only the first match will be used. * A serverclass can override this property and stop the matching. * Matching is done in the order in which server classes are defined. * Can be overridden at the serverclass level. * Defaults to true endpoint = <URL template string> * The endpoint from which content can be downloaded by a deployment client. The deployment client knows how to substitute values for variables in the URL. * Any custom URL can also be supplied here, as long as it uses the specified variables. * Need not be specified unless you have a very specific need, for example: To acquire deployment application files from a third-party Web server, for extremely large environments. * Can be overridden at the serverclass level. * Defaults to $deploymentserveruri$/services/streams/deployment?name=$serverclassname$:$appname$ filtertype = whitelist blacklist * The whitelist setting indicates a filtering strategy that pulls in a subset: * Items are not considered to match the stanza by default. * Items that match any whitelist entry, and do not match any blacklist entry are considered to match the stanza. * Items that match any blacklist entry are not considered to match the stanza, regardless of whitelist. * The blacklist setting indicates a filtering strategy that rules out a subset: * Items are considered to match the stanza by default. * Items that match any blacklist entry, and do not match any whitelist entry are considered to not match the stanza. * Items that match any whitelist entry are considered to match the stanza. * More briefly: * whitelist: default no-match -> whitelists enable -> blacklists disable * blacklist: default match -> blacklists disable-> whitelists enable * Can be overridden at the serverclass level, and the serverclass:app level. * Defaults to whitelist 262

263 whitelist.<n> = <clientname> <IP address> <hostname> blacklist.<n> = <clientname> <IP address> <hostname> * 'n' is a number starting at 0, and increasing by 1. Splunk stops evaluating a filter at the first break in sequence of 'n' values. * The value of this attribute is matched against several things in order: * Any clientname specified by the client in its deploymentclient.conf file * The IP address of the connected client * The hostname of the connected client, as provided by reverse DNS lookup * The hostname of the client, as provided by the client * All of these can be used with wildcards. * will match any sequence of characters. For example: * Match a network range: * * Match a domain: *.splunk.com * Can be overridden at the serverclass level, and the serverclass:app level. * There are no whitelist or blacklist entries by default. * These patterns are PCRE regular expressions, with the following aids for easier entry: * You can specify simply '.' to mean '\.' * You can specify simply '*' to mean '.*' * Matches are always case-insensitive; you do not need to specify the '(?i)' prefix. Note: Overriding one type of filter (whitelist/blacklist) causes the other to be overridden (and hence not inherited from parent) too. Example with filtertype=whitelist: whitelist.0=*.splunk.com blacklist.0=printer.splunk.com blacklist.1=scanner.splunk.com This will cause all hosts in splunk.com, except 'printer' and 'scanner', to match this server class. Example with filtertype=blacklist: blacklist.0=* whitelist.0=*.web.splunk.com whitelist.1=*.linux.splunk.com This will cause only the 'web' and 'linux' hosts to match the server class. No other hosts will match. Deployment client machine types (hardware type of respective host machines) can also be used to match DCs. This filter will be used only if match of a client could not be decided using the whitelist/blacklist filters. The value of each machine type is designated by the hardware platform itself; a few common ones are: linux-x86_64, windows-intel, linux-i686, freebsd-i386, darwin-i386, sunos-sun4u. The method for finding it varies by platform; once a deployment client is connected to the DS, however, you can determine the value of DC's machine type with this Splunk CLI command on the DS: <code>./splunk list deploy-clients</code> The <code>utsname</code> values in the output are the respective DCs' machine types. machinetypesfilter = <comma-separated list> * Not used unless specified. * Boolean OR logic is employed: a match against any element in the list constitutes a match. * This filter is used in boolean AND logic with white/blacklist filters. Only clients which match the white/blacklist AND which match this maachinetypesfilter will be included. * In other words, the match is an intersection of the matches for the white/blacklist and the matches for MachineTypesFilter. * This filter can be overridden at the serverclass and serverclass:app levels. * Unset by default. * These patterns are PCRE regular expressions, with the following aids for easier entry: * You can specify simply '.' to mean '\.' * You can specify simply '*' to mean '.*' * Matches are always case-insensitive; you do not need to specify the '(?i)' prefix. restartsplunkweb = true false * If true, restarts SplunkWeb on the client when a member app or a directly configured app is updated. * Can be overridden at the serverclass level and the serverclass:app level. * Defaults to false restartsplunkd = true false * If true, restarts splunkd on the client when a member app or a directly configured app is updated. * Can be overridden at the serverclass level and the serverclass:app level. * Defaults to false stateonclient = enabled disabled noop * If set to "enabled", sets the application state to enabled on the client, regardless of state on the deployment server. 263

264 * If set to "disabled", set the application state to disabled on the client, regardless of state on the deployment server. * If set to "noop", the state on the client will be the same as on the deployment server. * Can be overridden at the serverclass level and the serverclass:app level. * Defaults to enabled. SECOND LEVEL: serverclass [serverclass:<serverclassname>] * This stanza defines a server class. A server class is a collection of applications; an application may belong to multiple server classes. * serverclassname is a unique name that is assigned to this server class. * A server class can override all inheritable properties in the [global] stanza. * A server class name may only contain: letters, numbers, space, underscore, dash, dot, tilde, and the '@' symbol. It is case-sensitive. NOTE: The keys listed below are all described in detail in the [global] section above. They can be used with serverclass stanza to override the global setting continuematching = true false endpoint = <URL template string> excludefromupdate = <path>[,<path>]... filtertype = whitelist blacklist whitelist.<n> = <clientname> <IP address> <hostname> blacklist.<n> = <clientname> <IP address> <hostname> machinetypesfilter = <comma-separated list> restartsplunkweb = true false restartsplunkd = true false stateonclient = enabled disabled noop repositorylocation = <path> THIRD LEVEL: app [serverclass:<server class name>:app:<app name>] * This stanza maps an application (which must already exist in repositorylocation) to the specified server class. * server class name - the server class to which this content should be added. * app name can be '*' or the name of an app: * The value '*' refers to all content in the repositorylocation, adding it to this serverclass. '*' stanza cannot be mixed with named stanzas, for a given server class. * The name of an app explicitly adds the app to a server class. Typically apps are named by the folders that contain them. * An application name, if it is not the special '*' sign explained directly above, may only contain: letters, numbers, space, underscore, dash, dot, tilde, and the '@' symbol. It is case-sensitive. appfile=<file name> * In cases where the app name is different from the file or directory name, you can use this parameter to specify the file name. Supported formats are: directories,.tar files, and.tgz files. May override higher-level settings. excludefromupdate = <path>[,<path>]... serverclass.conf.example Version Example 1 Matches all clients and includes all apps in the server class [global] whitelist.0=* 264

265 whitelist matches all clients. [serverclass:allapps] [serverclass:allapps:app:*] a server class that encapsulates all apps in the repositorylocation Example 2 Assign server classes based on dns names. [global] [serverclass:appsforops] whitelist.0=*.ops.yourcompany.com [serverclass:appsforops:app:unix] [serverclass:appsforops:app:splunklightforwarder] [serverclass:appsfordesktops] filtertype=blacklist blacklist everybody except the Windows desktop machines. blacklist.0=* whitelist.0=*.desktops.yourcompany.com [serverclass:appsfordesktops:app:splunkdesktop] Example 3 Deploy server class based on machine types [global] [serverclass:appsbymachinetype] Ensure this server class is matched by all clients. It is IMPORTANT to have a general filter here, and a more specific filter at the app level. An app is matched _only_ if the server class it is contained in was successfully matched! whitelist.0=* [serverclass:appsbymachinetype:app:splunkdesktop] Deploy this app only to Windows boxes. machinetypesfilter=windows-* [serverclass:appsbymachinetype:app:unix] Deploy this app only to unix boxes - 32/64 bit. machinetypesfilter=linux-i686, linux-x86_64 Example 4 Specify app update exclusion list. [global] The local/ subdirectory within every app will not be touched upon update. excludefromupdate=$app_root$/local [serverclass:myapps] [serverclass:myapps:app:specialcaseapp] For the SpecialCaseApp, both the local/ and lookups/ subdirectories will not be touched upon update. excludefromupdate=$app_root$/local,$app_root$/lookups serverclass.seed.xml.conf 다음은 serverclass.seed.xml.conf의 사양 및 예제 파일입니다. serverclass.seed.xml.conf.spec Version <!-- This configuration is used by deploymentclient to seed a Splunk installation with applications, at startup time. This file should be located in the workingdir folder defined by deploymentclient.conf. 265

266 An interesting fact - the DS -> DC communication on the wire also uses this XML format. --> <?xml version="1.0"?> <deployment name="somename"> <!-- The endpoint from which all apps can be downloaded. This value can be overridden by serviceclass or ap declarations below. In addition, deploymentclient.conf can control how this property is used by deploymentclient - see deploymentclient.conf.spec. --> <endpoint>$deploymentserveruri$/services/streams/deployment?name=$serviceclassname$:$appname$</endpoint> <!-- The location on the deploymentclient where all applications will be installed. This value can be overridden by serviceclass or app declarations below. In addition, deploymentclient.conf can control how this property is used by deploymentclient - see deploymentclient.conf.spec. --> <repositorylocation>$splunk_home/etc/apps</repositorylocation> <serviceclass name="serviceclassname"> <!-- The order in which this service class is processed. --> <order>n</order> <!-- DeploymentClients can also override these values using serverrepositorylocationpolicy and serverendpointpolicy. --> <repositorylocation>$splunk_home/etc/myapps</repositorylocation> <endpoint>splunk.com/spacecake/$serviceclassname$/$appname$.tgz</endpoint> <!-- Please See serverclass.conf.spec for how these properties are used. --> <continuematching>true</continuematching> <restartsplunkweb>false</restartsplunkweb> <restartsplunkd>false</restartsplunkd> <stateonclient>enabled</stateonclient> <app name="appname1"> <!-- Applications can override the endpoint property. --> <endpoint>splunk.com/spacecake/$appname$</endpoint> </app> <app name="appname2"/> </serviceclass> </deployment> serverclass.seed.xml.conf.example <?xml version="1.0" encoding="utf-8"?> <deployment name="root"> <serverclass name="spacecake_apps"> <app name="app_0"> <repositorylocation>$splunk_home/etc/myapps</repositorylocation> <!-- Download app_0 from the given location --> <endpoint>splunk.com/spacecake/apps/app_0.tgz</endpoint> </app> <app name="app_1"> <repositorylocation>$splunk_home/etc/myapps</repositorylocation> <!-- Download app_1 from the given location --> <endpoint>splunk.com/spacecake/apps/app_1.tgz</endpoint> 266

267 </app> </serverclass> <serverclass name="foobar_apps"> <!-- construct url for each location based on the scheme below and download each app --> <endpoint>foobar.com:5556/services/streams/deployment?name=$serverclassname$_$appname$.bundle</endpoint> <app name="app_0"/> <app name="app_1"/> <app name="app_2"/> </serverclass> <serverclass name="local_apps"> <endpoint>foo</endpoint> <app name="app_0"> <!-- app present in local filesystem --> <endpoint>file:/home/johndoe/splunk/ds/service_class_2_app_0.bundle</endpoint> </app> <app name="app_1"> <!-- app present in local filesystem --> <endpoint>file:/home/johndoe/splunk/ds/service_class_2_app_1.bundle</endpoint> </app> <app name="app_2"> <!-- app present in local filesystem --> <endpoint>file:/home/johndoe/splunk/ds/service_class_2_app_2.bundle</endpoint> </app> </serverclass> </deployment> setup.xml.conf 다음은 setup.xml.conf의 사양 및 예제 파일입니다. setup.xml.conf.spec Version <!-- This file describes the setup XML config and provides some examples. setup.xml provides a Setup Screen that you provide to users to specify configurations for an app. The Setup Screen is available when the user first runs the app or from the Splunk Manager: Splunk > Manager > Apps > Actions > Set up Place setup.xml in the app's default directory: $SPLUNK_HOME/etc/apps/<app>/default/setup.xml The basic unit of work is an <input>, which is targeted to a triplet (endpoint, entity, field) and other information used to model the data. For example data type, validation information, name/label, etc. The (endpoint, entity, field attributes) identifies an object where the input is read/written to, for example: endpoint=saved/searches entity=mysavedsearch field=cron_schedule The endpoint/entities addressing is relative to the app being configured. Endpoint/entity can be inherited from the outer blocks (see below how blocks work). Inputs are grouped together within a <block> element: (1) blocks provide an iteration concept when the referenced REST entity is a regex (2) blocks allow you to group similar configuration items (3) blocks can contain <text> elements to provide descriptive text to the user. 267

268 (4) blocks can be used to create a new entry rather than edit an already existing one, set the entity name to "_new". NOTE: make sure to add the required field 'name' as an input. (5) blocks cannot be nested See examples below. Block Node attributes: endpoint - The REST endpoint relative to " of entities/object the block/input addresses. Generally, an endpoint maps to a Splunk configuration file. entity - An object at the endpoint. Generally, this maps to a stanza name in a configuration file. NOTE: entity names should be URI encoded. mode - (bulk iter) used if the entity attribute is a regular expression: o iter - (default value for mode) Iterate over all matching entities and provide a separate input field for each. o bulk - Update all matching entities with the same value. NOTE: splunk interprets '*' as the regex '.*' eai_search - a search to filter entities returned by an endpoint. If not specified the following search is used: eai:acl.app="" OR eai:acl.app="<current-app>" This search matches only objects defined in the app which the setup page is being used for. NOTE: if objects from another app are allowed to be configured, any changes to those objects will be stored in the current app. enabled - (true false in-windows in-unix) whether this block is enabled or not o true - (default) this block is enabled o false - block disabled o in-windows - block is enabled only in windows installations o in-unix - block is enabled in non-windows installations Input Node Attributes: endpoint - see description above (inherited from block) entity - see description above (inherited from block) field - <string> the field which is being configured old_style_disable - <bool> whether to perform entity disabling by submitting the edited entity with the following field set: disabled=1. (This is only relevant for inputs whose field=disabled enabled). Defaults to false. Nodes within an <input> element can display the name of the entity and field values within the entity on the setup screen. Specify $name$ to display the name of the entity. Use $<field_name>$ to specify the value of a specified field. --> <setup> <block title="basic stuff" endpoint="saved/searches/" entity="foobar"> <text> some description here </text> <input field="is_scheduled"> <label>enable Schedule for $name$</label> <!-- this will be rendered as "Enable Schedule for foobar" --> <type>bool</type> </input> <input field="cron_scheduled"> <label>cron Schedule</label> <type>text</type> </input> <input field="actions"> 268

269 <label>select Active Actions</label> <type>list</type> </input> <!-- bulk update --> <input entity="*" field="is_scheduled" mode="bulk"> <label>enable Schedule For All</label> <type>bool</type> </input> </block> <!-- iterative update in this block --> <block title="configure search" endpoint="saved/eventypes/" entity="*" mode="iter"> <input field="search"> <label>$name$ search</label> <type>string</type> </input> <input field="disabled"> <label>disable $name$</label> <type>bool</type> </input> </block> <block title="create a new eventtype" endpoint="saved/eventtypes/" entity="_new"> <input target="name"> <label>name</label> <type>text</type> </input> <input target="search"> <label>search</label> <type>text</type> </input> </block> <block title="add Account Info" endpoint="storage/passwords" entity="_new"> <input field="name"> <label>username</label> <type>text</type> </input> <input field="password"> <label>password</label> <type>password</type> </input> </block> <!-- example config for "Windows setup" --> <block title="collect local event logs" endpoint="admin/win-eventlogs/" eai_search="" > <text> Splunk for Windows needs at least your local event logs to demonstrate how to search them. You can always add more event logs after the initial setup in Splunk Manager. </text> <input entity="system" field="enabled" old_style_disable="true"> <label>enable $name$</label> <type>bool</type> </input> <input entity="security" field="enabled" old_style_disable="true"> <label>enable $name$</label> <type>bool</type> </input> <input entity="application" field="enabled" old_style_disable="true"> <label>enable $name$</label> <type>bool</type> </input> </block> <block title="monitor Windows update logs" endpoint="data/inputs/monitor"> <text> If you monitor the Windows update flat-file log, Splunk for Windows can show your patch history. You can also monitor other logs if you have them, such as IIS or DHCP logs, from Data Inputs in Splunk Manager </text> <input entity="%24windir%5cwindowsupdate.log" field="enabled"> 269

270 <label>enable $name$</label> <type>bool</type> </input> </block> </setup> setup.xml.conf.example No example source-classifier.conf 다음은 source-classifier.conf의 사양 및 예제 파일입니다. source-classifier.conf.spec Version This file contains all possible options for configuring settings for the file classifier in source-classifier.conf. There is a source-classifier.conf in $SPLUNK_HOME/etc/system/default/ To set custom configurations, place a source-classifier.conf in $SPLUNK_HOME/etc/system/local/. For examples, see source-classifier.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at ignored_model_keywords = <space-separated list of terms> * Terms to ignore when generating a sourcetype model. * To prevent sourcetype "bundles/learned/*-model.xml" files from containing sensitive terms (e.g. "bobslaptop") that occur very frequently in your data files, add those terms to ignored_model_keywords. ignored_filename_keywords = <space-separated list of terms> * Terms to ignore when comparing a new sourcename against a known sourcename, for the purpose of classifying a source. source-classifier.conf.example Version This file contains an example source-classifier.conf. Use this file to configure classification of sources into sourcetypes. To use one or more of these configurations, copy the configuration block into source-classifier.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at terms to ignore when generating sourcetype model to prevent model from containing servernames, ignored_model_keywords = sun mon tue tues wed thurs fri sat sunday monday tuesday wednesday thursday friday saturday jan feb mar apr may jun jul aug sep oct nov dec january february march april may june july august september october november december am pm ut utc gmt cet cest cetdst met mest metdst mez mesz eet eest eetdst wet west wetdst msk msd ist jst kst hkt ast adt est edt cst cdt mst mdt pst pdt cast cadt east eadt wast wadt terms to ignore when comparing a sourcename against a known sourcename 270

271 ignored_filename_keywords = log logs com common event events little main message messages queue server splunk sourcetype_metadata.conf 다음은 sourcetype_metadata.conf의 사양 및 예제 파일입니다. sourcetype_metadata.conf.spec Version 6.2 This file contains possible attribute/value pairs for sourcetype metadata. There is a default sourcetype_metadata.conf in $SPLUNK_HOME/etc/system/default. To set custom configurations, place a sourcetype_metadata.conf in $SPLUNK_HOME/etc/system/local/. To set custom configuration for an app, place sourcetype_metadata.conf in $SPLUNK_HOME/etc/apps/<app_name>/local/. For examples, see sourcetype_metadata.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<sourcetype>] * This stanza enables properties for a given <sourcetype>. * Follow the stanza name with any number of the following attribute/value pairs. category = <string> * Category of the sourcetype. * Can use one of the predefined categories, or a custom one. * Predefined categories are: category_structured, category_web, category_application, category_network_security category_voip, category_database, category_ , category_linux, category_miscellaneous, category_custom, category_company description = <string> * Description of the sourcetype. sourcetype_metadata.conf.example Version 6.2 This is an example sourcetype_metadata.conf. Use this file to define category and descripton for sourcetype. To use one or more of these configurations, copy the configuration block into sourcetype_metadata.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at First example is an example of assigning one of defined categories to a custom sourcetype. Second example uses a custom category and description [custom_sourcetype_1] category = category_database description = Custom sourcetype for database logs [custom_sourcetype_2] category = My Sourcetypes description = Custom sourcetype for apache logs 271

272 sourcetypes.conf 다음은 sourcetypes.conf의 사양 및 예제 파일입니다. sourcetypes.conf.spec Version NOTE: sourcetypes.conf is a machine-generated file that stores the document models used by the file classifier for creating source types. Generally, you should not edit sourcetypes.conf, as most attributes are machine generated. However, there are two attributes which you can change. There is a sourcetypes.conf in $SPLUNK_HOME/etc/system/default/ To set custom configurations, place a sourcetypes..conf in $SPLUNK_HOME/etc/system/local/. For examples, see sourcetypes.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. _sourcetype = <value> * Specifies the sourcetype for the model. * Change this to change the model's sourcetype. * Future sources that match the model will receive a sourcetype of this new name. _source = <value> * Specifies the source (filename) for the model. sourcetypes.conf.example Version This file contains an example sourcetypes.conf. Use this file to configure sourcetype models. NOTE: sourcetypes.conf is a machine-generated file that stores the document models used by the file classifier for creating source types. Generally, you should not edit sourcetypes.conf, as most attributes are machine generated. However, there are two attributes which you can change. To use one or more of these configurations, copy the configuration block into sourcetypes.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at This is an example of a machine-generated sourcetype models for a fictitious sourcetype cadcamlog. [/Users/bob/logs/bnf.x5_Thu_Dec_13_15:59:06_2007_ ] _source = /Users/bob/logs/bnf.x5 _sourcetype = cadcamlog L =

273 L-t<_EQ> = splunk-launch.conf 다음은 splunk-launch.conf의 사양 및 예제 파일입니다. splunk-launch.conf.spec Version splunk-launch.conf contains values used at startup time, by the splunk command and by windows services. Note: this conf file is different from most splunk conf files. There is only one in the whole system, located at $SPLUNK_HOME/etc/splunk-launch.conf; further, there are no stanzas, explicit or implicit. Finally, any splunk-launch.conf files in etc/apps/... or etc/users/... will be ignored. Lines beginning with a are considered comments and are ignored. ******* Environment variables Primarily, this file simply sets environment variables to be used by Splunk programs. These environment variables are the same type of system environment variables that can be set, on unix, using: bourne shells: $ export ENV_VAR=value c-shells: % setenv ENV_VAR value or at a windows command prompt: C:\> SET ENV_VAR=value ******* <environment_variable>=<value> * Any desired environment variable can be set to any value. Whitespace is trimmed from around both the key and value. * Environment variables set here will be available to all splunk processes, barring operating system limitations. ******* Specific Splunk environment settings These settings are primarily treated as environment variables, though some have some additional logic (defaulting). There is no need to explicitly set any of these values in typical environments. ******* SPLUNK_HOME=<pathname> * The comment in the auto-generated splunk-launch.conf is informational, not a live setting, and does not need to be uncommented. * Fully qualified path to the Splunk install directory. * If unset, Splunk automatically determines the location of SPLUNK_HOME based on the location of splunk-launch.conf * Specifically, the parent of the directory containing splunk-launch.conf * Defaults to unset. SPLUNK_DB=<pathname> * The comment in the auto-generated splunk-launch.conf is informational, not a live setting, and does not need to be uncommented. * Fully qualified path to the directory containing the splunk index directories. 273

274 * Primarily used by paths expressed in indexes.conf * The comment in the autogenerated splunk-launch.conf is informational, not a live setting, and does not need to be uncommented. * If unset, becomes $SPLUNK_HOME/var/lib/splunk (unix) or %SPLUNK_HOME%\var\lib\splunk (windows) * Defaults to unset. SPLUNK_BINDIP=<ip address> * Specifies an interface that splunkd and splunkweb should bind to, as opposed to binding to the default for the local operating system. * If unset, Splunk makes no specific request to the operating system when binding to ports/opening a listening socket. This means it effectively binds to '*'; i.e. an unspecified bind. The exact result of this is controlled by operating system behavior and configuration. * NOTE: When using this setting you must update mgmthostport in web.conf to match, or the command line and splunkweb will not know how to reach splunkd. * For splunkd, this sets both the management port and the receiving ports (from forwarders). * Useful for a host with multiple IP addresses, either to enable access or restrict access; though firewalling is typically a superior method of restriction. * Overrides the Splunkweb-specific web.conf/[settings]/server.socket_host param; the latter is preferred when SplunkWeb behavior is the focus. * Defaults to unset. SPLUNK_IGNORE_SELINUX=true * If unset (not present), Splunk on Linux will abort startup if it detects it is running in an SELinux environment. This is because in shipping/distribution-provided SELinux environments, Splunk will not be permitted to work, and Splunk will not be able to identify clearly why. * This setting is useful in environments where you have configured SELinux to enable Splunk to work. * If set to any value, Splunk will launch, despite the presence of SELinux. * Defaults to unset. SPLUNK_OS_USER = <string> <nonnegative integer> * The OS user whose privileges Splunk will adopt when running, if this parameter is set. * Example: SPLUNK_OS_USER=fnietzsche, but a root login is used to start splunkd. Immediately upon starting, splunkd abandons root's privileges, and acquires fnietzsche's privileges; any files created by splunkd (index data, logs, etc.) will be consequently owned by fnietzsche. So when splunkd is started next time by fnietzsche, files will be readable. * When 'splunk enable boot-start -user <U>' is invoked, SPLUNK_OS_USER is set to <U> as a side effect. * Under UNIX, username or apposite numeric UID are both acceptable; under Windows, only a username. ******* Service/server names. These settings are considered internal, and altering them is not supported. Under Windows, they influence the expected name of the service; on UNIX they influence the reported name of the appropriate server or daemon process. If you want to run multiple instances of Splunk as *services* under Windows, you will need to change the names below for 2nd, 3rd,..., instances. That is because the 1st instance has taken up service names 'Splunkd' and 'Splunkweb', and you may not have multiple services with same name. ******* SPLUNK_SERVER_NAME=<name> * Names the splunkd server/service. * Defaults to splunkd (UNIX), or Splunkd (Windows). SPLUNK_WEB_NAME=<name> * Names the Python app server / web server/service. * Defaults to splunkweb (UNIX), or Splunkweb (Windows). splunk-launch.conf.example 274

275 No example tags.conf 다음은 tags.conf의 사양 및 예제 파일입니다. tags.conf.spec Version This file contains possible attribute/value pairs for configuring tags. Set any number of tags for indexed or extracted fields. There is no tags.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a tags.conf in $SPLUNK_HOME/etc/system/local/. For help, see tags.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [<fieldname>=<value>] * The field name and value to which the tags in the stanza apply ( eg host=localhost ). * A tags.conf file can contain multiple stanzas. It is recommended that the value be URL encoded to avoid * config file parsing errors especially if the field value contains the following characters: \n, =, [] * Each stanza can refer to only one field=value <tag1> = <enabled disabled> <tag2> = <enabled disabled> <tag3> = <enabled disabled> * Set whether each <tag> for this specific <fieldname><value> is enabled or disabled. * While you can have multiple tags in a stanza (meaning that multiple tags are assigned to the same field/value combination), only one tag is allowed per stanza line. In other words, you can't have a list of tags on one line of the stanza. * WARNING: Do not quote the <tag> value: foo=enabled, not "foo"=enabled. tags.conf.example Version This is an example tags.conf. Use this file to define tags for fields. To use one or more of these configurations, copy the configuration block into tags.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at This first example presents a situation where the field is "host" and the three hostnames for which tags are being defined are "hostswitch," " box," and "devmachine." Each hostname has two tags applied to it, one per line. Note also that the "building1" tag has been applied to two hostname values ( box and devmachine). [host=hostswitch] pci = enabled cardholder-dest = enabled [host= box] = enabled building1 = enabled [host=devmachine] development = enabled 275

276 building1 = enabled [src_ip= ] firewall = enabled [seekptr=1cb58000] EOF = enabled NOT_EOF = disabled tenants.conf 다음은 tenants.conf의 사양 및 예제 파일입니다. tenants.conf.spec Version This.conf file is DEPRECATED as of Splunk 6.0; support for it and the feature it configures, Multi-Tenanted Deployment Server, will be removed altogether in the next major release. Use tenants.conf to redirect incoming requests from deployment clients to another deployment server or servers. This is typically used for offloading load on your splunkd's HTTP server. This is not a typical configuration for deployment server. There is no default tenants.conf There is no need to create/edit tenants.conf* unless you have worked with Splunk Professional Services to design a custom deployment that includes explicit involvement of tenants.conf. To set custom configurations, place a pubsub.conf in $SPLUNK_HOME/etc/system/local/. For examples, see pubsub.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. *************************************************************************** Configure tenants (DeploymentServer instances) within the same Splunk server. Multiple instances of deployment servers can be configured within the same Splunk instance using this configuration file. If this file is missing, a default DeploymentServer for tenant='default'is configured by the system, if there exists serverclass.conf or default-serverclass.conf. It is possible to redirect deployment clients to the appropriate instance of deployment server? by using a whitelist/blacklist mechanism, similar to the one in serverclass.conf. How does it all work? A DeploymentClient does a handshake with TenantService to determine which DeploymentServer it should be talking to. The TenantService will use this configuration to redirect a client to the appropriate deployment server (represented by phonehometopic). How is multi-tenant configuration stored? Server class configuration for each tenant (except for 'default' tenant) MUST be made available in: <tenantname>-serverclass.conf, and MUST include at least 1 serverclass. Server class configuration for the 'default' tenant MAY be made available in: <tenantname>-serverclass.conf; it MAY also reside in 'serverclass.conf' (note the missing <tenantname> prefix) in this case. The 'default' tenant MAY be associated with 0 serverclasses. 276

277 [tenant:<tenantname>] filtertype = whitelist blacklist * defaults to whitelist whitelist.<n> = <IP address or hostname or clientname> blacklist.<n> = <IP address of hostname of clientname> * 'n' is a number starting at 0, and increasing by 1. Stop looking at the filter when 'n' breaks. * IP address of deployment client. Can also use wildcards, such as * * hostname of deployment client. Can also use wildcards as *.splunk.com. * clientname- a logical or 'tag' name that can be assigned to each deployment client in deploymentclient.conf. Takes precedence (over IP/hostname) when matching a client to a filter. Internal. phonehometopic=deploymentserver/phonehome/$tenantname$ * some unique suffix. Default is to use the tenant name. Make sure this value is unique. * Override this value only when you wish to script and roll your own deployment server. token = <token-id for phone home communication> * defaults to 'default' This.conf file is DEPRECATED as of Splunk 6.0; support for it and the feature it configures, Multi-Tenanted Deployment Server, will be removed altogether in the next major release. tenants.conf.example Version This.conf file is DEPRECATED as of Splunk 6.0; support for it and the feature it configures, Multi-Tenanted Deployment Server, will be removed altogether in the next major release. Define two tenants - dept1 and dept2. DS Configuration for dept1 will be in a matching dept1-serverclass.conf DS Configuration for dept2 will be in a matching dept2-serverclass.conf [tenant:dept1] whitelist.0=*.dept1.splunk.com token=dept1 [tenant:dept2] whitelist.0=*.dept2.splunk.com token=dept2 times.conf 다음은 times.conf의 사양 및 예제 파일입니다. times.conf.spec Version This file contains possible attribute/value pairs for creating custom time ranges. To set custom configurations, place a times.conf in $SPLUNK_HOME/etc/system/local/. For help, see times.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS 277

278 Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<timerange_name>] * The token to be used when accessing time ranges via the API or command line * A times.conf file can contain multiple stanzas. label = <string> * The textual description used by the UI to reference this time range * Required header_label = <string> * The textual description used by the UI when displaying search results in this time range. * Optional. If omitted, the <timerange_name> is used instead. earliest_time = <string> * The string that represents the time of the earliest event to return, inclusive. * The time can be expressed with a relative time identifier or in epoch time. * Optional. If omitted, no earliest time bound is used. latest_time = <string> * The string that represents the time of the earliest event to return, inclusive. * The time can be expressed with a relative time identifier or in epoch time. * Optional. If omitted, no latest time bound is used. NOTE: events that occur in the future (relative to the server timezone) may be returned. order = <integer> * The key on which all custom time ranges are sorted, ascending. * The default time range selector in the UI will merge and sort all time ranges according to the 'order' key, and then alphabetically. * Optional. Default value is 0. sub_menu = <submenu name> * if present, the time range is to be shown in the given submenu instead of in the main menu. * the value for this key must be the label key of an existing stanza name, and that stanza name must have an is_sub_menu = True key * Optional. If omitted the given time option will display in the main menu. is_sub_menu = <boolean> * If True, the given item is only the 'opener' element for a submenu. * stanzas containing this key can still be assigned an order value to set the placement within the main menu, but can not themselves have latest_time nor earliest_time keys. times.conf.example Version This is an example times.conf. Use this file to create custom time ranges that can be used while interacting with the search system. To use one or more of these configurations, copy the configuration block into times.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Note: These are examples. Replace the values with your own customizations. The stanza name is an alphanumeric string (no spaces) that uniquely identifies 278

279 a time range. [this_business_week] Define the label used in the time range control label = This business week Define the label to be used in display headers. If omitted the 'label' key will be used with the first letter lowercased. header_label = during this business week earliest_time = +1d@w1 latest_time = +6d@w6 Define the ordering sequence of this time range. All time ranges are sorted numerically, ascending. If the time range is in a sub menu and not in the main menu, this will determine the position within the sub menu. order = 110 a time range that only has a bound on the earliest time [last_3_hours] label = Last 3 hours header_label = in the last 3 hours earliest_time = -3h order = 30 Use epoch time notation to define the time bounds for the Fall Semester 2013, where earliest_time is 9/4/13 00:00:00 and latest_time is 12/13/13 00:00:00. [Fall_2013] label = Fall Semester 2013 earliest_time = latest_time = two time ranges that should appear in a sub menu instead of in the main menu. the order values here determine relative ordering within the submenu. [yesterday] label = Yesterday earliest_time = -1d@d latest_time order = 10 sub_menu = Other options [day_before_yesterday] label = Day before yesterday header_label = from the day before yesterday earliest_time = -2d@d latest_time = -1d@d order = 20 sub_menu = Other options The sub menu item that should contain the previous two time ranges. the order key here determines the submenu opener's placement within the main menu. [other] label = Other options order = 202 transactiontypes.conf 다음은 transactiontypes.conf의 사양 및 예제 파일입니다. transactiontypes.conf.spec 279

280 Version This file contains all possible attributes and value pairs for a transactiontypes.conf file. Use this file to configure transaction searches and their properties. There is a transactiontypes.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a transactiontypes.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<TRANSACTIONTYPE>] * Create any number of transaction types, each represented by a stanza name and any number of the following attribute/value pairs. * Use the stanza name, [<TRANSACTIONTYPE>], to search for the transaction in Splunk Web. * If you do not specify an entry for each of the following attributes, Splunk uses the default value. maxspan = [<integer> s m h d -1] * Set the maximum time span for the transaction. * Can be in seconds, minutes, hours, or days, or -1 for an unlimited timespan. * For example: 5s, 6m, 12h or 30d. * Defaults to: maxspan=-1 maxpause = [<integer> s m h d -1] * Set the maximum pause between the events in a transaction. * Can be in seconds, minutes, hours, or days, or -1 for an unlimited pause. * For example: 5s, 6m, 12h or 30d. * Defaults to: maxpause=-1 maxevents = <integer> * The maximum number of events in a transaction. This constraint is disabled if the value is a negative integer. * Defaults to: maxevents=1000 fields = <comma-separated list of fields> * If set, each event must have the same field(s) to be considered part of the same transaction. * For example: fields=host,cookie * Defaults to: "" connected=[true false] * Relevant only if fields (see above) is not empty. Controls whether an event that is not inconsistent and not consistent with the fields of a transaction opens a new transaction (connected=true) or is added to the transaction. * An event can be not inconsistent and not field-consistent if it contains fields required by the transaction but none of these fields has been instantiated in the transaction (by a previous event addition). * Defaults to: connected=true startswith=<transam-filter-string> * A search or eval filtering expression which, if satisfied by an event, marks the beginning of a new transaction. * For example: * startswith="login" * startswith=(username=foobar) * startswith=eval(speed_field < max_speed_field) * startswith=eval(speed_field < max_speed_field/12) * Defaults to: "" endswith=<transam-filter-string> * A search or eval filtering expression which, if satisfied by an event, marks the end of a 280

281 transaction. * For example: * endswith="logout" * endswith=(username=foobar) * endswith=eval(speed_field > max_speed_field) * endswith=eval(speed_field > max_speed_field/12) * Defaults to: "" * For startswith/endswith <transam-filter-string> has the following syntax: * syntax: "<search-expression>" (<quoted-search-expression>) eval(<eval-expression>) * Where: * <search-expression> is a valid search expression that does not contain quotes * <quoted-search-expression> is a valid search expression that contains quotes * <eval-expression> is a valid eval expression that evaluates to a boolean. For example, startswith=eval(foo<bar*2) will match events where foo is less than 2 x bar. * Examples: * "<search expression>": startswith="foo bar" * <quoted-search-expression>: startswith=(name="mildred") * <quoted-search-expression>: startswith=("search literal") * eval(<eval-expression>): startswith=eval(distance/time < max_speed) memory constraint options maxopentxn=<int> * Specifies the maximum number of not yet closed transactions to keep in the open pool. When this limit is surpassed, Splunk begins evicting transactions using LRU (least-recently-used memory cache algorithm) policy. * The default value of this attribute is read from the transactions stanza in limits.conf. maxopenevents=<int> * Specifies the maximum number of events (can be) part of open transactions. When this limit is surpassed, Splunk begins evicting transactions using LRU (least-recently-used memory cache algorithm) policy. * The default value of this attribute is read from the transactions stanza in limits.conf. keepevicted=<bool> * Whether to output evicted transactions. Evicted transactions can be distinguished from non-evicted transactions by checking the value of the 'evicted' field, which is set to '1' for evicted transactions. * Defaults to: keepevicted=false multivalue rendering options mvlist=<bool> <field-list> * Field controlling whether the multivalued fields of the transaction are (1) a list of the original * events ordered in arrival order or (2) a set of unique field values ordered lexigraphically. If a * comma/space delimited list of fields is provided only those fields are rendered as lists * Defaults to: mvlist=f delim=<string> * A string used to delimit the original event values in the transaction event fields. * Defaults to: delim=" " nullstr=<string> * The string value to use when rendering missing field values as part of mv fields in a transaction. * This option applies only to fields that are rendered as lists. * Defaults to: nullstr=null values only used by the searchtxn search command search=<string> * A search string used to more efficiently seed transactions of this type. * The value should be as specific as possible, to limit the number of events that must be retrieved to find transactions. * Example: sourcetype="sendmaill_sendmail" * Defaults to "*" (all events) transactiontypes.conf.example 281

282 Version This is an example transactiontypes.conf. Use this file as a template to configure transactions types. To use one or more of these configurations, copy the configuration block into transactiontypes.conf in $SPLUNK_HOME/etc/system/local/. To learn more about configuration files (including precedence) please see the documentation located at [default] maxspan = 5m maxpause = 2s match = closest [purchase] maxspan = 10m maxpause = 5m fields = userid transforms.conf 다음은 transforms.conf의 사양 및 예제 파일입니다. transforms.conf.spec Version This file contains attributes and values that you can use to configure data transformations. and event signing in transforms.conf. Transforms.conf is commonly used for: * Configuring regex-based host and source type overrides. * Anonymizing certain types of sensitive incoming data, such as credit card or social security numbers. * Routing specific events to a particular index, when you have multiple indexes. * Creating new index-time field extractions. NOTE: We do not recommend adding to the set of fields that are extracted at index time unless it is absolutely necessary because there are negative performance implications. * Creating advanced search-time field extractions that involve one or more of the following: * Reuse of the same field-extracting regular expression across multiple sources, source types, or hosts. * Application of more than one regex to the same source, source type, or host. * Using a regex to extract one or more values from the values of another field. * Delimiter-based field extractions (they involve field-value pairs that are separated by commas, colons, semicolons, bars, or something similar). * Extraction of multiple values for the same field (multivalued field extraction). * Extraction of fields with names that begin with numbers or underscores. * NOTE: Less complex search-time field extractions can be set up entirely in props.conf. * Setting up lookup tables that look up fields from external sources. All of the above actions require corresponding settings in props.conf. You can find more information on these topics by searching the Splunk documentation ( There is a transforms.conf file in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a transforms.conf $SPLUNK_HOME/etc/system/local/. For examples, see the transforms.conf.example file. You can enable configurations changes made to transforms.conf by typing the following search string in Splunk Web: extract reload=t To learn more about configuration files (including precedence) please see the documentation located at 282

283 GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<unique_transform_stanza_name>] * Name your stanza. Use this name when you configure field extractions, lookup tables, and event routing in props.conf. For example, if you are setting up an advanced search-time field extraction, in props.conf you would add REPORT-<class> = <unique_transform_stanza_name> under the [<spec>] stanza that corresponds with a stanza you've created in transforms.conf. * Follow this stanza name with any number of the following attribute/value pairs, as appropriate for what you intend to do with the transform. * If you do not specify an entry for each attribute, Splunk uses the default value. REGEX = <regular expression> * Enter a regular expression to operate on your data. * NOTE: This attribute is valid for both index-time and search-time field extraction. * REGEX is required for all search-time transforms unless you are setting up a delimiter-based field extraction, in which case you use DELIMS (see the DELIMS attribute description, below). * REGEX is required for all index-time transforms. * REGEX and the FORMAT attribute: * Name-capturing groups in the REGEX are extracted directly to fields. This means that you do not need to specify the FORMAT attribute for simple field extraction cases (see the description of FORMAT, below). * If the REGEX extracts both the field name and its corresponding field value, you can use the following special capturing groups if you want to skip specifying the mapping in FORMAT: _KEY_<string>, _VAL_<string>. * For example, the following are equivalent: * Using FORMAT: * REGEX = ([a-z]+)=([a-z]+) * FORMAT = $1::$2 * Without using FORMAT * REGEX = (?<_KEY_1>[a-z]+)=(?<_VAL_1>[a-z]+) * When using either of the above formats, in a search-time extraction, the regex will continue to match against the source text, extracting as many fields as can be identified in the source text. * Defaults to an empty string. FORMAT = <string> * NOTE: This option is valid for both index-time and search-time field extraction. However, FORMAT behaves differently depending on whether the extraction is performed at index time or search time. * This attribute specifies the format of the event, including any field names or values you want to add. * FORMAT for index-time extractions: * Use $n (for example $1, $2, etc) to specify the output of each REGEX match. * If REGEX does not have n groups, the matching fails. * The special identifier $0 represents what was in the DEST_KEY before the REGEX was performed. * At index time only, you can use FORMAT to create concatenated fields: * FORMAT = ipaddress::$1.$2.$3.$4 * When you create concatenated fields with FORMAT, "$" is the only special character. It is treated as a prefix for regex-capturing groups only if it is followed by a number and only if the number applies to an existing capturing group. So if REGEX has only one capturing group and its value is "bar", then: * "FORMAT = foo$1" yields "foobar" * "FORMAT = foo$bar" yields "foo$bar" * "FORMAT = foo$1234" yields "foo$1234" * "FORMAT = foo$1\$2" yields "foobar\$2" * At index-time, FORMAT defaults to <stanza-name>::$1 * FORMAT for search-time extractions: * The format of this field as used during search time extractions is as follows: * FORMAT = <field-name>::<field-value>( <field-name>::<field-value>)* * where: * field-name = [<string> $<extracting-group-number>] * field-value = [<string> $<extracting-group-number>] 283

284 * Search-time extraction examples: * 1. FORMAT = first::$1 second::$2 third::other-value * 2. FORMAT = $1::$2 * If the key-name of a FORMAT setting is varying, for example $1 in the example 2 just above, then the regex will continue to match against the source key to extract as many matches as are present in the text. * NOTE: You cannot create concatenated fields with FORMAT at search time. That functionality is only available at index time. * At search-time, FORMAT defaults to an empty string. CLONE_SOURCETYPE = <string> * Specifies the sourcetype of a cloned data stream. * The value string must be nonempty. * The value string should be different from the sourcetype of the original data stream. If it is the same, no cloning happens and a warning will be logged. LOOKAHEAD = <integer> * NOTE: This option is valid for all index time transforms, such as index-time field creation, or DEST_KEY modifications. * Optional. Specifies how many characters to search into an event. * Defaults to You may want to increase this value if you have event line lengths that exceed 4096 characters (before linebreaking). WRITE_META = [true false] * NOTE: This attribute is only valid for index-time field extractions. * Automatically writes REGEX to metadata. * Required for all index-time field extractions except for those where DEST_KEY = _meta (see the description of the DEST_KEY attribute, below) * Use instead of DEST_KEY = _meta. * Defaults to false. DEST_KEY = <KEY> * NOTE: This attribute is only valid for index-time field extractions. * Specifies where Splunk stores the expanded FORMAT results in accordance with the REGEX match. * Required for index-time field extractions where WRITE_META = false or is not set. * For index-time extractions, DEST_KEY can be set to a number of values mentioned in the KEYS section at the bottom of this file. * If DEST_KEY = _meta (not recommended) you should also add $0 to the start of your FORMAT attribute. $0 represents the DEST_KEY value before Splunk performs the REGEX (in other words, _meta). * The $0 value is in no way derived *from* the REGEX match. (It does not represent a captured group.) * KEY names are case-sensitive, and should be used exactly as they appear in the KEYs list at the bottom of this file. (For example, you would say DEST_KEY = MetaData:Host, *not* DEST_KEY = metadata:host.) DEFAULT_VALUE = <string> * NOTE: This attribute is only valid for index-time field extractions. * Optional. Splunk writes the DEFAULT_VALUE to DEST_KEY if the REGEX fails. * Defaults to empty. SOURCE_KEY = <string> * NOTE: This attribute is valid for both index-time and search-time field extractions. * Optional. Defines the KEY that Splunk applies the REGEX to. * For search time extractions, you can use this attribute to extract one or more values from the values of another field. You can use any field that is available at the time of the execution of this field extraction. * For index-time extractions use the KEYs described at the bottom of this file. * KEYs are case-sensitive, and should be used exactly as they appear in the KEYs list at the bottom of this file. (For example, you would say SOURCE_KEY = MetaData:Host, *not* SOURCE_KEY = metadata:host.) * If <string> starts with "field:" or "fields:" the meaning is changed. Instead of looking up a KEY, it instead looks up an already indexed field. For example, if a CSV field name "price" was indexed then "SOURCE_KEY = field:price" causes the REGEX to match against the contents of that field. It's also possible to list multiple fields here with "SOURCE_KEY = fields:name1,name2,name3" which causes MATCH to be run against a string comprising of all three values, separated by space characters. * SOURCE_KEY is typically used in conjunction with REPEAT_MATCH in index-time field transforms. * Defaults to _raw, which means it is applied to the raw, unprocessed text of all events. REPEAT_MATCH = [true false] 284

285 * NOTE: This attribute is only valid for index-time field extractions. * Optional. When set to true Splunk runs the REGEX multiple times on the SOURCE_KEY. * REPEAT_MATCH starts wherever the last match stopped, and continues until no more matches are found. Useful for situations where an unknown number of REGEX matches are expected per event. * Defaults to false. DELIMS = <quoted string list> * NOTE: This attribute is only valid for search-time field extractions. * IMPORTANT: If a value may contain an embedded unescaped double quote character, such as "foo"bar", use REGEX, not DELIMS. An escaped double quote (\") is ok. * Optional. Used in place of REGEX when dealing with delimiter-based field extractions, where field values (or field/value pairs) are separated by delimiters such as colons, spaces, line breaks, and so on. * Sets delimiter characters, first to separate data into field/value pairs, and then to separate field from value. * Each individual character in the delimiter string is used as a delimiter to split the event. * Delimiters must be quoted with " " (use \ to escape). * When the event contains full delimiter-separated field/value pairs, you enter two sets of quoted characters for DELIMS: * The first set of quoted delimiters extracts the field/value pairs. * The second set of quoted delimiters separates the field name from its corresponding value. * When the event only contains delimiter-separated values (no field names) you use just one set of quoted delimiters to separate the field values. Then you use the FIELDS attribute to apply field names to the extracted values (see FIELDS, below). * Alternately, Splunk reads even tokens as field names and odd tokens as field values. * Splunk consumes consecutive delimiter characters unless you specify a list of field names. * The following example of DELIMS usage applies to an event where field/value pairs are separated by ' ' symbols and the field names are separated from their corresponding values by '=' symbols: [pipe_eq] DELIMS = " ", "=" * Defaults to "". FIELDS = <quoted string list> * NOTE: This attribute is only valid for search-time field extractions. * Used in conjunction with DELIMS when you are performing delimiter-based field extraction and only have field values to extract. * FIELDS enables you to provide field names for the extracted field values, in list format according to the order in which the values are extracted. * NOTE: If field names contain spaces or commas they must be quoted with " " (to escape, use \). * The following example is a delimiter-based field extraction where three field values appear in an event. They are separated by a comma and then a space. [commalist] DELIMS = ", " FIELDS = field1, field2, field3 * Defaults to "". MV_ADD = [true false] * NOTE: This attribute is only valid for search-time field extractions. * Optional. Controls what the extractor does when it finds a field which already exists. * If set to true, the extractor makes the field a multivalued field and appends the * newly found value, otherwise the newly found value is discarded. * Defaults to false CLEAN_KEYS = [true false] * NOTE: This attribute is only valid for search-time field extractions. * Optional. Controls whether Splunk "cleans" the keys (field names) it extracts at search time. "Key cleaning" is the practice of replacing any non-alphanumeric characters (characters other than those falling between the a-z, A-Z, or 0-9 ranges) in field names with underscores, as well as the stripping of leading underscores and 0-9 characters from field names. * Add CLEAN_KEYS = false to your transform if you need to extract field names that include non-alphanumeric characters, or which begin with underscores or 0-9 characters. * Defaults to true. KEEP_EMPTY_VALS = [true false] * NOTE: This attribute is only valid for search-time field extractions. * Optional. Controls whether Splunk keeps field/value pairs when the value is an empty string. * This option does not apply to field/value pairs that are generated by Splunk's autokv extraction. Autokv ignores field/value pairs with empty values. 285

286 * Defaults to false. CAN_OPTIMIZE = [true false] * NOTE: This attribute is only valid for search-time field extractions. * Optional. Controls whether Splunk can optimize this extraction out (another way of saying the extraction is disabled). * You might use this if you're running searches under a Search Mode setting that disables field discovery--it ensures that Splunk *always* discovers specific fields. * Splunk only disables an extraction if it can determine that none of the fields identified by the extraction will ever be needed for the successful evaluation of a search. * NOTE: This option should be rarely set to false. * Defaults to true. ******* Lookup tables ******* NOTE: Lookup tables are used ONLY during search time filename = <string> * Name of static lookup file. * File should be in $SPLUNK_HOME/etc/<app_name>/lookups/ for some <app_name>, or in $SPLUNK_HOME/etc/system/lookups/ * If file is in multiple 'lookups' directories, no layering is done. * Standard conf file precedence is used to disambiguate. * Defaults to empty string. collection = <string> * Name of the collection to use for this lookup. * Collection should be defined in $SPLUNK_HOME/etc/<app_name>/collections.conf for some <app_name> * If collection is in multiple collections.conf file, no layering is done. * Standard conf file precedence is used to disambiguate. * Defaults to empty string (in which case the name of the stanza is used). max_matches = <integer> * The maximum number of possible matches for each input lookup value (range ). * If the lookup is non-temporal (not time-bounded, meaning the time_field attribute is not specified), Splunk uses the first <integer> entries, in file order. * If the lookup is temporal, Splunk uses the first <integer> entries in descending time order. In other words, up <max_matches> lookup entries will be allowed to match, and if more than this many the ones nearest to the lookup value will be used. * Default = 1000 if the lookup is not temporal, default = 1 if it is temporal. min_matches = <integer> * Minimum number of possible matches for each input lookup value. * Default = 0 for both temporal and non-temporal lookups, which means that Splunk outputs nothing if it cannot find any matches. * However, if min_matches > 0, and Splunk get less than min_matches, then Splunk provides the default_match value provided (see below). default_match = <string> * If min_matches > 0 and Splunk has less than min_matches for any given input, it provides this default_match value one or more times until the min_matches threshold is reached. * Defaults to empty string. case_sensitive_match = <bool> * If set to false, case insensitive matching will be performed for all fields in a lookup table * Defaults to true (case sensitive matching) match_type = <string> * A comma and space-delimited list of <match_type>(<field_name>) specification to allow for non-exact matching * The available match_type values are WILDCARD, CIDR, and EXACT. EXACT is the default and does not need to be specified. Only fields that should use WILDCARD or CIDR matching should be specified in this list external_cmd = <string> * Provides the command and arguments to invoke to perform a lookup. Use this for external (or "scripted") lookups, where you interface with with an external script rather than a lookup table. 286

287 * This string is parsed like a shell command. * The first argument is expected to be a python script (or executable file) located in $SPLUNK_HOME/etc/<app_name>/bin (or../etc/searchscripts). * Presence of this field indicates that the lookup is external and command based. * Defaults to empty string. fields_list = <string> * A comma- and space-delimited list of all fields that are supported by the external command. external_type = [python executable kvstore] * Type of external command. * "python" a python script * "executable" a binary executable * Defaults to "python". time_field = <string> * Used for temporal (time bounded) lookups. Specifies the name of the field in the lookup table that represents the timestamp. * Defaults to an empty string, meaning that lookups are not temporal by default. time_format = <string> * For temporal lookups this specifies the 'strptime' format of the timestamp field. * You can include subseconds but Splunk will ignore them. * Defaults to %s.%q or seconds from unix epoch in UTC an optional milliseconds. max_offset_secs = <integer> * For temporal lookups, this is the maximum time (in seconds) that the event timestamp can be later than the lookup entry time for a match to occur. * Default is (no maximum, effectively). min_offset_secs = <integer> * For temporal lookups, this is the minimum time (in seconds) that the event timestamp can be later than the lookup entry timestamp for a match to occur. * Defaults to 0. batch_index_query = <bool> * For large file based lookups, this determines whether queries can be grouped to improve search performance. * Default is unspecified here, but defaults to true (at global level in limits.conf) allow_caching = <bool> * Allow output from lookup scripts to be cached * Default is true max_ext_batch = <integer> * The maximum size of external batch (range ). * Only used with kvstore. * Default = 300. ******* KEYS: ******* * NOTE: Keys are case-sensitive. Use the following keys exactly as they appear. queue : Specify which queue to send the event to (can be nullqueue, indexqueue). * indexqueue is the usual destination for events going through the transform-handling processor. * nullqueue is a destination which will cause the events to be dropped entirely. _raw : The raw text of the event. _meta : A space-separated list of metadata for an event. _time : The timestamp of the event, in seconds since 1/1/1970 UTC. MetaData:Host : The host associated with the event. The value must be prefixed by "host::" _MetaData:Index : The index where the event should be stored. MetaData:Source : The source associated with the event. The value must be prefixed by "source::" MetaData:Sourcetype : The sourcetype of the event. 287

288 The value must be prefixed by "sourcetype::" _TCP_ROUTING : Comma separated list of tcpout group names (from outputs.conf) Defaults to groups present in 'defaultgroup' for [tcpout]. _SYSLOG_ROUTING : Comma separated list of syslog-stanza names (from outputs.conf) Defaults to groups present in 'defaultgroup' for [syslog]. * NOTE: Any KEY (field name) prefixed by '_' is not indexed by Splunk, in general. [accepted_keys] <name> = <key> * Modifies Splunk's list of key names it considers valid when automatically checking your transforms for use of undocumented SOURCE_KEY or DEST_KEY values in index-time transformations. * By adding entries to [accepted_keys], you can tell Splunk that a key that is not documented is a key you intend to work for reasons that are valid in your environment / app / etc. * The 'name' element is simply used to disambiguate entries, similar to -class entries in props.conf. The name can be anything of your chosing, including a descriptive name for why you use the key. * The entire stanza defaults to not being present, causing all keys not documented just above to be flagged. transforms.conf.example Version This is an example transforms.conf. Use this file to create regexes and rules for transforms. Use this file in tandem with props.conf. To use one or more of these configurations, copy the configuration block into transforms.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Note: These are examples. Replace the values with your own customizations. Indexed field: [netscreen-error] REGEX = device_id=\[w+\](?<err_code>[^:]+) FORMAT = err_code::$1 WRITE_META = true Override host: [hostoverride] DEST_KEY = MetaData:Host REGEX = \s(\w*)$ FORMAT = host::$1 Extracted fields: [netscreen-error-field] REGEX = device_id=\[w+\](?<err_code>[^:]+) FORMAT = err_code::$1 Static lookup table [mylookuptable] filename = mytable.csv 288

289 one to one lookup guarantees that we output a single lookup value for each input value, if no match exists, we use the value of "default_match", which by default is "NONE" [mylook] filename = mytable.csv max_matches = 1 min_matches = 1 default_match = nothing external command lookup table [myexternaltable] external_cmd = testadapter.py blah fields_list = foo bar Temporal based static lookup table [staticwtime] filename = mytable.csv time_field = timestamp time_format = %d/%m/%y %H:%M:%S Mask sensitive data: [session-anonymizer] REGEX = (?m)^(.*)sessionid=\w+(\w{4}[&"].*)$ FORMAT = $1SessionId=$2 DEST_KEY = _raw Route to an alternate index: [AppRedirect] REGEX = Application DEST_KEY = _MetaData:Index FORMAT = Verbose Extract comma-delimited values into fields: [extract_csv] DELIMS = "," FIELDS = "field1", "field2", "field3" This example assigns the extracted values from _raw to field1, field2 and field3 (in order of extraction). If more than three values are extracted the values without a matching field name are ignored. [pipe_eq] DELIMS = " ", "=" The above example extracts key-value pairs which are separated by ' ' while the key is delimited from value by '='. [multiple_delims] DELIMS = " ;", "=:" The above example extracts key-value pairs which are separated by ' ' or ';'. while the key is delimited from value by '=' or ':'. BASIC MODULAR REGULAR EXPRESSIONS DEFINITION START When adding a new basic modular regex PLEASE add a comment that lists the fields that it extracts (named capturing groups), or whether it provides a placeholder for the group name as: Extracts: field1, field2... [all_lazy] 289

290 REGEX =.*? [all] REGEX =.* [nspaces] matches one or more NON space characters REGEX = \S+ [alphas] matches a string containing only letters a-za-z REGEX = [a-za-z]+ [alnums] matches a string containing letters + digits REGEX = [a-za-z0-9]+ [qstring] matches a quoted "string" - extracts an unnamed variable - name MUST be provided as in [[qstring:name]] Extracts: empty-name-group (needs name) REGEX = "(?<>[^"]*+)" [sbstring] matches a string enclosed in [] - extracts an unnamed variable - name MUST be provided as in [[sbstring:name]] Extracts: empty-name-group (needs name) REGEX = \[(?<>[^\]]*+)\] [digits] REGEX = \d+ [int] matches an integer or a hex number REGEX = 0x[a-fA-F0-9]+ \d+ [float] matches a float (or an int) REGEX = \d*\.\d+ [[int]] [octet] this would match only numbers from (one octet in an ip) REGEX = (?:2(?:5[0-5] [0-4][0-9]) [0-1][0-9][0-9] [0-9][0-9]?) [ipv4] matches a valid IPv4 optionally followed by :port_num the octets in the ip would also be validated range Extracts: ip, port REGEX = (?<ip>[[octet]](?:\.[[octet]]){3})(?::[[int:port]])? [simple_url] matches a url of the form proto://domain.tld/uri Extracts: url, domain REGEX = (?<url>\w++://(?<domain>[a-za-z0-9\-.:]++)(?:/[^\s"]*)?) [url] matches a url of the form proto://domain.tld/uri Extracts: url, proto, domain, uri REGEX = (?<url>[[alphas:proto]]://(?<domain>[a-za-z0-9\-.:]++)(?<uri>/[^\s"]*)?) [simple_uri] matches a uri of the form /path/to/resource?query Extracts: uri, uri_path, uri_query REGEX = (?<uri>(?<uri_path>[^\s\?"]++)(?:\\?(?<uri_query>[^\s"]+))?) [uri] uri = path optionally followed by query [/this/path/file.js?query=part&other=var] path = root part followed by file [/root/part/file.part] Extracts: uri, uri_path, uri_root, uri_file, uri_query, uri_domain (optional if in proxy mode) REGEX = (?<uri>(?:\w++://(?<uri_domain>[^/\s]++))?(?<uri_path>(?<uri_root>/+(?:[^\s\?;=/]*+/+)*)(? <uri_file>[^\s\?;=?/]*+))(?:\?(?<uri_query>[^\s"]+))?) BASIC MODULAR REGULAR EXPRESSIONS DEFINITION END 290

291 ui-prefs.conf 다음은 ui-prefs.conf의 사양 및 예제 파일입니다. ui-prefs.conf.spec Version This file contains possible attribute/value pairs for ui preferences for a view. There is a default ui-prefs.conf in $SPLUNK_HOME/etc/system/default. To set custom configurations, place a ui-prefs.conf in $SPLUNK_HOME/etc/system/local/. To set custom configuration for an app, place ui-prefs.conf in $SPLUNK_HOME/etc/apps/<app_name>/local/. For examples, see ui-prefs.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<stanza name>] * Stanza name is the name of the xml view file dispatch.earliest_time = dispatch.latest_time = Pref only options display.prefs.autoopensearchassistant = 0 1 display.prefs.timeline.height = <string> display.prefs.timeline.minimized = 0 1 display.prefs.timeline.minimalmode = 0 1 display.prefs.aclfilter = [none app owner] display.prefs.listmode = [tiles table] display.prefs.searchcontext = <string> display.prefs.events.count = [ ] display.prefs.statistics.count = [ ] display.prefs.fieldcoverage = [ ] display.prefs.enablemetadata = 0 1 display.prefs.showdatasummary = 0 1 ****** Display Formatting Options ****** General options display.general.enablepreview = 0 1 Event options TODO: uncomment the fields when we are ready to merge the values display.events.fields = <string> display.events.type = [raw list table] display.events.rownumbers = 0 1 display.events.maxlines = [ ] display.events.raw.drilldown = [inner outer full none] display.events.list.drilldown = [inner outer full none] display.events.list.wrap = 0 1 display.events.table.drilldown = 0 1 display.events.table.wrap = 0 1 Statistics options display.statistics.rownumbers = 0 1 display.statistics.wrap =

292 display.statistics.drilldown = [row cell none] Visualization options display.visualizations.type = [charting singlevalue] display.visualizations.chartheight = <int> display.visualizations.charting.chart = [line area column bar pie scatter radialgauge fillergauge markergauge] display.visualizations.charting.chart.style = [minimal shiny] display.visualizations.charting.legend.labelstyle.overflowmode = [ellipsisend ellipsismiddle ellipsisstart] Patterns options display.page.search.patterns.sensitivity = <float> Page options display.page.search.mode = [fast smart verbose] display.page.search.timeline.format = [hidden compact full] display.page.search.timeline.scale = [linear log] display.page.search.showfields = 0 1 display.page.home.showgettingstarted = 0 1 ui-prefs.conf.example Version This file contains example of ui preferences for a view. To use one or more of these configurations, copy the configuration block into ui-prefs.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at The following ui preferences will default timerange picker on the search page from All time to Today We will store this ui-prefs.conf in $SPLUNK_HOME/etc/apps/search/local/ to only update search view of search app. [search] dispatch.earliest_time dispatch.latest_time = now user-prefs.conf 다음은 user-prefs.conf의 사양 및 예제 파일입니다. user-prefs.conf.spec This file describes some of the settings that are used, and can be configured on a per-user basis for use by the Splunk Web UI. Settings in this file are requested with user and application scope of the relevant user, and the user-prefs app. Additionally, settings by the same name which are available in the roles the user belongs to will be used at lower precedence. This means interactive setting of these values will cause the values to be updated in $SPLUNK_HOME/etc/users/user-prefs/<username>/local/user-prefs.conf where <username> is the username for the user altering their preferences. It also means that values in another app will never be used unless they are exported globally (to system scope) or to the user-prefs app. In practice, providing values in other apps isn't very interesting, since values from the authorize.conf roles settings are more typically sensible ways to defaults for values in user-prefs. [general] 292

293 default_namespace = <app name> * Specifies the app that the user will see initially upon login to the Splunk Web User Interface. * This uses the "short name" of the app, such as launcher, or search, which is synonymous with the app directory name. * Splunk defaults this to 'launcher' via the default authorize.conf tz = <timezone> * Specifies the per-user timezone to use * If unset, the timezone of the Splunk Server or Search Head is used. * Only canonical timezone names such as America/Los_Angeles should be used (for best results use the Splunk UI). * Defaults to unset. [default] Additional settings exist, but are entirely UI managed. <setting> = <value> user-prefs.conf.example Version This is an example user-prefs.conf. Use this file to configure settings on a per-user basis for use by the Splunk Web UI. To use one or more of these configurations, copy the configuration block into user-prefs.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at Note: These are examples. Replace the values with your own customizations. EXAMPLE: Setting the default timezone to GMT for all Power and User role members. [role_power] tz = GMT [role_user] tz = GMT user-seed.conf 다음은 user-seed.conf의 사양 및 예제 파일입니다. user-seed.conf.spec Version Specification for user-seed.conf. Allows configuration of Splunk's initial username and password. Currently, only one user can be configured with user-seed.conf. To override the default username and password, place user-seed.conf in $SPLUNK_HOME/etc/system/local. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [user_info] USERNAME = <string> * Username you want to associate with a password. * Default is Admin. PASSWORD = <string> 293

294 * Password you wish to set for that user. * Default is changeme. user-seed.conf.example Version This is an example user-seed.conf. Use this file to create an initial login. NOTE: To change the default start up login and password, this file must be in $SPLUNK_HOME/etc/system/default/ prior to starting Splunk for the first time. To use this configuration, copy the configuration block into user-seed.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [user_info] USERNAME = admin PASSWORD = myowndefaultpass viewstates.conf 다음은 viewstates.conf의 사양 및 예제 파일입니다. viewstates.conf.spec Version This file explains how to format viewstates. To use this configuration, copy the configuration block into viewstates.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. [<view_name>:<viewstate_id>] * Auto-generated persistence stanza label that corresponds to UI views * The <view_name> is the URI name (not label) of the view to persist * if <view_name> = "*", then this viewstate is considered to be 'global' * The <viewstate_id> is the unique identifier assigned to this set of parameters * <viewstate_id> = '_current' is a reserved name for normal view 'sticky state' * <viewstate_id> = '_empty' is a reserved name for no persistence, i.e., all defaults <module_id>.<setting_name> = <string> * The <module_id> is the runtime id of the UI module requesting persistence * The <setting_name> is the setting designated by <module_id> to persist viewstates.conf.example 294

295 Version This is an example viewstates.conf. To learn more about configuration files (including precedence) please see the documentation located at [charting:g3b5fa7l] ChartTypeFormatter_0_7_0.default = area Count_0_6_0.count = 10 LegendFormatter_0_13_0.default = right LineMarkerFormatter_0_10_0.default = false NullValueFormatter_0_12_0.default = gaps [*:g3jck9ey] Count_0_7_1.count = 20 DataOverlay_0_12_0.dataOverlayMode = none DataOverlay_1_13_0.dataOverlayMode = none FieldPicker_0_6_1.fields = host sourcetype source date_hour date_mday date_minute date_month FieldPicker_0_6_1.sidebarDisplay = True FlashTimeline_0_5_0.annotationSearch = search index=twink FlashTimeline_0_5_0.enableAnnotations = true FlashTimeline_0_5_0.minimized = false MaxLines_0_13_0.maxLines = 10 RowNumbers_0_12_0.displayRowNumbers = true RowNumbers_1_11_0.displayRowNumbers = true RowNumbers_2_12_0.displayRowNumbers = true Segmentation_0_14_0.segmentation = full SoftWrap_0_11_0.enable = true [dashboard:_current] TimeRangePicker_0_1_0.selected = All time web.conf 다음은 web.conf의 사양 및 예제 파일입니다. web.conf.spec Version This file contains possible attributes and values you can use to configure Splunk's web interface. There is a web.conf in $SPLUNK_HOME/etc/system/default/. To set custom configurations, place a web.conf in $SPLUNK_HOME/etc/system/local/. For examples, see web.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at [settings] * Set general SplunkWeb configuration options under this stanza name. * Follow this stanza name with any number of the following attribute/value pairs. * If you do not specify an entry for each attribute, Splunk will use the default value. startwebserver = [0 1] * Set whether or not to start SplunkWeb. * 0 disables SplunkWeb, 1 enables it. * Defaults to 1. httpport = <port_number> * Must be present for SplunkWeb to start. * If omitted or 0 the server will NOT start an http listener. * If using SSL, set to the HTTPS port number. * Defaults to mgmthostport = <IP:port> * Location of splunkd. 295

296 * Don't include http[s]:// -- just the IP address. * Defaults to :8089. appserverports = <one or more port numbers> * Port number(s) for the python-based application server to listen on. This port is bound only on the loopback interface -- it is not exposed to the network at large. * If set to "0", this will prevent the application server from being run from splunkd. Instead, splunkweb will be started as a separate python-based service which directly listens to the 'httpport'. This is how Splunk 6.1.X and earlier behaved. * Generally, you should only set one port number here. For most deployments a single application server won't be a performance bottleneck. However you can provide a comma-separated list of port numbers here and splunkd will start a load-balanced application server on each one. * It is recommended that this be set to a non-zero value. Setting this to "0" should only be done if you experience a compatibility problem. The new separate application server configuration is faster and supports more configuration options. Also, setting this to "0" may cause problems when using the Search Head Clustering feature (see the [shclustering] stanza in server.conf) * Defaults to splunkdconnectiontimeout = <integer> * Number of seconds to wait before timing out when communicating with splunkd * Must be at least 30 * Values smaller than 30 will be ignored, resulting in the use of the default value * Defaults to 30 enablesplunkwebssl = [True False] * Toggle between http or https. * Set to true to enable https and SSL. * Defaults to False. privkeypath = etc/auth/splunkweb/privkey.pem * The path to the file containing the web server's SSL certificate's private key * Relative paths are interpreted as relative to $SPLUNK_HOME * Relative paths may not refer outside of $SPLUNK_HOME (eg. no../somewhere) * An absolute path can also be specified to an external key * See also enablesplunkwebssl and cacertpath cacertpath = etc/auth/splunkweb/cert.pem * The path to the file containing the SSL certificate for the splunk web server * The file may also contain root and intermediate certificates, if required They should be listed sequentially in the order: [ Server's SSL certificate ] [ One or more intermediate certificates, if required ] [ Root certificate, if required ] * Relative paths are interpreted as relative to $SPLUNK_HOME * Relative paths may not refer outside of $SPLUNK_HOME (eg. no../somewhere) * An absolute path can also be specified to an external certificate * See also enablesplunkwebssl and privkeypath serviceformposturl = * This attribute is deprecated since userregistrationurl = updatecheckerbaseurl = docscheckerbaseurl = * These are various Splunk.com urls that are configurable. * Setting updatecheckerbaseurl to 0 will stop the SplunkWeb from pinging Splunk.com for new versions of itself. enable_insecure_login = [True False] * Indicates if the GET-based /account/insecurelogin endpoint is enabled * Provides an alternate GET-based authentication mechanism * If True, the /account/insecurelogin?username=username&password=passwd is available * If False, only the main /account/login endpoint is available * Defaults to False login_content = <content_string> 296

297 * Add custom content to the login page * Supports any text including html sslversions = <list of ssl versions string> * Comma-separated list of SSL versions to support * The versions available are "ssl2", "ssl3", "tls1.0", "tls1.1", and "tls1.2" * The special version "*" selects all supported versions. The version "tls" selects all versions tls1.0 or newer * If a version is prefixed with "-" it is removed from the list * When configured in FIPS mode ssl2 and ssl3 are always disabled regardless of this configuration * Defaults to "*,-ssl2". (anything newer than SSLv2) * NOTE: this setting only takes effect when appserverports is set to a non-zero value supportsslv3only = [True False] * When appserverports is set to a non-zero value value (the default mode), this setting is DEPRECATED. SSLv2 is now disabled by default in this mode. The exact set of SSL versions allowed is now configurable via the "sslversions" setting above. * When appserverports is set to zero, this controls wither we disallow SSLv2 connections. ciphersuite = <cipher suite string> * If set, uses the specified cipher string for the HTTP server. * If not set, uses the default cipher string provided by OpenSSL. This is used to ensure that the server does not accept connections using weak encryption protocols. ecdhcurvename = <string> * ECDH curve to use for ECDH key negotiation * We only support named curves specified by their SHORT name. * (see struct ASN1_OBJECT in asn1.h) * The list of valid named curves by their short/long names * can be obtained by executing this command: * $SPLUNK_HOME/bin/splunk cmd openssl ecparam -list_curves * Default is empty string. root_endpoint = <URI_prefix_string> * defines the root URI path on which the appserver will listen * default setting is '/' * Ex: if you want to proxy the splunk UI at then set root_endpoint = /splunkui static_endpoint = <URI_prefix_string> * path to static content * The path here is automatically appended to root_endpoint defined above * default is /static static_dir = <relative_filesystem_path> * The directory that actually holds the static content * This can be an absolute url if you want to put it elsewhere * Default is share/splunk/search_mrsparkle/exposed rss_endpoint = <URI_prefix_string> * path to static rss content * The path here is automatically appended to root_endpoint defined above * default is /rss embed_uri = <URI> * optional URI scheme/host/port prefix for embedded content * This presents an optional strategy for exposing embedded shared * content that does not require authentication in reverse proxy/sso environment. * default is empty and will resolve to the client window.location.protocol + "//" + window.location.host embed_footer = <html_string> * chunk of html to define the footer for an embedded report. * Defaults to "splunk>" but can be changed to whatever the user would like. tools.staticdir.generate_indexes = [1 0] * Indicates if the webserver will serve a directory listing for static directories * Defaults to 0 (false) template_dir = <relative_filesystem_path> * base path to mako templates 297

298 * Defaults to share/splunk/search_mrsparkle/templates module_dir = <relative_filesystem_path> * base path to UI module assets * Defaults to share/splunk/search_mrsparkle/modules enable_gzip = [True False] * Determines if webserver applies gzip compression to responses * Defaults to True use_future_expires = [True False] * Determines if the Expires header of /static files is set to a far-future date * Defaults to True flash_major_version = <integer> flash_minor_version = <integer> flash_revision_version = <integer> * Specifies the minimum Flash plugin version requirements * Flash support, broken into three parts. * We currently require a min baseline of Shockwave Flash 9.0 r124 simple_xml_force_flash_charting = [True False] * Specifies whether or not to force the use of FlashChart when rendering simple xml into view xml * Defaults to False override_json_mime_type_with_text_plain = [True False] * Specifies whether or not to override the MIME type for JSON data served up by splunkweb endpoints with contenttype="text/plain; charset=utf-8" * If True, splunkweb endpoints (other than proxy) that serve JSON data will serve as "text/plain; charset=utf-8" * If False, splunkweb endpoints that serve JSON data will serve as "application/json; charset=utf-8" enable_proxy_write = [True False] * Indicates if the /splunkd proxy endpoint allows POST operations * If True, both GET and POST operations are proxied through to splunkd * If False, only GET operations are proxied through to splunkd * Setting this to False will prevent many client-side packages (such as the Splunk JavaScript SDK) from working correctly * Defaults to True js_logger_mode = [None Firebug Server] * JavaScript Logger mode * Available modes: None, Firebug, Server * Mode None: Does not log anything * Mode Firebug: Use firebug by default if it exists or defer to the older less promiscuous version of firebug lite * Mode Server: Log to a defined server endpoint * See js/logger.js Splunk.Logger.Mode for mode implementation details and if you would like to author your own * Defaults to None js_logger_mode_server_end_point = <URI_relative_path> * Specifies the server endpoint to post javascript log messages * Used when js_logger_mode = Server * Defaults to util/log/js js_logger_mode_server_poll_buffer = <integer> * Specifieds the interval in milliseconds to check, post and cleanse the javascript log buffer * Defaults to 1000 js_logger_mode_server_max_buffer = <integer> * Specifies the maximum size threshold to post and cleanse the javascript log buffer * Defaults to 100 ui_inactivity_timeout = <integer> * Specifies the length of time lapsed (in minutes) for notification when there is no user interface clicking, mouseover, scrolling or resizing. * Notifies client side pollers to stop, resulting in sessions expiring at the tools.sessions.timeout value. * If less than 1, results in no timeout notification ever being triggered (Sessions will stay alive for as long as the browser is open). * Defaults to 60 minutes js_no_cache = [True False] * Toggle js cache control 298

299 * Defaults to False cachebyteslimit = <integer> * When appserverports is set to a non-zero value, splunkd can keep a small cache of static assets in memory. When the total size of the objects in cache grows larger than this, we begin the process of ageing entries out. * Defaults to (i.e. 4 Megabytes) * If set to zero, this cache is completely disabled cacheentrieslimit = <integer> * When appserverports is set to a non-zero value, splunkd can keep a small cache of static assets in memory. When the number of the objects in cache grows larger than this, we begin the process of ageing entries out. * Defaults to * If set to zero, this cache is completely disabled staticcompressionlevel = <integer> * When appserverports is set to a non-zero value, splunkd can keep a small cache of static assets in memory. These are stored compressed and can usually be served directly to the web browser in compressed format. * This level can be a number between 1 and 9. Lower numbers use less CPU time to compress objects, but the resulting compressed objects will be larger. * Defaults to 9. Usually not much CPU time is spent compressing these objects so there is not much benefit to decreasing this. enable_autocomplete_login = [True False] * Indictes if the main login page allows browsers to autocomplete the username * If True, browsers may display an autocomplete drop down in the username field * If False, browsers are instructed not to show autocomplete drop down in the username field * Defaults to True verifycookiesworkduringlogin = [True False] * Normally, the login page will make an attempt to see if cookies work properly in the user's browser before allowing them to log in. If this is set to False, this check is skipped. * Defaults to True. It is recommended that this be left on. * NOTE: this setting only takes effect when appserverports is set to a non-zero value minify_js = [True False] * indicates whether the static JS files for modules are consolidated and minified * enabling improves client-side performance by reducing the number of HTTP requests and the size of HTTP responses minify_css = [True False] * indicates whether the static CSS files for modules are consolidated and minified * enabling improves client-side performance by reducing the number of HTTP requests and the size of HTTP responses * due to browser limitations, disabling this when using IE9 and earlier may result in display problems. trap_module_exceptions = [True False] * Toggle whether the JS for individual modules is wrapped in a try/catch * If True, syntax errors in individual modules will not cause the UI to hang, * other than when using the module in question * Set this to False when developing apps. enable_pivot_adhoc_acceleration = [True False] * Toggle whether the pivot interface will use its own ad-hoc acceleration when a data model is not accelerated. * If True, this ad-hoc acceleration will be used to make reporting in pivot faster and more responsive. * In situations where data is not stored in time order or where the majority of events are far in the past, disabling * this behavior can improve the pivot experience. * DEPRECATED in version 6.1 and later, use pivot_adhoc_acceleration_mode instead pivot_adhoc_acceleration_mode = [Elastic AllTime None] * Specify the type of ad-hoc acceleration used by the pivot interface when a data model is not accelerated. * If Elastic, the pivot interface will only accelerate the time range specified for reporting, and will dynamically * adjust when this time range is changed. 299

300 * If AllTime, the pivot interface will accelerate the relevant data over all time. This will make the interface * more responsive to time-range changes but places a larger load on system resources. * If None, the pivot interface will not use any acceleration. This means any change to the report will require * restarting the search. * Defaults to Elastic jschart_test_mode = [True False] * Toggle whether JSChart module runs in Test Mode * If True, JSChart module attaches HTML classes to chart elements for introspection * This will negatively impact performance, so should be disabled unless actively in use. JSChart data truncation configuration To avoid negatively impacting browser performance, the JSChart library places a limit on the number of points that will be plotted by an individual chart. This limit can be configured here either across all browsers or specifically per-browser. An empty or zero value will disable the limit entirely. jschart_truncation_limit = <int> * Cross-broswer truncation limit, if defined takes precedence over the browser-specific limits below jschart_truncation_limit.chrome = <int> * Chart truncation limit for Chrome only * Defaults to jschart_truncation_limit.firefox = <int> * Chart truncation limit for Firefox only * Defaults to jschart_truncation_limit.safari = <int> * Chart truncation limit for Safari only * Defaults to jschart_truncation_limit.ie11 = <int> * Chart truncation limit for Internet Explorer 11 only * Defaults to jschart_truncation_limit.ie10 = <int> * Chart truncation limit for Internet Explorer 10 only * Defaults to jschart_truncation_limit.ie9 = <int> * Chart truncation limit for Internet Explorer 9 only * Defaults to jschart_truncation_limit.ie8 = <int> * Chart truncation limit for Internet Explorer 8 only * Defaults to 2000 jschart_truncation_limit.ie7 = <int> * Chart truncation limit for Internet Explorer 7 only * Defaults to 2000 max_view_cache_size = <integer> * Specifies the maximum number of views to cache in the appserver. * Defaults to 300. pdfgen_is_available = [0 1] * Specifies whether Integrated PDF Generation is available on this search head * This is used to bypass an extra call to splunkd * Defaults to 1 on platforms where node is supported, defaults to 0 otherwise version_label_format = <printf_string> * internal config * used to override the version reported by the UI to *.splunk.com resources * defaults to: %s auto_refresh_views = [0 1] * Specifies whether the following actions cause the appserver to ask splunkd to reload views from disk. * Logging in via the UI * Switching apps * Clicking the Splunk logo * Defaults to 0. Header options x_frame_options_sameorigin = [True False] * adds a X-Frame-Options header set to "SAMEORIGIN" to every response served by cherrypy 300

301 * Defaults to True SSO remoteuser = <http_header_string> * Remote user HTTP header sent by the authenticating proxy server. * This header should be set to the authenticated user. * Defaults to 'REMOTE_USER'. * Caution: There is a potential security concern regarding Splunk's treatment of HTTP headers. * Your proxy provides the selected username as an HTTP header as specified above. * If the browser or other http agent were to specify the value of this header, probably any proxy would overwrite it, or in the case that the username cannot be determined, refuse to pass along the request or set it blank. * However, Splunk (cherrypy) will normalize headers containing the dash, and the underscore to the same value. For example USER-NAME and USER_NAME will be treated as the same in SplunkWeb. * This means that if the browser provides REMOTE-USER and splunk accepts REMOTE_USER, theoretically the browser could dictate the username. * In practice, however, in all our testing, the proxy adds its headers last, which causes them to take precedence, making the problem moot. * See also the 'remoteusermatchexact' setting which can enforce more exact header matching when running with appserverports enabled. remoteusermatchexact = [0 1] * IMPORTANT: this setting only takes effect when appserverports is set to a non-zero value * When matching the remoteuser header, consider dashes and underscores distinct (so "Remote-User" and "Remote_User" will be considered different headers * Defaults to "0" for compatibility with older versions of Splunk, but setting to "1" is a good idea when setting up SSO with appserverports enabled SSOMode = [permissive strict] * Allows SSO to behave in either permissive or strict mode. * Permissive: Requests to Splunk Web that originate from an untrusted IP address are redirected to a login page where they can log into Splunk without using SSO. * Strict: All requests to splunkweb will be restricted to those originating from a trusted IP except those to endpoints not requiring authentication. * Defaults to "strict" trustedip = <ip_address> * Trusted IP. This is the IP address of the authenticating proxy. * Splunkweb verifies it is receiving data from the proxy host for all SSO requests. * Uncomment and set to a valid IP address to enable SSO. * Disabled by default. Normal value is ' ' * If appserverports is set to a non-zero value, this setting can accept a richer set of configurations, using the same format as the "acceptfrom" setting. allowssowithoutchangingserverconf = [0 1] * IMPORTANT: this setting only takes effect when appserverports is set to a non-zero value * Usually when configuring SSO, a trustedip needs to be set both here in web.conf and also in server.conf. If this is set to "1" then we will enable web-based SSO without a trustedip in server.conf * Defaults to 0 testing_endpoint = <relative_uri_path> * Specifies the root URI path on which to serve splunkweb unit and * integration testing resources. * Development only setting * Defaults to '/testing' testing_dir = <relative_file_path> * Specifies the path relative to $SPLUNK_HOME that contains the testing * files to be served at endpoint defined by 'testing_endpoint'. * Development only setting * Defaults to 'share/splunk/testing' Results export server config 301

302 export_timeout = <integer> * An integral value that specifies the timeout when exporting results. * The splunk server will wait till the given timeout period before closing * the connection with splunkd. cherrypy HTTP server config server.thread_pool = <integer> * Specifies the minimum number of threads the appserver is allowed to maintain * Defaults to 20 server.thread_pool_max = <integer> * Specifies the maximum number of threads the appserver is allowed to maintain * Defaults to -1 (unlimited) server.thread_pool_min_spare = <integer> * Specifies the minimum number of spare threads the appserver keeps idle * Defaults to 5 server.thread_pool_max_spare = <integer> * Specifies the maximum number of spare threads the appserver keeps idle * Defaults to 10 server.socket_host = <ip_address> * Host values may be any IPv4 or IPv6 address, or any valid hostname. * The string 'localhost' is a synonym for ' ' (or '::1', if * your hosts file prefers IPv6). The string ' ' is a special * IPv4 entry meaning "any active interface" (INADDR_ANY), and '::' * is the similar IN6ADDR_ANY for IPv6. * Defaults to if listenonipv6 is set to no, else :: server.socket_timeout = <integer> * The timeout in seconds for accepted connections between the browser and splunkweb * Defaults to 10 listenonipv6 = <no yes only> * By default, splunkweb will listen for incoming connections using IPv4 only * To enable IPv6 support in splunkweb, set this to "yes". Splunkweb will simultaneously listen for connections on both IPv4 and IPv6 * To disable IPv4 entirely, set this to "only", which will cause splunkweb to exclusively accept connections over IPv6. * You will also want to set server.socket_host (use "::" instead of " ") if you wish to listen on an IPv6 address max_upload_size = <integer> * Specifies the hard maximum size of uploaded files in MB * Defaults to 500 log.access_file = <filename> * Specifies the HTTP access log filename * Stored in default Splunk /var/log directory * Defaults to web_access.log log.access_maxsize = <integer> * Specifies the maximum size the web_access.log file should be allowed to grow to (in bytes) * Comment out or set to 0 for unlimited file size * File will be rotated to web_access.log.0 after max file size is reached * See log.access_maxfiles to limit the number of backup files created * Defaults to unlimited file size log.access_maxfiles = <integer> * Specifies the maximum number of backup files to keep after the web_access.log file has reached its maximum size * Warning: setting this to very high numbers (eg ) may impact performance during log rotations * Defaults to 5 if access_maxsize is set log.error_maxsize = <integer> 302

303 * Specifies the maximum size the web_service.log file should be allowed to grow to (in bytes) * Comment out or set to 0 for unlimited file size * File will be rotated to web_service.log.0 after max file size is reached * See log.error_maxfiles to limit the number of backup files created * Defaults to unlimited file size log.error_maxfiles = <integer> * Specifies the maximum number of backup files to keep after the web_service.log file has reached its maximum size * Warning: setting this to very high numbers (eg ) may impact performance during log rotations * Defaults to 5 if access_maxsize is set log.screen = [True False] * Indicates if runtime output is displayed inside an interactive tty * Defaults to True request.show_tracebacks = [True False] * Indicates if a an exception traceback is displayed to the user on fatal exceptions * Defaults to True engine.autoreload_on = [True False] * Indicates if the appserver will auto-restart if it detects a python file has changed * Defaults to False tools.sessions.on = True * Indicates if user session support is enabled * Should always be True tools.sessions.timeout = <integer> * Specifies the number of minutes of inactivity before a user session is expired * The countdown is effectively reset by browser activity minute until ui_inactivity_timeout inactivity timeout is reached. * Use a value of 2 or higher, as a value of 1 will race with the browser refresh, producing unpredictable behavior. (Low values aren't very useful though except for testing.) * Defaults to 60 tools.sessions.restart_persist = [True False] * If set to False then the session cookie will be deleted from the browser when the browser quits * Defaults to True - Sessions persist across browser restarts (assuming the tools.sessions.timeout limit hasn't been reached) tools.sessions.httponly = [True False] * If set to True then the session cookie will be made unavailable to running javascript scripts, increasing session security * Defaults to True tools.sessions.secure = [True False] * If set to True and Splunkweb is configured to server requests using HTTPS (see the enablesplunkwebssl setting) then the browser will only transmit the session cookie over HTTPS connections, increasing session security * Defaults to True response.timeout = <integer> * Specifies the number of seconds to wait for the server to complete a response * Some requests such as uploading large files can take a long time * Defaults to 7200 tools.sessions.storage_type = [file] tools.sessions.storage_path = <filepath> * Specifies the session information storage mechanisms * Comment out the next two lines to use RAM based sessions instead * Use an absolute path to store sessions outside of the splunk tree * Defaults to storage_type=file, storage_path=var/run/splunk tools.decode.on = [True False] * Indicates if all strings that come into Cherrpy controller methods are decoded as unicode (assumes UTF-8 encoding). * WARNING: Disabling this will likely break the application, as all incoming strings are assumed * to be unicode. * Defaults to True 303

304 tools.encode.on = [True False] * Encodes all controller method response strings into UTF-8 str objects in Python. * WARNING: Disabling this will likely cause high byte character encoding to fail. * Defaults to True tools.encode.encoding = <codec> * Force all outgoing characters to be encoded into UTF-8. * This only works with tools.encode.on set to True. * By setting this to utf-8, Cherrypy's default behavior of observing the Accept-Charset header * is overwritten and forces utf-8 output. Only change this if you know a particular browser * installation must receive some other character encoding (Latin-1 iso , etc) * WARNING: Change this at your own risk. * Defaults to utf08 tools.proxy.on = [True False] * Used for running Apache as a proxy for Splunk UI, typically for SSO configuration. See for more information. * For Apache 1.x proxies only. Set this attribute to "true". This configuration instructs CherryPy (the Splunk Web HTTP server) to look for an incoming X-Forwarded-Host header and to use the value of that header to construct canonical redirect URLs that include the proper host name. For more information, refer to the CherryPy documentation on running behind an Apache proxy. This setting is only necessary for Apache 1.1 proxies. For all other proxies, the setting must be "false", which is the default. * Defaults to False tools.proxy.base = <scheme>://<url> * Used for setting the proxy base url in Splunk * Defaults to an empty value pid_path = <filepath> * Specifies the path to the PID file * Equals precisely and only var/run/splunk/splunkweb.pid * NOTE: Do not change this parameter. enabled_decomposers = <intention> [, <intention>]... * Added in Splunk 4.2 as a short term workaround measure for apps which happen to still require search decomposition, which is deprecated with 4.2. * Search decomposition will be entirely removed in a future release. * Comma separated list of allowed intentions. * Modifies search decomposition, which is a splunk-web internal behavior. * Can be controlled on a per-app basis. * If set to the empty string, no search decomposition occurs, which causes some usability problems with report builder. * The current possible values are: addcommand, stats, addterm, addtermgt, addtermlt, setfields, excludefields, audit, sort, plot * Default is 'plot', leaving only the plot intention enabled. simple_xml_module_render = [True False] * If True, simple xml dashboards and forms will render using the module system * Defaults to False simple_xml_perf_debug = [True False] * If True, simple xml dashboards will log some performance metrics to the browser console * Defaults to False job_min_polling_interval = <integer> * Minimum polling interval for job in miliseconds (ms) * The default value is 100 * This is the intial time wait for fetching results * The poll period increases gradually from min interval to max interval when search is in queued state or parsing state (and not running state) for a some time. * Set this value between 100 to job_max_polling_interval job_max_polling_interval = <integer> * Maximum polling interval for job in miliseconds (ms) * The default value is 1000 * This is the maximum time wait for fetching results * The recommended maximum value is 3000 acceptfrom = <network_acl>... * IMPORTANT: this setting only takes effect when appserverports is set to a non-zero value * Lists a set of networks or addresses to accept connections from. These rules are separated by commas or spaces 304

305 * Each rule can be in the following forms: * 1. A single IPv4 or IPv6 address (examples: " ", "fe80::4a3") * 2. A CIDR block of addresses (examples: "10/8", "fe80:1234/32") * 3. A DNS name, possibly with a '*' used as a wildcard (examples: "myhost.example.com", "*.splunk.com") * 4. A single '*' which matches anything * Entries can also be prefixed with '!' to cause the rule to reject the connection. Rules are applied in order, and the first one to match is used. For example, "!10.1/16, *" will allow connections from everywhere except the 10.1.*.* network. * Defaults to "*" (accept from anywhere) maxthreads = <int> * NOTE: this setting only takes effect when appserverports is set to a non-zero value * Number of threads that can be used by active HTTP transactions. This can be limited to constrain resource usage. * If set to 0 (the default) a limit will be automatically picked based on estimated server capacity. * If set to a negative number, no limit will be enforced. maxsockets = <int> * NOTE: this setting only takes effect when appserverports is set to a non-zero value * Number of simultaneous HTTP connections that we accept simultaneously. This can be limited to constrain resource usage. * If set to 0 (the default) a limit will be automatically picked based on estimated server capacity. * If set to a negative number, no limit will be enforced. forcehttp10 = auto never always * NOTE: this setting only takes effect when appserverports is set to a non-zero value * When set to "always", the REST HTTP server will not use some HTTP 1.1 features such as persistent connections or chunked transfer encoding. * When set to "auto" it will do this only if the client sent no User-Agent header, or if the user agent is known to have bugs in its HTTP/1.1 support. * When set to "never" it always will allow HTTP 1.1, even to clients it suspects may be buggy. * Defaults to "auto" crossoriginsharingpolicy = <origin_acl>... * IMPORTANT: this setting only takes effect when appserverports is set to a non-zero value * List of HTTP Origins to return Access-Control-Allow-* (CORS) headers for * These headers tell browsers that we trust web applications at those sites to make requests to the REST interface * The origin is passed as a URL without a path component (for example " * This setting can take a list of acceptable origins, separated by spaces and/or commas * Each origin can also contain wildcards for any part. Examples: *://app.example.com:* (either HTTP or HTTPS on any port) (any host under example.com, including example.com itself) * An address can be prefixed with a '!' to negate the match, with the first matching origin taking precedence. For example, "!*://evil.example.com:* *://*.example.com:*" to not avoid matching one host in a domain * A single "*" can also be used to match all origins * By default the list is empty allowsslcompression = true false * IMPORTANT: this setting only takes effect when appserverports is set to a non-zero value. When appserverports is zero or missing, this setting will always act as if it is set to "true" * If set to true, the server will allow clients to negotiate SSL-layer data compression. * Defaults to false. The HTTP layer has its own compression layer which is usually sufficient. allowsslrenegotiation = true false * IMPORTANT: this setting only takes effect when appserverports is set to a non-zero value * In the SSL protocol, a client may request renegotiation of the connection settings from time to time. * Setting this to false causes the server to reject all renegotiation 305

306 attempts, breaking the connection. This limits the amount of CPU a single TCP connection can use, but it can cause connectivity problems especially for long-lived connections. * Defaults to true sendstricttransportsecurityheader = true false * IMPORTANT: this setting only takes effect when appserverports is set to a non-zero value * If set to true, the REST interface will send a "Strict-Transport-Security" header with all responses to requests made over SSL. * This can help avoid a client being tricked later by a Man-In-The-Middle attack to accept a non-ssl request. However, this requires a commitment that no non-ssl web hosts will ever be run on this hostname on any port. For example, if splunkweb is in default non-ssl mode this can break the ability of browser to connect to it. Enable with caution. * Defaults to false dedicatediothreads = <int> * If set to zero, HTTP I/O will be performed in the same thread that accepted the TCP connection. * If set set to a non-zero value, separate threads will be run to handle the HTTP I/O, including SSL encryption. * Defaults to "0" * Typically this does not need to be changed. For most usage scenarios using the same the thread offers the best performance. * NOTE: this setting only takes effect when appserverports is set to a non-zero value [framework] * Put App Framework settings here django_enable = [True False] * Specifies whether Django should be enabled or not * Defaults to True * Django will not start unless an app requires it django_path = <filepath> * Specifies the root path to the new App Framework files, relative to $SPLUNK_HOME * Defaults to etc/apps/framework django_force_enable = [True False] * Specifies whether to force Django to start, even if no app requires it * Defaults to False custom cherrypy endpoints [endpoint:<python_module_name>] * registers a custom python CherryPy endpoint * the expected file must be located at: $SPLUNK_HOME/etc/apps/<APP_NAME>/appserver/controllers/<PYTHON_NODULE_NAME>.py * this module's methods will be exposed at /custom/<app_name>/<python_nodule_name>/<method_name> exposed splunkd REST endpoints [expose:<unique_name>] * Registers a splunkd-based endpoint that should be made available to the UI under the "/splunkd" and "/splunkd/ raw" hierarchies * The name of the stanza doesn't matter as long as it starts with "expose:" Each stanza name must be unique, however pattern = <url_pattern> * Pattern to match under the splunkd /services hierarchy. For instance, "a/b/c" would match URIs "/services/a/b/c" and "/servicesns/*/*/a/b/c" * The pattern should not include leading or trailing slashes * Inside the pattern an element of "*" will match a single path element. For example, "a/*/c" would match "a/b/c" but not "a/1/2/c" * A path element of "**" will match any number of elements. For example, "a/**/c" would match both "a/1/c" and "a/1/2/3/c" * A path element can end with a "*" to match a prefix. For example, "a/elem-*/b" would match "a/elem-123/c" methods = <method_lists> 306

307 * Comma separated list of methods to allow from the web browser (example: "GET,POST,DELETE") * If not included, defaults to "GET" oidenabled = [0 1] * If set to 1 indicates that the endpoint is capable of taking an embed-id as a query parameter * Defaults to 0 * This is only needed for some internal splunk endpoints, you probably should not specify this for app-supplied endpoints skipcsrfprotection = [0 1] * If set to 1, tells splunkweb that it is safe to post to this endpoint without applying CSRF protection * Defaults to 0 * This should only be set on the login endpoint (which already contains sufficient auth credentials to avoid CSRF problems) web.conf.example Version This is an example web.conf. Use this file to configure data web settings. To use one or more of these configurations, copy the configuration block into web.conf in $SPLUNK_HOME/etc/system/local/. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at This stanza heading must precede any changes. [settings] Change the default port number: httpport = Also run the python application server on a non-default port: appserverports = Turn on SSL: enablesplunkwebssl = true absolute paths may be used here. privkeypath = /home/user/certs/myprivatekey.pem cacertpath = /home/user/certs/mycacert.pem NOTE: non-absolute paths are relative to $SPLUNK_HOME wmi.conf 다음은 wmi.conf의 사양 및 예제 파일입니다. wmi.conf.spec Version This file contains possible attribute/value pairs for configuring Windows Management Instrumentation (WMI) access from Splunk. There is a wmi.conf in $SPLUNK_HOME\etc\system\default\. To set custom configurations, place a wmi.conf in $SPLUNK_HOME\etc\system\local\. For examples, see wmi.conf.example. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS

308 [settings] * The settings stanza specifies various runtime parameters. * The entire stanza and every parameter within it is optional. * If the stanza is missing, Splunk assumes system defaults. initial_backoff = <integer> * How long, in seconds, to wait before retrying the connection to the WMI provider after the first connection error. * If connection errors continue, the wait time doubles until it reaches the integer specified in max_backoff. * Defaults to 5. max_backoff = <integer> * The maximum time, in seconds, to attempt to reconnect to the WMI provider. * Defaults to 20. max_retries_at_max_backoff = <integer> * Once max_backoff is reached, tells Splunk how many times to attempt to reconnect to the WMI provider. * Splunk will try to reconnect every max_backoff seconds. * If reconnection fails after max_retries, give up forever (until restart). * Defaults to 2. checkpoint_sync_interval = <integer> * The minimum wait time, in seconds, for state data (event log checkpoint) to be written to disk. * Defaults to INPUT-SPECIFIC SETTINGS----- [WMI:$NAME] * There are two types of WMI stanzas: * Event log: for pulling event logs. You must set the event_log_file attribute. * WQL: for issuing raw Windows Query Language (WQL) requests. You must set the wql attribute. * Do not use both the event_log_file or the wql attributes. Use one or the other. server = <comma-separated strings> * A comma-separated list of servers from which to get data. * If not present, defaults to the local machine. interval = <integer> * How often, in seconds, to poll for new data. * This attribute is required, and the input will not run if the attribute is not present. * There is no default. disabled = [0 1] * Specifies whether the input is enabled or not. * 1 to disable the input, 0 to enable it. * Defaults to 0 (enabled). hostname = <host> * All results generated by this stanza will appear to have arrived from the string specified here. * This attribute is optional. * If it is not present, the input will detect the host automatically. current_only = [0 1] * Changes the characteristics and interaction of WMI-based event collections. * When current_only is set to 1: * For event log stanzas, this will only capture events that occur while Splunk is running. * For WQL stanzas, event notification queries are expected. The queried class must support sending events. Failure to supply 308

309 the correct event notification query structure will cause WMI to return a syntax error. * An example event notification query that watches for process creation: * SELECT * FROM InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'. * When current_only is set to 0: * For event log stanzas, all the events from the checkpoint are gathered. If there is no checkpoint, all events starting from the oldest events are retrieved. * For WQL stanzas, the query is executed and results are retrieved. The query is a non-notification query. * For example * Select * Win32_Process where caption = "explorer.exe" * Defaults to 0. index = <string> * Specifies the index that this input should send the data to. * This attribute is optional. * When defined, "index=" is automatically prepended to <string>. * Defaults to "index=main" (or whatever you have set as your default index). Event log-specific attributes: event_log_file = <Application, System, etc> * Tells Splunk to expect event log data for this stanza, and specifies the event log channels you want Splunk to monitor. * Use this instead of WQL to specify sources. * Specify one or more event log channels to poll. Multiple event log channels must be separated by commas. * There is no default. disable_hostname_normalization = [0 1] * If set to true, hostname normalization is disabled * If absent or set to false, the hostname for 'localhost' will be converted to %COMPUTERNAME%. * 'localhost' refers to the following list of strings: localhost, , ::1, the name of the DNS domain for the local computer, * the fully qualified DNS name, the NetBIOS name, the DNS host name of the local computer WQL-specific attributes: wql = <string> * Tells Splunk to expect data from a WMI provider for this stanza, and specifies the WQL query you want Splunk to make to gather that data. * Use this if you are not using the event_log_file attribute. * Ensure that your WQL queries are syntactically and structurally correct when using this option. * For example, SELECT * FROM Win32_PerfFormattedData_PerfProc_Process WHERE Name = "splunkd". * If you wish to use event notification queries, you must also set the "current_only" attribute to 1 within the stanza, and your query must be appropriately structured for event notification (meaning it must contain one or more of the GROUP, WITHIN or HAVING clauses.) * For example, SELECT * FROM InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process' * There is no default. namespace = <string> * The namespace where the WMI provider resides. * The namespace spec can either be relative (root\cimv2) or absolute (\\server\root\cimv2). * If the server attribute is present, you cannot specify an absolute namespace. * Defaults to root\cimv2. wmi.conf.example 309

310 Version This is an example wmi.conf. These settings are used to control inputs from WMI providers. Refer to wmi.conf.spec and the documentation at splunk.com for more information about this file. To use one or more of these configurations, copy the configuration block into wmi.conf in $SPLUNK_HOME\etc\system\local\. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at This stanza specifies runtime parameters. [settings] initial_backoff = 5 max_backoff = 20 max_retries_at_max_backoff = 2 checkpoint_sync_interval = 2 Pull events from the Application, System and Security event logs from the local system every 10 seconds. Store the events in the "wmi_eventlog" Splunk index. [WMI:LocalApplication] interval = 10 event_log_file = Application disabled = 0 index = wmi_eventlog [WMI:LocalSystem] interval = 10 event_log_file = System disabled = 0 index = wmi_eventlog [WMI:LocalSecurity] interval = 10 event_log_file = Security disabled = 0 index = wmi_eventlog Gather disk and memory performance metrics from the local system every second. Store event in the "wmi_perfmon" Splunk index. [WMI:LocalPhysicalDisk] interval = 1 wql = select Name, DiskBytesPerSec, PercentDiskReadTime, PercentDiskWriteTime, PercentDiskTime from Win32_PerfFormattedData_PerfDisk_PhysicalDisk disabled = 0 index = wmi_perfmon [WMI:LocalMainMemory] interval = 10 wql = select CommittedBytes, AvailableBytes, PercentCommittedBytesInUse, Caption from Win32_PerfFormattedData_PerfOS_Memory disabled = 0 index = wmi_perfmon Collect all process-related performance metrics for the splunkd process, every second. Store those events in the "wmi_perfmon" index. [WMI:LocalSplunkdProcess] interval = 1 wql = select * from Win32_PerfFormattedData_PerfProc_Process where Name = "splunkd" disabled = 0 index = wmi_perfmon Listen from three event log channels, capturing log events that occur only while Splunk is running, every 10 seconds. Gather data from three remote 310

311 servers srv1, srv2 and srv3. [WMI:TailApplicationLogs] interval = 10 event_log_file = Application, Security, System server = srv1, srv2, srv3 disabled = 0 current_only = 1 Listen for process-creation events on a remote machine, once a second. [WMI:ProcessCreation] interval = 1 server = remote-machine wql = select * from InstanceCreationEvent within 1 where TargetInstance isa 'Win32_Process' disabled = 0 current_only = 1 Receive events whenever someone connects or removes a USB device on the computer, once a second. [WMI:USBChanges] interval = 1 wql = select * from InstanceOperationEvent within 1 where TargetInstance ISA 'Win32_PnPEntity' and TargetInstance.Description='USB Mass Storage Device' disabled = 0 current_only = 1 workflow_actions.conf 다음은 workflow_actions.conf의 사양 및 예제 파일입니다. workflow_actions.conf.spec Version This file contains possible attribute/value pairs for configuring workflow actions in Splunk. There is a workflow_actions.conf in $SPLUNK_HOME/etc/apps/search/default/. To set custom configurations, place a workflow_actions.conf in either $SPLUNK_HOME/etc/system/local/ or add a workflow_actions.conf file to your app's local/ directory. For examples, see workflow_actions.conf.example. You must restart Splunk to enable configurations, unless editing them through the Splunk manager. To learn more about configuration files (including precedence) please see the documentation located at GLOBAL SETTINGS Use the [default] stanza to define any global settings. * You can also define global settings outside of any stanza, at the top of the file. * Each conf file should have at most one default stanza. If there are multiple default stanzas, attributes are combined. In the case of multiple definitions of the same attribute, the last definition in the file wins. * If an attribute is defined at both the global level and in a specific stanza, the value in the specific stanza takes precedence. General required settings: These apply to all workflow action types. type = <string> * The type of the workflow action. * If not set, Splunk skips this workflow action. label = <string> * The label to display in the workflow action menu. * If not set, Splunk skips this workflow action. 311

312 General optional settings: These settings are not required but are available for all workflow actions. fields = <comma or space separated list> * The fields required to be present on the event in order for the workflow action to be applied. * When "display_location" is set to "both" or "field_menu", the workflow action will be applied to the menu's corresponding to the specified fields. * If fields is undefined or set to *, the workflow action is applied to all field menus. * If the * character is used in a field name, it is assumed to act as a "globber". For example host* would match the fields hostname, hostip, etc. * Acceptable values are any valid field name, any field name including the * character, or * (e.g. *_ip). * Defaults to * eventtypes = <comma or space separated list> * The eventtypes required to be present on the event in order for the workflow action to be applied. * Acceptable values are any valid eventtype name, or any eventtype name plus the * character (e.g. host*). display_location = <string> * Dictates whether to display the workflow action in the event menu, the field menus or in both locations. * Accepts field_menu, event_menu, or both. * Defaults to both. disabled = [True False] * Dictates whether the workflow action is currently disabled * Defaults to False Using field names to insert values into workflow action settings Several settings detailed below allow for the substitution of field values using a special variable syntax, where the field's name is enclosed in dollar signs. For example, $_raw$, $hostip$, etc. The settings, label, link.uri, link.postargs, and search.search_string all accept the value of any valid field to be substituted into the final string. For example, you might construct a Google search using an error message field called error_msg like so: link.uri = Some special variables exist to make constructing the settings simpler. $@field_name$ * Allows for the name of the current field being clicked on to be used in a field action. * Useful when constructing searches or links that apply to all fields. * NOT AVAILABLE FOR EVENT MENUS $@field_value$ * Allows for the value of the current field being clicked on to be used in a field action. * Useful when constructing searches or links that apply to all fields. * NOT AVAILABLE FOR EVENT MENUS $@sid$ * The sid of the current search job. $@offset$ * The offset of the event being clicked on in the list of search events. $@namespace$ * The name of the application from which the search was run. $@latest_time$ * The latest time the event occurred. This is used to disambiguate similar events from one another. It is not often available for all fields. Field action types 312

313 Link type: Allows for the construction of GET and POST requests via links to external resources. link.uri = <string> * The URI for the resource to link to. * Accepts field values in the form $<field name>$, (e.g $_raw$). * All inserted values are URI encoded. * Required link.target = <string> * Determines if clicking the link opens a new window, or redirects the current window to the resource defined in link.uri. * Accepts: "blank" (opens a new window), "self" (opens in the same window) * Defaults to "blank" link.method = <string> * Determines if clicking the link should generate a GET request or a POST request to the resource defined in link.uri. * Accepts: "get" or "post". * Defaults to "get". link.postargs.<int>.<key/value> = <value> * Only available when link.method = post. * Defined as a list of key / value pairs like such that foo=bar becomes: link.postargs.1.key = "foo" link.postargs.1.value = "bar" * Allows for a conf compatible method of defining multiple identical keys (e.g.): link.postargs.1.key = "foo" link.postargs.1.value = "bar" link.postargs.2.key = "foo" link.postargs.2.value = "boo"... * All values are html form encoded appropriately. Search type: Allows for the construction of a new search to run in a specified view. search.search_string = <string> * The search string to construct. * Accepts field values in the form $<field name>$, (e.g. $_raw$). * Does NOT attempt to determine if the inserted field values may brake quoting or other search language escaping. * Required search.app = <string> * The name of the Splunk application in which to perform the constructed search. * By default this is set to the current app. search.view = <string> * The name of the view in which to preform the constructed search. * By default this is set to the current view. search.target = <string> * Accepts: blank, self. * Works in the same way as link.target. See link.target for more info. search.earliest = <time> * Accepts absolute and Splunk relative times (e.g. -10h). * Determines the earliest time to search from. search.latest = <time> * Accepts absolute and Splunk relative times (e.g. -10h). * Determines the latest time to search to. search.preserve_timerange = <boolean> * Ignored if either the search.earliest or search.latest values are set. * When true, the time range from the original search which produced the events list will be used. * Defaults to false. 313

314 workflow_actions.conf.example Version This is an example workflow_actions.conf. These settings are used to create workflow actions accessible in an event viewer. Refer to workflow_actions.conf.spec and the documentation at splunk.com for more information about this file. To use one or more of these configurations, copy the configuration block into workflow_actions.conf in $SPLUNK_HOME/etc/system/local/, or into your application's local/ folder. You must restart Splunk to enable configurations. To learn more about configuration files (including precedence) please see the documentation located at These are the default workflow actions and make extensive use of the special parameters: etc. [show_source] type=link fields = _cd, source, host, index display_location = event_menu label = Show Source link.uri = /app/$@namespace$/show_source?sid=$@sid$&offset=$@offset$&latest_time=$@latest_time$ [ifx] type = link display_location = event_menu label = Extract Fields link.uri = /ifx?sid=$@sid$&offset=$@offset$&namespace=$@namespace$ [etb] type = link display_location = event_menu label = Build Eventtype link.uri = /etb?sid=$@sid$&offset=$@offset$&namespace=$@namespace$ This is an example workflow action which will be displayed in a specific field menu (clientip). [whois] display_location = field_menu fields = clientip label = Whois: $clientip$ link.method = get link.target = blank link.uri = type = link This is an example field action which will allow a user to search every field value in Google. [Google] display_location = field_menu fields = * label = Google $@field_name$ link.method = get link.uri = type = link This is an example post link that will send its field name and field value to a fictional bug tracking system. [Create JIRA issue] display_location = field_menu fields = error_msg label = Create JIRA issue for $error_class$ link.method = post link.postargs.1.key = error link.postargs.1.value = $error_msg$ link.target = blank 314

315 link.uri = type = link This is an example search workflow action that will be displayed in an event's menu, but requires the field "controller" to exist in the event in order for the workflow action to be available for that event. [Controller req over time] display_location = event_menu fields = controller label = Requests over last day for $controller$ search.earliest = -3d search.search_string = sourcetype=rails_app controller=$controller$ timechart span=1h count search.target = blank search.view = charting type = search 315