장애 또는 버그를 분석할 때 로그를 어떻게 설계하고 활용하시나요?

Question

Accepted Answer

재현이 안 돼도 추적 가능한 로그를 지향합니다 핵심 키워드: 로그 레벨, traceId, 구조화 로그 "장애 상황에서는 재현이 안 되는 경우가 많아서, 한 요청의 흐름을 end-to-end로 추적할 수 있도록 traceId를 공통으로 남기도록 설계합니다." "또한 단순 문자열 로그보다는 JSON 구조화 로그로 남겨서, 검색과 필터링을 쉽게 하고, 로그 수집 시스템(예: ELK, Loki)에서 원하는 조건으로 바로 분석할 수 있게 합니다." "로그 레벨은 DEBUG/INFO/WARN/ERROR 기준을 팀에서 합의해 두고, 운영 환경에서는 INFO 이상만 남기되, 필요하면 일시적으로 DEBUG를 켜서 분석하는 식으로 운영합니다." 꼬리질문: 로그가 너무 많아서 오히려 분석이 어려웠던 경험이 있다면, 어떻게 정리하셨나요?
메트릭/트레이싱과 로그를 함께 활용한 사례가 있다면 공유해 주세요.

장애 또는 버그를 분석할 때 로그를 어떻게 설계하고 활용하시나요?

질문 의도

평가 포인트

이 주제를 더 공부하고 싶나요?

개발자에게 필요한 로그 관리| 이준형(Foo) - 인프런 강의

Springboot 모니터링 시스템 구축 (프로메테우스 + 그라파나)| Neo - 인프런 강의