Jaeger

OpenShift Container Platform 4.6

Jaeger のインストール、使用法、およびリリースノート

概要

本書では、OpenShift Container Platform で Jaeger を使用する方法について説明します。

第1章 Jaeger リリースノート

1.1. Jaeger の概要

サービスの所有者は、Jaeger を使用してサービスをインストルメント化し、サービスアーキテクチャーに関する洞察を得ることができます。Jaeger は、最新のクラウドネイティブ、マイクロサービスベースのアプリケーションにおいてコンポーネント間の対話のモニタリング、ネットワークプロファイリングおよびトラブルシューティングに使用できる、オープンソースの分散トレースプラットフォームです。

Jaeger を使用すると、以下の機能を実行できます。

  • 分散トランザクションの監視
  • パフォーマンスとレイテンシーの最適化
  • 根本原因分析の実行

Jaeger は特定のベンダーに依存しない OpenTracing API およびインストルメンテーションに基づいています。

1.2. 多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、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 により、問題の詳細と、利用可能な場合は問題の解決方法に関する情報が提供されます。

本書の改善が提案される場合や、エラーが見つかった場合は、Documentation コンポーネントの OpenShift Container Platform 製品に対して、Bugzilla レポートを送信してください。セクション名や OpenShift Container Platform バージョンなどの具体的な情報を提供してください。

1.3.1. OpenShift Jaeger 1.24.0 の新機能

本リリースの OpenShift Jaeger には、以下の新機能が含まれます。

  • Red Hat Elasticsearch Operator 5.0 および 5.1 のサポートを追加します。
  • Elasticsearch ロールオーバーサポートを追加します。
  • Elasticsearch 容認サポートを追加します。
  • Jaeger Operator を更新し、Strimzi Kafka Operator 0.23.0 のサポートが含まれるようにします。この更新に関連する既知の問題および回避策は、「既知の問題」のセクションで説明しています。
  • 本リリースでは、CVE(Common Vulnerabilities and Exposures)およびバグ修正に対応しています。

1.3.2. OpenShift Jaeger 1.20.4 の新機能

OpenShift Jaeger の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

1.3.3. OpenShift Jaeger 1.20.3 の新機能

OpenShift Jaeger の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

1.3.4. OpenShift Jaeger 1.20.2 の新機能

OpenShift Jaeger の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

1.3.5. OpenShift Jaeger 1.20.1 の新機能

OpenShift Jaeger の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

1.3.6. OpenShift Jaeger 1.20.0 の新機能

  • 本リリースの OpenShift Jaeger では、インストールされておらず、OpenShift Elasticsearch Operator によって作成される Elasticsearch インスタンスである「外部」 Elasticsearch クラスターを使用してトレースデータを保存するサポートが追加されました。
  • 今回のリリースで、Jaeger Collector および Ingester の自動スケーリングサポートが追加されました。

1.3.7. OpenShift Jaeger 1.17.9 の新機能

OpenShift Jaeger の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

1.3.8. OpenShift Jaeger 1.17.8 の新機能

OpenShift Jaeger の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

1.3.9. OpenShift Jaeger 1.17.7 の新機能

OpenShift Jaeger の本リリースでは、CVE (Common Vulnerabilities and Exposures) およびバグ修正に対応しています。

1.4. テクノロジープレビュー

重要

テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、https://access.redhat.com/ja/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 の既知の問題は以下のとおりです。

  • TRACING-2057 Kafka API が v1beta2 に更新され、Strimzi Kafka Operator 0.23.0 がサポートされるようになりました。ただし、この API バージョンは AMQ Streams 1.6.3 ではサポートされません。以下の環境がある場合、Jaeger サービスはアップグレードされず、新規の Jaeger サービスを作成したり、既存の Jaeger サービスを変更したりすることはできません。

    • Jaeger Operator チャネル: 1.17.x stable または 1.20.x stable
    • AMQ Streams Operator チャネル: amq-streams-1.6.x

      この問題を解決するには、AMQ Streams Operator のサブスクリプションチャネルを amq-streams-1.7.x または stable のいずれかに切り替えます。

  • BZ-1918920 Elasticsearch Pod は更新後に自動的に再起動しません。回避策として、Pod を手動で再起動します。
  • Trace-809 Jaeger Ingester には Kafka 2.3 との互換性がありません。Jaeger Ingester のインスタンスが複数あり、十分なトラフィックがある場合、リバランスメッセージがログに継続的に生成されます。これは、Kafka 2.3.1 で修正された Kafka 2.3 のリグレッションによって生じます。詳細は、Jaegertracing-1819 を参照してください。

