検索

1.17. メトリクス、ログ、およびトレース

download PDF

アプリケーションをメッシュに追加したら、アプリケーション経由でデータフローを確認できます。独自のアプリケーションがインストールされていない場合は、Bookinfo サンプルアプリケーション をインストールして、Red Hat OpenShift Service Mesh で可観測性がどのように機能するかを確認できます。

1.17.1. コンソールアドレスの検出

Red Hat OpenShift Service Mesh は、Service Mesh データを表示する以下のコンソールを提供します。

  • Kiali コンソール: Kiali は Red Hat OpenShift Service Mesh の管理コンソールです。
  • Jaeger コンソール: Jaeger は Red Hat OpenShift 分散トレースプラットフォームの管理コンソールです。
  • Grafana コンソール: Grafana は、Istio データの高度なクエリーとメトリクス分析およびダッシュボードをメッシュ管理者に提供します。任意で、Grafana を使用して Service Mesh メトリクスを分析できます。
  • Prometheus コンソール: Red Hat OpenShift Service Mesh は Prometheus を使用してサービスからのテレメトリー情報を保存します。

Service Mesh コントロールプレーンのインストール時に、インストールされた各コンポーネントのルートを自動的に生成します。ルートアドレスを作成したら、Kiali、Jaeger、Prometheus、または Grafana コンソールにアクセスして、Service Mesh データを表示および管理できます。

前提条件

  • コンポーネントが有効で、インストールされていること。たとえば、分散トレースをインストールしていない場合、Jaeger コンソールにはアクセスできません。

OpenShift コンソールからの手順

  1. cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. Networking Routes に移動します。
  3. Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例: istio-system)。

    Location 列には、各ルートのリンク先アドレスが表示されます。

  4. 必要な場合は、フィルターを使用して、アクセスするルートを持つコンポーネントコンソールを検索します。ルートの Location をクリックしてコンソールを起動します。
  5. Log In With OpenShift をクリックします。

CLI からの手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. Service Mesh コントロールプレーンプロジェクトに切り替えます。この例では、istio-system は Service Mesh コントロールプレーンプロジェクトです。以下のコマンドを実行します。

    $ oc project istio-system
  3. 各種 Red Hat OpenShift Service Mesh コンソールのルートを取得するには、以下のコマンドを実行します。

    $ oc get routes

    このコマンドは、Kiali、Jaeger、Prometheus、および Grafana Web コンソールの URL と、Service Mesh 内の他のルートの URL を返します。以下のような出力が表示されるはずです。

    NAME                    HOST/PORT                         SERVICES              PORT    TERMINATION
    info-gateway        bookinfo-gateway-yourcompany.com  istio-ingressgateway          http2
    grafana                 grafana-yourcompany.com           grafana               <all>   reencrypt/Redirect
    istio-ingressgateway    istio-ingress-yourcompany.com     istio-ingressgateway  8080
    jaeger                  jaeger-yourcompany.com            jaeger-query          <all>   reencrypt
    kiali                   kiali-yourcompany.com             kiali                 20001   reencrypt/Redirect
    prometheus              prometheus-yourcompany.com        prometheus            <all>   reencrypt/Redirect
  4. HOST/PORT コラムからアクセスするコンソールの URL をブラウザーにコピーして、コンソールを開きます。
  5. Log In With OpenShift をクリックします。

1.17.2. Kiali コンソールへのアクセス

Kiali コンソールでアプリケーションのトポロジー、健全性、およびメトリクスを表示できます。サービスで問題が発生した場合、Kiali コンソールは、サービス経由でデータフローを表示できます。抽象アプリケーションからサービスおよびワークロードまで、さまざまなレベルでのメッシュコンポーネントに関する洞察を得ることができます。Kiali は、リアルタイムで namespace のインタラクティブなグラフビューも提供します。

Kiali コンソールにアクセスするには、Red Hat OpenShift Service Mesh がインストールされ、Kiali がインストールおよび設定されている必要があります。

インストールプロセスにより、Kiali コンソールにアクセスするためのルートが作成されます。

Kiali コンソールの URL が分かっている場合は、直接アクセスできます。URL が分からない場合は、以下の指示を使用します。

管理者の手順

  1. 管理者ロールで OpenShift Container Platform Web コンソールにログインします。
  2. Home Projects をクリックします。
  3. Projects ページで、必要に応じてフィルターを使用してプロジェクトの名前を検索します。
  4. プロジェクトの名前 (例: info) をクリックします。
  5. Project details ページの Launcher セクションで、Kiali リンクをクリックします。
  6. OpenShift Container Platform コンソールにアクセスするときに使用するものと同じユーザー名とパスワードを使用して Kiali コンソールにログインします。

    初回の Kiali コンソールへのログイン時に、表示するパーミッションを持つ Service Mesh 内のすべての namespace を表示する Overview ページが表示されます。

    コンソールのインストールを検証中で、namespace がまだメッシュに追加されていないと、istio-system 以外のデータは表示されない可能性があります。

