アービトレーションサービスの監視

概要

アービトレーションサービス（Arbitration Service）は、Prometheusプロトコルを介したモニタリングメトリクスの収集をサポートしています。アービトレーションサービスには標準のGET /metricsインターフェースが組み込まれており、arbserverのCPU、メモリ、ディスク使用率、および現在管理されているクラスタ、テナント、LS、選挙、設定バージョン、モードバージョン、RPC遅延などのメトリクスを取得できます。

アービトレーションサービスは、組み込みのHTTP Serverを通じてモニタリングメトリクスを公開しています。Prometheus Serverを使用してこれらのメトリクスデータを取得・保存し、Grafanaでメトリクスを表示し、Alertmanagerでアラートを送信できます。この機能にはPrometheus、Grafana、Alertmanagerのインストールと設定は含まれません。これらの外部コンポーネントはご自身でデプロイおよび設定する必要があります。

アービトレーションサービスのPrometheusモニタリングメトリクスを利用することで、arbserverのリソース使用状況（CPU、メモリ、ディスク使用率）をリアルタイムで把握し、現在管理されているクラスタ、テナント、LSの数を確認し、各LSのリーダー状態や選挙頻度を監視し、設定バージョンやモードバージョンの変更履歴を追跡し、RPC遅延がネットワーク伝送段階とサーバー処理段階でどのように分布しているかを分析できます。

前提条件

• 現在のクラスタにアービトレーションサービスがデプロイ済みであること。アービトレーションサービスのデプロイ手順の詳細については、2レプリカ + アービトレーションサービスのOceanBaseクラスタのデプロイを参照してください。
• 外部環境にPrometheus Serverがデプロイ済みであり、Prometheus Serverとarbserver間のネットワーク相互接続が確保されていること。
• （オプション）可視化表示やアラートが必要な場合は、GrafanaとAlertmanagerもデプロイする必要があります。

Prometheusによるスクレイピングの設定

メトリクス収集ポートの設定

アービトレーションサービスは、構成パラメータprometheus_metrics_portを使用してメトリクス収集ポートの有効化と無効化を制御します。このサービスを有効にするには、以下の2つの方法があります：

方法1：

アービトレーションサービスの起動設定にポートパラメータを追加することで、メトリクス収集インターフェースを有効にできます。例：

-o "ob_startup_mode=arbitration,prometheus_metrics_port=2886"

完全な起動コマンドについては、コマンドラインを使用した2レプリカ + アービトレーションサービスのOceanBaseクラスタのデプロイを参照してください。

デフォルト設定を使用する場合、ポートを明示的に入力する必要はありません。arbserverは2886をリッスンしようと試みます。メトリクス収集インターフェースを無効にするには、このパラメータを0に設定します。例：

-o "ob_startup_mode=arbitration,prometheus_metrics_port=0"

方法2：

クラスタの稼働中にalter system setを使用してポートを変更し、arbserverプロセスを再起動することで変更が有効になります。

1. alter system setを使用してポートを変更します。

   alter system set prometheus_metrics_port = 2887;
   

2. アービトレーションサービスプロセスを再起動することで変更が有効になります。

アービトレーションサービスは特別モードで起動する軽量なobserverプロセスです。ノードプロセスの再起動については、ノードの再起動を参照してください。

この場合、メトリクス収集インターフェースを無効にするには、prometheus_metrics_portのポート番号を0に変更した後、再度再起動する必要があります。

動作の説明

prometheus_metrics_port構成パラメータの異なる設定シナリオにおける動作の説明は以下のとおりです。

• ポートが明示的に設定されていない場合：デフォルトポート 2886 を使用して /metrics を公開します。
• 他の正の数値に設定されている場合：arbserver が再起動すると、指定されたポートをリスニングするように変更されます。
• 0 に設定されている場合：メトリクス HTTP サーバーは起動せず、/metrics はアクセスできません。
• ポートを変更したが再起動していない場合：arbserver が再起動するまで、元のポートを引き続き使用します。
• ポートが既に使用中またはリスニングに失敗した場合：メトリクスサービスの初期化に失敗し、自動的に閉じられます。すべてのメトリクスは更新されなくなりますが、arbserver の正常な起動には影響しません。同時に、システムはログに WARN レベルのリスニングエラーメッセージ（disable Prometheus monitoring）を記録します。ポート競合問題が解決した後、メトリクス収集を復旧するには、arbserver を再起動する必要があります。
• 1つのarbserverが複数のクラスタにサービスを提供する場合：各収集周期で同じエンドポイントを複数回スクレイピングする必要はありません。LSメトリクスは、ラベルによってクラスタ、テナント、LSを区別します。
• arbserverが再起動した場合：永続化された状態から管理オブジェクトおよび関連するバージョンのメトリクスを再読み込みします。

