Как отслеживать метрики Jitsi Videobridge с помощью Prometheus и Grafana

Когда конференция Jitsi начинает тормозить, администратор может видеть жалобы на прерывистый звук или зависание видео, но у него нет быстрого способа определить, перегружен ли мост, недоступен ли он или просто обрабатывает больше трафика, чем обычно. Jitsi Videobridge (JVB) предоставляет операционные метрики, которые Prometheus может собирать, а Grafana — отображать. В этом руководстве описана практическая настройка, начиная с проверки локальной конечной точки и заканчивая панелью мониторинга, которую вы можете проверить.

Пример сценария: Представьте небольшую организацию, которая использует один JVB на хосте Linux, а также Prometheus и Grafana на том же хосте. Это иллюстративный пример, а не отчет о реальном развертывании или тестировании. Если ваши сервисы работают в отдельных контейнерах или на разных серверах, замените их доступные внутренние адреса, сохранив при этом те же сетевые ограничения.

Что вы будете отслеживать

В текущей документации проекта JVB описывается встроенная конечная точка Prometheus/OpenMetrics на /metricsчастном HTTP-интерфейсе моста. Она отображает статистику, такую ​​как активные конференции, конечные точки, скорость входящего и исходящего трафика, скорость передачи пакетов и нагрузку на мост. Представленная в Prometheus информация не обязательно содержит все статистические данные, доступные через другие форматы отчетов JVB, поэтому рассматривайте конечную точку, предоставляемую вашей установленной версией, как источник достоверной информации. В текущей конфигурации включен ресурс REST Prometheus и частный 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. Проверьте журналы JVB и конфигурацию установленной версии, а не включайте несвязанный API управления Colibri только для того, чтобы путь Prometheus заработал.

Вы можете просмотреть названия и типы метрик напрямую с помощью:

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 работает в другом месте, стандартная привязка loopback в 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.1указывайте на сам контейнер Prometheus; вместо этого используйте имя службы JVB и порт в общей частной сети Docker. Для удаленного хоста используйте его частное DNS-имя или адрес и ограничьте правила брандмауэра. В справочнике по конфигурации Prometheus объясняются задачи сбора данных, цели и настройки интервалов.

Перед применением изменений проверьте весь файл с помощью утилиты Prometheus, входящей в состав вашей установки:

promtool check config /etc/prometheus/prometheus.yml

Если проверка прошла успешно, перезагрузите Prometheus, используя метод, настроенный для вашей службы, или перезапустите его, если перезагрузка не включена. Не следует делать вывод об успехе только на основании корректного YAML-файла; синтаксически корректная цель все еще может быть недоступна.

Шаг 4: Подключите Grafana к Prometheus

В Grafana добавьте встроенный источник данных Prometheus и укажите URL-адрес, к которому Grafana может получить доступ. На одном хосте это может быть, http://localhost:9090если Grafana работает непосредственно на этом хосте. Когда Grafana работает в контейнере, localhostэто означает контейнер Grafana, а не хост или контейнер Prometheus; в общей сети используйте имя службы Prometheus. Сохраните и протестируйте источник данных. В руководстве по источникам данных Prometheus для Grafana описаны параметры подключения, а в документации к источникам данных объясняется, как Grafana запрашивает данные из бэкэнда метрик.

Откройте Explore, выберите Prometheus и запустите команду up{job="jitsi-videobridge"}. Это проверка работоспособности сбора данных Prometheus, а не метрика Jitsi. Значение 1 означает, что Prometheus успешно собрал данные с целевого объекта для текущей оценки; 0 означает, что настроенный целевой объект не работает. Если запрос не возвращает никаких серий, подтвердите точное имя задания, перезагрузку конфигурации, обнаружение целевого объекта и выбранный временной диапазон.

Шаг 5: Создайте удобную панель мониторинга и проверьте данные.

После того, upкак система будет работать корректно, используйте браузер метрик Grafana Explore или браузер выражений Prometheus, чтобы найти серии JVB, доступные в вашем релизе. Начните с небольшого набора операционных вопросов:

• Сколько конференций и конечных устройств активно, и как эти показатели меняются в течение дня?
• Изменяются ли входящие и исходящие RTP-битрейты или пакетные скорости по мере увеличения нагрузки на серверы?
• Растет ли напряжение в мосту пропорционально количеству точек напряжения на концах моста, или оно уже высокое при умеренной нагрузке?
• Доступны ли метрики потоков и сборки мусора JVM, и меняются ли они в зависимости от отчетов о медленных вызовах?

Используйте названия метрик и единицы измерения, выводимые вашей собственной /metricsконечной точкой. В справочнике статистики Jitsi описаны примеры, такие как conferences, endpoints, bit_rate_download, bit_rate_upload, и stress_levelв списке поддерживаемых статистических данных, но там предупреждается, что не все статистические данные в настоящее время доступны в формате Prometheus. Не вставляйте эти названия в запрос, пока не убедитесь, что семейство Prometheus существует в вашей сборке. Для кумулятивных счетчиков используйте функции PromQL, например, rate()в диапазоне; для мгновенных показателей, таких как текущее количество конференций, отображайте непосредственно на графике полученное значение. Сохраняйте указанные единицы измерения при маркировке панелей, поскольку поля битрейта и скорости пакетов используют разные единицы измерения.

Создайте панель мониторинга с несколькими панелями временных рядов, четкими единицами измерения и временным диапазоном, включающим недавние сборы данных. Избегайте обработки отсутствующих данных как нуля: отсутствие данных может указывать на орфографическую ошибку, неподдерживаемую метрику или сбой сбора данных. Для оповещений начните с доступности целевого сервера, а затем добавляйте пороговые значения только после того, как вы зафиксируете нормальный трафик для вашей собственной системы. Универсальное значение «высокой нагрузки» может ввести в заблуждение, поскольку пропускная способность зависит от хоста, медиамикса и конфигурации.

Проверьте завершенную настройку.

Выполните эту последовательность действий, начиная с самого простого и заканчивая наиболее сложным:

1. На хосте JVB запросите http://127.0.0.1:8080/metricsи подтвердите, что ответ содержит текстовые данные метрик.
2. С хоста или контейнера Prometheus отправьте запрос к той же конечной точке, используя настроенный частный адрес. Локальный успешный запрос не доказывает удаленную доступность.
3. В окне «Цели» Prometheus убедитесь, что jitsi-videobridgeцель активна, и проверьте последнюю ошибку сбора данных, если она неактивна.
4. В Grafana Explore подтвердите, up{job="jitsi-videobridge"}что возвращается 1, затем запросите имя одной метрики JVB, скопированное с рабочей конечной точки.
5. Откройте панель мониторинга за временной диапазон, включающий несколько интервалов сбора данных, и убедитесь, что единицы измерения, метки и временные метки имеют смысл.

Если конечная точка работает локально, но Prometheus сообщает об ошибке подключения, пересмотрите адрес привязки, порт, брандмауэр и сетевые настройки контейнера. Если целевой объект работает, но запросы JVB пусты, проверьте точное экспортированное имя, выбранный временной диапазон и наличие этой статистики в выходных данных Prometheus. Если панели мониторинга отображают данные, но качество встречи по-прежнему страдает, метрики помогают сузить круг поиска; сами по себе они не позволяют определить локальную сеть Wi-Fi участника, браузер или проблему в сети «последней мили».

Данная конфигурация соответствует документации Jitsi, Prometheus и Grafana, проверенной 6 октября 2026 года. Поскольку эталонная конфигурация Jitsi и экраны Grafana постоянно меняются, сравните примеры с документацией и файлами для тех версий, которые вы используете.