開発者の手順

  1. 開発者ロールで OpenShift Container Platform Web コンソールにログインします。
  2. Project をクリックします。
  3. 必要に応じて、Project Details ページで、フィルターを使用してプロジェクトの名前を検索します。
  4. プロジェクトの名前 (例: info) をクリックします。
  5. Project ページの Launcher セクションで、Kiali リンクをクリックします。
  6. Log In With OpenShift をクリックします。

1.17.3. Kiali コンソールでの Service Mesh データの表示

Kiali グラフは、メッシュトラフィックの強力な視覚化を提供します。このトポロジーは、リアルタイムのリクエストトラフィックと Istio 設定情報を組み合わせて、Service Mesh の動作を即座に把握し、問題を迅速に特定できるようにします。複数のグラフタイプを使用すると、トラフィックを高レベルのサービストポロジー、低レベルのワークロードトポロジー、またはアプリケーションレベルのトポロジーとして視覚化できます。

以下から選択できるグラフがいくつかあります。

  • App グラフ は、同じラベルが付けられたすべてのアプリケーションの集約ワークロードを示します。
  • Service グラフ は、メッシュ内の各サービスのノードを表示しますが、グラフからすべてのアプリケーションおよびワークロードを除外します。これは高レベルのビューを提供し、定義されたサービスのすべてのトラフィックを集約します。
  • Versioned App グラフ は、アプリケーションの各バージョンのノードを表示します。アプリケーションの全バージョンがグループ化されます。
  • Workload グラフ は、Service Mesh の各ワークロードのノードを表示します。このグラフでは、app および version のラベルを使用する必要はありません。アプリケーションが version ラベルを使用しない場合は、このグラフを使用します。

グラフノードは、さまざまな情報で装飾され、仮想サービスやサービスエントリーなどのさまざまなルートルーティングオプションや、フォールトインジェクションやサーキットブレーカーなどの特別な設定を指定します。mTLS の問題、レイテンシーの問題、エラートラフィックなどを特定できます。グラフは高度な設定が可能で、トラフィックのアニメーションを表示でき、強力な検索機能や非表示機能があります。

Legend ボタンをクリックして、グラフに表示されるシェイプ、色、矢印、バッジに関する情報を表示します。

メトリクスの要約を表示するには、グラフ内のノードまたはエッジを選択し、そのメトリクスの詳細をサマリーの詳細パネルに表示します。

1.17.3.1. Kiali でのグラフレイアウトの変更

Kiali グラフのレイアウトは、アプリケーションのアーキテクチャーや表示データによって異なることがあります。たとえば、グラフノードの数およびそのインタラクションにより、Kiali グラフのレンダリング方法を判別できます。すべての状況に適した単一のレイアウトを作成することは不可能であるため、Kiali は複数の異なるレイアウトの選択肢を提供します。

前提条件

  • 独自のアプリケーションがインストールされていない場合は、Bookinfo サンプルアプリケーションをインストールします。次に、以下のコマンドを複数回入力して Bookinfo アプリケーションのトラフィックを生成します。

    $ curl "http://$GATEWAY_URL/productpage"

    このコマンドはアプリケーションの productpage マイクロサービスにアクセスするユーザーをシミュレートします。

手順

  1. Kiali コンソールを起動します。
  2. Log In With OpenShift をクリックします。
  3. Kiali コンソールで、Graph をクリックし、namespace グラフを表示します。
  4. Namespace メニューから、アプリケーション namespace (例: info) を選択します。
  5. 別のグラフレイアウトを選択するには、以下のいずれか、両方を行います。

    • グラフの上部にあるメニューから、異なるグラフデータグループを選択します。

      • App graph
      • Service graph
      • Versioned App graph (デフォルト)
      • Workload graph
    • グラフの下部にある Legend から別のグラフレイアウトを選択します。

      • Layout default dagre
      • Layout 1 cose-bilkent
      • Layout 2 cola

1.17.3.2. Kiali コンソールでのログの表示

Kiali コンソールでワークロードのログを表示できます。Workload Detail ページには Logs タブが含まれており、アプリケーションとプロキシーログの両方を表示する統一されたログビューが表示されます。Kiali でログ表示を更新する頻度を選択できます。

