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

Меня зовут Дмитрий Меситов. Я продуктовый аналитик в ОК, и в этой статье я хочу рассказать о том, зачем нам понадобилась смена стека для мониторинга продуктовых метрик, какие варианты мы рассматривали и какой инструмент выбрали в итоге.

Отправная точка

Изначально основным методом визуализации данных в ОК был Charts — in‑house инструмент с основным методом визуализации Line Chart, поддержкой MS SQL, Clickhouse и Apache Druid.

С его помощью строились дашборды верхнеуровневых метрик по основным сервисам внутри ОК, среди которых сервисы Лента, Игры, Фото, Реклама. По каждому из продуктов список метрик оговаривался с продактами и ответственным аналитиком.

Главными преимуществами Charts была высокая скорость работы и возможность обрабатывать большие объемы данных. Инструмент успешно справлялся с поставленными задачами, но, вместе с тем, имел и ряд недостатков, среди которых:

• ограниченный набор аналитических инструментов — например, отсутствовал внутренний редактор запросов

• небольшая вариативность, которая сводилась к возможности изменения фильтров в уже заготовленных датасетах;

• «громоздкая», кастомная архитектура, которую затруднительно поддерживать и развивать без комьюнити.

Кроме этого, отдельно от Charts, в ОК существовал проект мониторинга продуктовых метрик. Для мониторинга данные ежедневно собирались в Apache Zeppelin из детальных слоев данных и витрин (в зависимости от сложности метрики), а после сбора данных — рассчитывались изменения значений метрик.

Для фиксирования изменения метрик были выбраны заранее заданные пороги (процент изменения метрики между сравниваемыми периодами), при пересечении которых метрика попадала в отчет. Для разных сравниваемых периодов (вчера в сравнении с позавчера, вчера в сравнении с таким же днем прошлой недели, средние значения недели к неделе) подбирались разные пороги. Также учитывалось наличие праздничных дней в рассматриваемые периоды:

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

Критерии поиска и варианты

При выборе альтернативы Charts мы хотели найти инструмент, который будет иметь:

• возможность визуализации необходимых метрик и гибкой настройки дашбордов;

• open‑source‑реализацию, которая исключает зависимость от вендора и позволяет начать работу без больших инвестиций;

• удобство работы и низкий порог входа, чтобы команде не пришлось с нуля получать уникальную экспертизу;

• поддержку различных БД;

• развитое комьюнити, которое в случае необходимости поможет с решением возникающих вопросов.

В качестве вариантов под свои задачи с учетом описанных критериев мы рассматривали несколько инструментов:

• Superset — решение для визуализации данных и создания отчетов. Оно позволяет анализировать данные, создавать диаграммы и графики, а также делиться ими с другими пользователями.

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

• Tableau — платформа для бизнес‑аналитики, которая дает возможность легко анализировать и визуализировать данные. Предлагает широкий спектр инструментов для создания интерактивных дашбордов и графиков, а также интеграции с разными источниками данных.

• Fine BI — платформа для управления данными и бизнес‑анализа. Предоставляет инструменты для обработки больших объемов данных, создания отчетов и дашбордов. Поддерживает интеграцию с разными системами управления данными.

При детальном рассмотрении Grafana не устроила нас с точки зрения удобства интерфейса и настройки, а также оказалась более ориентированной на технический мониторинг по данным, что не совсем подходит под наши задачи.

Tableau не подходил под нашу структуру данных в DWH, что потенциально могло осложнить его интеграцию. Более того, со временем Tableau ушел из России, как продукт — рассматривать далее его не было смысла.

Fine BI подходил по функциональности, но больше ориентирован на локальное хранение и обработку. К тому же, наш объем данных для него был чрезмерным. В итоге от инструмента пришлось отказаться.

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

Переезд и неочевидные сложности

После выбора инструмента и «введения» его в наш ИТ‑ландшафт мы начали перенос мониторинга из Zeppelin в Superset. При этом, как и планировали, в процессе миграции мы практически полностью сохранили структуру мониторинга — внесли лишь небольшие изменения.

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

