최근 회사에서 활용하게 될 OpenTelemtry에 대해 조사하게 되었다.
OpenTelemetry 는 무엇인가? Observability를 위한 프레임워크이자 툴킷이다. OpenTelemtry에서는 Observability를 어플리케이션이 잘 동작하는지 파악하기 위한(instrumentation 이라고 한다.) 데이터들(signal, telemetry data)이라고 정의하며 이를 로그, 매트릭, 트레이스로 분류하였다. 다시 말해, 시그널 데이터들을 통해 어플리케이션을 관측할 수 있고, 이에 도움을 주는 프레임워크이자 툴킷을 OpenTelemetry라고 한다.
What is OpenTelemetry? | OpenTelemetry
기존에도 Fluentd, Prometheus, Jaeger 등 다양한 시그널 데이터와 관련된 제품들이 많이 있었다. 이들과 OpenTelemtey의 차이는 무엇일까? 이는 표준화를 목표로 한다는 것이다. OpenTelemetry는 다른 제품들과는 달리 "밴더(제공자)와 무관하고 단순하게 수집하게 한다"는 목표를 가지고 있다. (물론 되려 사용자들에게 복잡하다는 평가를 듣기도 한다...)
그렇다면 OpenTelemetry 는 어떻게 어플리케이션을 관측할 수 있게 해줄까? 일반적으로 이러한 Observability는
여기에서 OpenTelemetry는 (1)과 (2)를 지원한다. 참고로 (3)은 다른 오픈소스들에 맡긴다.
위 이미지와 같이 볼 수 있다. OTel Auto.Inst, OTel API, Otel SDK 등이 데이터를 내보내는 Agent 역할 OTel Collector는 데이터를 모아 여러 저장소로 내보내는 파이프라인 역할을 가진다.
참고로 OTel에서 제공하는 로그, 매트릭, 트레이스 도구들 뿐만이 아니라 범용적인 솔루션들 (Prometheus, jaeger, datadog 등)도 OTel Colloector로 전송하여 저장할 수 있다.
OTel Collector은 아래와 같은 구조를 가지고 있다.
여러 데이터소스에서 전달받은 데이터를 Collector라는 컴퍼넌트를 통해 처리하여, 여러 백엔드 저장소로 내보낸다. 아까 살펴봤듯, 여러 데이터 소스와 백엔드 저장소를 지원한다. 구조 자체는 기존에 본인이 알고 있던 Fluentd와 유사했다. 다만 로그뿐만이 아니라 다양한 종류의 데이터를 처리하고자 한다는 점, 오픈소스에 적극적이라는 점, CNCF에서 밀어주고 있다는 점 등의 차이가 존재했다.
추가로 Collector에 대해 유의깊게 살펴보았던 건 (1) config를 배포할 수 있는지 (2) Persistent Queue를 지원하는지 였다.
회사에서 위와 같은 데이터 파이프라인을 운영하다 보면 요구사항으로써, (ㄱ) 저장하고싶은 저장소를 즉각적으로 바꿀 수 있는지 (ㄴ) 많은 트래픽에 프로그램이 종료되더라도 데이터가 유실되지 않는지 가 중요한데, 이들이 각각 (1) - (ㄱ), (2) - (ㄴ)와 직결되는 문제였다.
OpenTelemetry에서는 Collector을 관리하기 위해 Operator Pattern을 적용한 OTel Operator을 제공한다. Operator는 K8S에 있는 패턴으로 CRD를 통해서 어플리케이션들을 관리할 수 있다. OTel에서는 Operator을 통해서 Config 배포를 수행할 수 있다.
사람들이 기억하기 위해 어딘가 기록하듯, 프로그램도 장기기억을 위해선 메모리 대신 디스크에 기록할 필요가 있다. (정확히는 프로그램이 의도치않게 종료되었을 때 메모리 데이터는 날아가버리기 때문에 디스크에 저장할 필요가 있다.) Collector에서 자체적으로 제공하진 않지만 helper exporter
라는 확장 프로그램 개념으로 제공하고 있다. opentelemetry-collector/exporter/exporterhelper at main · open-telemetry/opentelemetry-collector · GitHub
OpenTelemetry에 대해 조사해보았다. 실제로 사용해보며 좀 더 자세하게 익혀보고 싶다.