Kiali に表示されるログのロギングレベルを変更するには、ワークロードまたはプロキシーのロギング設定を変更します。

前提条件

  • Service Mesh がインストールされ、設定されている。
  • Kiali がインストールされ、設定されている。
  • Kiali コンソールのアドレス。
  • アプリケーションまたは Bookinfo サンプルアプリケーションがメッシュに追加されました。

手順

  1. Kiali コンソールを起動します。
  2. Log In With OpenShift をクリックします。

    Kiali Overview ページには、閲覧権限を持つメッシュに追加された namespace が表示されます。

  3. Workloads をクリックします。
  4. Workloads ページで、Namespace メニューからプロジェクトを選択します。
  5. 必要な場合は、フィルターを使用して、表示するログがあるワークロードを見つけます。ワークロードの名前をクリックします。たとえば、ratings-v1 をクリックします。
  6. Workload Details ページで、Logs タブをクリックしてワークロードのログを表示します。
ヒント

ログエントリーが表示されない場合は、時間範囲または更新間隔のいずれかの調整が必要になる場合があります。

1.17.3.3. Kiali コンソールでのメトリクスの表示

Kiali コンソールで、アプリケーション、ワークロード、サービスのインバウンドおよびアウトバウンドメトリクスを表示できます。詳細ページには、以下のタブが含まれます。

  • inbound Application metrics
  • outbound Application metrics
  • inbound Workload metrics
  • outbound Workload metrics
  • inbound Service metrics

これらのタブには、関連するアプリケーション、ワークロード、またはサービスレベルに合わせて調整された事前定義済みのメトリクスダッシュボードが表示されます。アプリケーションおよびワークロードの詳細ビューには、ボリューム、期間、サイズ、TCP トラフィックなどの要求および応答メトリクスが表示されます。サービスの詳細ビューには、インバウンドトラフィックの要求および応答メトリクスのみ表示されます。

Kiali では、チャート化されたディメンションを選択してチャートをカスタマイズできます。Kiali は、ソースまたは宛先プロキシーメトリクスによって報告されるメトリクスを表示することもできます。また、トラブルシューティングのために、Kiali はメトリクスでトレースをオーバーレイできます。

前提条件

  • Service Mesh がインストールされ、設定されている。
  • Kiali がインストールされ、設定されている。
  • Kiali コンソールのアドレス。
  • (オプション): 分散トレースがインストールされ、設定されます。

手順

  1. Kiali コンソールを起動します。
  2. Log In With OpenShift をクリックします。

    Kiali Overview ページには、閲覧権限を持つメッシュに追加された namespace が表示されます。

  3. ApplicationsWorkloads、または Services のいずれかをクリックします。
  4. ApplicationsWorkloads、または Services ページで、Namespace メニューからプロジェクトを選択します。
  5. 必要な場合は、フィルターを使用して、ログを表示するアプリケーション、ワークロード、またはサービスを検索します。名前をクリックします。
  6. Application DetailWorkload Details、または Service Details ページで、Inbound Metrics または Outbound Metrics タブをクリックしてメトリクスを表示します。

1.17.4. 分散トレース

分散トレースは、アプリケーションのサービス呼び出しのパスを追跡して、アプリケーション内の個々のサービスのパフォーマンスを追跡するプロセスです。アプリケーションでユーザーがアクションを起こすたびに、要求が実行され、多くのサービスが応答を生成するために対話が必要になる場合があります。この要求のパスは、分散トランザクションと呼ばれます。

Red Hat OpenShift Service Mesh は Red Hat OpenShift 分散トレースプラットフォームを使用して、開発者がマイクロサービスアプリケーションで呼び出しフローを表示できるようにします。

1.17.4.1. Red Hat OpenShift 分散トレーシングプラットフォーム (Tempo) と Red Hat build of OpenTelemetry の設定

ServiceMeshControlPlanespec.meshConfig.extensionProviders 仕様に名前付き要素と opentelemetry プロバイダーを追加することで、トレースデータを Red Hat OpenShift 分散トレーシングプラットフォーム (Tempo) に公開できます。次に、テレメトリーカスタムリソースは、トレーススパンを収集して OpenTelemetry Collector エンドポイントに送信するように Istio プロキシーを設定します。

メッシュ namespace に Red Hat build of OpenTelemetry を作成し、トレースデータをトレースプラットフォームバックエンドサービスに送信するように設定できます。

