Дашборд Server Stats¶

Дашборд Server Stats обеспечивает верхнеуровневый мониторинг метрик загрузки серверов во всей вашей стриминговой инфраструктуре.

Его обзорная часть похожа на стандартные инструменты мониторинга серверов, но важно то, что он уже включен в сервис и вам не надо следить за дополнительными агентами.

Самые перегруженные серверы¶

Эта панель отображает серверы с наивысшим использованием ресурсов по основным измеряемым показателям.

Отображаемая информация:

Наверх поднимаются серверы с максимальной нагрузкой хотя бы одному параметру.
Распределение нагрузки во времени. Рекомендуется менять временной диапазон, сужение его до часов и минут может поднять наверх сервера со свежими проблемами.

Сценарии использования:

Выбрать в дешборде последние 2-3 часа, увидеть что есть сервера с красной индикацией, приступить к устранению проблемы
Выбрать в дешборде последние 7 дней, увидеть что есть периодические всплески нагрузки вплоть до красных. Установить источник периодического роста и если его не должно быть, устранить проблему.
Выбрать в дешборде последние 30 дней, увидеть планомерный рост нагрузки, начать планировать расширение инфраструктуры

Пример перегруженного сервиса

На этом сервисе ситуация с CPU и загрузкой вся в желтой зоне. Можно считать это умелой утилизацией серверов, потому что признаков полки на графике CPU нет, однако никакой дополнителной нагрузки эти сервера не перенесут.

Загрузка CPU и виртуальной машины¶

Две следующих панели дают обзорную картину загрузки центрального процессора и виртуальной машины. Это разные величины, нельзя ориентироваться только по одной.

Частая ошибка системных администраторов - принимать решения без знаний о работе виртуальной машины и жаловаться на рост CPU, не учитывая шедулер.

Загрузка процессора в 80% не является критической, хотя и повышенной. Работоспособность стримингового сервера необходимо оценивать по загрузке шедулера, это более достоверная метрика. Работа виртуальной машины может подразумевать высокую загрузку процессора, в особых случаях является нормой 100% полная загрузка нескольких ядер процессора.

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

На этом графике и дальше графики разделены по версиям. Очень удобно отслеживать: действительно ли была деградация производительности, или это лишь иллюзия.

Пример критической нагрузки

На этих двух графиках видно, что CPU на пределе (этот сервис уже упоминался выше) и возможно упирается в полку, т.е. не справляется, но по графику шедулера видно, что полки нет, просто сервер на пределе. Хотя дальше будет видно, что диски у него не справляются.

Использование оперативной памяти¶

Мониторинг использования RAM на серверах.

Показывается общее использование памяти, ориентироваться надо на этот график.

Норма - стабильное

На графике нет индикации использования swap по одной простой причине: на стриминговом сервере своп должен быть выключен, он не нужен ни в каком сценарии, зато может привести к тому, что вместо аварийного отключения, система уйдет в отказ и вместо нескольких минут простоя будут десятки минут.

Ошибки записи на диск¶

Отслеживание ошибок записи на диск.

Отображаемые метрики:

Сгруппированные записи на диск
Провалившиеся попытки записи

Когда хранилище начинает не успевать записывать (это нормальное поведение для сетевых стораджей, которые очень часто не способны неделями выдавать постоянно стабильную и предсказуемую скорость записи), сначала медиасервер начинает группировать соседние записи. Каждая такая группировка отражается на графике Collapsed writes и является тревожной ситуацией. Такого не должно происходить, но это пока ещё не проблема.

Как правило после длительного игнорирования collapsed writes можно наблюдать отказы в записи: failed writes. Медиасервер не может вечно хранить сегменты в очереди на запись, он их хранит ровно столько, сколько они доступны в лайве на просмотр, поэтому когда окно проигрывания уходит, а запись не произошла, видео потеряно безвозвратно.

Это уже серьезный отказ сервиса.

Сценарии использования:

Обнаруживать отказывающее оборудование хранилища
Выявлять проблемы файловой системы
Планировать замену дисков
Мониторить надежность хранилища

Утилизация диска¶

Мониторинг скорости работы дисков позволяет увидеть потенциальные проблемы на раздельных дисках.

В этот раздел имеет смысл попадать, если есть индикация ошибок записи или чтения с диска. В остальных случаях этот раздел носит характер ознакомительный, посмотреть раз в месяц, что тут никаких аномалий.

Процент загрузки диска

В норме тут должно быть не больше 80% Отдельные всплески допустимы, ничего страшного, если они не приводят к ошибкам работы сервиса.

Заполнение диска

Должно быть стабильно около предельного. 98% - это норма, если ваши хранилища используют ext4. Если вы решили воспользоваться btrfs, то возможен отказ сервиса уже на 55%, но мы вам помочь уже не сможем.

Скорость записи на диск

Одной нормы нет, она для шпинделя и NVME отличается на несколько порядков. Интересен резкий скачок или полка.

Скорость чтения с диска

Аналогично предыдущему: единой нормы нет. Стоит обращать внимание на резкие изменения, а так же на тренд изменения в разрезе месяцев.

Пример неудачного выбора дисков

По графикам выше можно сделать следующие выводы:

Диски куплены очень большие и впустую, их не получается забить данными
Некоторые диски перегружены записью. Возможно имеет смысл обратиться в поддержку за помощью по поиску стратегии более равномерной нагрузки на диски.
Flussonic RAID справляется с защитой соседних дисков от перегрузки. Несмотря на один сбойный диск, остальные с работой справляются.

Потоки и клиенты¶

Мониторинг активных потоков и подключенных клиентов. График обзорный, более детальная картина на соседних дешбордах.

Количество потоков

Рекомендуется мониторить при апгрейдах и следить за тем, что бы картина после апгрейда не менялась.

Количество клиентов

Рекомендуется мониторить при апгрейдах и совмещать с работой балансировщика, убедиться в том, что количество выходит на предыдущий до апгрейда уровень.

Ретроспектива за 3 месяца

Видно, что на этом сервере за 3 месяца количество стримов резко не менялось, их плавно переносят на новые сервера.

Сетевой трафик¶

Мониторинг входящего и исходящего сетевого трафика.

Входящий трафик в медиасервер

Дает представление о том, сколько входящего трафика видит сам медиа сервер. Иногда может радикально отличаться от системного графика, если есть захват с ASI, SDI или loopback.

Входящий системный трафик

Сколько трафика заходит в операционную систему. Может ощутимо отличаться и быть причиной отказов сети, если есть ещё потребители трафика кроме медиасервера.

Исходящий трафик медиасервера

Исходящий системный трафик