Что запрашивать, у кого и в каком порядке, чтобы получить возможность выгружать
диалоги, аудиозаписи и технические логи звонков. Заявки на ИФТ и ПРОМ поданы, маршрут проверен
на практике. Сверху — инструкция целиком, ниже — схема связей и пояснения к ней.
Инструкция
🎯Цель
Регулярно выгружать диалоги и записи для разбора звонков
По конкретному дефекту доходить до «что реально ушло в модель»
✅Что уже известномаршрут проверен на практике
Маршрут работает и занимает немного времени: пример — тикет SDMON-5160 «Доступ к кибане IFT», заведён и закрыт за 13 минут, учётные данные и ссылка пришли письмом
Это не отдельная учётка GigaChat, а доступ к общей платформе логирования Elastic, где лежат индексы SmartNLP и GigaChat. Работа идёт через интерфейс Kibana
Поиск по request-id там работает — проверено на запросе к GigaChat из ноутбука на ИФТ
⚠️ На звонке это не проверялось: искали запрос, который делали руками и чей id был известен заранее. Что можно найти запрос, порождённый звонком, — открытый вопрос
Заявки поданы: ИФТ — SD0289350910, ПРОМ — отдельная по другому маршруту. Учётка нужна каждому своя
🔐Доступ на ИФТдва шага, маршрут проверен
Инструкция: Confluence, пространство «Мониторинг SberDevices», страница «Доступы», pageId=9409597821
Шаг 1. Заявка в ДРУГ «Доступ к стендам разработки и тестирования», в поле автоматизированной системы указать SmartNLP (CI01808661). Сегмент сети — ваш фактический, обычно SIGMA
Шаг 2. После согласования — тикет в бэклог Jira, проект SDMON (SberDevices Monitoring), свободная форма. Готовый текст:
Доступ к Kibana ИФТ
Прошу предоставить read-only доступ к Elastic/Kibana ИФТ для поиска логов
SmartNLP и GigaChat по request-id в рамках диагностики проекта ЦКМ.
Сетевой доступ к SmartNLP (CI01808661) получен по заявке SD0289350910.
Сегмент: SIGMA, физдоступ имеется.
Согласуйте, пожалуйста, Еременко Руслан Александрович,
Романенков Максим Владимирович.
Шаг 3. Учётка приходит письмом со ссылкой на ресурс. Такой тикет закрывали за 13 минут
💡 Просить узко. PVS и Grafana в тикете не перечислять — проверенная формулировка упоминает только Kibana. Если чего-то не окажется, второй тикет займёт столько же времени, а широкая заявка может уйти на лишние согласования
Оговорка «Kibana — параллельно предоставляется доступ к PVS» относится к форме ДРУГ на ПРОМ и ПСИ, а не к свободному тикету на ИФТ
🏭Заявка на ПРОМподана 02.09
⚠️ ИФТ этих звонков не покажет. Внутренняя волна 28.08 проходила на ПРОМ, и штатные записи есть только на ПРОМ
Маршрут другой: ДРУГ, услуга «Доступ к автоматизированным системам Банка» — не «к тестовым ресурсам»
Тип заявки — Открытие. Класс среды — Промышленная. В этом положении стенд ПСИ для выбора недоступен, но он сейчас и не нужен
Автоматизированная система — АС SmartNLP.Мониторинг (ПРОМ)
⚠️ Форма даёт одну комбинацию, а не набор галочек. Как только отмечаешь Kibana в «Области данных», Grafana из выбора пропадает — то же с доменом. Grafana, если понадобится, подаётся отдельной заявкой с ролью «Пользователь viewer Grafana». Для поиска логов она не нужна
Полномочия — выпадающий список: Администратор Grafana, Пользователь 1line, Пользователь 3line, Пользователь smartapp_ide, Пользователь smsaide_rt_3line, Пользователь viewer Grafana. Выбран Пользователь 3line: 1line — первичный операционный мониторинг, 3line — техническое расследование. Это вывод по смыслу ролей, документацией не подтверждён
Область данных Виртуального Ассистента — B2B
Домен — тот, с которого работаете. С рабочего места на ПРОМ это OMEGA
Обоснование заполняется без указания полномочий, например: «Для доступа к логам запросов GigaChat по проекту ЦКМ (цифровой клиентский менеджер)»
🧩Что есть чточтобы не путать инструменты
Elasticsearch — база, где физически лежат логи и по которой идёт поиск. Учётку называют «учёткой Elastic», потому что заводится она именно там
Kibana — интерфейс к Elasticsearch. Открываете Discover, выбираете индекс, находите событие по полю и смотрите его целиком
PVS — внутренний просмотрщик логов того же класса: индексы, фильтры, поиск. По возможностям частично пересекается с Kibana
Grafana — графики и мониторинг: версии сервисов, доступность, ошибки, задержки во времени. Отдельных запросов и диалогов там нет
Разница на практике: в Kibana ищете конкретное событие — «запрос с таким request-id в 14:32 и что в нём было». В Grafana смотрите общую картину — «сколько сегодня ошибок и какая версия сервиса работает»
🔎Что проверить самому, как придёт учёткадо любых вопросов коллегам
Какие индексы и data view вообще открылись: только GigaChat и SkillFlow — или ещё GigaVoice
Открылись ли вместе с Kibana ещё PVS и Grafana
Имена полей известны из документации:X-Session-ID и X-Request-ID пишутся в каждое сообщение лога как session-id и request-id. Искать по ним
Латенси искать как отдельные записи: поле metric_name со значениями asr_latency, gopro_latency, tts_latency, turn_taking_latency, рядом process_time в миллисекундах и request_id_n
Есть ли событие service_info с версией движка
Видно ли тело запроса целиком — system prompt, messages, параметры — или только технические события
Находятся ли логи SkillFlow по context.user_id на индексах Delta
Находится ли звонок по времени и номеру, и видны ли диалог, IVR steps, completion code, voice_call_ID и идентификатор записи
⏰ Не забыть сменить диапазон с Last 24 hours на дату звонка
Главное: взять эталонный звонок и попробовать дойти от него до запроса в GigaChat. Это и есть незакрытый участок цепочки
🗂PVS и индексы SkillFlow
Старый индекс s.salut-ivr.skillflow.b2b.ift* после 24.08 пустой
Причина переезда: ИФТ-контур ELK на Sigma выведен из эксплуатации, всё переехало на Delta. Новые индексы и алиасы там создаются автоматически в течение часа после начала поступления данных
Рабочий приём: широкая выборка s.* с фильтром context.user_id: <номер> — отдаёт входящие и исходящие события Kafka по звонку
ИФТ, Delta: https://kibana.ift.sdmon.delta.sbrf.ru, обращение к elasticsearch по API https://api.elk.ift.sdmon.delta.sbrf.ru
ПРОМ, Alpha: https://kibana.sdmon.omega.sbrf.ru, отдельная Kibana для выгрузки csv-отчётов https://kibana-report.sdmon.omega.sbrf.ru, API https://api.elk.sdmon.omega.sbrf.ru
➕ Эти индексы относятся к SkillFlow и IVR: ingress, egress, context manager, application logs. Их наличие не означает, что там же лежат полные логи GigaVoice или тело запроса GigaChat
📦Собрать эталонный звонокдоступы не нужны
Взять звонок 16 из обзвона 28.08 — внутренняя волна, не клиенты, есть расшифровка и разбор
Зафиксировать в одном файле: дату и время, номер, расшифровку, наблюдаемое поведение, completion code
Это не проход цепочки, а заготовка. Прикладывать к каждому обращению ниже
Voice-дефекты рассматриваются по конкретным кейсам с session id и аудио, поэтому эталонный звонок существенно упростит обращение
У одного человека — не у всех сразу — попросить разовую выгрузку по этому звонку
📊СМДпосле проверки PVS
⚠️ Сначала посмотреть, не хватает ли PVS. Если звонок находится по времени и номеру, а диалог, completion code и идентификатор записи видны — отдельная подписка может не понадобиться. Заказывать витрину вслепую точно не стоит
Связь СМД и PVS не подтверждена. Похоже, это два способа потребления одних результатов: PVS — посмотреть вручную, СМД — регулярно выгружать
Если выяснится, что нужна массовая регулярная выгрузка, спрашивать у Яшагина и Паничева:
Точное название или ID подписки со звонками ЦКМ
Точное значение source для фильтра
Точное имя поля с идентификатором записи и как по нему слушать через PVS
➕ PVS — интерфейс просмотра и поиска, СМД — источник и подписка на данные. Доступ к PVS не заменяет подписку и право выгрузки. Возможность прослушать запись именно через PVS подтвердить у Паничева
Read-only доступ с правом выгрузки + retention
Разовая выгрузка эталонного звонка со всеми полями
Какие correlation-поля есть: call_id, voice_call_ID / session_id, id записи, возможно request_id / turn_id
⚠️ RqUID GigaChat в витрине отсутствует — запросы идут внутри платформы SmartIVR. Не закладываться
Подписка оформляется через Лабораторию данных
🎧Аудиоте же
Три разных вопроса, подтверждён только первый: слушать / скачать файл / получить две дорожки
Две дорожки нужны под шаблон дефектов: 1 канал — клиент, 2 канал — GigaVoice
Как запись связана с voice_call_ID, retention, правила доступа к ПРОМ-записям
На ИФТ штатной записи нет, на ПРОМ есть
🧾Логи GigaVoiceта же Kibana, не проверено
По voice_call_ID в Kibana находятся все логи GigaVoice — так сказали владельцы движка. Своей проверки не было
Отдельной системы для этого нет: доступ тот же, что к Kibana выше. Названия «АС NLP_Кибана» в инструкции по доступам не существует — это было распознано со слуха
Состав trace, который нужен: ASR, запрос в GigaChat с system prompt и messages, ответ, function call и результат, текст в TTS, ошибки, latency, VAD и перебивания, completion
🔗 X-Session-ID = voice_call_id — по документации это тождество, маппинг на уровне сессии не нужен
⚠️ X-Request-ID генерирует сам GigaVoice на каждую реплику. Логи GigaChat ищутся по request-id — совпадают ли эти значения, не проверено. Это главный открытый вопрос
Чанки одного синтеза несут общий uuid с суффиксами _m, _n. Одна реплика ≠ одна строка
🚫 Доступ в среду разработки SmartIVR не запрашивать — это инструмент разработчиков, не пользовательский маршрут
🔑Пермишены GigaVoiceсначала проверить логи, потом просить
⚠️ Просить преждевременно. Раздел документации называется «Логирование латенси и метрик»: компонентные латенси пишутся в серверные логи GigaVoice отдельными записями. Если Kibana отдаст индексы GigaVoice, метрики там уже будут и пермишены не понадобятся
Эти два списка управляют отправкой событий клиенту — то есть SmartIVR, который их ещё должен сохранить. Для анализа это другой путь
Порядок: получить Kibana → найти звонок по session-id → проверить, есть ли записи с metric_name и событие service_info. Обращаться только если их не окажется
UserIDsWithServiceInfoAccess — версия движка в сессии
CN основного запроса: CI03219423-IFT-CORP и CI03219423-PROM-kiparis-ckr
Старый CI00747093-IFT-CORP добавлять только если подтвердят, что через него ещё идут вызовы — пермишены работают на будущие события и старых логов не откроют
Уточнить, куда мы складываем приходящие service_info и metric — пермишен открывает поток, интерфейса просмотра не создаёт
➕ Тем же сообщением: лежит ли для наших CN что-то в config.system_prompt? Промпт передаётся через SkillFlow, а по документации конфигурационный дописывается к переданному в любом случае — если там копия, склеятся две версии нашего же промпта
💰 Зачем они вообще нужны: без раскладки задержки по участкам претензию «долгие паузы» нечем подтвердить — не видно, где уходит время, на распознавании, генерации или синтезе
🎚️Dumper — задать вопрос, не просить включить
Документация подтверждает сохранение входящего клиентского аудио в S3. Сохранение отдельной дорожки синтеза не описано и не гарантировано
Может затронуть весь трафик соответствующего инстанса или контура — scope, хранение и допустимость подтвердить у владельцев
Формулировка: «можно ли использовать Dumper для CN ЦКМ, на каком контуре, куда попадает аудио, кто имеет доступ и решает ли это задачу двухканальной записи?»
ИФТ выглядит единственным разумным местом для эксперимента — но только после согласования
⏸ Спрашивать имеет смысл только если штатным способом нужное аудио получить не удастся
💻Рабочее место
Вслепую не заказывать. У владельца каждого инструмента спросить: Сигма, Альфа, Омега или отдельный ВАРМ
В форме ДРУГ на ПРОМ указываются логины сразу в двух доменах — OMEGA и SIGMA, и домен выбирается отдельным полем
Просмотр и выгрузка могут требовать разных контуров — уточнять оба отдельно
⏳ Не тот ВАРМ через ДРУГ — потеря недель
🔬После получения доступов — пройти цепочку самостоятельно
запись в СМД → voice_call_ID → trace GigaVoice → request-id → запрос и ответ GigaChat → TTS → completion
На том же эталонном звонке: мы знаем, что в нём было, поэтому сразу видно, чего в логах нет
Главный незакрытый участок — мост от звонка к request-id. Логи GigaChat уже доступны и ищутся по id; неизвестно, как получить этот id для конкретного звонка
Ключевое по промпту: сверить фактический контекст с тем, что отправил SkillFlow. Собственного бизнес-промпта платформа не добавляет — проверяем, не задвоился ли наш промпт из конфига
При переданном silence_phrases_timeout в конец системного сообщения дописывается инструкция про пустое сообщение, а молчание пишется в историю как пара ходов, где ход клиента — пробел. Это одно из документированных платформенных дополнений к контексту: проверить, активна ли механика в нашем конфиге и нет ли других преобразований
⚠️Что не перепутать
СМД используется в проекте ещё и как источник исторических транскрибаций для персонализации. Это другая витрина и другая задача, технических логов не даст
Порядок
Заявки в ДРУГ поданы: ИФТ — SmartNLP (CI01808661), ПРОМ — АС SmartNLP.Мониторинг (ПРОМ). Ждём согласования
Пока ждём — собрать пакет по эталонному звонку. Больше ни от кого не зависитсегодня
Как согласуют ИФТ — тикет в бэклог SDMON, текст готов
Как придёт учётка — пройти чек-лист проверки самому, в Kibana и PVS
Зафиксировать, каких полей и возможностей реально не хватает
Только после этого — точечные вопросы владельцам: Головину и Вяткину по метрикам, Яшагину и Паничеву по витрине и аудио
Пройти цепочку на эталонном звонке и зафиксировать, где она обрывается
Схема связей
Ключевое разделение. GigaVoice — оркестратор, а не модель. Неверная транскрибация — вопрос к ASR; верная транскрибация при кривом ответе — вопрос к GigaChat или к нашему промпту. Это позволяет делить дефекты по зонам ещё до обращения к смежникам.
Пояснения к схеме
СМД
витрина звонков · источник и подписка
Внутри
Диалог вопрос-ответ, IVR steps, номер и время, сценарий, completion code, идентификатор записи
Ключ
source, call_id
Смотреть
через PVS
Нет там
RqUID GigaChat — запросы идут внутри платформы SmartIVR
Кто
Яшагин, Паничев · подписка через Лабораторию данных
Статус
запросить
PVS · логи SkillFlow
ingress, egress, context manager, app logs
Индексы
s.kib-ckr-text-va.smnlp-sf-ivr.*
Ключ
context.user_id — номер телефона
Внимание
Старый индекс s.salut-ivr.skillflow.b2b.ift* пуст после 24.08: ИФТ-контур ELK переехал с Sigma на Delta
Границы
Полных логов GigaVoice и тела запроса GigaChat здесь может не быть
Статус
проверить, придёт ли с Kibana
Логи GigaVoice
та же Kibana
Внутри
ASR, сборка контекста, запрос и ответ модели, function call, текст в TTS, ошибки, latency, VAD
Ключ
voice_call_ID
Кто
Качалова работала с этими логами
Статус
не проверено
Логи GigaChat
та же Kibana, ИФТ
Ключ
request-id
Доступ
Тикет SDMON-5160, закрыт за 13 минут
Проверено
Собственный запрос из ноутбука — не запрос от звонка
Статус
доступ есть
Аудиозаписи
на ПРОМ есть, на ИФТ штатной записи нет
Ключ
идентификатор записи из СМД
Слушать
подтверждено
Скачать
не подтверждено
2 дорожки
не подтверждено — нужно: 1 канал клиент, 2 канал GigaVoice
Пермишены GigaVoice
выдаются по CN
Даёт
service_info — версия движка в сессии metric — asr_latency, gopro_latency, tts_latency, turn_taking_latency
CN
CI03219423-IFT-CORP CI03219423-PROM-kiparis-ckr
Кто
Головин, Вяткин
Учесть
Латенси пишутся в серверные логи GigaVoice — если Kibana их отдаст, пермишены не нужны
Статус
сначала проверить в логах
подтверждено частично / требует проверки нужно запросить неизвестно
Что учесть
Сначала смотрим, потом спрашиваем
Почти всё, что хотелось уточнить у коллег, видно в логах самому. Обращение после проверки будет предметным: вот звонок, вот индекс, вот чего в нём нет.
PVS — это не СМД
PVS — интерфейс просмотра и поиска, СМД — источник и подписка. Доступ к PVS не заменяет подписку и право выгрузки.
ИФТ и ПРОМ просят по-разному
На ИФТ — свободный тикет, и формулировка узкая: только Kibana. На ПРОМ — форма, и она открывает одну комбинацию: выбрали Kibana — Grafana пропала из списка. Grafana при необходимости подаётся отдельно.
Dumper — не решение для аудио
Только входящий клиентский звук; дорожка синтеза не гарантирована. Может затронуть весь трафик инстанса. Уместен, похоже, только на ИФТ и только после согласования.
Две разные витрины СМД
Нужна витрина с результатами звонков. Историческая витрина транскрибаций для персонализации — другая задача, технических логов не даст.
Кто за что отвечает
Кто
Зона
С чем идти
Николай Яшагин Сергей Паничев
СМД, SmartIVR, аудиозаписи
Название и ID подписки, точный source, поле с идентификатором записи, retention, право выгрузки, разовая выгрузка эталонного звонка, вопросы по аудио
SberDevices Monitoring
Kibana, PVS, Grafana
Заявка в ДРУГ на SmartNLP (CI01808661), затем тикет в бэклог Jira SDMON в свободной форме. Согласующие — Еременко Руслан Александрович, Романенков Максим Владимирович
Екатерина Качалова
Поиск в логах
Как искать логи GigaVoice — работала с ними
Павел Головин Виктор Вяткин
GigaVoice
Пермишены service_info и metric по CN; вопросы по Dumper; лежит ли что-то в config.system_prompt для наших CN