Red Hat Connectivity Link 第4回: メトリクス監視でGateway APIを可視化する

はじめに

レッドハットのソリューションアーキテクトの森です。

第3回記事では、JWT（JSON Web Token）ベースの認証とロールベースアクセス制御（RBAC）について紹介しました。第4回の本記事では、Red Hat Connectivity Link（Kuadrant）のObservability機能に焦点を当て、メトリクス監視の実装方法を解説します。

これまでの記事で構築してきたGateway API環境（Gateway、HTTPRoute、各種Policy）が実際にどのように動作しているのか、トラフィックの状況やポリシーの適用状態を可視化することで、プラットフォームの運用管理が大きく改善されます。

過去の記事はこちらから

rheb.hatenablog.com

本記事で扱う内容

メトリクス収集の仕組み: OpenShift User Workload MonitoringとKuadrantの統合
3つのサンプルダッシュボード: Platform Engineer、App Developer、Business User向けの監視ビュー
実装手順: OpenShift環境でのGrafanaベース監視スタックの構築

メトリクス収集の仕組み

Red Hat Connectivity Link の observability は、 OpenShift User Workload Monitoring（Prometheus ベース監視基盤）と Kuadrant が提供するメトリクスを統合して実現されています。

Connectivity Link / Kuadrant / Envoy / Gateway API 関連コンポーネントは、 ServiceMonitor / PodMonitor を通じて Prometheus により収集されます。

収集したメトリクスは、必要に応じて Thanos Querier を介して集約され、 Grafana などの可視化ツールから PromQL クエリで参照できます。

アーキテクチャ概要

コンポーネントの役割

1. User Workload Monitoring (UWM)

OpenShift 4.x に組み込まれている監視機能で、ユーザーアプリケーションのメトリクス収集を担当します。

主な特徴:

Prometheusベースのメトリクス収集
ServiceMonitor/PodMonitor CRDによる動的な監視対象管理
Thanos統合による長期保存とクエリ統合
cluster-admin権限なしでの利用が可能

2. kube-state-metrics-kuadrant

Kuadrantが提供するカスタムメトリクスエクスポーターで、Gateway APIリソースの状態情報を収集します。

収集するメトリクス:

メトリクス名	説明	主要ラベル
`gatewayapi_httproute_labels`	HTTPRouteのラベル情報	`name`, `exported_namespace`, `service`, `deployment`
`gatewayapi_httproute_status_parent_info`	親Gatewayとの関連情報	`parent_name`, `parent_namespace`, `parent_kind`
`gatewayapi_httproute_created`	HTTPRoute作成時刻	`name`, `exported_namespace`
`gatewayapi_gateway_info`	Gateway基本情報	`name`, `exported_namespace`
`gatewayapi_gateway_status`	Gateway状態（Ready/Programmed）	`name`, `condition_type`, `condition_status`
`gatewayapi_gatewayclass_info`	GatewayClass情報	`name`, `controller_name`

重要な役割: このメトリクスは、Istioのトラフィックメトリクス（istio_requests_total等）とGateway APIリソースを紐付けるために使用されます。

例えば、以下のようなクエリで特定のHTTPRouteのトラフィックを抽出できます：

sum(rate(istio_requests_total{}[5m])) by (destination_service_name) 
* on(destination_service_name) group_left(name) 
(
  label_replace(
    gatewayapi_httproute_labels{name="news-api"}, 
    "destination_service_name", "$1", "service", "(.+)"
  )
)

3. Istio メトリクス

IstioのEnvoyプロキシが生成するトラフィックメトリクスです。

主要メトリクス:

メトリクス名	タイプ	説明
`istio_requests_total`	Counter	リクエスト総数
`istio_request_duration_milliseconds`	Histogram	リクエストレイテンシ
`istio_request_bytes`	Histogram	リクエストサイズ
`istio_response_bytes`	Histogram	レスポンスサイズ

デフォルトラベル:

destination_service_name: 宛先サービス名
response_code: HTTPステータスコード
request_protocol: プロトコル（http, grpc）
source_workload: 送信元ワークロード
reporter: メトリクスレポーター（source/destination）