1.6. Jaeger の修正された問題

  • TRACING-2009 Jaeger Operator が Strimzi Kafka Operator 0.23.0 のサポートを追加するように更新されました。
  • TRACING-1907: アプリケーション namespace に設定マップがないため、Jaeger エージェントサイドカーの挿入が失敗していました。設定マップは正しくない OwnerReference フィールドの設定により自動的に削除され、そのため、アプリケーション Pod は「ContainerCreating」ステージから移動しませんでした。誤った設定が削除されました。
  • TRACING-1725 は TRACING-1631 に対応しています。これはもう 1 つの修正であり、同じ名前だが異なる namespace にある複数の Jaeger 実稼働インスタンスがある場合に Elasticsearch 証明書を適切に調整することができるようになりました。BZ-1918920 も参照してください。
  • TRACING-1631 同じ名前を使用するが、異なる namespace 内にある複数の Jaeger 実稼働インスタンスを使用すると、Elasticsearch 証明書に問題が発生します。複数のサービスメッシュがインストールされている場合、すべての Jaeger Elasticsearch インスタンスは個別のシークレットではなく同じ Elasticsearch シークレットを持ち、これにより、OpenShift Elasticsearch Operator がすべての Elasticsearch クラスターと通信できなくなりました。
  • TRACING-1300 Istio サイドカーを使用する場合に、Agent と Collector 間の接続が失敗します。Jaeger Operator で有効にされた TLS 通信の更新は、Jaeger サイドカーエージェントと Jaeger Collector 間でデフォルトで提供されます。
  • TRACING-1208 Jaeger UI にアクセスする際に、認証の「500 Internal Error」が出されます。OAuth を使用して UI に対する認証を試行すると、oauth-proxy サイドカーが additionalTrustBundle でインストール時に定義されたカスタム CA バンドルを信頼しないため、500 エラーが出されます。
  • TRACING-1166 現時点で、Jaeger ストリーミングストラテジーを非接続環境で使用することはできません。Kafka クラスターがプロビジョニングされる際に、以下のエラーが出されます: Failed to pull image registry.redhat.io/amq7/amq-streams-kafka-24-rhel7@sha256:f9ceca004f1b7dccb3b82d9a8027961f9fe4104e0ed69752c0bdd8078b4a1076

第2章 Jaeger アーキテクチャー

2.1. Jaeger アーキテクチャー

ユーザーがアプリケーションでアクションを実行するたびに、応答を生成するために多数の異なるサービスに参加を要求する可能性のあるアーキテクチャーによって要求が実行されます。Jaeger を使用すると、分散トレースを実行できます。これは、アプリケーションを構成するさまざまなマイクロサービスによる要求のパスを記録します。

分散トレースは、さまざまな作業ユニットの情報を連携させるために使用される技術です。これは、分散トランザクションでのイベントのチェーン全体を理解するために、通常さまざまなプロセスまたはホストで実行されます。分散トレースを使用すると、開発者は大規模なマイクロサービスアーキテクチャーで呼び出しフローを可視化できます。これは、シリアル化、並行処理、およびレイテンシーのソースについての理解にも役立ちます。

Jaeger はマイクロサービスのスタック全体での個々の要求の実行を記録し、トレースとして表示します。トレース とは、システムにおけるデータ/実行パスです。エンドツーエンドトレースは、1 つ以上のスパンで構成されます。

スパンは、オペレーション名、オペレーションの開始時間および期間を持ち、タグやログを持つ可能性もある 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 の言語固有の実装です。それらは、手動または (Camel (Fuse)、Spring Boot (RHOAR)、MicroProfile (RHOAR/Thorntail)、Wildfly (EAP)、その他 OpenTracing にすでに統合されているものを含む) 各種の既存オープンソースフレームワークを使用して、分散トレース用にアプリケーションをインストルメント化するために使用できます。
  • Jaeger Agent (Server Queue、Processor Worker): Jaeger エージェントは、User Datagram Protocol (UDP) で送信されるスパンをリッスンするネットワークデーモンで、コレクターにバッチ処理や送信を実行します。このエージェントは、インストルメント化されたアプリケーションと同じホストに配置されることが意図されています。これは通常、Kubernetes などのコンテナー環境にサイドカーコンテナーを配置することによって実行されます。
  • Jaeger Collector (Queue、Worker): エージェントと同様に、コレクターはスパンを受信でき、これらを処理するために内部キューに配置できます。これにより、コレクターはスパンがストレージに移動するまで待機せずに、クライアント/エージェントにすぐに戻ることができます。
  • Storage (Data Store): コレクターには永続ストレージのバックエンドが必要です。Jaeger には、スパンストレージ用のプラグ可能なメカニズムがあります。本リリースでは、サポートされているストレージは Elasticsearch のみであることに注意してください。
  • Query (Query Service): Query は、ストレージからトレースを取得するサービスです。
  • Ingester (Ingester Service): Jaeger は Apache Kafka をコレクターと実際のバッキングストレージ (Elasticsearch) 間のバッファーとして使用できます。Ingester は、Kafka からデータを読み取り、別のストレージバックエンド (Elasticsearch) に書き込むサービスです。
  • Jaeger Console: Jaeger は、分散トレースデータを視覚化できるユーザーインターフェースを提供します。検索ページで、トレースを検索し、個別のトレースを構成するスパンの詳細を確認することができます。

第3章 Jaeger のインストール

3.1. Jaeger のインストール

