[OpenTelemetry] 2. OpenTelemetry란 무엇일까?

 

OpenTelemetry

OpenTelemetry (축약해서 OTel)은 trace, metric, log와 같은 telemetry 데이터를 instrumenting, generating, collecting, exporting 하기 위한 특정 벤더에 종립되지 않은 오픈소스(vendor-neutral open-source) Observability framework입니다.

 

 

OpenTelemetry가 왜 필요할까?

분산된 시스템이 커지고, 확장됨에 따라 개발자 입장에서 자신의 서비스가 어떤 서비스에 의존적이고 의존되고 있는지 파악하기 어려워졌고, 결론적으로 어떠한 영향을 받는지/주는지 보기 어려워졌습니다.

특히, 서비스 배포 또는 중단하는 경우에 말이죠.

 

이러한 문제를 해결하기 위해 어떻게 해야할까요?

일단, 시스템에 대한 정보가 부족하므로 시스템을 계측(instrument)해서 관찰가능(observable)하게 만들어야 합니다.

즉, 애플리케이션 코드에서 trace, metric, log 등과 같은 telemetry 데이터를 계측해야 하고, 이 계측된 데이터들을 Observability back-end로 전송해야만 합니다.

• 다양한 Observability back-end가 존재하는데요. Self host open-source 중에는 Jaeger, Zipkin 등이 있으며 상업적인 툴들도 다수 존재합니다.

 

 

과거에는 코드에서 계측되는 방식이 정말 다양했습니다. 예를 들어, Observability back-end에서 만든 자신의 계측 라이브러리(instrumentation libraries) 또는 에이전트를 추가 및 설치해서 운영해야만 했습니다.

다시 말해서, Observability back-end에 보내는 데이터 형식에 표준이 없어 각 Observability back-end에 맞는 라이브러리/에이전트를 사용해야만 했습니다.

이런 상황에서 만약 회사가 Observability back-end를 바꾸기로 결정했다고 하면 어떻게 될까요? 코드 단의 라이브러리/서버 내 설치되어진 에이전트 등을 다 수정해야만 했을 것입니다.

 

 

이런 표준에 대한 필요성이 인식되기 시작하면서, cloud community가 2가지 open-source project를 만들게 되었습니다.

• OpenTracing (CNCF project)
• OpenCensus (Google Open Source community project)

 

각 프로젝트마다 장단점이 존재했는데 이 둘이 조금 다르다보니 하나의 단일 표준을 목표를 하게 되었고, 결국 2019년에 이 두 프로젝트가 병합되어 OpenTelemetry가 탄생하게 되었습니다.

OpenTelemetry의 목표는 벤더에 종속되지 않는 SDK, API, tool을 통해 telemetry 데이터를 측정하고 Observabiltiy back-end로 전송하는 것입니다.

 

헷갈리지 맙시다.

OpenTelemetry는 observability back-end가 아닙니다. 즉, Jaeger, Zipkin, Prometheus 와 다릅니다.

대신에 이러한 Observability back-end에 데이터 전송을 지원하는 역할을 합니다.

다양한 프로토콜 및 형식을 지원해 Observability back-end에 종속되지 않는 구조로 만들어졌습니다.