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: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
name: name
spec:
storage: {}
resources: {}
storageSize: 200M
replicationFactor: 1
retention: {}
template:
distributor:{}
ingester: {}
compactor: {}
querier: {}
queryFrontend: {}
gateway: {}
| パラメーター | 説明 | 値 | デフォルト値 |
|---|---|---|---|
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) デプロイメントを作成するために必要な最小限の設定です。
apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
name: simplest
spec:
storage: 1
secret:
name: minio
type: s3
resources:
total:
limits:
memory: 2Gi
cpu: 2000m
template:
queryFrontend:
jaegerQuery:
enabled: true
ingress:
type: route- 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 でのクエリーフロントエンドコンポーネントの設定例
apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
name: simplest
spec:
storage:
secret:
name: minio
type: s3
storageSize: 200M
resources:
total:
limits:
memory: 2Gi
cpu: 2000m
template:
queryFrontend:
jaegerQuery:
enabled: true
ingress:
route:
termination: edge
type: route
4.2.1.3.1. 関連情報
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 カスタムリソース
kind: OpenTelemetryCollector
apiVersion: opentelemetry.io/v1alpha1
metadata:
name: otel
spec:
mode: deployment
observability:
metrics:
enableMetrics: true 1
config: |
connectors:
spanmetrics: 2
metrics_flush_interval: 15s
receivers:
otlp: 3
protocols:
grpc:
http:
exporters:
prometheus: 4
endpoint: 0.0.0.0:8889
add_metric_suffixes: false
resource_to_telemetry_conversion:
enabled: true # by default resource attributes are dropped
otlp:
endpoint: "tempo-simplest-distributor:4317"
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
exporters: [otlp, spanmetrics] 5
metrics:
receivers: [spanmetrics] 6
exporters: [prometheus]
- 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 カスタムリソース
kind: TempoStack
apiVersion: tempo.grafana.com/v1alpha1
metadata:
name: simplest
spec:
template:
queryFrontend:
jaegerQuery:
enabled: true
monitorTab:
enabled: true 1
prometheusEndpoint: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 2
ingress:
type: route
4.2.1.5. マルチテナントへの対応
認証と認可を備えたマルチテナンシーは、Tempo Gateway サービスで提供されます。認証には、OpenShift OAuth と Kubernetes TokenReview API を使用します。認可には、Kubernetes SubjectAccessReview API を使用します。
2 つのテナント (dev と prod) を使用したサンプル Tempo CR
apiVersion: tempo.grafana.com/v1alpha1
kind: TempoStack
metadata:
name: simplest
spec:
tenants:
mode: openshift 1
authentication: 2
- tenantName: dev 3
tenantId: "1610b0c3-c509-4592-a256-a1871353dbfa" 4
- tenantName: prod
tenantId: "1610b0c3-c509-4592-a256-a1871353dbfb"
template:
gateway:
enabled: true 5
queryFrontend:
jaegerQuery:
enabled: true
認可設定では、Kubernetes ロールベースアクセス制御 (RBAC) の ClusterRole と ClusterRoleBinding を使用します。デフォルトでは、読み取りまたは書き込み権限を持っているユーザーはいません。
認証されたユーザーが dev テナントおよび prod テナントのトレースデータを読み取ることができる読み取り RBAC 設定のサンプル
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: tempostack-traces-reader
rules:
- apiGroups:
- 'tempo.grafana.com'
resources: 1
- dev
- prod
resourceNames:
- traces
verbs:
- 'get' 2
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: tempostack-traces-reader
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: tempostack-traces-reader
subjects:
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: system:authenticated 3
otel-collector サービスアカウントが dev テナントのトレースデータを書き込むことができる書き込み RBAC 設定のサンプル
apiVersion: v1 kind: ServiceAccount metadata: name: otel-collector 1 namespace: otel --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: tempostack-traces-write rules: - apiGroups: - 'tempo.grafana.com' resources: 2 - dev resourceNames: - traces verbs: - 'create' 3 --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: tempostack-traces roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: tempostack-traces-write subjects: - kind: ServiceAccount name: otel-collector namespace: otel
トレースデータは、データ書き込み用の RBAC を持つサービスアカウントを使用する OpenTelemetry Collector から Tempo インスタンスに送信できます。
OpenTelemetry CR 設定のサンプル
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: cluster-collector
namespace: tracing-system
spec:
mode: deployment
serviceAccount: otel-collector
config: |
extensions:
bearertokenauth:
filename: "/var/run/secrets/kubernetes.io/serviceaccount/token"
exporters:
otlp/dev:
endpoint: tempo-simplest-gateway.tempo.svc.cluster.local:8090
tls:
insecure: false
ca_file: "/var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt"
auth:
authenticator: bearertokenauth
headers:
X-Scope-OrgID: "dev"
service:
extensions: [bearertokenauth]
pipelines:
traces:
exporters: [otlp/dev]
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に設定します。apiVersion: tempo.grafana.com/v1alpha1 kind: TempoStack metadata: name: <name> spec: observability: metrics: createServiceMonitors: trueTempoStack インスタンスのアラートを有効にするには、
spec.observability.metrics.createPrometheusRulesフィールドをtrueに設定します。apiVersion: tempo.grafana.com/v1alpha1 kind: TempoStack metadata: name: <name> spec: observability: metrics: createPrometheusRules: true
検証
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 を見つけます。
