Jaeger

OpenShift Container Platform 4.6

Jaeger 설치, 사용법 및 릴리스 노트

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform에서 Jaeger를 사용하는 방법에 대한 정보를 제공합니다.

1장. Jaeger 릴리스 노트

1.1. Jaeger 개요

서비스 소유자로 Jaeger를 사용하여 서비스 아키텍처에 대한 정보를 수집할 수 있습니다. Jaeger는 최신 클라우드 네이티브, 마이크로서비스 기반 애플리케이션의 구성 요소 간 상호 작용을 모니터링, 네트워크 프로파일링 및 문제 해결에 사용할 수 있는 오픈 소스 분산 추적 플랫폼입니다.

Jaeger를 사용하면 다음 기능을 수행할 수 있습니다.

  • 분산 트랜잭션 모니터링
  • 성능 및 대기 시간 최적화
  • 근본 원인 분석 수행

Jaeger는 벤더 중립 OpenTracing API 및 계측을 기반으로 합니다.

1.2. 보다 포괄적인 오픈 소스 구현

Red Hat은 코드, 문서 및 웹 속성에서 문제를 야기할 수 있는 언어를 변경하기 위해 최선을 다하고 있습니다. 이는 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist)의 네 가지 용어의 변경 작업에서부터 시작합니다. 이러한 변경 작업은 향후 여러 릴리스에 대해 단계적으로 구현될 예정입니다. 자세한 내용은 Red Hat CTO Chris Wright의 메시지에서 참조하십시오.

1.3. 지원 요청

이 문서에 설명된 절차 또는 일반적으로 OpenShift Container Platform에 문제가 발생하는 경우 Red Hat 고객 포털에 액세스하십시오. 고객 포털에서 다음을 수행할 수 있습니다.

  • Red Hat 제품과 관련된 기사 및 솔루션에 대한 Red Hat 지식베이스를 검색하거나 살펴볼 수 있습니다.
  • Red Hat 지원에 대한 지원 케이스 제출할 수 있습니다.
  • 다른 제품 설명서에 액세스 가능합니다.

클러스터의 문제를 식별하기 위해 Red Hat OpenShift Cluster Manager에서 Insights를 사용할 수 있습니다. Insights는 문제에 대한 세부 정보 및 문제 해결 방법에 대한 정보를 제공합니다.

이 문서를 개선하기 위한 제안이 있거나 오류를 발견한 경우 문서 구성 요소의 OpenShift Container Platform 제품에 대한 Bugzilla 보고서를 제출하십시오. 섹션 이름 및 OpenShift Container Platform 버전과 같은 구체적인 정보를 제공합니다.

1.3.1. 새로운 기능 OpenShift Jaeger 1.20.0

  • 이번 OpenShift Jaeger 릴리스는 "외부" Elasticsearch 클러스터를 사용하여 추적 데이터(Elasticsearch Operator에서 설치하고 생성하지 않은 Elasticsearch 인스턴스)를 저장하도록 추가로 지원합니다.
  • 이 릴리스에서는 Jaeger Collector 및 Ingester에 대한 자동 스케일링 지원이 추가되었습니다.

1.3.2. 새로운 기능 OpenShift Jaeger 1.17.7

이번 OpenShift Jaeger 릴리스는 CVE(Common Vulnerabilities and Exposures) 및 버그 수정을 처리합니다.

1.4. 기술 프리뷰

중요

Technology Preview 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 고객은 출시 예정된 제품 기능을 Preview를 통해 미리 사용해 보면서 테스트하고 개발 과정에서 피드백을 제공할 수 있습니다. Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

1.4.1. OpenShift Jaeger 2.0.0 기술 프리뷰 1

Jaeger Operator를 설치할 때 Jaeger의 기술 프리뷰 버전을 선택할 수 있습니다. 이를 통해 OpenTelemetry 프레임워크를 기반으로 Jaeger로 데이터를 내보낼 수 있는 클라이언트 및 인프라에 액세스할 수 있습니다. 이 버전은 프로덕션 환경에서 지원되지 않습니다.

OpenTelemetry 수집기는 개발자가 벤더와 무관한 API를 사용하여 코드를 조정할 수 있으며 벤더 종속을 피하고 관찰 기능 툴링의 증가하는 에코시스템을 실현할 수 있는 길이 열립니다.

1.5. Jaeger 알려진 문제

Jaeger에 다음과 같은 제한 사항은 있습니다.

  • Apache Spark가 지원되지 않습니다.
  • AMQ/Kafka를 통한 Jaeger 스트리밍은 IBM Z 및 IBM Power Systems에서 지원되지 않습니다.

다음은 Jaeger에서 알려진 문제입니다.

  • BZ-1918920 Elasticsearch pod는 업데이트 후 자동으로 다시 시작되지 않습니다. 이 문제를 해결하려면 pod를 수동으로 다시 시작합니다.
  • TRACING-809 Jaeger Ingester는 Kafka 2.3과 호환되지 않습니다. Jaeger Ingester의 두 개 이상의 인스턴스와 트래픽이 충분한 경우 로그에 지속적으로 리밸런싱 메시지를 생성합니다. 이는 Kafka 2.3.1에서 수정된 Kafka 2.3의 문제의 재발로 인해 발생합니다. 자세한 내용은 Jaegertracing-1819를 참조하십시오.

1.6. Jaeger 해결된 문제

  • TRACING-1725 TRACING-1631에 대한 후속 조치입니다. 동일한 이름을 사용하지만 다른 네임스페이스 내에 Jaeger 프로덕션 인스턴스가 여러 개인 경우 Elasticsearch 인증서가 올바르게 조정되는지 확인하기 위한 추가 수정 사항입니다. BZ-1918920도 참조하십시오.
  • TRACING-1631 동일한 이름을 사용하지만 다른 네임스페이스 내의 여러 Jaeger 프로덕션 인스턴스로, Elasticsearch 인증서 문제를 발생시킵니다. 여러 서비스 메시가 설치되면 모든 Jaeger Elasticsearch 인스턴스에 개별 시크릿 대신 동일한 Elasticsearch 시크릿이 있어 Elasticsearch Operator가 모든 Elasticsearch 클러스터와 통신할 수 없습니다.
  • TRACING-1300 Istio 사이드카를 사용할 때 에이전트와 수집기 간의 연결에 실패했습니다. Jaeger Operator 업데이트는 Jaeger 사이드카 에이전트와 Jaeger 수집기 간의 TLS 통신을 기본적으로 활성화했습니다.
  • TRACING-1208 Jaeger UI에 액세스할 때 인증 “500 Internal Error”입니다. OAuth를 사용하여 UI를 인증할 때 oauth-proxy 사이드카가 additionalTrustBundle로 설치할 때 정의된 사용자 정의 CA 번들을 신뢰하지 않기 때문에 500 오류가 발생합니다.
  • TRACING-1166 현재 연결이 끊긴 환경에서 Jaeger 스트리밍 전략을 사용할 수 없습니다. Kafka 클러스터가 프로비저닝 중인 경우 오류가 발생합니다. registry.redhat.io/amq7/amq-streams-kafka-24-rhel7@sha256:f9ceca004f1b7dccb3b82d9a8027961f9fe4104e0ed69752c0bdd8078b4a1076 이미지를 가져올 수 없습니다.

2장. Jaeger 아키텍처

2.1. Jaeger 아키텍처

사용자가 애플리케이션에서 작업을 수행할 때마다 응답을 생성하기 위해 참여하도록 다양한 서비스를 필요로 할 수 있는 아키텍처에 의해 요청이 실행됩니다. Jaeger를 사용하면 애플리케이션을 구성하는 다양한 마이크로 서비스를 통해 요청의 경로를 기록하는 분산 추적을 수행할 수 있습니다.

분산 추적은 분산 트랜잭션에 있는 전체 이벤트 체인을 이해하기 위해 일반적으로 다양한 프로세스 또는 호스트에서 실행되는 다양한 작업 단위에 대한 정보를 결합하는 데 사용되는 기술입니다. 개발자는 분산 추적을 사용하여 대규모 마이크로 서비스 아키텍처에서 호출 흐름을 시각화할 수 있습니다. 직렬화, 병렬 메커니즘 및 대기 시간 소스를 이해하는 데 중요합니다.

Jaeger는 마이크로 서비스의 전체 스택에서 개별 요청 실행을 기록하고 이를 추적으로 제공합니다. 추적은 시스템을 통한 데이터/실행 경로입니다. 엔드 투 엔드 추적은 하나 이상의 기간으로 구성됩니다.

기간은 Jaeger에 있는 작업의 논리 단위를 나타냅니다. 작업 이름, 작업의 시작 시간 및 기간과 잠재적으로 태그 및 로그를 포함할 수 있습니다. 기간은 중첩되어 인과 관계를 모델링하도록 주문될 수 있습니다.

2.1.1. Jaeger 개요

서비스 소유자로 Jaeger를 사용하여 서비스 아키텍처에 대한 정보를 수집할 수 있습니다. Jaeger는 최신 클라우드 네이티브, 마이크로서비스 기반 애플리케이션의 구성 요소 간 상호 작용을 모니터링, 네트워크 프로파일링 및 문제 해결에 사용할 수 있는 오픈 소스 분산 추적 플랫폼입니다.

Jaeger를 사용하면 다음 기능을 수행할 수 있습니다.

  • 분산 트랜잭션 모니터링
  • 성능 및 대기 시간 최적화
  • 근본 원인 분석 수행

Jaeger는 벤더 중립 OpenTracing API 및 계측을 기반으로 합니다.

2.1.2. Jaeger 기능

