Wie man Jitsi Videobridge-Metriken mit Prometheus und Grafana überwacht

Wenn ein Jitsi-Meeting ruckelt, erhalten Administratoren möglicherweise Beschwerden über abgehackten Ton oder eingefrorenes Video, können aber nicht schnell feststellen, ob die Videobrücke überlastet, nicht erreichbar ist oder einfach nur mehr Datenverkehr als üblich verarbeitet. Jitsi Videobridge (JVB) stellt Betriebsmetriken bereit, die Prometheus erfassen und Grafana visualisieren kann. Diese Anleitung beschreibt die praktische Einrichtung, beginnend mit einer lokalen Endpunktprüfung und endend mit einem Dashboard zur Überprüfung der Ergebnisse.

Beispielszenario: Stellen Sie sich eine kleine Organisation vor, die einen JVB-Container auf einem Linux-Host und Prometheus und Grafana auf demselben Host betreibt. Dies ist ein Beispiel zur Veranschaulichung und kein Bericht über eine reale Implementierung oder einen Test. Wenn Ihre Dienste in separaten Containern oder auf verschiedenen Servern laufen, ersetzen Sie deren erreichbare interne Adressen und beachten Sie die gleichen Netzwerkbeschränkungen.

Was Sie überwachen werden

Die aktuelle JVB-Projektdokumentation beschreibt einen integrierten Prometheus/OpenMetrics-Endpunkt auf /metricsder privaten HTTP-Schnittstelle der Bridge. Er listet Statistiken wie aktive Konferenzen, Endpunkte, eingehende und ausgehende Bitrate, Paketraten und Bridge-Auslastung auf. Die Prometheus-Dokumentation enthält nicht unbedingt alle Statistiken, die über die anderen Berichtsformate von JVB verfügbar sind. Verwenden Sie daher den von Ihrer installierten Version bereitgestellten Endpunkt als maßgebliche Datenquelle. Die Referenzkonfiguration aktiviert derzeit die Prometheus-REST-Ressource und bindet die private HTTP-Schnittstelle an Loopback; der dokumentierte Standard-Port für privates HTTP ist 8080. Ältere Pakete und Bereitstellungsvorlagen können abweichen.

Prometheus erfasst und speichert die Zeitreihen. Grafana verbindet sich mit Prometheus als Datenquelle und fragt diese gespeicherten Reihen ab. Für diesen direkten JVB-Metrikpfad ist kein separater Jitsi-Exporter erforderlich. Weitere Informationen finden Sie in der Dokumentation zu Jitsi-Statistiken und dem Prometheus-Endpunkt , der Konfiguration der privaten HTTP-Schnittstelle sowie in der Referenzkonfiguration . Diese Upstream-Dateien können sich ändern; überprüfen Sie daher die Konfiguration und die auf Ihrer Bridge installierte Version, bevor Sie die Beispielwerte anwenden.

Schritt 1: Bestätigen, dass JVB Metriken bereitstellt

Auf dem JVB-Rechner muss zunächst die aktive Konfiguration ermittelt werden. Gängige Debian- oder Ubuntu-Pakete verwenden die Datei ` /etc/jitsi/videobridge/jvb.conf<Konfigurationsdatei>`, Jitsi weist jedoch darauf hin, dass die tatsächliche Konfigurationsdatei der Pfad ist, der dem Bridge-Prozess übergeben wird. Container-Bereitstellungen können stattdessen eine generierte Konfiguration einbinden. Gehen Sie nicht davon aus, dass eine Beispielkonfigurationsdatei diejenige ist, die der laufende Dienst verwendet.

Führen Sie mit dem im Beispiel verwendeten Standardport und der Standard-Loopback-Bindung folgenden Befehl auf dem JVB-Host aus:

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