То есть нам требовался пересмотр формата мониторинга с упором на «сильные» стороны и доработкой недостатков.

В результате, чтобы закрыть эти потребности, мы:

• Пересобрали поиск пороговых значений для алертов. Раньше пороговые значения изменения метрик определялись в процентах, при переходе которых изменение считалось важным. На эти пороговые значения влияло только наличие или отсутствие праздников в сравниваемом периоде. Теперь важные праздники выписываются отдельно. Пороговые значения заменены на алгоритм, динамически определяющий точки сдвига (Probabilistic CUSUM).

• Внедрили новую версию вероятностной вариации алгоритма CUSUM. За основу идеи взяли статью Сарема Сейтца (Sarem Seitz). При этом сделали выбор в пользу самописной реализации в Clickhouse с некоторыми оговорками.

Алгоритм получился достаточно простой, чтобы его можно было реализовать на стороне SQL-запроса над готовыми данными, где он позволяет найти точки разрыва временного ряда.

В нашем конкретном случае алгоритм упрощён — для «прогрева» смотрится недавний и непродолжительный (несколько недель, чтобы не быть подверженным долгосрочной сезонности) период. По сути этим же методом проводится проверка «был ли сдвиг в течение предыдущей недели»?

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

• Отображаем значения и изменения метрик более лаконично. Взяв на основу гайд Ивана Шамаева, мы сделали максимально наглядные и удобные дашборды, по которым можем быстро и прозрачно контролировать продуктовые метрики.

• Написали гайдлайны по оформлению и добавили CSS‑стайлинг с корпоративными цветами и стилем. Для удобства пользования и быстрого ориентирования при переключении между дашбордами, мы выработали единый стиль и формат именования элементов. Подход оправдал себя, поэтому разработанные стиль и нейминг сейчас применяются в большинстве продуктовых дашбордов.

На выходе мы получили новую версию нашего мониторинга в Superset.

Наши результаты

Переезд на Superset мы смогли реализовать довольно «мягко» — без неочевидных проблем и «подводных камней», хоть и не без дополнительных издержек. Вместе с тем, затраченные нами ресурсы и время, дали комплексный профит.

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

• Работа с данными стала проще и продуктивнее. Данные берутся все также из Hadoop, но расчет агрегированных данных идет на мощностях DWH и помещается в Clickhouse. Результаты ежедневного мониторинга отправляются на почту. При этом, помимо статичной версии, на почте теперь отчет доступен и в интерактивном виде — с возможностью выбора даты отчета и платформы.

• Порог входа в мониторинг метрик стал ниже. Superset удобен как менеджерам, так и аналитикам. К тому же он имеет довольно проработанную, подробную документацию. Поэтому на его освоение, при наличии соответствующей экспертизы и опыта работы со схожими решениями, не нужно много времени. Миграция на Superset обычно проходит для специалистов мягко.

• Обновленная система позволила сократить «зоопарк технологий». Преимущества, которые мы получили при переходе на Superset, оказались важны и для других аналитических команд. В итоге они тоже начали мигрировать на Superset со своими дашбордами, что уменьшило «зоопарк технологий» внутри компании.

Что дальше?

Мы не останавливаемся на достигнутом и продолжаем совершенствовать систему мониторинга продуктовых метрик. Так, в перспективе мы планируем ряд доработок.

• Планируем добавить мониторинги по тем продуктам, которых ещё нет в Superset. Это обеспечит полное покрытие мониторингами продуктовых направлений и позволит в формате «единого окна» следить за здоровьем каждого сервиса.

• Хотим внедрить программную генерацию дашбордов. Автоматизация создания дашбордов позволит делать новые и единовременно обновлять старые мониторинги, если такое понадобится, что кратно уменьшит нагрузку на аналитиков.

• Настроим рассылку в том числе и через корпоративный мессенджер. Это повысит удобство потребления и сделает взаимодействие с отчетами ещё проще.

О том, как будет меняться наш подход к мониторингу метрик и как будет трансформироваться работа с Superset — обязательно сообщим в одной из следующих статей.