Jaeger 추적은 다음과 같은 기능을 제공합니다.

  • Kiali와의 통합 - 올바르게 구성된 경우 Kiali 콘솔에서 Jaeger 데이터를 볼 수 있습니다.
  • 높은 확장성 - Jaeger 백엔드는 하나의 실패 지점을 보유하고 비즈니스 요구 사항으로 확장할 수 있도록 설계되었습니다.
  • 분산 컨텍스트 전파 - 다른 구성 요소의 데이터를 함께 연결하여 완전한 엔드 투 엔드 추적을 만들 수 있습니다.
  • Zipkin과의 역호환성 - Jaeger에는 Zipkin의 드롭인 대체로 사용할 수 있는 API가 있지만 Red Hat은 이 릴리스에서 Zipkin 호환성을 지원하지 않습니다.

2.1.3. Jaeger 아키텍처

Jaeger는 연동을 통해 추적 데이터를 수집, 저장, 표시하는 여러 구성 요소로 이루어집니다.

  • Jaeger Client(Tracer, Reporter, 조정된 애플리케이션, 클라이언트 라이브러리)- Jaeger 클라이언트는 OpenTracing API의 언어 특정 구현입니다. 수동으로 또는 이미 OpenTracing과 통합된 Camel(Fuse), Spring Boot(RHOAR), MicroProfile(RHOAR/T©tail), Wildfly(EAP) 등의 다양한 기존 오픈 소스 프레임워크를 사용하여 분산 추적에 대해 애플리케이션을 조정하는 데 사용할 수 있습니다.
  • Jaeger 에이전트(Server Queue, Processor Workers) - Jaeger 에이전트는 UDP(User Datagram Protocol)를 통해 전송되는 기간을 수신 대기하는 네트워크 데몬으로, 수집기에 배치 및 전송합니다. 에이전트는 조정된 애플리케이션과 동일한 호스트에 배치되어야 합니다. 일반적으로 Kubernetes와 같은 컨테이너 환경에서 사이드카를 보유하여 수행됩니다.
  • Jaeger 수집기(Queue, Workers) - 에이전트와 유사하게 수집기는 기간을 수신하여 처리를 위한 내부 큐에 배치할 수 있습니다. 그러면 수집기는 기간이 스토리지로 이동할 때까지 대기하지 않고 클라이언트/에이전트로 즉시 돌아갈 수 있습니다.
  • 스토리지(데이터 저장소) - 수집기에는 영구 스토리지 백엔드가 필요합니다. Jaeger에는 기간 스토리지를 위한 플러그인 메커니즘이 있습니다. 이 릴리스에서 지원되는 유일한 스토리지는 Elasticsearch입니다.
  • 쿼리(쿼리 서비스) - 쿼리는 스토리지에서 추적을 검색하는 서비스입니다.
  • Ingester(Ingester 서비스) - Jaeger는 수집기와 실제 백업 스토리(Elasticsearch) 간의 버퍼로 Apache Kafka를 사용할 수 있습니다. Ingester는 Kafka에서 데이터를 읽고 다른 스토리지 백엔드(Elasticsearch)에 쓰는 서비스입니다.
  • Jaeger 콘솔 - Jaeger는 분산 추적 데이터를 시각화할 수 있는 사용자 인터페이스를 제공합니다. 검색 페이지에서 추적을 찾고 개별 추적을 구성하는 기간의 세부 사항을 확인할 수 있습니다.

3장. Jaeger 설치

3.1. Jaeger 설치

다음 두 가지 방법 중 하나로 OpenShift Container Platform에 Jaeger를 설치할 수 있습니다.

  • Jaeger를 Red Hat OpenShift Service Mesh의 일부로 설치할 수 있습니다. Jaeger는 기본적으로 Service Mesh 설치에 포함되어 있습니다. Jaeger를 서비스 메시의 일부로 설치하려면 Red Hat Service Mesh 설치 지침을 따르십시오. Jaeger는 서비스 메시와 동일한 네임스페이스에 설치되어 있어야 합니다. 즉 ServiceMeshControlPlane 및 Jaeger 리소스가 동일한 네임스페이스에 있어야 합니다.
  • 서비스 메시를 설치하지 않으려면 Jaeger Operator를 사용하여 자체적으로 OpenShift Jaeger를 설치할 수 있습니다. 서비스 메시 없이 Jaeger를 설치하려면 다음 지침을 사용하십시오.

3.1.1. 전제 조건

OpenShift Jaeger를 설치하려면 설치 활동을 검토하고 사전 요구 사항을 충족해야 합니다.

3.1.2. Jaeger 설치 개요

OpenShift Jaeger 설치 단계는 다음과 같습니다.

  • 문서를 검토하고 배포 전략을 확인합니다.
  • 배포 전략에 영구 스토리지가 필요한 경우 OperatorHub를 통해 Elasticsearch Operator를 설치합니다.
  • OperatorHub를 통해 Jaeger Operator를 설치합니다.
  • Jaeger YAML 파일을 수정하여 배포 전략을 지원합니다.
  • Jaeger의 인스턴스를 OpenShift Container Platform 환경에 하나 이상 배포합니다.

3.1.3. Elasticsearch Operator 설치

기본 Jaeger 배포는 Jaeger를 평가하거나 설명을 제공하거나 테스트 환경에서 Jaeger를 사용하기 위해 빠르게 설치하도록 설계되었으므로 메모리 내 스토리지를 사용합니다. 프로덕션에서 Jaeger를 사용하려면 영구 스토리지 옵션을 설치하고 구성해야 합니다(이 경우 Elasticsearch).

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.
  • cluster-admin 역할이 있는 계정.
주의

Operator의 커뮤니티 버전은 설치하지 마십시오. 커뮤니티 Operator는 지원되지 않습니다.

참고

이미 Elasticsearch Operator를 OpenShift 클러스터 로깅의 일부로 설치한 경우 Elasticsearch Operator를 다시 설치할 필요가 없습니다. Jaeger Operator는 설치된 Elasticsearch Operator를 사용하여 Elasticsearch 인스턴스를 생성합니다.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. OperatorsOperatorHub로 이동합니다.
  3. Elasticsearch를 필터 상자에 입력하여 Elasticsearch Operator를 찾습니다.
  4. Red Hat에서 제공하는 Elasticsearch Operator를 클릭하여 Operator에 대한 정보를 표시합니다.
  5. 설치를 클릭합니다.
  6. Operator 설치 페이지의 설치 모드에서 클러스터의 모든 네임스페이스(기본값)를 선택합니다. 이렇게 하면 클러스터의 모든 프로젝트에서 Operator를 사용할 수 있습니다.
  7. 설치된 네임스페이스의 메뉴에서 openshift-operators-redhat을 선택합니다.

    참고

    Elasticsearch 설치에는 Elasticsearch Operator의 openshift-operators-redhat 네임스페이스가 필요합니다. 다른 OpenShift Jaeger Operator는 openshift-operators 네임스페이스에 설치됩니다.

  8. OpenShift Container Platform 설치와 일치하는 업데이트 채널을 선택합니다. 예를 들어 OpenShift Container Platform 버전 4.6에 설치하는 경우 4.6 업데이트 채널을 선택합니다.
  9. 자동 승인 전략을 선택합니다.

    참고

    수동 승인 전략을 사용하려면 적절한 인증 정보를 가진 사용자가 Operator 설치 및 서브스크립션 프로세스를 승인해야 합니다.

  10. 설치를 클릭합니다.
  11. 설치된 Operator 페이지에서 openshift-operators-redhat 프로젝트를 선택합니다. 계속하기 전에 Elasticsearch Operator에 "InstallSucceeded" 상태가 표시될 때까지 기다립니다.

3.1.4. Jaeger Operator 설치

Jaeger를 설치하려면 OperatorHub를 사용하여 Jaeger Operator를 설치합니다.

기본적으로 Operator는 openshift-operators 프로젝트에 설치됩니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스합니다.
  • cluster-admin 역할이 있는 계정.
  • 영구 스토리지가 필요한 경우 Jaeger Operator를 설치하기 전에 Elasticsearch Operator도 설치해야 합니다.
주의

Operator의 커뮤니티 버전은 설치하지 마십시오. 커뮤니티 Operator는 지원되지 않습니다.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. OperatorsOperatorHub로 이동합니다.
  3. Jaeger를 필터에 입력하여 Jaeger Operator를 찾습니다.
  4. Red Hat에서 제공하는 Jaeger Operator를 클릭하여 Operator에 대한 정보를 표시합니다.
  5. 설치를 클릭합니다.
  6. Operator 설치 페이지에서 stable 업데이트 채널을 선택합니다. 새로운 버전이 릴리스되면 Jaeger가 자동으로 업데이트됩니다. 유지 관리 채널(예: 1.17-stable)을 선택하면 해당 버전의 지원 주기 길이에 대한 버그 수정 및 보안 패치가 제공됩니다.
  7. 클러스터의 모든 네임스페이스(기본값)를 선택합니다. 이렇게 하면 기본 openshift-operators 프로젝트에서 Operator가 설치되고 클러스터의 모든 프로젝트에서 Operator를 사용할 수 있습니다.

    • 승인 전략을 선택합니다. 자동 또는 수동 업데이트를 선택할 수 있습니다. 설치된 Operator에 대해 자동 업데이트를 선택하는 경우 해당 Operator의 새 버전이 사용 가능하면 OLM(Operator Lifecycle Manager)은 개입 없이 Operator의 실행 중인 인스턴스를 자동으로 업그레이드합니다. 수동 업데이트를 선택하면 최신 버전의 Operator가 사용 가능할 때 OLM이 업데이트 요청을 작성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.

      참고

      수동 승인 전략을 사용하려면 적절한 인증 정보를 가진 사용자가 Operator 설치 및 서브스크립션 프로세스를 승인해야 합니다.

  8. 설치를 클릭합니다.
  9. 서브스크립션 개요 페이지에서 openshift-operators 프로젝트를 선택합니다. 계속하기 전에 Jaeger Operator에 "InstallSucceeded" 상태가 표시될 때까지 기다립니다.

3.2. Jaeger 구성 및 배포

