3.2. 設定
Tempo Operator は、distributed tracing platform (Tempo) の作成とデプロイで使用するアーキテクチャーおよび設定を定義するカスタムリソース定義 (CRD) ファイルを使用します。デフォルト設定をインストールするか、ファイルを変更できます。
3.2.1. バックエンドストレージの設定
バックエンドストレージの設定は、永続ストレージについて および選択したストレージオプションに関連する設定セクションを参照してください。
3.2.2. TempoStack 設定パラメーターの概要
TempoStack
カスタムリソース (CR) は、distributed tracing platform (Tempo) リソースを作成するときに使用するアーキテクチャーと設定を定義します。これらのパラメーターを変更して、実装をビジネスニーズに合わせてカスタマイズできます。
TempoStack
CR の例
apiVersion: tempo.grafana.com/v1alpha1 1 kind: TempoStack 2 metadata: 3 name: <name> 4 spec: 5 storage: {} 6 resources: {} 7 replicationFactor: 1 8 retention: {} 9 template: distributor: {} 10 ingester: {} 11 compactor: {} 12 querier: {} 13 queryFrontend: {} 14 gateway: {} 15 limits: 16 global: ingestion: {} 17 query: {} 18 observability: 19 grafana: {} metrics: {} tracing: {} search: {} 20 managementState: managed 21
- 1
- オブジェクトの作成時に使用する API バージョン。
- 2
- 作成する Kubernetes オブジェクトの種類を定義します。
- 3
name
の文字列、UID
、オプションのnamespace
などのオブジェクトを一意に識別するデータ。OpenShift Container Platform はUID
を自動的に生成し、オブジェクトが作成されるプロジェクトの名前でnamespace
を完了します。- 4
- TempoStack インスタンスの名前。
- 5
- TempoStack インスタンスのすべての設定パラメーターが含まれます。すべての Tempo コンポーネントに共通の定義が必要な場合は、
spec
セクションで定義します。定義が個々のコンポーネントに関連している場合は、spec.template.<component>
セクションに配置します。 - 6
- ストレージはインスタンスのデプロイメント時に指定されます。インスタンスのストレージオプションの詳細は、インストールページを参照してください。
- 7
- Tempo コンテナーのコンピュートリソースを定義します。
- 8
- スパンを受け入れる前にディストリビューターからのデータを確認する必要があるインジェスターの数を表す整数値。
- 9
- トレースの保持に関する設定オプション。
- 10
- Tempo
distributor
コンポーネントの設定オプション。 - 11
- Tempo
ingester
コンポーネントの設定オプション。 - 12
- Tempo
compactor
コンポーネントの設定オプション。 - 13
- Tempo
querier
コンポーネントの設定オプション。 - 14
- Tempo
query-frontend
コンポーネントの設定オプション。 - 15
- Tempo
gateway
コンポーネントの設定オプション。 - 16
- 取り込みとクエリーのレートを制限します。
- 17
- 取り込みの流量制御を定義します。
- 18
- クエリーの流量制御を定義します。
- 19
- テレメトリーデータを処理するためのオペランドを設定します。
- 20
- 検索機能を設定します。
- 21
- この CR が Operator によって管理されるかどうかを定義します。デフォルト値は
managed
です。
3.2.3. クエリー設定オプション
分散トレースプラットフォーム (Tempo) の 2 つのコンポーネント、クエリアーとクエリーフロントエンドがクエリーを管理します。これらのコンポーネントは両方とも設定できます。
クエリアーコンポーネントは、インジェスターまたはバックエンドストレージで要求されたトレース ID を検索します。設定されたパラメーターに応じて、クエリアーコンポーネントはインジェスターの両方にクエリーを実行し、bloom またはインデックスをバックエンドからプルして、オブジェクトストレージ内のブロックを検索できます。クエリアーコンポーネントは GET /querier/api/traces/<trace_id>
で HTTP エンドポイントを公開します。ただし、このエンドポイントを直接使用することは想定されていません。クエリーはクエリーフロントエンドに送信する必要があります。
パラメーター | 説明 | 値 |
---|---|---|
| ノード選択制約の単純な形式。 | type: object |
| コンポーネントに対して作成されるレプリカの数。 | type: integer; format: int32 |
| コンポーネント固有の Pod 容認。 | type: array |
クエリーフロントエンドコンポーネントは、受信クエリーの検索スペースをシャーディングする役割を持ちます。クエリーフロントエンドは、単純な HTTP エンドポイント (GET /api/traces/<trace_id>
) を介してトレースを公開します。内部的には、クエリーフロントエンドコンポーネントは blockID
スペースを設定可能な数のシャードに分割し、これらのリクエストをキューに登録します。クエリアーコンポーネントは、ストリーミング gRPC 接続を介してクエリーフロントエンドコンポーネントに接続し、これらのシャードクエリーを処理します。
パラメーター | 説明 | 値 |
---|---|---|
| クエリーフロントエンドコンポーネントの設定。 | type: object |
| ノード選択制約の単純な形式。 | type: object |
| クエリーフロントエンドコンポーネントに対して作成されるレプリカの数。 | type: integer; format: int32 |
| クエリーフロントエンドコンポーネントに固有の Pod 容認。 | type: array |
| Jaeger Query コンポーネントに固有のオプション。 | type: object |
|
| type: boolean |
| Jaeger Query Ingress のオプション。 | type: object |
| Ingress オブジェクトのアノテーション。 | type: object |
| Ingress オブジェクトのホスト名。 | type: string |
| IngressClass クラスターリソースの名前。この Ingress リソースを提供する Ingress コントローラーを定義します。 | type: string |
| OpenShift ルートのオプション。 | type: object |
|
終端タイプ。デフォルトは | type: string (enum: insecure, edge, passthrough, reencrypt) |
|
Jaeger Query UI の Ingress のタイプ。サポートされているタイプは、 | type: string (enum: ingress, route) |
| Monitor タブの設定。 | type: object |
|
Jaeger コンソールの Monitor タブを有効にします。 | type: 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
3.2.4. Jaeger UI の Monitor タブの設定
トレースデータには豊富な情報が含まれており、データはインストルメント化された言語およびフレームワーク間で正規化されます。したがって、リクエストのレート、エラー、および期間 (RED) メトリクスをトレースから抽出できます。メトリクスは、Jaeger コンソールの Monitor タブで可視化できます。
メトリクスは、ユーザーワークロード監視スタックにデプロイされた Prometheus により Collector から収集された OpenTelemetry コレクターのスパンから導出されます。Jaeger UI は、Prometheus エンドポイントからこれらのメトリクスをクエリーし、可視化します。
3.2.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 コネクターは、メトリクスパイプラインのレシーバーとして設定されています。
3.2.4.2. Tempo の設定
TempoStack
カスタムリソースでは、Monitor タブが有効で、ユーザー定義の監視スタックからデータをクエリーするように Prometheus エンドポイントを Thanos Querier サービスに設定する必要があります。
Monitor タブが有効な TempoStack カスタムリソース
apiVersion: tempo.grafana.com/v1alpha1 kind: TempoStack metadata: name: redmetrics spec: storage: secret: name: minio-test type: s3 storageSize: 1Gi template: gateway: enabled: false queryFrontend: jaegerQuery: enabled: true monitorTab: enabled: true 1 prometheusEndpoint: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 2 ingress: type: route
3.2.4.3. Span RED メトリクスとアラートルール
spanmetrics
コネクターによって生成されるメトリクスは、アラートルールで使用できます。たとえば、このコネクターは、サービスの速度低下に関するアラートの場合や、サービスレベル目標 (SLO) を定義する場合のために、duration_bucket
ヒストグラムと calls
カウンターメトリクスを作成します。これらのメトリクスには、サービス、API 名、操作タイプ、その他の属性を識別するラベルが付いています。
ラベル | 説明 | 値 |
---|---|---|
|
|
|
| 操作の名前。 |
|
| サーバー、クライアント、メッセージング、または内部操作を識別します。 |
|
フロントエンドサービスで 2000 ミリ秒以内に 95% の要求が処理されない場合の SLO のアラートルールを定義する PrometheusRule
CR の例
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: span-red
spec:
groups:
- name: server-side-latency
rules:
- alert: SpanREDFrontendAPIRequestLatency
expr: histogram_quantile(0.95, sum(rate(duration_bucket{service_name="frontend", span_kind="SPAN_KIND_SERVER"}[5m])) by (le, service_name, span_name)) > 2000 1
labels:
severity: Warning
annotations:
summary: "High request latency on {{$labels.service_name}} and {{$labels.span_name}}"
description: "{{$labels.instance}} has 95th request latency above 2s (current value: {{$value}}s)"
- 1
- 95% のフロントエンドサーバーの応答時間値が 2000 ミリ秒未満であるかどうかを確認する式。時間範囲 (
[5m]
) が収集間隔の 4 倍以上で、メトリクスの変化に対応できる十分な長さである必要があります。
3.2.5. レシーバーの TLS の設定
TempoStack または TempoMonolithic インスタンスのカスタムリソースで、ユーザーが指定する証明書または OpenShift のサービス提供証明書を使用して、レシーバーの TLS を設定できます。
3.2.5.1. TempoStack インスタンス用のレシーバーの TLS 設定
シークレットの TLS 証明書を指定することも、OpenShift Container Platform によって生成されるサービス提供証明書を使用することもできます。
シークレットの TLS 証明書を指定するには、
TempoStack
カスタムリソースでそれを設定します。注記この機能は、有効な Tempo Gateway ではサポートされていません。
レシーバーの TLS と、ユーザーが指定するシークレットの証明書の使用
apiVersion: tempo.grafana.com/v1alpha1 kind: TempoStack # ... spec: # ... template: distributor: tls: enabled: true 1 certName: <tls_secret> 2 caName: <ca_name> 3 # ...
または、OpenShift Container Platform によって生成されたサービス提供証明書を使用することもできます。
注記この機能では、相互 TLS 認証 (mTLS) はサポートされていません。
レシーバーの TLS と、OpenShift Container Platform によって生成されるサービス提供証明書の使用
apiVersion: tempo.grafana.com/v1alpha1 kind: TempoStack # ... spec: # ... template: distributor: tls: enabled: true 1 # ...
- 1
- Tempo Distributor の TLS に十分な設定。
関連情報
3.2.5.2. TempoMonolithic インスタンス用のレシーバーの TLS 設定
シークレットの TLS 証明書を指定することも、OpenShift Container Platform によって生成されるサービス提供証明書を使用することもできます。
シークレットの TLS 証明書を指定するには、
TempoMonolithic
カスタムリソースでそれを設定します。注記この機能は、有効な Tempo Gateway ではサポートされていません。
レシーバーの TLS と、ユーザーが指定するシークレットの証明書の使用
apiVersion: tempo.grafana.com/v1alpha1 kind: TempoMonolithic # ... spec: # ... ingestion: otlp: grpc: tls: enabled: true 1 certName: <tls_secret> 2 caName: <ca_name> 3 # ...
または、OpenShift Container Platform によって生成されたサービス提供証明書を使用することもできます。
注記この機能では、相互 TLS 認証 (mTLS) はサポートされていません。
レシーバーの TLS と、OpenShift Container Platform によって生成されるサービス提供証明書の使用
apiVersion: tempo.grafana.com/v1alpha1 kind: TempoMonolithic # ... spec: # ... ingestion: otlp: grpc: tls: enabled: true http: tls: enabled: true 1 # ...
- 1
- Tempo Distributor の TLS の最小設定。
関連情報
3.2.6. マルチテナントへの対応
認証と認可を備えたマルチテナンシーは、Tempo Gateway サービスで提供されます。認証には、OpenShift OAuth と Kubernetes TokenReview
API を使用します。認可には、Kubernetes SubjectAccessReview
API を使用します。
Tempo Gateway サービスは、OTLP/gRPC 経由のトレース取り込みのみをサポートしています。OTLP/HTTP はサポートされていません。
2 つのテナント (dev
と prod)
を使用したサンプル Tempo CR
apiVersion: tempo.grafana.com/v1alpha1 kind: TempoStack metadata: name: simplest namespace: chainsaw-multitenancy spec: storage: secret: name: minio type: s3 storageSize: 1Gi resources: total: limits: memory: 2Gi cpu: 2000m 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: 1 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" otlphttp/dev: 2 endpoint: https://tempo-simplest-gateway.chainsaw-multitenancy.svc.cluster.local:8080/api/traces/v1/dev 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] 3
3.2.7. taint および toleration の使用
専用ノードで TempoStack Pod をスケジュールするには、OpenShift 4 で nodeSelector と tolerations を使用してインフラノードにさまざまな TempoStack コンポーネントをデプロイする方法 を参照してください。
3.2.8. 監視とアラートの設定
Tempo Operator は、distributor や ingester などの各 TempoStack コンポーネントのモニタリングとアラートをサポートし、Operator 自体に関するアップグレードおよび運用のメトリクスを公開します。
3.2.8.1. TempoStack のメトリクスとアラートの設定
TempoStack インスタンスのメトリクスとアラートを有効にできます。
前提条件
- ユーザー定義プロジェクトのモニタリングがクラスターで有効にされている。
手順
TempoStack インスタンスのメトリクスを有効にするには、
spec.observability.metrics.createServiceMonitors
フィールドをtrue
に設定します。apiVersion: tempo.grafana.com/v1alpha1 kind: TempoStack metadata: name: <name> spec: observability: metrics: createServiceMonitors: true
TempoStack インスタンスのアラートを有効にするには、
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 が利用可能であることを確認します。
3.2.8.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 を見つけます。