---
title: Обращение в техподдержку
url: https://doc2.pstreamer.tv/ru/manual/support/index.html
lang: ru
product: Perfect Streamer
version: 2.0.2.399
---

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

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

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

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

## Вопросник

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

**Узел**

1. Какая версия сборки установлена? Она показана на экране [О системе](../webui/administration.md#webui-about) в разделе «Сборка и библиотеки»; из командной строки её вместе с версиями встроенных библиотек выводит `/usr/local/bin/pss -v`.
2. Какая операционная система и её версия? Узел работает на физическом сервере или в виртуальной машине?
3. Какое оборудование задействовано в проблеме: модель процессора и объём памяти, модели сетевых карт, видеокарт и DVB-плат?
4. Узел работает один или входит в домен Meshwork? Если в домене — сколько в нём узлов и на всех ли одна и та же версия сборки?
5. Какой тип лицензии и действует ли она? Экран [Лицензия](../webui/administration.md#webui-license). Идентификатор ключа и файлы C2V/V2C к обращению не прикладываются, пока поддержка их не запросит.

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

1. Что ожидалось и что происходит вместо этого? Опишите наблюдаемое, а не предполагаемую причину: «на выходе HLS картинка замирает раз в несколько минут», а не «сломался транскодер».
2. Когда проблема появилась впервые и когда проявлялась в последний раз? Время указывайте с часовым поясом. Журнал `main.log` по умолчанию пишет время по UTC и без года (Журнал службы) — соотнесите одно с другим.
3. Проблема постоянная, периодическая или случилась один раз? Если периодическая — с какой частотой и есть ли закономерность: время суток, нагрузка, определённый источник.
4. Воспроизводится ли проблема по шагам? Если да — перечислите их.
5. Что изменилось незадолго до появления проблемы: обновление сборки или операционной системы, правка настроек, замена оборудования, изменения в сети или у источника?

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

1. Какие потоки затронуты — номера потоков на узле? Затронуты все потоки, часть или один?
2. Какой транспорт на входе и на выходе затронутого потока, SPTS это или MPTS? Используется ли транскодирование, и если да — какой бэкенд и какой версии ([Бэкенды и кодеки](../streamer/transcoder.md#streamer-transcoder-backends), экран [О системе](../webui/administration.md#webui-about), раздел «Транскодеры»)?
3. Какие кодеки и какой битрейт у источника? Если есть отчёт анализатора (Что приложить), этот вопрос закрывает он.
4. Проблема на стороне входа или выхода? Видна ли она в статистике потока ([Статистика потока](../webui/streams.md#webui-stream-stats)) — ошибки непрерывности, переключения на резервный вход, сброс буфера?
5. Как ведёт себя тот же источник в обход узла или на другом узле? Как ведёт себя другой источник на том же потоке?

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

1. Перезапускалась ли служба в интервале проблемы? На экране [Журналы](../webui/monitor.md#webui-logs) каждый запуск отмечен строкой «Запуск стримера»; прогон, завершившийся без штатной остановки, помечен отдельно.
2. Какие оповещения активны на узле ([Оповещения](../webui/monitor.md#webui-alerts))?
3. Какова загрузка процессора, памяти и сетевых интерфейсов в момент проблемы? Экран [Системный монитор](../webui/monitor.md#webui-system), блок «История».

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

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

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

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

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

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

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

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

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

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

**Записи экрана** [Журналы](../webui/monitor.md#webui-logs), отобранные по затронутому потоку и диапазону дат. Полный текст отдельной записи копируется кнопкой «Скопировать сообщение».

**Снимки экрана** статистики затронутого потока ([Статистика потока](../webui/streams.md#webui-stream-stats)) и системного монитора за тот же интервал.

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

**Отчёт анализатора по источнику**, если проблема похожа на дефект самого потока: утилита [TS Analyze Perfect Streamer Toolkit v2.3 — TR 101 290](../toolkit/ts_analyze.md#toolkit-ts-analyze) читает UDP или файл и выдаёт текстовый или XML-отчёт.

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

- лицензия и ключ — вывод `pss_lic` с опцией `-v` ([PSS Lic Perfect Streamer Toolkit v2.0 — лицензия узла](../toolkit/pss_lic.md#toolkit-pss-lic));
- аппаратный транскодер NVIDIA — `nvidia-smi`, Intel — `vainfo --display drm --device /dev/dri/renderD128` ([Транскодеры](../install/transcoder.md#install-transcoder));
- потери приёма UDP-мультикаста — `netstat -su`, строка `RcvbufErrors` ([Рекомендации по работе с UDP-мультикастом](../faq/index.md#faq-multicast-nic)).

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

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

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

```sh
$ 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`.

Уровень журналирования задаётся на экране [Настройки сервера](../webui/administration.md#webui-server-settings) — общий и отдельно для библиотек SRT, RIST и FFmpeg. Для входов и выходов отдельных транспортов есть собственная трассировка — поле `Trace` ([Поля входов и выходов по транспортам](../webui/io/index.md#webui-io)). Повышайте уровень или включайте трассировку, только когда об этом просит поддержка, и возвращайте прежнее значение после сбора: подробный журнал быстро растёт.

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

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

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

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

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

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

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

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

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

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

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

- пароли, парольные фразы, ключи и секреты — полный перечень ключей конфигурации, которые их хранят, приведён в разделе [Значения, которые нельзя пересылать](../extras/config_file.md#extras-config-file-secrets);
- адреса с учётными данными прямо в ссылке — у источника входа и у адреса публикации на внешнюю площадку;
- IP-адреса и имена хостов источников, получателей и абонентов, а также адреса самого узла;
- имена абонентов, логины учётных записей, названия каналов и сведения о заказчике, если они сами по себе раскрывают информацию.

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

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