5.2. 분산 추적 데이터 수집 구성 및 배포

Red Hat OpenShift distributed tracing data collection Operator는 분산 추적 데이터 수집 리소스를 생성하고 배포할 때 사용할 아키텍처 및 구성 설정을 정의하는 CRD(사용자 정의 리소스 정의) 파일을 사용합니다. 기본 구성을 설치하거나 파일을 수정할 수 있습니다.

5.2.1. OpenTelemetry 수집기 구성 옵션

OpenTelemetry Collector는 Telemetry 데이터에 액세스하는 세 가지 구성 요소로 구성됩니다.

수신자: 내보내기 또는 풀 기반이 될 수 있는 수신자는 데이터가 수집기로 들어오는 방법입니다. 일반적으로 수신자는 지정된 형식으로 데이터를 수락하고 내부 형식으로 변환한 다음 해당 파이프라인에 정의된 프로세서 및 내보내기에 전달합니다. 기본적으로 수신자는 구성되지 않습니다. 하나 이상의 수신자를 구성해야 합니다. 수신자는 하나 이상의 데이터 소스를 지원할 수 있습니다.
프로세서: 선택 사항: 프로세서가 수신되고 내보낼 때까지 데이터를 통해 실행됩니다. 기본적으로 프로세서는 사용할 수 없습니다. 모든 데이터 소스에 대해 프로세서를 활성화해야 합니다. 일부 프로세서는 모든 데이터 소스를 지원하는 것은 아닙니다. 데이터 소스에 따라 여러 프로세서가 활성화될 수 있습니다. 프로세서의 순서가 중요합니다.
내보내기: 푸시 또는 풀 기반이 될 수 있는 내보내기는 하나 이상의 백엔드 또는 대상에 데이터를 보내는 방법입니다. 기본적으로 내보내기는 구성되지 않습니다. 하나 이상의 내보내기를 구성해야 합니다. 내보내기는 하나 이상의 데이터 소스를 지원할 수 있습니다. 내보내기는 기본 설정과 함께 사용할 수 있지만 대상 및 보안 설정을 지정하려면 많은 내보내기 구성이 필요합니다.

사용자 정의 리소스 YAML 파일에서 구성 요소의 여러 인스턴스를 정의할 수 있습니다. 구성하는 경우 YAML 파일의 spec.config.service 섹션에 정의된 파이프라인을 통해 이러한 구성 요소를 활성화해야 합니다. 필요한 구성 요소만 활성화하는 것이 좋습니다.

OpenTelemetry Collector 사용자 정의 리소스 파일의 예

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: cluster-collector
  namespace: tracing-system
spec:
  mode: deployment
  ports:
  - name: promexporter
    port: 8889
    protocol: TCP
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
    exporters:
      jaeger:
        endpoint: jaeger-production-collector-headless.tracing-system.svc:14250
        tls:
          ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"
      prometheus:
        endpoint: 0.0.0.0:8889
        resource_to_telemetry_conversion:
          enabled: true # by default resource attributes are dropped
    service: 1
      pipelines:
        traces:
          receivers: [otlp]
          processors: []
          exporters: [jaeger]
        metrics:
          receivers: [otlp]
          processors: []
          exporters: [prometheus]

1: 구성 요소가 구성되었지만 service 섹션에 정의되지 않은 경우 구성 요소가 활성화되지 않습니다.

표 5.1. Operator에서 OpenTelemetry 수집기를 정의하는 데 사용하는 매개변수
매개변수	설명	값	기본값
receivers:	수신자는 데이터가 수집기로 들어오는 방법입니다. 기본적으로 수신자는 구성되지 않습니다. 구성을 유효한 것으로 간주하려면 하나 이상의 활성화된 수신자가 있어야 합니다. 수신자는 파이프라인에 추가하여 활성화됩니다.	`otlp`,`jaeger`,`zipkin`	없음
processors:	프로세서가 수신되고 내보낼 때까지 데이터를 통해 실행됩니다. 기본적으로 프로세서는 사용할 수 없습니다.		없음
exporters:	내보내기는 하나 이상의 백엔드 또는 대상에 데이터를 보냅니다. 기본적으로 내보내기는 구성되지 않습니다. 구성을 유효한 것으로 간주하려면 하나 이상의 내보내기가 활성화되어 있어야 합니다. 내보내기를 파이프라인에 추가하여 사용할 수 있습니다. 내보내기는 기본 설정과 함께 사용할 수 있지만 대상 및 보안 설정을 지정하려면 많은 구성이 필요합니다.	`otlp`,`otlphttp`,`jaeger`,`logging`,`prometheus`	없음
service: pipelines:	구성 요소는 `services.pipeline` 아래의 파이프라인에 추가하여 활성화됩니다.
service: pipelines: traces: receivers:	`service.pipelines.traces` 에 추가하여 추적에 대한 수신자를 활성화합니다.		없음
service: pipelines: traces: processors:	`service.pipelines.traces` 에서 추적을 위해 프로세서를 활성화합니다.		없음
service: pipelines: traces: exporters:	`service.pipelines.traces` 에서 추적에 대해 내보내기를 활성화합니다.		없음
service: pipelines: metrics: receivers:	`service.pipelines.metrics` 에 추가하여 메트릭의 수신자를 활성화합니다.		없음
service: pipelines: metrics: processors:	`service.pipelines.metrics` 에 추가하여 metircs의 프로세서를 활성화합니다.		없음
service: pipelines: metrics: exporters:	`service.pipelines.metrics` 에서 메트릭에 내보내기를 활성화합니다.		없음

