[모니터링] OpenTelemetry 살펴보기

이전 글에서 효과적인 모니터링을 위해 로그와 매트릭을 동시에 수집해야 한다고 했다.

 

이를 위해 Log 수집에 특화된 Flunent Bit, FileBeat 등이나,

Metric 수집에 특화된 Telegraf, Prometheus Exporter 등을 함께 사용해볼까 했다.

 

하지만 이렇게 되면,

초반 세팅과 유지보수가 힘들고 비교적 벤더에 의존적이라고 판단했다.

 

그렇게 해서 선택한 것이 과거에 가볍게 써본적 있는 Opentelemetry Collector이다.

 

🙋🏻Opentelemetry 란?

OpenTelemetry는 메트릭, 추적, 로그를 포함한 모든 원격 측정 데이터를 수집하고 표준화하며,

이를 다양한 백엔드로 내보낼 수 있는 포괄적인 관찰 프레임워크이다.

 

주요 특징은 크게 다음과 같다.

 

- 원격 측정 데이터 Log, Metric, Trace 제공

 

- 높은 호환성

 

- Trace 데이터 제공

 

Opentelemetry Collector는 Opentelemetry의 핵심 요소로,

각종 데이터 소스로부터 수집한 데이터를 처리하고 다양한 벤더로 내보내는 역할을 한다.

 

 

Opentelemetry Collector는 다음과 같은 강점을 가진다.

 

1. 통합된 원격 측정 데이터 관리
   • 로그, 메트릭, 추적 데이터를 한곳에서 관리하며 디버깅 효율성을 향상.
   • 다양한 원격 측정 유형을 단일 에이전트로 처리해 파이프라인을 간소화.
   • OpenTelemetry Collector를 활용해 여러 소스의 데이터를 통합적으로 수집.
2. 높은 벤더 호환성
   • 특정 백엔드 도구에 종속되지 않으며 다양한 모니터링 및 분석 도구와 연동 가능.
   • 백엔드 전환 시 코드 변경 없이 구성만 수정하여 설정 가능.
3. 보안 강화
   • 민감한 데이터(예: API 키, 신용카드 번호 등)의 노출을 방지.
   • 데이터를 내보내기 전 필터링과 정제를 수행하여 보안 및 규정 준수를 강화.
4. 마이크로서비스 및 Kubernetes 환경에 최적화된 데이터 처리
   • 마이크로서비스 아키텍처와 Kubernetes 환경에서 발생하는 다양한 형태의 원격 데이터를 처리할 수 있도록 설계
   • 서비스 간 복잡한 상호작용을 효과적으로 추적하고, 데이터 손실 없이 수집·전송·변환 가능
5. Observability 까지 확대 가능 

1. • Trace 데이터를 제공하기 때문에 Observabiltiy 범위까지 확대 가능.

 

선택 이유 중 많은 비중을 차지한 것이 "다양한 데이터 소스와 벤더 호환성"이다.

 

OTel Collector를 살펴보면 매트릭, 트레이스에 특화된 Prometheus, Jaeger을 통한 수집을 지원할 뿐 아니라,

자체 프로토콜인 OTel Protocol을 이용해서 다양한 소스로부터 일관적인 인터페이스를 통해 데이터를 수집할 수 있다.

 

특히 언어 상관없이 OpenTelemetry API를 통해 수집 인터페이스를 지정하고,

실제 API의 구현체인 OpenTelemtry SDK를 이용해서 데이터 처리, 내보내기를 지원한다.

 

이를 통해, 지원하는 모든 언어로 작성된 어플리케이션들의 원격 데이터를 통일된 인터페이스로 수집할 수 있게 된다.

 

마찬가지로 처리한 데이터를 내보낼 벤더에 대한 호환성도 좋아서ELK-Stack, Prometheus, Jaeger 등 각종 수집 벤더로 익스포트가 가능하다는 장점을 가진다.