メトリクスインターフェースの可用性検証

設定完了後、curl コマンドを使用してメトリクスインターフェースが正常にアクセス可能かどうかを検証できます。

Prometheus Server または同一収集ネットワーク内のマシンで以下のコマンドを実行します：

curl -fsS http://<arbserver_ip>:2886/metrics

正常な応答には # HELP、# TYPE、および arb_* メトリクスデータが含まれます。応答例は以下のとおりです：

# HELP arb_cluster_count number of clusters managed
# TYPE arb_cluster_count gauge
arb_cluster_count 1

スクレイピング設定

Prometheusの設定ファイルであるprometheus.ymlに、arbserverのメトリクスデータを取得するためのスクレイプジョブを追加します。設定例は以下のとおりです：

scrape_configs:
  - job_name: oceanbase-arbserver
    metrics_path: /metrics
    scrape_interval: 15s
    static_configs:
      - targets:
          - <arbserver_ip>:2886
        labels:
          service: arbserver

構成パラメータの説明は以下のとおりです：

複数のarbserverインスタンスがある場合は、各インスタンスのアドレスを targets リストに追加するか、デプロイメントプラットフォームの既存のサービスディスカバリメカニズムに接続する必要があります。Prometheusスクレイピング設定の詳細な形式については、Prometheus Configurationを参照してください。

スクレイピング状態の検証

スクレイピング設定が完了したら、以下の手順に従って、Prometheusがarbserverメトリクスを正常に取得したかどうかを検証してください。

1. Prometheus Server上で prometheus ユーザーを使用して、設定ファイルの構文が正しいかどうか確認します。

   promtool check config <prometheus.yml>
   

   設定ファイルの構文が正しい場合、出力結果に SUCCESS が表示されます。

2. Prometheus Server上でPrometheusサービスをリロードまたは再起動し、設定を有効にします。

   • Prometheusでホットリロード機能が有効になっている場合、ネットワークアクセス権限を持つ任意のユーザーがHTTP APIを使用して設定の再読み込みをトリガーできます：

     curl -X POST http://<prometheus_ip>:9090/-/reload
     

   • rootユーザーを使用するか、sudo権限を使用してPrometheusサービスを直接再起動することもできます：

     sudo systemctl restart prometheus
     

   sudo journalctl -u prometheus -fでログを確認し、Completed loading of configuration file が表示され、エラーがないことを確認します。

3. Prometheus Web UIにアクセス可能な任意のマシンで、arbserverのtarget状態が UP であることを確認します。

   説明

   upはPrometheusが各スクレイピングターゲットごとに自動生成するメトリクスであり、arbserver自体が公開する arb_* メトリクスには含まれません。状態がUPであることは、PrometheusサーバーがarbserverのexposerにHTTPリクエストを正常に送信し、形式に合致する応答を正常に受信したことを意味します。

   • ブラウザを使用して http://<prometheus_ip>:9090/targets にアクセスし、targetリストで oceanbase-arbserver を見つけて、その状態が UP であることを確認します。

   • Prometheus APIにアクセス可能な任意のマシンでコマンドを使用してtarget状態を確認することもできます。例：

     curl -s http://<prometheus_ip>:9090/api/v1/targets | grep -o '"health":"[^"]*"'
     

4. Prometheus APIにアクセス可能な任意のマシンで、up メトリクスを照会してarbserverが正常にスクレイピングされたことを確認します。例：

   curl -s "http://<prometheus_ip>:9090/api/v1/query?query=up%7Bjob%3D%22oceanbase-arbserver%22%7D"
   

   実行結果で value が 1 の場合、スクレイピングは正常です。0 の場合、スクレイピングに失敗したため、Prometheusとarbserver間のネットワーク接続性とポート設定を調査する必要があります。

5. Prometheus APIにアクセス可能な任意のマシンで、arb_cluster_count、arb_ls_has_leader などのビジネスメトリクスを照会して、arbserverのメトリクスが正常に収集されたことを確認します。例：

   curl -s "http://<prometheus_ip>:9090/api/v1/query?query=arb_cluster_count"
   

   すべての arb_ プレフィックスのメトリクスを一覧表示して、メトリクスが完全に収集されたことを確認することもできます。例：

   curl -s "http://<prometheus_ip>:9090/api/v1/label/__name__/values" | grep '^arb_'
   

指標の説明

arbserverは現在、リソースと管理規模、LS状態、RPC遅延の3つのカテゴリに分類される13個の論理指標を提供しています。

リソースと管理規模

