Skip to content

Ошибки входа

Один счётчик ошибок отвечает только на вопрос «на входе есть проблема». Головной станции этого мало: причина определяет, кому звонить. Потери пакетов — это сеть, отказ соединения — это партнёр, таймаут рукопожатия — это его энкодер или файрвол между вами.

Поэтому ошибки входа считаются по причинам, и каждая причина — отдельная линия на графике и отдельная серия в метриках.

Две семьи причин

  • Медиа-дефекты живого потока — данные приходят, но испорчены: lost_packets, broken_payload, desync, ts_pat.
  • Отказы источника — данных нет, и причина смерти названа: connection_closed, connection_refused, timeout, http_request_error, not_found, denied, decode_error, protocol_error, io_error, other.

Разница практическая. Первая семья означает, что сигнал идёт и его надо чинить по транспорту — там же смотрите счётчики TR 101 290. Вторая означает, что сигнала нет вовсе, и чинить надо соединение.

Как это считается:

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

График в карточке стрима

Панель Ошибки источника на вкладке Источники рисует ошибки за минуту раздельными линиями по причинам. Причины без событий легенду не занимают — на графике видно ровно то, что происходит.

Минуты, в которые темп входных кадров был нулевым, подсвечены как outage. Это ответ на вопрос, который одним счётчиком ошибок не закрывается: были ли это ошибки при живом сигнале или сигнала в это время не было вовсе.

Потеря SRT-источника: полосы outage и таймауты ретраев

Недоступный HLS- или HTTP-MPEGTS-источник даёт http_request_error на каждый ретрай, отказ SRT-рукопожатия по таймауту — timeout:

Мёртвые входы: http_request_error и timeout

Без опции «расширенные счётчики» панель показывает одну агрегатную линию; детальные линии появляются вместе с опцией.

Серия метрик

Во встроенном Prometheus-сервере детализация едет одной серией с лейблом причины — errors_detail_total{name, cause}; когда станций несколько, серии несут ещё и node. Причины без единого события серий не заводят.

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

# все входы, где сейчас идут отказы соединения
sum by (name) (rate(errors_detail_total{cause="connection_closed"}[5m])) > 0

Как читать

Что видно Что это значит
lost_packets при живом битрейте теряет сеть между источником и станцией; ищите на счётчиках транспорта, какой PID страдает
timeout пачками, полосы outage источник не отвечает; каждая пачка — очередной ретрай
http_request_error ровным гребнем HTTP-источник недоступен: адрес, DNS, файрвол или упавший ориджин
connection_closed при живом стриме партнёр рвёт соединение сам; смотрите его сторону
denied, not_found доступ или путь: ключ, streamid, имя ресурса
desync, broken_payload данные приходят битыми — транспорт или кодировщик на той стороне

Одиночная ошибка на графике — норма сети. Диагноз ставит форма: ровный гребень одной причины, пачки вокруг полос outage, рост при неизменном битрейте.

Что дальше