Jak monitorować wskaźniki Jitsi Videobridge za pomocą Prometheusa i Grafany

Gdy spotkanie w Jitsi zaczyna się zacinać, administrator może zgłaszać problemy z przerywanym dźwiękiem lub zamrożonym obrazem, ale nie ma szybkiego sposobu na stwierdzenie, czy most jest przeciążony, niedostępny, czy po prostu obsługuje większy ruch niż zwykle. Jitsi Videobridge (JVB) udostępnia metryki operacyjne, które Prometheus może gromadzić, a Grafana może wyświetlać. Ten przewodnik przeprowadzi Cię przez praktyczną konfigurację, zaczynając od sprawdzenia lokalnego punktu końcowego, a kończąc na panelu, który możesz zweryfikować.

Przykładowy scenariusz: Wyobraź sobie małą organizację z jednym systemem JVB na hoście z systemem Linux oraz platformami Prometheus i Grafana na tym samym hoście. To przykład ilustracyjny, a nie raport z rzeczywistego wdrożenia lub testu. Jeśli Twoje usługi działają w oddzielnych kontenerach lub na różnych serwerach, zastąp je dostępnymi adresami wewnętrznymi, zachowując te same ograniczenia sieciowe.

Co będziesz monitorować

Aktualna dokumentacja projektu JVB opisuje wbudowany punkt końcowy Prometheus/OpenMetrics na /metricsprywatnym interfejsie HTTP mostu. Zawiera on statystyki, takie jak aktywne konferencje, punkty końcowe, przychodząca i wychodząca przepływność, przepływność pakietów oraz obciążenie mostu. Opis Prometheusa niekoniecznie zawiera wszystkie statystyki dostępne w innych formatach raportowania JVB, dlatego należy traktować punkt końcowy obsługiwany przez zainstalowaną wersję jako źródło prawdziwych danych. Konfiguracja referencyjna obecnie włącza zasób REST Prometheusa i wiąże prywatny interfejs HTTP z pętlą zwrotną; udokumentowany domyślny prywatny port HTTP to 8080. Starsze pakiety i szablony wdrożenia mogą się różnić.

Prometheus pobiera i zapisuje szeregi czasowe. Grafana łączy się z Prometheusem jako źródłem danych i przeszukuje te zapisane szeregi. Do korzystania z tej bezpośredniej ścieżki metryk JVB nie jest wymagany oddzielny eksporter Jitsi. Zapoznaj się ze statystykami Jitsi i dokumentacją punktów końcowych Prometheusa , konfiguracją prywatnego interfejsu HTTP oraz konfiguracją referencyjną . Te pliki źródłowe mogą ulec zmianie; przed zastosowaniem przykładowych wartości sprawdź konfigurację i wersję zainstalowaną na własnym moście.

Krok 1: Potwierdź, że JVB obsługuje metryki

Na maszynie JVB należy najpierw zidentyfikować aktywną konfigurację. Typowy pakiet Debian lub Ubuntu używa /etc/jitsi/videobridge/jvb.conf, ale Jitsi zaznacza, że ​​rzeczywisty plik to ścieżka przekazana do procesu mostu. Wdrożenia kontenerowe mogą zamiast tego montować wygenerowaną konfigurację. Nie należy zakładać, że plik przykładowy jest tym, który odczytywana jest przez działającą usługę.

Używając domyślnego portu i powiązania pętli zwrotnej z przykładu, uruchom to polecenie na hoście JVB:

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

Pomyślna odpowiedź to zwykły tekst zawierający rodziny metryk Prometheusa, często z wierszami # HELPi, # TYPEpo których następują próbki. Ilustracja przedstawia tylko polecenie; nie jest to dowód na to, że serwer działa. Odmowa połączenia zazwyczaj oznacza, że ​​JVB jest zatrzymany i nasłuchuje na innym adresie lub porcie, albo że zainstalowana konfiguracja wyłącza ten nasłuch HTTP. Błąd HTTP 404 sugeruje, że serwer odpowiedział, ale trasa jest niedostępna w tej kompilacji lub konfiguracji API. Sprawdź logi JVB i konfigurację zainstalowanej wersji, zamiast włączać niezwiązane z tym API kontroli Colibri tylko po to, aby ścieżka Prometheusa działała.

Nazwy i typy metryk można sprawdzać bezpośrednio za pomocą:

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

JVB dokumentuje, że dostępne metryki Prometheusa nie są pełnym odzwierciedleniem statystyk JSON. Dokumentuje również histogramy wielkości konferencji, dostępne tylko w formacie Prometheusa. Sprawdź, co faktycznie zwraca zainstalowana wersja, zanim zaczniesz pisać zapytania PromQL lub importować pulpit nawigacyjny, który przyjmuje określone nazwy.

