Комментарии 21
Главное — не попасть в системную ошибку выжившего, когда мониторинг не покрыл юзеров, с порога выкинувших поделие, сожравшее четыре гига на полупрозрачные окошки и потребовавшее аккаунта в трёх облачных сервисах…
При этом всё перечисленное на удивление мало кушает
Зависит от того, с какой точки зрения посмотреть. Каждый процесс в отдельности кушает действительно мало, но если просуммировать весь стек мониторинга, то лично у меня набежало под 300 мегабайт занятой оперативки — если у вас мажорская стойка из 128-гиговых дедиков, вы такую мелочь конечно не заметите, но если, например, для пет-проекта брать дешёвый гиговый VPS по акции на сэкономленные с обедов деньги, то эти 300 мегабайт начинают очень сильно ощущаться
Создать /etc/systemd/system/node-exporter.service
Простите, а зачем запускать node-exporter в докере, если он состоит из одного-единственного бинарника, способного запускаться в любой среде, и если вы всё равно ломаете изоляцию контейнера пачкой volume?
Разумеется, запускать node-exporter (равно как и все остальные компоненты) в контейнере вовсе не обязательно. Это лишь пример, иллюстрация одного из вариантов :)
Изоляция процессов в контейнерах осуществляется благодаря двумя механизмами ядра Linux – пространствам имен (namespaces) и контрольным группам (cgroups). Мы частично нарушили изоляцию файловой системы, но остальные пространства все еще работают, как и контрольные группы.
Еще один плюс (возможно очень субъективный) – все программное обеспечение распространяется через образы. Это банально удобно
Стоит иметь в виду, что systemd тоже умеет изоляцию процессов через те же самые namespaces и cgroups, так что использование докера ради изоляции может быть оверкиллом
А учитывая, что задачей node-exporter является мониторинг хоста, а не контейнера - изоляция его в контейнере может сломать часть метрик (я по этой причине специально выключил у себя всю изоляцию, чтобы node-exporter не вопил, что rootfs внезапно read-only бида-бида, и всё в таком духе - я осознаю, что это менее безопасно, но зато метрики более качественные)
Спасибо за важное замечание! Мне остается только добавить, что разработчик действительно не рекомендует запускать node_exporter в контейнере:
The
node_exporteris designed to monitor the host system. It's not recommended to deploy it as a Docker container because it requires access to the host system.
«Во Франции незаконно называть свинью Наполеоном, но меня не остановить» :)
затем же, зачем и устанавливать кучу различных систем мониторинга, а потом их дебажить и искать проблемные места в самом мониторинге =)
А можете объяснить дилетанту, чем внедряют Vicoria Metrics в дополнении к Prometheus? Зачем плодить лишние хранилища? В интернетах пишут что Vicoria Metrics якобы нужна для создания долгосрочного хранилища данных, но почему этого нельзя сделать в Prometheus я так и не уловил
Как минимум благодаря дедубликации данных можно хранить меньшее число точек во временных рядах. Например, Prometheus собирает значения от экспортера каждые 15 секунд и на отрезке последних нескольких недель это оправданно. Однако на глубине в год такая точность уже не требуется – и VictoriaMetrics позволяет хранить только значения за каждые 60 секунд с помощью опции -dedup.minScrapeInterval=60s. Тогда горячие данные можно смотреть от источника данных Prometheus, а холодные – от VM.
Также есть интересная статья Бенчмарк Prometheus vs VictoriaMetrics на метриках node_exporter, которая наглядно сравнивает потребление ресурсов
На практике это может это может выглядеть так (набор экспортеров очень пестрый, от того же node до mongodb и кастомных):
Prometheus – хранение данных 21 день, БД ~90 ГБ
VictoriaMetrics – хранение данных 365 дней, БД ~270 ГБ
Prometheus тоже позволяет хранить только значения за каждые 60 секунд, ровно как и любой другой интервал. Если 15 секунд не требуется вообще никогда — просто поменять scrape_interval: 15s на нужный. Если требуется одновременно хранить разреженные метрики для истории и подробные для оперативного анализа — можно запустить два инстанса прометеуса (если экспортеров много) или просто в prometheus.yml указать две цели с разным интервалом.
Еще рассматриваю связку Prometheus + VictoriaMetrics, для использования экземпляров Prometheus в изолированных сегментах сети, а VictoriaMetrics в тойже что и Grafana источником данных для которой будет VictoriaMetrics. Ну и экономия места подкупает при долгосрочном хранении, на экземплярах Prometheus метрики будут какое то ограниченное количество часов храниться.
Где "основы мониторинга", обещанные в заголовке?
Где сравнение систем мониторинга и обоснование выбора в пользу прометеуса?
Где пример того, как замониторить какую-нибудь программу, тот же nginx, например? Ага, скачайте и поставьте что-то там.
Зачем ставить и запускать сразу три экспортёра, а не ограничиться одним? Или одним экспортёром нельзя собирать все нужные данные?
Статья обрывается на моменте, как мы запустили сервисы графаны и прометеуса.
Лучи ненависти в сторону автора, и минусы в статью и в карму за потраченное время.
Типичный shitops подход - понадёргать отдельных команд и файлов из интернета, получить какую-то херню на выходе с модным интерфейсом и считать себя крутым специалистом.
Основы мониторинга в понимании разных людей должны содержать разную информацию. Необходимость, понятие и краткий обзор существующих систем – вот что является основами по-моему субъективному мнению (которое не обязательно должно совпадать с Вашим)
Статья изначально не подавалась как сравнительная. Различные системы мониторинга перечислены для понимания общей картины. Нет и не может быть универсального обоснования в вакууме в пользу Prometheus (как и в пользу любой другой системы)
Это забавно, но в концепции Prometheus «замониторить какую-нибудь программу» действительно означает развернуть экспортер :) В статье есть упоминание, где подобный экспортер найти, дальше достаточно открыть ReadMe. Можно написать и свой экспортер, что совсем не сложно по официальной документации
Зачем делать репозиторий для каждого проекта, неужели нельзя сложить все в один? Иногда реализовать экспортер, который будет отдавать метрики по разным подсистемам, все же можно и даже разумно, но объединять метрики по хосту, контейнерам и проверке доступности точек входа по tcp/http – странное предложение. Возможно я не понял сарказм :(
Верно. Остается только дополнить, что статья останавливается на минимальном наборе сервисов, которые можно потрогать вживую, и понимании, как дальше разворачивать необходимые экспортеры и добавлять дашборды
Эмоции – двигатель прогресса
Мне больше импонирует термин monkeyops. И все же команды и файлы не понадерганы из Интернета, не стоит настолько упрощать. Крутым специалистом себя не считаю :)
Раз уж взялись за историю, то MRTG был и кактус Cacti.
Странно что не была упомянута netdata...
У себя мы используем для "долгосрочной истории" zabbix, а для среднесрочного и мониторинга в реальном времени используем связку netdata -> netdata-registry -> prometheus <- grafana.
Ну а alertmanager заменяет собственно netdata-registry, которая и занимается рассылкой уведомлений. Да, не такая гибкая как alertmanager, но вполне себе хватает.
Отличная статья! Большое спасибо автору, жаль, что не наткнулся раньше и методом проб и ошибок (офф. документация не очень помогла), в итоге, пришёл к похожему решению, но, по итогу, не осилил написание конфиг-файлов для data sources и дэшбордов, но благодаря вам решение найдено за, что я очень вам благодарен!
Основы мониторинга (обзор Prometheus и Grafana)