Jaeger Operator는 Jaeger 리소스를 생성하고 배포할 때 사용할 아키텍처 및 구성 설정을 정의하는 CRD(사용자 정의 리소스 정의) 파일을 사용합니다. 기본 구성을 설치하거나 비즈니스 요구 사항에 맞게 파일을 수정할 수 있습니다.

Jaeger에는 사전 정의된 배포 전략이 있습니다. 사용자 정의 리소스 파일에 배포 전략을 지정합니다. Jaeger 인스턴스를 생성할 때 Operator는 이 구성 파일을 사용하여 배포에 필요한 오브젝트를 생성합니다.

배포 전략을 표시하는 Jaeger 사용자 정의 리소스 파일

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production 1

1
Jaeger Operator는 현재 다음 배포 전략을 지원합니다.
  • allInOne(기본값) - 이 전략은 개발, 테스트 및 데모 목적으로 설계되었습니다. 이는 프로덕션 사용을 목적으로 하지 않습니다. 기본 백엔드 구성 요소인 에이전트, 수집기 및 쿼리 서비스는 모두 메모리 내 스토리지를 사용하도록 (기본적으로) 구성된 단일 실행 파일로 패키지됩니다.

    참고

    메모리 내 스토리지는 영구적이지 않습니다. 즉, Jaeger 인스턴스가 종료, 재시작 또는 교체되면 추적 데이터가 손실됩니다. 각 Pod에 자체 메모리가 있으므로 메모리 내 스토리지를 확장할 수 없습니다. 영구 스토리지의 경우 Elasticsearch를 기본 스토리지로 사용하는 production 또는 streaming 전략을 사용해야 합니다.

  • 프로덕션 - 프로덕션 전략은 장기적인 추적 데이터 저장과 더 확장 가능하고 가용성이 높은 아키텍처가 필요한 프로덕션 환경을 위한 것입니다. 따라서 각 백엔드 구성 요소는 별도로 배포됩니다. 에이전트는 조정된 애플리케이션에서 사이드카로 삽입될 수 있습니다. 쿼리 및 수집기 서비스는 지원되는 스토리지 유형(현재 Elasticsearch)으로 구성됩니다. 이러한 각 구성 요소의 여러 인스턴스는 성능 및 복원에 필요한 대로 프로비저닝할 수 있습니다.
  • 스트리밍 - 스트리밍 전략은 수집기와 백엔드 스토리지(Elasticsearch) 간에 효과적으로 적용되는 스트리밍 기능을 제공하여 프로덕션 전략을 보강하도록 설계되었습니다. 이를 통해 높은 로드 상황에서 백엔드 스토리지의 부담을 줄이고 다른 추적 후 처리 기능을 통해 스트리밍 플랫폼(AMQ Streams/ Kafka)에서 직접 실시간 데이터를 가져올 수 있습니다.

    참고

    스트리밍 전략에는 AMQ Streams에 대한 추가 Red Hat 서브스크립션이 필요합니다.

참고

Jaeger를 서비스 메시의 일부로 또는 독립형 구성 요소로 설치 및 사용할 수 있는 두 가지 방법이 있습니다. Red Hat OpenShift Service Mesh의 일부로 Jaeger를 설치한 경우 ServiceMeshControlPlane 의 일부로 Jaeger를 구성하고 배포한 다음 SMCP에서 Jaeger 구성을 참조할 수 있습니다.

3.2.1. 웹 콘솔에서 기본 Jaeger 전략 배포

CRD(사용자 정의 리소스 정의)는 Jaeger 인스턴스를 배포할 때 사용되는 구성을 정의합니다. Jaeger의 기본 CR 이름은 jaeger-all-in-one-inmemory로 지정되어 기본 OpenShift Container Platform 설치에 성공적으로 설치할 수 있도록 최소한의 리소스로 구성됩니다. 이 기본 구성을 사용하여 AllInOne 배포 전략을 사용하는 Jaeger 인스턴스를 만들거나 고유한 사용자 정의 리소스 파일을 정의할 수 있습니다.

참고

메모리 내 스토리지는 영구적이지 않습니다. 즉, Jaeger Pod가 종료, 재시작 또는 교체되면 추적 데이터가 손실됩니다. 영구 스토리지의 경우 Elasticsearch를 기본 스토리지로 사용하는 production 또는 streaming 전략을 사용해야 합니다.

전제 조건

  • Jaeger Operator가 설치되어 있어야 합니다.
  • Jaeger 설치를 사용자 지정하는 방법에 대한 지침을 검토하십시오.
  • cluster-admin 역할이 있는 계정.
참고

Jaeger 스트리밍은 현재 IBM Z에서 지원되지 않습니다.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. 새 프로젝트를 생성합니다(예: jaeger-system).

    1. 프로젝트로 이동합니다.
    2. Create Project를 클릭합니다.
    3. jaeger-systemName 필드에 입력합니다.
    4. Create를 클릭합니다.
  3. Operators설치된 Operator로 이동합니다.
  4. 필요한 경우 프로젝트 메뉴에서 jaeger-system을 선택합니다. Operator가 새 프로젝트에 복사될 때까지 몇 분 정도 기다려야 할 수 있습니다.
  5. OpenShift Jaeger Operator를 클릭합니다. 개요 탭의 제공된 API에서 Operator는 단일 링크를 제공합니다.
  6. Jaeger에서 인스턴스 생성을 클릭합니다.
  7. Jaeger 생성 페이지에서 기본값을 사용하여 설치하려면 만들기를 클릭하여 Jaeger 인스턴스를 생성합니다.
  8. Jaegers 페이지에서 Jaeger 인스턴스의 이름을 클릭합니다(예: jaeger-all-one-in-in-inmemory).
  9. Jaeger 세부 정보 페이지에서 리소스 탭을 클릭합니다. 계속하기 전에 Pod 상태가 "실행 중"이 될 때까지 기다립니다.

3.2.1.1. CLI에서 기본 Jaeger 배포

다음 절차에 따라 명령줄에서 Jaeger 인스턴스를 생성합니다.

전제 조건

  • 설치되고 검증된 OpenShift Jaeger Operator.
  • OpenShift Container Platform 버전과 일치하는 OpenShift CLI(oc)에 대한 액세스.
  • cluster-admin 역할이 있는 계정.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다.

    $ oc login https://{HOSTNAME}:8443
  2. jaeger-system이라는 새 프로젝트를 생성합니다.

    $ oc new-project jaeger-system
  3. 다음 텍스트가 포함된 jaeger.yaml이라는 사용자 정의 리소스 파일을 생성합니다.

    예: jaeger-all-one.yaml

    apiVersion: jaegertracing.io/v1
    kind: Jaeger
    metadata:
      name: jaeger-all-in-one-inmemory

  4. 다음 명령을 실행하여 Jaeger를 배포합니다.

    $ oc create -n jaeger-system -f jaeger.yaml
  5. 다음 명령을 실행하여 설치 프로세스 중에 Pod의 진행 상황을 확인합니다.

    $ oc get pods -n jaeger-system -w

    설치 프로세스가 완료되면 다음과 유사한 출력이 표시됩니다.

    NAME                                         READY   STATUS    RESTARTS   AGE
    jaeger-all-in-one-inmemory-cdff7897b-qhfdx   2/2     Running   0          24s

3.2.2. 웹 콘솔에서 Jaeger 프로덕션 전략 배포

production 배포 전략은 프로덕션 환경을 위해 고안되어 있으며, 여기서 추적 데이터의 장기 스토리지가 중요하며 더 확장이 가능하고 가용성이 높은 아키텍처가 필요합니다.

전제 조건

  • Elasticsearch Operator가 설치되어 있어야 합니다.
  • Jaeger Operator가 설치되어 있어야 합니다.
  • Jaeger 설치를 사용자 지정하는 방법에 대한 지침을 검토하십시오.
  • cluster-admin 역할이 있는 계정.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. 새 프로젝트를 생성합니다(예: jaeger-system).

    1. 프로젝트로 이동합니다.
    2. Create Project를 클릭합니다.
    3. jaeger-systemName 필드에 입력합니다.
    4. Create를 클릭합니다.
  3. Operators설치된 Operator로 이동합니다.
  4. 필요한 경우 프로젝트 메뉴에서 jaeger-system을 선택합니다. Operator가 새 프로젝트에 복사될 때까지 몇 분 정도 기다려야 할 수 있습니다.
  5. Jaeger Operator를 클릭합니다. 개요 탭의 제공된 API에서 Operator는 단일 링크를 제공합니다.
  6. Jaeger에서 인스턴스 생성을 클릭합니다.
  7. Jaeger 만들기 페이지에서 기본 all-in-one yaml 텍스트를 프로덕션 YAML 구성으로 교체합니다. 예를 들면 다음과 같습니다.

    예 jaeger-production.yaml 파일을 Elasticsearch로

    apiVersion: jaegertracing.io/v1
    kind: Jaeger
    metadata:
      name: jaeger-production
      namespace:
    spec:
      strategy: production
      ingress:
        security: oauth-proxy
      storage:
        type: elasticsearch
        elasticsearch:
          nodeCount: 3
          redundancyPolicy: SingleRedundancy
        esIndexCleaner:
          enabled: true
          numberOfDays: 7
          schedule: 55 23 * * *
        esRollover:
          schedule: '*/30 * * * *'

  8. 만들기를 클릭하여 Jaeger 인스턴스를 생성합니다.
  9. Jaegers 페이지에서 Jaeger 인스턴스의 이름을 클릭합니다(예: jaeger-prod-elasticsearch).
  10. Jaeger 세부 정보 페이지에서 리소스 탭을 클릭합니다. 계속하기 전에 모든 Pod 상태가 "실행 중"이 될 때까지 기다립니다.

3.2.2.1. CLI에서 Jaeger 프로덕션 배포

다음 절차에 따라 명령줄에서 Jaeger 인스턴스를 생성합니다.

