Мониторинг¶

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

Правило выбора простое:

• «Что происходит сейчас?» — панель или API.
• «Что происходило последние часы?» — встроенный Prometheus-сервер.
• «Что было на прошлой неделе и почему упало ночью?» — Retroview.
• «Хочу свой Prometheus, Grafana и alertmanager» — скрейп.

Что именно смотреть¶

Разбор счётчиков живёт на задачных страницах, а не здесь:

• Контроль доставки — направления: статус, скорость, ошибки, реконнекты, ретрансмиты.
• Ошибки входа — причины отказов и минуты без сигнала.
• TR 101 290 — качество транспорта по каждому PID.
• Резервирование входов — время на основном и на резерве.

Встроенный Prometheus-сервер¶

Внутри Mcaster работает Prometheus-сервер: HTTP API /api/v1/query, /api/v1/query_range, /api/v1/series, /api/v1/labels, /api/v1/label/{name}/values поверх собственного хранилища в памяти. Для Grafana это готовый датасорс — добавьте датасорс типа Prometheus и укажите URL станции. Этими же запросами питаются графики панели.

Ограничения по построению:

• история — несколько часов, в памяти; после перезапуска хранилище пустое. Это канал «что происходит сейчас», а не архив метрик;
• PromQL поддержан подмножеством: селекторы с матчерами лейблов, rate/irate/increase, агрегации sum/avg/min/max/count с by()/without(), арифметика, offset. Неподдержанная конструкция возвращает явную ошибку, а не искажённый результат;
• набор серий базовый; глубина по PID, SRT и RTP приходит с опцией «расширенные счётчики».

# скорость приёма стрима
rate(stream_input_bytes_total{stream="tv1"}[1m])

# ошибки входа за 5 минут по причинам
sum by (cause) (increase(errors_detail_total{name="tv1"}[5m]))

# отдача по каждому направлению
rate(stream_push_bytes_total{stream="tv1"}[1m])

Когда станций несколько, каждая серия несёт лейбл node, а один и тот же дашборд работает и против одной станции, и против управляющего контура: агрегируйте sum without (node) — на одиночной машине лейбла нет, и агрегация ничего не меняет.

Скрейп для своего мониторинга¶

Метрики в текстовом формате Prometheus:

• GET /streamer/api-v4/live-metrics — стримы и входы;
• GET /streamer/api-v4/sessions-metrics — сессии;
• GET /streamer/api-v4/dvr/metrics — диски и каталог архива;
• GET /streamer/api-v4/runtime/metrics — процесс и аллокатор.

История хранится у вас и ограничена только retention'ом вашей TSDB; доступна полная глубина, включая метрики по каждому PID, SRT и RTP; алертинг — ваш alertmanager. Счётчики монотонны и переживают наблюдение перезапусков.

Retroview¶

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

Когда идти туда, а не во встроенный Prometheus-сервер:

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

Логи¶

Логи структурированные, уровень задаётся переменной RUST_LOG:

journalctl -u mcaster -f

Записи несут имя стрима и целевой модуль, поэтому фильтровать по конкретному стриму можно и без внешнего индексатора. Трейсы экспортируются по OpenTelemetry (OTLP).

Здоровье станции¶

• Readiness-проба: GET /streamer/api/v3/monitoring/readiness — для балансировщиков и оркестраторов.
• Память по частям пайплайна: sum by (part) (stream_memory_bytes) — монотонный рост без роста нагрузки требует разбирательства.