前提条件

  • tracing-system namespace で Red Hat Tempo Operator を使用して TempoStack インスタンスを作成しました。詳細は、「Red Hat OpenShift 分散トレーシングプラットフォーム (Tempo) のインストール」を参照してください。
  • Red Hat build of OpenTelemetry Operator を、推奨される namespace または openshift-operators namespace のいずれかにインストールしました。詳細は、「Red Hat build of OpenTelemetry のインストール」を参照してください。
  • Red Hat OpenShift Service Mesh 2.5 以前を使用している場合は、ServiceMeshControlPlane リソースの spec.tracing.type パラメーターを None に設定して、トレースデータを OpenTelemetry Collector に送信できるようにします。

手順

  1. メッシュ namespace に OpenTelemetry Collector インスタンスを作成します。この例では、info namespace を使用します。

    OpenTelemetry Collector の設定例

    apiVersion: opentelemetry.io/v1alpha1
    kind: OpenTelemetryCollector
    metadata:
      name: otel
      namespace: info  1
      annotations:
        sidecar.istio.io/inject: 'true' 2
    spec:
      mode: deployment
      config: |
        receivers:
          otlp:
            protocols:
              grpc:
                endpoint: 0.0.0.0:4317
        exporters:
          otlp:
            endpoint: "tempo-sample-distributor.tracing-system.svc.cluster.local:4317" 3
            tls:
              insecure: true
        service:
          pipelines:
            traces:
              receivers: [otlp]
              processors: []
              exporters: [otlp]

    1
    ServiceMeshMemberRoll メンバーリストに namespace を含めます。
    2
    サイドカーインジェクションアノテーションは、ServiceMeshControlPlane リソースで mTLS 暗号化の spec.security.dataPlane パラメーターを有効にする場合にのみ必要です。
    3
    この例では、TempoStack インスタンスが tracing-system namespace で実行しています。ServiceMeshMemberRoll メンバーリストに、`tracing-system` などの TempoStack namespace を含める必要はありません。
    注記

    ServiceMeshMemberRoll メンバー namespace の 1 つに OpenTelemetry Collector のインスタンスを 1 つだけ作成する必要があります。

  2. otel-collector Pod ログを確認し、Pod が実行中であることを確認します。

    otel-collector Pod ログチェックの例

    $ oc logs -n info  -l app.kubernetes.io/name=otel-collector

  3. istio-system namespace で ServiceMeshControlPlane カスタムリソース (CR) を作成または既存の ServiceMeshControlPlane を更新します。

    SMCP カスタムリソースの例

    kind: ServiceMeshControlPlane
    apiVersion: maistra.io/v2
    metadata:
      name: basic
      namespace: istio-system
    spec:
      addons:
        grafana:
          enabled: false
        kiali:
          enabled: true
        prometheus:
          enabled: true
      meshConfig:
        extensionProviders:
          - name: otel
            opentelemetry:
              port: 4317
              service: otel-collector.info.svc.cluster.local
      policy:
        type: Istiod
      telemetry:
        type: Istiod
      version: v2.6

    注記

    SMCP 2.5 から 2.6 にアップグレードする場合は、spec.tracing.type パラメーターを None に設定します。

    SMCP spec.tracing.type パラメーターの例

    spec:
      tracing:
        type: None

  4. istio-system namespace に Telemetry リソースを作成します。

    Telemetry リソースの例

    apiVersion: telemetry.istio.io/v1alpha1
    kind: Telemetry
    metadata:
      name: mesh-default
      namespace: istio-system
    spec:
      tracing:
      - providers:
        - name: otel
        randomSamplingPercentage: 100

  5. istiod ログを確認します。
  6. Kiali リソース仕様を設定して、Kiali ワークロードトレースダッシュボードを有効にします。ダッシュボードを使用して、トレースクエリーの結果を表示できます。

    Kiali リソースの例

    apiVersion: kiali.io/v1alpha1
    kind: Kiali
    # ...
    spec:
      external_services:
        tracing:
          query_timeout: 30 1
          enabled: true
          in_cluster_url: 'http://tempo-sample-query-frontend.tracing-system.svc.cluster.local:16685'
          url: '[Tempo query frontend Route url]'
          use_grpc: true 2

    1
    デフォルトの query_timeout 整数値は 30 秒です。値を 30 秒より大きく設定する場合は、Kiali CR の .spec.server.write_timeout を更新し、Kiali ルートに haproxy.router.openshift.io/timeout=50s アノテーションを追加する必要があります。.spec.server.write_timeouthaproxy.router.openshift.io/timeout= は両方とも query_timeout より大きくする必要があります。
    2
    デフォルトの HTTP または gRPC ポートを使用していない場合は、in_cluster_url: ポートをカスタムポートに置き換えます。
    注記

    Kiali 1.73 は、Jaeger Query API を使用するため、Tempo リソースの制限に応じて応答時間が長くなります。Kiali UI に Could not fetch spans のエラーメッセージが表示された場合は、Tempo 設定を確認するか、Kiali のクエリーごとの制限を減らしてください。

  7. アプリケーションにリクエストを送信します。
  8. istiod Pod ログと otel-collector Pod ログを確認します。