Krok 2: Zachowaj prywatny interfejs

Gdy Prometheus działa na tym samym hoście co JVB, pozostaw interfejs prywatny włączony 127.0.0.1. Pozwoli to uniknąć otwierania kolejnego odbiornika w sieci. W hipotetycznej konfiguracji z tym samym hostem, do celu 127.0.0.1:8080może dotrzeć bezpośrednio Prometheus.

Jeśli Prometheus działa gdzie indziej, domyślne powiązanie pętli zwrotnej JVB nie będzie akceptować połączeń z niego. Możesz skonfigurować prywatny nasłuchiwacz tak, aby powiązał się z wewnętrznym interfejsem dostępnym dla Prometheusa, a następnie ograniczyć zaporę sieciową lub sieć kontenerów tak, aby tylko host Prometheusa mógł połączyć się z prywatnym portem. Nie udostępniaj portów 8080 ani 8443 publicznemu internetowi: Jitsi wyraźnie opisuje ten interfejs jako prywatny i informuje, że jego punkty końcowe nie są przeznaczone do publicznego dostępu. Jeśli środowisko wymaga szyfrowania w trakcie przesyłania, prywatny interfejs obsługuje TLS po skonfigurowaniu z magazynem kluczy; alternatywnie, użyj ściśle kontrolowanego wewnętrznego serwera proxy TLS. Unikaj kopiowania szerokiego publicznego powiązania, na przykład 0.0.0.0bez towarzyszącego mu ograniczenia dostępu.

Po zmianie ustawień programu nasłuchującego, użyj mechanizmu konfiguracji obsługiwanego przez wdrożenie i uruchom ponownie lub przeładuj JVB tylko wtedy, gdy jest to wymagane przez daną wersję. Ponowne uruchomienie może przerwać wywołania we wdrożeniu z pojedynczym mostem, dlatego zaplanuj je odpowiednio. W Dockerze edytuj trwałą konfigurację po stronie hosta lub środowisko użyte do jej wygenerowania, a nie tymczasowy plik kontenera. curlPrzed kontynuowaniem zweryfikuj program nasłuchujący z maszyny Prometheus za pomocą .

Krok 3: Dodaj zadanie scrapowania Prometheus

Dodaj zadanie scrapowania do pliku konfiguracyjnego Prometheusa. W przypadku tego samego hosta odpowiednia sekcja wygląda następująco:

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

Konfiguracja Prometheusa wykorzystuje scrape_configsi obsługuje statyczne cele dla małych, stałych wdrożeń. Jeśli JVB znajduje się w innym kontenerze, 127.0.0.1wskazuje na sam kontener Prometheusa; zamiast tego należy użyć nazwy usługi JVB i portu we współdzielonej prywatnej sieci Docker. W przypadku hosta zdalnego należy użyć jego prywatnej nazwy DNS lub adresu i zachować wąską regułę zapory. Dokumentacja konfiguracji Prometheusa wyjaśnia zadania scrapowania, cele i ustawienia interwałów.

Przed zastosowaniem zmiany należy sprawdzić poprawność całego pliku za pomocą narzędzia Prometheus dołączonego do instalacji:

promtool check config /etc/prometheus/prometheus.yml

Jeśli walidacja się powiedzie, przeładuj Prometheusa, używając metody skonfigurowanej dla usługi, lub uruchom go ponownie, jeśli przeładowania nie są włączone. Nie wnioskuj o powodzeniu tylko na podstawie prawidłowego pliku YAML; cel o poprawnej składni może nadal być nieosiągalny.

Krok 4: Połącz Grafanę z Prometheusem

W Grafanie dodaj wbudowane źródło danych Prometheus i wprowadź adres URL, do którego sama Grafana może dotrzeć. Na jednym hoście może to oznaczać, http://localhost:9090że Grafana działa bezpośrednio na tym hoście. Gdy Grafana działa w kontenerze, localhostoznacza to kontener Grafana, a nie hosta ani kontener Prometheus; użyj nazwy usługi Prometheus w sieci współdzielonej. Zapisz i przetestuj źródło danych. Przewodnik po źródłach danych Prometheus w Grafanie opisuje ustawienia połączenia, a dokumentacja źródeł danych wyjaśnia, jak Grafana wysyła zapytania do zaplecza metryk.

Otwórz Eksplorator, wybierz Prometheusa i uruchom up{job="jitsi-videobridge"}. To jest kontrola kondycji Prometheusa, a nie metryka Jitsi. Wartość 1 oznacza, że ​​Prometheus pomyślnie zeskrobał cel dla bieżącej oceny; 0 oznacza, że ​​skonfigurowany cel nie działa. Jeśli zapytanie nie zwróci żadnej serii, sprawdź dokładną nazwę zadania, ponowne załadowanie konfiguracji, wykrycie celu i wybrany zakres czasu.

