Из цикла ETL для зоопарка ботов: из Dialogflow в BigQuery

Это вторая статья из ETL-цикла о «зоопарке» ботов на Python. В ней я разложу шаги от старта разработки/настройки до регулярной поддержки проекта. С  попутным описанием вспомогательных фичей. 

Если у вашего бота уже есть пользователи, и вы хотите начать анализировать их данные — статья для вас.
Анонс цикла

Dialogflow → Logs Router

Перед вами бот в Dialogflow ES (Essentials), отвечающий на часто задаваемые вопросы. Для простоты демонстрации оставлю лишь одно древо намерений, на наладку потока данных это не повлияет.

Переходим в настройки проекта, нажав на «шестеренку» (1), и попадем в раздел General (Общее). Включаем запись логов (2) и их отправку в выделенное хранилище Google Cloud (3). Жмём Save. 

Консоль Logs Explorer

Теперь каждую реплику — и все 46 столбцов её метаданных  — можно увидеть в системе Logs Router (https://console.cloud.google.com/logs/query?project=[название_проекта)].

Это прослойка между конструктором и хранилищем BigQuery, которая поддерживает SQL-запросы и позволяет конструировать их с помощью множества параметров. Самые важные вынесены в верхнюю правую часть конструктора в виде дропдаунов:

• Resource — на случай связи с продуктами вроде Firebase;
• Log name — тип лога: реплики пользователей и бота, активности модераторов, системные события;
• Severity — серьезность события: критическая ошибка, простое уведомление или стандартное состояние;
• Relative Time — выбор временного интервала, на скриншоте выглядит как Last 7 days. 

Во избежание лишних затрат, Logs Explorer хранит данные только за последние два месяца. 

Помимо запросов, вы можете наблюдать за диалогами в режиме реального времени с помощью Stream logs. В этом представлении логи подгружаются в список снизу сразу.

С помощью Create metric вы можете создать подсчитываемое значение, например, число ошибок. Или мониторить скорость ответа сервера с помощью подвида метрики Distribution. 

На время отладки экспериментальных фичей (у нас бот сверяется со справочником юрлиц) функция Create alert позволит отфильтровать определённые запросы с помощью SQL и выслать их на почту или в мессенджер.

Соорудим запрос

Я воспользуюсь тестовым выражением из документации — «выбрать все ошибки за временной интервал»:

severity>=ERROR AND

timestamp>="2023-06-01T00:00:00Z" AND timestamp<="2023-06-18T00:00:00Z"

Если при попадании в консоль у вас не отображается поле для выражения, нажмите Show query в правой верхней части экрана.

Бывает, что сервер справочника юрлиц не отвечает (1). Или при обновлении скрипта, рассчитывающего эффективность той или иной группы намерений, я путаю типы числовых фичей (2). 

Так мы получим выдержку только из ошибочных логов за период с 1 по 18 июня. В неё льется множество полезных данных, например, можно отслеживать активность модераторов бота с помощью гистограммы и логов типа activity:

Однако Logs Router не в состоянии преобразовать логи или представить их по индивидуальным потребностям хозяев проекта. Потому мы подключили платное и хранилище BigQuery. Нам оно обходится в 5 рублей в месяц. 

Среди официальных партнёров Google есть те, кто производит переводы за рубеж и предоставляет закрывающие документы. Но для теста подойдут и малыши-помогаторы. Я проверила Плати Легко!, и за исключением комиссии в 20% нареканий нет.

Logs Router → BigQuery

Настраиваем так называемую «раковину» — промежуточное ПО, автоматически передающее логи в базу данных. Для этого наводим курсор на раскрывающееся меню слева и выбираем Logs Router:

Попав в раздел, жмём Create Sink и попадаем на форму. 

Я создаю роутер, который выгружает в BigQuery все логи, поэтому в разделе Choose logs to include in sink не заполняю поле. 

На следующем шаге можно исключить некоторые логи. Тогда в поле лег бы SQL-запрос:

severity>=ERROR

Иногда «раковину» удаётся создать не с первого раза, вылезают системные ошибки, на которые пользователю почти никак не повлиять. Если вы столкнулись с таким, просто пересоздайте её на следующий день. 

Мне повезло: 

Спустя примерно сутки логи полностью зальются в BigQuery.

Теперь, когда потоковые данные попали в DWH, мы можем создать так называемые «представления» (Views) — виртуальную таблицу, содержимое которой определяется запросом. То есть начать «вращать» данные под любым углом, фильтровать их и готовить к BI-системам.

Заключение

Google сделал многое, чтобы упростить и без того комплексные процедуры обработки пользовательских данных. Отдельно радует, конечно, отлаженность всех систем (ошибки встречаются редко). 

И хоть Dialogflow ES уже отходит на второй план в сравнении со своим собратом Dialogflow CX, он по-прежнему имеет больше активных проектов, лучше «обкатан» на форумах и является конструктором из ТОП-5 самых популярных в мире. 

В следующей статье мы подробно разберём, как работают регулярные представления, как подружиться с JOIN’ами, научиться как бы мерджить таблицы с помощью CTE и многое другое.

Каким сервисом оплаты зарубежного ПО вы пользуетесь? Какая минимальная комиссия? Поделитесь в комментариях.