조용한 개발 노트

10편에서 샘플링이 Observability의 성패를 좌우한다고 이야기했다. 그런데 샘플링까지 잘 설정했는데도, 여전히 이런 말을 듣게 되는 경우가 있다.“Trace는 보이는데, 그래서 뭐가 문제인지는 모르겠다.”이 단계에서의 문제는 도구가 아니다. 대부분 표현 방식과 해석 방식에 있다.문제 1. 이름이 의미를 전달하지 못한다Trace를 열었을 때 가장 먼저 보이는 것은 Span의 이름이다.그런데 이런 이름을 자주 보게 된다.method.invokeservice.callprocess기술적으로는 맞을 수 있다. 하지만 이 이름들만으로는 무슨 일이 일어났는지 설명할 수 없다.OpenTelemetry 공식 문서는 Span 이름이 “무엇을 했는지”를 한 문장으로 설명해야 한다고 강조한다.예를 들어:GET /or..

1편에서 다뤘던 문제를 다시 떠올려보자. 로그도 있고 메트릭도 있는데, 막상 장애가 나면 "어떤 요청이 어디서 느려졌는지"를 한 번에 설명하기가 어렵다.이 문제를 해결하기 위해 OpenTelemetry는 요청 단위 관측을 핵심 개념으로 삼는다. 그리고 그 중심에 있는 신호가 바로 Trace다.왜 요청 단위 관측이 중요한가메트릭은 전체를 요약한다. 예를 들어 p95 latency, error rate 같은 값은 시스템의 상태를 빠르게 감지하는 데 매우 유용하다.하지만 메트릭만으로는 다음 질문에 답하기 어렵다.느려진 요청은 모두 그런가, 일부만 그런가?특정 사용자-특정 기능에서만 발생한 문제인가?느려진 요청이 어떤 내부 호출 경로를 거쳤는가?이 질문들은 모두 "요청 하나"를 기준으로 시스템을 보고 싶다는 요..