Cheondi Review 2026년 5월호

Observability Practice

로그를 많이 남긴다고 원인이 보이는 건 아니다

로그, 메트릭, 트레이스를 따로 운영하면서 생기는 단절과 OpenTelemetry를 공통 수집 경계로 두는 이유를 짚는다.

도구를 하나로 합치는 것보다 같은 요청을 화면에서 서비스까지 따라갈 수 있는 식별자와 질문을 먼저 맞춰야 한다.

Cloud Native Computing Foundation · CNCF · 2026.05.06

원문 GitHub 내 포스팅

Project Maturity

2019년 sandbox에서 시작한 OpenTelemetry가 2026년 5월 graduated 프로젝트가 되기까지의 범위와 생태계를 확인한다.

성숙한 표준과 도구가 생겼다는 뜻이지, 어떤 신호를 왜 수집할지에 대한 제품별 판단까지 대신해 주는 것은 아니다.

Cloud Native Computing Foundation · OpenTelemetry Maintainers · 2026.05.11

원문 GitHub 내 포스팅

Telemetry Signals

traces, metrics, logs, baggage, profiles가 각각 어떤 질문에 답하는지 공식 개념 문서에서 구분한다.

모든 정보를 한 신호에 밀어 넣기보다 trace ID처럼 서로 연결할 최소 문맥을 공유하는 편이 조사하기 쉽다.

OpenTelemetry · OpenTelemetry Authors · 2026.03.10

원문 GitHub 내 포스팅

Source Code Shelf

OpenTelemetry Go

여러 형식의 telemetry를 받아 처리하고 내보내는 vendor-neutral 수집 파이프라인 구현이다.

저장소 보기

OpenTelemetry Go

Go 서비스에서 trace, metric, log 문맥을 계측하는 API와 SDK 구현을 확인할 수 있다.

저장소 보기

Grafana Labs Go

분산 trace를 저장하고 로그와 메트릭에서 trace로 이동하는 백엔드 구성을 읽기 좋다.

저장소 보기

Cheondi's Desk

Evidence Chain

화면 증상, API 요청, 서비스 로그와 trace를 같은 사건의 증거로 연결하는 순서를 정리한 기록이다.

참고 자료 3개 · 코드 저장소 3개