PrometheusとGrafanaを使用してJitsi Videobridgeのメトリクスを監視する方法

Jitsi ミーティングで音声が途切れたり、映像がフリーズしたりといった苦情が寄せられる場合、管理者はブリッジが過負荷状態なのか、アクセス不能なのか、あるいは単に通常よりもトラフィックが多いだけなのかをすぐに判断する手段がないかもしれません。Jitsi Videobridge (JVB) は、Prometheus が収集し Grafana で表示できる運用メトリクスを公開します。このガイドでは、ローカルエンドポイントのチェックから始めて、検証可能なダッシュボードに至るまで、実践的な設定手順を説明します。

シナリオ例：小規模な組織が、Linuxホスト上でJVBを1つ実行し、同じホスト上でPrometheusとGrafanaを実行していると想像してください。これはあくまで例であり、実際の導入やテストの報告ではありません。サービスが別々のコンテナまたは異なるサーバーで実行されている場合は、到達可能な内部アドレスを置き換え、同じネットワーク制限を維持してください。

監視対象

現在の JVB プロジェクトのドキュメントでは、ブリッジのプライベート HTTP インターフェイスに組み込まれた Prometheus/OpenMetrics エンドポイントについて説明しています/metrics。このエンドポイントには、アクティブな会議、エンドポイント、送受信ビットレート、パケットレート、ブリッジの負荷などの統計情報が表示されます。Prometheus の情報は、JVB の他のレポート形式で利用できるすべての統計情報を含んでいるとは限らないため、インストールされているリリースで提供されるエンドポイントを信頼できる情報源として扱ってください。現在のリファレンス構成では、Prometheus REST リソースが有効になり、プライベート HTTP インターフェイスがループバックにバインドされます。ドキュメントに記載されているデフォルトのプライベート HTTP ポートは 8080 です。古いパッケージやデプロイメント テンプレートでは異なる場合があります。

Prometheusは時系列データをスクレイピングして保存します。GrafanaはデータソースとしてPrometheusに接続し、保存された時系列データをクエリします。この直接的なJVBメトリクスパスでは、別途Jitsiエクスポーターは必要ありません。Jitsiの統計情報とPrometheusエンドポイントのドキュメント、プライベートHTTPインターフェースの設定、およびリファレンス設定を参照してください。これらのアップストリームファイルは変更される可能性があるため、サンプル値を適用する前に、ご自身のブリッジにインストールされている設定とバージョンを確認してください。

ステップ1：JVBがメトリクスを提供していることを確認する

JVBマシン上で、まずアクティブな構成を特定します。一般的なDebianまたはUbuntuパッケージでは を使用します/etc/jitsi/videobridge/jvb.confが、Jitsiによると、実際のファイルはブリッジプロセスに渡されるパスになります。コンテナ展開では、代わりに生成された構成をマウントする場合があります。サンプルファイルが実行中のサービスが読み込むファイルであると想定しないでください。

サンプルで使用されているデフォルトのポートとループバックバインディングを使用して、JVBホストで次のコマンドを実行します。

curl -fsS http://127.0.0.1:8080/metrics | head

正常な応答は、Prometheus メトリックファミリーを含むプレーンテキストで、多くの場合# HELP、# TYPEサンプルが続く行が含まれています。図はコマンドのみを示しており、ライブサーバー応答の証拠ではありません。接続拒否は、通常、JVB が停止しているか、別のアドレスまたはポートでリッスンしているか、インストールされている構成でその HTTP リスナーが無効になっていることを意味します。HTTP 404 は、サーバーが応答したが、そのビルドまたは API 構成でルートが利用できないことを示唆しています。Prometheus パスを機能させるためだけに無関係な Colibri コントロール API を有効にするのではなく、JVB ログとインストールされているリリースの構成を確認してください。

メトリック名とタイプは、以下の方法で直接確認できます。

curl -fsS http://127.0.0.1:8080/metrics | grep -E '^(# HELP|# TYPE)' | head -n 40

JVBは、利用可能なPrometheusメトリクスがJSON統計情報と完全に一致するわけではないことを明記しています。また、会議規模のヒストグラムはPrometheus形式でのみ利用可能であることも明記しています。PromQLクエリを作成したり、特定の名前を前提としたダッシュボードをインポートしたりする前に、インストールされているバージョンが実際に何を返すかを確認してください。

