반응형

traces 2

4편. 로그-메트릭-트레이스를 같이 봐야 하는 이유

3편에서 Trace가 끊어지는 가장 큰 원인이 Context Propagation이라는 이야기를 했다. 그런데 Context를 잘 전달했더라도, 여전히 이런 상황은 자주 발생한다.“메트릭은 분명히 나빠졌는데, 로그에서는 큰 문제가 안 보인다.” “로그에는 에러가 있는데, 지표는 정상이다.”이 혼란의 원인은 단순하다. 각각 다른 질문에 답하는 도구를, 하나의 답을 기대하며 보고 있기 때문이다.Signals는 역할이 다르다OpenTelemetry 공식 문서는 관측 신호(signals)를 traces, metrics, logs 세 가지로 나눈다. 이 분류는 구현 편의가 아니라, 각각이 답하는 질문이 다르기 때문이다.Metrics: 지금 시스템 상태가 정상인가? (전체적인 건강 상태를 빠르게 본다)Logs: 어..

1편. 로그도 있고 메트릭도 있는데, 장애 원인은 왜 안 보일까?

장애가 났다. 알람도 울렸고, 대시보드도 빨갛다. 로그도 남아 있다. 그런데 막상 "왜 느려졌는지"를 한 문장으로 말하기가 어렵다. 특히 서비스가 여러 개로 쪼개진 분산 환경에서는 이 문제가 더 자주-더 오래 반복된다.이 글은 OpenTelemetry 공식 문서의 관점(telemetry를 통해 내부 상태를 이해한다)을 빌려, 왜 이런 일이 생기는지-그리고 무엇이 빠져 있는지를 "문제 중심"으로 정리한다. 다음 글부터는 OpenTelemetry의 핵심 개념을 하나씩 붙여서, 실제로 원인을 추적 가능한 형태로 만들어갈 예정이다.현실: 로그-메트릭은 있는데 "요청 흐름"이 없다우리가 흔히 갖고 있는 관측 데이터는 보통 두 가지다.로그: 특정 시점에 어떤 일이 발생했는지(텍스트로 기록)메트릭: 어떤 값이 얼마나..

반응형