1.15. メトリックス、ログ、およびトレース
アプリケーションをメッシュに追加したら、アプリケーション経由でデータフローを確認できます。独自のアプリケーションがインストールされていない場合は、Bookinfo サンプルアプリケーション をインストールして、Red Hat OpenShift Service Mesh で可観測性がどのように機能するかを確認できます。
1.15.1. コンソールアドレスの検出
Red Hat OpenShift Service Mesh は、サービスメッシュデータを表示する以下のコンソールを提供します。
- Kiali コンソール: Kiali は Red Hat OpenShift Service Mesh の管理コンソールです。
- Jaeger コンソール: Jaeger は Red Hat OpenShift 分散トレースの管理コンソールです。
- Grafana コンソール: Grafana は、Istio データの高度なクエリーとメトリックス分析およびダッシュボードをメッシュ管理者に提供します。任意で、Grafana を使用してサービスメッシュメトリクスを分析できます。
- Prometheus コンソール: Red Hat OpenShift Service Mesh は Prometheus を使用してサービスからのテレメトリー情報を保存します。
Service Mesh コントロールプレーンのインストール時に、インストールされた各コンポーネントのルートを自動的に生成します。ルートアドレスを作成したら、Kiali、Jaeger、Prometheus、または Grafana コンソールにアクセスして、サービスメッシュデータを表示および管理できます。
前提条件
- コンポーネントが有効で、インストールされていること。たとえば、分散トレースをインストールしていない場合、Jaeger コンソールにはアクセスできません。
OpenShift コンソールからの手順
-
cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合)
dedicated-admin
ロールがあるアカウント。 -
Networking
Routes に移動します。 Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例:
istio-system
)。Location 列には、各ルートのリンク先アドレスが表示されます。
- 必要な場合は、フィルターを使用して、アクセスするルートを持つコンポーネントコンソールを検索します。ルートの Location をクリックしてコンソールを起動します。
- Log In With OpenShift をクリックします。
CLI からの手順
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。$ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
Service Mesh コントロールプレーンプロジェクトに切り替えます。この例では、
istio-system
は Service Mesh コントロールプレーンプロジェクトです。以下のコマンドを実行します。$ oc project istio-system
各種 Red Hat OpenShift Service Mesh コンソールのルートを取得するには、以下のコマンドを実行します。
$ oc get routes
このコマンドは、Kiali、Jaeger、Prometheus、および Grafana Web コンソールの URL と、サービスメッシュ内の他のルートの 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
-
HOST/PORT
コラムからアクセスするコンソールの URL をブラウザーにコピーして、コンソールを開きます。 - Log In With OpenShift をクリックします。
1.15.2. Kiali コンソールへのアクセス
Kiali コンソールでアプリケーションのトポロジー、健全性、およびメトリクスを表示できます。サービスで問題が発生した場合、Kiali コンソールは、サービス経由でデータフローを表示できます。抽象アプリケーションからサービスおよびワークロードまで、さまざまなレベルでのメッシュコンポーネントに関する洞察を得ることができます。Kiali は、リアルタイムで namespace のインタラクティブなグラフビューも提供します。
Kiali コンソールにアクセスするには、Red Hat OpenShift Service Mesh がインストールされ、Kiali がインストールおよび設定されている必要があります。
インストールプロセスにより、Kiali コンソールにアクセスするためのルートが作成されます。
Kiali コンソールの URL が分かっている場合は、直接アクセスできます。URL が分からない場合は、以下の指示を使用します。
管理者の手順
- 管理者ロールで OpenShift Container Platform Web コンソールにログインします。
-
Home
Projects をクリックします。 - Projects ページで、必要に応じてフィルターを使用してプロジェクトの名前を検索します。
-
プロジェクトの名前 (例:
info
) をクリックします。 - Project details ページの Launcher セクションで、Kiali リンクをクリックします。
OpenShift Container Platform コンソールにアクセスするときに使用するものと同じユーザー名とパスワードを使用して Kiali コンソールにログインします。
初回の Kiali コンソールへのログイン時に、表示するパーミッションを持つサービスメッシュ内のすべての namespace を表示する Overview ページが表示されます。
コンソールのインストールを検証中で、namespace がまだメッシュに追加されていないと、
istio-system
以外のデータは表示されない可能性があります。
開発者の手順
- 開発者ロールで OpenShift Container Platform Web コンソールにログインします。
- Project をクリックします。
- 必要に応じて、Project Details ページで、フィルターを使用してプロジェクトの名前を検索します。
-
プロジェクトの名前 (例:
info
) をクリックします。 - Project ページの Launcher セクションで、Kiali リンクをクリックします。
- Log In With OpenShift をクリックします。
1.15.3. Kiali コンソールでのサービスメッシュデータの表示
Kiali グラフは、メッシュトラフィックの強力な視覚化を提供します。トポロジーは、リアルタイムの要求トラフィックを Istio 設定情報と組み合わせ、サービスメッシュの動作に関する洞察を即座に得て、問題を迅速に特定できるようにします。複数のグラフタイプを使用すると、トラフィックを高レベルのサービストポロジー、低レベルのワークロードトポロジー、またはアプリケーションレベルのトポロジーとして視覚化できます。
以下から選択できるグラフがいくつかあります。
- App グラフ は、同じラベルが付けられたすべてのアプリケーションの集約ワークロードを示します。
- Service グラフ は、メッシュ内の各サービスのノードを表示しますが、グラフからすべてのアプリケーションおよびワークロードを除外します。これは高レベルのビューを提供し、定義されたサービスのすべてのトラフィックを集約します。
- Versioned App グラフ は、アプリケーションの各バージョンのノードを表示します。アプリケーションの全バージョンがグループ化されます。
- Workload グラフ は、サービスメッシュの各ワークロードのノードを表示します。このグラフでは、app および version のラベルを使用する必要はありません。アプリケーションが version ラベルを使用しない場合は、このグラフを使用します。
グラフノードは、さまざまな情報で装飾され、仮想サービスやサービスエントリーなどのさまざまなルートルーティングオプションや、フォールトインジェクションやサーキットブレーカーなどの特別な設定を指定します。mTLS の問題、レイテンシーの問題、エラートラフィックなどを特定できます。グラフは高度な設定が可能で、トラフィックのアニメーションを表示でき、強力な検索機能や非表示機能があります。
Legend ボタンをクリックして、グラフに表示されるシェイプ、色、矢印、バッジに関する情報を表示します。
メトリクスの要約を表示するには、グラフ内のノードまたはエッジを選択し、そのメトリクスの詳細をサマリーの詳細パネルに表示します。
1.15.3.1. Kiali でのグラフレイアウトの変更
Kiali グラフのレイアウトは、アプリケーションのアーキテクチャーや表示データによって異なることがあります。たとえば、グラフノードの数およびそのインタラクションにより、Kiali グラフのレンダリング方法を判別できます。すべての状況に適した単一のレイアウトを作成することは不可能であるため、Kiali は複数の異なるレイアウトの選択肢を提供します。
前提条件
独自のアプリケーションがインストールされていない場合は、Bookinfo サンプルアプリケーションをインストールします。次に、以下のコマンドを複数回入力して Bookinfo アプリケーションのトラフィックを生成します。
$ curl "http://$GATEWAY_URL/productpage"
このコマンドはアプリケーションの
productpage
マイクロサービスにアクセスするユーザーをシミュレートします。
手順
- Kiali コンソールを起動します。
- Log In With OpenShift をクリックします。
- Kiali コンソールで、Graph をクリックし、namespace グラフを表示します。
-
Namespace メニューから、アプリケーション namespace (例:
info
) を選択します。 別のグラフレイアウトを選択するには、以下のいずれか、両方を行います。
グラフの上部にあるメニューから、異なるグラフデータグループを選択します。
- App graph
- Service graph
- Versioned App graph (デフォルト)
- Workload graph
グラフの下部にある Legend から別のグラフレイアウトを選択します。
- Layout default dagre
- Layout 1 cose-bilkent
- Layout 2 cola
1.15.3.2. Kiali コンソールでのログの表示
Kiali コンソールでワークロードのログを表示できます。Workload Details ページには Logs タブが含まれており、アプリケーションとプロキシーログの両方を表示する統一されたログビューが表示されます。Kiali でログ表示を更新する頻度を選択できます。
Kiali に表示されるログのロギングレベルを変更するには、ワークロードまたはプロキシーのロギング設定を変更します。
前提条件
- Service Mesh がインストールされ、設定されている。
- Kiali がインストールされ、設定されている。
- Kiali コンソールのアドレス。
- アプリケーションまたは Bookinfo サンプルアプリケーションがメッシュに追加されました。
手順
- Kiali コンソールを起動します。
Log In With OpenShift をクリックします。
Kiali Overview ページには、閲覧権限を持つメッシュに追加された namespace が表示されます。
- Workloads をクリックします。
- Workloads ページで、Namespace メニューからプロジェクトを選択します。
- 必要な場合は、フィルターを使用して、表示するログがあるワークロードを見つけます。ワークロードの名前をクリックします。たとえば、ratings-v1 をクリックします。
- Workload Details ページで、Logs タブをクリックしてワークロードのログを表示します。
ログエントリーが表示されない場合は、時間範囲または更新間隔のいずれかの調整が必要になる場合があります。
1.15.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 コンソールのアドレス。
- (オプション): 分散トレースがインストールされ、設定されます。
手順
- Kiali コンソールを起動します。
Log In With OpenShift をクリックします。
Kiali Overview ページには、閲覧権限を持つメッシュに追加された namespace が表示されます。
- Applications、Workloads、または Services のいずれかをクリックします。
- Applications、Workloads、または Services ページで、Namespace メニューからプロジェクトを選択します。
- 必要な場合は、フィルターを使用して、ログを表示するアプリケーション、ワークロード、またはサービスを検索します。名前をクリックします。
- Application Detail、Workload Details、または Service Details ページで、Inbound Metrics または Outbound Metrics タブをクリックしてメトリックスを表示します。
1.15.4. 分散トレース
分散トレースは、アプリケーションのサービス呼び出しのパスを追跡して、アプリケーション内の個々のサービスのパフォーマンスを追跡するプロセスです。アプリケーションでユーザーがアクションを起こすたびに、要求が実行され、多くのサービスが応答を生成するために対話が必要になる場合があります。この要求のパスは、分散トランザクションと呼ばれます。
Red Hat OpenShift Service Mesh は Red Hat OpenShift 分散トレースを使用して、開発者がマイクロサービスアプリケーションで呼び出しフローを表示できるようにします。
1.15.4.1. 既存の分散トレースインスタンスの接続
OpenShift Container Platform に既存の Red Hat OpenShift 分散トレースプラットフォームインスタンスがある場合、分散トレースにそのインスタンスを使用するように ServiceMeshControlPlane
リソースを設定できます。
前提条件
- Red Hat OpenShift 分散トレースインスタンスがインストールされ、設定されている。
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators をクリックします。 - Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
-
Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、
ServiceMeshControlPlane
リソースの名前 (basic
など) をクリックします。 分散トレースプラットフォームインスタンスの名前を
ServiceMeshControlPlane
に追加します。- YAML タブをクリックします。
分散トレースプラットフォームインスタンスの名前を
ServiceMeshControlPlane
リソースのspec.addons.jaeger.name
に追加します。以下の例では、str-tracing-production
は分散トレースプラットフォームインスタンスの名前です。分散トレースの設定例
spec: addons: jaeger: name: distr-tracing-production
- Save をクリックします。
-
Reload をクリックして、
ServiceMeshControlPlane
リソースが正しく設定されていることを確認します。
1.15.4.2. サンプリングレートの調整
トレースは、サービスメッシュ内のサービス間の実行パスです。トレースは、1 つ以上のスパンで設定されます。スパンは、名前、開始時間、および期間を持つ作業の論理単位です。サンプリングレートは、トレースが永続化される頻度を決定します。
Envoy プロキシーのサンプリングレートは、デフォルトでサービスメッシュでトレースの 100% をサンプリングするように設定されています。サンプリングレートはクラスターリソースおよびパフォーマンスを消費しますが、問題のデバッグを行う場合に役立ちます。Red Hat OpenShift Service Mesh を実稼働環境でデプロイする前に、値を小さめのトレースサイズに設定します。たとえば、spec.tracing.sampling
を 100
に設定し、トレースの 1% をサンプリングします。
Envoy プロキシーサンプリングレートを、0.01% の増分を表すスケーリングされた整数として設定します。
基本的なインストールでは、spec.tracing.sampling
は 10000
に設定され、トレースの 100% をサンプリングします。以下に例を示します。
- この値を 10 サンプル (トレースの 0.1%) に設定します。
- この値を 500 サンプル (トレースの 5%) に設定します。
Envoy プロキシーサンプリングレートは、Service Mesh で利用可能なアプリケーションに適用され、Envoy プロキシーを使用します。このサンプリングレートは、Envoy プロキシーが収集および追跡するデータ量を決定します。
Jaeger リモートサンプリングレートは、Service Mesh の外部にあるアプリケーションに適用され、データベースなどの Envoy プロキシーを使用しません。このサンプリングレートは、分散トレースシステムが収集および保存するデータ量を決定します。詳細は、分散トレース設定オプション を参照してください。
手順
-
OpenShift Container Platform Web コンソールで、Operators
Installed Operators をクリックします。 - Project メニューをクリックし、コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
-
Red Hat OpenShift Service Mesh Operator をクリックします。Istio Service Mesh Control Plane 列で、
ServiceMeshControlPlane
リソースの名前 (basic
など) をクリックします。 サンプリングレートを調整するには、
spec.tracing.sampling
に別の値を設定します。- YAML タブをクリックします。
ServiceMeshControlPlane
リソースでspec.tracing.sampling
の値を設定します。以下の例では、100
に設定します。Jaeger サンプリングの例
spec: tracing: sampling: 100
- Save をクリックします。
-
Reload をクリックして、
ServiceMeshControlPlane
リソースが正しく設定されていることを確認します。
1.15.5. Jaeger コンソールへのアクセス
Jaeger コンソールにアクセスするには、Red Hat OpenShift Service Mesh がインストールされ、Red Hat OpenShift 分散トレースプラットフォームがインストールおよび設定されている必要があります。
インストールプロセスにより、Jaeger コンソールにアクセスするためのルートが作成されます。
Jaeger コンソールの URL が分かっている場合は、これに直接アクセスできます。URL が分からない場合は、以下の指示を使用します。
OpenShift コンソールからの手順
-
cluster-admin 権限を持つユーザーとして OpenShift Container Platform Web コンソールにログインします。(Red Hat OpenShift Dedicated を使用する場合)
dedicated-admin
ロールがあるアカウント。 -
Networking
Routes に移動します。 Routes ページで、Namespace メニューから Service Mesh コントロールプレーンプロジェクトを選択します (例:
istio-system
)。Location 列には、各ルートのリンク先アドレスが表示されます。
-
必要な場合は、フィルターを使用して
jaeger
ルートを検索します。ルートの Location をクリックしてコンソールを起動します。 - Log In With OpenShift をクリックします。
Kiali コンソールからの手順
- Kiali コンソールを起動します。
- 左側のナビゲーションペインで Distributed Tracing をクリックします。
- Log In With OpenShift をクリックします。
CLI からの手順
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。$ oc login --username=<NAMEOFUSER> https://<HOSTNAME>:6443
コマンドラインを使用してルートの詳細をクエリーするには、以下のコマンドを入力します。この例では、
istio-system
が Service Mesh コントロールプレーンの namespace です。$ export JAEGER_URL=$(oc get route -n istio-system jaeger -o jsonpath='{.spec.host}')
-
ブラウザーを起動し、
https://<JAEGER_URL>
に移動します。ここで、<JAEGER_URL>
は直前の手順で検出されたルートです。 - OpenShift Container Platform コンソールへアクセスするときに使用するものと同じユーザー名とパスワードを使用してログインします。
サービスメッシュにサービスを追加し、トレースを生成している場合は、フィルターと Find Traces ボタンを使用してトレースデータを検索します。
コンソールインストールを検証すると、表示するトレースデータはありません。
Jaeger の設定に関する詳細は、分散トレースのドキュメント を参照してください。
1.15.6. Grafana コンソールへのアクセス
Grafana は、サービスメッシュメトリクスの表示、クエリー、および分析に使用できる解析ツールです。この例では、istio-system
が Service Mesh コントロールプレーンの namespace です。Grafana にアクセスするには、以下の手順を実施します。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
- Routes をクリックします。
- Grafana 行の Location コラムのリンクをクリックします。
- OpenShift Container Platform 認証情報を使用して Grafana コンソールにログインします。
1.15.7. Prometheus コンソールへのアクセス
Prometheus は、マイクロサービスに関する多次元データの収集に使用できるモニタリングおよびアラートツールです。この例では、istio-system
が Service Mesh コントロールプレーンの namespace です。
手順
- OpenShift Container Platform Web コンソールにログインします。
- Project メニューをクリックし、Service Mesh コントロールプレーンをインストールしたプロジェクト (例: istio-system) を選択します。
- Routes をクリックします。
- Prometheus 行の Location コラムのリンクをクリックします。
- OpenShift Container Platform 認証情報を使用して Prometheus コンソールにログインします。
1.15.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 がインストールされている。
手順
次のコマンドを実行して、Thanos for Kiali へのトークンを作成します。
次のコマンドを実行して、
SECRET
環境変数を設定します。$ SECRET=`oc get secret -n openshift-user-workload-monitoring | grep prometheus-user-workload-token | head -n 1 | awk '{print $1 }'`
次のコマンドを実行して、
TOKEN
環境変数を設定します。$ TOKEN=`oc get secret $SECRET -n openshift-user-workload-monitoring -o jsonpath='{.data.token}' | base64 -d`
次のコマンドを実行して、Thanos for Kiali へのトークンを作成します。
$ oc create secret generic thanos-querier-web-token -n istio-system --from-literal=token=$TOKEN
ユーザーワークロードを監視するために Kiali を設定します。
apiVersion: kiali.io/v1alpha1 kind: Kiali metadata: name: kiali-user-workload-monitoring namespace: istio-system spec: external_services: istio: url_service_version: 'http://istiod-basic.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
外部 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: {}
カスタムネットワークポリシーを適用して、モニタリング namespace からの受信トラフィックを許可します。
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: user-workload-access namespace: info 1 spec: ingress: - from: - namespaceSelector: matchLabels: network.openshift.io/policy-group: monitoring podSelector: {} policyTypes: - Ingress
- 1
- カスタムネットワークポリシーはすべての namespace に適用する必要があります。
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
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
- 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 が関連付けられたメッシュからのメトリックのみを参照できるように、Kiali リソースの
Mesh_id
の再ラベル付けとspec.prometheus.query_scope
フィールドの両方が必要です。Kiali がデプロイされていない場合でも、異なるメッシュのメトリックを互いに区別できるように、mesh_id
の再ラベル付けを適用することを推奨します。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 が関連付けられたメッシュからのメトリックのみを参照できるように、Kiali リソースの
Mesh_id
の再ラベル付けとspec.prometheus.query_scope
フィールドの両方が必要です。Kiali がデプロイされていない場合でも、異なるメッシュのメトリックを互いに区別できるように、mesh_id
の再ラベル付けを適用することを推奨します。- OpenShift Container Platform Web コンソールを開き、メトリックが表示されていることを確認します。