5.2.1.1. OpenTelemetry 수집기 구성 요소

5.2.1.1.1. 수신자

5.2.1.1.1.1. OTLP 수신기

OTLP 수신기는 OTLP(OpenTelemetry Protocol)를 사용하여 데이터를 수집합니다.

지원 수준: 기술 프리뷰
지원되는 신호: 추적, 메트릭

활성화된 OTLP 수신자가 있는 OpenTelemetry 수집기 사용자 정의 리소스

  config: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317 1
            tls: 2
              ca_file: ca.pem
              cert_file: cert.pem
              key_file: key.pem
              client_ca_file: client.pem 3
              reload_interval: 1h 4
          http:
            endpoint: 0.0.0.0:4318 5
            tls: 6

    service:
      pipelines:
        traces:
          receivers: [otlp]
        metrics:
          receivers: [otlp]

1: OTLP gRPC 끝점입니다. 생략하면 기본값 0.0.0.0:4317 이 사용됩니다.
2: 서버 측 TLS 구성입니다. TLS 인증서의 경로를 정의합니다. 생략하면 TLS가 비활성화됩니다.
3: 서버가 클라이언트 인증서를 확인하는 TLS 인증서의 경로입니다. 이렇게 하면 TLSConfig 에서 ClientCA 및 ClientAuth 의 값이 RequireAndVerifyClientCert 로 설정됩니다. 자세한 내용은 Golang TLS 패키지 구성을 참조하십시오.
4: 인증서를 다시 로드하는 시간 간격을 지정합니다. 값을 설정하지 않으면 인증서가 다시 로드되지 않습니다. RELOAD_ INTERVAL은 ns,us (또는 Cryostats ), ms,s,m,h 와 같은 유효한 시간 단위를 포함하는 문자열을 허용합니다.
5: OTLP HTTP 끝점입니다. 기본값은 0.0.0.0:4318 입니다.
6: 서버 측 TLS 구성입니다. 자세한 내용은 grpc 프로토콜 구성 섹션을 참조하십시오.

5.2.1.1.1.2. Jaeger 수신자

Jaeger 수신자는 Jaeger 형식으로 데이터를 수집합니다.

지원 수준: 기술 프리뷰
지원되는 신호: 추적

활성화된 Jaeger 수신자가 있는 OpenTelemetry 수집기 사용자 정의 리소스

  config: |
    receivers:
      jaeger:
        protocols:
          grpc:
            endpoint: 0.0.0.0:14250 1
          thrift_http:
            endpoint: 0.0.0.0:14268 2
          thrift_compact:
            endpoint: 0.0.0.0:6831 3
          thrift_binary:
            endpoint: 0.0.0.0:6832 4
          tls: 5

    service:
      pipelines:
        traces:
          receivers: [jaeger]

1: Jaeger gRPC 끝점입니다. 생략하면 기본값 0.0.0.0:14250 이 사용됩니다.
2: Jaeger Thrift HTTP 끝점입니다. 생략하면 기본값 0.0.0.0:14268 이 사용됩니다.
3: Jaeger Thrift Cryostat 끝점입니다. 생략하면 기본값 0.0.0.0:6831 이 사용됩니다.
4: Jaeger Thrift Binary 끝점입니다. 생략하면 기본값 0.0.0.0:6832 가 사용됩니다.
5: TLS 서버 측 구성입니다. 자세한 내용은 OTLP 수신기 구성 섹션을 참조하십시오.

5.2.1.1.1.3. Zipkin Receiver

