OTel Collector 이관 가이드, Helm 기반에서 OpenTelemetry Operator로

안녕하세요. J4J입니다.

 

이번 포스팅은 helm 기반 otel collector에서 open telemetry operator 기반 otel collector 이관하는 방법에 대해 적어보는 시간을 가져보려고 합니다.

 

 

 

관련 글

 

OpenTelemetry 구축 가이드: OTel Collector를 이용하여 메트릭, 로그, 트레이스를 하나로

OpenTelemetry 구축 가이드: OTel Collector를 이용하여 메트릭, 로그, 트레이스를 하나로

 

 

OpenTelemetry Operator로 Java Agent 자동 주입하기: 코드 수정 없는 Trace 수집

OpenTelemetry Operator로 Java Agent 자동 주입하기: 코드 수정 없는 Trace 수집

 

 

반응형

 

 

OpenTelemetry Operator로 변경하는 이유

 

open telemetry operator는 kubernetes 환경에서 collector와 자동 계측을 포함한 open telemetry 구성 요소들을 자동으로 배포 및 관리해 주는 컨트롤러 역할을 수행합니다.

 

그래서 단순히 helm이나 별도로 open telemetry에서 사용되는 리소스를 구성하는 방식보다 CRD를 기반으로 한 operator를 활용한다면 더 편리하고 관리하기 쉽게 계측 환경을 구성해볼 수 있습니다.

 

 

 

특히, 저와 같이 auto instrumentation 설정을 기반으로 한 agent 주입을 원하는 경우 helm을 통해서는 제공이 불가능하기에 필수적으로 operator 환경이 구성되어 있게 됩니다.

 

operator 환경이 구축되어 있다면 open telemetry에 사용될 수 있는 다른 리소스들을 구성할 때 helm chart를 가져오거나 별도의 values 들을 관리하는 행위 없이 CRD만을 이용하는 것이 합리적인 방법입니다.

 

그렇기 때문에 open telemetry의 리소스 중 하나인 otel collector의 경우도 다른 리소스들과 동일하게 operator를 이용한 서비스 구성으로 변경하는 것을 고려하게 됩니다.

 

 

 

또한 operator를 이용하여 구성하게 된다면 단절 없이 재 배포를 하는 것도 용이합니다.

 

물론 helm을 이용하는 경우에도 단 기간에 재 배포를 할 수 있는 상황을 제공하고 단절이 없어 보일 수 있지만 pod가 재 생성되면서 잠시 동안의 단절은 발생할 수 있게 됩니다.

 

하지만 operator를 사용하게 된다면 내부적으로 구성되어 있는 방식을 활용하여 HMR 및 롤링 배포를 통해 단절 없이 배포가 이루어집니다.

 

이 외에도 sidecar 및 daemonset collector 자동 관리 등 관리자의 입장에서 운영 난이도를 줄여주고 간편하게 적용을 할 수 있는 다양한 기능들을 많이 제공해주고 있기에 operator를 이용한 환경 구성은 선택이 아니라 필수라고 생각을 하게 되었습니다.

 

 

 

 

Operator 기반 Collector 구성 이관

 

이전 글에서 helm 기반으로 otel collector를 구성하기 위해 사용했던 values 정보는 다음과 같습니다.

 

// otel-collector-values.yaml
# collector 모드 설정 (deployment, daemonset, statefulset), 중앙 집중형의 형태로 collector 사용
mode: deployment

presets:
  kubernetesAttributes:
    # 수집된 span에 kubernetes 메타데이터 자동 라벨 적용 (pod, namespace, node 정보 등)
    enabled: true