Jaeger を OpenShift Container Platform にインストールするには、以下のいずれかの方法を使用できます。

  • Jaeger は、Red Hat OpenShift Service Mesh の一部としてインストールできます。Jaeger はデフォルトでサービスメッシュインストールに含まれています。サービスメッシュの一部として Jaeger をインストールするには、Red Hat Service Mesh のインストール手順に従います。Jaeger はサービスメッシュと同じ namespace にインストールされる必要があります。つまり、ServiceMeshControlPlane および Jaeger リソースは同じ namespace にある必要があります。
  • サービスメッシュをインストールする必要がない場合は、Jaeger Operator を使用して OpenShift Jaeger 自体をインストールできます。サービスメッシュなしで Jaeger をインストールするには、以下の手順を実行します。

3.1.1. 前提条件

OpenShift Jaeger をインストールするには、インストールアクティビティーを確認し、前提条件を満たしていることを確認してください。

3.1.2. Jaeger インストールの概要

OpenShift Jaeger のインストール手順は以下のとおりです。

  • 本書を確認し、デプロイメントストラテジーを確認します。
  • デプロイメントストラテジーに永続ストレージが必要な場合は、OperatorHub を使用して OpenShift Elasticsearch Operator をインストールします。
  • OperatorHub を使用して Jaeger Operator をインストールします。
  • Jaeger YAML ファイルをデプロイメントストラテジーをサポートするように変更します。
  • Jaeger の 1 つ以上のインスタンスを OpenShift Container Platform 環境にデプロイします。

3.1.3. OpenShift Elasticsearch Operator のインストール

デフォルトの Jaeger デプロイメントはインメモリーストレージを使用します。それは、Jaeger の評価、デモの提供、またはテスト環境での Jaeger の使用を目的としてすぐにインストールできるように設計されているためです。実稼働環境で Jaeger を使用する予定がある場合、永続ストレージのオプション (この場合は Elasticsearch) をインストールし、設定する必要があります。

前提条件

  • OpenShift Container Platform Web コンソールへのアクセスが可能です。
  • cluster-admin ロールを持つアカウントが必要です。({product-dedicated} を使用する場合) dedicated-admin ロールがあるアカウント。
警告

Operator のコミュニティーバージョンはインストールしないでください。コミュニティー Operator はサポートされていません。

注記

OpenShift クラスターロギングの一部として OpenShift Elasticsearch Operator がすでにインストールされている場合、OpenShift Elasticsearch Operator を再びインストールする必要はありません。Jaeger Operator はインストールされた OpenShift Elasticsearch Operator を使用して Elasticsearch インスタンスを作成します。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。({product-dedicated} を使用する場合) dedicated-admin ロールがあるアカウント。
  2. OperatorsOperatorHub に移動します。
  3. Elasticsearch とフィルターボックスに入力して、OpenShift Elasticsearch Operator を検索します。
  4. Red Hat が提供する OpenShift Elasticsearch Operator をクリックし、Operator についての情報を表示します。
  5. Install をクリックします。
  6. Install Operator ページの Installation Mode で、 All namespaces on the cluster (default) を選択します。これにより、Operator をクラスター内のすべてのプロジェクトで利用可能にできます。
  7. Installed Namespaces で、メニューから openshift-operators-redhat を選択します。

    注記

    Elasticsearch インストールでは、 Elasticsearch Operator に openshift-operators-redhat namespace が必要です。他の OpenShift Jaeger Operator は openshift-operators namespace にインストールされます。

  8. Update Channel として stable-5.x を選択します。
  9. Automatic Approval Strategy を選択します。

    注記

    手動の承認ストラテジーには、Operator のインストールおよびサブスクリプションプロセスを承認するための適切な認証情報を持つユーザーが必要です。

  10. Install をクリックします。
  11. Installed Operators ページで、openshift-operators-redhat プロジェクトを選択します。OpenShift Elasticsearch Operator が「InstallSucceeded」のステータスを表示するまで待機してから続行します。

3.1.4. Jaeger Operator のインストール

Jaeger をインストールするには、OperatorHub を使用して Jaeger Operator をインストールします。

デフォルトで、Operator は openshift-operators プロジェクトにインストールされます。

前提条件

  • OpenShift Container Platform Web コンソールへのアクセスが可能です。
  • cluster-admin ロールを持つアカウントが必要です。({product-dedicated} を使用する場合) dedicated-admin ロールがあるアカウント。
  • 永続ストレージが必要な場合、Jaeger Operator をインストールする前に OpenShift Elasticsearch Operator もインストールする必要があります。
警告

