OTel의 실험적 상태가 길어지는 이유: 호환성, 유지관리자, 방대한 범위의 충돌

수동 계측이 아주 큰 문제였던 적은 없음. 비즈니스 이벤트를 이해하고 넣기 시작하면 얻는 정보가 훨씬 많아짐.

벤더 SDK의 대안은 락인, 큰 비용, 복잡한 환경에서 불완전한 지원임. OTel은 누구나 무료 공개 명세로 OTLP 소스를 만들 수 있고 여러 싱크에 붙일 수 있다는 점이 큼.

나는 Prometheus와 Jaeger를 각각 쓰는 편이 낫다고 봄. 둘은 단순해서 전부 이해할 수 있고, 회사 프레임워크용 작은 셈을 직접 만드는 일도 어렵지 않음. OTel은 단순하지도 않음.

OTel이 사실상 이길 흐름이라 더 답답함. 주요 벤더 지원은 아직 알파나 베타 같고, 성능 비용과 서버리스 콜드스타트 비용이 크며, 결국 벤더별 exporter 설정과 전용 계측도 남음.

게이트웨이와 엣지 Collector를 둘 다 돌릴 필요는 없음. 앱이 OTLP로 싱크에 직접 보내게 하면 되고, 보통 URL과 DSN 헤더만 설정하면 됨.

나는 OTel이 없었으면 좋겠음. 추상화 설계가 나쁘고, 그 때문에 코드가 너무 지저분해짐.

나는 코드에 한 번만 주석을 달고, 런타임에 메트릭·로그·트레이스 중 무엇으로 볼지 고를 수 있으면 좋겠음. 대시보드 이상 징후를 보고 다음 발생 때만 트레이스를 저장하라고 클릭 한 번으로 지시하고 싶음.

나는 기본적으로 전부 트레이싱하고 나중에 샘플링을 고르는 방식을 씀. Grafana Cloud에도 이런 적응형 샘플링 방식이 있음.

내 생각에 트레이스는 가장 일반적인 형식임. span에는 시간 범위, 트리 관계, 태그와 이벤트가 있으니 여기서 메트릭과 로그를 뽑을 수 있음. 처음부터 프로그램에 트레이싱을 넣어야 함.

메트릭을 트레이스로 표현할 수 있다는 말에는 동의 못 함. GC 메트릭 같은 것은 로그나 트레이스로 만들 수 없고, 셋은 서로 다른 데이터임. 이상 징후를 감지해 샘플링 결정을 내리는 구성 요소는 만들 수 있음.

내가 보기엔 문제는 너무 많은 것을 하나의 명세에 넣고, 수많은 어댑터를 단일 표준 기구의 승인을 거치게 하는 설계임. 데이터가 드나드는 규약만 정하고 각자가 어댑터를 만들게 해야 함.

나는 관측성을 오래 했는데 OTel은 그냥 쓸 만함. 시작 시점에 샘플링을 정하는 점은 아쉬워서, 헬스체크 같은 '지루한' segment를 내보내기 전에 버리고 예상된 오류는 오류 등급을 낮추도록 고쳤음.

HN에서는 OTel을 늘 불평하지만, 글의 데이터가 프로젝트가 위기라는 근거는 아니라고 봄. 언어마다 투입 인력이 다른 건 사실이지만, 대부분은 건강한 오픈소스 프로젝트로 보임.

내게 OTel은 Kubernetes와 비슷함. 바로 쓰는 프레임워크라기보다 그 위에 프레임워크를 만드는 기반임. 벤더가 내부에서 이를 써서 조합은 쉬워지고, 각 프레임워크와 백엔드의 버그 많은 지원은 줄었으면 함.