왜 지금 로그 집계 시스템인가: 장애를 “조기”에 잡아내는 힘
장애는 항상 발생합니다. 중요한 것은 “언제 발견하느냐”와 “얼마나 빨리 대응하느냐”입니다. 로그는 시스템의 “진실”을 전달하지만, 서비스가 커질수록 서버, 컨테이너, 애플리케이션, CDN, 데이터베이스 등 곳곳에 흩어진 로그를 사람이 일일이 확인하는 것은 불가능합니다. 그래서 로그를 한곳에 모으고, 표준화하며, 상관관계를 파악하고, 자동으로 경보를 울리는 로그 집계 시스템이 필요합니다.
이 글에서는 ELK(Elasticsearch, Logstash, Kibana)와 Sentry를 묶어 장애를 조기 감지하고 즉각 대응하는 워크플로우를 설계하는 방법을 소개합니다. 단순히 도구 설치를 넘어, 운영에 필요한 지표 정의, 파이프라인 설계, 경보 튜닝, 팀 워크플로우까지 실전적인 관점에서 다룹니다.
목표와 범위: 무엇을 감지하고 어떻게 대응할 것인가
구축에 앞서 다음 질문에 답해보세요.
- 비즈니스적으로 치명적인 장애는 무엇인가? (예: 결제 실패, 로그인 불가, 데이터 손실)
- 중요한 사용자 경험 지표(SLI)는? (예: 오류율, 응답 시간, 성공률, 레이턴시 p95)
- SLO/SLAs는? (예: 오류율 < 1%, p95 < 500ms)
- 누구에게, 어떤 경로로 알릴 것인가? (Slack, PagerDuty, 이메일)
- 대응 조직과 책임(RACI)은? (On-call, Incident Commander, Communication)
이 기준은 ELK와 Sentry의 경보 임계치와 대시보드, 그리고 대응 플레이북의 바탕이 됩니다.
ELK와 Sentry의 역할 분담
- ELK: 시스템 전반의 로그/메트릭/추세를 집계·검색·시각화. 대규모 텍스트 로그, 구조화 로그, 인프라 지표의 중심.
- Sentry: 애플리케이션 수준의 예외와 성능 트레이싱(APM)에 특화. 에러 집계, 릴리스/릴리즈별 리그레션, 이슈 라이프사이클 관리.
둘을 함께 쓰면:
- Sentry로 “에러 이벤트”를 빠르게 감지하고, ELK로 “왜 그런지” 로그 문맥을 깊게 파고듭니다.
- Correlation ID로 에러와 로그를 상호 링크해 근본 원인 분석(RCA)이 빨라집니다.
아키텍처 개요: 수집부터 분석, 알림까지
일반적인 구성은 다음과 같습니다.
- 수집(Edge)
- Filebeat/Fluent Bit/CloudWatch/Stackdriver/Log Driver 등 에이전트가 애플리케이션/인프라 로그를 수집
- 애플리케이션은 JSON 구조화 로그 + Correlation ID 포함
- 파싱/정규화(Ingest)
- Logstash 또는 Elasticsearch Ingest Pipeline에서 파싱, 마스킹(PII), ECS 스키마 정규화, 필드 추가(환경, 서비스명)
- 저장(Indexing)
- Elasticsearch에 인덱싱. 핫-웜-콜드 티어와 ILM(수명주기)로 비용 최적화
- 시각화 및 탐색
- Kibana 대시보드, 탐색(Discover), Lens/TSVB
- 경보
- Kibana Alerting 또는 Watcher로 이상치/임계치 경보
- Slack/PagerDuty로 라우팅
- 애플리케이션 에러/트레이싱
- Sentry SDK로 코드 레벨 예외, 트레이스, 릴리스 태깅
- Sentry Alert Rules로 에러율/새로운 이슈 감지
- 상관관계
- Sentry event_id ↔ ELK log.correlation_id 상호 참조
- Kibana 링크에서 Sentry 이슈로, Sentry 이슈에서 Kibana 로그로 왕복 이동
로그 수집과 표준화: “보이는” 로그를 만들어라
구조화 로그(JSON)와 ECS
무료 텍스트 로그보다 JSON 구조화 로그가 필수입니다. 표준 스키마(ECS: Elastic Common Schema)를 채택하면 대시보드 확장성과 쿼리 호환성이 높아집니다. 필수 필드는 다음과 같습니다.
- timestamp, log.level, message
- service.name, service.version, event.dataset
- host.name, container.id, cloud.provider/region
- trace.id, transaction.id, span.id (분산 트레이싱 연계)
- http.request.method, http.response.status_code
- user.id, user.email (가능하면 해시/익명화)
- labels.env, labels.region 등 태그
애플리케이션에서 로그 예시(JSON):
{
"@timestamp": "2025-10-05T02:45:13Z",
"log.level": "ERROR",
"message": "Payment authorization failed",
"service.name": "checkout-api",
"service.version": "2.3.1",
"labels.env": "prod",
"http.request.method": "POST",
"http.response.status_code": 502,
"trace.id": "4f1bd8c6509b7a2c",
"transaction.id": "a1b2c3d4",
"user.id": "u_8a1f9",
"error.type": "UpstreamTimeout",
"error.stack_trace": "...",
"sentry.event_id": "9e2f0a4b23c84f2cb5a5b2"
}
Filebeat/Fluent Bit 에이전트
컨테이너 환경에서는 사이드카/DaemonSet로 배포합니다. Filebeat 예시:
filebeat.inputs:
- type: container
paths:
- /var/lib/docker/containers/*/*.log
processors:
- add_docker_metadata: ~
- add_cloud_metadata: ~
output.logstash:
hosts: ["logstash:5044"]
processors:
- add_fields:
target: labels
fields:
env: "prod"
region: "ap-northeast-2"
Logstash 파이프라인: 파싱, 마스킹, 라우팅
input {
beats { port => 5044 }
}
filter {
# JSON 파싱
json { source => "message" target => "json" skip_on_invalid_json => true }
mutate {
# JSON이면 상위로 승격
rename => { "[json]" => "[event]" }
}
# Grok 예시: NGINX access log
if [event][event][dataset] == "nginx.access" {
grok {
match => { "[event][message]" => "%{COMBINEDAPACHELOG}" }
}
}
# PII 마스킹
mutate {
gsub => [
"[event][user][email]", "(?<=.).(?=[^@]*?@)", "*"
]
}
# ECS 표준화
mutate {
add_field => {
"[labels][env]" => "%{[labels][env]}"
"[service][name]" => "%{[event][service][name]}"
}
}
}
output {
elasticsearch {
hosts => ["https://es-prod:9200"]
index => "logs-%{[labels][env]}-%{+yyyy.MM.dd}"
user => "${ES_USER}"
password => "${ES_PASS}"
ilm_enabled => true
ilm_policy => "logs-hot-warm-cold"
}
}
인덱스 설계와 비용 최적화: 빠르고 싸게 저장하기
인덱스 수명주기 관리(ILM)
- 핫(빠른 검색/쓰기) → 웜(저비용 검색) → 콜드(드문 검색) → 삭제
- 롤오버 기준: 최대 문서 수, 인덱스 크기, 기간
예시 ILM 정책:
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": { "max_size": "50gb", "max_age": "7d" },
"set_priority": { "priority": 100 }
}
},
"warm": {
"min_age": "7d",
"actions": {
"forcemerge": { "max_num_segments": 1 },
"set_priority": { "priority": 50 }
}
},
"cold": {
"min_age": "30d",
"actions": {
"set_priority": { "priority": 0 }
}
},
"delete": {
"min_age": "90d",
"actions": { "delete": {} }
}
}
}
}
샤드/레플리카 전략
- 하루 인덱스 50GB 기준: 기본 1~2 샤드, 1 레플리카 권장
- 샤드가 너무 많으면 검색 지연, 관리 복잡 증가
- 인덱스 템플릿으로 매핑 고정(키워드 vs 텍스트, 날짜, 숫자 타입 명확화)
Kibana 대시보드: 조기 감지를 위한 시야 구성
다음 패널을 포함하면 대부분의 장애 신호를 빠르게 파악할 수 있습니다.
- 전사 에러율(HTTP 5xx 비율, Sentry Issue 발생 속도)
- 서비스별 요청 수/오류율/레지던스 p95
- 최근 배포 릴리스별 오류율 비교
- 인프라 자원 지표(CPU/메모리/GC/FS)
- 상위 에러 타입/메시지 Top N, 상위 느린 엔드포인트
- 알림/이벤트 타임라인
실전 팁:
- 대시보드 “링크드 필터”: env=prod, service.name로 글로벌 필터 적용
- 저장 검색(Saved Search)로 RCA 템플릿 만들기: 특정 trace.id, user.id, release 필터
- Lens 시계열 이상 탐지와 ML Job을 함께 사용하면 자동으로 변동 감지 가능
Sentry 통합: 에러와 성능을 코드 수준에서
SDK 초기화(예: Node.js Express)
import * as Sentry from "@sentry/node";
import * as Tracing from "@sentry/tracing";
import express from "express";
Sentry.init({
dsn: process.env.SENTRY_DSN,
environment: process.env.NODE_ENV || "prod",
release: "[email protected]",
tracesSampleRate: 0.2, // 트랜잭션 트레이싱 샘플링
integrations: [new Sentry.Integrations.Http({ tracing: true })],
});
// 요청 스코프에 트레이스 ID 주입
const app = express();
app.use(Sentry.Handlers.requestHandler());
app.use(Sentry.Handlers.tracingHandler());
app.post("/pay", async (req, res, next) => {
try {
// ...
} catch (err) {
next(err);
}
});
app.use(Sentry.Handlers.errorHandler());
Sentry Event ID를 로그에 남겨 ELK와 상호 링크합니다.
app.use((err, req, res, next) => {
const eventId = res.sentry; // Sentry가 부여
console.error(
JSON.stringify({
"@timestamp": new Date().toISOString(),
"log.level": "ERROR",
"message": err.message,
"service.name": "checkout-api",
"sentry.event_id": eventId,
"trace.id": Sentry.getCurrentHub().getScope()?.getSpan()?.traceId
})
);
res.status(500).json({ error: "internal", eventId });
});
베스트 프랙티스
- Release/Environment/Server Name을 일관되게 설정
- Fingerprint/Grouping을 조정해 노이즈 감소
- Breadcrumbs와 User Context로 재현성 향상(PII는 마스킹)
- Performance 트레이스를 사용해 느린 트랜잭션 파악
경보 설계: “시끄럽지 않게” 하지만 “늦지 않게”
Sentry 알림 규칙
- 조건 예시
- 새로운 이슈가 생성되면 알림
- 특정 이슈의 이벤트 속도 > N/min
- 오류율(Regressed release) 급증 시 알림
- 라우팅
- 프런트엔드: 채널 #incident-frontend
- 백엔드 크리티컬: PagerDuty Sev1
- 억제(Suppression)
- 배포 직후 일정 시간 동안 임계치 상향
- 배치 작업/크론 잡 시간대에는 다른 임계치 적용
Kibana 알림
- HTTP 5xx 비율 > 2% (5분 이동 평균) 10분 지속 → Sev2
- p95 응답 시간 > 800ms (특정 서비스) 3회 연속 → Sev2
- 로그량 급증(분당 로그 수 3배 상승) → 이상 탐지 → Sev3
Kibana에서 Slack 커넥터 설정 후, 메시지 템플릿에 대시보드 링크/쿼리 파라미터 포함:
[Prod][checkout-api] 오류율 경보 발생
- 5xx rate: {{context.group.value}}%
- 기간: {{context.period}}
- 대시보드: https://kibana.example/app/dashboards#/view/abc123?_g=(time:from:now-15m)&_a=(filters:!((query:(match_phrase:(service.name:'checkout-api')))))
상관관계 강화: 로그 ↔ Sentry 왕복 이동
- Correlation ID(예: trace.id)를 모든 요청 체인에 전파
- HTTP 헤더(X-Correlation-Id)와 로그, Sentry Scope에 주입
- Sentry event_id를 로그에 남기고, Kibana 필드 포맷터로 Sentry 이슈 링크 생성
- Kibana URL 템플릿:
- sentry.event_id 필드 클릭 → https://sentry.io/organizations/{org}/issues/?query={{value}}
- Sentry 이슈 Description에 Kibana Discover 링크 삽입:
이렇게 하면 알림에서 한 번의 클릭으로 양방향 탐색이 가능합니다.
대응 워크플로우: 사람이 움직이는 절차 설계
장애는 도구가 아니라 사람이 해결합니다. 다음 워크플로우를 명확히 합의하세요.
- 감지
- Sentry/Kibana가 알림 발송 → On-call에게 Slack/PagerDuty
- 분류(Severity)
- Sev1: 결제/로그인 불가, 대규모 고객 영향
- Sev2: 특정 기능 불가 또는 오류율 > 2%
- Sev3: 성능 저하/간헐 오류
- 지정
- Incident Commander(IC) 지정, Communications Liaison, Scribe
- 초기 완화(Mitigation)
- 트래픽 차단/롤백/Feature flag 오프/스케일 아웃 등
- RCA
- Kibana로 로그/지표 확인 → Sentry로 에러 스택, 릴리스 비교
- 최근 변경(배포, 설정, 외부 의존성) 체크
- 해결/검증
- 릴리스/설정 수정 후 지표 회복 확인
- 사후 분석(Postmortem)
- 타임라인, 원인, 재발 방지 액션, SLA 영향 기록
- 학습/자동화
- 알림 튜닝, 대시보드 개선, 런북 업데이트
런북 예시(결제 5xx 급증):
- 체크리스트
- Sentry: checkout-api 이슈 폭증 여부 확인, 최근 릴리스 여부
- Kibana: 5xx 증가 타임라인과 동일 시점의 Upstream 응답 지연 여부
- DB/결제 게이트웨이 타임아웃 지표
- 임시 조치: 이전 릴리스로 롤백 또는 feature flag로 결제 경로 전환
- 근본 조치: 커넥션 풀 사이즈/타임아웃 조정, 재시도 정책 보완
보안과 거버넌스: 로그도 데이터다
- PII/민감 정보
- 수집 단계(Logstash/Ingest Pipeline)에서 마스킹/해시
- Sentry PII 스크러빙 옵션 사용
- 액세스 제어
- Elasticsearch/Kibana 공간(Space)과 롤(Role)로 RBAC
- 감사 로그 활성화
- 규정 준수
- 데이터 보존(ILM)과 삭제 SLA 준수
- Cross-region 복제는 법규 검토
- 비상 차단
- 오용/폭주 시 수집 중단 토글, 샘플링 상향
성능과 비용 관리: 지속 가능한 운영
- 샘플링
- 애플리케이션 로그: 정상 로그는 샘플링(예: 1%), 에러/워닝은 100%
- Sentry tracesSampleRate/ProfilesSampleRate 조정
- 필드 선택
- 고카디널리티 필드 최소화(user.id는 해시/버킷화)
- 대용량 스택트레이스는 요약 저장
- 압축과 롤오버
- forcemerge, cold tier 전환으로 장기 보관 비용 절감
- 프리필터링
- 에이전트에서 노이즈 로그 드롭(healthcheck, liveness)
구축 로드맵: PoC → Pilot → Production
- PoC(2주)
- 단일 서비스 + Filebeat + Logstash + Elasticsearch + Kibana
- Sentry SDK 1개 서비스에 적용, 이슈/알림 동작 확인
- Pilot(4~6주)
- 주요 서비스 확대, ECS 표준화, ILM 적용
- 기본 대시보드/알림 세트 구성, On-call 룰 연동
- Production(8주+)
- 핫-웜-콜드 아키텍처, 보안/RBAC, 백업/스냅샷
- 상관관계(Trace/Correlation ID) 전사 표준
- 런북/포스트모템 프로세스 정착
- 지속 개선
- ML 이상 탐지, 비용 최적화, 릴리스 헬스 모니터링
시나리오: 5xx 폭증 사건의 탐지부터 해결까지
상황: 금요일 오후 6시, 결제 API 오류율 급증.
- Sentry 알림
- “checkout-api: New issue spike UpstreamTimeout (120/min)”
- 최근 릴리스 2.3.1 이후 시작
- Kibana 대시보드
- 5xx rate 6% → Sev1 자동 승격
- p95 응답 시간 1.5s, 외부 PG사 API 응답 지연 동반
- 초동 조치
- Feature flag로 문제되는 라우팅 비활성화(특정 PG사 우회)
- 트래픽 50% 감축, 큐잉 활성화
- RCA
- 로그에서 커넥션 풀 고갈 경고 확인
- 릴리스 2.3.1에서 타임아웃 기본값 증가, 재시도 정책 회귀 발견
- Sentry 트레이스에서 특정 /pay 경로만 느림
- 해결
- 재시도 백오프 수정, 커넥션 풀 상향, 타임아웃 정상화
- 핫픽스 배포 후 10분 내 오류율 < 0.5% 회복
- 사후
- 포스트모템: 회귀 테스트 추가, SLO 보호를 위한 서킷브레이커 규칙 강화
- Kibana 경보 튜닝: 외부 API 슬로우 신호에 선행 알림
핵심: Sentry가 “증상”을 빠르게 감지했고, ELK가 “원인”을 찾는 속도를 높였습니다. 상관관계 메타데이터가 RCA를 단축했습니다.
운영 체크리스트
- 모든 서비스가 JSON 구조화 로그(ECS) 출력
- 요청 단위 Correlation ID/trace.id 전파
- Logstash/Ingest에서 PII 마스킹 적용
- Elasticsearch ILM 정책 설정(핫-웜-콜드)
- 핵심 대시보드(오류율, 레이턴시, 릴리스 비교) 구비
- Sentry Release/Environment 통일, Alert Rule 튜닝
- Slack/PagerDuty 연동과 Escalation 룰 정의
- 런북/포스트모템 프로세스 활성화
- 비용/성능 샘플링 정책 적용
- 접근 제어(RBAC)와 감사 로그 활성화
자주 겪는 함정과 회피 전략
- 노이즈 폭탄: 임계치 너무 낮거나 배포 시간대 무시 → 시간대별/환경별 임계치, 알림 억제 윈도우 도입
- 고카디널리티 필드 폭증: userId, sessionId를 키워드로 무분별 저장 → 해시/버킷화, not_analyzed 필드 최소화
- 상관관계 부재: trace.id 미전파 → 미들웨어로 자동 주입, 아웃바운드 HTTP/DB에도 전파
- 보존 비용 급등: 무제한 보관 → ILM/샘플링/필드 축소
- Sentry 그룹핑 혼선: stack trace 미미한 차이로 분리 → fingerprint 규칙 커스터마이징
팀 변화: 데이터 기반 장애 문화 만들기
- 공용 언어: SLI/SLO, Sev, MTTR/MTTD 등 용어 통일
- 대시보드 데일리 리뷰: 배포 후 1시간, 스탠드업에서 어제 지표 검토
- 포스트모템은 비난이 아닌 학습: 액션 아이템 추적
- 개발자 경험 개선: 로컬에서도 Sentry DSN/샘플링 설정으로 재현성 강화
마무리: 빠르게 감지하고, 정확히 진단하고, 안전하게 복구한다
효율적인 장애 관리는 기술과 프로세스, 문화가 함께 필요합니다. ELK는 광범위한 로그와 지표를 정규화·탐색·시각화하는 기반을 제공하고, Sentry는 애플리케이션 에러와 성능 이슈를 코드 수준에서 빠르게 포착합니다. 둘을 상관관계로 엮고, 경보와 런북, 온콜 프로세스를 더하면 MTTD(감지까지 시간)와 MTTR(복구까지 시간)을 크게 줄일 수 있습니다.
작게 시작해 빠르게 학습하고, 표준화와 자동화를 통해 조직 전체로 확장하세요. 로그는 쌓이는 것이 아니라, “쓰는” 것입니다. ELK와 Sentry로 로그가 말하는 신호를 가장 먼저 듣는 팀이 되길 바랍니다.