1.17.4.1.1. mTLS 暗号化された Service Mesh メンバー namespace での Red Hat OpenShift 分散トレーシングプラットフォーム (Tempo) の設定
注記

Service Mesh メンバー namespace ではない namespace に TempoStack インスタンスを作成した場合、この追加の DestinationRule 設定は必要ありません。

Service Mesh dataPlane mTLS 暗号化を有効にし、tracing-system-mtls などの Service Mesh メンバー namespace に TempoStack インスタンスを作成すると、すべてのトラフィックが TLS で暗号化されます。この暗号化は Tempo 分散サービスでは予期されていないため、TLS エラーが返されます。

TLS エラーを修正するには、Tempo と Kiali に DestinationRule を適用して TLS trafficPolicy を無効にします。

DestinationRule Tempo の例

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: tempo
  namespace: tracing-system-mtls
spec:
  host: "*.tracing-system-mtls.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: DISABLE

DestinationRule Kiali の例

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: kiali
  namespace: istio-system
spec:
  host: kiali.istio-system.svc.cluster.local
  trafficPolicy:
    tls:
      mode: DISABLE

1.17.4.2. 既存の分散トレーシングの Jaeger インスタンスへの接続

OpenShift Container Platform に既存の Red Hat OpenShift distributed tracing platform (Jaeger) インスタンスがある場合、distributed tracing platform にそのインスタンスを使用するように ServiceMeshControlPlane リソースを設定できます。

重要

Red Hat OpenShift Service Mesh 2.5 以降、Red Hat OpenShift 分散トレーシングプラットフォーム (Jaeger) と OpenShift Elasticsearch Operator が非推奨になりました。これらは今後のリリースで削除される予定です。Red Hat は、現行リリースのライフサイクル中はこれらの機能のバグ修正とサポートを提供しますが、今後これらの機能に対する機能強化は行われません。Red Hat OpenShift 分散トレーシングプラットフォーム (Jaeger) の代わりに、Red Hat OpenShift 分散トレーシングプラットフォーム (Tempo) を使用できます。

前提条件

  • Red Hat OpenShift 分散トレースプラットフォームインスタンスがインストールされ、設定されている。

手順

  1. OpenShift Container Platform Web コンソールで、Operators Installed Operators をクリックします。
  2. Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、ServiceMeshControlPlane リソースの名前 (basic など) をクリックします。
  4. 分散トレースプラットフォーム (Jaeger) インスタンスの名前を ServiceMeshControlPlane に追加します。

    1. YAML タブをクリックします。
    2. 分散トレースプラットフォーム (Jaeger) インスタンスの名前を ServiceMeshControlPlane リソースの spec.addons.jaeger.name に追加します。以下の例では、str-tracing-production は分散トレースプラットフォーム (Jaeger) インスタンスの名前です。

      分散トレースの設定例

      spec:
        addons:
          jaeger:
            name: distr-tracing-production

    3. Save をクリックします。
  5. Reload をクリックして、ServiceMeshControlPlane リソースが正しく設定されていることを確認します。

1.17.4.3. サンプリングレートの調整

トレースは、Service Mesh 内のサービス間の実行パスです。トレースは 1 つ以上のスパンで構成されます。スパンは、名前、開始時間、および期間を持つ作業の論理単位です。サンプリングレートは、トレースが永続化される頻度を決定します。

Envoy プロキシーのサンプリングレートは、デフォルトで Service Mesh でトレースの 100% をサンプリングするように設定されています。サンプリングレートはクラスターリソースおよびパフォーマンスを消費しますが、問題のデバッグを行う場合に役立ちます。Red Hat OpenShift Service Mesh を実稼働環境でデプロイする前に、値を小さめのトレースサイズに設定します。たとえば、spec.tracing.sampling100 に設定し、トレースの 1% をサンプリングします。

Envoy プロキシーサンプリングレートを、0.01% の増分を表すスケーリングされた整数として設定します。

基本的なインストールでは、spec.tracing.sampling10000 に設定され、トレースの 100% をサンプリングします。以下に例を示します。

  • この値を 10 サンプル (トレースの 0.1%) に設定します。
  • この値を 500 サンプル (トレースの 5%) に設定します。
注記