전제 조건

  • 설치되고 검증된 OpenShift Jaeger Operator.
  • OpenShift CLI(oc)에 액세스합니다.
  • cluster-admin 역할이 있는 계정.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다.

    $ oc login https://{HOSTNAME}:8443
  2. jaeger-system이라는 새 프로젝트를 생성합니다.

    $ oc new-project jaeger-system
  3. 이전 프로세스의 예제 텍스트가 포함된 jaeger-production.yaml이라는 사용자 정의 리소스 파일을 생성합니다.
  4. 다음 명령을 실행하여 Jaeger를 배포합니다.

    $ oc create -n jaeger-system -f jaeger-production.yaml
  5. 다음 명령을 실행하여 설치 프로세스 중에 Pod의 진행 상황을 확인합니다.

    $ oc get pods -n jaeger-system -w

    설치 프로세스가 완료되면 다음과 유사한 출력이 표시됩니다.

    NAME                                                              READY   STATUS    RESTARTS   AGE
    elasticsearch-cdm-jaegersystemjaegerproduction-1-6676cf568gwhlw   2/2     Running   0          10m
    elasticsearch-cdm-jaegersystemjaegerproduction-2-bcd4c8bf5l6g6w   2/2     Running   0          10m
    elasticsearch-cdm-jaegersystemjaegerproduction-3-844d6d9694hhst   2/2     Running   0          10m
    jaeger-production-collector-94cd847d-jwjlj                        1/1     Running   3          8m32s
    jaeger-production-query-5cbfbd499d-tv8zf                          3/3     Running   3          8m32s

3.2.3. 웹 콘솔에서 Jaeger 스트리밍 전략 배포

streaming 배포 전략은 프로덕션 환경을 위해 고안되어 있으며, 여기서 추적 데이터의 장기 스토리지가 중요하며 더 확장이 가능하고 가용성이 높은 아키텍처가 필요합니다.

streaming 전략은 수집기와 스토리지(Elasticsearch) 간에 있는 스트리밍 기능을 제공합니다. 이렇게 하면 높은 로드 상황에서 스토리지의 부담을 줄이고 다른 추적 후 처리 기능을 통해 스트리밍 플랫폼(Kafka)에서 직접 실시간 데이터로 전환할 수 있습니다.

참고

스트리밍 전략에는 AMQ Streams에 대한 추가 Red Hat 서브스크립션이 필요합니다. AMQ Streams 서브스크립션이 없는 경우 영업 담당자에게 자세한 내용을 문의하십시오.

전제 조건

  • AMQ Streams Operator가 설치되어 있어야 합니다. 버전 1.4.0 이상을 사용하는 경우 자체 프로비저닝을 사용할 수 있습니다. 그러지 않으면 Kafka 인스턴스를 생성해야 합니다.
  • Jaeger Operator가 설치되어 있어야 합니다.
  • Jaeger 설치를 사용자 지정하는 방법에 대한 지침을 검토하십시오.
  • cluster-admin 역할이 있는 계정.
참고

Jaeger 스트리밍은 현재 IBM Z에서 지원되지 않습니다.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. 새 프로젝트를 생성합니다(예: jaeger-system).

    1. 프로젝트로 이동합니다.
    2. Create Project를 클릭합니다.
    3. jaeger-systemName 필드에 입력합니다.
    4. Create를 클릭합니다.
  3. Operators설치된 Operator로 이동합니다.
  4. 필요한 경우 프로젝트 메뉴에서 jaeger-system을 선택합니다. Operator가 새 프로젝트에 복사될 때까지 몇 분 정도 기다려야 할 수 있습니다.
  5. Jaeger Operator를 클릭합니다. 개요 탭의 제공된 API에서 Operator는 단일 링크를 제공합니다.
  6. Jaeger에서 인스턴스 생성을 클릭합니다.
  7. Jaeger 만들기 페이지에서 기본 all-in-one yaml 텍스트를 스트리밍 YAML 구성으로 교체합니다. 예를 들면 다음과 같습니다.

jaeger-streaming.yaml 파일 예

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-streaming
spec:
  strategy: streaming
  collector:
    options:
      kafka:
        producer:
          topic: jaeger-spans
          #Note: If brokers are not defined,AMQStreams 1.4.0+ will self-provision Kafka.
          brokers: my-cluster-kafka-brokers.kafka:9092
  storage:
    type: elasticsearch
  ingester:
    options:
      kafka:
        consumer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092

  1. 만들기를 클릭하여 Jaeger 인스턴스를 생성합니다.
  2. Jaegers 페이지에서 Jaeger 인스턴스의 이름을 클릭합니다(예: jaeger-streaming ).
  3. Jaeger 세부 정보 페이지에서 리소스 탭을 클릭합니다. 계속하기 전에 모든 Pod 상태가 "실행 중"이 될 때까지 기다립니다.

3.2.3.1. CLI에서 Jaeger 스트리밍 배포

다음 절차에 따라 명령줄에서 Jaeger 인스턴스를 생성합니다.

전제 조건

  • 설치되고 검증된 OpenShift Jaeger Operator.
  • OpenShift CLI(oc)에 액세스합니다.
  • cluster-admin 역할이 있는 계정.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform CLI에 로그인합니다.

    $ oc login https://{HOSTNAME}:8443
  2. jaeger-system이라는 새 프로젝트를 생성합니다.

    $ oc new-project jaeger-system
  3. 이전 프로세스의 예제 텍스트가 포함된 jaeger-streaming.yaml이라는 사용자 정의 리소스 파일을 생성합니다.
  4. 다음 명령을 실행하여 Jaeger를 배포합니다.

    $ oc create -n jaeger-system -f jaeger-streaming.yaml
  5. 다음 명령을 실행하여 설치 프로세스 중에 Pod의 진행 상황을 확인합니다.

    $ oc get pods -n jaeger-system -w

    설치 프로세스가 완료되면 다음과 유사한 출력이 표시됩니다.

    NAME                                                              READY   STATUS    RESTARTS   AGE
    elasticsearch-cdm-jaegersystemjaegerstreaming-1-697b66d6fcztcnn   2/2     Running   0          5m40s
    elasticsearch-cdm-jaegersystemjaegerstreaming-2-5f4b95c78b9gckz   2/2     Running   0          5m37s
    elasticsearch-cdm-jaegersystemjaegerstreaming-3-7b6d964576nnz97   2/2     Running   0          5m5s
    jaeger-streaming-collector-6f6db7f99f-rtcfm                       1/1     Running   0          80s
    jaeger-streaming-entity-operator-6b6d67cc99-4lm9q                 3/3     Running   2          2m18s
    jaeger-streaming-ingester-7d479847f8-5h8kc                        1/1     Running   0          80s
    jaeger-streaming-kafka-0                                          2/2     Running   0          3m1s
    jaeger-streaming-query-65bf5bb854-ncnc7                           3/3     Running   0          80s
    jaeger-streaming-zookeeper-0                                      2/2     Running   0          3m39s

3.2.4. Jaeger 배포 사용자 정의

3.2.4.1. 배포 모범 사례

  • Jaeger 인스턴스 이름은 고유해야 합니다. 여러 Jaeger 인스턴스가 있고 사이드카 삽입된 Jaeger 에이전트를 사용하려는 경우 Jaeger 인스턴스에 고유한 이름이 있어야 하며 삽입 주석은 보고해야 하는 Jaeger 인스턴스 이름을 명시적으로 지정해야 합니다.
  • 다중 테넌트 구현이 있고 테넌트가 네임스페이스에 의해 구분되는 경우 Jaeger 인스턴스를 각 테넌트 네임스페이스에 배포합니다.
  • Jaeger를 Red Hat OpenShift Service Mesh의 일부로 설치하는 경우 ServiceMeshControlPlane 리소스와 동일한 네임스페이스에 Jaeger 리소스를 설치해야 합니다.

3.2.4.2. Jaeger 기본 구성 옵션

Jaeger CR(사용자 정의 리소스)은 Jaeger 리소스를 생성할 때 사용할 아키텍처 및 설정을 정의합니다. 이러한 매개변수를 수정하여 Jaeger 구현을 비즈니스 요구에 맞게 사용자 지정할 수 있습니다.

Jaeger 일반 YAML 예

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: name
spec:
  strategy: <deployment_strategy>
  allInOne:
    options: {}
    resources: {}
  agent:
    options: {}
    resources: {}
  collector:
    options: {}
    resources: {}
  sampling:
    options: {}
  storage:
    type:
    options: {}
  query:
    options: {}
    resources: {}
  ingester:
    options: {}
    resources: {}
  options: {}

표 3.1. Jaeger 매개변수

매개변수설명기본값

apiVersion:

오브젝트를 생성할 때 사용할 애플리케이션 프로그램 인터페이스 버전입니다.

jaegertracing.io/v1

jaegertracing.io/v1

kind:

생성할 Kubernetes 오브젝트를 정의합니다.

jaeger

 

metadata:

이름 문자열, UID 및 선택적 namespace 를 포함하여 오브젝트를 고유하게 식별할 수 있는 데이터입니다.

 

OpenShift는 UID를 자동으로 생성하고 오브젝트가 생성된 프로젝트의 이름으로 네임스페이스를 완료합니다.

name:

개체의 이름입니다.

Jaeger 인스턴스의 이름입니다.

jaeger-all-in-one-inmemory

spec:

생성할 오브젝트의 사양입니다.

Jaeger 인스턴스에 대한 모든 구성 매개변수를 포함합니다. 공통 정의(모든 Jaeger 구성 요소에 대해)가 필요한 경우 사양 노드 아래에 정의됩니다. 정의가 개별 구성 요소와 관련된 경우 spec/<component> 노드 아래에 배치됩니다.

해당 없음

strategy:

Jaeger 배포 전략

allInOne, production 또는 streaming

allInOne

allInOne:

allInOne 이미지가 에이전트, 수집기, 쿼리, ingester, Jaeger UI를 단일 Pod에 배포하므로 이 배포에 대한 구성은 allInOne 매개변수의 구성을 중첩해야 합니다.

  

