[OTEL] OpenTelemetry란

 

 

 

---

OpenTelemetry

 

 

OpenTelemetry는 줄여서 OTel이라고도 많이 사용되며, OpenTracing과 OpenCensus라는 두 개의 프로젝트가 합쳐져서 탄생한 프로젝트이다.

 

 

다양한 모니터링 시스템과 함께 통합되어 사용되는 오픈소스 중 하나이며 Trace, Metric 및 Log를 수집하는 데 사용된다.

 

 

현재는 CNCF에서의 Incubating의 단계에 속해있으나, 많은 벤더사의 지원을 받으며, Shopify, eBay나 Github과 같은 대형 조직에서도 사용되고 있다는 것을 볼 수 있다.

 

 

 

Otel을 지원하는 벤더사는 아래 사이트에서 확인할 수 있는데, 굉장히 많은 업체가 나열되어 있는 것을 확인할 수 있다.

 

 

https://opentelemetry.io/ecosystem/vendors/

Vendors

 

---

아키텍처

 

OTel의 아키텍처는 아래와 같다.

[출처 : https://opentelemetry.io/docs/]

 

 

아키텍처를 컴포넌트의 흐름대로 보자면,

 

 

1. 마이크로 서비스에 부착된 OTel의 API/SDK가 수집하는 데이터를 OTel Collector(또는 다른 수집기)로 전송

 

2. Collector에 집계된 데이터를 Collector가 데이터 저장소에 저장

 

 

 

 

※ OTel의 Kubernetes Operator는 쿠버네티스 클러스터 내에서 OTel 컴포넌트를 관리하는 역할을 수행하는데, 그 예시로 Annotation을 이용하여 애플리케이션 파드에 API/SDK를 적용하거나, CRD를 통하여 Collector를 생성하는 등의 역할을 수행한다.

 

 

https://opentelemetry.io/docs/kubernetes/operator/

OpenTelemetry Operator for Kubernetes

 

 

 

 

 

이렇게 데이터를 수집하는 역할은 하지만, 자체적으로는 관찰 가능성(Observability)을 제공하는 기능은 없기 때문에, Prometheus나 Jaeger와 같은 다른 오픈소스와 함께 사용되는 경우가 많다.

 

 

 

---

장점

 

1. 환경에 따라서 애플리케이션 내 코드의 수정이 전혀 없이 OTel을 적용 가능(Zero-code Instrumentation)
2. 유연하고 확장성이 좋음(확장하기 좋도록 설계가 되어 있음)
3. 다양한 언어를 지원(API/SDK)

[출처 : https://opentelemetry.io/docs/languages/]

 

 

 

단점

 

1. 초기 설정이 어렵고 복잡하기 때문에, 각 구성 요소(컴포넌트)에 대한 이해가 필요
2. 아직 개발 중인 부분이 다소 존재하여 일부 환경에서는 부적합하고 버전에 따른 변화가 클 수 있음

 

 

 

Otel은 아직 개발과 개선이 꾸준하게 진행 중인 프로젝트라고 생각이 된다.

 

하지만 현재는 Datadog이나 Elastic과 같은 유료 서비스를 제외한다면, 관측 가능성을 위한 데이터를 발생시키는 오픈소스 중에는 Otel이 많은 입지를 차지하고 있는 것이 아닌가 싶다. 

 

 

 

---