Envoy プロキシーサンプリングレートは、Service Mesh で利用可能なアプリケーションに適用され、Envoy プロキシーを使用します。このサンプリングレートは、Envoy プロキシーが収集および追跡するデータ量を決定します。

Jaeger リモートサンプリングレートは、Service Mesh の外部にあるアプリケーションに適用され、データベースなどの Envoy プロキシーを使用しません。このサンプリングレートは、分散トレースシステムが収集および保存するデータ量を決定します。詳細は、分散トレース設定オプション を参照してください。

手順

  1. OpenShift Container Platform Web コンソールで、Operators Installed Operators をクリックします。
  2. Project メニューをクリックし、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、ServiceMeshControlPlane リソースの名前 (basic など) をクリックします。
  4. サンプリングレートを調整するには、spec.tracing.sampling に別の値を設定します。

    1. YAML タブをクリックします。
    2. ServiceMeshControlPlane リソースで spec.tracing.sampling の値を設定します。以下の例では、100 に設定します。

      Jaeger サンプリングの例

      spec:
        tracing:
          sampling: 100

    3. Save をクリックします。
  5. Reload をクリックして、ServiceMeshControlPlane リソースが正しく設定されていることを確認します。

1.17.5. Jaeger コンソールへのアクセス

Jaeger コンソールにアクセスするには、Red Hat OpenShift Service Mesh がインストールされ、Red Hat OpenShift 分散トレースプラットフォーム (Jaeger) がインストールおよび設定されている必要があります。

インストールプロセスにより、Jaeger コンソールにアクセスするためのルートが作成されます。

Jaeger コンソールの URL が分かっている場合は、これに直接アクセスできます。URL が分からない場合は、以下の指示を使用します。

重要

Red Hat OpenShift Service Mesh 2.5 以降、Red Hat OpenShift 分散トレーシングプラットフォーム (Jaeger) と OpenShift Elasticsearch Operator が非推奨になりました。これらは今後のリリースで削除される予定です。Red Hat は、現行リリースのライフサイクル中はこれらの機能のバグ修正とサポートを提供しますが、今後これらの機能に対する機能強化は行われません。Red Hat OpenShift 分散トレーシングプラットフォーム (Jaeger) の代わりに、Red Hat OpenShift 分散トレーシングプラットフォーム (Tempo) を使用できます。

OpenShift コンソールからの手順

  1. cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。
  2. Networking Routes に移動します。
  3. Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例: istio-system)。

    Location 列には、各ルートのリンク先アドレスが表示されます。

  4. 必要な場合は、フィルターを使用して jaeger ルートを検索します。ルートの Location をクリックしてコンソールを起動します。
  5. Log In With OpenShift をクリックします。

Kiali コンソールからの手順

  1. Kiali コンソールを起動します。
  2. 左側のナビゲーションペインで Distributed Tracing をクリックします。
  3. Log In With OpenShift をクリックします。

CLI からの手順

  1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合) dedicated-admin ロールがあるアカウント。

    $ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
  2. コマンドラインを使用してルートの詳細をクエリーするには、以下のコマンドを入力します。この例では、istio-system が Service Mesh コントロールプレーンの namespace です。

    $ oc get route -n istio-system jaeger -o jsonpath='{.spec.host}'
  3. ブラウザーを起動し、https://<JAEGER_URL> に移動します。ここで、<JAEGER_URL> は直前の手順で検出されたルートです。
  4. OpenShift Container Platform コンソールへアクセスするときに使用するものと同じユーザー名とパスワードを使用してログインします。
  5. サービスメッシュにサービスを追加し、トレースを生成している場合は、フィルターと Find Traces ボタンを使用してトレースデータを検索します。

    コンソールインストールを検証すると、表示するトレースデータはありません。

Jaeger の設定に関する詳細は、分散トレースのドキュメント を参照してください。

1.17.6. Grafana コンソールへのアクセス

Grafana は、Service Mesh メトリクスの表示、クエリー、および分析に使用できる解析ツールです。この例では、istio-system が Service Mesh コントロールプレーンの namespace です。Grafana にアクセスするには、以下の手順を実施します。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Routes をクリックします。
  4. Grafana 行の Location コラムのリンクをクリックします。
  5. OpenShift Container Platform 認証情報を使用して Grafana コンソールにログインします。

1.17.7. Prometheus コンソールへのアクセス

Prometheus は、マイクロサービスに関する多次元データの収集に使用できるモニタリングおよびアラートツールです。この例では、istio-system が Service Mesh コントロールプレーンの namespace です。