拡張ラベル（Telemetry設定で追加）:

Kuadrantのダッシュボードでは、以下の追加ラベルが必要です：

request_url_path: リクエストパス（例: /technology, /sports）
request_host: リクエストホスト（例: api.example.com）
destination_port: 宛先ポート（例: 443）

これらはIstio Telemetry CRDで設定します（後述）。

4. Kuadrant コンポーネントメトリクス

Kuadrantの各コンポーネントも独自のメトリクスを公開しています：

Authorino（認証/認可）:

authorino_server_evaluator_*: 認証評価メトリクス
authorino_server_authconfig_*: AuthConfig状態

Limitador（レート制限）:

limitador_counter_*: カウンター値
limitador_limit_*: リミット設定

DNS Operator:

dns_provider_health_*: DNSプロバイダーヘルス

これらのメトリクスはServiceMonitorによって自動的に収集されます。

メトリクスフロー

収集: Prometheusが定期的（30秒間隔）にServiceMonitor/PodMonitorで定義されたエンドポイントからメトリクスをスクレイプ
保存: User Workload Monitoring Prometheusに24時間保存
統合: Thanos Querierが複数のPrometheusインスタンスからメトリクスを統合クエリ
可視化: GrafanaがThanos Querierに対してPromQLクエリを発行し、ダッシュボードに表示

3つのサンプルダッシュボード

Kuadrantプロジェクトは、異なる役割のユーザー向けに3つのGrafanaダッシュボードのサンプルを提供しています。

App Developer Dashboard

対象ユーザー: アプリケーション開発者、サービスオーナー

目的: 自分のHTTPRoute（API）のトラフィック、パフォーマンス、エラー状況の監視

主要パネル

1. Request breakdown by code (rate) (左側)

HTTPステータスコード別のリクエストレート（req/sec）
成功系（2xx）、リダイレクト（3xx）、クライアントエラー（4xx）、サーバーエラー（5xx）を色分け表示

画像では時系列でステータスコード別のトラフィック推移が確認できます。APIのトラフィックパターンと正常系/異常系の比率を把握できます。

2. Request latency percentiles (右側)

p95レイテンシ（95パーセンタイル）
p90レイテンシ
p99レイテンシ

画像では複数のパーセンタイルが重ねて表示されており、レスポンス時間の分布を把握できます。ユーザー体験に直結するレスポンス時間を監視します。

ユースケース例

シナリオ: APIのレスポンスが遅いという報告を受けた

App Developer Dashboardで確認：

Request latency percentiles (右側): p95レイテンシの推移を確認（通常時と比較）
Request breakdown by code (左側): ステータスコード分布から異常なエラー増加がないか確認

これにより、パフォーマンス問題の原因（トラフィック増、特定エンドポイントの問題、エラー率上昇等）を特定できます。

Business User Dashboard

対象ユーザー: プロダクトマネージャー、ビジネスアナリスト、エグゼクティブ

目的: ビジネスメトリクスとトレンド分析

主要パネル

1. Traffic Summary (左上)

時間帯別のリクエスト数
サービス別のトラフィック分布

ビジネス活動のパターンを把握できます。画像では時系列でトラフィックの推移が表示されています。

2. Historical Request Comparison (右上)

直近期間（most recent）と前期間（previous）のリクエスト数比較（棒グラフ）

トレンドの変化を視覚的に把握できます。画像では青い棒グラフで比較が表示されています。

3. Breakdown by Path (左下)

パス別のリクエストレート（req/sec）
パスごとの時系列グラフ

APIの各エンドポイントの利用状況を比較できます。画像では複数のパス（色分け）の推移が確認できます。

4. Total Requests for Selected Range (右下)

選択期間のトータルリクエスト数（パス別）
前期間との比較
増減率（Increase/Decrease列）

どのエンドポイントが成長/縮小しているかを一目で把握できます。

ユースケース例

シナリオ: 新機能リリース後の影響を評価したい

Business User Dashboardで確認：

Total Requests for Selected Range: リリース前後でトラフィックがどう変化したか（画像右下のテーブルで確認）
Breakdown by Path: 新しいエンドポイントへのアクセスが増えているか（画像左下のグラフで確認）
Historical Request Comparison: 前週/前月との比較（画像右上の棒グラフで確認）