LS状態

以下の指標にはすべてcluster_id、tenant_id、ls_idのラベルが付いており、異なるクラスタ、テナント、ログストリームを区別するために使用されます。

RPC遅延

Histogramタイプの指標は、/metrics配下で _bucket、_sum、_countに展開されます。デフォルトのbucketは以下のとおりです：

100us, 500us, 1ms, 5ms, 10ms, 50ms,
100ms, 500ms, 1s, 5s, 10s, +Inf

一般的なクエリ例

以下のクエリ文は、Prometheus Web UIのクエリボックスで直接実行することも、Prometheus HTTP APIを通じてクエリすることもできます。

• arbserverのスクレイピング状態を確認する：

  up{job="oceanbase-arbserver"}
  

• 現在リーダーのいないLSを照会する：

  arb_ls_has_leader == 0
  

• 過去10分間の選挙回数を照会する：

  increase(arb_ls_election_count[10m])
  

• サーバー側RPC P99遅延を照会する：

  histogram_quantile(
    0.99,
    sum by (le) (rate(arb_rpc_process_latency_seconds_bucket[5m]))
  )
  

• ネットワーク転送RPC P99遅延を照会する：

  histogram_quantile(
    0.99,
    sum by (le) (rate(arb_rpc_transport_latency_seconds_bucket[5m]))
  )
  

制限事項

• 現在、SQLを通じた指標収集ポートのオンライン切り替えはサポートされていません。構成パラメータprometheus_metrics_portは静的に有効となり、変更後はarbserverを再起動しなければ変更が反映されません。
• 現在、HTTPSおよびAPI認証はサポートされていません。/metricsインターフェースは平文HTTPであり、認証やTLS暗号化はありません。
• 現在、IPv6アドレスのリスニングはサポートされていません。固定でIPv4アドレス0.0.0.0をリスニングします。observerがIPv6アドレスでデプロイされている場合、PrometheusはIPv6アドレス経由で /metrics インターフェースにアクセスできず、アービトレーションサービスの監視データが取得できません。
• 現在、arbserverの自動検出メカニズムは提供されていません。Prometheusで静的targetを手動で設定するか、デプロイプラットフォームの既存のサービスディスカバリメカニズムに接続する必要があります。
• 現在、プリセットのGrafana DashboardやAlertmanagerアラートルールは提供されていません。GrafanaとAlertmanagerでご自身で作成・設定する必要があります。
• 現在、CPU使用率、メモリ使用率、ディスク使用率の3種類のリソース系指標のみを提供しており、ホストのネットワークやファイルシステムの包括的な監視は含まれていません。パケット損失、再送信、読み取り専用ファイルシステムなどの指標を監視する必要がある場合は、node_exporterの使用を推奨します。
• 現在、arbserverの指標には、observerのログレプリケーションの遅延やFPAXOS状態情報（例：follower lag、Q1/Q2、Reconfirm待機メンバーなど）が含まれていません。
• 現在、2つのRPCヒストグラム指標にはグローバル集計値のみがあり、RPCタイプ、クラスタ、またはテナント別に遅延を分析することはできません。

セキュリティと容量に関する注意事項

• /metrics インターフェースはすべてのIPv4 NICをリスニングしており、認証やTLS暗号化はありません。セキュリティグループ、ファイアウォール、コンテナネットワーク、またはリバースプロキシなどを使用し、Prometheusの収集ネットワークからのみ、このインターフェースへのアクセスを許可することを推奨します。これにより、インターフェースを信頼できないネットワークに直接露出させることを防ぎます。

• 同一マシン上で複数のarbserverインスタンスを実行する場合、各インスタンスは異なるポートを使用する必要があります。ポートを変更した後は、Prometheusのtarget設定も同期して更新してください。

• リソース指標は10秒ごとに1回サンプリングされ、リーダー状態は2秒ごとに更新されます。実際の監視データの更新遅延は、arbserverのサンプリング間隔とPrometheusのscrape_intervalの合計です。アラートルールでは、状態の継続時間を考慮してforパラメータを設定することを推奨します。これにより、単一のサンプリングでの変動によって即座にアラートがトリガーされるのを防ぐことができます。

• 各LSは、cluster_id、tenant_id、ls_idラベルを持つ5組の指標を生成します。大規模なLSシナリオでは、取得応答サイズ、Prometheus series数、ストレージコスト、クエリオーバーヘッドを評価し、必要に応じてscrape_intervalを適宜拡大して収集頻度を下げることができます。

関連ドキュメント

• 監視の概要

• システム監視指標の概要

• アービトレーションサービスの概要

• テナントでアービトレーションサービスを有効にする