Comments 8
Найдем первоисточник метрик – данные actuator Prometeus (actuator/prometeus/).
Actuator - это какая-то Ваша специфика (погуглил - скорее всего, приложение на Spring Boot).
Если все получилось - перемещаемся в раздел Dashboards, добавляем “New dashboard”, затем делаем “Add new panel”, находим поле с вводом PromQL query и туда добавляем нашу метрику
А можно просто разглядеть кнопочку "Add to dashboard" прямо в разделе "Explore" (в более актуальных версиях сначала кнопочка "Add", потом "Add to dashboard") и избежать лишних кликов и копипасты :)
Но в зависимости от версии Grafana – можно бесконечно указывать sort_desc в query, но сортировки не будет.
А это не из-за версии Grafana (которая тут вообще не при чём, можете без всякой Графаны Прометеусу PromQL-запросы слать), а, почти наверняка, из-за непонимания разницы между instant и range. Есть там такие кнопочки ниже поля для ввода PromQL-запроса...
Доброго дня!
Спасибо за уточнения! Вы абсолютно правы в нескольких моментах:
Actuator – действительно, это Spring Boot Actuator, который мы используем для экспорта метрик. В статье я опустила это уточнение, но стоило явно указать.
Про кнопку "Add to dashboard" в Explore – отличное замечание! Действительно, в новых версиях Grafana (начиная с ~9.4) этот workflow стал удобнее. В статье описан универсальный способ, но Ваш вариант определённо лаконичнее.
Насчёт сортировки и версий Grafana – Вы совершенно правильно подметили, что проблема не в Grafana, а в понимании разницы между instant и range queries. Мой пример был дан в контексте instant-запроса (что подразумевалось по умолчанию), но стоило явно это обозначить, чтобы избежать путаницы.
Благодарю за интерес к статье и ценные замечания – они помогают сделать материал точнее!
Извините, но почему такие метрики бизнеса надо сложно мониторить в графане+прометеусе? Для базовой аналитики (уж типа dau/mau) есть же для веба Яндекс-метрика/ГА, для мобилок appmetrika+firebase? Я бы сказал, что это основа основ для коммерческих приложений. Для закрытых сегментов сети да, надо ставить тогда сервера matomo, тут реально иногда проще в графану запихаться, но во всех остальных случаях все выкаты регулируются именно типовыми стандартными приложухами. Для когорт - amplitude удобнее всего, хотя и GA уже это все позволяет. Для внутренних обработок я вообще предпочитаю логгирующие таблицы в БД класть, потому что дашборды дашбордами, кибана кибаной, а разбор отклонений все равно sql-кой удобнее делать)
Добрый день!
Зрите в корень :) Для базовой веб- и мобильной аналитики инструменты вроде Яндекс.Метрики, GA или Amplitude будут удобнее.
В нашем случае выбор Grafana + Prometheus обусловлен рядом причин:
Во-первых, нужно было собирать и агрегировать метрики не только стандартные (DAU/MAU), но и специфические, с возможностью глубокой кастомизации.
Во-вторых, в некоторых сценариях (наш случай – регулируемая отрасль) важно иметь полный контроль над данными, включая их хранение и передачу.
Про SQL и логи — согласна, для анализа отклонений это часто удобнее. У нас тоже часть метрик дублируется в БД. Grafana в данном случае выступает как единая точка входа для разных команд (не только аналитиков).
Всё классно подметили, спасибо) Для многих проектов действительно нет смысла усложнять, но у нас альтернативы были менее подходящими.
Первое правило построения аналитики на графане - необходимо отказаться от построения аналитики на графане
Графана отлично подходит для отслеживания системных «таймлайн» метрик (нагрузка, кол-во транзакций и пр.) которые в основном смотрят люди, понимающие специфику разработки. Но, стоит только показать эти метрики бизнесу, и вся ваша работа будет перенаправлена на реализацию их бесчисленного множества хотелок. Причем реализация этих хотелок как трудозатратна, так и вредна для разработки.
В конечном итоге вы придете к огромному кол-ву никак не связанных дашбордов, противоречащих и неидеальных метрик и огорченному бизнесу, потому что «как так нельзя посчитать кол-во новых юзеров зашедших к нам в 5-е полнолуние и зарегистрированных в меркурии под юпитером»
Поэтому, что бы избежать всех этих проблем очень советую продавить идею создания реплики продовой БД и развертки специализированных bi систем (для начала подойдут open-source сервисы superset/redash/metabase). Таким образом вы сможете избавить себя от огромного кол-ва будущего гемороя
Добрый день! Вы как раз вовремя) Согласна на 100%, что Grafana — не идеальный инструмент для чисто бизнес-аналитики. Ваш пример про "полнолуние и Меркурий" — это классика жанра 😄 Почему в нашем случае всё же пошли этим путём:
У нас метрики технические и бизнес переплетены, а Grafana дала возможность видеть корреляции без переключения между системами.
Для некоторых сценариев (особенно в регулируемых средах) даже read-only реплика БД — это дополнительные согласования и задержки.
Ваш совет про BI-системы — шикарен для большинства проектов) Конечно, можно было расширить статью и рассказать про ограничения Grafana. Возьму на заметку Ваш коммент на будущее 😊
Иными словами вы пишете в логи лишнее, чего не должно быть в логах, если "даже read-only - требует согласования".
Статья прикольная, но боже упаси делать бизнес метрики на графане, я бы уволился через 3 минуты, как такое чудо увидел.(2 минуты на "офигивание" и 1 минуту на заявление)
Прям интересно узнать число "аналитиков" и время затрачиваемое на построение дашбордов, это:
а) не может работать at scale
b) в компании нет "аналитики" как таковой.
(судя по тому что пост пишет "системный аналитик" - это тот самый случай, "раз ты аналитик - пили дашборды"(c)).
Хочется ответить: "А кому сейчас легко?" :)
Или "Один SA в поле воин"...шутка-юмор. Хотя в каждой шутке есть только доля шутки.
Текущий контекст (один аналитик, MVP) позволяет временно использовать Grafana как "костыль". Как только метрики или команда вырастут, надеюсь, перейдём на специализированные BI-инструменты. Спасибо :)
Гайд по бизнес-метрикам в Grafana для аналитиков: бороться и искать, найти и не сдаваться