これにより、新機能の採用状況とサービス品質への影響を評価できます。

Platform Engineer Dashboard

対象ユーザー: プラットフォームエンジニア、SRE、クラスター管理者

目的: Gateway APIインフラストラクチャ全体の健全性とポリシー適用状態の監視

主要パネル - Gatewaysセクション

上図では、Gatewaysセクションが表示されています：

1. Gateway Overview

Total: Gateway総数
Healthy: 正常なGateway数
Unhealthy: 異常なGateway数

2. Gateways テーブル

Gateway Class: 使用しているGatewayClass
Name: Gateway名
Namespace: デプロイ先namespace
Programmed: プログラミング状態
Accepted: 受理状態

3. Gateway Listeners

Gateway: Gateway名
Gateway NS: Gatewayのnamespace
Hostname: リスナーのホスト名
Listener: リスナー名
Port: ポート番号
Protocol: プロトコル

4. Gateway Policies

Kind: Policyの種類（TLSPolicy, RateLimitPolicy, AuthPolicy, DNSPolicy）
Name: Policy名
Namespace: デプロイ先namespace
Target Kind: 適用対象のリソース種別（Gateway）
Target Name: 適用対象のリソース名

このパネルで、クラスター内のGateway APIリソースの全体像とポリシー適用状態を一覧できます。

主要パネル - HTTPRoutesセクション

上図では、HTTPRoutesセクションが表示されています：

1. Total requests (graphs)

HTTPRoute別のリクエスト数推移（時系列グラフ）

2. Total Gateways (requests)

Gateway別のリクエスト数一覧

3. Request latency

HTTPRoute別のレイテンシ推移

このセクションで、各HTTPRouteのトラフィック状況とパフォーマンスを監視できます。

主要パネル - Alertsセクション

上図では、Alertsセクションが表示されています：

1. Alert Summary

Total Firing: 発火中のアラート数（画像では2）
Total Pending: 保留中のアラート数（画像では0）

2. Currently Active テーブル

現在検出中の Alert

AlertmanagerReceiversNotConfigured: Alertmanagerの通知先未設定（テスト環境では無視可能）
Watchdog: 監視システムが正常動作している証明（常時発火が正常）

3. Active State Timeline

時系列でアラートの発火状態を表示：

赤色: Firing（発火中）
オレンジ色: Pending（保留中）
緑色: Inactive（非アクティブ）

画像では複数のアラート（AlertmanagerReceiversNotConfigured, Watchdog, KubeContainerWaiting等）の状態推移が確認できます。

ユースケース例

シナリオ: 新しいHTTPRouteをデプロイ後、トラフィックが流れない

Platform Engineer Dashboardで確認：

Gateways テーブル: GatewayのProgrammedとAcceptedがTrueか確認（画像1枚目）
Gateway Policies: 関連するAuthPolicyやRateLimitPolicyが表示されているか確認（画像1枚目）
HTTPRoutes セクション: デプロイしたHTTPRouteがリクエストを受けているか確認（画像2枚目）
Alerts: 関連するアラートが発火していないか確認（画像3枚目）

これにより、問題の切り分けが迅速に行えます。

OpenShift環境への導入手順

ここからは、実際にOpenShift環境でGrafanaベースの監視スタックを構築する手順を解説します。

前提条件

以下が完了していることを前提とします：

Red Hat Connectivity Link 1.3 がインストール済み（第1回記事参照）
OpenShift CLI (oc) がインストール済みで、クラスターにログイン済み
cluster-admin権限 または以下の権限:
- User Workload Monitoringの有効化（openshift-monitoring namespaceの編集）
- Operatorのインストール（openshift-operators namespaceへのSubscription作成）
- 各namespaceでのリソース作成権限
（推奨）第2回記事で作成した環境 - Gateway、HTTPRoute、News APIがデプロイ済み

Step 1: Kuadrant Observability の有効化

Connectivity Link / Kuadrant のメトリクス収集を開始するには、Kuadrant CRで observability を有効化する必要があります。

1.1 有効化の設定

