로그 수집 파이프라인

학습 목표

로그가 앱 → 수집 → 저장 → 검색까지 흐르는 파이프라인을 그릴 수 있다.

Agent와 Aggregator의 역할을 구분할 수 있다.

컨테이너·K8s 환경에서 로그를 노드 밖으로 보내야 하는 이유를 설명할 수 있다.

ELK와 Loki 스택의 차이를 워크로드 관점에서 비교할 수 있다.

문제 상황

• 장애 시 kubectl logs만 보면 이미 사라진 Pod 로그를 못 본다
• 서버 50대에 SSH로 tail -f — 확장이 안 된다
• JSON 로그는 앱에서 잘 쓰는데, 검색 UI는 없다
• Elasticsearch 비용이 커서 "로그만" Loki로 가자는 말이 나오는데 차이를 모른다

구조화 로그·correlation ID를 봤다. 이번 편은 로그를 모으고 찾는 인프라다.

1. 왜 파이프라인이 필요한가

로컬 파일만 쓸 때	중앙 수집
Pod/컨테이너 삭제 시 유실	보존 기간·복제
호스트별로 흩어짐	한 곳에서 검색·필터
correlation ID 추적 어려움	전 서비스 cross-search
디스크 가득 참	retention·tiering 정책

• 관측성 삼각형에서 로그는 "무슨 일이 있었나"의 근거
• 메트릭·트레이스와 같은 trace/request ID로 엮으면 장애 시간 단축

2. 파이프라인 구성

Application  →  stdout/stderr (JSON 권장)
      ↓
Agent        →  Filebeat, Fluent Bit, Promtail (노드·컨테이너 tail)
      ↓
Aggregator   →  Logstash, Fluentd (선택 — 파싱·라우팅·버퍼)
      ↓
Storage      →  Elasticsearch, OpenSearch, Loki, S3+cold
      ↓
Query UI     →  Kibana, Grafana Explore

Application

• stdout/stderr로 출력 (12-factor)
• 파일 로그는 agent가 tail — 로테이션·권한 이슈 주의
• 필드·trace_id는 앱에서 구조화 (이전 편)

Agent

• 가벼운 데몬, 노드당 1개 또는 Pod당 sidecar
• 역할: tail, 메타데이터 붙이기 (pod, namespace, host), backpressure 처리
• K8s: 보통 노드 레벨 agent가 /var/log/containers 수집

Aggregator (선택)

• 여러 agent → 중앙 처리
• grok 파싱, PII 마스킹, 라우팅(에러만 다른 인덱스)
• 소규모는 agent → storage 직접 전송도 흔함

Storage & Query

• 인덱스 기반(ES) vs 라벨 + 청크(Loki)
• retention, ILM(Lifecycle), 비용 tier

3. 배포 패턴

패턴	설명
Node agent	DaemonSet — 노드당 Filebeat/Fluent Bit
Sidecar	앱 Pod 옆 로그 shipper — 멀티테넌트·특수 포맷
Direct ship	앱이 HTTP/gRPC로 직접 전송 — agent 부담↓, 앱 복잡도↑

• 컨테이너 내부 파일에만 의존하지 말 것 — ephemeral filesystem
• 네트워크 장애 시 agent 로컬 버퍼·재시도

4. ELK vs Loki

ELK (Elastic Stack)

• Beats → Logstash(선택) → Elasticsearch → Kibana
• 로그 전문 인덱싱 — 풍부한 full-text search, aggregation
• 비용: 인덱스 크기·샤드·핫 노드 — 고 cardinality 필드 주의

Loki (Grafana)

• Promtail / agent → Loki → Grafana
• 라벨(낮은 cardinality)로 스트림 식별, 로그 본문은 압축 청크
• PromQL 유사 LogQL — 메트릭·로그 한 UI
• trade-off: 라벨 설계 안 하면 검색 느림; full-text는 ES보다 제한적

기준	ELK	Loki
검색	강한 full-text	라벨 + 필터 중심
비용	인덱스 비용 큼	상대적으로 저렴한 경우 많음
스택	Kibana	Grafana (메트릭과 통합)
적합	복잡 쿼리·감사·SIEM	K8s·클라우드 네이티브, 비용 민감

• 둘 다 쓰거나, OpenSearch, Datadog, CloudWatch Logs 등 관리형 선택도 많다

5. 운영 체크리스트

• 라벨/필드 설계 — service, env, level (cardinality 폭발 필드는 값 제한)
• 샘플링 — debug 전량 수집 vs prod는 info+
• PII — 수집 전 마스킹 (Security·규제 연계)
• retention — 7일 hot, 90일 warm, S3 cold
• 장애 시 — agent가 storage보다 먼저 죽지 않게 리소스·헬스체크

6. 정리

• 로그는 앱에서 끝나지 않고 중앙 저장·검색까지가 한 세트
• agent가 tail·메타데이터·전송, aggregator는 선택적 가공
• ELK는 인덱스 검색, Loki는 라벨·비용 — 워크로드에 맞게 선택
• correlation ID는 파이프라인 전 구간 필드로 유지

다음에 다룰 것

• 로그로 장애 좁히기
• tail, filter, Network 트러블슈팅 연계

---

해당 내용은 Elastic Stack Documentation, Grafana Loki Documentation 및 관측성 실무 관행을 기반으로 합니다.