Operator のコミュニティーバージョンはインストールしないでください。コミュニティー Operator はサポートされていません。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。({product-dedicated} を使用する場合) dedicated-admin ロールがあるアカウント。
  2. OperatorsOperatorHub に移動します。
  3. Jaeger とフィルターに入力して、Jaeger Operator を検索します。
  4. Red Hat が提供する Jaeger Operator をクリックし、Operator についての情報を表示します。
  5. Install をクリックします。
  6. Install Operator ページで、stable 更新チャネルを選択します。これにより、新しいバージョンがリリースされると Jaeger が自動的に更新されます。1.17-stable などのメンテナンスチャネルを選択すると、そのバージョンのサポートサイクルの期間、バグ修正およびセキュリティーパッチが送信されます。
  7. All namespaces on the cluster(default) を選択します。これにより、Operator がデフォルトの openshift-operators プロジェクトにインストールされ、Operator はクラスター内のすべてのプロジェクトで利用可能になります。

    • Approval Strategy を選択します。Automatic または Manual の更新を選択できます。インストールされた Operator について自動更新を選択する場合、Operator の新規バージョンが利用可能になると、Operator Lifecycle Manager (OLM) は人の介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。手動更新を選択する場合、Operator の新規バージョンが利用可能になると、OLM は更新要求を作成します。クラスター管理者は、Operator が新規バージョンに更新されるように更新要求を手動で承認する必要があります。

      注記

      手動の承認ストラテジーには、Operator のインストールおよびサブスクリプションプロセスを承認するための適切な認証情報を持つユーザーが必要です。

  8. Install をクリックします。
  9. Subscription Overview ページで、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 (デフォルト): このストラテジーは、開発、テストおよびデモの目的で使用されることが意図されています。主なバックエンドコンポーネントである Agent、Collector、および Query サービスはすべて、インメモリーストレージを使用するように (デフォルトで) 設定された単一の実行可能ファイルにパッケージ化されます。

    注記

    インメモリーストレージには永続性がありません。つまり、Jaeger インスタンスがシャットダウンするか、再起動するか、または置き換えられると、トレースデータが失われます。各 Pod には独自のメモリーがあるため、インメモリーストレージはスケーリングできません。永続ストレージの場合、デフォルトのストレージとして Elasticsearch を使用する production または streaming ストラテジーを使用する必要があります。

  • production: production ストラテジーは、実稼働環境向けのストラテジーであり、トレースデータの長期の保存が重要となり、より拡張性および高可用性のあるアーキテクチャーも必要になります。そのため、バックエンドコンポーネントはそれぞれ別々にデプロイされます。エージェントは、インストルメント化されたアプリケーションのサイドカーとして挿入できます。Query および Collector サービスは、サポートされているストレージタイプ (現時点では Elasticsearch) で設定されます。これらの各コンポーネントの複数のインスタンスは、パフォーマンスと回復性を確保するために、必要に応じてプロビジョニングできます。
  • streaming: streaming ストラテジーは、Collector とバックエンドストレージ (Elasticsearch) 間に効果的に配置されるストリーミング機能を提供することで、production ストラテジーを増強する目的で設計されています。これにより、負荷の高い状況でバックエンドストレージに加わる圧力を軽減し、他のトレース処理後の機能がストリーミングプラットフォーム (AMQ Streams/ Kafka) から直接リアルタイムのスパンデータを利用できるようにします。

    注記

    ストリーミングストラテジーには、AMQ Streams 用の追加の Red Hat サブスクリプションが必要です。

注記

サービスメッシュの一部としてか、またはスタンドアロンのコンポーネントとして Jaeger をインストールし、使用するには 2 つの方法があります。Jaeger を Red Hat OpenShift Service Mesh の一部としてインストールしている場合、Service MeshControlPlane の一部として Jaeger を設定し、デプロイするか、または Jaeger を設定してから ServiceMeshControlPlane の Jaeger 設定を参照できます

3.2.1. Web コンソールからのデフォルト 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 Web コンソールにログインします。
  2. 新規プロジェクト (例: jaeger-system) を作成します。

    1. HomeProjects に移動します。
    2. Create Project をクリックします。
    3. Name フィールドに jaeger-system を入力します。
    4. Create をクリックします。
  3. OperatorsInstalled Operators に移動します。
  4. 必要な場合は、Project メニューから jaeger-system を選択します。Operator が新規プロジェクトにコピーされるまでに数分待機する必要がある場合があります。
  5. OpenShift Jaeger Operator をクリックします。Overview タブの Provided APIs で、Operator は単一リンクを提供します。
  6. JaegerCreate Instance をクリックします。
  7. Create Jaeger ページで、デフォルトを使用してインストールするには、 Create をクリックして Jaeger インスタンスを作成します。
  8. Jaegers ページで、Jaeger インスタンスの名前 (例: jaeger-all-in-one-inmemory) をクリックします。
  9. Jaeger Details ページで、Resources タブをクリックします。Pod のステータスが「Running」になるまで待機してから続行します。

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-in-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. Web コンソールからの Jaeger production ストラテジーのデプロイ

production デプロイメントストラテジーは、実稼働環境向けのストラテジーであり、トレースデータの長期の保存が重要となり、より拡張性および高可用性のあるアーキテクチャーも必要になります。

前提条件

  • OpenShift Elasticsearch Operator がインストールされている必要があります。
  • Jaeger Operator がインストールされている必要があります。
  • Jaeger インストールのカスタマイズ方法についての手順を確認します。
  • cluster-admin ロールを持つアカウントが必要です。

