Комментарии 11
Минус всей этой статьи, что в ней ничего не сказано как это все работает.
Инструкции по дефолтной установке и дефолтной настроке преднастроенных плагинов и сервисов, из которых вообще непонятно какие именно данные как именно и в каком формате попадают. Даже графана дашборд импортируется уже преднастроенная.
В таком виде ну совсем нет смысла в статье - ведь все эти данные прописаны в ридми или документации по установке.
Что же касается мониторинга дженкинса, там наверное было бы полезнее смотреть мониторинг дженкинс ексекьюторов, ведь сетап где дженкинс крутится без агентов и эксекьюторы только на мастере - это прям такой маленький проект, что смысла в установке целых трех служб для мониторинга - отсутствует. Там проще top посмотреть...
Мне не понравилось :(
На практике все либо в k8s с помощью helm разворачивают мониторинг, либо через docker-compose хотя бы. Смысл ставить всё на хост, если есть docker?
Эээ, или можно просто поставить zabbix)))))
Zabbix больше про инфраструктуру, а не микросервисы. Да, с помощью него тоже можно мониторить контейнеры, но с Prometheus+Grafana не сравнится.
Больше да, но: 1) в статье описывается, если честно, мониторинг вообще непонятно чего… то ли CPU, то ли определенной задачи на хосте… 2) в статье описано столько телодвижений, что заббикс установить намного проще даже новичку, и я молчу про конфиженг! 3) в статье описана установка далеко не легковесных продуктов, которые надо еще подружить, в отличие от заббикса 4) да, для контейнера или облака прометеус неплох, но без графаны - это хардкор… 5) после всех манипуляций и пометок, что в статье не все расписано - точно мониторим микросервисы? Или сегодня это микросервис, а завтра это 100500 сенсоров?! 6) по итогу - реклама курсов «иначе без нас не разберетесь»
В статье описан мониторинг с помощью node-exporter, то есть самого хоста, плюс мониторинг веб морды Jenkins. Если эту связку разворачивать через тот же docker-compose, то там никаких лишних телодвижений не будет по сути, кроме установки самого docker и docker-compose. Я про это писал выше, что сомнительно ставить это всё прямо на хост. Ок, забудем про микросервисы. Если сравнивать мониторинг хоста с помощью node-exporter в Prometheus+Grafana и мониторинг хоста в Zabbix, то добавить на мониторинг хост конечно же проще в Zabbix, но в Grafana красивее, нагляднее и удобнее).
Так собственно я об этом и писал… задачу можно решить любыми способами и мониторинг может быть абсолютно любой, ведь важна только прокладка между рулем и сиденьем, а так то хоть «какти» от пыли стряхни и пользуй! Так что на вкус и цвет фломастеры разные, но способ будет хорош тот, в котором не будет потом рекламы: после установки идите на наши курсы))) имхо
По поводу красивее, нагляднее и тем более удобней… короче на ML мне и комфортно и удобно передвигаться хоть на 10 км, хоть на 500, но снег предпочитаю расчищать трактором (мой ровесник) и там нет удобства и комфорта, зато эта боевая лошадка под свои цели и задачи, но вот даже 5 км я на нём на дальняк не поеду)))
Аллегория понятна. Но, когда речь идёт о Jenkins, это говорит о том, что в компании есть CI/CD, а если есть CI/CD, то помимо мониторинга инфраструктуры, скорее всего нужно мониторить и сервисы, и вот тут держать одновременно Zabbix под инфру и Prometheus+Grafana под сервисы, контейнеры и прочее жирновато, хотя и такой подход имеет право на жизнь. Сейчас работаю в компании, где как раз так. Недавно был кейс, на одном из хостов, какой-то контейнер стал съедать много памяти, пошёл в Zabbix, а там куча графиков на несколько страниц, и нет какого-то агрегированного дашборда как в Grafana, мне проще было воткнуть на хост cadvisor в контейнере, чем мучаться с Zabbix).
О да, я вас понимаю и у самого точно такая же песня, где два отдела держат две разные платформы, как раз графана и заббикс и попеременно качели склоняются то в одну, то в другую сторону))
Как мониторить Jenkins с помощью Prometheus, Node exporter и Grafana