조용한 개발 노트

보이지 않으면 통제할 수 없다분산 시스템은 정상과 비정상의 경계가 흐리다.일부 요청만 실패한다특정 구간에서만 지연이 발생한다장애는 천천히 퍼진다이런 환경에서 단순한 모니터링만으로는 무엇이 일어나고 있는지 알 수 없다.그래서 분산 시스템에서는 Observability가 필수가 된다.Observability는 모니터링이 아니다모니터링은 보통 다음 질문에 답한다.CPU 사용률은 얼마인가에러율이 증가했는가서버는 살아 있는가하지만 분산 시스템에서 더 중요한 질문은 이것이다.왜 이 요청이 실패했는가Observability는 내부 상태를 추론할 수 있는 능력을 의미한다.왜 분산 시스템은 본질적으로 불투명한가분산 시스템은 다음 이유로 본질적으로 불투명하다.요청이 여러 서비스와 노드를 거친다부분 실패가 정상 동작처럼 보..

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

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