手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。
  2. 新規プロジェクト (例: jaeger-system) を作成します。

    1. HomeProjects に移動します。
    2. Create Project をクリックします。
    3. Name フィールドに jaeger-system を入力します。
    4. Create をクリックします。
  3. OperatorsInstalled Operators に移動します。
  4. 必要な場合は、Project メニューから jaeger-system を選択します。Operator が新規プロジェクトにコピーされるまでに数分待機する必要がある場合があります。
  5. Jaeger Operator をクリックします。Overview タブの Provided APIs で、Operator は単一リンクを提供します。
  6. JaegerCreate Instance をクリックします。
  7. Create Jaeger ページで、デフォルトの all-in-one yaml テキストを実稼働用の YAML 設定に置き換えます。以下は例になります。

    Elasticsearch を含む jaeger-production.yaml ファイルの例

    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. Create をクリックして Jaeger インスタンスを作成します。
  9. Jaegers ページで、Jaeger インスタンスの名前 (例: jaeger-prod-elasticsearch) をクリックします。
  10. Jaeger Details ページで、Resources タブをクリックします。すべての Pod のステータスが「Running」になるまで待機してから続行します。

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. Web コンソールからの Jaeger ストリーミングストラテジーのデプロイ

streaming デプロイメントストラテジーは、実稼働環境向けのストラテジーであり、トレースデータの長期の保存が重要となり、より拡張性および高可用性のあるアーキテクチャーも必要になります。