agent:

Jaeger 에이전트를 정의하는 구성 옵션입니다.

  

collector:

Jaeger 수집기를 정의하는 구성 옵션입니다.

  

sampling:

추적을 위한 샘플링 전략을 정의하는 구성 옵션입니다.

  

storage:

스토리지를 정의하는 구성 옵션입니다. 모든 스토리지 관련 옵션은 allInOne 또는 기타 구성 요소 옵션에 있지 않고 storage 아래에 배치되어야 합니다.

  

query:

쿼리 서비스를 정의하는 구성 옵션입니다.

  

ingester:

Ingester 서비스를 정의하는 구성 옵션입니다.

  

다음 예제 YAML은 기본 설정을 사용하여 Jaeger 인스턴스를 생성하는 데 필요한 최소값입니다.

예 최소값 필요 jaeger-all-in-one.yaml

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-all-in-one-inmemory

3.2.4.3. Jaeger 수집기 구성 옵션

Jaeger 수집기는 추적기에서 캡처한 기간을 수신하여 production 전략을 사용할 때 영구 스토리지(Elasticsearch)에 기록하거나 streaming 전략을 사용할 때 AMQ Streams에 기록하는 구성 요소입니다.

수집기는 스테이트리스이므로 Jaeger 수집기의 많은 인스턴스가 병렬로 실행될 수 있습니다. 수집기는 Elasticsearch 클러스터의 위치를 제외하고 거의 구성이 필요하지 않습니다.

표 3.2. Jaeger 수집기를 정의하는 데 Operator에서 사용하는 매개변수

매개변수설명
collector:
  replicas:

생성할 수집기 복제본 수를 지정합니다.

정수(예: 5)

표 3.3. 수집기에 전달된 Jaeger 매개변수

매개변수설명
spec:
 collector:
  options: {}

Jaeger 수집기를 정의하는 구성 옵션입니다.

 
options:
  collector:
    num-workers:

큐에서 가져온 작업자 수입니다.

정수(예: 50)

options:
  collector:
    queue-size:

수집기 큐의 크기입니다.

정수(예: 2000)

options:
  kafka:
    producer:
      topic: jaeger-spans

topic 매개변수는 메시지를 생성하는 수집기와 메시지를 사용하는 ingester에서 사용하는 Kafka 구성을 식별합니다.

생성자의 레이블

kafka:
  producer:
    brokers: my-cluster-kafka-brokers.kafka:9092

메시지를 생성하기 위해 수집기에서 사용하는 Kafka 구성을 식별합니다. 브로커를 지정하지 않고 AMQ Streams 1.4.0+가 설치되어 있으면 Jaeger가 Kafka를 자체적으로 프로비저닝합니다.

 
log-level:

수집기의 로깅 수준입니다.

trace, debug, info, warning, error, fatal, panic

maxReplicas:

수집기를 자동 스케일링할 때 생성할 최대 복제본 수를 지정합니다.

정수(예: 100)

num-workers:

큐에서 가져온 작업자 수입니다.

정수(예: 50)

queue-size:

수집기 큐의 크기입니다.

정수(예: 2000)

replicas:

생성할 수집기 복제본 수를 지정합니다.

정수(예: 5)

3.2.4.3.1. 자동 스케일링을 위한 수집기 구성
참고

Jaeger 1.20 이상에서만 자동 스케일링이 지원됩니다.

자동 스케일링을 위해 수집기를 구성할 수 있습니다. 수집기는 CPU 및/또는 메모리 소비에 따라 확장 또는 축소됩니다. 자동 스케일링을 위해 수집기를 구성하면 증가된 로드 시간 동안 Jaeger 환경이 확장되고 적은 리소스가 필요하면 축소되어 비용을 절감할 수 있습니다. autoscale 매개변수를 true로 설정하고 사용할 수집기의 Pod를 예상하는 리소스의 적절한 값과 함께 .spec.collector.maxReplicas의 값을 지정하여 자동 스케일링을 구성합니다. .spec.collector.maxReplicas의 값을 설정하지 않으면 Operator가 100으로 설정합니다.

기본적으로 .spec.collector.replicas에 제공된 값이 없는 경우 Jaeger Operator는 수집기에 대한 HPA(Horizontal Pod Autoscaler) 구성을 생성합니다. HPA에 대한 자세한 내용은 Kubernetes 문서를 참조하십시오.

다음은 자동 스케일링 구성의 예로, 수집기의 제한과 최대 복제본 수를 설정합니다.

수집기 자동 스케일링 예

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  collector:
    maxReplicas: 5
    resources:
      limits:
        cpu: 100m
        memory: 128Mi

3.2.4.4. Jaeger 샘플링 구성 옵션

Operator는 원격 샘플러를 사용하도록 구성된 추적기에 제공될 샘플링 전략을 정의하는 데 사용할 수 있습니다.

모든 추적이 생성되지만 소수만 샘플링됩니다. 추적 샘플링은 추가 처리 및 스토리지의 추적을 나타냅니다.

참고

이는 샘플링 결정에 따라 Istio 프록시에서 추적을 시작한 경우와 관련이 없습니다. Jaeger 샘플링 결정은 Jaeger 추적기를 사용하여 애플리케이션에서 추적을 시작할 때에만 관련이 있습니다.

서비스에서 추적 컨텍스트가 없는 요청을 수신하면 Jaeger 추적기가 새 추적을 시작하여 임의 추적 ID를 할당하고 현재 설치된 샘플 설정에 따라 샘플 결정을 내립니다. 샘플링 결정은 추적의 모든 후속 요청으로 전파되며, 이로 인해 다른 서비스에서 샘플링 결정을 다시 하지 않습니다.

Jaeger 라이브러리는 다음 샘플을 지원합니다.

  • 확률론 - 샘플러는 샘플링(sampling.param) 속성의 값과 동일한 샘플링의 확률로 임의 샘플링 결정을 내립니다. 예를 들어, sampling.param=0.1로 10개의 추적 중 약 1개가 샘플링됩니다.
  • 속도 제한 - 샘플러는 누수된 버킷 속도 제한기를 사용하여 추적을 특정한 일정 속도로 샘플링합니다. 예를 들어, sampling.param=2.0인 경우 초당 2개 추적의 속도로 샘플 요청을 수행합니다.

표 3.4. Jaeger 샘플링 옵션

매개변수설명기본값
spec:
 sampling:
  options: {}
    default_strategy:
    service_strategy:

추적을 위한 샘플링 전략을 정의하는 구성 옵션입니다.

 

구성을 제공하지 않으면 수집기는 모든 서비스에 대해 0.001(0.1%) 가능성이 있는 기본 확률 샘플링 정책을 반환합니다.

default_strategy:
  type:
service_strategy:
  type:

사용할 샘플링 전략입니다. (위의 설명을 참조하십시오.)

유효한 값은 확률적, 속도 제한입니다.

probabilistic

default_strategy:
  param:
service_strategy:
  param:

선택한 샘플링 전략에 대한 매개변수입니다.

10진수 및 정수 값(0, .1, 1, 10)

1

이 예에서는 추적 인스턴스가 샘플링될 가능성이 50%인 비율로 확률적인 기본 샘플링 전략을 정의합니다.

확률 샘플링 예

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: with-sampling
spec:
  sampling:
    options:
      default_strategy:
        type: probabilistic
        param: 0.5
      service_strategies:
        - service: alpha
          type: probabilistic
          param: 0.8
          operation_strategies:
            - operation: op1
              type: probabilistic
              param: 0.2
            - operation: op2
              type: probabilistic
              param: 0.4
        - service: beta
          type: ratelimiting
          param: 5

사용자 제공 구성이 없는 경우 Jaeger는 다음 설정을 사용합니다.

기본 샘플링

spec:
  sampling:
    options:
      default_strategy:
        type: probabilistic
        param: 1

3.2.4.5. Jaeger 스토리지 구성 옵션

spec:storage에서 수집기, Ingester 및 쿼리 서비스에 대한 스토리지를 구성합니다. 이러한 각 구성 요소의 여러 인스턴스는 성능 및 복원에 필요한 대로 프로비저닝할 수 있습니다.

표 3.5. Jaeger 스토리지 정의를 위해 Operator에서 사용하는 일반 스토리지 매개변수

매개변수설명기본값
spec:
  storage:
    type:

배포에 사용할 스토리지 유형입니다.

memory 또는 elasticsearch. 메모리 스토리지는 Pod가 종료되면 데이터가 유지되지 않으므로 개념 환경의 개발, 테스트, 시연 및 검증에만 적합합니다. 프로덕션 환경의 경우 Jaeger는 영구 스토리지를 위해 Elasticsearch를 지원합니다.

memory

storage:
  secretname:

시크릿 이름(예: jaeger-secret)입니다.

 

해당 없음

storage:
  options: {}

스토리지를 정의하는 구성 옵션입니다.

  

표 3.6. Elasticsearch 인덱스 정리 매개변수

매개변수설명기본값
storage:
  esIndexCleaner:
    enabled:

Elasticsearch 스토리지를 사용하는 경우 기본적으로 인덱스에서 오래된 추적을 정리하는 작업이 생성됩니다. 이 매개변수는 인덱스 정리 작업을 활성화하거나 비활성화합니다.

true/ false

true

storage:
  esIndexCleaner:
    numberOfDays:

인덱스를 삭제하기 전에 대기하는 일 수입니다.

정수 값

7

storage:
  esIndexCleaner:
    schedule:

Elasticsearch 인덱스를 정리하는 빈도에 대한 일정을 정의합니다.

Cron 표현식

"55 23 * * *"

3.2.4.5.1. Elasticsearch 인스턴스 자동 프로비저닝

storage:typeelasticsearch로 설정되어 있지만 spec:storage:options:es:server-urls에 대한 값이 없는 경우 Jaeger Operator는 Elasticsearch Operator를 사용하여 사용자 정의 리소스 파일의 스토리지 섹션에 제공된 구성에 따라 Elasticsearch 클러스터를 생성합니다.