以下のように spec.observability.enable: true を追加します：

apiVersion: kuadrant.io/v1beta1
kind: Kuadrant
metadata:
  name: kuadrant
  namespace: kuadrant-system
spec:
  observability:
    enable: true #追加
  # ... その他の設定

1.2 有効化の確認

設定が反映されたことを確認します：

oc get kuadrant kuadrant -n kuadrant-system -o jsonpath='{.spec.observability.enable}'
# 出力: true

ServiceMonitorが作成されているか確認します：

oc get servicemonitor -n kuadrant-system

以下のようなServiceMonitorが表示されれば成功です：

NAME                         AGE
authorino-operator-monitor   22s
dns-operator-monitor         22s
kuadrant-authorino-monitor   22s
kuadrant-operator-monitor    22s
limitador-operator-monitor   22s

重要: この設定を有効化することで、Kuadrantの各コンポーネント（Authorino、Limitador、DNS Operator等）のメトリクスが収集可能になります。

Step 2: HTTPRouteラベルの確認と設定

メトリクス収集を正しく機能させるために、HTTPRouteに適切なラベルが設定されている必要があります。kube-state-metrics-kuadrantは、HTTPRouteのラベル情報をメトリクスに含めることで、ダッシュボードでDeploymentやServiceと紐付けた表示を可能にします。

HTTPRouteには、以下のラベルが設定されている必要があります：

deployment: バックエンドのDeployment名
service: バックエンドのService名

これらのラベルは、gatewayapi_httproute_labels メトリクスに含まれ、ダッシュボードのクエリで使用されます。

ラベルが不足している場合、HTTPRouteを更新します：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  ...
  labels:
    app: news-api
    deployment: news-api  # ラベル追加
    service: news-api     # ラベル追加
  ...
spec:
  ...

注意: - deployment ラベルの値は、実際のDeployment名と一致させてください - service ラベルの値は、実際のService名と一致させてください - 複数のHTTPRouteがある場合、それぞれに適切なラベルを設定してください

Step 3: User Workload Monitoring の有効化

OpenShiftのUser Workload Monitoring機能を有効化されていない場合は、設定を変更します。

3.1 ConfigMapの作成

User Workload Monitoringを有効化するConfigMapを作成します：

cat <<EOF | oc apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    enableUserWorkload: true
EOF

3.2 有効化の確認

User Workload Monitoring用のPodが起動するまで待ちます（通常30秒〜1分）：

oc get pods -n openshift-user-workload-monitoring

以下のようなPodが表示されれば成功です：

NAME                                   READY   STATUS    RESTARTS   AGE
prometheus-operator-xxx                2/2     Running   0          1m
prometheus-user-workload-0             6/6     Running   0          1m
prometheus-user-workload-1             6/6     Running   0          1m
thanos-ruler-user-workload-0           3/3     Running   0          1m
thanos-ruler-user-workload-1           3/3     Running   0          1m

重要: この設定はクラスター全体に影響するため、他のユーザーワークロードもメトリクス収集の対象になります。

Step 4: kube-state-metrics-kuadrant のデプロイ

Gateway APIリソースのメトリクスを収集するkube-state-metrics-kuadrantをデプロイします。

4.1 Kuadrant Observability設定の確認

Kuadrantが提供するサンプルのObservability設定を確認します：

https://raw.githubusercontent.com/Kuadrant/kuadrant-operator/v1.3.0/config/install/configure/observability/kustomization.yaml

この設定には以下が含まれます：

kube-state-metrics-kuadrantのDeployment
ServiceMonitor（Prometheus用のスクレイプ設定）
ConfigMap（カスタムリソースの定義）
RBAC（ClusterRole, ServiceAccount等）
Grafana Operator インストール

4.2 Observability設定の適用

Kustomizeを使用して設定を適用します：

oc apply -k 'https://github.com/Kuadrant/kuadrant-operator/config/install/configure/observability?ref=v1.3.0'

実行すると、以下のリソースが作成されます：

