서버나 Kubernetes를 운영하다 보면 이런 용어를 자주 만나게 됩니다.
- OpenSearch
- Fluent Bit
- Logstash
- OpenSearch Dashboards
- 로그 파싱
- 로그 수집
처음 보면 각각 무엇을 하는지 헷갈릴 수 있습니다. 😵
하지만 전체 흐름부터 보면 생각보다 간단합니다.
서버 / Kubernetes Pod
↓
Fluent Bit / Logstash
↓
OpenSearch
↓
OpenSearch Dashboards
↓
관리자 👨💻
쉽게 말하면,
Fluent Bit / Logstash가 로그를 모아서 정리하고 → OpenSearch에 저장하면 → 관리자가 검색하고 분석하는 구조입니다.
1️⃣ OpenSearch가 뭐야? 🔍
OpenSearch는 많은 데이터를 저장하고 빠르게 검색·분석하는 검색 엔진입니다.
쉽게 생각하면,
📚 회사 내부 로그를 위한 초대형 검색 시스템
이라고 이해하면 됩니다.
예를 들어 서버가 100대 있다고 해보겠습니다.
Server01 → 시스템 로그
Server02 → 애플리케이션 로그
Server03 → GPU 로그
Server04 → API 로그
Server05 → 보안 로그
...
Server100 → 각종 로그
로그가 조금이라면 서버에 접속해서 grep 명령어로 찾을 수도 있습니다.
grep ERROR application.log
하지만 서버가 수십~수백 대이고 로그가 하루에 수백 GB씩 발생한다면 어떻게 될까요?
서버마다 접속해서 찾는 것은 현실적으로 어렵습니다.
이럴 때 로그를 OpenSearch에 중앙 집중화합니다.
Server01 ─┐
Server02 ─┤
Server03 ─┤
Server04 ─┤
Server05 ─┤
↓
OpenSearch
그러면 관리자는 한 곳에서 검색할 수 있습니다.
예를 들어:
GPU3 오류만 검색
또는
ERROR 로그만 검색
또는
최근 1시간 동안 HTTP 500 오류 검색
같은 작업이 가능합니다.
2️⃣ 쉽게 비유하면? 📚
OpenSearch를 엄청 큰 도서관이라고 생각하면 이해하기 쉽습니다.
도서관에는 수백만 권의 책이 있습니다.
그런데 책이 아무렇게나 쌓여 있다면 원하는 책을 찾기 어렵겠죠?
그래서 도서관에서는 책을 분류하고 검색할 수 있도록 정리합니다.
OpenSearch도 비슷합니다.
엄청난 양의 로그
↓
OpenSearch에 저장
↓
Index 생성
↓
빠르게 검색
즉,
Google이 인터넷을 검색한다면
OpenSearch는 주로 내 회사의 로그와 데이터를 검색한다
라고 이해하면 쉽습니다. 👍
3️⃣ 그런데 OpenSearch가 직접 로그를 가져오나?
여기서 중요한 부분입니다. ⭐
OpenSearch는 보통 서버를 돌아다니면서 직접 로그를 수집하지 않습니다.
그 역할을 담당하는 프로그램이 필요합니다.
대표적인 것이 바로:
🔹 Fluent Bit
🔹 Logstash
입니다.
그래서 전체 구조는 보통 이렇게 됩니다.
애플리케이션
Kubernetes Pod
Linux Server
↓
로그 발생
↓
Fluent Bit / Logstash
↓
OpenSearch
↓
OpenSearch Dashboards
4️⃣ Fluent Bit은 뭐야? 🚚
Fluent Bit은 서버나 Pod에서 발생하는 로그를 수집해서 다른 시스템으로 전달하는 경량 로그 수집기입니다.
쉽게 말하면:
🚚 로그 배달기사
라고 생각하면 됩니다.
예를 들어 Kubernetes Pod에서 로그가 계속 발생합니다.
Pod A → application log
Pod B → error log
Pod C → nginx log
Pod D → API log
Fluent Bit이 이런 로그를 수집합니다.
Pod A ─┐
Pod B ─┤
Pod C ─┤
Pod D ─┘
↓
Fluent Bit
↓
OpenSearch
Fluent Bit이 하는 대표적인 작업은 다음과 같습니다.
✅ 로그 수집
예:
/var/log/containers/*.log
Kubernetes Container 로그를 읽습니다.
✅ 간단한 Parsing
로그가 다음과 같다면:
2026-08-09 10:30:20 ERROR GPU3 Xid 43
이를 구조화할 수 있습니다.
timestamp = 2026-08-09 10:30:20
level = ERROR
gpu = GPU3
error = Xid 43
✅ 필요 없는 데이터 제거
불필요한 필드를 삭제할 수도 있습니다.
✅ 로그 전달
최종적으로 OpenSearch 같은 시스템으로 데이터를 전달합니다.
Fluent Bit
↓
OpenSearch
5️⃣ Fluent Bit을 Kubernetes에서 많이 사용하는 이유 ☸️
Kubernetes에서는 Fluent Bit을 많이 사용합니다.
가장 큰 이유는 가볍기 때문입니다.
Kubernetes에서는 일반적으로 Fluent Bit을 DaemonSet으로 배포합니다.
DaemonSet은 쉽게 말하면:
Kubernetes의 각 Node마다 Pod 하나씩 실행시키는 방식
입니다.
예를 들어 Worker Node가 3대라면:
Worker Node01
├─ Application Pod
├─ Application Pod
└─ Fluent Bit
Worker Node02
├─ Application Pod
├─ Application Pod
└─ Fluent Bit
Worker Node03
├─ Application Pod
└─ Fluent Bit
각 Node의 Fluent Bit이 해당 Node에서 발생하는 Container 로그를 가져갑니다.
전체 구조는 다음과 같습니다.
Node01 로그 ─→ Fluent Bit ─┐
Node02 로그 ─→ Fluent Bit ─┤
Node03 로그 ─→ Fluent Bit ─┤
↓
OpenSearch
그래서 Kubernetes 로그 수집 구조에서 Fluent Bit을 아주 자주 볼 수 있습니다.
6️⃣ 그러면 Logstash는 뭐야? ⚙️
Logstash도 로그를 수집하고 전달하는 프로그램입니다.
하지만 Fluent Bit과 비교하면 데이터 가공 능력이 훨씬 강력합니다.
쉽게 비유하면:
Fluent Bit
= 가볍고 빠른 로그 배달기사 🚚
Logstash
= 로그를 전문적으로 가공하는 공장 🏭
Logstash는 단순히 로그를 가져오는 것뿐 아니라 데이터를 복잡하게 변환할 수 있습니다.
예를 들어 원본 로그가:
2026-08-09 10:30:20 ERROR server01 GPU3 Xid43
라고 하면 Logstash에서 다음처럼 상세하게 구조화할 수 있습니다.
timestamp : 2026-08-09 10:30:20
level : ERROR
hostname : server01
gpu : GPU3
xid : 43
이런 작업을 흔히 Parsing 또는 로그 가공이라고 합니다.
7️⃣ Logstash는 데이터를 어떻게 처리할까?
Logstash를 이해할 때 가장 중요한 구조가 있습니다.
바로:
INPUT
↓
FILTER
↓
OUTPUT
입니다.
📥 INPUT
어디서 데이터를 가져올 것인가?
예:
File
Kafka
Beats
TCP
HTTP
⚙️ FILTER
가져온 데이터를 어떻게 가공할 것인가?
예:
Parsing
필드 추가
필드 삭제
문자열 변환
날짜 변환
정규표현식 처리
📤 OUTPUT
가공한 데이터를 어디로 보낼 것인가?
예:
OpenSearch
Elasticsearch
Kafka
File
따라서 Logstash 전체 흐름은:
INPUT
↓
로그 수집
FILTER
↓
Parsing / 데이터 가공
OUTPUT
↓
OpenSearch 전달
이라고 이해하면 됩니다.
8️⃣ Fluent Bit과 Logstash 차이는? 🤔
둘 다 로그를 수집하고 전달할 수 있기 때문에 처음에는 헷갈립니다.
간단하게 비교하면 다음과 같습니다.
구분Fluent BitLogstash
| 주요 역할 | 로그 수집·전달 | 로그 수집·가공·전달 |
| 무게 | 매우 가벼움 | 상대적으로 무거움 |
| Kubernetes | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 데이터 가공 | 기본적인 가공 | 복잡한 가공 가능 |
| 자원 사용 | 적음 | 상대적으로 많음 |
| 대표 용도 | Container 로그 수집 | 복잡한 Parsing |
| 비유 | 🚚 배달기사 | 🏭 데이터 가공 공장 |
무조건 둘 중 하나가 더 좋은 것은 아닙니다.
사용 목적에 따라 선택합니다.
9️⃣ Fluent Bit만 사용해도 되나?
물론 가능합니다. 👍
로그 구조가 단순한 경우에는 굳이 Logstash가 필요하지 않을 수 있습니다.
Kubernetes Pod
↓
Fluent Bit
↓
OpenSearch
이 구조는 단순하고 리소스 사용량도 적습니다.
특히 Kubernetes 환경에서 많이 사용됩니다.
🔟 Fluent Bit + Logstash를 같이 사용할 수도 있나?
가능합니다.
예를 들어 로그 가공이 복잡하면:
Kubernetes Pod
↓
Fluent Bit
↓
Logstash
↓
OpenSearch
구조를 사용할 수 있습니다.
역할을 구분하면:
Fluent Bit
↓
로그 수집
Logstash
↓
복잡한 Parsing / 데이터 가공
OpenSearch
↓
저장 / 검색
OpenSearch Dashboards
↓
화면 / 분석
이렇게 됩니다.
1️⃣1️⃣ OpenSearch는 데이터를 어떻게 저장할까?
OpenSearch에서 자주 나오는 용어가 있습니다.
📄 Document
데이터 한 건입니다.
로그 환경에서는 보통 로그 한 건을 Document라고 생각하면 됩니다.
예:
{
"timestamp": "2026-08-09T10:30:20",
"level": "ERROR",
"hostname": "gpu-server01",
"gpu": "GPU3",
"error": "Xid 43"
}
이 한 덩어리가 하나의 Document입니다.
📚 Index
Document들을 모아놓는 공간입니다.
예:
Index : kubernetes-logs
├─ Document 1
├─ Document 2
├─ Document 3
├─ Document 4
└─ Document 5
예를 들어 날짜별로 Index를 만들 수도 있습니다.
kubernetes-logs-2026.08.07
kubernetes-logs-2026.08.08
kubernetes-logs-2026.08.09
🧩 Shard
데이터가 너무 많아지면 Index 하나를 여러 조각으로 나눌 수 있습니다.
그 조각이 Shard입니다.
Index
│
├─ Shard 1
├─ Shard 2
└─ Shard 3
Shard를 여러 OpenSearch Node에 분산해서 저장하면 대량의 데이터를 여러 서버가 나눠 처리할 수 있습니다.
1️⃣2️⃣ OpenSearch Dashboards는 뭐야? 📊
OpenSearch가 데이터를 저장하고 검색하는 엔진이라면,
OpenSearch Dashboards는 사람이 데이터를 쉽게 확인할 수 있도록 보여주는 웹 화면입니다.
쉽게 비교하면:
OpenSearch
= 저장 + 검색 + 분석 엔진
OpenSearch Dashboards
= 검색 화면 + 그래프 + 대시보드
예를 들어 이런 화면을 만들 수 있습니다.
📊 시간대별 ERROR 발생량
📊 서버별 장애 발생 건수
📊 HTTP 500 Error 추이
📊 로그인 실패 횟수
📊 Kubernetes Pod 오류
📊 특정 서비스 로그
📊 보안 이벤트 현황
1️⃣3️⃣ Elasticsearch와는 무슨 관계야?
OpenSearch를 공부하다 보면 Elasticsearch도 반드시 만나게 됩니다.
둘 다 비슷한 역할을 하는 검색·분석 엔진입니다.
OpenSearch는 Elasticsearch 7.10.2와 Kibana 7.10.2를 기반으로 시작된 오픈소스 프로젝트입니다.
쉽게 비교하면:
Elasticsearch
↓
데이터 검색·분석
OpenSearch
↓
데이터 검색·분석
UI도 대응해서 이해할 수 있습니다.
Elasticsearch → Kibana
OpenSearch → OpenSearch Dashboards
1️⃣4️⃣ 전체 로그 흐름을 한 번에 이해해보자 🚀
이제 지금까지 배운 내용을 연결해보겠습니다.
Kubernetes Pod에서 다음 로그가 발생했다고 가정하겠습니다.
2026-08-09 10:30:20 ERROR GPU3 CUDA device unavailable
① 애플리케이션에서 로그 발생
Application
↓
로그 생성
② Fluent Bit이 로그 수집
Application
↓
Fluent Bit
③ Parsing
원본 로그:
2026-08-09 10:30:20 ERROR GPU3 CUDA device unavailable
구조화:
timestamp = 2026-08-09 10:30:20
level = ERROR
gpu = GPU3
message = CUDA device unavailable
간단한 Parsing이면 Fluent Bit에서 처리할 수 있고,
복잡한 Parsing이 필요하면 Logstash를 사용할 수도 있습니다.
④ OpenSearch 저장
Fluent Bit
또는
Logstash
↓
OpenSearch
⑤ 관리자가 검색
OpenSearch Dashboards에서:
level:ERROR AND gpu:GPU3
같은 조건으로 검색합니다.
그러면 GPU3에서 발생한 ERROR 로그만 빠르게 확인할 수 있습니다.
🎯 전체 구조 총정리
가장 중요한 그림입니다.
┌──────────────────────────────┐
│ Kubernetes / Linux / App │
│ │
│ Pod / Server에서 로그 발생 │
└──────────────┬───────────────┘
↓
┌───────────────┐
│ Fluent Bit │
│ │
│ 로그 수집 │
│ 간단한 Parsing│
│ 로그 전달 │
└───────┬───────┘
↓
필요하면
↓
┌───────────────┐
│ Logstash │
│ │
│ 복잡한 Parsing│
│ 데이터 가공 │
└───────┬───────┘
↓
┌───────────────┐
│ OpenSearch │
│ │
│ 데이터 저장 │
│ 검색 │
│ 분석 │
└───────┬───────┘
↓
┌──────────────────────────────┐
│ OpenSearch Dashboards │
│ │
│ 검색 🔍 │
│ 그래프 📊 │
│ 장애 분석 🚨 │
└──────────────────────────────┘
💡 한 줄씩 기억하기
🔹 Parsing
로그를 분석해서 의미 있는 필드로 나누는 작업
🔹 Fluent Bit
🚚 서버와 Kubernetes Pod의 로그를 가볍게 수집해서 전달하는 프로그램
🔹 Logstash
🏭 로그를 복잡하게 Parsing하고 가공해서 전달하는 프로그램
🔹 OpenSearch
🔍 엄청난 양의 데이터를 저장하고 빠르게 검색·분석하는 시스템
🔹 OpenSearch Dashboards
📊 OpenSearch 데이터를 사람이 검색하고 그래프로 볼 수 있게 해주는 화면
🚀 가장 쉬운 최종 정리
처음 공부할 때는 아래 한 줄만 기억해도 충분합니다.
로그 발생
↓
Fluent Bit
↓
Parsing / 필요하면 Logstash
↓
OpenSearch
↓
OpenSearch Dashboards
그리고 역할을 사람에 비유하면 더 쉽습니다.
Application
= 로그를 만드는 사람 📝
Fluent Bit
= 로그를 가져오는 배달기사 🚚
Logstash
= 로그를 정리하는 가공 전문가 🏭
OpenSearch
= 로그를 보관하는 거대한 도서관 📚
OpenSearch Dashboards
= 도서관 검색창 + 분석 화면 🔍📊
이 구조를 이해하면 Kubernetes 로그 시스템을 공부할 때 나오는 Fluent Bit → OpenSearch → Grafana/OpenSearch Dashboards → Loki 같은 개념도 훨씬 쉽게 연결할 수 있습니다.
'J-H-T > OpenSearch' 카테고리의 다른 글
| 🚀 OpenSearch 실무 용량 설계 입문 (0) | 2026.08.09 |
|---|---|
| [🔍 OpenSearch 내부 구조 쉽게 이해하기] Index → Document → Shard → Replica → Node (0) | 2026.08.09 |
댓글