Обращение в техподдержку

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

Обращение направляется по электронной почте; адрес службы поддержки указан на сайте https://pstreamer.tv/.

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

Вопросник

Ответьте на вопросы по порядку. Если ответ неизвестен, так и напишите: это тоже сведения, и они экономят время.

Узел

  1. Какая версия сборки установлена? Она показана на экране О системе в разделе «Сборка и библиотеки»; из командной строки её вместе с версиями встроенных библиотек выводит /usr/local/bin/pss -v.

  2. Какая операционная система и её версия? Узел работает на физическом сервере или в виртуальной машине?

  3. Какое оборудование задействовано в проблеме: модель процессора и объём памяти, модели сетевых карт, видеокарт и DVB-плат?

  4. Узел работает один или входит в домен Meshwork? Если в домене — сколько в нём узлов и на всех ли одна и та же версия сборки?

  5. Какой тип лицензии и действует ли она? Экран Лицензия. Идентификатор ключа и файлы C2V/V2C к обращению не прикладываются, пока поддержка их не запросит.

Что происходит

  1. Что ожидалось и что происходит вместо этого? Опишите наблюдаемое, а не предполагаемую причину: «на выходе HLS картинка замирает раз в несколько минут», а не «сломался транскодер».

  2. Когда проблема появилась впервые и когда проявлялась в последний раз? Время указывайте с часовым поясом. Журнал main.log по умолчанию пишет время по UTC и без года (Журнал службы) — соотнесите одно с другим.

  3. Проблема постоянная, периодическая или случилась один раз? Если периодическая — с какой частотой и есть ли закономерность: время суток, нагрузка, определённый источник.

  4. Воспроизводится ли проблема по шагам? Если да — перечислите их.

  5. Что изменилось незадолго до появления проблемы: обновление сборки или операционной системы, правка настроек, замена оборудования, изменения в сети или у источника?

Затронутые потоки

  1. Какие потоки затронуты — номера потоков на узле? Затронуты все потоки, часть или один?

  2. Какой транспорт на входе и на выходе затронутого потока, SPTS это или MPTS? Используется ли транскодирование, и если да — какой бэкенд и какой версии (Бэкенды и кодеки, экран О системе, раздел «Транскодеры»)?

  3. Какие кодеки и какой битрейт у источника? Если есть отчёт анализатора (Что приложить), этот вопрос закрывает он.

  4. Проблема на стороне входа или выхода? Видна ли она в статистике потока (Статистика потока) — ошибки непрерывности, переключения на резервный вход, сброс буфера?

  5. Как ведёт себя тот же источник в обход узла или на другом узле? Как ведёт себя другой источник на том же потоке?

Служба и ресурсы

  1. Перезапускалась ли служба в интервале проблемы? На экране Журналы каждый запуск отмечен строкой «Запуск стримера»; прогон, завершившийся без штатной остановки, помечен отдельно.

  2. Какие оповещения активны на узле (Оповещения)?

  3. Какова загрузка процессора, памяти и сетевых интерфейсов в момент проблемы? Экран Системный монитор, блок «История».

Что уже сделано

  1. Какие действия уже предпринимались и что из них дало результат: перезапуск потока или службы, смена входа, изменение настроек?

Хронология инцидента

  1. Опишите ход событий по порядку, с отметками времени и часовым поясом:

    • последний момент, когда всё работало как ожидалось;

    • изменения, сделанные после него, — на узле, в сети, у источника или получателя;

    • первое проявление проблемы и как её обнаружили: оповещение, жалоба абонента, собственное наблюдение;

    • как проблема развивалась дальше: усиливалась, проходила сама, повторялась;

    • каждое предпринятое действие и что после него изменилось;

    • текущее состояние на момент обращения.

    Хронология связывает ответы на предыдущие вопросы в одну картину и позволяет сопоставить события с журналом узла строка за строкой.

Что приложить

Прикладывайте то, что относится к проблеме. Перечень ниже — наиболее частые материалы, а не обязательный набор.

Журнал службы за интервал проблемы — см. Журнал службы.

Журналы транскодера, если в проблеме участвует транскодирование, — прежде всего «Предыдущий журнал» процесса, а также последний код выхода и текущий журнал. Они хранятся только в памяти узла и теряются при перезапусках, поэтому снимайте их первыми — см. Журналы транскодера.

Записи экрана Журналы, отобранные по затронутому потоку и диапазону дат. Полный текст отдельной записи копируется кнопкой «Скопировать сообщение».

Снимки экрана статистики затронутого потока (Статистика потока) и системного монитора за тот же интервал.

Настройки затронутого потока — только после очистки (Приватные данные). Полная резервная копия конфигурации с экрана Обслуживание содержит пароли и ключи всех объектов узла в открытом виде; прикладывайте её, только если поддержка попросит, и тоже после очистки.

