Или "Один SA в поле воин"...шутка-юмор. Хотя в каждой шутке есть только доля шутки. Текущий контекст (один аналитик, MVP) позволяет временно использовать Grafana как "костыль". Как только метрики или команда вырастут, надеюсь, перейдём на специализированные BI-инструменты. Спасибо :)
Добрый день! Вы как раз вовремя) Согласна на 100%, что Grafana — не идеальный инструмент для чисто бизнес-аналитики. Ваш пример про "полнолуние и Меркурий" — это классика жанра 😄 Почему в нашем случае всё же пошли этим путём:
У нас метрики технические и бизнес переплетены, а Grafana дала возможность видеть корреляции без переключения между системами.
Для некоторых сценариев (особенно в регулируемых средах) даже read-only реплика БД — это дополнительные согласования и задержки. Ваш совет про BI-системы — шикарен для большинства проектов) Конечно, можно было расширить статью и рассказать про ограничения Grafana. Возьму на заметку Ваш коммент на будущее 😊
Добрый день! Зрите в корень :) Для базовой веб- и мобильной аналитики инструменты вроде Яндекс.Метрики, GA или Amplitude будут удобнее. В нашем случае выбор Grafana + Prometheus обусловлен рядом причин: Во-первых, нужно было собирать и агрегировать метрики не только стандартные (DAU/MAU), но и специфические, с возможностью глубокой кастомизации. Во-вторых, в некоторых сценариях (наш случай – регулируемая отрасль) важно иметь полный контроль над данными, включая их хранение и передачу. Про SQL и логи — согласна, для анализа отклонений это часто удобнее. У нас тоже часть метрик дублируется в БД. Grafana в данном случае выступает как единая точка входа для разных команд (не только аналитиков). Всё классно подметили, спасибо) Для многих проектов действительно нет смысла усложнять, но у нас альтернативы были менее подходящими.
Доброго дня! Спасибо за уточнения! Вы абсолютно правы в нескольких моментах:
Actuator – действительно, это Spring Boot Actuator, который мы используем для экспорта метрик. В статье я опустила это уточнение, но стоило явно указать.
Про кнопку "Add to dashboard" в Explore – отличное замечание! Действительно, в новых версиях Grafana (начиная с ~9.4) этот workflow стал удобнее. В статье описан универсальный способ, но Ваш вариант определённо лаконичнее.
Насчёт сортировки и версий Grafana – Вы совершенно правильно подметили, что проблема не в Grafana, а в понимании разницы между instant и range queries. Мой пример был дан в контексте instant-запроса (что подразумевалось по умолчанию), но стоило явно это обозначить, чтобы избежать путаницы.
Благодарю за интерес к статье и ценные замечания – они помогают сделать материал точнее!
Да здесь целый курс по диаграммам последовательности))
Из онлайн-инструментов проектирования (на минималках) прекрасен еще https://sequencediagram.org/
Хочется ответить: "А кому сейчас легко?" :)
Или "Один SA в поле воин"...шутка-юмор. Хотя в каждой шутке есть только доля шутки.
Текущий контекст (один аналитик, MVP) позволяет временно использовать Grafana как "костыль". Как только метрики или команда вырастут, надеюсь, перейдём на специализированные BI-инструменты. Спасибо :)
Добрый день! Вы как раз вовремя) Согласна на 100%, что Grafana — не идеальный инструмент для чисто бизнес-аналитики. Ваш пример про "полнолуние и Меркурий" — это классика жанра 😄 Почему в нашем случае всё же пошли этим путём:
У нас метрики технические и бизнес переплетены, а Grafana дала возможность видеть корреляции без переключения между системами.
Для некоторых сценариев (особенно в регулируемых средах) даже read-only реплика БД — это дополнительные согласования и задержки.
Ваш совет про BI-системы — шикарен для большинства проектов) Конечно, можно было расширить статью и рассказать про ограничения Grafana. Возьму на заметку Ваш коммент на будущее 😊
Добрый день!
Зрите в корень :) Для базовой веб- и мобильной аналитики инструменты вроде Яндекс.Метрики, GA или Amplitude будут удобнее.
В нашем случае выбор Grafana + Prometheus обусловлен рядом причин:
Во-первых, нужно было собирать и агрегировать метрики не только стандартные (DAU/MAU), но и специфические, с возможностью глубокой кастомизации.
Во-вторых, в некоторых сценариях (наш случай – регулируемая отрасль) важно иметь полный контроль над данными, включая их хранение и передачу.
Про SQL и логи — согласна, для анализа отклонений это часто удобнее. У нас тоже часть метрик дублируется в БД. Grafana в данном случае выступает как единая точка входа для разных команд (не только аналитиков).
Всё классно подметили, спасибо) Для многих проектов действительно нет смысла усложнять, но у нас альтернативы были менее подходящими.
Доброго дня!
Спасибо за уточнения! Вы абсолютно правы в нескольких моментах:
Actuator – действительно, это Spring Boot Actuator, который мы используем для экспорта метрик. В статье я опустила это уточнение, но стоило явно указать.
Про кнопку "Add to dashboard" в Explore – отличное замечание! Действительно, в новых версиях Grafana (начиная с ~9.4) этот workflow стал удобнее. В статье описан универсальный способ, но Ваш вариант определённо лаконичнее.
Насчёт сортировки и версий Grafana – Вы совершенно правильно подметили, что проблема не в Grafana, а в понимании разницы между instant и range queries. Мой пример был дан в контексте instant-запроса (что подразумевалось по умолчанию), но стоило явно это обозначить, чтобы избежать путаницы.
Благодарю за интерес к статье и ценные замечания – они помогают сделать материал точнее!