config:
  # 데이터를 내보내는 exporter 서비스 설정
  exporters:
    # otlp 기반 exporter (jeager 설정)
    otlp:
      endpoint: jaeger-collector.observability.svc:4317 # gRPC 기반 데이터 전송
      tls:
        insecure: true # tls 인증 생략
    # collector 디버깅용 정보 출력
    # 실제 운영할 땐 debug: { }로 설정 권장
    debug:
      verbosity: detailed
      
  # receiver 로 부터 전달 받은 데이터를 가공하는 단계
  processors:
    # 여러 데이터를 한 번에 묶어서 전송하기 위한 batch 설정
    batch:
      # batch 크기
      send_batch_size: 1024
      # batch 전송 주기
      timeout: 5s

    # exporter를 통해 데이터가 내보내지기 전 trace sampling 처리
    # 사전 sampling 처리만 필요한 경우 설정할 필요 없음
    tail_sampling:
      # 첫 span을 확인한 뒤 sampling 판단을 내리기 위해 기다리는 시간
      decision_wait: 10s
      # 메모리에 동시에 관리되는 trace 수
      num_traces: 10000
      # 추정되는 TPS 설정
      expected_new_traces_per_sec: 100
      policies:
        # 에러 발생한 trace는 항상 sampling
        - name: error-traces
          type: status_code
          status_code:
            status_codes: [ERROR]
        # 설정 외 모든 trace는 5%만 sampling
        - name: normal-traces
          type: probabilistic
          probabilistic:
            sampling_percentage: 5
            
    # 동일 trace를 모으기 위한 설정
    groupbytrace:
      # 동일 trace가 모두 모일때까지 최대 기다리는 시간
      wait_duration: 10s
      # 메모리에 동시에 관리되는 trace 수
      num_traces: 10000
      
    # 메모리 제한 설정
    memory_limiter:
      # 메모리 제한 확인 주기
      check_interval: 5s
      # resource limit 메모리의 80%까지 사용 제한
      limit_percentage: 80
      # 갑자기 요청이 몰려 순간적으로 메모리 사용량이 치솟아도 추가로 최대 resource limit의 25%까지 허용
      # limit_percentage + spike_limit_percentage 만큼 메모리가 사용될 수도 있음
      spike_limit_percentage: 25

  # collector에 수신될 수 있는 정보 설정
  receivers:
    # otlp 설정
    otlp:
      protocols:
        # 네트워크 전역에 gRPC로 수신 가능하도록 설정
        grpc:
          endpoint: 0.0.0.0:4317
        # 네트워크 전역에 http로 수신 가능하도록 설정
        http:
          endpoint: 0.0.0.0:4318
    # jaeger, prometheus, zipkin 등 추가 설정 가능

  service:
    # Receivers → Processors → Exporters 처리 파이프라인 정의, 정의된 순서대로 동작을 수행
    pipelines:
      logs:
        # debug 를 원하는 경우 주석 해제
        # exporters:
          # - debug
        processors:
          - memory_limiter
          - batch
        receivers:
          - otlp
      metrics:
        # debug 를 원하는 경우 주석 해제
        # exporters:
          # - debug
        processors:
          - memory_limiter
          - batch
        receivers:
          - otlp
      traces:
        exporters:
          - otlp
          - debug
        processors:
          - memory_limiter
          - groupbytrace
          - tail_sampling
          - batch
        receivers:
          - otlp
          
image:
  # contrib 이미지 사용, processor에 tail_sampling, groupbytrace 등 활용 하기 위함
  # 가장 최소한의 설정만 담긴 collector, 클러스터 환경을 위한 collector-k8s 등 다양하게 존재
  repository: otel/opentelemetry-collector-contrib
          
resources:
  # resource limit 설정 (otel-collector가 사용할 수 있는 최대 리소스 설정)
  limits:
    cpu: 250m
    memory: 512Mi

 

 

 

해당 구성과 동일하게 collector가 사용될 수 있도록 다음과 같이 적용 해볼 수 있습니다.

 

이전 글을 보시지 않은 분들을 위하여 open telemetry operator를 설치하는 과정부터 작성할 예정이니, 이미 operator 설치가 되어 있다면 operator 설치 과정은 넘어가주셔도 됩니다.

 

 

 

 

[ 1. cert manager 설치 ]

 

open telemetry operator에서 open telemetry 서비스 간 안전한 통신을 위해 cert manager를 필수적으로 설치해줘야 합니다.

 

다만, 기존에 구성되어 있는 cert manager가 있는 경우에는 보통 추가적인 설치를 별도로 수행하지 않아도 됩니다.

 

cert manager의 최신 release 버전은 CertManager Release에서 확인할 수 있습니다.

 

$ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.1/cert-manager.yaml

 

 

 

[ 2. open telemetry operator 설치 ]

 

open telemetry operator의 최신 release 버전은 OpenTelemetryOperator Release에서 확인할 수 있습니다.

 

$ kubectl create namespace opentelemetry-operator-system
$ kubectl create -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml -n opentelemetry-operator-system

 

 

 

[ 3. collector 구성 ]

 

apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: otel-collector
  namespace: observability