namespace/monitoring created
serviceaccount/kube-state-metrics-kuadrant created
clusterrole.rbac.authorization.k8s.io/kube-state-metrics-kuadrant created
clusterrolebinding.rbac.authorization.k8s.io/kube-state-metrics-kuadrant created
configmap/custom-resource-state created
service/kube-state-metrics-kuadrant created
deployment.apps/kube-state-metrics-kuadrant created
servicemonitor.monitoring.coreos.com/kube-state-metrics-kuadrant created
servicemonitor.monitoring.coreos.com/authorino-operator-metrics created
servicemonitor.monitoring.coreos.com/dns-operator-metrics-monitor created
servicemonitor.monitoring.coreos.com/kuadrant-operator-metrics created
servicemonitor.monitoring.coreos.com/limitador-operator-metrics created
subscription.operators.coreos.com/grafana-operator created

重要: このKustomizeには以下も含まれています：

Grafana Operator: コミュニティ版Grafana Operator v5が自動的にインストールされます
ServiceMonitor: Kuadrant各コンポーネント（Authorino、Limitador、DNS Operator等）のメトリクス収集設定

注意: gateway-system namespaceに関するエラーが表示されることがありますが、無視して問題ありません（Gateway API CRDの標準namespaceですが、実際には使用されません）。

Step 5: Istio Telemetry の設定

Istioメトリクスに追加ラベル（request_url_path等）を設定します。

5.1 istio-system namespace の確認

namespace: istio-system が存在しない場合は作成します：

oc create namespace istio-system

5.2 Telemetry リソースの作成

Istioの Telemetry リソースを作成します。 Istioメトリクスにrequest_url_path、request_host、destination_portラベルを追加します：

cat <<EOF | oc apply -f -
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: namespace-metrics
  namespace: istio-system
spec:
  metrics:
  - overrides:
    - match:
        metric: REQUEST_COUNT
      tagOverrides:
        destination_port:
          value: string(destination.port)
        request_host:
          value: request.host
        request_url_path:
          value: request.url_path
    - match:
        metric: REQUEST_DURATION
      tagOverrides:
        destination_port:
          value: string(destination.port)
        request_host:
          value: request.host
        request_url_path:
          value: request.url_path
    providers:
    - name: prometheus
EOF

Step 6: Grafana Instance のデプロイ

monitoring namespaceにGrafana Instanceを作成します。

6.1 ServiceAccount の作成

GrafanaがPrometheusにアクセスするためのServiceAccountを作成します：

oc create serviceaccount grafana-serviceaccount -n monitoring

6.2 権限の付与

重要: GrafanaがThanos Querierに接続するために、cluster-monitoring-view ClusterRoleを付与する必要があります。

oc adm policy add-cluster-role-to-user cluster-monitoring-view \
  system:serviceaccount:monitoring:grafana-serviceaccount

この権限により、GrafanaはThanos Querierからメトリクスを取得できます。

権限付与を確認：

oc get clusterrolebinding cluster-monitoring-view -o yaml | grep -A 3 "subjects:"

出力例：

subjects:
- kind: ServiceAccount
  name: grafana-serviceaccount
  namespace: monitoring

6.3 ServiceAccount Token Secret の作成

Kubernetes 1.24以降、ServiceAccountのTokenは自動生成されないため、明示的にSecretを作成します：

cat <<EOF | oc apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: grafana-serviceaccount-token
  namespace: monitoring
  annotations:
    kubernetes.io/service-account.name: grafana-serviceaccount
type: kubernetes.io/service-account-token
EOF

6.4 Grafana CR の作成

Grafana Instanceを定義します：

cat <<EOF | oc apply -f -
apiVersion: grafana.integreatly.org/v1beta1
kind: Grafana
metadata:
  name: grafana
  namespace: monitoring
  labels:
    dashboards: grafana
spec:
  config:
    security:
      admin_user: admin
      admin_password: grafana123
  route:
    spec:
      port:
        targetPort: 3000
      tls:
        insecureEdgeTerminationPolicy: Redirect
        termination: edge
      wildcardPolicy: None
EOF

設定のポイント:

admin_password: grafana123: テスト環境用の簡易パスワード（本番環境では変更必須）
route.spec: OpenShift RouteでHTTPS経由でアクセス可能に

6.5 Grafana起動の確認

