로그 모니터링, 어디부터 봐야 효율적일까요?

---

실제 장애 터졌을 때 로그 쌓인 거 보는데 너무 막막하네요.
다들 웹서버, WAS, DB 로그 다 봐야 한다고 하는데, 근데 이게 너무 방대해서 어디서부터 손대야 할지 감이 안 잡혀요.

일단 장애가 발생하면 보통 트래픽 폭증 같은 외부 요인부터 의심하게 되거든요.
그래서 웹 서버 로그부터 보는 게 맞는지, 아니면 비즈니스 로직에 문제가 생겼을 때 WAS 쪽으로 바로 깊게 들어가는 게 효율적인지 궁금합니다.

혹시 이런 상황에서 '가장 먼저 봐도 될 만한', 즉 원인 특정 확률이 높은 로그 시그널이 있다면 뭐가 있을까요?
관성적으로 다 보는 게 아니라, 시간 대비 효율을 따져서 우선순위를 정하고 싶습니다.

로그 모니터링 이거 진짜 만만하게 볼 수 없는 부분이죠.
저도 처음에 장애 났을 때 로그 보면서 '이걸 다 봐야 돼?' 싶었던 적이 정말 많아서, 질문자님 마음 너무 이해합니다.
방대함 자체가 제일 큰 적이에요.
결론부터 말씀드리자면, '무조건 이걸 먼저 봐야 한다'는 만능 공식은 없지만, 보통은 외부 요인(인프라/트래픽)부터 시작해서, 점차 내부 비즈니스 로직으로 깊게 들어가는 단계적 접근이 가장 효율적입니다.
관성적으로 다 보는 것보다, '가설 설정 -> 검증'의 사이클을 돌린다고 생각하시면 돼요.
제가 경험했던 것들과, 현업에서 많이 쓰는 효율적인 순서대로 몇 가지 팁을 좀 풀어보겠습니다.
--- ### 1.
장애 발생 직후 (초기 대응 단계) - '큰 그림' 파악이 핵심 장애가 터진 직후에는, '무엇이 아예 안 되고 있는가?' 를 파악하는 게 1차 목표입니다.
여기서 너무 깊게 파고드는 건 시간 낭비예요.
1순위: 외부/인프라 레벨 (웹 서버 로그, API Gateway 로그) 가장 먼저 봐야 할 곳은 **접근 로그(Access Log)**와 **에러 로그(Error Log)**가 모여있는 웹 서버(Nginx, Apache 등) 레벨입니다.

• 왜 여기부터 보냐? * 사용자 요청이 우리 시스템에 아예 도달했는지, 아니면 중간에 막혔는지(CDN, 로드 밸런서 등)를 여기서 한 번에 볼 수 있어요.
• 가장 먼저 체크할 시그널: * HTTP 4xx 코드의 급증: 사용자 측 문제(잘못된 요청 경로, 인증 실패 등)가 갑자기 늘었는지 확인.
  (이 경우 WAS 문제는 아닐 수 있음) * HTTP 5xx 코드의 급증: 서버 내부 문제(WAS, DB 등)가 확실히 발생했다는 신호.
• 요청량(Request Volume)의 급변: 트래픽이 갑자기 폭증했는지, 아니면 갑자기 0으로 떨어졌는지 확인.
  (이는 외부 이슈나 서비스 중단 신호일 수 있음) * 실무 팁: * 이 단계에서는 '시간대별 트래픽 변화 추이 그래프' 를 보는 게 로그 자체를 훑는 것보다 10배는 효율적입니다.
• 만약 API Gateway나 로드 밸런서 단에서 지표(Metrics)를 수집하고 있다면, 이 지표를 1차로 보는 게 가장 빠릅니다. 로그는 '사건 기록'이고, 메트릭은 '상태 변화 추이'니까요.
  2순위: WAS (애플리케이션 서버) 로그 - '비즈니스 흐름' 확인 웹 서버에서 5xx 에러가 확인되거나, 트래픽은 정상인데 특정 기능만 안 된다는 느낌이 들 때 들어갑니다.
• 여기서 뭘 찾을까? * 예외(Exception) 로그: NullPointerException, TimeoutException, OutOfMemoryError 등 구체적인 예외 메시지를 찾으세요.
  이 예외 메시지가 원인 특정에 가장 결정적입니다.
• 특정 트랜잭션의 시작/종료 로그: 만약 서비스 로직에 @Log 같은 걸 붙여서 특정 API 호출 시작/종료 시점을 찍어뒀다면, 성공한 요청과 실패한 요청의 경계 지점을 비교하는 게 좋아요.
• 주의할 점 (흔한 실수): WAS 로그만 본다고 '비즈니스 로직 오류'라고 단정 짓지 마세요.
  로그가 뜬 건 '예외가 발생했다'는 사실만 알려줄 뿐, '왜' 발생했는지는 원인 분석이 필요합니다.
  --- ### 2.
  문제의 영역별 분리 및 심화 분석 (원인 추적 단계) 만약 1차 분석에서 'WAS에서 DB 연결이 문제인 것 같다'는 가설이 세워졌다면, 이제 로그의 범위를 좁혀야 합니다.
  가설 검증 순서 (가장 효율적인 흐름) 1.
  [웹 서버] $\rightarrow$ [WAS] $\rightarrow$ [DB] 순서로 역추적 하는 것이 기본 원칙입니다.