Отчёт анализатора по источнику, если проблема похожа на дефект самого потока: утилита TS Analyze Perfect Streamer Toolkit v2.3 — TR 101 290 читает UDP или файл и выдаёт текстовый или XML-отчёт.

Вывод диагностики по профилю проблемы:

Журнал службы

Служба пишет журнал в файл main.log. Каталог задаёт ключ log-dir файла pss.properties, по умолчанию — /var/log/pss. Файл ротируется ежедневно: прошлые дни лежат рядом в файлах main.log.<метка времени>, поэтому для интервала в прошлом нужен файл того дня, а не текущий main.log.

Время в строках журнала указано без года и по умолчанию по UTC; местное время включает ключ log-time-local того же файла.

$ ls -l /var/log/pss/
$ tail -n 200 /var/log/pss/main.log
$ journalctl -u pss -n 50

Две последние команды не равнозначны. Если служба не поднялась вовсе, причина может лежать раньше самого журнала — недоступен его каталог, не читается pss.properties, — и тогда в main.log об этом не будет ни строки: файл может остаться от прошлого запуска и показывать старое. Такую причину служба печатает строкой, начинающейся с !!!, и видна она в системном журнале, то есть в выводе journalctl -u pss. Обычные строки журнала попадают туда же, только если в pss.properties включён log-to-console или log-to-syslog.

Уровень журналирования задаётся на экране Настройки сервера — общий и отдельно для библиотек SRT, RIST и FFmpeg. Для входов и выходов отдельных транспортов есть собственная трассировка — поле Trace (Поля входов и выходов по транспортам). Повышайте уровень или включайте трассировку, только когда об этом просит поддержка, и возвращайте прежнее значение после сбора: подробный журнал быстро растёт.

Журналы транскодера

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

Процесс транскодера ведёт подробный журнал всегда, отдельно включать трассировку не нужно. Но в файл этот журнал не пишется: узел держит в памяти только его хвост, последние 256 КБ, и только для двух запусков процесса — текущего и предыдущего. Открывается журнал в окне Экземпляр транскодера (экран Транскодеры), в блоке «Журнал процесса»: «Текущий журнал», «Предыдущий журнал» и «Последний код выхода». Каждый журнал забирается кнопкой «Копировать».

Ценнее всего «Предыдущий журнал». Сбойный процесс обычно уже перезапущен — сторожевым таймером или самим узлом, — и тогда именно предыдущий журнал содержит запуск, который завершился, вместе с сообщениями, предшествовавшими сбою. Текущий журнал описывает уже новый запуск и показывает только, повторяется ли проблема.

Из этого следуют правила сбора:

  • Копируйте «Предыдущий журнал» сразу, как только заметили проблему. Каждый новый запуск процесса — сторожевой перезапуск, остановка и повторный старт потока — сдвигает журналы на одну позицию: текущий становится предыдущим, а прежний предыдущий стирается. Если сбой повторится ещё раз до того, как журнал скопирован, запись о первом сбое будет потеряна. Перезапуск службы или узла стирает оба журнала.

  • Не перезапускайте поток или службу до того, как журнал скопирован — даже если перезапуск восстанавливает работу.

  • Прикладывайте вместе с ним последний код выхода и текущий журнал.

  • У давно работающего процесса начало журнала уже вытеснено. Если важен момент запуска — например, выбор устройства и драйвера, — повторите проблему после перезапуска потока и скопируйте журнал сразу.

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

$ grep -i 'transcoder' /var/log/pss/main.log

К журналам транскодера приложите тип и версию бэкенда с экрана О системе (раздел «Транскодеры») и вывод диагностики устройства — nvidia-smi или vainfo (Что приложить).

Приватные данные

Журналы, настройки и снимки экрана содержат данные, которые в обращение попадать не должны. Перед отправкой замените их:

  • пароли, парольные фразы, ключи и секреты — полный перечень ключей конфигурации, которые их хранят, приведён в разделе Значения, которые нельзя пересылать;

  • адреса с учётными данными прямо в ссылке — у источника входа и у адреса публикации на внешнюю площадку;

  • IP-адреса и имена хостов источников, получателей и абонентов, а также адреса самого узла;

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

Заменяйте последовательно: одно и то же исходное значение — везде одной и той же подстановкой (10.0.0.5 → HOST-A). Тогда в очищенном журнале по-прежнему видно, какие строки относятся к одному узлу, а какие — к разным, и разбор не теряет смысла.

Не передавайте в обращении учётные данные для входа на узел или в его веб-интерфейс. Если для разбора потребуется доступ, способ его предоставления согласуется отдельно.