Podが起動するまで待ちます（1〜2分）：

oc get pods -n monitoring -l app=grafana -w

RunningになればOKです。Ctrl+Cで監視を終了します。

Grafana CRの状態確認：

oc get grafana grafana -n monitoring -o jsonpath='{.status.stage}'

completeが表示されれば正常です。

6.6 Grafana URL の確認

作成されたRouteのURLを確認します：

oc get route grafana-route -n monitoring -o jsonpath='{.spec.host}'

出力例：

grafana-route-monitoring.apps.cluster-xxx.xxx.openshiftapps.com

ブラウザで https://<上記のホスト名> にアクセスし、ログイン画面が表示されることを確認します。

ログイン情報:

Username: admin
Password: grafana123

Step 7: Prometheus Datasource の設定

GrafanaからThanos Querierに接続するためのDatasourceを設定します。

7.1 Bearer Token の取得

ServiceAccountのTokenを取得します：

TOKEN=$(oc get secret grafana-serviceaccount-token -n monitoring -o jsonpath='{.data.token}' | base64 -d)
echo "Token length: ${#TOKEN}"

7.2 Token Secret の作成

Grafana Operatorが参照できるようにSecretを作成します：

cat <<EOF | oc apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: prometheus-bearer-token
  namespace: monitoring
stringData:
  token: "Bearer ${TOKEN}"
type: Opaque
EOF

7.3 Thanos Querier URL の取得

OpenShift MonitoringのThanos Querier URLを取得します：

CLUSTER_DOMAIN=$(oc get route console -n openshift-console -o jsonpath='{.spec.host}' | sed 's/^console-openshift-console\.//')
THANOS_URL="https://thanos-querier-openshift-monitoring.${CLUSTER_DOMAIN}"
echo "Thanos Querier URL: ${THANOS_URL}"

出力例：

Thanos Querier URL: https://thanos-querier-openshift-monitoring.apps.cluster-xxx.xxx.openshiftapps.com

7.4 GrafanaDatasource CR の作成

cat <<EOF | oc apply -f -
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDatasource
metadata:
  name: prometheus-datasource
  namespace: monitoring
spec:
  instanceSelector:
    matchLabels:
      dashboards: grafana
  datasource:
    name: Prometheus
    type: prometheus
    access: proxy
    url: ${THANOS_URL}
    isDefault: true
    jsonData:
      httpHeaderName1: Authorization
      timeInterval: 30s
      tlsSkipVerify: true
    secureJsonData:
      httpHeaderValue1: \${token}
  valuesFrom:
    - targetPath: secureJsonData.httpHeaderValue1
      valueFrom:
        secretKeyRef:
          name: prometheus-bearer-token
          key: token
EOF

設定のポイント:

url: Thanos QueryerのURL
httpHeaderName1: Authorization: Bearer Token認証を使用
tlsSkipVerify: true: 自己署名証明書を許可
secureJsonData.httpHeaderValue1: \${token}: プレースホルダー（Grafana Operatorが valuesFrom で指定された値に置き換える）
valuesFrom: Secret (prometheus-bearer-token) からBearerトークンを取得し、\${token} プレースホルダーを置き換え

7.5 Datasource の確認

GrafanaDatasource CRの状態を確認します：

oc get grafanadatasource prometheus-datasource -n monitoring

出力例：

NAME                    NO MATCHING INSTANCES   LAST RESYNC   AGE
prometheus-datasource                           30s           30s

LAST RESYNC に時間が表示されていれば、Grafana Operatorが同期処理を完了しています。

7.6 Grafana UIで接続テスト

重要: 必ずGrafana UIから接続テストを実施してください。

ブラウザでGrafanaにログイン:
- Username: admin
- Password: grafana123
Datasource接続テスト:
- 左メニュー > Connections > Data sources
- Prometheus をクリック
- 下部までスクロールして Save & test ボタンをクリック
成功メッセージを確認: ✓ Successfully queried the Prometheus API.

緑のチェックマークとこのメッセージが表示されれば成功です。

Step 8: Grafana Dashboard のインポート

Kuadrantの3つのサンプルダッシュボードをインポートします。

