Elasticsearch
엘라스틱서치
는 문서를 인덱싱하고 검색·집계하는 분산 검색 엔진이다. 필드의 과 분석 방식이 어떤 질문에 답할 수 있는지 결정하며 는 그 자료를 탐색하는 별도 화면이다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 보안·운영 이벤트를 문서와 인덱스로 저장한다.
- 검색용 와 필드 타입을 사용해 조건 검색과 집계를 처리한다.
- ·로 데이터를 나누고 복사하여 처리와 가용성을 구성한다.
02어떤 순서로 동작하나
- 문서와 타입 준비
이벤트를 문서로 만들고 인덱스의 으로 필드 타입·분석 방식을 정한다. 동일 필드에 숫자와 객체가 섞이면 타입 충돌로 거부될 수 있다.
- 샤드에 인덱싱
문서가 담당 primary 로 전달되고 설정한 로 복제된다. 분석 결과는 토큰에서 문서를 찾는 에 사용되며 는 정확한 값의 조건과 집계에 쓰인다.
- 질의 분산
검색 요청의 범위와 조건을 관련 에 전달하고 부분 결과를 모아 반환한다. 노드는 고정된 전용 서버라는 뜻이 아니며 여러 를 배치받을 수 있다.
- 검색과 가용성 확인
저장 응답·검색 가능 시점·화면 시간 범위를 구분해 관찰한다. 적절한 다른 노드가 없으면 설정한 가 미할당될 수 있고, 만으로 독립 백업을 대신하지 못한다.
03먼저 알아둘 용어와 구성요소
- 인덱스에 저장·검색되는 하나의 자료 단위.
- 필드의 타입과 분석 방식을 정의하는 계약.
- 인덱스 데이터를 나누어 저장·검색하는 단위.
- Primary 의 복사본으로 장애 대응과 읽기 분산에 사용된다.
- 문서를 조직하는 논리적 검색·저장 대상.
- 값을 검색에 사용할 토큰으로 처리하는 구성.
- 분석한 토큰을 통한 전문 검색에 쓰는 문자열 필드 타입.
- 정확한 값의 필터·정렬·집계 등에 쓰는 문자열 필드 타입.
- 각 토큰을 그 토큰이 있는 문서에 연결하는 검색 구조.
- 객체·배열·값을 텍스트로 표현하는 자료 형식.
Filebeat 입력 설정에서 Kibana 문서 세 건까지 추적하기
설정 파일의 입력·출력과 검색 화면의 문서·시간·필드를 연결한다.
실습 구성과 전제
- 자신의 격리 Elastic 환경과 비밀값을 별도로 관리한 수집 계정을 사용한다.
- 설정 화면과 검색 화면은 같은 제품의 서로 다른 수집 사례다. filestream 입력이 사진 속 세 문서의 유일한 출처였다고 단정하지 않는다.
입력 경로와 출력 주소를 분리한다
- filestream은 paths에 일치하는 파일을 수집하고 output.는 문서를 보낼 목적지를 정한다. setup.는 대시보드 등의 설정 연결이며 로그 본문을 로 직접 보내는 경로가 아니다.
- 사진에는 시험용 관리자 계정이 보이지만 실제 배포에서는 전용 권한·keystore를 사용한다. fingerprint 길이와 작은 파일 처리 조건은 설치 버전의 문서로 확인한다.
shellfilebeat test config -e filebeat test output -e실제 비밀값이 출력될 수 있는 디버그 로그는 외부에 복사하지 않는다.
원본 크기로 보기 ↗- setup.kibana, output.elasticsearch, filebeat.inputs 세 블록이 나뉘어 보인다.
- filestream의 id·paths와 fingerprint.length 64가 표시된다. 필드 이름은 같아도 버전별 기본 동작을 확인해야 한다.
확인 기준filebeat test config와 test output을 각각 수행해 문법과 연결을 구분한다.
시간 필터와 문서 수를 먼저 확인한다
- Discover에서 Data view와 시간 범위를 맞춘 뒤 Documents 수를 읽는다. 서비스가 실행 중이어도 해당 인덱스·시간 범위에 문서가 없으면 검색은 비어 있다.
- 화면의 세 문서는 테스트 로그·로그인 성공·결제 오류라는 메시지를 가진다. 메시지 이름은 사건 분류의 입력이며 실제 비즈니스 성공을 독립 검증한 값은 아니다.
원본 크기로 보기 ↗- Data view는 elk-basic이고 시간 범위는 Last 7 days, Documents는 3으로 표시된다.
- 각 행에 @timestamp·host.hostname·message·_index가 보여 수집 문서를 구조화된 필드로 읽을 수 있다.
확인 기준시각·인덱스·데이터 뷰가 틀려 생긴 빈 결과와 수집 실패를 분리한다.
검색어와 필드 조건의 차이를 시험한다
- 사진의 검색창은 호스트 이름 문자열을 검색한다. 정확한 필드 조건을 쓰려면 KQL의 필드:값 구문과 해당 필드의 매핑을 확인한다.
- 원본 message와 event.original을 보존하면서 필요한 구조 필드를 추가하고, 파싱 실패를 성공 문서와 구분한다.
host.hostname : "lab-host"KQL의 필드 조건 예시. 자신의 문서에 저장된 호스트 이름으로 바꾼다.
원본 크기로 보기 ↗- 왼쪽 Available fields에 @timestamp·event.original·host.hostname·lab·message가 보인다.
- 검색 후에도 Documents 3이 보이며 호스트 문자열이 강조된다. 강조 표시만으로 정확한 필드 동등 비교가 수행됐다고 해석하지 않는다.
확인 기준시간 범위와 필드 매핑을 고정한 뒤 검색 결과 수를 비교한다.
실습에서 확인한 동작 원리
- 설정 연결과 문서 출력은 다른 경로다.
- 검색 결과는 데이터 뷰·시간·필드 매핑 조건에 의존한다.
04예제로 따라가기
- 사용자 이름을 로 저장하면 정확한 값별 집계를 만들 수 있지만 분석 결과의 토큰과 같은 의미가 되지는 않는다.
- status 필드를 숫자로 정하면 범위 비교를 할 수 있다. 이후 같은 필드에 구조가 다른 객체가 들어오면 매핑 충돌이 날 수 있다.
- 문서가 적재되었어도 화면 시간 필드나 시간 범위가 다르면 Discover에서 보이지 않을 수 있다.
05혼동하기 쉬운 점과 확인 기준
- 는 논리적 분할과 실제 저장·검색을 연결하는 단위이며 인덱스가 곧 파일 하나라는 뜻은 아니다.
- 는 모든 운영 실수와 전체 클러스터 삭제에 대비하는 독립 백업을 대신하지 않는다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.