streaming ストラテジーは、Collector とストレージ (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 Web コンソールにログインします。
  2. 新規プロジェクト (例: jaeger-system) を作成します。

    1. HomeProjects に移動します。
    2. Create Project をクリックします。
    3. Name フィールドに jaeger-system を入力します。
    4. Create をクリックします。
  3. OperatorsInstalled Operators に移動します。
  4. 必要な場合は、Project メニューから jaeger-system を選択します。Operator が新規プロジェクトにコピーされるまでに数分待機する必要がある場合があります。
  5. Jaeger Operator をクリックします。Overview タブの Provided APIs で、Operator は単一リンクを提供します。
  6. JaegerCreate Instance をクリックします。
  7. Create 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. Create をクリックして Jaeger インスタンスを作成します。
  2. Jaegers ページで、 Jaeger インスタンスの名前 (例: jaeger-streaming) をクリックします。
  3. Jaeger Details ページで、Resources タブをクリックします。すべての Pod のステータスが「Running」になるまで待機してから続行します。

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 インスタンスには一意の名前が必要となり、挿入 (injection) のアノテーションはトレースデータを報告する必要のある Jaeger インスタンスの名前を明示的に指定する必要があります。
  • マルチテナントの実装があり、テナントが namespace で分離されている場合、Jaeger インスタンスを各テナント namespace にデプロイします。

    • デーモンセットとしての Jaeger エージェントはマルチテナントインストールまたは OpenShift Dedicated ではサポートされません。サイドカーとしての Jaeger エージェントは、これらのユースケースでサポートされる唯一の設定です。
  • Jaeger を Red Hat OpenShift Service Mesh の一部としてインストールする場合、Jaeger リソースを ServiceMeshControlPlane リソースと同じ namespace にインストールする必要があります。

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:

オブジェクトの作成時に使用する Application Program Interface のバージョン。

jaegertracing.io/v1

jaegertracing.io/v1

kind:

作成する Kubernetes オブジェクトの種類を定義します。

jaeger

 

metadata:

name 文字列、UID、およびオプションの namespace などのオブジェクトを一意に特定するのに役立つデータ。

 

OpenShift は UID を自動的に生成し、オブジェクトが作成されるプロジェクトの名前で namespace を完成します。

name:

オブジェクトの名前。

Jaeger インスタンスの名前。

jaeger-all-in-one-inmemory

spec:

作成するオブジェクトの仕様。

Jaeger インスタンスのすべての設定パラメーターが含まれます。(Jaeger コンポーネントすべてに) 共通する定義が必要な場合、これは仕様ノードで定義されます。定義が個別のコンポーネントに関連する場合、これは spec/<component> ノードの下に配置されます。

該当なし

strategy:

Jaeger デプロイメントストラテジー

allInOneproduction、または streaming

allInOne

allInOne:

allInOne イメージはエージェント、Collector、Query、Ingester, Jaeger UI を単一 Pod にデプロイするため、このデプロイメントの設定は、コンポーネント設定を allInOne パラメーターの下でネストする必要があります。

  

agent:

Jaeger エージェントを定義する設定オプション。

  

collector:

Jaeger Collector を定義する設定オプション。

  

sampling:

トレース用のサンプリングストラテジーを定義する設定オプション。

  

storage:

ストレージを定義する設定オプション。すべてのストレージ関連のオプションは、 allInOne または他のコンポーネントオプションではなく、storage に配置される必要があります。

  

query:

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 Collector 設定オプション

Jaeger Collector は、トレーサーによってキャプチャーされたスパンを受信し、production ストラテジーを使用する場合はそれらを永続ストレージ(Elasticsearch) に書き込み、streaming ストラテジーを使用する場合は AMQ Streams に書き込むコンポーネントです。

コレクターはステートレスであるため、Jaeger Collector のインスタンスの多くは並行して実行できます。Elasticsearch クラスターの場所を除き、Collector では設定がほとんど必要ありません。

表3.2 Operator によって使用される Jaeger Collector パラメーターを定義するためのパラメーター

パラメーター説明
collector:
  replicas:

作成する Collector レプリカの数を指定します。

整数 (例: 5)。

表3.3 Collector に渡される Jaeger パラメーター

パラメーター説明
spec:
 collector:
  options: {}

Jaeger Collector を定義する設定オプション。

 
options:
  collector:
    num-workers:

キューからプルするワーカーの数。

整数 (例: 50)。

options:
  collector:
    queue-size:

Collector キューのサイズ。

整数 (例: 2000)。

options:
  kafka:
    producer:
      topic: jaeger-spans

topic パラメーターは、コレクターによってメッセージを生成するために使用され、Ingester によってメッセージを消費するために使用される Kafka 設定を特定します。

プロデューサーのラベル

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

メッセージを生成するために Collector によって使用される Kafka 設定を特定します。ブローカーが指定されていない場合で、AMQ Streams 1.4.0+ がインストールされている場合、Jaeger は Kafka をセルフプロビジョニングします。

 
log-level:

コレクターのロギングレベル。

tracedebuginfowarningerrorfatalpanic

maxReplicas:

Collector の自動スケーリング時に作成するレプリカの最大数を指定します。

整数 (例: 100)。

num-workers:

キューからプルするワーカーの数。

整数 (例: 50)。

queue-size:

Collector キューのサイズ。

整数 (例: 2000)。

replicas:

作成する Collector レプリカの数を指定します。

整数 (例: 5)。

3.2.4.3.1. 自動スケーリングのための Collector の設定
注記

自動スケーリングは Jaeger 1.20 以降でのみサポートされます。

Collector を自動スケーリングできるように設定できます。Collector は CPU および/またはメモリーの消費に基づいてスケールアップまたはスケールダウンします。Collector を自動スケーリングできるように設定すると、Jaeger 環境は負荷が増加するとスケールアップし、必要なリソースが少なくなるとスケールダウンし、これによってコストを節約できます。自動スケーリングを設定するには、autoscale パラメーターを true に設定し、.spec.collector.maxReplicas の値を、Collector の Pod が消費することが予想されるリソースの妥当な値と共に指定します。.spec.collector.maxReplicas の値を設定しない場合、Operator はこれを 100 に設定します。

デフォルトで、.spec.collector.replicas の値が指定されていない場合、Jaeger Operator は Collector の Horizontal Pod Autoscaler (HPA) 設定を作成します。HPA についての詳細は、Kubernetes ドキュメント を参照してください。

以下は、Collector の制限とレプリカの最大数を設定する自動スケーリングの設定例です。

Collector の自動スケーリングの例

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 ライブラリーは以下のサンプラーをサポートします。

  • Probabilistic: サンプラーは、sampling.param プロパティーの値と等しいサンプリングの確率で、ランダムなサンプリングの意思決定を行います。たとえば、sampling.param=0.1 の場合に、約 10 の内 1 のトレースがサンプリングされます。
  • Rate Limiting: サンプラーは、リーキーバケット (leaky bucket) レートリミッターを使用して、トレースが一定のレートでサンプリングされるようにします。たとえば、sampling.param=2.0 の場合、1 秒あたり 2 トレースの割合で要求がサンプリングされます。

表3.4 Jaeger サンプリングのオプション

パラメーター説明デフォルト値
spec:
 sampling:
  options: {}
    default_strategy:
    service_strategy:

トレース用のサンプリングストラテジーを定義する設定オプション。

 

設定を指定しない場合、コレクターはすべてのサービスの確率 0.001 (0.1%) のデフォルトの確率的なサンプリングポリシーを返します。

default_strategy:
  type:
service_strategy:
  type:

使用するサンプリングストラテジー。(上記の説明を参照してください。)

有効な値は probabilistic、および ratelimiting です。

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 の下で Collector、Ingester、および Query サービスのストレージを設定します。これらの各コンポーネントの複数のインスタンスは、パフォーマンスと回復性を確保するために、必要に応じてプロビジョニングできます。

表3.5 Jaeger ストレージを定義するために Operator によって使用される一般的なストレージパラメーター

パラメーター説明デフォルト値
spec:
  storage:
    type:

デプロイメントに使用するストレージのタイプ。

memory または elasticsearchメモリーストレージは、Pod がシャットダウンした場合にデータが永続化されないため、開発、テスト、デモ、および概念検証用の環境にのみに適しています。実稼働環境については、Jaeger は永続ストレージの Elasticsearch をサポートします。

メモリー

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 は OpenShift Elasticsearch Operator を使用してカスタムリソースファイルの storage セクションで指定される設定に基づいて Elasticsearch クラスターを作成します。

制限

  • namespace ごとにセルフプロビジョニングされた Elasticsearch インスタンスがある Jaeger 1 つだけを使用できます。Elasticsearch クラスターは単一の Jaeger インスタンスの専用のクラスターになります。
  • namespace ごとに 1 つの Elasticsearch のみを使用できます。
注記

Elasticsearch を OpenShift ロギングの一部としてインストールしている場合、Jaeger Operator はインストールされた OpenShift Elasticsearch Operator を使用してストレージをプロビジョニングできます。

以下の設定パラメーターは、セルフプロビジョニングされた Elasticsearch インスタンスについてのものです。これは、OpenShift Elasticsearch Operator を使用して Jaeger Operator によって作成されるインスタンスです。セルフプロビジョニングされた Elasticsearch の設定オプションは、設定ファイルの spec:storage: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 シャードをクラスター内のデータノードにレプリケートする方法を定義します。指定されていない場合、Jaeger Operator はノード数に基づいて最も適切なレプリケーションを自動的に判別します。

ZeroRedundancy(レプリカシャードなし)、SingleRedundancy(レプリカシャード 1 つ)、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 gp2 のサイズは 5Gi です。値の指定がない場合、Jaeger は emptyDir を使用します。OpenShift Elasticsearch Operator は、Jaeger インスタンスで削除されない PersistentVolumeClaim および PersistentVolume をプロビジョニングします。同じ名前および namespace で Jaeger インスタンスを作成する場合は、同じボリュームをマウントできます。
3.2.4.5.2. 既存の Elasticsearch インスタンスへの接続

Jaeger でのストレージに、既存の Elasticsearch クラスター (Jaeger Operator で自動プロビジョニングされなかったインスタンス) を使用できます。これは、設定で既存クラスターの URL を spec:storage:options:es:server-urls 値に指定して実行します。

制限

  • Jaeger で OpenShift Jaeger ロギング Elasticsearch インスタンスを共有したり、再利用したりすることはできません。Elasticsearch クラスターは単一の Jaeger インスタンスの専用のクラスターになります。
注記

Red Hat は、外部 Elasticsearch インスタンスのサポートを提供しません。カスタマーポータル でテスト済み統合マトリックスを確認できます。

以下の設定パラメーターは、外部 Elasticsearch インスタンスとして知られる、既存の 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 は 2 つの内の小さい方の値を使用します。

 

10000

es:
  max-num-spans:

[非推奨: 今後のリリースで削除されます。代わりに es.max-doc-count を使用してください。] Elasticsearch のクエリーごとに、1 度にフェッチするスパンの最大数。es.max-num-spanses.max-doc-count の両方を設定する場合、Elasticsearch は 2 つの内の小さい方の値を使用します。

 

10000

es:
  max-span-age:

Elasticsearch のスパンについての最大ルックバック。

 

72h0m0s

es:
  sniffer:

Elasticsearch のスニファー設定。クライアントはスニファープロセスを使用してすべてのノードを自動的に検出します。デフォルトでは無効にされています。

true/ false

false

es:
  sniffer-tls-enabled:

Elasticsearch クラスターに対してスニッフィングする際に TLS を有効にするためのオプション。クライアントはスニッフィングプロセスを使用してすべてのノードを自動的に検索します。デフォルトでは無効にされています。

true/ false

false

es:
  timeout:

クエリーに使用されるタイムアウト。ゼロに設定するとタイムアウトはありません。

 

0s

es:
  username:

Elasticsearch で必要なユーザー名。Basic 認証は、指定されている場合に 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 のインデックスごとのシャード数。

 

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: この後に、他のしきい値に関係なく一括要求がコミットされます。バルクプロセッサーのフラッシュ間隔を無効にするには、これをゼロに設定します。

 

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) を有効にします。デフォルトでは無効にされています。

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: この後に、他のしきい値に関係なく一括要求がコミットされます。バルクプロセッサーのフラッシュ間隔を無効にするには、これをゼロに設定します。

 

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 のクエリーごとに、1 度にフェッチするスパンの最大数。

 

