This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.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 を見つけます。