Меня зовут Маша, я системный аналитик в компании EvApps. Эта статья - пошаговая инструкция для тех аналитиков, кто без скиллов в BI пытается к утру сделать бизнес-метрики в Grafana, имея только доступ к ней. Надеюсь, что гайд поможет быстро настроить дашборд по бизнес-метрикам и найти варианты устранения ошибок, которые возникает в работе начинающего аналитика в данной сфере.
Проект, где я работаю, прошел несколько стадий своего развития, а если говорить с точки зрения кривой Гартнера (Gartner Hype Cycle) – сейчас героически выползаем из пропасти разочарования в сторону склона просветления. Длительная адаптация новых технологий проекта, которые казались внутреннему пользователю слишком сложными, наконец получили принятие и заслуженную реабилитацию. Чтобы отследить момент, когда же мы наконец начнем выходить на плато продуктивности по каждому сервису, решено было мониторить MAU (Monthly Active Users - количество уникальных пользователей, которые взаимодействовали с сервисом в течение месяца), DAU (Daily Active Users - число уникальных пользователей, взаимодействующих с сервисом за один день) и успешные/неуспешные запуски по каждому из модулей проекта.
Спойлер: один из шести сервисов всё-таки оказался категорически невостребованным пользователями. А пара других – начали ставить рекорды по запускам и прилетающим багам.
Гайд по метрикам актуален для тех, кто использует Apache Kafka на проекте. И уже активно внедрена система мониторинга и алертинга Prometeus. В связи с тем, что мои задачи касаются работающего проекта – вопросы непосредственно настройки Prometeus опустим. Советы далее пригодятся тем, кому надо к завтрашнему утру запустить несколько дашбордов, а за окном уже смеркается.
Шаг 1: Ищем метрики для дашборда
Найдем первоисточник метрик – данные actuator Prometeus (actuator/prometeus/). Просим ссылочку на данные актуатора у разработчиков. Все живые и мертвые метрики прячутся как раз здесь. Если выкатили новый сервис с метриками – опять ищем там же. Строчка в актуаторе вида:
metric_mau_task {month=”2025-03”,} 4.0 - поведает нам про 4 уникальных активных пользователей сервиса в марте 2025 года.
Шаг 2: Проверка метрик в Explore
Начинаем танец с бубном в Grafana:
В разделе Explore (в моей версии Grafana – боковая панель слева, значок «Компас») устанавливаем data source, в query вбиваем метрику, запускаем run query – и видим график (путь представлен ниже на рисунках, в том числе и сам график). Делаем вывод, что метрика живая и возможно годится в Dashboard. Если метрика не определилась – листаем ниже к «причинам».
Шаг 3: Нашли и не сдаемся. Создаем дашборд
Если все получилось - перемещаемся в раздел Dashboards, добавляем “New dashboard”, затем делаем “Add new panel”, находим поле с вводом PromQL query и туда добавляем нашу метрику, нажимаем кнопку «Run queries» (еще три картинки ниже в помощь).
Задаем дополнительный параметр запроса, например для отслеживания нужного нам временного промежутка (месяц) (на рисунке выше - это текст внесен в строку query):
sum by (month) (metric_mau_task)
Помним, что у Prom QL свой синтаксис, это не Postgre и не MySQL. Не паникуем, а смотрим какие параметры в актуаторе есть у метрики в скобках рядом, когда изучаем данные актуатора Prometeus, пытаемся по ним выбирать данные.
наводим фэн-шуй по дизайну: в боковой панели справа от графика метрики выбираем среди богатства визуализаций (раздел «visualizations»): time series (по умолчанию), bar chat, stat, gauge, bar gauge (мой любимый), histogram, pie chart и много других (часть перечня визуализаций представлена на рисунке дальше).
придумываем title (приличное и понятное команде название) и description (обычно здесь оставляю оригинальное название метрики, чтоб без редактирования увидеть – какая сломалась при наведении на дашборд в режиме просмотра). Дальше докручиваем стилистику линий, цифр, оттенка цветов там же.
не спешим выходить из режима “Edit” и устанавливаем временной период метрики (список слева от визуализаций). Часто от того, что вы выбрали один месяц – еще не значит, что не появятся данные за несколько лет. Если изначально в метрике в коде не установлена была данная фильтрация, то все возможные периоды будут на вашем дашборде. Вздохнули, сохранили и начинаем копаться в деталях. Недаром там много чего скрывается.
Шаг 4: Бороться, если метрики не работают.
Мы искали и нашли метрики. Почему они не идеальны? Или почему не станут таковыми. Или вообще не работают? У них на это минимум пять причин, как и в песне Николаева. А то и больше.
Шероховатости Grafana, о которых лучше узнать заранее:
1. Проблема: сортировка не всегда работает.
Аналитики обладают широким спектром знаний query language. И Prom QL вроде обещает сортировку. Но в зависимости от версии Grafana – можно бесконечно указывать sort_desc в query, но сортировки не будет. А дашборд будет работать сам по себе. Например, на картинке ниже - сортировка абсолютно никак не преображает дашборд в нужный вид.
Решение: не страдаем с версиями Grafana, помним - у нас нет времени. Самое простое - предупреждаем заинтересованных лиц (в случае особой важности визуала).
Альтернативный вариант: с разработчиками установить ограниченный период отслеживания метрики на уровне кода (1 или 2 последних года, чтоб красиво уместить в рамки дашборда наши показатели). Также исключаем показатели, которые, например, меньше нуля были за период - пишем это в query. Цель оправдывает средства - делаем лаконичный дашборд.
2. Проблема: всех ли пользователей учитывать в метрике?
Решение: исключить админов сервиса заранее. Обычно - значительное количество админских запусков с ошибками как раз будет наши метрики сводить в красную зону. В Grafana с id-шниками не будем мучаться сами, не сработает.Обращаемся к разработке - нам нужно сообщить все id-шники админов, чтоб в коде метрики их исключить. Перезапустит разработка ваш сервис, метрики обновятся с учетом админов. Получим информацию в дашборде теперь только по обычным пользователям.
3. Проблема: как разделить метрики на prom и dev?
Решение: Узнать у разработки, какой лейбл отвечает за dev, какой за prom. Иными словами, когда прописываем метрику в query - указывать лейбл “system”, который может быть равен “dev” или “main” (см. картинку выше). Но может так произойти, что существует только main. Data source (в любом из случаев) у вас будет один и тот же, не поменяется.
4. Проблема: регистрозависимость в query
Решение: возвращаемся к картинке №2 нашего гайда - пишем метрику в query так, как нашли в /actuator/prometeus/. Например, Hbase и HBASE могут отнять еще капельку нервов аналитика.
5. Проблема: разные лейблы - разные команды
Сервисы могут быть созданы разными командами. Как итог: даже для указания в query по метрике – в одной метрике количество пользователей будет суммироваться по month, а в другой - по mnth. И это нормально.
Решение: возвращаемся к картинке №2 нашего гайда. Это не опечатка -пишем лейблы метрики так, как нашли в актуаторе Prometeus.
6. Проблема: метрику сломали
Например, изменились статусы запусков (допустим, статусы задач в вашем проекте были цифровые (2,1,0), стали буквенные (END, RUNNING, ERROR).
Решение: Придется проверять каждый релиз. А лучше сделать и на dev метрики, и на prom. Начинать с метрик на dev - если упали они, спрашиваем у разработки, что за лейблы могли поменяться? И проверять все. И переписывать query в Grafana. Методично, но работает.
Да, будут расхождения в структуре метрик – на prom исключаем админов, на dev - нет. Здесь приключения выбирает каждый сам. Но зато можно отследить сразу изменения на dev, чтоб оперативно восстановить работоспособность дашбордов на prom.
И эта музыка будет вечной – невозможно остановиться. Появятся новые статусы запуска задачи, новая платформа для отслеживания – всё будет переделываться.
Самое интересное – расхождения с БД. Были пройдены все тернии, стали видны звезды. Но чертова статистика, собираемая с помощью скриптов из дорогой сердцу БД, имеет расхождения с Grafana. Самое обидное – расхождение на один запуск. Размяли затекшую шею, руки, опять вздохнули и разбираем отдельным блоком.
Шаг 5: Не сдаваться. Устраняем расхождения дашбордов
Итак, у нас есть данные выборки из БД (запускали метрику как скрипт ранее, например в DBeaver). Проблема: выборка из БД и дашборд имеют расхождения.
1. Решение: перезапуск старых скриптов в актуальной БД. Делали выборку по показателям ручками давным-давно. Хранили в эксельке, рисовали презентацию, показывали боссам. А если опять перезапустить скрипт? Внезапно может лихо найтись тот один несчастный запуск. И всё сойдется с Grafana. Просто перезапустить скрипт.
2. Решение: указать всех админов именно в скрипте, чтоб они соответствовали коду по метрике. Когда-то появился новый админ, в скрипте про него благополучно забыли. А сейчас мы снова проверим id-шники админов в скрипте и в метрике. Нашлись.
3. Решение: исключаем лишнее и режущее глаз. Видим на графиках некрасивые NaN на dev, а на prom их нет. Наверно, в таблицах БД dev есть null-поля и фэн-шуй наш нарушен. Поправляем, если режет глаз (задаем фильтр по значениям больше нуля).
А зачем нам метрики и дашборды?
Если статья встретилась вам на этапе обсуждения на проекте – а нужны ли метрики? Давайте разберем все «за» и «против»:
Отслеживание бизнес-метрик по проекту — это необходимый аспект управления и анализа эффективности бизнеса. За счет визуализации метрик в Grafana можно сократить время на выборку показателей эффективности с помощью скриптов.
Польза метрик в Grafana
1. Метрики помогают понять, что работает из сервисов, а что нет, и принимать решения на основе данных. Существует ли необходимость поддерживать тот или иной сервис или настало время его закрыть. На моем проекте один из сервисов попал под закрытие именно по итогам наблюдения за его низкой популярностью у пользователей (хоть и смежная команда, занимавшаяся его разработкой, всеми средствами пыталась его сохранить).
2. Отслеживать прогресс и эффективность инициатив. В кейсе нашего проекта случайным образом был запущен самый простой сервис для пользователей, который по факту, удерживает первенство по посещаемости и популярности уже год. Хотя изначально команде казалось, что это сущая ерунда и есть аналоги конкурентов.
3. Выполним стандарты и требования – наличие метрик станет дополнительным бонусом при соблюдении ISO 9001, ГОСТ Р ИСО 9001-2015:
- стандарт по управлению качеством ISO 9001 подразумевает необходимость мониторинга и измерения процессов для обеспечения их эффективности. Хотя он не требует конкретных бизнес-метрик, он подчеркивает важность данных для улучшения процессов;
- ISO 9001 – стандарт ГОСТ Р ИСО 9001-2015 - также акцентирует внимание на необходимости мониторинга и анализа данных для управления качеством. Кроме того, в зависимости от отрасли проекта - могут существовать специфические стандарты, которые требуют отслеживания определенных метрик. Например, в банковском секторе могут быть требования по мониторингу финансовых показателей.
Сложности внедрения мониторинга бизнес-метрик:
1. Интеграция данных. В первую очередь, разнообразие источников данных. Если данные поступают из разных систем (например, базы данных, API, облачные сервисы), интеграция может быть сложной. Кроме этого, разные источники могут использовать разные форматы, что требует дополнительной обработки данных.
2. Производительность. Если запросы к данным слишком частые или объемные, это может повлиять на производительность как Grafana, так и источников данных. А неправильные или неоптимизированные запросы могут замедлить работу дашбордов.
3. Обеспечение качества данных: это и к вопросу об актуальности - данные могут быть устаревшими, если обновление происходит нерегулярно; и в тему некорректных данных - если данные не собираются или обрабатываются недолжным образом, это может привести к неправильным выводам.
4. Безопасность и доступ тоже может стать краеугольным камнем внедрения. Придется корректно настроить права доступа для пользователей, чтобы защитить конфиденциальные данные.
5. Обучение команды – понимаем, если аналитик за вечер попытается запустить несколько дашбордов, это еще не значит, что все их интерпретируют так, как он задумал. Команде может потребоваться время на изучение Grafana и принципов работы с ней для эффективного мониторинга и выявления именно тех метрик, которые актуальны для проекта.
6. Настройка дашбордов – тот самый процесс, который если появился однажды, будет напоминать о себе регулярно. Отдельная тема это алерты, их в рамках статьи не затрагиваем. А другой вопрос - сложность настройки дашбордов, где непрозрачные требования по информативности и удобству потребуют значительных усилий и времени команды. Неправильный выбор типов графиков или панелей может затруднить восприятие данных. И здесь может быть полезен еще один кейс из моего проекта.
Кейс из реального проекта
Дано: метрики MAU (Monthly Active Users) и DAU (Daily Active Users) для одного сервиса. Как будем визуализировать то, что накоплено месяцами?
Подбор вариантов визуализации: полезные решения
Выбор подходящей визуализации в Grafana зависит от того, какую информацию вы хотите донести и как планируете анализировать данные. Смотрим на требования заказчика и выбираем, что может ему подойти:
1. Показать тренды изменений MAU и DAU во времени – используем линейный график. Преимущества: хорошо визуализирует колебания и позволяет легко увидеть рост или спад активных пользователей.
2. Сравнить MAU и DAU по месяцам или дням – выбираем столбчатую диаграмму. Преимущества: позволяет наглядно сравнивать значения между разными периодами. Можно использовать группировку по месяцам для MAU и по дням для DAU.
3. Показать общий объем активных пользователей с учетом MAU и DAU – создаем площадной график. Преимущества: позволяет визуализировать объемы и изменения, а также может быть полезен для отображения накопительных значений.
4. Представить точные значения MAU и DAU за определенные периоды – берем таблицу. Преимущества: удобно для детального анализа, особенно если нужно показать дополнительные метрики или данные.
5. Визуализировать одновременно MAU и DAU на одном графике – годится комбинированный график. Он позволяет сравнивать два показателя, используя разные типы визуализации (например, линейный график для MAU и столбчатую диаграмму для DAU).
6. Проанализировать долгосрочные тенденции - используем трендовые линии. Точные значения в этом случае не будут смотреться наглядно, но сможем выявить сезонные колебания и долгосрочные изменения в активности пользователей.
Вот такой дашборд может получиться.
Безусловно, с первого раза совпасть с визуализацией и требованиями заказчика будет сложно. И нет предела совершенству. Раз Grafana встретилась аналитику, скорее всего это надолго. Придется сделать инструкцию по использованию дашборда, объяснить команде, что такое MAU и DAU, выслушать все шутки по поводу этих названий.
Помним, что мы сделали большое дело и теперь есть приятный интерактив по работе нашего сервиса для стейкхолдеров. Да, что-то будет ломаться. Добавятся новые метрики и сервисы. Но базу мы уже создали.