spec:
  # collector 모드 설정 (deployment, daemonset, statefulset), 중앙 집중형의 형태로 collector 사용
  mode: deployment
  
  config:
    # collector에 수신될 수 있는 정보 설정
    receivers:
      # otlp 설정
      otlp:
        protocols:
          # 네트워크 전역에 gRPC로 수신 가능하도록 설정
          grpc:
            endpoint: 0.0.0.0:4317
          # 네트워크 전역에 http로 수신 가능하도록 설정
          http:
            endpoint: 0.0.0.0:4318
            
    # receiver 로 부터 전달 받은 데이터를 가공하는 단계
    processors:
      # 메모리 제한 설정
      memory_limiter:
        # 메모리 제한 확인 주기
        check_interval: 5s
        # resource limit 메모리의 80%까지 사용 제한
        limit_percentage: 80
        # 갑자기 요청이 몰려 순간적으로 메모리 사용량이 치솟아도 추가로 최대 resource limit의 25%까지 허용
        # limit_percentage + spike_limit_percentage 만큼 메모리가 사용될 수도 있음
        spike_limit_percentage: 25
        
      # 동일 trace를 모으기 위한 설정
      groupbytrace:
        # 동일 trace가 모두 모일때까지 최대 기다리는 시간
        wait_duration: 10s
        # 메모리에 동시에 관리되는 trace 수
        num_traces: 10000
        
      # exporter를 통해 데이터가 내보내지기 전 trace sampling 처리
      # 사전 sampling 처리만 필요한 경우 설정할 필요 없음
      tail_sampling:
        # 첫 span을 확인한 뒤 sampling 판단을 내리기 위해 기다리는 시간
        decision_wait: 10s
        # 메모리에 동시에 관리되는 trace 수
        num_traces: 10000
        # 추정되는 TPS 설정
        expected_new_traces_per_sec: 100
        policies:
          # 에러 발생한 trace는 항상 sampling
          - name: error-traces
            type: status_code
            status_code:
              status_codes: [ERROR]
          # 설정 외 모든 trace는 5%만 sampling
          - name: normal-traces
            type: probabilistic
            probabilistic:
              sampling_percentage: 5

      # 여러 데이터를 한 번에 묶어서 전송하기 위한 batch 설정
      batch:
        # batch 크기
        send_batch_size: 1024
        # batch 전송 주기
        timeout: 5s
            
    # 데이터를 내보내는 exporter 서비스 설정
    exporters:
      # otlp 기반 exporter (jeager 설정)
      otlp:
        endpoint: jaeger-collector.observability.svc:4317 # gRPC 기반 데이터 전송
        tls:
          insecure: true # tls 인증 생략
      # collector 디버깅용 정보 출력
      # 실제 운영할 땐 debug: { }로 설정 권장
      debug:
        verbosity: detailed

    service:
      # Receivers → Processors → Exporters 처리 파이프라인 정의, 정의된 순서대로 동작을 수행
      pipelines:
        logs:
          exporters:
            - debug
          processors:
            - memory_limiter
            - batch
          receivers:
            - otlp
        metrics:
          exporters:
            - debug
          processors:
            - memory_limiter
            - batch
          receivers:
            - otlp
        traces:
          exporters:
            - otlp
            - debug
          processors:
            - memory_limiter
            - groupbytrace
            - tail_sampling
            - batch
          receivers:
            - otlp

  # contrib 이미지 사용, processor에 tail_sampling, groupbytrace 등 활용 하기 위함
  # 가장 최소한의 설정만 담긴 collector, 클러스터 환경을 위한 collector-k8s 등 다양하게 존재            
  image: otel/opentelemetry-collector-contrib
    
  resources:
    # resource limit 설정 (otel-collector가 사용할 수 있는 최대 리소스 설정)
    limits:
      cpu: 250m
      memory: 512Mi

 

 

 

[ 4. collector 설치 ]

 

$ kubectl apply -f collector.yaml

 

 

 

[ 5. 설치 확인 ]

 

설치가 올바르게 되었다면 동작되고 있는 pod 정보를 확인해 줍니다.

 

$ kubectl get pods -n observability

 

 

여기서 중요한 사항 중 하나는 새롭게 설치한 경우라면 문제가 없지만, 기존에 사용되고 있던 것이 있는 상황에서 이관 구성을 하게 된 경우라면 svc 값도 확인해 봐야 합니다.

 

저의 경우 helm 기반으로 설치 했을설치했을 때는 `otel-colletor-opentelemetry-collector`와 같은 svc가 구성되었지만, operator를 이용하여 설치했을 때는 `otel-collector-collector`와 같이 svc가 구성되어 있습니다.

 

만약 svc의 이름이 서로 다른 상황이 되었다면 agent exporter / istio / spring otlp exporter 등 collector로 telemetry 정보를 수집하기 위해 exporter 설정을 적용한 곳에서 collector 설정 값들을 모두 변경해주셔야 합니다.

 

변경이 완료되어서 수집이 올바르게 수행된다면 helm 기반으로 구성했던 것과 동일한 결과를 확인할 수 있습니다.

 

 

 

 

 

 

이상으로 helm 기반 otel collector에서 open telemetry operator 기반 otel collector 이관하는 방법에 대해 간단하게 알아보는 시간이었습니다.

 

읽어주셔서 감사합니다.