Menu Close
分散トレーシング
Jaeger のインストール、使用法、およびリリースノート
概要
前書き
第1章 分散トレースアーキテクチャー
1.1. Jaeger アーキテクチャー
ユーザーがアプリケーションでアクションを実行するたびに、応答を生成するために多数の異なるサービスに参加を要求する可能性のあるアーキテクチャーによって要求が実行されます。Jaeger を使用すると、分散トレースを実行できます。これは、アプリケーションを構成するさまざまなマイクロサービスによる要求のパスを記録します。
分散トレースは、さまざまな作業ユニットの情報を連携させるために使用される技術です。これは、分散トランザクションでのイベントのチェーン全体を理解するために、通常さまざまなプロセスまたはホストで実行されます。分散トレースを使用すると、開発者は大規模なマイクロサービスアーキテクチャーで呼び出しフローを可視化できます。これは、シリアル化、並行処理、およびレイテンシーのソースについての理解にも役立ちます。
Jaeger はマイクロサービスのスタック全体での個々の要求の実行を記録し、トレースとして表示します。トレース とは、システムにおけるデータ/実行パスです。エンドツーエンドトレースは、1 つ以上のスパンで構成されます。
スパンは、オペレーション名、オペレーションの開始時間および期間を持ち、タグやログを持つ可能性もある Jaeger の作業の論理単位を表しています。スパンは因果関係をモデル化するためにネスト化され、順序付けられます。
1.1.1. Jaeger の概要
サービスの所有者は、Jaeger を使用してサービスをインストルメント化し、サービスアーキテクチャーに関する洞察を得ることができます。Jaeger は、最新のクラウドネイティブ、マイクロサービスベースのアプリケーションにおいてコンポーネント間の対話のモニタリング、ネットワークプロファイリングおよびトラブルシューティングに使用できる、オープンソースの分散トレースプラットフォームです。
Jaeger を使用すると、以下の機能を実行できます。
- 分散トランザクションの監視
- パフォーマンスとレイテンシーの最適化
- 根本原因分析の実行
Jaeger は特定のベンダーに依存しない OpenTracing API およびインストルメンテーションに基づいています。
1.1.2. Jaeger の機能
Jaeger のトレース機能には以下の機能が含まれます。
- Kiali との統合: 適切に設定されている場合、Kiali コンソールから Jaeger データを表示できます。
- 高いスケーラビリティー: Jaeger バックエンドは、単一障害点がなく、ビジネスニーズに合わせてスケーリングできるように設計されています。
- 分散コンテキストの伝播: さまざまなコンポーネントからのデータをつなぎ、完全なエンドツーエンドトレースを作成します。
- Zipkin との後方互換性: Jaeger には、Zipkin のドロップイン置き換えで使用できるようにする API がありますが、本リリースでは、Red Hat は Zipkin の互換性をサポートしていません。
1.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 は、分散トレースデータを視覚化できるユーザーインターフェースを提供します。検索ページで、トレースを検索し、個別のトレースを構成するスパンの詳細を確認することができます。
第2章 分散トレースのインストール
2.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 をインストールするには、以下の手順を実行します。
2.1.1. 前提条件
OpenShift Jaeger をインストールするには、インストールアクティビティーを確認し、前提条件を満たしていることを確認してください。
- お使いの Red Hat アカウントに有効な OpenShift Container Platform サブスクリプションを用意します。サブスクリプションをお持ちでない場合は、営業担当者にお問い合わせください。
- 「OpenShift Container Platform 4.9 の概要」を確認します。
OpenShift Container Platform 4.9 をインストールします。
-
OpenShift Container Platform バージョンに一致する OpenShift CLI(
oc
)のバージョンをインストールし、これをパスに追加します。 -
cluster-admin
ロールを持つアカウントが必要です。
2.1.2. Jaeger インストールの概要
OpenShift Jaeger のインストール手順は以下のとおりです。
- 本書を確認し、デプロイメントストラテジーを確認します。
- デプロイメントストラテジーに永続ストレージが必要な場合は、OperatorHub を使用して OpenShift Elasticsearch Operator をインストールします。
- OperatorHub を使用して Jaeger Operator をインストールします。
- Jaeger YAML ファイルをデプロイメントストラテジーをサポートするように変更します。
- Jaeger の 1 つ以上のインスタンスを OpenShift Container Platform 環境にデプロイします。
2.1.3. OpenShift Elasticsearch Operator のインストール
デフォルトの Jaeger デプロイメントはインメモリーストレージを使用します。それは、Jaeger の評価、デモの提供、またはテスト環境での Jaeger の使用を目的としてすぐにインストールできるように設計されているためです。実稼働環境で Jaeger を使用する予定がある場合、永続ストレージのオプション (この場合は Elasticsearch) をインストールし、設定する必要があります。
前提条件
- OpenShift Container Platform Web コンソールへのアクセスが可能です。
-
cluster-admin
ロールを持つアカウントが必要です。({product-dedicated} を使用する場合)dedicated-admin
ロールがあるアカウント。
Operator のコミュニティーバージョンはインストールしないでください。コミュニティー Operator はサポートされていません。
OpenShift Logging の一部として OpenShift Elasticsearch Operator がすでにインストールされている場合、OpenShift Elasticsearch Operator を再びインストールする必要はありません。Jaeger Operator はインストールされた OpenShift Elasticsearch Operator を使用して Elasticsearch インスタンスを作成します。
手順
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。({product-dedicated} を使用する場合)dedicated-admin
ロールがあるアカウント。 - Operators → OperatorHub に移動します。
- Elasticsearch とフィルターボックスに入力して、OpenShift Elasticsearch Operator を検索します。
- Red Hat が提供する OpenShift Elasticsearch Operator をクリックし、Operator についての情報を表示します。
- Install をクリックします。
- Install Operator ページの Installation Mode で、 All namespaces on the cluster (default) を選択します。これにより、Operator をクラスター内のすべてのプロジェクトで利用可能にできます。
Installed Namespaces で、メニューから openshift-operators-redhat を選択します。
注記Elasticsearch インストールでは、 Elasticsearch Operator に openshift-operators-redhat namespace が必要です。他の OpenShift Jaeger Operator は
openshift-operators
namespace にインストールされます。- Update Channel として stable-5.x を選択します。
Automatic Approval Strategy を選択します。
注記手動の承認ストラテジーには、Operator のインストールおよびサブスクリプションプロセスを承認するための適切な認証情報を持つユーザーが必要です。
- Install をクリックします。
-
Installed Operators ページで、
openshift-operators-redhat
プロジェクトを選択します。OpenShift Elasticsearch Operator が「InstallSucceeded」のステータスを表示するまで待機してから続行します。
2.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 はサポートされていません。
手順
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。({product-dedicated} を使用する場合)dedicated-admin
ロールがあるアカウント。 - Operators → OperatorHub に移動します。
- Jaeger とフィルターに入力して、Jaeger Operator を検索します。
- Red Hat が提供する Jaeger Operator をクリックし、Operator についての情報を表示します。
- Install をクリックします。
- Install Operator ページで、stable 更新チャネルを選択します。これにより、新しいバージョンがリリースされると Jaeger が自動的に更新されます。1.17-stable などのメンテナンスチャネルを選択すると、そのバージョンのサポートサイクルの期間、バグ修正およびセキュリティーパッチが送信されます。
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 のインストールおよびサブスクリプションプロセスを承認するための適切な認証情報を持つユーザーが必要です。
- Install をクリックします。
-
Subscription Overview ページで、
openshift-operators
プロジェクトを選択します。Jaeger Operator に「InstallSucceeded」のステータスが表示されるまで待機してから続行します。
2.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 の一部としてインストールしている場合、 ServiceMeshControlPlane の一部として Jaeger を設定し、デプロイするか、または Jaeger を設定してから ServiceMeshControlPlane の Jaeger 設定を参照できます。
2.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 ではサポートされていません。
手順
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。 新規プロジェクト (例:
jaeger-system
) を作成します。- Home → Projects に移動します。
- Create Project をクリックします。
-
Name フィールドに
jaeger-system
を入力します。 - Create をクリックします。
- Operators → Installed Operators に移動します。
-
必要な場合は、Project メニューから
jaeger-system
を選択します。Operator が新規プロジェクトにコピーされるまでに数分待機する必要がある場合があります。 - OpenShift Jaeger Operator をクリックします。Overview タブの Provided APIs で、Operator は単一リンクを提供します。
- Jaeger で Create Instance をクリックします。
- Create Jaeger ページで、デフォルトを使用してインストールするには、 Create をクリックして Jaeger インスタンスを作成します。
-
Jaegers ページで、Jaeger インスタンスの名前 (例:
jaeger-all-in-one-inmemory
) をクリックします。 - Jaeger Details ページで、Resources タブをクリックします。Pod のステータスが「Running」になるまで待機してから続行します。
2.2.1.1. CLI からのデフォルト Jaeger のデプロイ
以下の手順に従って、コマンドラインから Jaeger のインスタンスを作成します。
前提条件
- OpenShift Jaeger Operator がインストールされ、検証済みです。
-
OpenShift Container Platform バージョンに一致する OpenShift CLI (
oc
) へのアクセスが可能です。 -
cluster-admin
ロールを持つアカウントが必要です。
手順
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。$ oc login https://{HOSTNAME}:8443
jaeger-system
という名前の新規プロジェクトを作成します。$ oc new-project jaeger-system
以下のテキストが含まれる
jaeger.yaml
という名前のカスタムリソースファイルを作成します。例: jaeger-all-in-one.yaml
apiVersion: jaegertracing.io/v1 kind: Jaeger metadata: name: jaeger-all-in-one-inmemory
以下のコマンドを実行して Jaeger をデプロイします。
$ oc create -n jaeger-system -f jaeger.yaml
以下のコマンドを実行して、インストールプロセス時の 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
2.2.2. Web コンソールからの Jaeger production ストラテジーのデプロイ
production
デプロイメントストラテジーは、実稼働環境向けのストラテジーであり、トレースデータの長期の保存が重要となり、より拡張性および高可用性のあるアーキテクチャーも必要になります。
前提条件
- OpenShift Elasticsearch Operator がインストールされている必要があります。
- Jaeger Operator がインストールされている必要があります。
- Jaeger インストールのカスタマイズ方法についての手順を確認します。
-
cluster-admin
ロールを持つアカウントが必要です。
手順
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。 新規プロジェクト (例:
jaeger-system
) を作成します。- Home → Projects に移動します。
- Create Project をクリックします。
-
Name フィールドに
jaeger-system
を入力します。 - Create をクリックします。
- Operators → Installed Operators に移動します。
-
必要な場合は、Project メニューから
jaeger-system
を選択します。Operator が新規プロジェクトにコピーされるまでに数分待機する必要がある場合があります。 - Jaeger Operator をクリックします。Overview タブの Provided APIs で、Operator は単一リンクを提供します。
- Jaeger で Create Instance をクリックします。
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 * * * *'
- Create をクリックして Jaeger インスタンスを作成します。
-
Jaegers ページで、Jaeger インスタンスの名前 (例:
jaeger-prod-elasticsearch
) をクリックします。 - Jaeger Details ページで、Resources タブをクリックします。すべての Pod のステータスが「Running」になるまで待機してから続行します。
2.2.2.1. CLI からの Jaeger 実稼働環境のデプロイ
以下の手順に従って、コマンドラインから Jaeger のインスタンスを作成します。
前提条件
- OpenShift Jaeger Operator がインストールされ、検証済みです。
-
OpenShift CLI (
oc
) へのアクセスが可能です。 -
cluster-admin
ロールを持つアカウントが必要です。
手順
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。$ oc login https://{HOSTNAME}:8443
jaeger-system
という名前の新規プロジェクトを作成します。$ oc new-project jaeger-system
-
直前の手順のサンプルファイルのテキストが含まれる
jaeger-production.yaml
という名前のカスタムリソースファイルを作成します。 以下のコマンドを実行して Jaeger をデプロイします。
$ oc create -n jaeger-system -f jaeger-production.yaml
以下のコマンドを実行して、インストールプロセス時の 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
2.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 ではサポートされていません。
手順
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。 新規プロジェクト (例:
jaeger-system
) を作成します。- Home → Projects に移動します。
- Create Project をクリックします。
-
Name フィールドに
jaeger-system
を入力します。 - Create をクリックします。
- Operators → Installed Operators に移動します。
-
必要な場合は、Project メニューから
jaeger-system
を選択します。Operator が新規プロジェクトにコピーされるまでに数分待機する必要がある場合があります。 - Jaeger Operator をクリックします。Overview タブの Provided APIs で、Operator は単一リンクを提供します。
- Jaeger で Create Instance をクリックします。
-
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
- Create をクリックして Jaeger インスタンスを作成します。
-
Jaegers ページで、 Jaeger インスタンスの名前 (例:
jaeger-streaming
) をクリックします。 - Jaeger Details ページで、Resources タブをクリックします。すべての Pod のステータスが「Running」になるまで待機してから続行します。
2.2.3.1. CLI からの Jaeger ストリーミングのデプロイ
以下の手順に従って、コマンドラインから Jaeger のインスタンスを作成します。
前提条件
- OpenShift Jaeger Operator がインストールされ、検証済みです。
-
OpenShift CLI (
oc
) へのアクセスが可能です。 -
cluster-admin
ロールを持つアカウントが必要です。
手順
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。$ oc login https://{HOSTNAME}:8443
jaeger-system
という名前の新規プロジェクトを作成します。$ oc new-project jaeger-system
-
直前の手順のサンプルファイルのテキストが含まれる
jaeger-streaming.yaml
という名前のカスタムリソースファイルを作成します。 以下のコマンドを実行して Jaeger をデプロイします。
$ oc create -n jaeger-system -f jaeger-streaming.yaml
以下のコマンドを実行して、インストールプロセス時の 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
2.2.4. Jaeger デプロイメントのカスタマイズ
2.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 にインストールする必要があります。
2.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: {}
表2.1 Jaeger パラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
| オブジェクトの作成時に使用する Application Program Interface のバージョン。 |
|
|
| 作成する Kubernetes オブジェクトの種類を定義します。 |
| |
|
|
OpenShift Container Platform は | |
| オブジェクトの名前。 | Jaeger インスタンスの名前。 |
|
| 作成するオブジェクトの仕様。 | Jaeger インスタンスのすべての設定パラメーターが含まれます。(Jaeger コンポーネントすべてに) 共通する定義が必要な場合、これは仕様ノードで定義されます。定義が個別のコンポーネントに関連する場合、これは spec/<component> ノードの下に配置されます。 | 該当なし |
| Jaeger デプロイメントストラテジー |
|
|
| allInOne イメージはエージェント、Collector、Query、Ingester, Jaeger UI を単一 Pod にデプロイするため、このデプロイメントの設定は、コンポーネント設定を allInOne パラメーターの下でネストする必要があります。 | ||
| Jaeger エージェントを定義する設定オプション。 | ||
| Jaeger Collector を定義する設定オプション。 | ||
| トレース用のサンプリングストラテジーを定義する設定オプション。 | ||
|
ストレージを定義する設定オプション。すべてのストレージ関連のオプションは、 | ||
| Query サービスを定義する設定オプション。 | ||
| Ingester サービスを定義する設定オプション。 |
以下の YAML サンプルは、デフォルト設定を使用して Jaeger インスタンスを作成するための最小要件です。
最小要件の jaeger-all-in-one.yaml の例
apiVersion: jaegertracing.io/v1 kind: Jaeger metadata: name: jaeger-all-in-one-inmemory
2.2.4.3. Jaeger Collector 設定オプション
Jaeger Collector は、トレーサーによってキャプチャーされたスパンを受信し、production
ストラテジーを使用する場合はそれらを永続ストレージ(Elasticsearch) に書き込み、streaming
ストラテジーを使用する場合は AMQ Streams に書き込むコンポーネントです。
コレクターはステートレスであるため、Jaeger Collector のインスタンスの多くは並行して実行できます。Elasticsearch クラスターの場所を除き、Collector では設定がほとんど必要ありません。
表2.2 Operator によって使用される Jaeger Collector パラメーターを定義するためのパラメーター
パラメーター | 詳細 | 値 |
---|---|---|
collector: replicas: | 作成する Collector レプリカの数を指定します。 |
整数 (例: |
表2.3 Collector に渡される Jaeger パラメーター
パラメーター | 詳細 | 値 |
---|---|---|
spec: collector: options: {} | Jaeger Collector を定義する設定オプション。 | |
options: collector: num-workers: | キューからプルするワーカーの数。 |
整数 (例: |
options: collector: queue-size: | Collector キューのサイズ。 |
整数 (例: |
options: kafka: producer: topic: jaeger-spans |
| プロデューサーのラベル |
kafka: producer: brokers: my-cluster-kafka-brokers.kafka:9092 | メッセージを生成するために Collector によって使用される Kafka 設定を特定します。ブローカーが指定されていない場合で、AMQ Streams 1.4.0+ がインストールされている場合、Jaeger は Kafka をセルフプロビジョニングします。 | |
log-level: | コレクターのロギングレベル。 |
|
maxReplicas: | Collector の自動スケーリング時に作成するレプリカの最大数を指定します。 |
整数 (例: |
num-workers: | キューからプルするワーカーの数。 |
整数 (例: |
queue-size: | Collector キューのサイズ。 |
整数 (例: |
replicas: | 作成する Collector レプリカの数を指定します。 |
整数 (例: |
2.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
2.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 トレースの割合で要求がサンプリングされます。
表2.4 Jaeger サンプリングのオプション
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
spec: sampling: options: {} default_strategy: service_strategy: | トレース用のサンプリングストラテジーを定義する設定オプション。 | 設定を指定しない場合、コレクターはすべてのサービスの確率 0.001 (0.1%) のデフォルトの確率的なサンプリングポリシーを返します。 | |
default_strategy: type: service_strategy: type: | 使用するサンプリングストラテジー。(上記の説明を参照してください。) |
有効な値は |
|
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
2.2.4.5. Jaeger ストレージ設定のオプション
spec.storage
の下で Collector、Ingester、および Query サービスのストレージを設定します。これらの各コンポーネントの複数のインスタンスは、パフォーマンスと回復性を確保するために、必要に応じてプロビジョニングできます。
表2.5 Jaeger ストレージを定義するために Operator によって使用される一般的なストレージパラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
spec: storage: type: | デプロイメントに使用するストレージのタイプ。 |
|
|
storage: secretname: |
シークレットの名前 (例: | 該当なし | |
storage: options: {} | ストレージを定義する設定オプション。 |
表2.6 Elasticsearch インデックスクリーナーのパラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
storage: esIndexCleaner: enabled: | Elasticsearch ストレージを使用する場合、デフォルトでジョブが作成され、古いトレースをインデックスからクリーンアップします。このパラメーターは、インデックスクリーナージョブを有効または無効にします。 |
|
|
storage: esIndexCleaner: numberOfDays: | インデックスの削除を待機する日数。 | 整数値 |
|
storage: esIndexCleaner: schedule: | Elasticsearch インデックスを消去する頻度についてのスケジュールを定義します。 | cron 式 | "55 23 * * *" |
2.2.4.5.1. Elasticsearch インスタンスの自動プロビジョニング
storage:type
が elasticsearch
に設定されているが、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
の下で指定します。
表2.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 はノード数に基づいて最も適切なレプリケーションを自動的に判別します。 |
| |
各 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 インスタンスを作成する場合は、同じボリュームをマウントできます。
2.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 の設定オプションを指定します。
表2.8 汎用 ES 設定パラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
es: server-urls: | Elasticsearch インスタンスの URL。 | Elasticsearch サーバーの完全修飾ドメイン名。 | |
es: max-doc-count: |
Elasticsearch クエリーから返す最大ドキュメント数。これは集約にも適用されます。 | 10000 | |
es: max-num-spans: |
[非推奨: 今後のリリースで削除されます。代わりに | 10000 | |
es: max-span-age: | Elasticsearch のスパンについての最大ルックバック。 | 72h0m0s | |
es: sniffer: | Elasticsearch のスニファー設定。クライアントはスニファープロセスを使用してすべてのノードを自動的に検出します。デフォルトでは無効にされています。 |
|
|
es: sniffer-tls-enabled: | Elasticsearch クラスターに対してスニッフィングする際に TLS を有効にするためのオプション。クライアントはスニッフィングプロセスを使用してすべてのノードを自動的に検索します。デフォルトでは無効にされています。 |
|
|
es: timeout: | クエリーに使用されるタイムアウト。ゼロに設定するとタイムアウトはありません。 | 0s | |
es: username: |
Elasticsearch で必要なユーザー名。Basic 認証は、指定されている場合に CA も読み込みます。 | ||
es: password: |
Elasticsearch で必要なパスワード。 | ||
es: version: | 主要な Elasticsearch バージョン。指定されていない場合、値は Elasticsearch から自動検出されます。 | 0 |
表2.9 ES データレプリケーションパラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
es: num-replicas: | Elasticsearch のインデックスごとのレプリカ数。 | 1 | |
es: num-shards: | Elasticsearch のインデックスごとのシャード数。 | 5 |
表2.10 ES インデックス設定パラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
es: create-index-templates: |
|
|
|
es: index-prefix: | Jaeger インデックスのオプションのプレフィックス。たとえば、これを「production」に設定すると、「production-jaeger-*」という名前のインデックスが作成されます。 |
表2.11 ES バルクプロセッサー設定パラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
es: bulk: actions: | バルクプロセッサーがディスクへの更新のコミットを決定する前にキューに追加できる要求の数。 | 1000 | |
es: bulk: flush-interval: |
| 200ms | |
es: bulk: size: | バルクプロセッサーがディスクへの更新をコミットするまでに一括要求が発生する可能性のあるバイト数。 | 5000000 | |
es: bulk: workers: | 一括要求を受信し、Elasticsearch にコミットできるワーカーの数。 | 1 |
表2.12 ES TLS 設定パラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
es: tls: ca: | リモートサーバーの検証に使用される TLS 認証局 (CA) ファイルへのパス。 | デフォルトではシステムトラストストアを使用します。 | |
es: tls: cert: | リモートサーバーに対するこのプロセスの特定に使用される TLS 証明書ファイルへのパス。 | ||
es: tls: enabled: | リモートサーバーと通信する際に、トランスポート層セキュリティー (TLS) を有効にします。デフォルトでは無効にされています。 |
|
|
es: tls: key: | リモートサーバーに対するこのプロセスの特定に使用される TLS 秘密鍵ファイルへのパス。 | ||
es: tls: server-name: | リモートサーバーの証明書の予想される TLS サーバー名を上書きします。 | ||
es: token-file: | ベアラートークンが含まれるファイルへのパス。このフラグは、指定されている場合は認証局 (CA) ファイルも読み込みます。 |
表2.13 ES アーカイブ設定パラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
es-archive: bulk: actions: | バルクプロセッサーがディスクへの更新のコミットを決定する前にキューに追加できる要求の数。 | 0 | |
es-archive: bulk: flush-interval: |
| 0s | |
es-archive: bulk: size: | バルクプロセッサーがディスクへの更新をコミットするまでに一括要求が発生する可能性のあるバイト数。 | 0 | |
es-archive: bulk: workers: | 一括要求を受信し、Elasticsearch にコミットできるワーカーの数。 | 0 | |
es-archive: create-index-templates: |
|
|
|
es-archive: enabled: | 追加ストレージを有効にします。 |
|
|
es-archive: index-prefix: | Jaeger インデックスのオプションのプレフィックス。たとえば、これを「production」に設定すると、「production-jaeger-*」という名前のインデックスが作成されます。 | ||
es-archive: max-doc-count: | Elasticsearch クエリーから返す最大ドキュメント数。これは集約にも適用されます。 | 0 | |
es-archive: max-num-spans: |
[非推奨: 今後のリリースで削除されます。代わりに | 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-archive: server-urls: |
Elasticsearch サーバーのコンマ区切りの一覧。完全修飾 URL(例: | ||
es-archive: sniffer: | Elasticsearch のスニファー設定。クライアントはスニファープロセスを使用してすべてのノードを自動的に検出します。デフォルトでは無効にされています。 |
|
|
es-archive: sniffer-tls-enabled: | Elasticsearch クラスターに対してスニッフィングする際に TLS を有効にするためのオプション。クライアントはスニッフィングプロセスを使用してすべてのノードを自動的に検索します。デフォルトでは無効にされています。 |
|
|
es-archive: timeout: | クエリーに使用されるタイムアウト。ゼロに設定するとタイムアウトはありません。 | 0s | |
es-archive: tls: ca: | リモートサーバーの検証に使用される TLS 認証局 (CA) ファイルへのパス。 | デフォルトではシステムトラストストアを使用します。 | |
es-archive: tls: cert: | リモートサーバーに対するこのプロセスの特定に使用される TLS 証明書ファイルへのパス。 | ||
es-archive: tls: enabled: | リモートサーバーと通信する際に、トランスポート層セキュリティー (TLS) を有効にします。デフォルトでは無効にされています。 |
|
|
es-archive: tls: key: | リモートサーバーに対するこのプロセスの特定に使用される TLS 秘密鍵ファイルへのパス。 | ||
es-archive: tls: server-name: | リモートサーバーの証明書の予想される TLS サーバー名を上書きします。 | ||
es-archive: token-file: | ベアラートークンが含まれるファイルへのパス。このフラグは、指定されている場合は認証局 (CA) ファイルも読み込みます。 | ||
es-archive: username: |
Elasticsearch で必要なユーザー名。Basic 認証は、指定されている場合に CA も読み込みます。 | ||
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
- すべてのストレージコンポーネントにマウントされるボリュームのマウントとボリューム。
2.2.4.6. Jaeger Query 設定オプション
Query とは、ストレージからトレースを取得し、ユーザーインターフェースをホストしてそれらを表示するサービスです。
表2.14 Operator で使用される Jaeger Query を定義するためのパラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
spec: query: replicas: | 作成する Query レプリカの数を指定します。 |
整数 (例: |
表2.15 Query に渡される Jaeger パラメーター
パラメーター | 詳細 | 値 | デフォルト値 |
---|---|---|---|
spec: query: options: {} | Query サービスを定義する設定オプション。 | ||
options: log-level: | Query のロギングレベル。 |
使用できる値は、 | |
options: query: base-path: |
すべての jaeger-query HTTP ルートのベースパスは、root 以外の値に設定できます。たとえば、 | /{path} |
Query 設定の例
apiVersion: jaegertracing.io/v1 kind: "Jaeger" metadata: name: "my-jaeger" spec: strategy: allInOne allInOne: options: log-level: debug query: base-path: /jaeger
2.2.4.7. Jaeger Ingester 設定オプション
Ingester は、Kafka トピックから読み取り、別のストレージバックエンド (Elasticsearch) に書き込むサービスです。allInOne
または production
デプロイメントストラテジーを使用している場合は、Ingester サービスを設定する必要はありません。
表2.16 Ingester に渡される Jaeger パラメーター
パラメーター | 詳細 | 値 |
---|---|---|
spec: ingester: options: {} | Ingester サービスを定義する設定オプション。 | |
options: deadlockInterval: | Ingester が終了するまでメッセージを待機する間隔 (秒単位または分単位) を指定します。システムの初期化中にメッセージが到達されない場合に Ingester が終了しないようにするため、デッドロック間隔はデフォルトで無効に(0 に設定)されます。 |
分と秒 (例: |
options: kafka: consumer: topic: |
|
コンシューマーのラベル例: |
kafka: consumer: brokers: | メッセージを消費するために Ingester によって使用される Kafka 設定を特定します。 |
ブローカーのラベル (例: |
ingester: deadlockInterval: | Ingester が終了するまでメッセージを待機する間隔 (秒単位または分単位) を指定します。システムの初期化中にメッセージが到達されない場合に Ingester が終了しないようにするため、デッドロック間隔はデフォルトで無効に(0 に設定)されます。 |
分と秒 (例: |
log-level: | Ingester のロギングレベル。 |
使用できる値は、 |
maxReplicas: | Ingester の自動スケーリング時に作成するレプリカの最大数を指定します。 |
整数 (例: |
ストリーミング 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
2.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
2.2.5. サイドカーコンテナーの挿入
OpenShift Jaeger は、アプリケーションの Pod 内のプロキシーサイドカーコンテナーを使用してエージェントを提供します。Jaeger Operator は Jaeger Agent サイドカーを Deployment ワークロードに挿入できます。自動のサイドカーコンテナー挿入を有効にしたり、手動で管理したりできます。
2.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
のデフォルトの場所でアクセスできます。
2.2.5.2. サイドカーコンテナーの手動挿入
Deployments
以外のコントローラータイプ(StatefulSets
、DaemonSet
など)の場合、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 のデフォルトの場所でアクセスできます。
2.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 」を参照してください。
2.4. Jaeger の削除
OpenShift Container Platform クラスターから Jaeger を削除する手順は、以下のとおりです。
- Jaeger Pod をシャットダウンします。
- Jaeger インスタンスを削除します。
- Jaeger Operator を削除します。
2.4.1. Web コンソールを使用した Jaeger インスタンスの削除
インメモリーストレージを使用するインスタンスを削除すると、すべてのデータが完全に失われます。永続ストレージ (Elasticsearch など)に保存されているデータは、Jaeger インスタンスが削除されても削除されません。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Operators → Installed Operators に移動します。
-
Project メニューから Operator がインストールされているプロジェクトの名前 (例:
jaeger-system
) を選択します。 - Jaeger Operator をクリックします。
- Jaeger タブをクリックします。
-
Options メニュー
(削除するインスタンスの横にある) をクリックし、Delete Jaeger を選択します。
- 確認ウィンドウで Delete をクリックします。
2.4.2. CLI からの Jaeger インスタンスの削除
OpenShift Container Platform CLI にログインします。
$ oc login
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
Jaeger のインスタンスを削除するには、以下のコマンドを実行します。
$ oc delete jaeger <deployment-name> -n <jaeger-project>
例:
$ oc delete jaeger tracing2 -n jaeger-system
削除を確認するには、
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
2.4.3. Jaeger Operator の削除
手順
クラスターからの Operator の削除についての手順に従います。
- Jaeger Operator を削除します。
- Jaeger Operator の削除後、(該当する場合は) OpenShift Elasticsearch Operator を削除します。