8.1 Platform Engineer Dashboard

cat <<EOF | oc apply -f -
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDashboard
metadata:
  name: platform-engineer-dashboard
  namespace: monitoring
spec:
  instanceSelector:
    matchLabels:
      dashboards: grafana
  datasources:
    - inputName: "DS_GRAFANACLOUD-KUADRANTDEV-PROM"
      datasourceName: "Prometheus"
  url: "https://raw.githubusercontent.com/Kuadrant/kuadrant-operator/refs/tags/v1.3.0/examples/dashboards/platform_engineer.json"
EOF

8.2 App Developer Dashboard

cat <<EOF | oc apply -f -
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDashboard
metadata:
  name: app-developer-dashboard
  namespace: monitoring
spec:
  instanceSelector:
    matchLabels:
      dashboards: grafana
  datasources:
    - inputName: "DS_GRAFANACLOUD-KUADRANTDEV-PROM"
      datasourceName: "Prometheus"
  url: "https://raw.githubusercontent.com/Kuadrant/kuadrant-operator/refs/tags/v1.3.0/examples/dashboards/app_developer.json"
EOF

8.3 Business User Dashboard

cat <<EOF | oc apply -f -
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDashboard
metadata:
  name: business-user-dashboard
  namespace: monitoring
spec:
  instanceSelector:
    matchLabels:
      dashboards: grafana
  datasources:
    - inputName: "DS_GRAFANACLOUD-KUADRANTDEV-PROM"
      datasourceName: "Prometheus"
  url: "https://raw.githubusercontent.com/Kuadrant/kuadrant-operator/refs/tags/v1.3.0/examples/dashboards/business_user.json"
EOF

インポート方法のポイント:

spec.url: GitHubのサンプルのJSONを直接参照
datasources: ダッシュボード内のDatasource名をマッピング
Grafana Operatorが自動でJSONをダウンロードしてインポート

8.4 Dashboard の確認

Grafana Operatorがダッシュボードを同期するまで待ちます（30秒〜1分）：

CRの状態確認：

oc get grafanadashboard -n monitoring

出力例：

NAME                          NO MATCHING INSTANCES   LAST RESYNC   AGE
app-developer-dashboard                               45s           45s
business-user-dashboard                               44s           44s
platform-engineer-dashboard                           46s           46s

Grafana UIで確認： 1. Grafanaにログイン 2. 左メニュー > Dashboards 3. 3つのダッシュボードが表示されていることを確認

Step 9: 動作確認

9.1 メトリクス収集の確認

Gateway APIメトリクスが収集されているか確認：

# HTTPRouteメトリクスの確認
oc exec -n openshift-user-workload-monitoring prometheus-user-workload-0 -c prometheus -- \
  promtool query instant http://localhost:9090 \
  'gatewayapi_httproute_labels{name="news-api"}'

メトリクスが返ってくればOKです。

9.2 トラフィックの生成

ダッシュボードにデータを表示するため、テストリクエストを送信します：以下は、第2回記事で使用したリソースをデプロイしている場合の例です。

# 環境変数設定
API_KEY=$(oc get secret api-keys -n kuadrant-system -o jsonpath='{.data.api_key}' | base64 -d)
GATEWAY_HOST=$(oc get gateway external -n api-gateway -o jsonpath='{.spec.listeners[0].hostname}')

# リクエスト送信（複数回）
for i in {1..10}; do
  curl -sk -H "Authorization: APIKEY ${API_KEY}" https://${GATEWAY_HOST}/
  curl -sk -H "Authorization: APIKEY ${API_KEY}" https://${GATEWAY_HOST}/technology
  curl -sk -H "Authorization: APIKEY ${API_KEY}" https://${GATEWAY_HOST}/sports
  sleep 1
done

9.3 App Developer Dashboard の確認

Grafanaにアクセス: https://<grafana-route-host>
左メニュー > Dashboards > App Developer Dashboard
上部の変数セレクターで：
- route_name: news-apiを選択
- api_namespace: news-apiを選択
以下を確認：
- Request breakdown by code (左上): ステータスコード別のリクエストレートグラフ
- Request latency percentiles (右上): p95, p90, p99レイテンシのグラフ
- Request breakdown by code and path (左下): パス別・コード別の詳細グラフ
- Request latency by code and path (p95) (右下): パス別p95レイテンシ

