Всем привет! Меня зовут Дима Зотов, я специалист техподдержки. Работаю в Почтатехе на проекте Почта.ID. Мы обеспечиваем регистрацию и вход в сервисы Почты России, а также отвечаем за хранение учетных записей. Еще разрабатываем решения для некоторых почтовых услуг. Например, получение отправлений по коду или отправка электронных извещений.
Я расскажу про подход к логированию, который используется на нашем проекте: почему мы выделили бизнес-логи в отдельную категорию и как с их помощью обеспечили observability процессов.
Статья будет полезна продактам, которые хотят прокачать поддержку на своем проекте и упростить сбор статистики, а также специалистам саппорта и всем, кто интересуется темой логирования.
Как мы пришли к бизнес-логированию
Немного истории о формировании поддержки на проекте.
По большей части мы оказываем поддержку для внешних пользователей — клиентов Почты России, физических и юридических лиц. Обычно они обращаются из-за проблем со входом и обслуживанием аккаунтов. Мы также решаем вопросы, связанные с упрощенным вручением отправлений, электронными доверенностями и извещениями, бонусной программой.
Формировать отдельный канал поддержки по продуктам нашего проекта мы начали в 2015 году. Но до 2019 года специалист по техподдержке отсутствовал — эту функцию обеспечивали силами команды разработки. Поэтому ответы на пользовательские инциденты были шаблонные, а часть запросов обработать и вовсе не получалось. По логам, которые тогда генерировали сервисы, невозможно было проследить цепочку действий пользователя, которая приводила к ошибке. Поэтому в ряде случаев было трудно анализировать пользовательские кейсы.
Таким образом, на этапе развития наш проект столкнулся со следующими трудностями:
На проекте не хватало понимания, как именно пользователи и интеграторы используют наши сервисы.
Из-за проблемы выше мы не могли оказывать качественную пользовательскую поддержку.
Не было инструмента, чтобы отслеживать действия пользователей и мониторить операционную деятельность сервисов, собирать статистику.
Не было отдельного специалиста, который мог бы полноценно оказывать поддержку.
Со временем в команде появился специалист технической поддержки, а остальные проблемы помог решить новый подход к логированию и сопутствующие инструменты.
Что такое бизнес-логи и чем они отличаются от системных
Под бизнес-логами мы подразумеваем адаптированные аудит-логи. Использование аудит-логов — распространенная практика для анализа кейсов, связанных с информационной безопасностью. Мы позаимствовали эту технику и адаптировали ее под наши бизнес-процессы.
На нашем проекте используется два вида логов: бизнес-логи и системные.
Системные логи нужны прежде всего для анализа состояния системы. Например, с их помощью мы можем узнать, что в базе данных произошла ошибка, или отследить отказы сервиса.
Бизнес-логи помогают анализировать бизнес-события — действия
пользователя или самой системы, которые не являются системной ошибкой, но все
равно представляют для нас интерес. В них можно посмотреть предысторию и
подробности об инциденте. К примеру, бизнес-логи помогают узнать, почему
появляется ошибка при регистрации нового пользователя.
Чтобы читать такие логи, не нужно лезть под капот самой системы. Их можно понять, не углубляясь в документацию.
Системные и бизнес-события отличаются по структуре и предназначены для решения разных задач, поэтому мы разделяем логи каждого микросервиса на два отдельных индекса: бизнес-индекс и системный. Индексация проходит в Elastic.
Какие задачи решает бизнес-логирование
Если говорить в общем, то бизнес-логирование решает следующие задачи:
Быстрый разбор инцидентов и запросов на обслуживание.
Построение мониторинга с триггерами.
Накопление статистики и создание метрик для анализа.
Чтобы понять, каким образом мы это делаем с помощью бизнес-логов, рассмотрим структуру бизнес-событий на нашем проекте.
В бизнес-логах наших микросервисов у каждого события есть поле event_type — по его значению можно понять, какое именно событие произошло.
У каждого типа события задан определенный набор данных, которые попадают в логи, они передаются в поля с приставкой event_context.
Также в логи записывается время, когда было выполнено действие, среда, хост и прочая информация.
События, подлежащие логированию, и структура их контекстов выносится на уровень требований в процессе разработки сервиса. Важно описать и задокументировать, что именно мы хотим получить.
Теперь рассмотрим конкретные примеры задач, которые мы решаем бизнес-логированием.
Разбор инцидентов
Представим ситуацию: пользователь обратился с жалобой, что мы систематически не возвращаем списанные баллы на отправления, которые он отменил.
В бизнес-индексе бонусной программы можно воспроизвести всю цепочку действий пользователя, выставив фильтр на его идентификатор — бонусный счет. При такой фильтрации мы также увидим все автоматические события, которые происходили со счетом пользователя, в том числе возвраты.
На картинке ниже в Kibana по идентификатору пользователя выстроена цепочка его списаний и начислений. С помощью встроенных инструментов можно отфильтровать данные по конкретному пользователю и настроить контекстные поля таким образом, чтобы их было удобно анализировать. В бонусный бизнес-индекс в контекст записывается баланс пользователя в момент проведения транзакции и сумма начисления или списания.
Составив цепочку списаний, начислений и возвратов, можно быстро дать обратную связь пользователю. Достаточно выгрузить все операции по бонусному счету из Kibana и посчитать сальдо баланса за проблемный период.
Запросы на обслуживание
Запросы на обслуживание со стороны бизнес-заказчика решаются при помощи тех же инструментов, что и инциденты. Но дополнительно может понадобиться визуализация, так как часто запросы требуют расчета тех или иных метрик.
Рассмотрим пример. Найдем топ-10 пользователей, которые сделали больше всего предоплаченных отправлений за ноябрь. Будем использовать инструмент визуализации в Kibana. На скриншоте — табличная визуализация логов нашего бонусного сервиса.
Благодаря контексту, который логируется при завершении бонусной транзакции, мы нашли бонусные счета самых активных клиентов Почты России. Некоторые из них оформили более 2 тысяч предоплаченных отправлений за месяц.
Дополнительный мониторинг
Следующая задача, которую мы решаем с помощью бизнес-логов, — это дополнение системы мониторинга.
Такой мониторинг идет плюсом к системному, потому что системные логи все равно играют значимую роль в реагировании, но некоторые тонкости в них уловить нельзя. Например, когда со стороны системы в целом все ок, показатели в порядке, но бизнес-процесс не выполняется.
Для анализа таких кейсов нужна понятная визуализация и триггеры, основанные на бизнес-логах. В этом нам помогает Grafana.
Например, на скриншоте ниже мы замеряем процент успешно использованных кодов подтверждения, которые направили пользователям. Если показатель падает, это значит, что коды подтверждения не приходят.
Уже не раз при срабатывании триггера на этих графиках мы выявляли проблему как на стороне провайдера сервиса рассылки кодов, так и в самом сервисе. При этом системные метрики были в норме. В подобных случаях мы можем вебхуком информировать мониторинговые системы Почты о том, что есть проблема.
Пара слов о том, как настроить такую визуализацию.
Реализация заключается в написании запроса в Elastic с нужными параметрами. Запрос из Grafana можно скопировать в Kibana и наоборот — это очень удобно.
После обновления Grafana до версии 8.2 у нас появилась возможность делать математические выражения из запросов, например делить результат одного запроса на результат другого или что-то более сложное. Именно так реализован расчет процента подтверждений — мы находим отношение использованных кодов подтверждения к высланным.
Также поток высланных и подтвержденных кодов можно визуализировать в виде гистограммы и навесить триггер на достижение того или иного потока критического значения.
Сбор статистики
Структура бизнес-логов позволяет, например, считать уникальных пользователей тех или иных услуг по дням (DAU) или месяцам (MAU), так как в контекст событий мы логируем идентификаторы пользователей. Визуализируем DAU или MAU мы в Grafana, настраивая счетчик на уникальные идентификаторы пользователя.
Но что если хочется посмотреть уникальных пользователей в разрезе полгода или года? При этом хранить логи больше 90 дней затратно, так как они занимают место.
Для таких задач мы используем встроенный в Kibana инструмент, который называется ролл-ап.
Ролл-ап — это периодическая задача, которая агрегирует данные из индекса, перерабатывает их и сохраняет в новый индекс.
То есть ролл-ап позволяет сгруппировать значения поля за определенный промежуток времени так, как это сделала бы функция group by в SQL, и записать результат в отдельный индекс. Ролл-апы мало весят и не имеют ограничений по сроку хранения.
Например, у нас была задача хранить данные по уникальным пользователям одной из наших услуг. Для этого мы группировали данные из индекса микросервиса по полю event_type и идентификатору пользователя.
Ролл-ап запускается раз в 24 часа, схлопывает идентификаторы пользователей, которые встречаются более одного раза, и записывает схлопнутые данные в отдельный индекс.
После запуска ролл-апа мы настроили статистическую визуализацию в Grafana.
Сейчас прошло полтора года после настройки, а индекс, в который ролл записывает значения, занимает 130 Гб. По меркам логов, это мало — некоторые сервисы столько записывают в день.
В таблице ниже — сравнение, сколько места занимает ролл-ап и индекс, из которого он берет данные.
Срок | Исходный индекс (горячее хранение) | Ролл-ап |
День | 7,53 Гб | 240 Мб |
Месяц | 225,9 Гб | 7,2 Гб |
Год | 2,65 Тб | 86,4 Гб |
Наш опыт внедрения и выводы
Результаты внедрения
Нам потребовалось всего несколько часов для того, чтобы перейти к такому логированию. Но у нас были детально прописаны все бизнес-процессы и подготовлена техническая документация: списки событий и желаемый контекст.
В итоге удалось решить проблемы, которые я обозначил в начале своего повествования:
Теперь мы лучше понимаем, как функционирует система в ее операционной части.
Можем мониторить состояние бизнес-процессов, строить воронки использования услуг, собирать статистику и фиксировать отклонение показателей.
Предоставляем качественную поддержку пользователям.
В среднем мы обрабатываем 800 обращений в месяц. С этим справляется один специалист поддержки. CSI, рассчитанный по обратной связи пользователей после решения инцидента, составляет 4,56 из 5.
Таким образом, мы следуем за общим трендом — обеспечиваем observability («наблюдаемость») системы. Мы настроили аудит процессов, мониторинг и алертинг. В дальнейшем планируем сделать распределенную трассировку.
А еще мы решили тиражировать этот подход: новые сервисы и фичи нашего проекта уже запускаются с бизнес-логами. Но не всем это подойдет — бизнес-логирование требует от проекта и самой команды определенной зрелости. Нужно глубоко проработать документацию проекта и детально описать бизнес-процесс. Заручиться поддержкой разработчиков — именно они будут помогать запускать и настраивать мониторинг. Ну и прокачать самих специалистов саппорта — они должны иметь навыки работы с Elasticsearch.
Плюсы и минусы бизнес-логирования
Почему бизнес-логирование — это удобно?
За счет большой детализации события можно собирать контексты в показатели и следить за их динамикой.
Помогает качественно анализировать обращения и в ряде случаев может заменить остальные инструменты анализа.
Выстраивает полноценный мониторинг, который опирается не только на показатели системы, но и на бизнес-логику.
Позволяет создавать статистические метрики.
Из недостатков можно выделить вот что:
У логов короткий срок жизни. Максимум на нашем проекте — 90 дней, после чего наступает холодное хранение на срок около года.
Технические неполадки с Elastic. Если он падает, весь алертинг перестает работать (но это, скорее, исключение из правил — если что, мы обращаемся к Prometheus).
Актуальность бизнес-логов нужно поддерживать — для этого важно вести документацию и периодически проводить ревью логов. При чрезмерном логировании индексы могут занимать много места.
Стандартными инструментами Kibana нельзя выгрузить из Elastic больше 10 тысяч строк, но это решается скриптом и обращением напрямую к Elastic.