手順

  1. OpenShift Container Platform Web コンソールにログインします。
  2. Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
  3. Routes をクリックします。
  4. Prometheus 行の Location コラムのリンクをクリックします。
  5. OpenShift Container Platform 認証情報を使用して Prometheus コンソールにログインします。

1.17.8. ユーザーのワークロード監視との統合

デフォルトでは、Red Hat OpenShift Service Mesh (OSSM) は、メッシュからメトリクスを収集するための Prometheus の専用インスタンスを含む Service Mesh コントロールプレーン (SMCP) をインストールします。ただし、実稼働システムには、ユーザー定義プロジェクトの OpenShift Container Platform モニタリングなど、より高度なモニタリングシステムが必要です。

次の手順では、Service Mesh をユーザーワークロードの監視と統合する方法を示します。

前提条件

  • ユーザーのワークロードの監視が有効になっている。
  • Red Hat OpenShift Service Mesh Operator 2.4 がインストールされている。
  • Kiali Operator 1.65 がインストールされている。

手順

  1. cluster-monitoring-view ロールを Kiali サービスアカウントに付与します。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: kiali-monitoring-rbac
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cluster-monitoring-view
    subjects:
    - kind: ServiceAccount
      name: kiali-service-account
      namespace: istio-system
  2. ユーザーワークロードを監視するために Kiali を設定します。

    apiVersion: kiali.io/v1alpha1
    kind: Kiali
    metadata:
      name: kiali-user-workload-monitoring
      namespace: istio-system
    spec:
      external_services:
        prometheus:
          auth:
            type: bearer
            use_kiali_token: true
          query_scope:
            mesh_id: "basic-istio-system"
          thanos_proxy:
            enabled: true
          url: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091
    • Istio Operator 2.4 を使用する場合は、次の設定を使用して Kiali をユーザーワークロードモニタリング用に設定します。

      apiVersion: kiali.io/v1alpha1
      kind: Kiali
      metadata:
        name: kiali-user-workload-monitoring
        namespace: istio-system
      spec:
        external_services:
          istio:
            config_map_name: istio-<smcp-name>
            istio_sidecar_injector_config_map_name: istio-sidecar-injector-<smcp-name>
            istiod_deployment_name: istiod-<smcp-name>
            url_service_version: 'http://istiod-<smcp-name>.istio-system:15014/version'
          prometheus:
            auth:
              token: secret:thanos-querier-web-token:token
              type: bearer
              use_kiali_token: false
            query_scope:
              mesh_id: "basic-istio-system"
            thanos_proxy:
              enabled: true
            url: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091
        version: v1.65
  3. 外部 Prometheus 用に SMCP を設定します。

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
      namespace: istio-system
    spec:
      addons:
        prometheus:
          enabled: false 1
        grafana:
          enabled: false 2
        kiali:
          name: kiali-user-workload-monitoring
      meshConfig:
        extensionProviders:
        - name: prometheus
          prometheus: {}
    1
    OSSM によって提供されるデフォルトの Prometheus インスタンスを無効にします。
    2
    Grafana を無効にします。外部 Prometheus インスタンスではサポートされていません。
  4. カスタムネットワークポリシーを適用して、モニタリング namespace からの受信トラフィックを許可します。

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: user-workload-access
      namespace: istio-system 1
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              network.openshift.io/policy-group: monitoring
      podSelector: {}
      policyTypes:
      - Ingress
    1
    カスタムネットワークポリシーはすべての namespace に適用する必要があります。
  5. Telemetry オブジェクトを適用して、Istio プロキシーのトラフィックメトリクスを有効にします。

    apiVersion: telemetry.istio.io/v1alpha1
    kind: Telemetry
    metadata:
      name: enable-prometheus-metrics
      namespace: istio-system 1
    spec:
      selector: 2
        matchLabels:
          app: info
      metrics:
      - providers:
        - name: prometheus
    1
    コントロールプレーンの namespace で作成された Telemetry オブジェクトは、メッシュ内のすべてのワークロードに適用されます。Telemetry を 1 つの namespace のみに適用するには、ターゲット namespace にオブジェクトを作成します。
    2
    オプション: selector.matchLabels 仕様を設定すると、ターゲット namespace 内の特定のワークロードに Telemetry オブジェクトが適用されます。
  6. ServiceMonitor オブジェクトを適用して Istio コントロールプレーンを監視します。

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: istiod-monitor
      namespace: istio-system 1
    spec:
      targetLabels:
      - app
      selector:
        matchLabels:
          istio: pilot
      endpoints:
      - port: http-monitoring
        interval: 30s
        relabelings:
        - action: replace
          replacement: "basic-istio-system" 2
          targetLabel: mesh_id
    1
    この ServiceMonitor オブジェクトは Istiod サービスを監視するため、Istio コントロールプレーン namespace に作成します。この例では、namespace は istio-system です。
    2
    文字列 "basic-istio-system" は、SMCP 名とその namespace の組み合わせですが、クラスター内のユーザーワークロード監視を使用するメッシュごとに一意である限り、任意のラベルを使用できます。ステップ 2 で設定した Kiali リソースの spec.prometheus.query_scope は、この値と一致する必要があります。
    注記

    ユーザーワークロードモニタリングを使用するメッシュが 1 つだけの場合、Kiali リソースの Mesh_id の再ラベル付けと spec.prometheus.query_scope フィールドは両方ともオプションです (ただし、mesh_id ラベルが削除される場合は、ここで指定される query_scope フィールドも削除される必要があります)。

    クラスター上の複数のメッシュインスタンスがユーザーワークロードのモニタリングを使用する可能性がある場合は、Kiali リソースの mesh_id の再ラベル付けと spec.prometheus.query_scope フィールドの両方が必要です。これにより、Kiali は関連付けられたメッシュからのメトリクスのみ参照します。

    Kiali をデプロイしていない場合でも、別のメッシュのメトリクスを区別できるように mesh_id の再ラベル付けを適用できます。

  7. PodMonitor オブジェクトを適用して、Istio プロキシーからメトリクスを収集します。

    apiVersion: monitoring.coreos.com/v1
    kind: PodMonitor
    metadata:
      name: istio-proxies-monitor
      namespace: istio-system 1
    spec:
      selector:
        matchExpressions:
        - key: istio-prometheus-ignore
          operator: DoesNotExist
      podMetricsEndpoints:
      - path: /stats/prometheus
        interval: 30s
        relabelings:
        - action: keep
          sourceLabels: [__meta_kubernetes_pod_container_name]
          regex: "istio-proxy"
        - action: keep
          sourceLabels: [__meta_kubernetes_pod_annotationpresent_prometheus_io_scrape]
        - action: replace
          regex: (\d+);(([A-Fa-f0-9]{1,4}::?){1,7}[A-Fa-f0-9]{1,4})
          replacement: '[$2]:$1'
          sourceLabels: [__meta_kubernetes_pod_annotation_prometheus_io_port,
          __meta_kubernetes_pod_ip]
          targetLabel: __address__
        - action: replace
          regex: (\d+);((([0-9]+?)(\.|$)){4})
          replacement: $2:$1
          sourceLabels: [__meta_kubernetes_pod_annotation_prometheus_io_port,
          __meta_kubernetes_pod_ip]
          targetLabel: __address__
        - action: labeldrop
          regex: "__meta_kubernetes_pod_label_(.+)"
        - sourceLabels: [__meta_kubernetes_namespace]
          action: replace
          targetLabel: namespace
        - sourceLabels: [__meta_kubernetes_pod_name]
          action: replace
          targetLabel: pod_name
        - action: replace
          replacement: "basic-istio-system" 2
          targetLabel: mesh_id
    1
    OpenShift Container Platform モニタリングは ServiceMonitor オブジェクトと PodMonitor オブジェクトの namespaceSelector 仕様を無視するため、コントロールプレーンの namespace を含むすべてのメッシュ namespace に PodMonitor オブジェクトを適用する必要があります。
    2
    文字列 "basic-istio-system" は、SMCP 名とその namespace の組み合わせですが、クラスター内のユーザーワークロード監視を使用するメッシュごとに一意である限り、任意のラベルを使用できます。ステップ 2 で設定した Kiali リソースの spec.prometheus.query_scope は、この値と一致する必要があります。
    注記

    ユーザーワークロードモニタリングを使用するメッシュが 1 つだけの場合、Kiali リソースの Mesh_id の再ラベル付けと spec.prometheus.query_scope フィールドは両方ともオプションです (ただし、mesh_id ラベルが削除される場合は、ここで指定される query_scope フィールドも削除される必要があります)。

    クラスター上の複数のメッシュインスタンスがユーザーワークロードのモニタリングを使用する可能性がある場合は、Kiali リソースの mesh_id の再ラベル付けと spec.prometheus.query_scope フィールドの両方が必要です。これにより、Kiali は関連付けられたメッシュからのメトリクスのみ参照します。

    Kiali をデプロイしていない場合でも、別のメッシュのメトリクスを区別できるように mesh_id の再ラベル付けを適用できます。

  8. OpenShift Container Platform Web コンソールを開き、メトリクスが表示されていることを確認します。

1.17.9. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.