ステップ2：プライベートインターフェースを非公開に保つ

Prometheus が JVB と同じホストで実行される場合、プライベートインターフェースを有効にしたままにしてください127.0.0.1。これにより、ネットワークへの別のリスナーが開かれるのを回避できます。仮想的な同一ホスト構成では、127.0.0.1:8080Prometheus はターゲットに直接アクセスできます。

Prometheus が別の場所で実行されている場合、JVB のデフォルトのループバック バインディングはそこからの接続を受け付けません。プライベート リスナーを Prometheus からアクセス可能な内部インターフェイスにバインドするように構成し、ファイアウォールまたはコンテナ ネットワークを制限して、Prometheus ホストのみがプライベート ポートに接続できるようにします。ポート 8080 または 8443 をパブリック インターネットに公開しないでください。Jitsi ではこのインターフェイスをプライベートと明示的に説明しており、エンドポイントはパブリック アクセスを意図していないと述べています。転送中に暗号化が必要な環境では、プライベート インターフェイスはキー ストアで構成すると TLS をサポートします。または、厳密に制御された内部 TLS プロキシを使用します。0.0.0.0アクセス制限を伴わない広範なパブリック バインドをコピーすることは避けてください。

リスナー設定を変更した後は、デプロイメントでサポートされている構成メカニズムを使用し、そのリリースで必要な場合にのみ JVB を再起動またはリロードしてください。再起動はシングルブリッジデプロイメントでの呼び出しを中断する可能性があるため、適切にスケジュールしてください。Docker では、一時的なコンテナ ファイルではなく、永続的なホスト側構成またはそれを生成するために使用された環境を編集してください。curl続行する前に、Prometheus マシンからリスナーを確認してください。

ステップ3：Prometheusのスクレイピングジョブを追加する

Prometheusの設定ファイルにスクレイピングジョブを追加します。同一ホストの例では、関連するセクションは次のとおりです。

scrape_configs:
  - job_name: jitsi-videobridge
    metrics_path: /metrics
    static_configs:
      - targets:
          - 127.0.0.1:8080

Prometheusの設定でscrape_configsは、小規模な固定デプロイメント向けに静的ターゲットが使用され、サポートされています。JVBが別のコンテナにある場合は、127.0.0.1Prometheusコンテナ自体を指定してください。共有プライベートDockerネットワークの場合は、代わりにJVBサービス名とポートを使用してください。リモートホストの場合は、そのプライベートDNS名またはアドレスを使用し、ファイアウォールルールを狭く設定してください。Prometheusの設定リファレンスでは、スクレイピングジョブ、ターゲット、および間隔設定について説明しています。

変更を適用する前に、インストール時に同梱されている Prometheus ユーティリティを使用してファイル全体を検証してください。

promtool check config /etc/prometheus/prometheus.yml

検証が成功した場合は、サービスに設定されている方法を使用して Prometheus をリロードするか、リロードが有効になっていない場合は再起動してください。有効な YAML ファイルのみで成功を判断しないでください。構文的に有効なターゲットでも、実際には到達できない場合があります。

ステップ4：GrafanaをPrometheusに接続する

Grafana で、組み込みの Prometheus データソースを追加し、Grafana 自体がアクセスできる URL を入力します。ホストによっては、http://localhost:9090Grafana がそのホスト上で直接実行されている場合、この URL は 1 つになります。Grafana がコンテナ内で実行されている場合は、localhostホストや Prometheus コンテナではなく、Grafana コンテナの URL を使用します。共有ネットワークでは、Prometheus サービス名を使用します。データソースを保存してテストします。Grafana のPrometheus データソースガイドには接続設定の説明があり、データソースのドキュメントにはGrafana がメトリクスバックエンドにクエリを実行する方法が説明されています。

Exploreを開き、Prometheusを選択して、を実行しますup{job="jitsi-videobridge"}。これはJitsiメトリックではなく、Prometheusのスクレイピング健全性チェックです。値が1の場合は、Prometheusが現在の評価対象を正常にスクレイピングしたことを意味します。0の場合は、設定された対象が失敗していることを意味します。クエリがシリーズを全く返さない場合は、正確なジョブ名、構成の再読み込み、対象検出、および選択した時間範囲を確認してください。

