検索

3.2. 設定

download PDF

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 エンドポイントを公開します。ただし、このエンドポイントを直接使用することは想定されていません。クエリーはクエリーフロントエンドに送信する必要があります。

表3.2 クエリアーコンポーネントの設定パラメーター
パラメーター説明

nodeSelector

ノード選択制約の単純な形式。

type: object

replicas

コンポーネントに対して作成されるレプリカの数。

type: integer; format: int32

toleration

コンポーネント固有の Pod 容認。

type: array

クエリーフロントエンドコンポーネントは、受信クエリーの検索スペースをシャーディングする役割を持ちます。クエリーフロントエンドは、単純な HTTP エンドポイント (GET /api/traces/<trace_id>) を介してトレースを公開します。内部的には、クエリーフロントエンドコンポーネントは blockID スペースを設定可能な数のシャードに分割し、これらのリクエストをキューに登録します。クエリアーコンポーネントは、ストリーミング gRPC 接続を介してクエリーフロントエンドコンポーネントに接続し、これらのシャードクエリーを処理します。

表3.3 クエリーフロントエンドコンポーネントの設定パラメーター
パラメーター説明

component

クエリーフロントエンドコンポーネントの設定。

type: object

component.nodeSelector

ノード選択制約の単純な形式。

type: object

component.replicas

クエリーフロントエンドコンポーネントに対して作成されるレプリカの数。

type: integer; format: int32

component.tolerations

クエリーフロントエンドコンポーネントに固有の Pod 容認。

type: array

jaegerQuery

Jaeger Query コンポーネントに固有のオプション。

type: object

jaegerQuery.enabled

enabled にすると、Jaeger Query コンポーネント jaegerQuery が作成されます。

type: boolean

jaegerQuery.ingress

Jaeger Query Ingress のオプション。

type: object

jaegerQuery.ingress.annotations

Ingress オブジェクトのアノテーション。

type: object

jaegerQuery.ingress.host

Ingress オブジェクトのホスト名。

type: string

jaegerQuery.ingress.ingressClassName

IngressClass クラスターリソースの名前。この Ingress リソースを提供する Ingress コントローラーを定義します。

type: string

jaegerQuery.ingress.route

OpenShift ルートのオプション。

type: object

jaegerQuery.ingress.route.termination

終端タイプ。デフォルトは edge です。

type: string (enum: insecure, edge, passthrough, reencrypt)

jaegerQuery.ingress.type

Jaeger Query UI の Ingress のタイプ。サポートされているタイプは、ingressroute、および none です。

type: string (enum: ingress, route)

jaegerQuery.monitorTab

Monitor タブの設定。

type: object

jaegerQuery.monitorTab.enabled

Jaeger コンソールの Monitor タブを有効にします。PrometheusEndpoint を設定する必要があります。

type: boolean

jaegerQuery.monitorTab.prometheusEndpoint

スパンのレート、エラー、および期間 (RED) メトリクスを含む Prometheus インスタンスへのエンドポイント。たとえば、https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 です。

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

1
Jaeger コンソールの監視タブを有効にします。
2
ユーザーワークロード監視からの Thanos Querier のサービス名。

3.2.4.3. Span RED メトリクスとアラートルール

spanmetrics コネクターによって生成されるメトリクスは、アラートルールで使用できます。たとえば、このコネクターは、サービスの速度低下に関するアラートの場合や、サービスレベル目標 (SLO) を定義する場合のために、duration_bucket ヒストグラムと calls カウンターメトリクスを作成します。これらのメトリクスには、サービス、API 名、操作タイプ、その他の属性を識別するラベルが付いています。

表3.4 spanmetrics コネクターで作成されるメトリクスのラベル
ラベル説明

service_name

otel_service_name 環境変数によって設定されるサービス名。

frontend

span_name

操作の名前。

  • /
  • /customer

span_kind

サーバー、クライアント、メッセージング、または内部操作を識別します。

  • SPAN_KIND_SERVER
  • SPAN_KIND_CLIENT
  • SPAN_KIND_PRODUCER
  • SPAN_KIND_CONSUMER
  • SPAN_KIND_INTERNAL

フロントエンドサービスで 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
    # ...

    1
    Tempo Distributor で TLS が有効になります。
    2
    事前に適用する tls.key 鍵と tls.crt 証明書を含むシークレット。
    3
    オプション: 相互 TLS 認証 (mTLS) を有効にするための config map 内の CA。
  • または、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
    # ...

    1
    Tempo Distributor で TLS が有効になります。
    2
    事前に適用する tls.key 鍵と tls.crt 証明書を含むシークレット。
    3
    オプション: 相互 TLS 認証 (mTLS) を有効にするための config map 内の CA。
  • または、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 つのテナント (devprod) を使用したサンプル 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

1
openshift に設定する必要があります。
2
テナントのリスト。
3
テナント名。データを取り込む際に、X-Scope-OrgId ヘッダーで指定する必要があります。
4
一意のテナント ID。
5
認証と認可を実行するゲートウェイを有効にします。Jaeger UI は、http://<gateway-ingress>/api/traces/v1/<tenant-name>/search で公開されています。

認可設定では、Kubernetes ロールベースアクセス制御 (RBAC) の ClusterRoleClusterRoleBinding を使用します。デフォルトでは、読み取りまたは書き込み権限を持っているユーザーはいません。

認証されたユーザーが 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

1
テナントをリスト表示します。
2
値が get の場合、読み取り操作が有効になります。
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

1
トレースデータのエクスポートでクライアントが使用するサービスアカウント名。クライアントは、サービスアカウントトークン /var/run/secrets/kubernetes.io/serviceaccount/token をベアラートークンヘッダーとして送信する必要があります。
2
テナントをリスト表示します。
3
値が create の場合、書き込み操作が有効になります。

トレースデータは、データ書き込み用の 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]

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 インスタンスのメトリクスとアラートを有効にできます。

前提条件

  • ユーザー定義プロジェクトのモニタリングがクラスターで有効にされている。

手順

  1. TempoStack インスタンスのメトリクスを有効にするには、spec.observability.metrics.createServiceMonitors フィールドを true に設定します。

    apiVersion: tempo.grafana.com/v1alpha1
    kind: TempoStack
    metadata:
      name: <name>
    spec:
      observability:
        metrics:
          createServiceMonitors: true
  2. TempoStack インスタンスのアラートを有効にするには、spec.observability.metrics.createPrometheusRules フィールドを true に設定します。

    apiVersion: tempo.grafana.com/v1alpha1
    kind: TempoStack
    metadata:
      name: <name>
    spec:
      observability:
        metrics:
          createPrometheusRules: true

検証

Web コンソールの Administrator ビューを使用して、正常に設定されたことを確認できます。

  1. Observe Targets に移動して Source: User でフィルタリングし、tempo-<instance_name>-<component> 形式の ServiceMonitor のステータスが Up であることを確認します。
  2. アラートが正しく設定されていることを確認するには、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 ビューを使用して、正常に設定されたことを確認できます。

  1. Observe Targets に移動して Source: Platform でフィルタリングし、tempo-operator を検索します。その場合は、ステータスは Up でなければなりません。
  2. アラートが正しく設定されていることを確認するには、Observe Alerting Alerting rules に移動して Source: Platform でフィルタリングし、Tempo OperatorAlert rules を見つけます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.