Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 17
метрики и логи всегда больдырказадница в каком бы то ни было даже среднем проекте
как бы не хотелось "попроще" но прометей уже давно стандарт с которым проще смирится и поддерживать, чем страдать с самописными костылями
по факту агрегация и показ это уже две разных задачи и с этим можно работать. Например собирать локально викторией, а уже для показа собирать дампами с разными в единую базу или вообще тупо подключать графану сразу напрямую к разным (но лучше таки собирать особенно если локальные ноды "в притык" по выделенным ресурсам)
интересное решение со статусом платформы, сразу подумал о том что бы просто написать одностраничный агрегатор что с прометея берет выборку простым HTTP и уже отдает в json для "статусной" страницы что бы прометей наружу не торчал
и я не увидел у вас в статье то что написано в заголовке - как можно проще без прометея и тд. Особенно учитывая что и в худшие времена прометей и аналоги ставились и запускались очень просто, всегда больше вопрос к ресурсам был
По преимуществу прометея для большинства проектов - согласен, чаще всего добавить один сервис в конфиг и реализовать минимальный /metrics проще.
В статье не ставил честно говоря задачу доказать, что можно проще, скорее, что в конкретных случаях целесообразнее воссоздать сбор метрик вручную - результат уже на оценку читателю.
По поводу определения статуса платформы запросами поверх http, честно хз, напрягать ради этого сеть сомнительно, но как вариант - да, своеобразная прослойка между промой и приложением возможна.
А что мешало прикрутить к Графане тот же SSO, что и у Вашего приложения, и встроить в Вашу админку графановские дашборды? К тому же при наличии прометеусовских метрик пользователи наверняка оценили бы возможность мониторить приложение не только встроенными средствами, но и интегрировав в свой централизованный мониторинг всего остального.
пользователи наверняка оценили бы возможность мониторить приложение не только встроенными средствами
Пользователи - нет, а вот эксплуатация - да :)
Согласен, наличие в продукте метрик для интеграции со своим мониторингом сильно упрощает жизнь.
Обычно очень увлекательно изобретать свои велосипеды вокруг, если это не предусмотрели разработчики.
В общем и целом - ничего. Пару часов за настройкой дашбордов и загораживанием sso порта графаны. Проблема не столько в недостаточности графаны и прометеуса, сколько в разграничении доступов между админами и суммаризации всех собранных метрик под видом статуса всей платформы.
Клиенты/пользователи - преимущественно не технические пользователи, нужны им не столько дашборды, сколько понимание текущего статуса и произошедших за последние 24 часа инцидентов. В комментарии сверху хабровчанин предлагает реализовать то же самое поверх http, добавив по сути агрегирующий слой отдельным сервисом и тягать метрики с прометеуса - как вариант.
В конкретно моём случае проще показалось в целом отказаться от внешнего "склада" метрик и хранить и собирать на стороне основного приложения. Как результат - все те же метрики и диаграммы, что и с графаной и промой + страница статуса платформы для всех клиентов.
Какой вариант выбирать - на усмотрение читателя.
Проблема не столько в недостаточности графаны и прометеуса, сколько в разграничении доступов между админами и суммаризации всех собранных метрик под видом статуса всей платформы.
Так Графана же умеет разграничивать доступ к дашбордам по пользователям. Если я правильно понял задачу - то сделать общий дашборд с агрегацией всего доступным для всех, а дальше на отдельные дашборды уже выдавать права доступа по необходимости.
загораживанием sso порта графаны
А почему порта? У неё поддержка SSO встроенная. Тогда как раз и получится, что те же пользователи, которые в системе, они же и в Графане, и там для них можно использовать встроенные механизмы разграничения доступа.
Про разграничение доступов к конкретным дашбордам в рамках одного сервиса графаны - честно признаюсь, ни разу не слышал или слышал, но подобные трюки требовали дополнительных прослоек - по сути самодельных реализаций. Если есть ссылка на источник - буду благодарен.
Графана не спорю, сама по себе прекрасна. Но это только дашборды, задача была упаковать/встроить метрики и соответствующие им диаграммы в единую админку над всей платформой, включающую тех.поддержку, анализ клиентуры, управление миграциями...
По сему, вместо возни с графаной проще было реализовать все самому, ну и если уже такое дело - зачем хранить метрики вне основного приложения -> отсюда отказ уже от прометеуса.
В итоге единая модель сбора + отображения метрик для админов, так ещё и с определением инцидентов и статусом всей платформы для клиентов.
Про разграничение доступов к конкретным дашбордам в рамках одного сервиса графаны - честно признаюсь, ни разу не слышал или слышал, но подобные трюки требовали дополнительных прослоек - по сути самодельных реализаций. Если есть ссылка на источник - буду благодарен.
Официальная документация же. Ну и в любом дашборде тыкаем Edit -> шестерёнку Options -> Settings -> Permissions. Что-то там только в энтерпрайз-версии доступно, но базовый функционал разграничения доступа по дашбордам я и у себя в опенсорсной инсталляции наблюдаю. Там, кстати, другой вопрос: если ли у Вас свой SaaS, позволяет ли такие фокусы лицензия Графаны...
Это здорово, что вы думаете про мониторинг и метрики сразу.
Но точно ли вам нужно изобретать свое решение? В инфраструктуре больше одного сервера мониторинг в целом не помешает, а уж на масштабе - просто необходим, поэтому рядом с вашей платформой уже что-то будет, она же не единственная система в условной компании.
Те же ошибки HTTP логичнее собирать с балансировщиков, например.
Когда у разных команд есть один инструмент для всех частей и не нужно делать свою - обычно получается лучше.
Поддерживать одновременно два варианта, один из которых больше нигде не может использоваться - будто бы накладно, если вы и так отдаете метрики в принятом индустрией стандарте сейчас.
Прома + графана были оставлены больше как запасной вариант, если что-то пойдет уж совсем не так.
В целом, понимаю вашу позицию по поводу использования стандартизированных инструментов, но по какой-то неведомой мне причине, всегда было желание объединить мониторинг и другие административные функции в рамках одной системы на основе разграничения доступов даже для метрик.
На больших масштабах, да, чаще всего и правда кроме основной платформы рядом будет стоять ещё пару сервисов, контролирующих нагрузку на ядро. Вопрос только в том, что это будут за сервисы.
В статье упоминаю, что в идеале воркеры и хранилище метрик должны быть изолированы от основной платформы. Такой подход с агрегацией метрик своими силами очевидно имеет большой минус в виде отсутствия стандартизации, но с другой стороны дает возможность крутить собранными данным как душе угодно. Хотите страницу статуса - получайте. Хотите репорты при превышении нагрузки - пожалуйста.....список можно продолжать бесконечно
всегда было желание объединить мониторинг и другие административные функции в рамках одной системы
Это может казаться удобным, но при деградации зависимость мониторинга от самой этой системы - это очень слабое место.
Кстати о метриках - в grafana вполне себе есть гибкое управление доступом к дашбордам.
На больших масштабах, да, чаще всего и правда кроме основной платформы рядом будет стоять ещё пару сервисов,
Там будет намного больше, чем "пара" :)
Если вы целитесь и в такой сегмент - лучше сразу предусмотреть типовые потребности эксплуатации и не забывать про это.
Если ваша платформа может отдать свой статус, ещё и с детализацией, вам будут благодарны.
"Психопат на крайней стадии выгорания" – лучший технический архетип года. Но у его подхода есть классика жанра: снимки каждую минуту будут идеальны ровно до первого "а где был алерт, система лежала 40 секунд?". ERP-инциденты уважают ваш интервал polling’а и заканчиваются за 30 секунд до следующего снимка.
Да, сэр, вы правы, алертинг это в целом отдельная тема, хоть и тесно связанная с метриками.
настоящий психопат это каскадные логи когда сначала пишется каждый чих а потом идут "оптимизации" по минута-час-сутки-месяц с бекапами и тд
и психопатом такие люди становятся когда к ним приходят с требованием разобраться что за проблема была месяц назад, как раз тогда когда подробные логи за тот период уже очистились, а дисцилированые ничего не говорят
а алерты это совсем другое пальто. даже в рамках Графаны там можно ежа против шерсти родить в процессе настройки но все равно прошляпить фактическую деградацию. как по мне алерты начинаются уже в самом приложении, а не метриками едиными
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ещё один круг ада: мониторинг ERP без Prometheus, Grafana и выделенного DevOps