Eine erfolgreiche Antwort ist Klartext mit Prometheus-Metrikfamilien, oft mit # HELPZeilen, # TYPEgefolgt von Beispielen. Die Abbildung zeigt nur den Befehl; sie ist kein Beweis für eine Antwort eines aktiven Servers. Eine Verbindungsablehnung bedeutet üblicherweise, dass JVB gestoppt ist, auf einer anderen Adresse oder einem anderen Port lauscht oder dass die installierte Konfiguration diesen HTTP-Listener deaktiviert. Ein HTTP-404-Fehler deutet darauf hin, dass der Server geantwortet hat, die Route aber in dieser Build- oder API-Konfiguration nicht verfügbar ist. Überprüfen Sie die JVB-Protokolle und die Konfiguration Ihrer installierten Version, anstatt die unabhängige Colibri-Steuerungs-API zu aktivieren, nur um den Prometheus-Pfad zum Laufen zu bringen.

Sie können Metriknamen und -typen direkt überprüfen mit:

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

JVB dokumentiert, dass die verfügbaren Prometheus-Metriken nicht vollständig mit den JSON-Statistiken übereinstimmen. Außerdem werden Konferenzgrößen-Histogramme nur im Prometheus-Format angezeigt. Prüfen Sie daher, welche Metriken Ihre installierte Version tatsächlich zurückgibt, bevor Sie PromQL-Abfragen schreiben oder ein Dashboard importieren, das bestimmte Namen verwendet.

Schritt 2: Die private Schnittstelle privat halten

Wenn Prometheus auf demselben Host wie JVB läuft, lassen Sie die private Schnittstelle aktiviert 127.0.0.1. Dadurch wird vermieden, dass ein weiterer Listener in Ihrem Netzwerk geöffnet wird. In dieser hypothetischen Konfiguration auf demselben Host 127.0.0.1:8080kann das Ziel direkt von Prometheus erreicht werden.

Wenn Prometheus auf einem anderen Rechner läuft, akzeptiert die standardmäßige Loopback-Bindung von JVB keine Verbindungen von dort. Sie können den privaten Listener so konfigurieren, dass er an eine interne Schnittstelle gebunden wird, die für Prometheus erreichbar ist. Anschließend können Sie die Firewall oder das Containernetzwerk so einschränken, dass nur der Prometheus-Host eine Verbindung zum privaten Port herstellen kann. Geben Sie die Ports 8080 und 8443 nicht im öffentlichen Internet frei: Jitsi beschreibt diese Schnittstelle ausdrücklich als privat und weist darauf hin, dass ihre Endpunkte nicht für den öffentlichen Zugriff bestimmt sind. Wenn die Umgebung eine Verschlüsselung der Datenübertragung erfordert, unterstützt die private Schnittstelle TLS, wenn sie mit einem Keystore konfiguriert ist. Alternativ können Sie einen streng kontrollierten internen TLS-Proxy verwenden. Vermeiden Sie es, eine allgemeine öffentliche Bindung ohne 0.0.0.0entsprechende Zugriffsbeschränkung zu kopieren.

Nach dem Ändern einer Listener-Einstellung verwenden Sie den von Ihrer Bereitstellung unterstützten Konfigurationsmechanismus und starten oder laden Sie JVB nur dann neu, wenn dies von der jeweiligen Version gefordert wird. Ein Neustart kann Aufrufe in einer Single-Bridge-Bereitstellung unterbrechen; planen Sie ihn daher entsprechend. Bearbeiten Sie in Docker die persistente Host-seitige Konfiguration oder die Umgebung, die zur Generierung verwendet wurde, nicht eine temporäre Containerdatei. Überprüfen Sie den Listener auf dem Prometheus-Rechner, curlbevor Sie fortfahren.

Schritt 3: Einen Prometheus-Scrape-Job hinzufügen

Fügen Sie einen Scrape-Job zur Prometheus-Konfigurationsdatei hinzu. Im Beispiel mit demselben Host ist der relevante Abschnitt:

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