Zipkin 수신기는 Zipkin v1 및 v2 형식으로 데이터를 수집합니다.

지원 수준: 기술 프리뷰
지원되는 신호: 추적

Zipkin receiver가 활성화된 OpenTelemetry 수집기 사용자 정의 리소스

  config: |
    receivers:
      zipkin:
        endpoint: 0.0.0.0:9411 1
        tls: 2

    service:
      pipelines:
        traces:
          receivers: [zipkin]

1: Zipkin HTTP 끝점입니다. 생략하면 기본값 0.0.0.0:9411 이 사용됩니다.
2: TLS 서버 측 구성입니다. 자세한 내용은 OTLP 수신기 구성 섹션을 참조하십시오.

5.2.1.1.2. 프로세서

5.2.1.1.2.1. 일괄 프로세서

배치 프로세서는 Telemetry 정보를 전송하는 데 필요한 발신 연결 수를 줄이기 위해 데이터를 배치합니다.

지원 수준: 기술 프리뷰
지원되는 신호: 추적, 메트릭

배치 프로세서를 사용할 때 OpenTelemetry 수집기 사용자 정의 리소스의 예

  config: |
    processor:
      batch:
        timeout: 5s
        send_batch_max_size: 10000
    service:
      pipelines:
        traces:
          processors: [batch]
        metrics:
          processors: [batch]

표 5.2. 배치 프로세서에서 사용하는 매개변수
매개변수	설명	기본값
`timeout`	크기와 관계없이 특정 기간 후에 일괄 처리를 보냅니다.	200ms
`send_batch_size`	지정된 수의 범위 또는 메트릭 후에 원격 분석 데이터의 배치를 보냅니다.	8192
`send_batch_max_size`	일괄 처리의 최대 허용 크기입니다. `send_batch_size` 보다 크거나 같아야 합니다.	0
`metadata_keys`	활성화하면 `client.Metadata` 에 있는 각 고유한 값 집합에 대해 일괄 처리 인스턴스가 생성됩니다.	[]
`metadata_cardinality_limit`	`metadata_keys` 가 채워지면 이 구성은 프로세스 기간 동안 처리된 고유한 메타데이터 키-값 조합의 수를 제한합니다.	1000

5.2.1.1.2.2. 메모리 제한 프로세서

메모리 제한 프로세서는 주기적으로 수집기의 메모리 사용량을 확인하고 소프트 메모리 제한에 도달할 때 데이터 처리를 일시 중지합니다. 일반적으로 수신자인 이전 구성 요소는 동일한 데이터 전송을 다시 시도해야 하며 들어오는 데이터에 백압을 적용할 수 있습니다. 메모리 사용량이 하드 제한을 초과하면 메모리 제한 프로세서가 가비지 수집을 강제 실행합니다.

지원 수준: 정식 출시일 (GA)
지원되는 신호: 추적, 메트릭, 로그

메모리 제한 프로세서를 사용할 때 OpenTelemetry 수집기 사용자 정의 리소스의 예

  config: |
    processor:
      memory_limiter:
        check_interval: 1s
        limit_mib: 4000
        spike_limit_mib: 800
    service:
      pipelines:
        traces:
          processors: [batch]
        metrics:
          processors: [batch]

표 5.3. 메모리 제한 프로세서에서 사용하는 매개변수
매개변수	설명	기본값
`check_interval`	메모리 사용량 측정 사이의 시간입니다. 최적의 값은 1s입니다. spiky 트래픽 패턴의 경우 `check_interval` 을 줄이거나 `spike_limit_mib` 를 늘릴 수 있습니다.	`0s`
`limit_mib`	힙에 할당된 MiB 단위의 최대 메모리 양인 하드 제한입니다. 일반적으로 OpenTelemetry 수집기의 총 메모리 사용량은 이 값보다 약 50MiB입니다.	`0`
`spike_limit_mib`	메모리 사용량의 최대 급증(MiB)입니다. 최적의 값은 `limit_mib` 의 약 20%입니다. 소프트 제한을 계산하려면 `limit_mib` 에서 `spike_limit_mib` 를 뺀 값입니다.	`limit_mib`의 20%
`limit_percentage`	`limit_mib` 와 동일하지만 사용 가능한 총 메모리의 백분율로 표시됩니다. `limit_mib` 설정이 이 설정보다 우선합니다.	`0`
`spike_limit_percentage`	`spike_limit_mib` 와 동일하지만 사용 가능한 총 메모리의 백분율로 표시됩니다. `limit_percentage` 설정과 함께 사용하도록 설계되었습니다.	`0`

