1. 서버가 여러 대일 때는 로그를 어떻게 찾을까?
서버가 1대일 때는 그 서버 로그 파일만 보면 된다. 하지만 서버가 여러 대가 되면 이야기가 달라진다.
예를 들어 웨이팅 API 서버가 3대라고 가정해보자.
고객 문의가 들어와 특정 시각의 에러를 찾아야 한다면, 단순하게는 아래 작업을 해야 한다.
- 서버 1번 로그 확인
- 서버 2번 로그 확인
- 서버 3번 로그 확인
심지어 로그가 압축돼 있거나, 서버마다 파일 이름이 다르거나, 시간이 조금씩 섞여 있으면 찾는 작업이 더 어려워진다.
이 문제를 줄이기 위해 실무에서는 여러 서버에 흩어진 로그를 한 곳으로 모아 중앙에서 검색하고 분석한다.
Elastic 공식 문서는 Elastic Stack이 데이터를 수집하고, 저장하고, 검색하고, 시각화하는 데 쓰인다고 설명한다. [1]
즉, 입문 단계에서는 아래처럼 이해하면 된다.
여러 서버 로그를 한 곳에 모아
검색과 분석을 쉽게 하려는 목적의 대표적인 구성이 ELK다.
2. ELK 스택이란?
ELK는 아래 세 가지 도구 이름의 앞글자를 딴 표현이다.
- Elasticsearch
- Logstash
- Kibana
Elastic 공식 문서는 오늘날 Elastic Stack이 Elasticsearch, Kibana, Logstash, Beats, Elastic Agent 등 더 넓은 구성까지 포함한다고 설명한다. [1][2]
즉, 정확히 말하면 아래처럼 이해하는 것이 좋다.
ELK = Elasticsearch + Logstash + Kibana 중심의 전통적인 표현
Elastic Stack = 그보다 더 넓은 현재 공식 표현
그래도 로그 수집/검색/분석 입문에서는 여전히 ELK라는 표현을 많이 쓴다.
3. Elasticsearch는 무엇을 할까?
Elasticsearch는 저장된 데이터를 검색하고 분석하는 핵심 엔진이다.
Elastic 공식 문서는 Elasticsearch를 distributed search and analytics engine이라고 설명한다. [3]
즉, 로그 관점에서 보면 아래 역할을 한다.
- 많은 로그 데이터를 저장한다.
- 검색 가능한 형태로 색인(index)한다.
- 빠르게 조회하고 집계한다.
예를 들어 아래 같은 질문에 답하기 좋다.
- 오전 9시 이후
ERROR로그만 보기 - 특정 사용자 ID가 포함된 요청 찾기
- 최근 10분간 에러 건수 집계
- 특정 API 경로에서 응답 지연이 많은지 확인
즉, Elasticsearch는 “로그를 보관하고 찾는 중심 저장소”라고 이해하면 된다.
4. Logstash는 무엇을 할까?
Logstash는 데이터를 수집하고 변환해서 다른 곳으로 보내는 도구다.
Elastic 공식 문서는 Logstash를 server-side data processing pipeline이라고 설명하며, 다양한 소스에서 데이터를 받아 변환하고 원하는 목적지로 보낸다고 설명한다. [4][5]
즉, 로그 관점에서는 아래 역할을 맡는다.
- 각 서버에서 로그를 받는다.
- 로그 형식을 파싱한다.
- 필요한 필드를 변환하거나 정리한다.
- Elasticsearch로 전달한다.
예를 들어 아래 같은 작업이 가능하다.
- 원본 로그 문자열에서 timestamp 추출
INFO,WARN,ERROR필드 분리- JSON 형태 로그 정규화
- 여러 서버 로그를 하나의 공통 구조로 맞춤
즉, Logstash는 “로그를 받아서 가공하고 다음 단계로 넘기는 파이프라인”이라고 이해하면 된다.
5. Kibana는 무엇을 할까?
Kibana는 Elasticsearch에 저장된 데이터를 화면에서 탐색하고 시각화하는 도구다.
Elastic 공식 문서는 Kibana를 Elasticsearch에 저장된 데이터를 query, analyze, visualize, manage 하는 인터페이스라고 설명한다. [6]
즉, Kibana는 아래 역할을 한다.
- 로그를 검색 화면에서 직접 조회
- 그래프와 차트 생성
- 대시보드 구성
- 운영 현황을 시각적으로 확인
예를 들어 Kibana에서는 아래 같은 화면을 만들 수 있다.
- 시간대별 에러 건수 그래프
- API별 요청 수 대시보드
- 응답시간 상위 API 차트
- 특정 서비스의 최근 장애 로그 검색 화면
즉, Kibana는 “쌓인 로그를 사람이 보기 쉽게 보여주는 화면”이라고 보면 된다.
6. ELK는 세 개가 어떻게 같이 동작할까?
입문 단계에서는 아래 흐름으로 이해하면 된다.
애플리케이션 로그
-> Logstash가 수집/변환
-> Elasticsearch가 저장/검색
-> Kibana가 조회/시각화
조금 더 풀어 쓰면:
- 여러 서버에서 로그가 발생한다.
- Logstash가 그 로그를 모은다.
- Elasticsearch에 저장한다.
- Kibana에서 검색하고 그래프로 본다.
Elastic 공식 문서도 Elastic Stack이 ingest, store, search, visualize 흐름으로 동작한다고 설명한다. [1]
7. 왜 ELK를 쓰면 편할까?
ELK를 쓰면 가장 큰 장점은 “여러 서버 로그를 한 번에 찾기 쉬워진다”는 점이다.
예를 들어 아래 차이가 생긴다.
ELK가 없을 때
- 서버마다 접속
- 파일마다 열기
- 시간 맞춰 grep
- 서버별 결과를 사람이 합치기
ELK가 있을 때
- Kibana 한 화면에서 검색
- 시간 범위로 필터링
- 에러 레벨로 필터링
- 서비스 이름으로 필터링
즉, “로그를 모아두는 것” 자체보다도 “중앙에서 빠르게 찾고 비교할 수 있다”는 점이 실무에서 훨씬 중요하다.
8. 지금도 꼭 Logstash를 써야 할까?
이 부분은 조금 더 정확히 봐야 한다.
오늘날 Elastic 공식 문서는 Elastic Stack에 Logstash뿐 아니라 Beats, Elastic Agent 같은 수집 도구도 함께 포함한다고 설명한다. [1][2]
즉, 현재는 아래처럼 이해하는 것이 맞다.
- 전통적인 ELK 구성:
- Elasticsearch + Logstash + Kibana
- 더 넓은 현재 구성:
- Elasticsearch + Kibana + Logstash + Beats/Elastic Agent 등
따라서 로그 수집을 꼭 Logstash로만 해야 하는 것은 아니다. 다만 입문 단계에서는 역할 분리가 뚜렷해서 ELK 구조로 배우는 것이 이해하기 쉽다.
정리
ELK는 여러 서버에 흩어진 로그를 한 곳으로 모아 저장하고 검색하고 시각화하기 위한 대표적인 구성이다.
핵심만 정리하면 아래와 같다.
- Elasticsearch는 로그를 저장하고 검색한다.
- Logstash는 로그를 수집하고 변환해 전달한다.
- Kibana는 로그를 검색하고 시각화한다.
- 여러 서버 로그를 중앙에서 한 번에 확인할 수 있다는 점이 가장 큰 장점이다.
- 오늘날 공식 표현은 ELK보다 더 넓은 Elastic Stack이지만, 입문 설명에서는 ELK라는 표현도 여전히 많이 쓰인다.
즉, ELK는 “여러 서버 로그를 중앙에서 찾고 분석하기 쉽게 만드는 도구 묶음”이라고 이해하면 된다.
출처
- Elastic Docs, “The Elastic Stack”, https://www.elastic.co/docs/get-started/the-stack
- Elastic, “Elastic Stack (ELK)”, https://www.elastic.co/elastic-stack
- Elastic, “Elasticsearch”, https://www.elastic.co/elasticsearch
- Elastic, “Logstash”, https://www.elastic.co/logstash
- Elastic Docs, “Logstash”, https://www.elastic.co/docs/reference/logstash
- Elastic, “Kibana”, https://www.elastic.co/kibana