• 요청(Request)이 왔고 $\rightarrow$ WAS에서 처리하다가 $\rightarrow$ DB에 접근하려 할 때 문제가 생기는 구조가 가장 흔하거든요.

DB 로그 분석 시 유의점: * DB 로그는 보통 '느린 쿼리(Slow Query)' 에 집중해야 합니다.

• 단순히 에러가 뜬 것보다, "평소보다 이 쿼리가 갑자기 엄청나게 느려졌다" 가 더 큰 장애 원인일 때가 많습니다.
• 쿼리 실행 계획(Execution Plan)을 확인하는 것이 로그 분석보다 더 중요할 때가 많으니, 이 부분은 DBA 분의 도움이 필요할 수 있습니다.
  --- ### 3.
  로그 모니터링 효율성을 극대화하는 실무적 조언 (이게 제일 중요) 로그를 '보는 방법' 자체를 개선해야 시간이 단축됩니다.
  A.
  구조화된 로깅 (Structured Logging)으로 전환하세요. 이게 정말 혁신적입니다.
  지금 로그가 <날짜> [레벨] 메시지 내용 이렇게 텍스트로만 되어 있다면, 이걸 JSON 형태로 바꾸세요.
• Before (텍스트): 사용자 ID 123이 상품 A를 조회하려다 DB 연결 시간 초과로 실패함. * After (JSON): json { "timestamp": "2024-05-20T10:00:00Z", "level": "ERROR", "service": "product-api", "user_id": 123, "endpoint": "/api/product/view", "error_type": "DB_TIMEOUT", "details": "Connection timed out while fetching product details." } * 효과: 이렇게 구조화하면, 모니터링 툴(ELK Stack, Grafana/Loki 등)에서 WHERE user_id = 123 AND error_type = "DB_TIMEOUT" 같은 쿼리가 가능해집니다.
  텍스트 검색보다 수십 배 빠릅니다.
  B.
  경고(Alert)는 '결과'가 아닌 '이상 징후'에 걸도록 설정하세요. "에러가 10건 넘으면 알려줘" 같은 단순 카운트는 너무 흔합니다.
• 효율적인 알람 조건 예시: 1.
  평균 응답 시간(Latency)이 평소 대비 3배 이상 증가했을 때.
  (트래픽은 정상인데 느려지는 경우를 잡아냄) 2.
  특정 비즈니스 핵심 API의 성공률(Success Rate)이 95% 이하로 떨어졌을 때. 3.
  특정 시점(예: 정오, 업무 시작 시간)에 평소와 다른 패턴의 에러가 반복될 때.
  (예: 평소엔 304가 나오는데 갑자기 500이 나오기 시작) C.
  로그 수집 대상을 범위를 좁히세요 (Scope Down). 모든 로그를 다 볼 필요는 없습니다.
• 로그 레벨(Log Level) 필터링: 운영 환경에서는 DEBUG 레벨 로그는 전부 비활성화하거나, 심각한 장애 발생 시에만 수동으로 켜세요.
  INFO 레벨은 '성공적으로 정상 작동한 기록'이 너무 많아서 오히려 노이즈가 됩니다.
  WARN과 ERROR 레벨에 집중하는 게 좋습니다.
  --- ### 요약 정리 (질문자님을 위한 체크리스트) | 단계 | 목표 | 주로 볼 로그/지표 | 핵심 체크 포인트 | | :--- | :--- | :--- | :--- | | 1단계 (초기) | 시스템 전반의 상태 파악 (외부 $\to$ 내부) | Access Log, API Gateway Metrics | 5xx 코드 급증 여부, 트래픽 급변 여부 | | 2단계 (가설 수립) | 문제 발생 지점 추정 | WAS Error Log, 트랜잭션 추적 로그 | 구체적인 예외 메시지 확인 (NPE, Timeout 등) | | 3단계 (검증/심화) | 근본 원인 특정 | DB Slow Query Log, 시스템 메트릭 | 느려진 쿼리, 리소스 고갈(메모리/커넥션 풀) 여부 | 로그 모니터링은 결국 '가설을 세우고, 그 가설을 가장 빨리 반증하거나 입증할 수 있는 곳' 에 시간을 쓰는 싸움입니다.
  처음에는 이 '가설 설정' 과정에 시간을 많이 쓰시고, 구조화된 로깅을 통해 검색 속도를 높이는 방향으로 시스템을 개선하는 걸 목표로 삼으시면 금방 감이 잡히실 겁니다.
  너무 스트레스 받지 마시고, 차근차근 이 단계별 접근 방식을 적용해 보시길 바랍니다.
  화이팅입니다!