5.2.1.1.2.3. 리소스 탐지 프로세서

리소스 탐지 프로세서는 OpenTelemetry의 리소스 의미 체계 표준과 일치하여 호스트 리소스 세부 정보를 식별하도록 설계되었습니다. 감지된 이 정보를 사용하여 원격 분석 데이터에서 리소스 값을 추가하거나 교체할 수 있습니다.

지원 수준: 기술 프리뷰
지원되는 신호: 추적, 메트릭

리소스 탐지 프로세서에 필요한 OpenShift Container Platform 권한

kind: ClusterRole
metadata:
  name: otel-collector
rules:
- apiGroups: ["config.openshift.io"]
  resources: ["infrastructures", "infrastructures/status"]
  verbs: ["get", "watch", "list"]

리소스 탐지 프로세서를 사용한 OpenTelemetry 수집기

  config: |
    processor:
      resourcedetection:
        detectors: [openshift]
        override: true
    service:
      pipelines:
        traces:
          processors: [resourcedetection]
        metrics:
          processors: [resourcedetection]

5.2.1.1.3. 내보내기

5.2.1.1.3.1. OTLP 내보내기

OTLP gRPC 내보내기는 OTLP(OpenTelemetry 프로토콜)를 사용하여 데이터를 내보냅니다.

지원 수준: 기술 프리뷰
지원되는 신호: 추적, 메트릭

활성화된 OTLP 내보내기가 활성화된 OpenTelemetry 수집기 사용자 정의 리소스

  config: |
    exporters:
      otlp:
        endpoint: tempo-ingester:4317 1
        tls: 2
          ca_file: ca.pem
          cert_file: cert.pem
          key_file: key.pem
          insecure: false 3
          insecure_skip_verify: false 4
          reload_interval: 1h 5
          server_name_override: <name> 6
        headers: 7
          X-Scope-OrgID: "dev"
    service:
      pipelines:
        traces:
          exporters: [otlp]
        metrics:
          exporters: [otlp]

1: OTLP gRPC 끝점입니다. https:// 스키마를 사용하는 경우 클라이언트 전송 보안이 활성화되고 tls 의 비보안 설정을 덮어씁니다.
2: 클라이언트 측 TLS 구성입니다. TLS 인증서의 경로를 정의합니다.
3: true 로 설정된 경우 클라이언트 전송 보안을 비활성화합니다. 기본값은 기본적으로 false 입니다.
4: true 로 설정된 경우 인증서 확인을 건너뜁니다. 기본값은 false입니다.
5: 인증서를 다시 로드하는 시간 간격을 지정합니다. 값을 설정하지 않으면 인증서가 다시 로드되지 않습니다. RELOAD_ INTERVAL은 ns,us (또는 Cryostats ), ms,s,m,h 와 같은 유효한 시간 단위를 포함하는 문자열을 허용합니다.
6: 요청의 권한 헤더 필드와 같은 권한의 가상 호스트 이름을 재정의합니다. 테스트에 이 값을 사용할 수 있습니다.
7: 설정된 연결 중에 수행되는 모든 요청에 대해 헤더가 전송됩니다.

5.2.1.1.3.2. OTLP HTTP 내보내기

OTLP HTTP 내보내기는 OTLP(OpenTelemetry 프로토콜)를 사용하여 데이터를 내보냅니다.

지원 수준: 기술 프리뷰
지원되는 신호: 추적, 메트릭

활성화된 OTLP 내보내기가 활성화된 OpenTelemetry 수집기 사용자 정의 리소스

  config: |
    exporters:
      otlphttp:
        endpoint: http://tempo-ingester:4318 1
        tls: 2
        headers: 3
          X-Scope-OrgID: "dev"

    service:
      pipelines:
        traces:
          exporters: [otlphttp]
        metrics:
          expoters: [otlphttp]

1: OTLP HTTP 끝점입니다. https:// 스키마를 사용하는 경우 클라이언트 전송 보안이 활성화되고 tls 의 비보안 설정을 덮어씁니다.
2: 클라이언트 측 TLS 구성입니다. TLS 인증서의 경로를 정의합니다.
3: 헤더는 모든 HTTP 요청에 전송됩니다.

5.2.1.1.3.3. Jaeger 내보내기

Jaeger 내보내기는 gRPC를 통해 Jaeger 프로토 형식을 사용하여 데이터를 내보냅니다.

지원 수준: 기술 프리뷰
지원되는 신호: 추적

