4.2. distributed tracing platform (Tempo) の設定とデプロイ
Tempo Operator は、distributed tracing platform (Tempo) の作成とデプロイで使用するアーキテクチャーおよび設定を定義するカスタムリソース定義 (CRD) ファイルを使用します。デフォルト設定をインストールするか、ファイルを変更できます。
4.2.1. デプロイメントのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
バックエンドストレージの設定については、永続ストレージについて と、選択したストレージに対応する設定トピックを参照してください。
4.2.1.1. 分散トレースのデフォルト設定オプション リンクのコピーリンクがクリップボードにコピーされました!
Tempo カスタムリソース (CR) は、distributed tracing platform (Tempo) リソースの作成時に使用されるアーキテクチャーおよび設定を定義します。これらのパラメーターを変更して、distributed tracing platform (Tempo) の実装をビジネスニーズに合わせてカスタマイズできます。
汎用 Tempo YAML ファイルの例
| パラメーター | 説明 | 値 | デフォルト値 |
|---|---|---|---|
apiVersion:
| オブジェクトの作成時に使用する API バージョン。 |
|
|
kind:
| 作成する Kubernetes オブジェクトの種類を定義します。 |
| |
metadata:
|
|
OpenShift Container Platform は | |
name:
| オブジェクトの名前。 | TempoStack インスタンスの名前。 |
|
spec:
| 作成するオブジェクトの仕様。 |
TempoStack インスタンスのすべての設定パラメーターが含まれています。すべての Tempo コンポーネントの共通定義が必要な場合、 | 該当なし |
resources:
| TempoStack に割り当てられたリソース。 | ||
storageSize:
| Ingester PVC のストレージサイズ。 | ||
replicationFactor:
| レプリケーション係数の設定。 | ||
retention:
| トレースの保持に関する設定オプション。 | ||
storage:
|
ストレージを定義する設定オプション。すべてのストレージ関連オプションは、 | ||
template.distributor:
|
Tempo | ||
template.ingester:
|
Tempo | ||
template.compactor:
|
Tempo | ||
template.querier:
|
Tempo | ||
template.queryFrontend:
|
Tempo | ||
template.gateway:
|
Tempo |
最低限必要な設定
以下は、デフォルト設定で distributed tracing platform (Tempo) デプロイメントを作成するために必要な最小限の設定です。
- 1
- このセクションでは、デプロイされたオブジェクトストレージバックエンドを指定します。そのためには、オブジェクトストレージにアクセスするための作成済みシークレットと認証情報が必要です。
4.2.1.2. distributed tracing platform (Tempo) のストレージ設定 リンクのコピーリンクがクリップボードにコピーされました!
spec.storage の下にある TempoStack カスタムリソースで、distributed tracing platform (Tempo) のオブジェクトストレージを設定できます。サポート対象である複数のストレージプロバイダーから選択できます。
| パラメーター | 説明 | 値 | デフォルト値 |
|---|---|---|---|
spec:
storage:
secret
type:
| デプロイメントに使用するストレージのタイプ。 |
|
|
storage: secretname:
| 設定されたオブジェクトストレージタイプの認証情報を含むシークレットの名前。 | 該当なし | |
storage:
tls:
caName:
|
CA は、CA 証明書が含まれる |
| ストレージプロバイダー |
|---|
| Secret パラメーター |
|
|
| MinIO |
| MinIO Operator を参照してください。
|
| Amazon S3 |
|
|
| Microsoft Azure Blob Storage |
|
|
| Google Cloud Storage on Google Cloud Platform (GCP) |
|
|
4.2.1.3. クエリー設定オプション リンクのコピーリンクがクリップボードにコピーされました!
分散トレースプラットフォームの 2 つのコンポーネント(Tempo)で、クエリーアとクエリーフロントエンドはクエリーを管理します。これらのコンポーネントの両方を設定できます。
querier コンポーネントは、取り込み元またはバックエンドストレージで要求されたトレース ID を見つけます。set パラメーターに応じて、querier コンポーネントは、取り込み担当者とプルブームまたはインデックスの両方をバックエンドからクエリーして、オブジェクトストレージ内のブロックを検索できます。querier コンポーネントは、GET /querier/api/traces/<traceID > で HTTP エンドポイントを公開しますが、直接使用することは想定されていません。クエリーはクエリーフロントエンドに送信する必要があります。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| node-selection 制約の単純な形式。 | type: object |
|
| コンポーネント用に作成されるレプリカの数。 | type: integer; format: int32 |
|
| コンポーネント固有の Pod の容認。 | type: array |
クエリーフロントエンドコンポーネントは、受信クエリーの検索スペースをシャード化します。クエリー frontend は、単純な HTTP エンドポイント( GET /api/traces/<traceID>)でトレースを公開します。内部的には、クエリーフロントエンドコンポーネントは blockID 領域を設定可能なシャード数に分割し、これらの要求をキューに入れます。querier コンポーネントは、ストリーミング gRPC 接続を介してクエリーフロントエンドコンポーネントに接続し、これらのシャードクエリーを処理します。
| パラメーター | 説明 | 値 |
|---|---|---|
|
| クエリーフロントエンドコンポーネントの設定。 | type: object |
|
| ノード選択制約の単純な形式。 | type: object |
|
| クエリーの frontend コンポーネント用に作成されるレプリカの数です。 | type: integer; format: int32 |
|
| クエリーフロントエンドコンポーネントに固有の Pod 容認。 | type: array |
|
| Jaeger Query コンポーネントに固有のオプション。 | type: object |
|
|
| 型:boolean |
|
| Jaeger Query ingress のオプション。 | type: object |
|
| Ingress オブジェクトのアノテーション。 | type: object |
|
| Ingress オブジェクトのホスト名。 | type: string |
|
| IngressClass クラスターリソースの名前。この Ingress リソースを提供する Ingress コントローラーを定義します。 | type: string |
|
| OpenShift ルートのオプション。 | type: object |
|
|
終了タイプ。デフォルトは | 型:文字列(enum: insecure、edge、passthrough、reencrypt) |
|
|
Jaeger Query UI の Ingress のタイプ。サポートされるタイプは | 型:文字列(enum: ingress、route) |
|
| 監視タブの設定。 | type: object |
|
|
Jaeger コンソールの monitor タブを有効にします。 | 型:boolean |
|
|
スパンレート、エラー、および期間(RED)メトリクスが含まれる Prometheus インスタンスへのエンドポイント。例: | type: string |
TempoStack CR でのクエリーフロントエンドコンポーネントの設定例
4.2.1.4. Yeter UI の Monitor タブの設定 リンクのコピーリンクがクリップボードにコピーされました!
トレースデータには豊富な情報が含まれており、データはインストルメント化された言語およびフレームワーク間で正規化されます。したがって、要求レート、エラー、および期間(RED)メトリクスをトレースから抽出できます。メトリクスは、Jaeger コンソールの Monitor タブで可視化できます。
メトリクスは、ユーザーワークロード監視スタックにデプロイされた Prometheus により Collector から収集された OpenTelemetry コレクターのスパンから導出されます。Jaeger UI は、Prometheus エンドポイントからこれらのメトリクスをクエリーし、可視化します。
4.2.1.4.1. OpenTelemetry Collector の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenTelemetry Collector では、トレースからメトリクスを導出し、そのメトリクスを Prometheus 形式でエクスポートする spanmetrics コネクターの設定が必要です。
スパン RED の OpenTelemetry Collector カスタムリソース
- 1
ServiceMonitorカスタムリソースを作成して、Prometheus エクスポーターの収集を有効にします。- 2
- Spanmetrics コネクターはトレースを受信し、メトリクスをエクスポートします。
- 3
- OpenTelemetry プロトコルのスパンを受信する OTLP レシーバー。
- 4
- Prometheus エクスポーターは、Prometheus 形式でメトリクスをエクスポートするために使用されます。
- 5
- Spanmetrics コネクターは、トレースパイプラインのエクスポーターとして設定されています。
- 6
- Spanmetrics コネクターは、メトリクスパイプラインのレシーバーとして設定されています。
4.2.1.4.2. Tempo の設定 リンクのコピーリンクがクリップボードにコピーされました!
TempoStack カスタムリソースでは、Monitor タブが有効で、ユーザー定義の監視スタックからデータをクエリーするように Prometheus エンドポイントを Thanos Querier サービスに設定する必要があります。
Monitor タブが有効な TempoStack カスタムリソース
4.2.1.5. マルチテナントへの対応 リンクのコピーリンクがクリップボードにコピーされました!
認証と認可を備えたマルチテナンシーは、Tempo Gateway サービスで提供されます。認証には、OpenShift OAuth と Kubernetes TokenReview API を使用します。認可には、Kubernetes SubjectAccessReview API を使用します。
2 つのテナント (dev と prod) を使用したサンプル Tempo CR
認可設定では、Kubernetes ロールベースアクセス制御 (RBAC) の ClusterRole と ClusterRoleBinding を使用します。デフォルトでは、読み取りまたは書き込み権限を持っているユーザーはいません。
認証されたユーザーが dev テナントおよび prod テナントのトレースデータを読み取ることができる読み取り RBAC 設定のサンプル
otel-collector サービスアカウントが dev テナントのトレースデータを書き込むことができる書き込み RBAC 設定のサンプル
トレースデータは、データ書き込み用の RBAC を持つサービスアカウントを使用する OpenTelemetry Collector から Tempo インスタンスに送信できます。
OpenTelemetry CR 設定のサンプル
4.2.2. distributed tracing platform (Tempo) のモニタリング設定 リンクのコピーリンクがクリップボードにコピーされました!
Tempo Operator は、distributor や ingester などの各 TempoStack コンポーネントのモニタリングとアラートをサポートし、Operator 自体に関するアップグレードおよび運用のメトリクスを公開します。
4.2.2.1. TempoStack メトリクスとアラートの設定 リンクのコピーリンクがクリップボードにコピーされました!
TempoStack インスタンスのメトリクスとアラートを有効にできます。
前提条件
- ユーザー定義プロジェクトのモニタリングがクラスターで有効にされている。ユーザー定義プロジェクトのモニタリングの有効化 を参照してください。
手順
TempoStack インスタンスのメトリクスを有効にするには、
spec.observability.metrics.createServiceMonitorsフィールドをtrueに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow TempoStack インスタンスのアラートを有効にするには、
spec.observability.metrics.createPrometheusRulesフィールドをtrueに設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
Web コンソールの Administrator ビューを使用して、正常に設定されたことを確認できます。
-
Observe
Targets に移動して Source: User でフィルタリングし、 tempo-<instance_name>-<component>形式の ServiceMonitor のステータスが Up であることを確認します。 -
アラートが正しく設定されていることを確認するには、Observe
Alerting Alerting rules に移動して Source: User でフィルタリングし、TempoStack インスタンスコンポーネントの Alert rules が利用可能であることを確認します。
4.2.2.2. Tempo Operator のメトリクスとアラートの設定 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールから Tempo Operator をインストールする場合は、Enable Operator recommended cluster monitoring on this Namespace チェックボックスを選択すると、Tempo Operator のメトリクスおよびアラートを作成できます。
インストール時にチェックボックスを選択しなかった場合も、Tempo Operator をインストールした後にメトリクスとアラートを手動で有効にできます。
手順
-
Tempo Operator がインストールされているプロジェクトに
openshift.io/cluster-monitoring: "true"ラベルを追加します。デフォルトはopenshift-tempo-operatorです。
検証
Web コンソールの Administrator ビューを使用して、正常に設定されたことを確認できます。
-
Observe
Targets に移動して Source: Platform でフィルタリングし、 tempo-operatorを検索します。その場合は、ステータスは Up でなければなりません。 -
アラートが正しく設定されていることを確認するには、Observe
Alerting Alerting rules に移動して Source: Platform でフィルタリングし、Tempo Operator の Alert rules を見つけます。