Krok 5: Zbuduj użyteczny pulpit nawigacyjny i zweryfikuj dane

Gdy system upjest sprawny, użyj przeglądarki metryk Grafana Explore lub przeglądarki wyrażeń Prometheusa, aby znaleźć serię JVB ujawnioną przez Twoją wersję. Zacznij od krótkiego zestawu pytań operacyjnych:

• Ile konferencji i punktów końcowych jest aktywnych i jak te liczby zmieniają się w ciągu dnia?
• Czy przychodząca i wychodząca szybkość transmisji bitów RTP lub szybkość pakietów zmieniają się wraz ze wzrostem obciążenia spotkań?
• Czy seria naprężeń mostu rośnie wraz z liczbą punktów końcowych, czy też jest już wysoka przy umiarkowanym obciążeniu?
• Czy metryki wątków i zbierania śmieci JVM są dostępne i czy zmieniają się w przypadku raportów o powolnych wywołaniach?

Użyj nazw metryk i jednostek wydrukowanych przez Twój własny /metricspunkt końcowy. W dokumentacji statystycznej Jitsi opisano przykłady takie jak conferences, endpoints, bit_rate_download, bit_rate_uploadi stress_levelna liście obsługiwanych statystyk, ale ostrzega się, że nie wszystkie statystyki są obecnie dostępne w formacie Prometheus. Nie wklejaj tych nazw do zapytania, dopóki nie potwierdzisz, że rodzina Prometheus istnieje w Twojej kompilacji. W przypadku liczników skumulowanych użyj funkcji PromQL, takich jak rate()dla zakresu; w przypadku wskaźników chwilowych, takich jak bieżąca liczba konferencji, wyświetl bezpośrednio wartość próbkowania. Zachowaj udokumentowane jednostki podczas etykietowania paneli, ponieważ pola przepływności i przepływności pakietów używają różnych jednostek.

Utwórz pulpit nawigacyjny z kilkoma panelami szeregów czasowych, czystymi jednostkami i zakresem czasowym obejmującym ostatnie scrapowania. Unikaj traktowania brakującej serii jako zera: brak danych może wskazywać na błąd pisowni, nieobsługiwaną metrykę lub błąd scrapowania. W przypadku alertów zacznij od docelowej dostępności, a następnie dodaj progi dopiero po zaobserwowaniu normalnego ruchu we własnym wdrożeniu. Uniwersalna wartość „wysokiego obciążenia” może być myląca, ponieważ przepustowość zależy od hosta, miksu mediów i konfiguracji.

Sprawdź ukończoną konfigurację

Wykonaj tę sekwencję od najłatwiejszej do najbardziej szczegółowej:

1. Na hoście JVB poproś o http://127.0.0.1:8080/metricsodpowiedź i potwierdź, że zawiera ona tekst metryczny.
2. Z hosta lub kontenera Prometheus wyślij żądanie do tego samego punktu końcowego, używając skonfigurowanego adresu prywatnego. Lokalny sukces nie oznacza, że ​​można go zdalnie odebrać.
3. W widoku Cele w Prometheusie sprawdź, czy jitsi-videobridgecel jest aktywny i sprawdź jego ostatni błąd skanowania, jeśli jest wyłączony.
4. W Grafana Explore potwierdź, że up{job="jitsi-videobridge"}zwracana jest wartość 1, a następnie wykonaj zapytanie o jedną nazwę metryki JVB skopiowaną z aktywnego punktu końcowego.
5. Otwórz pulpit nawigacyjny obejmujący okres obejmujący kilka interwałów zbierania danych i sprawdź, czy jednostki, etykiety i znaczniki czasu mają sens.

Jeśli punkt końcowy działa lokalnie, ale Prometheus zgłasza błąd połączenia, sprawdź ponownie adres powiązania, port, zaporę sieciową i sieć kontenerów. Jeśli cel działa, ale zapytania JVB są puste, sprawdź dokładną wyeksportowaną nazwę, wybrany zakres czasu i czy ta statystyka jest obecna w wynikach Prometheusa. Jeśli pulpity nawigacyjne wyświetlają dane, ale jakość spotkania nadal spada, metryki pomagają zawęzić zakres dochodzenia; same w sobie nie identyfikują problemu uczestnika z lokalną siecią Wi-Fi, przeglądarką ani siecią ostatniej mili.

Ta konfiguracja jest zgodna z dokumentacją Jitsi, Prometheus i Grafana, którą przejrzano 6 października 2026 r. Ponieważ konfiguracja referencyjna Jitsi i ekrany Grafana ewoluują, porównaj przykłady z dokumentacją i plikami dla konkretnych wersji, z których korzystasz.