--- title: "Istio Prometheus連携の設定：istio_requests_totalの収集とGrafana・Kialiでの可視化【1.31系】" url: "https://www.issoh.co.jp/tech/details/18605/" published: 2026-10-20 updated: 2026-10-20 categories: ["Kubernetes・コンテナ"] publisher: "株式会社一創" --- # Istio Prometheus連携の設定：istio\_requests\_totalの収集とGrafana・Kialiでの可視化【1.31系】 IstioとPrometheusを組み合わせると、アプリのコードに手を入れずに、サービスごとのリクエスト数、エラー率、レイテンシを集められます。この記事では、標準メトリクスの読み方、既存のPrometheusへの収集設定、PromQL、GrafanaとKialiへのつなぎ方、時系列を抑える設定を、Istio 1.31系の公式ドキュメントに沿ったYAMLで示します。 ## まとめ：Envoyのメトリクスを集めreporterで絞りラベルを削る Istioのサイドカーやゲートウェイは、通過したリクエストを`istio_requests_total`などの標準メトリクスとして公開します。Prometheusはこれを収集するだけでよく、アプリ側に計装を足す必要はありません。検証なら`samples/addons`のPrometheus、Grafana、Kialiを`kubectl apply`で入れれば数分で画面まで届きます。 集計では、1回のリクエストが送信元と宛先の両方から報告される点に注意し、`reporter`ラベルをどちらかに固定します。そろえないと件数が2倍になります。 本番では、既存の監視基盤へscrapeの設定を足すか、記録ルールで集約した値をフェデレーションで送ります。ラベルの多さで時系列が膨らむため、Telemetry APIで不要なラベルを削る設計も最初から入れておきます。 ## Istioが出す標準メトリクスとPrometheusが集める対象を確認 Istio全体の仕組みは[Istioとは？サービスメッシュの仕組みとサイドカー/アンビエント方式・導入判断を解説](https://www.issoh.co.jp/tech/details/15568/)で扱っています。ここでは、Prometheusから見えるメトリクスの名前とラベルを押さえます。 ### HTTPとgRPCとTCPで出るistio\_で始まる標準メトリクス [Istio Standard Metricsのリファレンス](https://istio.io/latest/docs/reference/config/metrics/)によると、HTTP、HTTP/2、gRPCの通信では次のメトリクスが出ます。 - `istio_requests_total`（COUNTER）：処理したリクエスト数 - `istio_request_duration_milliseconds`（DISTRIBUTION）：リクエストの所要時間 - `istio_request_bytes`（DISTRIBUTION）：リクエスト本文の大きさ - `istio_response_bytes`（DISTRIBUTION）：レスポンス本文の大きさ gRPCではこれに加えて、メッセージ数を数える`istio_request_messages_total`と`istio_response_messages_total`が出ます。TCPの通信では、送受信バイト数の`istio_tcp_sent_bytes_total`と`istio_tcp_received_bytes_total`、接続の開始と終了を数える`istio_tcp_connections_opened_total`と`istio_tcp_connections_closed_total`の4つです。DISTRIBUTIONの型は、Prometheus上では`_bucket`、`_sum`、`_count`の3系列に分かれたヒストグラムとして見えます。 ### 集計時のreporterラベルと送信元・宛先のラベルの読み方 同じリファレンスは、メトリクスに付くラベルも定めています。集計でよく使うのは次のラベルです。 - `reporter`：宛先側のプロキシが報告したら`destination`、送信元側のプロキシかゲートウェイなら`source` - `source_workload`と`destination_workload`：呼び出し元と呼び出し先のワークロード名 - `destination_service`：宛先のサービスのホスト名（例：`details.default.svc.cluster.local`） - `response_code`：HTTPのステータスコード（HTTPのメトリクスだけに付く） - `connection_security_policy`：宛先側の報告でmTLSが使われていれば`mutual_tls` サイドカー方式では、1回の呼び出しが送信元と宛先の両方のサイドカーで数えられます。受信量は`reporter="destination"`、呼び出し元から見た遅延は`reporter="source"`と決めておくと、画面とアラートの数字が食い違いません。 ## samples/addonsでPrometheusとGrafanaとKialiを入れて試す まずは検証用のクラスタで、メトリクスが届くまでを確かめます。Istio本体のインストールにPrometheusは含まれないため、別に入れる必要があります。 ### kubectl applyでアドオンを入れistioctl dashboardで開く [IstioのPrometheus連携ページ](https://istio.io/latest/docs/ops/integrations/prometheus/)は、クイックスタートとして次のマニフェストを示しています。GrafanaとKialiも同じ`release-1.31`のディレクトリにあります。 ``` # Istio 1.31系に対応したアドオンを入れる kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.31/samples/addons/prometheus.yaml kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.31/samples/addons/grafana.yaml kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.31/samples/addons/kiali.yaml # Prometheusのサービスが起動したか確かめる kubectl -n istio-system get svc prometheus # ポートフォワードしてブラウザでUIを開く istioctl dashboard prometheus istioctl dashboard grafana istioctl dashboard kiali ``` [公式のQuerying Metricsタスク](https://istio.io/latest/docs/tasks/observability/metrics/querying-metrics/)の手順どおり、アプリに何度かリクエストを送ってから、PrometheusのUIで`istio_requests_total`を実行すると結果が返ります。公式はこれらをデモ用と明記しており、[Observability Best Practices](https://istio.io/latest/docs/ops/best-practices/observability/)によれば、クイックスタートのPrometheusの保持期間は6時間です。 ### 15020番ポートのメトリクスマージとプロキシからの直接確認 Prometheus連携ページによると、Istioは既定で「メトリクスマージ」を有効にしています。データプレーンのPodには`prometheus.io`のアノテーションが自動で付き、Envoyのメトリクスとアプリ自身のメトリクスがまとめて`:15020/stats/prometheus`から公開されます。 メトリクスが見えないときは、先にプロキシが値を出しているかを確かめます。[公式のCustomizing Istio Metricsタスク](https://istio.io/latest/docs/tasks/observability/metrics/customize-metrics/)の確認方法は次のとおりです。 ``` # サイドカーのEnvoyが出しているistio_requests_totalを直接見る kubectl exec "$(kubectl get pod -l app=productpage -o jsonpath='{.items[0].metadata.name}')" \ -c istio-proxy -- curl -sS 'localhost:15000/stats/prometheus' | grep istio_requests_total ``` ここに値があれば原因は収集の設定です。アプリが同名のメトリクスを出す場合やTLSで収集したい場合は、Podに`prometheus.istio.io/merge-metrics: "false"`を付けてマージを止めます。 ## 既存のPrometheusやOperatorにIstio向けの収集設定を足す すでに監視基盤のPrometheusがある場合は、アドオンを入れずにIstioの収集ジョブを追加します。Prometheusそのものの構築とexporterの設計は[Prometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積り](https://www.issoh.co.jp/tech/details/17516/)にまとめています。 ### scrape\_configsにistiodとenvoy-statsのジョブを追加する Prometheus連携ページが示すジョブは2本です。1本目はコントロールプレーンのistiodを、2本目はサイドカーとゲートウェイのEnvoyを対象にします。 ``` scrape_configs: - job_name: 'istiod' kubernetes_sd_configs: - role: endpoints namespaces: names: - istio-system relabel_configs: - source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] action: keep regex: istiod;http-monitoring - job_name: 'envoy-stats' metrics_path: /stats/prometheus kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_container_port_name] action: keep regex: '.*-envoy-prom' ``` envoy-statsのジョブは、コンテナのポート名が`-envoy-prom`で終わるものだけを残します。サイドカーが注入されたPodにはこの名前のポートが定義されるため、アプリのポートと取り違えずに済みます。 ### PodMonitorとServiceMonitorで集めるOperator向けの書き方 Prometheus Operatorやkube-prometheus-stackを使っている環境では、scrape\_configsを直接書かずにカスタムリソースで指定します。Istioのリポジトリにある[samples/addons/extras/prometheus-operator.yaml](https://github.com/istio/istio/blob/master/samples/addons/extras/prometheus-operator.yaml)から、要点を抜き出すと次のとおりです。 ``` apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: envoy-stats-monitor namespace: istio-system labels: monitoring: istio-proxies release: istio spec: selector: matchExpressions: - {key: istio-prometheus-ignore, operator: DoesNotExist} namespaceSelector: any: true jobLabel: envoy-stats podMetricsEndpoints: - path: /stats/prometheus interval: 15s relabelings: - action: keep sourceLabels: [__meta_kubernetes_pod_container_name] regex: "istio-proxy" - action: keep sourceLabels: [__meta_kubernetes_pod_annotationpresent_prometheus_io_scrape] --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: istio-component-monitor namespace: istio-system labels: monitoring: istio-components release: istio spec: jobLabel: istio targetLabels: [app] selector: matchExpressions: - {key: istio, operator: In, values: [pilot]} namespaceSelector: any: true endpoints: - port: http-monitoring interval: 15s ``` 原本のPodMonitorには収集先のアドレスを組み立てるrelabelingも続くため、適用には原本を使ってください。`release: istio`のラベルは、Prometheusリソースの`podMonitorSelector`と`serviceMonitorSelector`に合わせて書き換えます。一致しないと収集は始まりません。 ### STRICTのmTLS環境でアプリのメトリクスを集める証明書の設定 Prometheus連携ページによると、コントロールプレーン、ゲートウェイ、サイドカーのメトリクスは平文で収集されます。mTLSの影響を受けるのは、アプリ自身が出すメトリクスだけです。PeerAuthenticationが`STRICT`なら、Prometheusにもメッシュの証明書を持たせる必要があります。`PERMISSIVE`の場合は、PrometheusにTLSを設定してはいけません。 公式の方法は、Prometheusのポッドにサイドカーを注入しつつ、通信の横取りは止め、証明書だけを共有ボリュームへ書き出させるものです。 ``` # Prometheusのポッドテンプレートに付けるアノテーション traffic.sidecar.istio.io/includeInboundPorts: "" traffic.sidecar.istio.io/includeOutboundIPRanges: "" proxy.istio.io/config: | proxyMetadata: OUTPUT_CERTS: /etc/istio-output-certs sidecar.istio.io/userVolumeMount: '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]' # 収集ジョブ側のTLS設定 scheme: https tls_config: ca_file: /etc/prom-certs/root-cert.pem cert_file: /etc/prom-certs/cert-chain.pem key_file: /etc/prom-certs/key.pem insecure_skip_verify: true ``` Prometheusのコンテナには同じ`istio-certs`を`/etc/prom-certs/`にマウントします。`insecure_skip_verify`は、Istioのセキュアネーミングに未対応なため公式が付けている設定です。STRICT化の手順そのものは[Istio AuthorizationPolicyの書き方：ALLOW・DENYの評価順とmTLS前提のYAML例](https://www.issoh.co.jp/tech/details/18575/)で扱っています。 ## PromQLでリクエスト数とエラー率とP95レイテンシを出す 集めたメトリクスから、サービスの状態を表す数字を作ります。関数の詳細は[PrometheusのQuery functions](https://prometheus.io/docs/prometheus/latest/querying/functions/)にあります。 ### rateとsum byでサービスごとの毎秒リクエスト数を出す `istio_requests_total`は増え続けるカウンターなので、`rate`で毎秒の値に直してから集計します。 ``` # 宛先サービスごとの毎秒リクエスト数（過去5分の平均） sum by (destination_service_name, destination_service_namespace) ( rate(istio_requests_total{reporter="destination"}[5m]) ) # 呼び出し元と呼び出し先の組み合わせで見る sum by (source_workload, destination_workload) ( rate(istio_requests_total{reporter="destination"}[5m]) ) ``` 2本目は、どのサービスがどこを呼んでいるかを表で見るクエリです。`destination_workload`が`unknown`の行は宛先の情報が取れていない呼び出しで、メッシュ外への通信が混ざっていないかの手がかりになります。 ### 5xxのエラー率とhistogram\_quantileでP95を求めるクエリ エラー率は、5xxの件数を全体の件数で割って出します。レイテンシは`_bucket`の系列を`histogram_quantile`に渡します。 ``` # サービスごとの5xxエラー率（0〜1） sum by (destination_service_name) ( rate(istio_requests_total{reporter="destination", response_code=~"5.."}[5m]) ) / sum by (destination_service_name) ( rate(istio_requests_total{reporter="destination"}[5m]) ) # 呼び出し元から見たP95レイテンシ（ミリ秒） histogram_quantile(0.95, sum by (destination_service_name, le) ( rate(istio_request_duration_milliseconds_bucket{reporter="source"}[5m]) ) ) # mTLSを使っていない受信がないかを確かめる sum by (destination_workload) ( rate(istio_requests_total{reporter="destination", connection_security_policy!="mutual_tls"}[5m]) ) ``` `histogram_quantile`に渡す`sum by`には、必ず`le`を残します。`le`を落とすとバケットの境界が失われ、値が計算できません。3本目のクエリは、PERMISSIVEからSTRICTへ移す前に平文の通信が残っていないかを数えるのに使えます。エラー率やレイテンシをSLIとして扱う考え方は[SLIとは？SLOとの違いと指標の選び方・PromQLでの測り方](https://www.issoh.co.jp/tech/details/9177/)で解説しています。 ### PrometheusRuleでエラー率が上がったときのアラートを定義する Prometheus Operatorを使っている場合、上のエラー率の式をそのままアラートの条件にできます。閾値と継続時間は、サービスのSLOに合わせて決めてください。 ``` apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: istio-service-alerts namespace: monitoring spec: groups: - name: istio-service rules: - alert: IstioHigh5xxRate expr: | sum by (destination_service_name) ( rate(istio_requests_total{reporter="destination", response_code=~"5.."}[5m]) ) / sum by (destination_service_name) ( rate(istio_requests_total{reporter="destination"}[5m]) ) > 0.05 for: 10m labels: severity: warning annotations: summary: "{{ $labels.destination_service_name }} の5xx率が5%を超えています" ``` リクエストの少ない時間帯は1件の失敗で率が大きく振れるので、分母の値に`> 1`などの条件を`and`で足すと誤報が減ります。Kubernetes全体のアラート閾値の考え方は[Kubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断](https://www.issoh.co.jp/tech/details/15303/)にまとめています。 ## GrafanaのIstioダッシュボードとKialiを外部Prometheusへ接続 クエリを毎回書かなくても、Istioが用意したダッシュボードとKialiで全体を見渡せます。アドオンではなく既存のGrafanaやPrometheusを使う場合のつなぎ方を示します。 ### grafana.comのダッシュボードIDと既存Grafanaへの取り込み [IstioのGrafana連携ページ](https://istio.io/latest/docs/ops/integrations/grafana/)は、メッシュ全体、サービス別、ワークロード別、性能、コントロールプレーン、WebAssembly拡張、ztunnelの7種類のダッシュボードを挙げています。grafana.comでのIDは`7639`、`11829`、`7636`、`7630`、`7645`、`13277`、`21306`で、7639が[Istio Mesh Dashboard](https://grafana.com/grafana/dashboards/7639-istio-mesh-dashboard/)、21306がztunnel用です。 既存のGrafanaでは「Import」にIDを入れ、Istioのメトリクスを集めているPrometheusをデータソースに選びます。公式ページには7つをまとめて取り込むスクリプトも載っています。リビジョンはIstioの版ごとに作られるので、使っている版に合うものを選んでください。 ### KialiのCRでexternal\_servicesのPrometheus接続先を指定 Kialiは、Prometheusに入っている`istio_requests_total`などからトポロジー図と健全性を組み立てます。Prometheusにメトリクスが無ければ、図には何も描かれません。[Kiali OperatorのCRの記載例](https://github.com/kiali/kiali-operator/blob/master/crd-docs/cr/kiali.io%5Fv1alpha1%5Fkiali.yaml)では、接続先を`external_services`の下に書きます。 ``` apiVersion: kiali.io/v1alpha1 kind: Kiali metadata: name: kiali namespace: istio-system spec: external_services: prometheus: url: "http://prometheus-operated.monitoring:9090" grafana: enabled: true internal_url: "http://grafana.monitoring:3000" external_url: "https://grafana.example.com" ``` URLは自分の環境の値に置き換えます。`internal_url`はKialiのサーバーからの問い合わせ先、`external_url`はブラウザで開くリンク先です。[IstioのKiali連携ページ](https://istio.io/latest/docs/ops/integrations/kiali/)は、サンプルのKialiを外部に公開するならConfigMapの`signing_key`を変えるよう注意しており、本番はKialiプロジェクトの手順での導入を勧めています。 ## 時系列数を抑えるTelemetry APIと記録ルールの設計判断 標準メトリクスには20を超えるラベルが付き、サービスとバージョンとステータスコードの組み合わせごとに時系列ができます。メッシュが大きくなるほど、Prometheusのメモリとクエリ時間が膨らみます。 ### Telemetry APIでラベルの削除と追加・メトリクスの停止 [Telemetryリソースのリファレンス](https://istio.io/latest/docs/reference/config/telemetry/)には、ラベルを削る例と、メトリクスの出力を止める例が載っています。次の例は、特定のワークロードで`istio_requests_total`から`response_code`を外すものです。 ``` apiVersion: telemetry.istio.io/v1 kind: Telemetry metadata: name: remove-response-code namespace: foo spec: selector: matchLabels: service.istio.io/canonical-name: bar metrics: - providers: - name: prometheus overrides: - match: metric: REQUEST_COUNT tagOverrides: response_code: operation: REMOVE ``` `tagOverrides`に`value: "request.host"`のような式を書けばラベルを足せ、`metric: ALL_METRICS`と`mode: SERVER`に`disabled: true`を付けると受信側のメトリクスをまとめて止められます。利用者IDやリクエストパスのように値が際限なく増える項目は、ラベルに入れないでください。カーディナリティの考え方は[メトリクス監視とは｜4種のメトリック型・収集方式・アラート閾値の設計と導入判断を実装目線で解説](https://www.issoh.co.jp/tech/details/15704/)でも扱っています。 ### 記録ルールとフェデレーションで本番のPrometheusを軽くする Observability Best Practicesは、本番規模の監視には階層フェデレーションと記録ルールの組み合わせを勧めています。メッシュ側のPrometheusでPod単位の差を集約した系列を作り、本番のPrometheusはその集約済みの系列だけを取りに行く構成です。 ``` groups: - name: "istio.recording-rules" interval: 5s rules: - record: "workload:istio_requests_total" expr: | sum without(instance, kubernetes_namespace, kubernetes_pod_name) (istio_requests_total) - record: "workload:istio_request_duration_milliseconds_bucket" expr: | sum without(instance, kubernetes_namespace, kubernetes_pod_name) (istio_request_duration_milliseconds_bucket) ``` 上は公式の14本のうち2本の抜粋です。本番側は`/federate`から`workload:`で始まる系列を取り込み、`metric_relabel_configs`で接頭辞を外すので、既存のダッシュボードをそのまま使えます。 注意したいのは`sum without`で外すラベル名です。公式の記録ルールは`kubernetes_namespace`と`kubernetes_pod_name`を外しますが、同じページはクイックスタートのPrometheusが付けるラベルを`instance`、`pod`、`namespace`と説明しています。実際のラベル名にそろえないと、Pod単位の系列が集約されずに残ります。 ### アンビエント方式はztunnelがTCP分、waypointがL7分を出す サイドカーを使わないアンビエント方式では、メトリクスを出す場所が変わります。[Ambient data planeのページ](https://istio.io/latest/docs/ambient/architecture/data-plane/)によると、ノードごとのztunnelが出すのは標準メトリクスのうちTCPの系列です。`istio_requests_total`のようなHTTPの系列は出ません。 [Use Layer 7 featuresのページ](https://istio.io/latest/docs/ambient/usage/l7-features/)は、waypointプロキシを置くとIstioのトラフィックメトリクス一式が出ると説明しています。エラー率やレイテンシを見たいサービスには、waypointを置く前提で設計してください。 ### アドオンのまま使う条件と保持期間・監視要件で本番の監視基盤へ移す条件 アドオンのPrometheusで済むのは、検証環境と、直近数時間の様子が見えれば足りる小さなクラスタです。保持期間が6時間のため、障害の振り返りや容量計画には使えません。 本番の監視基盤へ移すのは、過去の障害を後から調べる、複数のクラスタをまとめて見る、Istio以外のメトリクスと同じ画面で見る、アラートを当番体制に流す、のどれかが必要な場合です。規模が大きければ記録ルールとフェデレーションを組み合わせます。 収集の設定やダッシュボードは、Istioの更新やサービスの追加に合わせて手直しが続きます。監視の運用まで含めて任せたい場合は、[保守運用 / 内製化支援](https://www.issoh.co.jp/service/system/maintenance/)のように、運用の引き受けから社内チームへの引き継ぎまでを相談できる窓口もあります。 ## Istio Prometheusの設定と運用で挙がるよくある質問 IstioのメトリクスをPrometheusで集め始めたときに出やすい疑問に、公式ドキュメントの記述をもとに答えます。 ### istio\_requests\_totalがPrometheusに表示されないのはなぜですか？ カウンターは通信が発生するまで現れないため、まずリクエストを流します。次にサイドカーの`localhost:15000/stats/prometheus`を見て、値があればPrometheusの収集ジョブ（アノテーション、PodMonitorのラベル選択、ポート名）を調べます。 ### アプリが出す独自のメトリクスも同じPrometheusで集められますか？ 同じPrometheusでの収集が可能です。既定のメトリクスマージでは、アプリのメトリクスも`:15020/stats/prometheus`から一緒に公開されます。マージを止めて個別に集めるなら、STRICTの環境ではPrometheus側に証明書の設定が要ります。 ### Kialiのトポロジー図に一部のサービスが表示されないのはなぜですか？ KialiはPrometheusのメトリクスから図を描くため、選んだ時間範囲に通信の無いサービスは線が出ません。Kialiが参照するPrometheusのURLが、メトリクスを集めているものと同じかも確かめてください。アンビエント方式でwaypointの無いサービスは、HTTPのメトリクスが出ない点にも注意します。 ### カナリアリリースの新旧バージョンを分けて比べられますか？ 比べられます。`destination_version`や`destination_canonical_revision`のラベルで分けて、エラー率とP95を並べます。Podの`version`ラベルが正しく付いていないと値が`unknown`になるため、Deploymentのラベルを先に確かめてください。重み付けの設定は[Istio VirtualServiceの書き方：DestinationRuleとカナリア・リトライのYAML例](https://www.issoh.co.jp/tech/details/18573/)を参照してください。 ### Istioのバージョンを上げるとダッシュボードや設定の変更が要りますか？ アドオンとダッシュボードは版ごとに用意されているため、`release-1.31`のようなURLは更新時に書き換えます。[Istioのサポート表](https://istio.io/latest/docs/releases/supported-releases/)を見ると、2026年10月時点のドキュメントは1.31系（1.31.2）が対象です。版ごとの差分は[Istioの最新バージョンは1.31｜1.28〜1.31の新機能・サポート期限とアップグレード手順](https://www.issoh.co.jp/tech/details/9698/)にまとめています。 ## 関連記事 - [Istioとは？サービスメッシュの仕組みとサイドカー/アンビエント方式・導入判断を解説](https://www.issoh.co.jp/tech/details/15568/)：Istio全体の仕組みと導入判断 - [Prometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積り](https://www.issoh.co.jp/tech/details/17516/)：Prometheus本体の構築と保持期間 - [Kubernetes監視・モニタリングの設計｜メトリクス・ログ・アラート閾値の実装判断](https://www.issoh.co.jp/tech/details/15303/)：クラスタ全体の監視設計 - [Istio Gatewayの設定方法：Ingress GatewayのYAML・TLS終端・Gateway API対応](https://www.issoh.co.jp/tech/details/18571/)：外部からの入口の設定 - [Istio AuthorizationPolicyの書き方：ALLOW・DENYの評価順とmTLS前提のYAML例](https://www.issoh.co.jp/tech/details/18575/)：サービス間認可とmTLS - [サービスメッシュとは？サイドカー方式の仕組みとAPIゲートウェイとの違い・導入判断を解説](https://www.issoh.co.jp/tech/details/13224/)：サービスメッシュの位置づけ - [Linkerdとは？軽量なRust製サービスメッシュの仕組みとIstioとの選び分けを解説](https://www.issoh.co.jp/tech/details/15570/)：より軽量なメッシュとの比較 --- 出典: [Istio Prometheus連携の設定：istio\_requests\_totalの収集とGrafana・Kialiでの可視化【1.31系】]()（株式会社一創）