0

es-archive:
  max-span-age:

Elasticsearch のスパンについての最大ルックバック。

 

0s

es-archive:
  num-replicas:

Elasticsearch のインデックスごとのレプリカ数。

 

0

es-archive:
  num-shards:

Elasticsearch のインデックスごとのシャード数。

 

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:

クエリーに使用されるタイムアウト。ゼロに設定するとタイムアウトはありません。

 

0s

es-archive:
  tls:
    ca:

リモートサーバーの検証に使用される TLS 認証局 (CA) ファイルへのパス。

 

デフォルトではシステムトラストストアを使用します。

es-archive:
  tls:
    cert:

リモートサーバーに対するこのプロセスの特定に使用される TLS 証明書ファイルへのパス。

  
es-archive:
  tls:
    enabled:

リモートサーバーと通信する際に、トランスポート層セキュリティー (TLS) を有効にします。デフォルトでは無効にされています。

true/ false

false

es-archive:
  tls:
    key:

リモートサーバーに対するこのプロセスの特定に使用される TLS 秘密鍵ファイルへのパス。

  
es-archive:
  tls:
    server-name:

リモートサーバーの証明書の予想される TLS サーバー名を上書きします。

  
es-archive:
  token-file:

ベアラートークンが含まれるファイルへのパス。このフラグは、指定されている場合は認証局 (CA) ファイルも読み込みます。

  
es-archive:
  username:

Elasticsearch で必要なユーザー名。Basic 認証は、指定されている場合に 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
デフォルト namespace で実行されている Elasticsearch サービスへの URL。
2
TLS 設定。この場合、CA 証明書のみを使用できますが、相互 TLS を使用する場合に es.tls.key および es.tls.cert を含めることもできます。
3
環境変数 ES_PASSWORD および ES_USERNAME を定義するシークレット。Created by kubectl create secret generic jaeger-secret --from-literal=ES_PASSWORD=changeme --from-literal=ES_USERNAME=elastic
4
すべてのストレージコンポーネントにマウントされるボリュームのマウントとボリューム。

3.2.4.6. Jaeger Query 設定オプション

Query とは、ストレージからトレースを取得し、ユーザーインターフェースをホストしてそれらを表示するサービスです。

表3.14 Operator で使用される Jaeger Query を定義するためのパラメーター

パラメーター説明デフォルト値
spec:
  query:
    replicas:

作成する Query レプリカの数を指定します。

整数 (例: 2)

 

表3.15 Query に渡される Jaeger パラメーター

パラメーター説明デフォルト値
spec:
  query:
    options: {}

Query サービスを定義する設定オプション。

  
options:
  log-level:

Query のロギングレベル。

使用できる値は、tracedebuginfowarningerrorfatalpanic です。

 
options:
  query:
    base-path:

すべての jaeger-query HTTP ルートのベースパスは、root 以外の値に設定できます。たとえば、/jaeger ではすべての UI URL が /jaeger で開始するようになります。これは、リバースプロキシーの背後で jaeger-query を実行する場合に役立ちます。

/{path}

 

Query 設定の例

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 のロギングレベル。

使用できる値は、tracedebuginfowarningerrorfatalpanic です。

maxReplicas:

Ingester の自動スケーリング時に作成するレプリカの最大数を指定します。

整数 (例: 100)

ストリーミング Collector および 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 に設定し、.spec.ingester.maxReplicas の値を、Ingester の Pod が消費することが予想されるリソースの妥当な値と共に指定します。.spec.ingester.maxReplicas の値を設定しない場合、Operator はこれを 100 に設定します。

デフォルトで、.spec.ingester.replicas の値が指定されていない場合、Jaeger Operator は Ingester の Horizontal Pod Autoscaler (HPA) 設定を作成します。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 Agent サイドカーを Deployment ワークロードに挿入できます。自動のサイドカーコンテナー挿入を有効にしたり、手動で管理したりできます。

3.2.5.1. サイドカーコンテナーの自動挿入

この機能を有効にするには、文字列 true または oc get jaegers で返される Jaeger インスタンス名のいずれかに設定されるアノテーション sidecar.jaegertracing.io/inject を追加します。true を指定する場合、デプロイメントとして単一の Jaeger インスタンスのみが同じ namespace に存在する必要があります。そうでない場合に、Operator は使用する Jaeger インスタンスを判別することができません。デプロイメントの特定の Jaeger インスタンス名は、その namespace に適用される true よりも優先されます。

以下のスニペットは、サイドカーコンテナーを挿入する単純なアプリケーションを示しています。Jaeger エージェントは、同じ namespace で利用可能な単一の 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 以外のコントローラータイプ(StatefulSetsDaemonSet など)の場合、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 エージェントは localhost のデフォルトの場所でアクセスできます。

3.3. Jaeger のアップグレード

Operator Lifecycle Manager は、クラスター内の Operator のインストール、アップグレード、ロールベースのアクセス制御 (RBAC) を制御します。OLM はデフォルトで OpenShift Container Platform で実行されます。OLM は利用可能な Operator のクエリーやインストールされた Operator のアップグレードを実行します。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 にアップグレードします。

OpenShift Elasticsearch Operator の更新方法に関する詳細は、「 Updating OpenShift Logging 」を参照してください。

3.4. Jaeger の削除

OpenShift Container Platform クラスターから Jaeger を削除する手順は、以下のとおりです。

  1. Jaeger Pod をシャットダウンします。
  2. Jaeger インスタンスを削除します。
  3. Jaeger Operator を削除します。

3.4.1. Web コンソールを使用した Jaeger インスタンスの削除

注記

インメモリーストレージを使用するインスタンスを削除すると、すべてのデータが完全に失われます。永続ストレージ (Elasticsearch など)に保存されているデータは、Jaeger インスタンスが削除されても削除されません。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsInstalled Operators に移動します。
  3. Project メニューから Operator がインストールされているプロジェクトの名前 (例: jaeger-system) を選択します。
  4. Jaeger Operator をクリックします。
  5. Jaeger タブをクリックします。
  6. 削除するインスタンスの横にある Options メニュー kebab をクリックし、Delete Jaeger を選択します。
  7. 確認ウィンドウで Delete をクリックします。

3.4.2. CLI からの Jaeger インスタンスの削除

  1. OpenShift Container Platform CLI にログインします。

    $ oc login
  2. Jaeger インスタンスを表示するには、以下のコマンドを実行します。

    $ oc get deployments -n <jaeger-project>

    Operator の名前には、サフィックスの -operator が付きます。以下の例は、2 つの Jaeger Operator と 4 つの Jaeger インスタンスを示しています。

    $ 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 の削除後、(該当する場合は) OpenShift Elasticsearch Operator を削除します。