Die Prometheus-Konfiguration verwendet scrape_configsund unterstützt statische Ziele für kleine, feste Bereitstellungen. Befindet sich der JVB in einem separaten Container, 127.0.0.1verweist er auf den Prometheus-Container selbst; verwenden Sie stattdessen den JVB-Dienstnamen und -Port in einem gemeinsam genutzten privaten Docker-Netzwerk. Bei einem Remote-Host verwenden Sie dessen privaten DNS-Namen oder die Adresse und halten Sie die Firewall-Regel restriktiv. Die Prometheus-Konfigurationsreferenz erläutert Scrape-Jobs, Ziele und Intervalleinstellungen.

Bevor Sie eine Änderung anwenden, überprüfen Sie die gesamte Datei mit dem Prometheus-Dienstprogramm, das mit Ihrer Installation mitgeliefert wurde:

promtool check config /etc/prometheus/prometheus.yml

Wenn die Validierung erfolgreich ist, laden Sie Prometheus mit der für Ihren Dienst konfigurierten Methode neu oder starten Sie es neu, falls Neuladen nicht aktiviert ist. Schließen Sie nicht allein aus einer gültigen YAML-Datei auf Erfolg; ein syntaktisch korrektes Ziel kann dennoch unerreichbar sein.

Schritt 4: Grafana mit Prometheus verbinden

Fügen Sie in Grafana die integrierte Prometheus-Datenquelle hinzu und geben Sie die URL ein, die Grafana selbst erreichen kann. Auf einem Host, http://localhost:9090auf dem Grafana direkt ausgeführt wird, könnte dies beispielsweise die URL sein. Läuft Grafana in einem Container, localhostist mit „Prometheus“ der Grafana-Container gemeint, nicht der Host oder der Prometheus-Container. Verwenden Sie in einem gemeinsam genutzten Netzwerk den Prometheus-Dienstnamen. Speichern und testen Sie die Datenquelle. Die Anleitung zur Prometheus-Datenquelle in Grafana beschreibt die Verbindungseinstellungen, und die Dokumentation zur Datenquelle erklärt, wie Grafana ein Metrik-Backend abfragt.

Öffnen Sie Explore, wählen Sie Prometheus aus und führen Sie den Befehl aus up{job="jitsi-videobridge"}. Dies ist ein Prometheus-Scraping-Integritätscheck, keine Jitsi-Metrik. Der Wert 1 bedeutet, dass Prometheus das Ziel für die aktuelle Auswertung erfolgreich gescraped hat; 0 bedeutet, dass ein konfiguriertes Ziel nicht erreicht wurde. Falls die Abfrage keine Ergebnisse liefert, überprüfen Sie den genauen Jobnamen, das Neuladen der Konfiguration, die Zielerkennung und den ausgewählten Zeitraum.

Schritt 5: Erstellen Sie ein nützliches Dashboard und überprüfen Sie die Daten.

Sobald updie Verfügbarkeit geprüft ist, verwenden Sie den Metrik-Browser von Grafana Explore oder den Ausdrucks-Browser von Prometheus, um die von Ihrer Veröffentlichung bereitgestellten JVB-Serien zu ermitteln. Beginnen Sie mit einigen wenigen Fragen zum Betrieb:

• Wie viele Konferenzen und Endpunkte sind aktiv, und wie verändern sich diese Zahlen im Laufe des Tages?
• Ändern sich die eingehenden und ausgehenden RTP-Bitraten bzw. Paketratenreihen mit steigender Meeting-Last?
• Steigt die Brückenspannungsreihe mit der Anzahl der Endpunkte, oder ist sie bereits bei mäßiger Belastung hoch?
• Sind Metriken für JVM-Threads und Garbage Collection verfügbar und ändern sie sich im Zusammenhang mit Berichten über langsame Aufrufe?

