05 · CHAPTER 04 · LOG & MONITORING
검색 가능한
기록 창고
DB와 Elasticsearch에 로그를 저장하고 인덱스·필드·시간 범위로 빠르게 찾는 구조를 살펴봅니다.
LOG & MONITORING STUDY NOTE검색 가능한 기록 창고MySQL · Elasticsearch · Index · Query
01
창고에 상자만 쌓으면 찾을 수 있을까?
핵심 용어
MySQL Elasticsearch Index Query
라벨과 선반 번호가 없으면 자료가 많을수록 원하는 기록을 찾기 어려워집니다.
관계형 DB는 정형화된 이벤트와 집계에 강하고 Elasticsearch는 많은 문서의 검색과 시간 기반 분석에 적합합니다.
ReceivedAt이나 @timestamp 같은 시간 필드와 호스트, 출발지, 이벤트 유형을 일관되게 저장해야 합니다.
02
저장소에서 확인할 것
핵심 개념
Document/Row Field/Column Index Mapping/Schema Retention
데이터 존재와 최신성, 검색 성능을 따로 봅니다.
Document/Row하나의 이벤트
Field/Column검색 가능한 속성
Index검색 경로
Mapping/Schema자료형과 구조
Retention보존과 삭제 정책
03
최신성과 인덱스 확인
관련 명령어
curl -sS http://127.0.0.1:9200/ curl -sS http://127.0.0.1:9200/_cat/indices?v php spark db:show php spark db:table SystemEvents 비밀 값은 환경 파일에서 불러오고 화면에는 출력하지 않습니다.
$ curl -sS http://127.0.0.1:9200/
$ curl -sS http://127.0.0.1:9200/_cat/indices?v
$ php spark db:show
$ php spark db:table SystemEvents
04
무제한 조회를 피하기
보안 관점
위험 요소 확인 기준 대응 원칙
하루치 원문이 매우 크면 집계와 페이지 조회를 분리하고 시간·결과 건수에 상한을 둡니다.
ReceivedAt 같은 자주 쓰는 시간 필드에 적절한 인덱스를 두고, 전체 원문은 전문 분석 화면에서 확인하도록 역할을 나눕니다.
검색이 느릴 때 화면부터 고치지 말고 시간 필드와 인덱스, 반환 건수와 쿼리를 먼저 확인하자.
CHAPTER REVIEW
이번 장에서 기억할 한 문장
많은 로그를 빠르게 찾으려면 저장보다 먼저 어떤 필드와 시간으로 질문할지를 설계해야 한다.