9.4 Business User Dashboard の確認

Dashboards > Business User Dashboard
以下を確認：
- Total Requests for Selected Range (右下): パス別リクエスト数のテーブル
  - /, /technology, /sports が表示される
- Breakdown by Path (左下): パス別のトラフィックグラフ
- Historical Request Comparison (右上): 期間比較の棒グラフ

9.5 Platform Engineer Dashboard の確認

Dashboards > Platform Engineer Dashboard
以下を確認：
- Gateways: Gateway数とステータス、Policyの適用状態
- HTTPRoutes: HTTPRoute別のトラフィックとレイテンシ
- Alerts: 発火中のアラート一覧

注意: メトリクスが表示されるまで1〜2分かかる場合があります。データが表示されない場合は、ブラウザをリフレッシュしてください。

まとめ

本記事では、Red Hat Connectivity LinkのObservability機能として、メトリクス監視の実装方法を解説しました。

構築した環境

OpenShift User Workload Monitoring: Prometheusベースのメトリクス収集基盤
kube-state-metrics-kuadrant: Gateway APIリソースのメトリクス収集
Istio Telemetry: トラフィックメトリクスへの追加ラベル設定
Grafana監視スタック: 3つの役割別ダッシュボード

3つのダッシュボードの使い分け

ダッシュボード	対象ユーザー	主な用途	確認する内容
App Developer	アプリケーション開発者	API監視	トラフィック、レイテンシ、エラー率
Business User	PM、アナリスト	ビジネスメトリクス	リクエスト数トレンド、パス別分析
Platform Engineer	SRE、クラスター管理者	インフラ全体監視	Gateway/Policy状態、コンポーネントヘルス、アラート

はじめに

本記事で扱う内容

メトリクス収集の仕組み

アーキテクチャ概要

コンポーネントの役割

1. User Workload Monitoring (UWM)

2. kube-state-metrics-kuadrant

3. Istio メトリクス

4. Kuadrant コンポーネントメトリクス

メトリクスフロー

3つのサンプルダッシュボード

App Developer Dashboard

主要パネル

ユースケース例

Business User Dashboard

主要パネル

ユースケース例

Platform Engineer Dashboard

主要パネル - Gatewaysセクション

主要パネル - HTTPRoutesセクション

主要パネル - Alertsセクション

ユースケース例

OpenShift環境への導入手順

前提条件

Step 1: Kuadrant Observability の有効化

1.1 有効化の設定

1.2 有効化の確認

Step 2: HTTPRouteラベルの確認と設定

Step 3: User Workload Monitoring の有効化

3.1 ConfigMapの作成

3.2 有効化の確認

Step 4: kube-state-metrics-kuadrant のデプロイ

4.1 Kuadrant Observability設定の確認

4.2 Observability設定の適用

Step 5: Istio Telemetry の設定

5.1 istio-system namespace の確認

5.2 Telemetry リソースの作成

Step 6: Grafana Instance のデプロイ

6.1 ServiceAccount の作成

6.2 権限の付与

6.3 ServiceAccount Token Secret の作成

6.4 Grafana CR の作成

6.5 Grafana起動の確認

6.6 Grafana URL の確認

Step 7: Prometheus Datasource の設定

7.1 Bearer Token の取得

7.2 Token Secret の作成

7.3 Thanos Querier URL の取得

7.4 GrafanaDatasource CR の作成

7.5 Datasource の確認

7.6 Grafana UIで接続テスト

Step 8: Grafana Dashboard のインポート

8.1 Platform Engineer Dashboard

8.2 App Developer Dashboard

8.3 Business User Dashboard

8.4 Dashboard の確認

Step 9: 動作確認

9.1 メトリクス収集の確認

9.2 トラフィックの生成

9.3 App Developer Dashboard の確認

9.4 Business User Dashboard の確認

9.5 Platform Engineer Dashboard の確認

まとめ

構築した環境

3つのダッシュボードの使い分け

参考リンク