ステップ5：便利なダッシュボードを作成し、データを検証する

up正常になったら、Grafana ExploreのメトリックブラウザまたはPrometheusの式ブラウザを使用して、リリースによって公開されているJVBシリーズを見つけます。まずは、いくつかの運用上の質問から始めましょう。

• 現在アクティブな会議とエンドポイントの数はいくつで、それらの数は一日を通してどのように変化しますか？
• 会議の負荷が増加するにつれて、受信および送信RTPビットレートまたはパケットレートの系列は変化していますか？
• 橋梁の応力系列は、終点数の増加に伴って上昇するのか、それとも比較的低い荷重でも既に高い値を示すのか？
• JVMスレッドとガベージコレクションのメトリクスは利用可能ですか？また、スローコールレポートの前後でこれらのメトリクスは変化しますか？

エンドポイントが出力するメトリック名と単位を使用してください/metrics。Jitsi の統計リファレンスには、サポートされている統計リストに、、、、などの例が記載されていますが、conferencesすべての統計が現在 Prometheus 形式で公開されているわけではないことに注意が必要です。ビルドに Prometheus ファミリーが存在することを確認するまでは、これらの名前をクエリに貼り付けないでください。累積カウンターには、範囲に対してなどの PromQL 関数を使用します。現在の会議数などの瞬間的なゲージには、サンプリングされた値を直接グラフ化します。ビットレート フィールドとパケット レートでは異なる単位が使用されるため、パネルにラベルを付ける際には、ドキュメントに記載されている単位を維持してください。endpointsbit_rate_downloadbit_rate_uploadstress_levelrate()

時系列パネルをいくつか用意し、単位を明確にし、最近のスクレイピングデータを含む時間範囲を設定したダッシュボードを作成してください。欠落している系列をゼロとして扱わないでください。データがないということは、スペルミス、サポートされていないメトリック、またはスクレイピングの失敗を示している可能性があります。アラートについては、まずターゲット可用性から始め、自社のデプロイメントで正常なトラフィックを確認した後にのみしきい値を追加してください。容量はホスト、メディアミックス、構成によって異なるため、一律の「高負荷」数値は誤解を招く可能性があります。

セットアップが完了したか確認してください

以下の手順を、最も簡単なものから最も具体的なものの順に実行してください。

1. JVBホスト上で、リクエストを送信しhttp://127.0.0.1:8080/metrics、レスポンスにメトリックテキストが含まれていることを確認します。
2. Prometheusホストまたはコンテナから、設定済みのプライベートアドレスを使用して同じエンドポイントにリクエストを送信します。ローカルでの成功は、リモートへの到達可能性を証明するものではありません。
3. Prometheusのターゲットビューで、jitsi-videobridgeターゲットが稼働していることを確認し、稼働していない場合は最後のスクレイピングエラーを調べます。
4. Grafana Exploreで、確認するとup{job="jitsi-videobridge"}1が返されます。次に、ライブエンドポイントからコピーしたJVBメトリック名を1つクエリします。
5. 複数のデータ取得間隔を含む期間のダッシュボードを開き、単位、ラベル、タイムスタンプが適切であることを確認してください。

エンドポイントがローカルで正常に動作しているにもかかわらず、Prometheusが接続エラーを報告する場合は、バインドアドレス、ポート、ファイアウォール、およびコンテナネットワークを再確認してください。ターゲットが起動しているにもかかわらずJVBクエリが空の場合は、エクスポートされた正確な名前、選択された時間範囲、およびその統計情報がPrometheusの出力に含まれているかどうかを確認してください。ダッシュボードにデータが表示されていても会議の品質が低下している場合は、メトリクスが調査範囲を絞り込むのに役立ちますが、メトリクスだけでは参加者のローカルWi-Fi、ブラウザ、またはラストマイルネットワークの問題を特定することはできません。

この設定は、2026年10月6日にレビューされたJitsi、Prometheus、およびGrafanaの公式ドキュメントに準拠しています。Jitsiのリファレンス設定とGrafanaの画面は変更される可能性があるため、ご使用のバージョンに対応するドキュメントとファイルを参照し、例を比較してください。