[Opentelemetry] 오픈텔레메트리 소개와 역할

오픈소스

[Opentelemetry] 오픈텔레메트리 소개와 역할

안녕유지 2024. 5. 27. 00:15

Observability란

Observability

관측성, 관찰 가능성

시스템이나 소프트웨어 어플리케이션 내부 상태와 작동을 실시간으로 이해하고 모니터링 할 수 있는 능력을 나타냅니다.

Telemetry data

- logs : 시간 기반 텍스트, 어플리케이션 내에서 발생하는 이벤트와 상태 변경을 기록합니다.

- metrics : 런타임 환경에서 측정된 값, 특정 지표나 통계적인 데이터를 나타냅니다. 성능 및 상태를 측정하고 추적하는데 사용됩니다.

- traces: 어떤 요청이 처리 될 때 경로, 어플리케이션의 특정 트랜잭션 또는 작업에 대한 상세한 시간 경과 정보를 제공합니다.

Opentelemetry란

Observability 도와주는 일종의 Framework

(Observability back-end는 아닙니다)

Opentelemetry 역할과 아키텍처

Otel Collector

여러 collector를 단일 runtime 형식으로 통합한데 의의가 있습니다.

Receiver

- 원격 측정 데이터를 수신합니다. 스크레이퍼 처럼 데이터를 얻을 수 도 있습니다.

- Receiver를 통해 얻어진 측정값은 각각 다른 프로세서 (파이프라인)로 전달 될 수 있습니다.

- ex) Jaeger, Prometheus, OTLP, Zipkin

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: localhost:4317

service:
  pipelines:
    traces: # a pipeline of “traces” type
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]
    traces/2: # another pipeline of “traces” type
      receivers: [otlp]
      processors: [transform]
      exporters: [otlp]

Processor

- pipe와 filter pattern

- 프로세서는 데이터를 전달하기 전에 범위에서 속성을 추가하거나 제거하는 등 데이터를 변환할 수 있습니다. 데이터를 전달하지 않기로 결정하여 데이터를 삭제하거나 새로운 데이터를 생성할 수 도 있습니다.

- ex) Sampling, Change attributes, Batching

processors:
  batch:
    send_batch_size: 10000
    timeout: 10s

service:
  pipelines:
    traces: # a pipeline of “traces” type
      receivers: [zipkin]
      processors: [batch]
      exporters: [otlp]
    traces/2: # another pipeline of “traces” type
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Exporter

- 일반적으로 얻은 데이터를 네트워크 대상으로 전달하거나, 데이터를 필요한 백엔드 서비스로 보낼 수 있습니다.

- 동일한 파이프라인에서 동일한 유형의 여러 내보내기를 허용합니다.

- Jaeger, Zipkin, Prometheus, 기타 벤더 등

exporters:
  otlp/1:
    endpoint: example.com:4317
  otlp/2:
    endpoint: localhost:14317
    
service:
  pipelines:
    traces: # a pipeline of “traces” type
      receivers: [zipkin]
      processors: [memory_limiter]
      exporters: [otlp]
    traces/2: # another pipeline of “traces” type
      receivers: [otlp]
      processors: [transform]
      exporters: [otlp]

만약 기본적으로 제공되는 Receiver나 Exporter에 없다면 다음과 같이 커스텀으로 제공되는 항목에 대해 사용도 가능하다

https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver

opentelemetry-collector-contrib/receiver at main · open-telemetry/opentelemetry-collector-contrib

Contrib repository for the OpenTelemetry Collector - open-telemetry/opentelemetry-collector-contrib

github.com

Collector 배포 방법

https://github.com/jpkrohling/opentelemetry-collector-deployment-patterns

GitHub - jpkrohling/opentelemetry-collector-deployment-patterns: Repository of OpenTelemetry Collector deployment patterns

Repository of OpenTelemetry Collector deployment patterns - jpkrohling/opentelemetry-collector-deployment-patterns

github.com

1) 사이드카 배포

어플리케이션 컨테이너와 동일한 파드에 컬렉터를 배포합니다.

2) 에이전트로 실행

어플리케이션 파드와 동일한 노드의 컨테이너로 컬렉터를 실행합니다. 데몬셋 배포를 나타내며, 컬렉터 컨테이너가 쿠버네티스 클러스터의 모든 노드에 배포됩니다.

에이전트 방식은 애플리케이션의 코드에 직접 라이브러리를 포함시켜 추적 데이터를 수집하는 방법입니다.

동작 방식: 애플리케이션 내부에 OpenTelemetry SDK를 사용하여 코드를 작성하고, 이 SDK가 애플리케이션의 성능 데이터를 수집합니다.
장점:
- 애플리케이션과 밀접하게 연동되어 세밀한 데이터를 수집할 수 있습니다.
- 코드 레벨에서 커스터마이징이 용이합니다.
단점:
- 애플리케이션 코드에 변경이 필요합니다.
- 각 애플리케이션에 에이전트를 설치하고 관리해야 하므로 배포 및 관리가 복잡해질 수 있습니다.

3) 게이트웨이로 실행

컬렉터 서비스의 컨테이너가 쿠버네티스 노드에서 실행되며 어플리케이션 파드가 실행 중인 노드와 동일한 노드일 수도 있고 그렇지 않을 수도 있습니다.

게이트웨이 방식은 애플리케이션 외부에서 데이터를 수집하는 방법으로, 네트워크 트래픽을 감시하여 데이터를 수집합니다.

동작 방식: 애플리케이션이 외부의 게이트웨이 서버로 데이터를 전송하면, 게이트웨이 서버가 이 데이터를 수집하고 가공합니다.
장점:
- 애플리케이션 코드에 대한 수정이 필요 없습니다.
- 중앙 집중형 관리가 가능하여 배포 및 운영이 용이합니다.
단점:
- 세밀한 애플리케이션 내부 상태를 수집하는 데 한계가 있을 수 있습니다.
- 추가 네트워크 오버헤드가 발생할 수 있습니다.

멀티 클라우드 환경에서는 AWS ECS와 Kubernetes를 동시에 사용하는 상황을 고려해야 합니다. 각 환경의 특성에 따라 최적의 방법을 선택하는 것이 중요합니다.

에이전트 방식

Kubernetes: 각 Pod에 에이전트를 배포하여 세밀한 데이터를 수집할 수 있습니다. Kubernetes의 사이드카 패턴을 활용하면 각 애플리케이션과 함께 에이전트를 배포할 수 있어 일관된 모니터링 설정을 유지할 수 있습니다.
AWS ECS: 각 Task 정의에 에이전트를 포함시켜 데이터를 수집할 수 있습니다. 하지만 각 Task마다 에이전트를 설정해야 하므로 관리가 복잡해질 수 있습니다.

게이트웨이 방식

Kubernetes: DaemonSet을 사용하여 각 노드에 게이트웨이를 배포할 수 있습니다. 이렇게 하면 각 노드에서 데이터를 중앙에서 수집하고 관리할 수 있습니다.
AWS ECS: Service나 Task 정의에 게이트웨이를 추가하여 데이터를 수집할 수 있습니다. 중앙 집중식 게이트웨이를 설정하면 관리가 용이해집니다.

'오픈소스' 카테고리의 다른 글

[Kyverno] Kyverno 이해하기 (0)	2025.03.12
[Karmada] 오픈 소스 기여하기 2주차 (0)	2024.05.21
[Karmada] 오픈 소스 기여하기 1주차 (0)	2024.05.21

현재글[Opentelemetry] 오픈텔레메트리 소개와 역할

hellouz's Devlog