제한 사항

  • 네임스페이스당 Elasticsearch가 하나만 있을 수 있습니다.
  • Jaeger와 OpenShift Jaeger 로깅 Elasticsearch 인스턴스를 공유하거나 재사용할 수 없습니다. Elasticsearch 클러스터는 단일 Jaeger 인스턴스 전용입니다.
참고

OpenShift 로깅의 일부로 Elasticsearch를 이미 설치한 경우 Jaeger Operator는 설치된 Elasticsearch Operator를 사용하여 스토리지를 프로비저닝할 수 있습니다.

다음 구성 매개변수는 Elasticsearch Operator를 사용하여 Jaeger Operator에 의해 생성된 인스턴스인 자체 프로비저닝 Elasticsearch 인스턴스에 대한 것입니다. 구성 파일의 spec:storage:elasticsearch에서 자체 프로비저닝 Elasticsearch에 대한 구성 옵션을 지정합니다.

표 3.7. Elasticsearch 리소스 구성 매개변수

매개변수설명기본값
elasticsearch:
  nodeCount:

Elasticsearch 노드 수입니다. 고가용성의 경우 최소 3개의 노드를 사용합니다. “스플릿 브레인” 문제가 발생할 수 있으므로 2개의 노드를 사용하지 마십시오.

정수 값입니다. 예를 들면 개념 증명 = 1, 최소 배포 =3입니다.

3

elasticsearch:
  resources:
    requests:
      cpu:

사용자 환경 구성에 따른 요청에 대한 중앙 처리 단위 수입니다.

코어 또는 밀리코어(예: 200m, 0.5, 1)에 지정되어 있습니다. 예를 들면 개념 증명 = 500m, 최소 배포 =1입니다.

1

elasticsearch:
  resources:
    requests:
      memory:

환경 구성에 따른 요청에 사용 가능한 메모리입니다.

바이트로 지정됩니다(예: 200Ki, 50Mi, 5Gi). 예를 들면 개념 증명 = 1Gi, 최소 배포 = 16Gi*입니다.

16Gi

elasticsearch:
  resources:
    limits:
      cpu:

사용자 환경 구성에 따른 중앙 처리 장치 수에 대한 제한입니다.

코어 또는 밀리코어(예: 200m, 0.5, 1)에 지정되어 있습니다. 예를 들면 개념 증명 = 500m, 최소 배포 =1입니다.

 
elasticsearch:
  resources:
    limits:
      memory:

사용자 환경 구성에 따라 사용 가능한 메모리 제한입니다.

바이트로 지정됩니다(예: 200Ki, 50Mi, 5Gi). 예를 들면 개념 증명 = 1Gi, 최소 배포 = 16Gi*입니다.

 
elasticsearch:
  redundancyPolicy:

데이터 복제 정책은 Elasticsearch shard가 클러스터의 데이터 노드에 복제되는 방법을 정의합니다. 지정하지 않으면 Jaeger Operator가 노드 수에 따라 가장 적절한 복제를 자동으로 결정합니다.

ZeroRedundancy(replica shard 없음), SingleRedundancy(하나의 replica shard), MultipleRedundancy(각 인덱스가 데이터 노드의 반을 넘어 분산됨), FullRedundancy(각 인덱스가 클러스터의 모든 데이터 노드에 전체적으로 복제됨).

 

*각 Elasticsearch 노드는 더 낮은 메모리 설정으로 작동할 수 있지만 프로덕션 배포에는 권장되지 않습니다. 프로덕션 용도의 경우 기본적으로 각 Pod에 할당된 16Gi 미만이 있어야 하지만 Pod당 최대 64Gi까지 할당할 수도 있습니다.

프로덕션 스토리지 예

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      nodeCount: 3
      resources:
        requests:
          cpu: 1
          memory: 16Gi
        limits:
          memory: 16Gi

영구 스토리지가 있는 스토리지 예:

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      nodeCount: 1
      storage: 1
        storageClassName: gp2
        size: 5Gi
      resources:
        requests:
          cpu: 200m
          memory: 4Gi
        limits:
          memory: 4Gi
      redundancyPolicy: ZeroRedundancy

1
영구 스토리지 구성. 이 경우 AWS gp25Gi 크기가 있습니다. 값이 지정되지 않으면 Jaeger는 emptyDir을 사용합니다. Elasticsearch Operator는 Jaeger 인스턴스와 함께 제거되지 않은 PersistentVolumeClaimPersistentVolume을 프로비저닝합니다. 동일한 이름과 네임스페이스를 사용하여 Jaeger 인스턴스를 생성하면 동일한 볼륨을 마운트할 수 있습니다.
3.2.4.5.2. 기존 Elasticsearch 인스턴스에 연결

Jaeger를 사용하면 스토리지에 기존(자체 프로비저닝) Elasticsearch 클러스터를 사용할 수도 있습니다. 기존 클러스터의 URL을 구성의 spec:storage:options:es:server-urls 값으로 지정하여 이 작업을 수행합니다.

제한 사항

  • 네임스페이스당 자체 프로비저닝 Elasticsearch 인스턴스가 있는 Jaeger가 하나만 있을 수 있습니다.
참고

Red Hat은 외부 Elasticsearch 인스턴스를 지원하지 않습니다. Customer Portal에서 테스트된 통합 매트릭스를 검토할 수 있습니다.

다음 구성 매개변수는 Elasticsearch Operator를 사용하여 생성되지 않은 인스턴스인 외부 Elasticsearch 인스턴스에 대한 것입니다. 구성 파일에서 spec:storage:options:es에 외부 Elasticsearch에 대한 구성 옵션을 지정합니다.

표 3.8. 일반 ES 구성 매개변수

매개변수설명기본값
es:
  server-urls:

Elasticsearch 인스턴스의 URL입니다.

Elasticsearch 서버의 정규화된 도메인 이름입니다.

http://elasticsearch.<namespace>.svc:9200

es:
  max-doc-count:

Elasticsearch 쿼리에서 반환하는 최대 문서 수입니다. 이는 집계에도 적용됩니다. es.max-doc-countes.max-num-spans를 모두 설정하면 Elasticsearch에서 이 둘 중 작은 값을 사용합니다.

 

10000

es:
  max-num-spans:

[더 이상 사용되지 않음 - 향후 릴리스에서 제거되며 대신 es.max-doc-count를 사용합니다.] Elasticsearch에서 쿼리당 한 번에 가져올 최대 기간 수입니다. es.max-num-spanses.max-doc-count를 모두 설정하면 Elasticsearch는 이 둘 중 작은 값을 사용합니다.

 

10000

es:
  max-span-age:

Elasticsearch에서 기간에 대한 최대 조회 수입니다.

 

72h0m0s

es:
  sniffer:

Elasticsearch의 스니퍼 구성입니다. 클라이언트는 스니핑 프로세스를 사용하여 모든 노드를 자동으로 찾습니다. 기본적으로 비활성되어 있습니다.

true/ false

false

es:
  sniffer-tls-enabled:

Elasticsearch 클러스터를 스니핑할 때 TLS를 활성화하는 옵션입니다. 클라이언트는 스니핑 프로세스를 사용하여 모든 노드를 자동으로 찾습니다. 기본적으로 비활성화되어 있습니다.

true/ false

false

es:
  timeout:

쿼리에 사용되는 시간 제한입니다. 0으로 설정하면 시간 제한이 없습니다.

 

0s

es:
  username:

Elasticsearch에 필요한 사용자 이름입니다. 기본 인증은 지정된 경우 CA도 로드합니다. es.password도 참조하십시오.

  
es:
  password:

Elasticsearch에 필요한 암호입니다. es.username도 참조하십시오.

  
es:
  version:

주요 Elasticsearch 버전입니다. 지정하지 않으면 Elasticsearch에서 값을 자동으로 탐지합니다.

 

0

표 3.9. ES 데이터 복제 매개변수

매개변수설명기본값
es:
  num-replicas:

Elasticsearch의 인덱스당 복제본 수입니다.

 

1

es:
  num-shards:

Elasticsearch의 인덱스당 shard 수입니다.

 

5

표 3.10. ES 인덱스 구성 매개변수

매개변수설명기본값
es:
  create-index-templates:

true로 설정할 때 애플리케이션 시작 시 인덱스 템플릿을 자동으로 생성합니다. 템플릿이 수동으로 설치되면 false로 설정합니다.

true/ false

true

es:
  index-prefix:

Jaeger 인덱스의 선택적 접두사입니다. 예를 들어, 이 값을 "production"으로 설정하면 "production-jaeger-*"라는 인덱스가 생성됩니다.

  

표 3.11. ES 일괄 프로세서 구성 매개변수

매개변수설명기본값
es:
  bulk:
    actions:

대규모 프로세서가 디스크에 업데이트를 커밋하기 전에 큐에 추가할 수 있는 요청 수입니다.

 

1000

es:
  bulk:
    flush-interval:

다른 임계값에 관계없이 대규모 요청이 커밋된 후 time.Duration입니다. 대규모 프로세서 플러시 간격을 비활성화하려면 이를 0으로 설정합니다.

 

200ms

es:
  bulk:
    size:

대규모 프로세서가 디스크에 업데이트를 커밋하기 전에 대규모 요청이 수행할 수 있는 바이트 수입니다.

 

5000000

es:
  bulk:
    workers:

Elasticsearch에 대규모 요청을 수신하고 커밋할 수 있는 작업자 수입니다.

 

1

표 3.12. ES TLS 구성 매개변수

매개변수설명기본값
es:
  tls:
    ca:

원격 서버를 확인하는 데 사용되는 TLS 인증 기관(CA) 파일의 경로입니다.

 

기본적으로 시스템 신뢰 저장소를 사용합니다.

es:
  tls:
    cert:

이 프로세스를 원격 서버로 식별하는 데 사용되는 TLS 인증서 파일의 경로입니다.

  
es:
  tls:
    enabled:

원격 서버에 연결할 때 TLS(Transport Layer Security)를 활성화합니다. 기본적으로 비활성되어 있습니다.

true/ false

false

es:
  tls:
    key:

이 프로세스를 원격 서버에 식별하는 데 사용되는 TLS 개인 키 파일의 경로입니다.

  
es:
  tls:
    server-name:

원격 서버의 인증서에서 예상 TLS 서버 이름을 재정의합니다.

  
es:
  token-file:

전달자 토큰이 포함된 파일의 경로입니다. 이 플래그는 지정된 경우 CA(인증 기관) 파일도 로드합니다.

  

표 3.13. ES 아카이브 구성 매개변수

매개변수설명기본값
es-archive:
  bulk:
    actions:

대규모 프로세서가 디스크에 업데이트를 커밋하기 전에 큐에 추가할 수 있는 요청 수입니다.

 

0

es-archive:
  bulk:
    flush-interval:

다른 임계값에 관계없이 대규모 요청이 커밋된 후 time.Duration입니다. 대규모 프로세서 플러시 간격을 비활성화하려면 이를 0으로 설정합니다.

 

0s

es-archive:
  bulk:
    size:

대규모 프로세서가 디스크에 업데이트를 커밋하기 전에 대규모 요청이 수행할 수 있는 바이트 수입니다.

 

0

es-archive:
  bulk:
    workers:

Elasticsearch에 대규모 요청을 수신하고 커밋할 수 있는 작업자 수입니다.

 

0

es-archive:
  create-index-templates:

true로 설정할 때 애플리케이션 시작 시 인덱스 템플릿을 자동으로 생성합니다. 템플릿이 수동으로 설치되면 false로 설정합니다.

true/ false

false

es-archive:
  enabled:

추가 스토리지를 활성화합니다.

true/ false

false

es-archive:
  index-prefix:

Jaeger 인덱스의 선택적 접두사입니다. 예를 들어, 이 값을 "production"으로 설정하면 "production-jaeger-*"라는 인덱스가 생성됩니다.

  
es-archive:
  max-doc-count:

Elasticsearch 쿼리에서 반환하는 최대 문서 수입니다. 이는 집계에도 적용됩니다.

 

0

es-archive:
  max-num-spans:

[더 이상 사용되지 않음 - 향후 릴리스에서 제거되며 대신 es-archive.max-doc-count를 사용합니다.] Elasticsearch에서 쿼리당 한 번에 가져올 최대 기간 수입니다.

 

0

es-archive:
  max-span-age:

Elasticsearch에서 기간에 대한 최대 조회 수입니다.

 

0s

es-archive:
  num-replicas:

Elasticsearch의 인덱스당 복제본 수입니다.

 

0

es-archive:
  num-shards:

Elasticsearch의 인덱스당 shard 수입니다.

 

0

es-archive:
  password:

Elasticsearch에 필요한 암호입니다. es.username도 참조하십시오.

  
es-archive:
  server-urls:

Elasticsearch 서버의 쉼표로 구분된 목록입니다. 정규화된 URL로 지정해야 합니다(예: http://localhost:9200).

  
es-archive:
  sniffer:

Elasticsearch의 스니퍼 구성입니다. 클라이언트는 스니핑 프로세스를 사용하여 모든 노드를 자동으로 찾습니다. 기본적으로 비활성되어 있습니다.

true/ false

false

es-archive:
  sniffer-tls-enabled:

Elasticsearch 클러스터를 스니핑할 때 TLS를 활성화하는 옵션입니다. 클라이언트는 스니핑 프로세스를 사용하여 모든 노드를 자동으로 찾습니다. 기본적으로 비활성되어 있습니다.

true/ false

false

es-archive:
  timeout:

쿼리에 사용되는 시간 제한입니다. 0으로 설정하면 시간 제한이 없습니다.

 

0s

es-archive:
  tls:
    ca:

원격 서버를 확인하는 데 사용되는 TLS 인증 기관(CA) 파일의 경로입니다.

 

기본적으로 시스템 신뢰 저장소를 사용합니다.

es-archive:
  tls:
    cert:

이 프로세스를 원격 서버로 식별하는 데 사용되는 TLS 인증서 파일의 경로입니다.

  
es-archive:
  tls:
    enabled:

원격 서버에 연결할 때 TLS(Transport Layer Security)를 활성화합니다. 기본적으로 비활성되어 있습니다.

true/ false

false

es-archive:
  tls:
    key:

이 프로세스를 원격 서버에 식별하는 데 사용되는 TLS 개인 키 파일의 경로입니다.

  
es-archive:
  tls:
    server-name:

원격 서버의 인증서에서 예상 TLS 서버 이름을 재정의합니다.

  
es-archive:
  token-file:

전달자 토큰이 포함된 파일의 경로입니다. 이 플래그는 지정된 경우 CA(인증 기관) 파일도 로드합니다.

  
es-archive:
  username:

Elasticsearch에 필요한 사용자 이름입니다. 기본 인증은 지정된 경우 CA도 로드합니다. es-archive.password도 참조하십시오.

  
es-archive:
  version:

주요 Elasticsearch 버전입니다. 지정하지 않으면 Elasticsearch에서 값을 자동으로 탐지합니다.

 

0

볼륨 마운트가 있는 스토리지 예

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: https://quickstart-es-http.default.svc:9200
        index-prefix: my-prefix
        tls:
          ca: /es/certificates/ca.crt
    secretName: jaeger-secret
  volumeMounts:
    - name: certificates
      mountPath: /es/certificates/
      readOnly: true
  volumes:
    - name: certificates
      secret:
        secretName: quickstart-es-http-certs-public

다음 예는 시크릿에 저장된 볼륨 및 사용자/암호에서 마운트된 TLS CA 인증서가 포함된 외부 Elasticsearch 클러스터를 사용하는 Jaeger CR을 보여줍니다.

외부 Elasticsearch 예:

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: https://quickstart-es-http.default.svc:9200 1
        index-prefix: my-prefix
        tls: 2
          ca: /es/certificates/ca.crt
    secretName: jaeger-secret 3
  volumeMounts: 4
    - name: certificates
      mountPath: /es/certificates/
      readOnly: true
  volumes:
    - name: certificates
      secret:
        secretName: quickstart-es-http-certs-public

1
기본 네임스페이스에서 실행되는 Elasticsearch 서비스에 대한 URL입니다.
2
TLS 구성입니다. 이 경우 CA 인증서만 해당하지만 상호 TLS를 사용하는 경우 es.tls.key 및 es.tls.cert를 포함할 수 있습니다.
3
환경 변수 ES_PASSWORD 및 ES_USERNAME을 정의하는 시크릿입니다. kubectl create secret generic jaeger-secret --from-literal=ES_PASSWORD=changeme --from-literal=ES_USERNAME=elastic에서 생성됩니다.
4
모든 스토리지 구성 요소에 마운트되는 볼륨 마운트 및 볼륨입니다.

3.2.4.6. Jaeger 쿼리 구성 옵션

쿼리는 스토리지에서 추적을 검색하고 사용자 인터페이스에서 표시하도록 호스팅하는 서비스입니다.

표 3.14. Jaeger 쿼리 정의를 위해 Operator에서 사용하는 매개변수

매개변수설명기본값
spec:
  query:
    replicas:

생성할 쿼리 복제본 수를 지정합니다.

정수(예: 2)

 

표 3.15. 쿼리에 전달된 Jaeger 매개변수

매개변수설명기본값
spec:
  query:
    options: {}

쿼리 서비스를 정의하는 구성 옵션입니다.

  
options:
  log-level:

쿼리의 로깅 수준입니다.

가능한 값: trace, debug, info, warning, error, fatal, panic.

 
options:
  query:
    base-path:

모든 jaeger-query HTTP 경로의 기본 경로는 root 값이 아닌 값으로 설정할 수 있습니다(예: /jaeger는 모든 UI URL을 /jaeger로 시작합니다). 이는 리버스 프록시 뒤에서 jaeger-query를 실행할 때 유용할 수 있습니다.

/{path}

 

샘플 쿼리 구성

apiVersion: jaegertracing.io/v1
kind: "Jaeger"
metadata:
  name: "my-jaeger"
spec:
  strategy: allInOne
  allInOne:
    options:
      log-level: debug
      query:
        base-path: /jaeger

3.2.4.7. Jaeger Ingester 구성 옵션

Ingester는 Kafka 항목에서 읽고 다른 스토리지 백엔드(Elasticsearch)에 쓰는 서비스입니다. allInOne 또는 production 배포 전략을 사용하는 경우 Ingester 서비스를 구성할 필요가 없습니다.

표 3.16. Ingester에 전달된 Jaeger 매개변수

매개변수설명
spec:
  ingester:
    options: {}

Ingester 서비스를 정의하는 구성 옵션입니다.

 
options:
  deadlockInterval:

Ingester가 종료되기 전에 메시지를 기다려야 하는 간격(초 또는 분)을 지정합니다. 교착 상태 간격은 시스템이 초기화되는 동안 메시지가 없을 때 Ingester가 종료되는 것을 방지하기 위해 기본적으로 (0으로 설정) 비활성화됩니다.

분 및 초(예: 1m0s)입니다. 기본값은 0입니다.

options:
  kafka:
    consumer:
      topic:

topic 매개변수는 메시지를 생성하는 수집기와 메시지를 사용하는 ingester에서 사용하는 Kafka 구성을 식별합니다.

소비자의 레이블입니다. 예를 들면 jaeger-spans입니다.

kafka:
  consumer:
    brokers:

메시지를 사용하려면 Ingester에서 사용하는 Kafka 구성을 식별합니다.

브로커의 레이블은 예를 들면 my-cluster-kafka-brokers.kafka:9092입니다.

ingester:
  deadlockInterval:

Ingester가 종료되기 전에 메시지를 기다려야 하는 간격(초 또는 분)을 지정합니다. 교착 상태 간격은 시스템이 초기화되는 동안 메시지가 없을 때 Ingester가 종료되는 것을 방지하기 위해 기본적으로 (0으로 설정) 비활성화됩니다.

분 및 초(예: 1m0s)입니다. 기본값은 0입니다.

log-level:

Ingester의 로깅 수준입니다.

가능한 값: trace, debug, info, warning, error, fatal, panic.

maxReplicas:

Ingester를 자동 스케일링할 때 생성할 최대 복제본 수를 지정합니다.

정수(예: 100)입니다.

스트리밍 수집기 및 Ingester 예

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-streaming
spec:
  strategy: streaming
  collector:
    options:
      kafka:
        producer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092
  ingester:
    options:
      kafka:
        consumer:
          topic: jaeger-spans
          brokers: my-cluster-kafka-brokers.kafka:9092
      ingester:
        deadlockInterval: 5
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: http://elasticsearch:9200

3.2.4.7.1. 자동 스케일링을 위해 Ingester 구성
참고

Jaeger 1.20 이상에서만 자동 스케일링이 지원됩니다.

Ingester가 자동 스케일링되도록 구성할 수 있습니다. Ingester는 CPU 및/또는 메모리 소비에 따라 확장 또는 축소됩니다. 자동 스케일링하도록 Ingester를 구성하면 증가된 로드 시간 동안 Jaeger 환경이 확장되고 적은 리소스가 필요하면 축소되어 비용을 절감할 수 있습니다. autoscale 매개변수를 true로 설정하고 사용할 Ingester의 Pod를 예상하는 리소스의 적절한 값과 함께 .spec.ingester.maxReplicas의 값을 지정하여 자동 스케일링을 구성합니다. .spec.ingester.maxReplicas의 값을 설정하지 않으면 Operator가 100으로 설정합니다.

기본적으로 .spec.ingester.replicas 에 제공된 값이 없는 경우 Jaeger Operator는 Ingester에 대한 HPA(Horizontal Pod Autoscaler) 구성을 생성합니다. HPA에 대한 자세한 내용은 Kubernetes 문서를 참조하십시오.

다음은 자동 스케일링 구성의 예로, Ingester의 제한과 최대 복제본 수를 설정합니다.

Ingester 자동 스케일링 예

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-streaming
spec:
  strategy: streaming
  ingester:
    maxReplicas: 8
    resources:
      limits:
        cpu: 100m
        memory: 128Mi

3.2.5. 사이드카 삽입

OpenShift Jaeger는 애플리케이션의 Pod 내에서 프록시 사이드카를 사용하여 에이전트를 제공합니다. Jaeger Operator는 Jaeger 에이전트의 사이드카를 배포 워크로드에 삽입할 수 있습니다. 자동 사이드카 삽입을 활성화하거나 수동으로 관리할 수 있습니다.

3.2.5.1. 자동으로 사이드카 삽입

이 기능을 활성화하려면 주석 sidecar.jaegertracing.io/inject 집합을 문자열 true 또는 oc get jaegers에서 반환한 Jaeger 인스턴스 이름에 추가합니다. true를 지정하는 경우 배포와 동일한 네임스페이스에 대한 하나의 Jaeger 인스턴스만 있어야 합니다. 그러지 않으면 Operator는 사용할 Jaeger 인스턴스를 결정할 수 없습니다. 배포의 특정 Jaeger 인스턴스 이름은 해당 네임스페이스에 적용된 true보다 우선 순위가 높습니다.

다음 스니펫에서는 Jaeger 에이전트가 동일한 네임스페이스에서 사용할 수 있는 단일 Jaeger 인스턴스를 가리키는 사이드카를 삽입할 간단한 애플리케이션을 보여줍니다.

샘플 자동 사이드카 삽입

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  annotations:
    "sidecar.jaegertracing.io/inject": "true" 1
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: acme/myapp:myversion

사이드카가 삽입되면 Jaeger 에이전트가 localhost에서 기본 위치에 액세스할 수 있습니다.

3.2.5.2. 수동으로 사이드카 삽입

Deployments 이외의 컨트롤러 유형(예: StatefulSets, DaemonSets 등)의 경우 사양에 Jaeger 에이전트 사이드카를 수동으로 정의할 수 있습니다.

다음 스니펫에서는 Jaeger 에이전트 사이드카의 컨테이너 섹션에 포함할 수 있는 수동 정의를 보여줍니다.

StatefulSet의 사이드카 정의 예

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: example-statefulset
  namespace: example-ns
  labels:
    app: example-app
spec:

    spec:
      containers:
        - name: example-app
          image: acme/myapp:myversion
          ports:
            - containerPort: 8080
              protocol: TCP
        - name: jaeger-agent
          image: registry.redhat.io/distributed-tracing/jaeger-agent-rhel7:<version>
           # The agent version must match the operator version
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 5775
              name: zk-compact-trft
              protocol: UDP
            - containerPort: 5778
              name: config-rest
              protocol: TCP
            - containerPort: 6831
              name: jg-compact-trft
              protocol: UDP
            - containerPort: 6832
              name: jg-binary-trft
              protocol: UDP
            - containerPort: 14271
              name: admin-http
              protocol: TCP
          args:
            - --reporter.grpc.host-port=dns:///jaeger-collector-headless.example-ns:14250
            - --reporter.type=grpc

그런 다음 Jaeger 에이전트는 로컬 호스트에서 기본 위치에 액세스할 수 있습니다.

3.3. Jaeger 업그레이드

OLM(Operator Lifecycle Manager)은 클러스터에서 Operator의 설치, 업그레이드 및 역할 기반 액세스 제어(RBAC)를 제어합니다. OLM은 OpenShift Container Platform에서 기본적으로 실행됩니다. 사용 가능한 Operator 및 설치된 Operator의 업그레이드에 대한 OLM 쿼리입니다. OpenShift Container Platform에서 업그레이드를 처리하는 방법에 대한 자세한 내용은 Operator Lifecycle Manager 설명서를 참조하십시오.

Jaeger Operator에서 사용하는 업데이트 방식은 관리된 Jaeger 인스턴스를 Operator와 연결된 버전으로 업그레이드합니다. 새 버전의 Jaeger Operator가 설치될 때마다 Operator가 관리하는 모든 Jaeger 애플리케이션 인스턴스는 Operator의 버전으로 업그레이드됩니다. 예를 들어 버전 1.10이 설치되어 있고(Operator 및 백엔드 구성 요소 모두) Operator가 1.11로 업그레이드되는 경우 Operator 업그레이드가 완료되는 즉시 Operator는 Jaeger 인스턴스 실행을 검사하여 1.11로 업그레이드합니다.

3.4. Jaeger 제거

OpenShift Container Platform 클러스터에서 Jaeger를 제거하는 단계는 다음과 같습니다.

  1. 모든 Jaeger Pod를 종료합니다.
  2. Jaeger 인스턴스를 제거합니다.
  3. Jaeger Operator를 제거합니다.

3.4.1. 웹 콘솔을 사용하여 Jaeger 인스턴스 제거

참고

메모리 내 스토리지를 사용하는 인스턴스를 삭제하면 모든 데이터가 영구적으로 손실됩니다. Jaeger 인스턴스가 제거될 때 영구 스토리지(예: Elasticsearch)에 저장된 데이터는 삭제되지 않습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. Operators설치된 Operator로 이동합니다.
  3. 프로젝트 메뉴에서 Operator가 설치된 프로젝트의 이름을 선택합니다(예: jaeger-system).
  4. Jaeger Operator를 클릭합니다.
  5. Jaeger 탭을 클릭합니다.
  6. 인스턴스 옆에 있는 옵션 메뉴 kebab 를 클릭하고 Jaeger 삭제를 선택합니다.
  7. 확인 메시지에서 삭제를 클릭합니다.

3.4.2. CLI에서 Jaeger 인스턴스 제거

  1. OpenShift Container Platform CLI에 로그인합니다.

    $ oc login
  2. Jaeger 인스턴스를 표시하려면 명령을 실행합니다.

    $ oc get deployments -n <jaeger-project>

    Operator 이름에는 접미사 -operator가 있습니다. 다음 예는 Jaeger Operator 2개와 Jaeger 인스턴스 4개를 보여줍니다.

    $ oc get deployments -n jaeger-system

    출력은 다음과 유사합니다.

    NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
    elasticsearch-operator   1/1     1            1           93m
    jaeger-operator          1/1     1            1           49m
    jaeger-test              1/1     1            1           7m23s
    jaeger-test2             1/1     1            1           6m48s
    tracing1                 1/1     1            1           7m8s
    tracing2                 1/1     1            1           35m
  3. Jaeger 인스턴스를 제거하려면 명령을 실행합니다.

    $ oc delete jaeger <deployment-name> -n <jaeger-project>

    예를 들면 다음과 같습니다.

    $ oc delete jaeger tracing2 -n jaeger-system
  4. 삭제를 확인하려면 oc get deployment를 다시 실행합니다.

    $ oc get deployments -n <jaeger-project>

    예를 들면 다음과 같습니다.

    $ oc get deployments -n jaeger-system

    다음과 유사한 출력을 생성해야 합니다.

    NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
    elasticsearch-operator   1/1     1            1           94m
    jaeger-operator          1/1     1            1           50m
    jaeger-test              1/1     1            1           8m14s
    jaeger-test2             1/1     1            1           7m39s
    tracing1                 1/1     1            1           7m59s

3.4.3. Jaeger Operator 제거

프로세스

  1. 클러스터에서 Operator 삭제 에 대한 지침을 따르십시오.

    • Jaeger Operator를 제거합니다.
    • Jaeger Operator가 제거된 후 해당하는 경우 Elasticsearch Operator를 제거합니다.

법적 공지

Copyright © 2021 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.