Verwenden Sie die von Ihrem Endpunkt ausgegebenen Metriknamen und -einheiten /metrics. Die Statistikreferenz von Jitsi beschreibt Beispiele wie conferences` <meta>`, ` <meta>` , endpoints` <meta> ` und ` <meta>` in ihrer Liste der unterstützten Statistiken, weist aber darauf hin, dass derzeit nicht alle Statistiken im Prometheus-Format verfügbar sind. Fügen Sie diese Namen erst dann in eine Abfrage ein, wenn Sie sichergestellt haben, dass die Prometheus-Familie in Ihrer Konfiguration vorhanden ist. Verwenden Sie für kumulative Zähler PromQL-Funktionen wie `<meta>` über einen Bereich; für Momentanwerte wie die aktuelle Konferenzanzahl stellen Sie den Messwert direkt grafisch dar. Behalten Sie die dokumentierten Einheiten bei der Beschriftung von Panels bei, da Bitratenfelder und Paketraten unterschiedliche Einheiten verwenden.bit_rate_downloadbit_rate_uploadstress_levelrate()

Erstellen Sie ein Dashboard mit einigen Zeitreihen-Panels, eindeutigen Einheiten und einem Zeitraum, der die letzten Datenabfragen umfasst. Vermeiden Sie es, fehlende Datenreihen als Nullwerte zu behandeln: Fehlende Daten können auf einen Rechtschreibfehler, eine nicht unterstützte Metrik oder einen fehlgeschlagenen Datenabruf hinweisen. Beginnen Sie bei Warnmeldungen mit der Zielverfügbarkeit und fügen Sie Schwellenwerte erst hinzu, nachdem Sie den normalen Datenverkehr Ihrer eigenen Bereitstellung beobachtet haben. Ein allgemeiner Wert für „hohe Auslastung“ kann irreführend sein, da die Kapazität vom Host, dem Medienmix und der Konfiguration abhängt.

Überprüfen Sie die fertige Einrichtung.

Führen Sie diese Sequenz von der einfachsten zur spezifischsten aus:

1. Auf dem JVB-Host anfordern http://127.0.0.1:8080/metricsund bestätigen, dass die Antwort Metriktext enthält.
2. Vom Prometheus-Host oder -Container aus fordern Sie denselben Endpunkt über die konfigurierte private Adresse an. Ein lokaler Erfolg beweist nicht die Erreichbarkeit aus der Ferne.
3. Überprüfen Sie in der Zielansicht von Prometheus, ob das jitsi-videobridgeZiel aktiv ist, und prüfen Sie, ob der letzte Scrape-Fehler aufgetreten ist, falls es inaktiv ist.
4. In Grafana Explore bestätigen Sie, up{job="jitsi-videobridge"}dass 1 zurückgegeben wird, und fragen dann einen JVB-Metriknamen ab, der vom Live-Endpunkt kopiert wurde.
5. Öffnen Sie ein Dashboard über einen Zeitraum, der mehrere Abrufintervalle umfasst, und prüfen Sie, ob Einheiten, Bezeichnungen und Zeitstempel sinnvoll sind.

Funktioniert der Endpunkt lokal, meldet Prometheus aber einen Verbindungsfehler, überprüfen Sie die Bindungsadresse, den Port, die Firewall und die Container-Netzwerkkonfiguration. Ist das Ziel erreichbar, liefern JVB-Abfragen aber keine Ergebnisse, prüfen Sie den genauen exportierten Namen, den ausgewählten Zeitraum und ob die entsprechende Statistik in der Prometheus-Ausgabe vorhanden ist. Zeigen Dashboards Daten an, die Meeting-Qualität leidet aber weiterhin. Metriken helfen zwar, die Fehlersuche einzugrenzen, identifizieren aber nicht allein lokale WLAN-, Browser- oder Netzwerkprobleme eines Teilnehmers.

Diese Konfiguration orientiert sich an der am 6. Oktober 2026 aktualisierten Dokumentation von Jitsi, Prometheus und Grafana. Da sich die Referenzkonfiguration von Jitsi und die Grafana-Oberflächen weiterentwickeln, vergleichen Sie die Beispiele mit der Dokumentation und den Dateien der von Ihnen verwendeten Versionen.