OpenTelemetry이 잘 안 되고 있다 (그리고 제가 스프레드시트를 만들었습니다)
OTel isn't going well (and I made a spreadsheet about it)
OpenTelemetry는 수년째 '아직 완성되지 않은' 느낌을 주며, 이에 대한 불만이 끊이지 않는다. 저자는 CNCF 프로젝트인 Envoy, Prometheus와의 24개월 활동 데이터를 비교 분석해 문제의 원인을 찾아냈다. 주요 원인은 세 가지다: 바이너리 안정성 게이트, 소수의 핵심 유지보수자에 대한 과도한 의존, 그리고 방대한 언어/프레임워크 지원 범위. 특히 PHP, Ruby, Kotlin 등 일부 SDK는 한두 명의 유지보수자에게 병목이 집중되어 있으며, 이는 오픈소스 생태계의 건강성에 심각한 위협이다. 또한 semantic-conventions 저장소의 PR 처리 속도는 예상과 달리 병목이 아니었다. 결론적으로, 안정성에 대한 장기 계약은 취미 개발자에게 맞지 않으며, 이는 결국 유지보수자 고용 문제로 귀결된다.
안정성에 대한 기대가 프로젝트를 사실상 동결시켰다는 느낌이 든다.
HN 토론
118- osener
OpenTelemetry에 대해 항상 저를 헷갈리게 하는 점은 트레이싱, 메트릭, 로그가 모두 독립적으로 설계되었다는 것입니다. 코드베이스에 한 번만 주석을 달고, 무언가를 메트릭/로그/트레이스로 노출할지에 대한 최종 결정을 런타임에 동적으로 할 수 있다면 좋겠어요.
예를 들어, 모니터링 대시보드의 그래프를 보고 뭔가 수상한 점을 발견하면, "다음에 이런 일이 또 발생하면 트레이스를 저장해줘"라고 말하고 싶습니다. 그냥 마우스 클릭 한 번으로 그렇게 할 수 있어야 해요.
그들이 트레이싱 스펙/SDK를 출시하고 "이제 메트릭과 로그로 넘어가자"고 말했던 것을 기억합니다. 그게 항상 저에게는 옳게 느껴지지 않았어요.
- EdSchouten
OTel은 정말 답답합니다. 이 분야에서 확실한 승자가 되지 않았다면 그렇게 많이 불평하지 않았을 거예요. 하지만 오늘날:
1. 모든 주요 벤더는 여전히 이 모든 시간이 지난 후에도 OTel에 대해 이상한 알파/베타 지원 상태에 있습니다.
2. 성능 저하가 상당해서, 같은 워크로드를 실행하는 데 두 배의 컴퓨팅/RAM이 필요하다면 성능 계측의 의미가 무엇인지 의문이 들게 합니다.
3. 서버리스 런타임은 OTel로 콜드 스타트에 큰 패널티를 받습니다.
4. 현실적인 사용을 위해서는 게이트웨이 수집기와 엣지 수집기를 모두 실행해야 합니다.
5. 대상 내보내기기를 각각 고유한 방식으로 구성해야 합니다. 이는 OTel의 가치가 무엇인지 의문을 갖게 합니다.
6. OTel이 다루는 범위를 넘어서는 벤더는 여전히 자체 맞춤형 계측이 필요합니다. 그렇다면 이 모든 것의 의미가 무엇이었을까요?
- psadri
저는 동의하지 않습니다. 저는 관측성(observability)에 관심이 많은 사람인데, OTel은... 괜찮습니다.
제가 원하는 몇 가지가 빠져 있지만, 직접 구현할 수 있었습니다. 주요 설계 문제는 샘플링 결정이 세그먼트의 _시작_ 시점에 이루어진다는 점이라고 생각합니다. 그래서 몇 가지 개선 사항을 직접 구현했습니다:
1. 세그먼트를 "지루한" 것으로 표시하여 내보내기 전에 버릴 수 있는 기능. 헬스체크, "대기 중인 작업 가져오기" 같은 빈 쿼리 등에 유용합니다.
2. 오류를 반환할 것으로 예상되는 세그먼트(예: S3에 존재하지 않는 객체에 대한 HEAD 요청으로 캐시된 블롭이 있는지 확인하는 경우)에 대해 오류를 다운그레이드하는 기능.