Документация › Работа с клиентами › Логи событий

Логи событий

«Что бот сделал за кадром»: вызовы функций, поиск по базе знаний, действия в CRM. Эти события видны прямо в ленте диалога, чтобы можно было понять, почему бот ответил так, а не иначе.

⏱ 7 мин · 👤 для владельца и оператора · 🟢 live

За 30 секунд:
В диалоге, помимо сообщений, видны карточки событий: вызвал функцию, искал в базе знаний, изменил сделку в CRM.
Типы: function_call (вызов функции), kb_search (поиск по базе знаний), *`crm_inbound_`** (события из внешней CRM).
В карточке, что именно сделал, успех/ошибка, сколько заняло. Секреты маскируются.
Это главный инструмент диагностики «почему бот так поступил».

Раздел «Логи», что бот делал, вызовы функций, поиск по знаниям, действия CRM

Зачем это нужно

Сообщения показывают, что бот написал. Логи событий показывают, что он делал между сообщениями: дёрнул ли функцию записи, нашёл ли ответ в базе знаний, отправил ли сделку в CRM. Без этого «почему бот так ответил», гадание.

События приходят через API диалога (/projects/<id>/conversations/<convId>/events) и показываются карточками в ленте переписки, в хронологии с сообщениями. Обновляются в реальном времени.

Какие события видны

Тип события	Что значит	Что в карточке
`function_call`	бот вызвал функцию	имя функции, успех/ошибка, длительность, запрос/ответ (обрезаны)
`kb_search`	бот искал в базе знаний	запрос, сколько источников нашёл, не ниже ли порога релевантности
*`crm_inbound_`**	пришло событие из внешней CRM	смена статуса сделки / заметка / обновление контакта

Среди crm_inbound_*: изменение статуса сделки, обновление сделки, удаление, добавление заметки, обновление контакта.

📌 Где искать падения функций. Если бот «должен был записать, но не записал», открой логи диалога и найди карточку function_call: там видно, вызвал ли он функцию и с какой ошибкой. → Функция не вызывается / падает

Безопасность данных в логах

Секреты маскируются. Токены, ключи, авторизация в параметрах функций редактируются перед сохранением.
Объём ограничен. Запрос/ответ функции обрезаются до ~2000 символов каждый, чтобы логи не разрастались и не текли.

Под капотом

Два журнала. Исходящие действия бота в CRM (создать/двинуть/прокомментировать сделку) пишутся в отдельный журнал crm_action_log (с полями action / result / error_message / crm_deal_id), а не в общий events_log. В ленте диалога они объединяются: «сырой» function_call для crm_* отбрасывается, показывается более информативная запись из crm_action_log (дедуп).
Forensic. events_log и crm_action_log: это история для разбора инцидентов; при удалении проекта такие записи сохраняются (не каскадятся), чтобы можно было провести пост-мортем.
Realtime. Лента подписана на оба журнала через Postgres Changes: события появляются без обновления страницы.

Простыми словами

Представь, что у бота есть «руки», он не только пишет, но и делает: записывает клиента в таблицу, ищет цену в базе знаний, заводит сделку в CRM. Логи событий это как раз список того, что он сделал руками, прямо внутри переписки, отдельными плашками между сообщениями.

Зачем тебе это? Чтобы понимать, почему бот ответил именно так. Сказал «записал вас на 15:00», а в плашке видно, реально ли сработала функция записи или упала с ошибкой. Это лучшее место, чтобы разобраться, когда что-то идёт не так. А чувствительные данные вроде паролей и ключей в этих логах автоматически замазываются, утечки не будет.

Дальше: → Обзор интеграций
Связано: Диалоги · Функции · База знаний · Функция не вызывается / падает
Не получилось? → Функция не вызывается / падает