개념 사전 · 프로그램

Elasticsearch

엘라스틱서치

는 문서를 인덱싱하고 검색·집계하는 분산 검색 엔진이다. 필드의 과 분석 방식이 어떤 질문에 답할 수 있는지 결정하며 는 그 자료를 탐색하는 별도 화면이다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • 보안·운영 이벤트를 문서와 인덱스로 저장한다.
  • 검색용 와 필드 타입을 사용해 조건 검색과 집계를 처리한다.
  • ·로 데이터를 나누고 복사하여 처리와 가용성을 구성한다.

02어떤 순서로 동작하나

  1. 문서와 타입 준비

    이벤트를 문서로 만들고 인덱스의 으로 필드 타입·분석 방식을 정한다. 동일 필드에 숫자와 객체가 섞이면 타입 충돌로 거부될 수 있다.

  2. 샤드에 인덱싱

    문서가 담당 primary 로 전달되고 설정한 로 복제된다. 분석 결과는 토큰에서 문서를 찾는 에 사용되며 는 정확한 값의 조건과 집계에 쓰인다.

  3. 질의 분산

    검색 요청의 범위와 조건을 관련 에 전달하고 부분 결과를 모아 반환한다. 노드는 고정된 전용 서버라는 뜻이 아니며 여러 를 배치받을 수 있다.

  4. 검색과 가용성 확인

    저장 응답·검색 가능 시점·화면 시간 범위를 구분해 관찰한다. 적절한 다른 노드가 없으면 설정한 가 미할당될 수 있고, 만으로 독립 백업을 대신하지 못한다.

03먼저 알아둘 용어와 구성요소

인덱스에 저장·검색되는 하나의 자료 단위.
필드의 타입과 분석 방식을 정의하는 계약.
인덱스 데이터를 나누어 저장·검색하는 단위.
Primary 의 복사본으로 장애 대응과 읽기 분산에 사용된다.
문서를 조직하는 논리적 검색·저장 대상.
값을 검색에 사용할 토큰으로 처리하는 구성.
분석한 토큰을 통한 전문 검색에 쓰는 문자열 필드 타입.
정확한 값의 필터·정렬·집계 등에 쓰는 문자열 필드 타입.
각 토큰을 그 토큰이 있는 문서에 연결하는 검색 구조.
객체·배열·값을 텍스트로 표현하는 자료 형식.
LEARN THROUGH PRACTICE

Filebeat 입력 설정에서 Kibana 문서 세 건까지 추적하기

설정 파일의 입력·출력과 검색 화면의 문서·시간·필드를 연결한다.

실습 구성과 전제

  • 자신의 격리 Elastic 환경과 비밀값을 별도로 관리한 수집 계정을 사용한다.
  • 설정 화면과 검색 화면은 같은 제품의 서로 다른 수집 사례다. filestream 입력이 사진 속 세 문서의 유일한 출처였다고 단정하지 않는다.
  1. 입력 경로와 출력 주소를 분리한다

    • filestream은 paths에 일치하는 파일을 수집하고 output.는 문서를 보낼 목적지를 정한다. setup.는 대시보드 등의 설정 연결이며 로그 본문을 로 직접 보내는 경로가 아니다.
    • 사진에는 시험용 관리자 계정이 보이지만 실제 배포에서는 전용 권한·keystore를 사용한다. fingerprint 길이와 작은 파일 처리 조건은 설치 버전의 문서로 확인한다.
    shell
    filebeat test config -e
    filebeat test output -e

    실제 비밀값이 출력될 수 있는 디버그 로그는 외부에 복사하지 않는다.

    Beats 수집과 Elastic 연결 · Elasticsearch에 실제 데이터가 들어오는지 확인 (2)원본 크기로 보기 ↗
    • setup.kibana, output.elasticsearch, filebeat.inputs 세 블록이 나뉘어 보인다.
    • filestream의 id·paths와 fingerprint.length 64가 표시된다. 필드 이름은 같아도 버전별 기본 동작을 확인해야 한다.
    확인 기준

    filebeat test config와 test output을 각각 수행해 문법과 연결을 구분한다.

  2. 시간 필터와 문서 수를 먼저 확인한다

    • Discover에서 Data view와 시간 범위를 맞춘 뒤 Documents 수를 읽는다. 서비스가 실행 중이어도 해당 인덱스·시간 범위에 문서가 없으면 검색은 비어 있다.
    • 화면의 세 문서는 테스트 로그·로그인 성공·결제 오류라는 메시지를 가진다. 메시지 이름은 사건 분류의 입력이며 실제 비즈니스 성공을 독립 검증한 값은 아니다.
    Elastic·Kibana 운영 · Discover (5)원본 크기로 보기 ↗
    • Data view는 elk-basic이고 시간 범위는 Last 7 days, Documents는 3으로 표시된다.
    • 각 행에 @timestamp·host.hostname·message·_index가 보여 수집 문서를 구조화된 필드로 읽을 수 있다.
    확인 기준

    시각·인덱스·데이터 뷰가 틀려 생긴 빈 결과와 수집 실패를 분리한다.

  3. 검색어와 필드 조건의 차이를 시험한다

    • 사진의 검색창은 호스트 이름 문자열을 검색한다. 정확한 필드 조건을 쓰려면 KQL의 필드:값 구문과 해당 필드의 매핑을 확인한다.
    • 원본 message와 event.original을 보존하면서 필요한 구조 필드를 추가하고, 파싱 실패를 성공 문서와 구분한다.
    host.hostname : "lab-host"

    KQL의 필드 조건 예시. 자신의 문서에 저장된 호스트 이름으로 바꾼다.

    Elastic·Kibana 운영 · Discover (6)원본 크기로 보기 ↗
    • 왼쪽 Available fields에 @timestamp·event.original·host.hostname·lab·message가 보인다.
    • 검색 후에도 Documents 3이 보이며 호스트 문자열이 강조된다. 강조 표시만으로 정확한 필드 동등 비교가 수행됐다고 해석하지 않는다.
    확인 기준

    시간 범위와 필드 매핑을 고정한 뒤 검색 결과 수를 비교한다.

실습에서 확인한 동작 원리

  • 설정 연결과 문서 출력은 다른 경로다.
  • 검색 결과는 데이터 뷰·시간·필드 매핑 조건에 의존한다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 사용자 이름을 로 저장하면 정확한 값별 집계를 만들 수 있지만 분석 결과의 토큰과 같은 의미가 되지는 않는다.
  • status 필드를 숫자로 정하면 범위 비교를 할 수 있다. 이후 같은 필드에 구조가 다른 객체가 들어오면 매핑 충돌이 날 수 있다.
  • 문서가 적재되었어도 화면 시간 필드나 시간 범위가 다르면 Discover에서 보이지 않을 수 있다.

05혼동하기 쉬운 점과 확인 기준

  • 는 논리적 분할과 실제 저장·검색을 연결하는 단위이며 인덱스가 곧 파일 하나라는 뜻은 아니다.
  • 는 모든 운영 실수와 전체 클러스터 삭제에 대비하는 독립 백업을 대신하지 않는다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.