활성화된 Jaeger 내보내기가 활성화된 OpenTelemetry 수집기 사용자 정의 리소스

  config: |
    exporters:
      jaeger:
        endpoint: jaeger-all-in-one:14250 1
        tls: 2
    service:
      pipelines:
        traces:
          exporters: [jaeger]

1: Jaeger gRPC 끝점입니다.
2: 클라이언트 측 TLS 구성입니다. TLS 인증서의 경로를 정의합니다.

5.2.1.1.3.4. 로깅 내보내기

로깅 내보내기는 데이터를 표준 출력에 출력합니다.

지원 수준: 기술 프리뷰
지원되는 신호: 추적, 메트릭

활성화된 로깅 내보내기가 있는 OpenTelemetry 수집기 사용자 정의 리소스

  config: |
    exporters:
      logging:
        verbosity: detailed 1
    service:
      pipelines:
        traces:
          exporters: [logging]
        metrics:
          exporters: [logging]

1: 로깅 내보내기 세부 정보 표시: 세부 정보 또는 일반 또는 기본. 세부 정보로 설정하면 파이프라인 데이터가 세부적으로 기록됩니다. 기본값은 Normal입니다.

5.2.1.1.3.5. Prometheus 내보내기

Prometheus 내보내기는 Prometheus 또는 OpenMetrics 형식을 사용하여 데이터를 내보냅니다.

지원 수준: 기술 프리뷰
지원되는 신호: 메트릭

활성화된 Prometheus 내보내기가 포함된 OpenTelemetry 수집기 사용자 정의 리소스

  ports:
  - name: promexporter 1
    port: 8889
    protocol: TCP
  config: |
    exporters:
      prometheus:
        endpoint: 0.0.0.0:8889 2
        tls: 3
          ca_file: ca.pem
          cert_file: cert.pem
          key_file: key.pem
        namespace: prefix 4
        const_labels: 5
          label1: value1
        enable_open_metrics: true 6
        resource_to_telemetry_conversion: 7
          enabled: true
        metric_expiration: 180m 8
    service:
      pipelines:
        metrics:
          exporters: [prometheus]

1: 수집기 Pod 및 서비스에서 Prometheus 포트를 노출합니다. ServiceMonitor 또는 PodMonitor 사용자 정의 리소스의 포트 이름을 사용하여 Prometheus에서 메트릭 스크랩을 활성화할 수 있습니다.
2: 지표가 노출되는 네트워크 끝점입니다.
3: 서버 측 TLS 구성입니다. TLS 인증서의 경로를 정의합니다.
4: 설정된 경우 제공된 값 아래에 지표를 내보냅니다. 기본값이 없습니다.
5: 내보낸 모든 메트릭에 적용되는 키-값 쌍 레이블입니다. 기본값이 없습니다.
6: true 인 경우 OpenMetrics 형식을 사용하여 메트릭을 내보냅니다. exemp declarations는 OpenMetrics 형식으로만 내보내지며 히스토그램 및 단조적 합계 메트릭 (예: counter )에만 사용할 수 있습니다. 기본적으로 비활성되어 있습니다.
7: enabled 가 true 이면 모든 리소스 속성이 기본적으로 지표 레이블로 변환됩니다. 기본적으로 비활성되어 있습니다.
8: 업데이트 없이 메트릭이 노출되는 기간을 정의합니다. 기본값은 5m 입니다.

5.2.2. 모니터링 스택에 메트릭 전송

OpenTelemetry 수집기 지표 끝점을 스크랩하고 스크랩 중에 모니터링 스택이 추가한 중복 레이블을 제거하도록 모니터링 스택을 구성할 수 있습니다.

수집기 메트릭을 스크랩하도록 모니터링 스택을 구성하는 샘플 PodMonitor CR(사용자 정의 리소스)

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: otel-collector
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: otel-collector
  podMetricsEndpoints:
  - port: metrics 1
  - port: promexporter 2
    relabelings:
    - action: labeldrop
      regex: pod
    - action: labeldrop
      regex: container
    - action: labeldrop
      regex: endpoint
    metricRelabelings:
    - action: labeldrop
      regex: instance
    - action: labeldrop
      regex: job

1: OpenTelemetry 수집기의 내부 메트릭 포트의 이름입니다. 이 포트 이름은 항상 메트릭 입니다.
2: OpenTelemetry 수집기의 Prometheus 내보내기 포트의 이름입니다. 이 포트 이름은 OpenTelemetryCollector CR의 .spec.ports 섹션에 정의됩니다.

5.2.3. 추가 리소스

사용자 정의 프로젝트 모니터링 활성화