Комментарии 29
TLDR:
Часто появляются и исчезают сущности? -- нет --> Zabbix
|
да
|
V
Не Zabbix
Почему нельзя испоьзовать Zabbix с Графаной?
Графана не часть прометеуса и отлично живет без него
Да и с заббиксом прекрасно дружит
Так как целью статьи было сравнить prometheus и zabbix в контексте минимальной работоспособности и Zabbix уже имеет встроенную систему визуализацию дашбордов, в данном примере мы к нему не подключаем Grafana. А так да, подключить можно без проблем.
Так прометеус вроде тоже имеет простенькую систему визуализации дашбордов, в этом плане тогда минимально можно пробовать без графаны вообще?
А в целом, мне прометеус не нравится по трем причинам. Во-первых изначальная архитектура усложнена и не слишком гибка. Точнее гибкость есть, но она обеспечивается сложнее, чем в других мониторинговых системах.
Популярность прометеуса достигнута была в осномном тем, что он из коробки работает с некоторыми популярными наборами метрик, в результате многие просто по инструкции его ставят в виде next-next-completed, но не понимают ни что под капотом ни как оно работает ни как его кастомайзить. А кастомайзить его сложнее, чем другие мониторинговые системы...
К сожалению, мой опыт работы с прометеусом в основном на уровне proof of concept, поэтоум я могу сильно ошибаться, и ищу статьи где наглядно бы подтвердили или опровергли мое мнение.
Комплексно реализованный прометей+графана+алертменеджер на практике оказался более гибким чем заббикс. Можно и заббикс с графаной реализовать, но как будет оно работь с тоной метрик по сравнении с прометеем? Хотя в таких случаях еще лучше будет victoriametrics
А вы посмотрите вместо prometheus на victoriametrics single. Там встроенный ui есть и графики можно свои пихать, и много чего еще умеет. Вот демо https://play.victoriametrics.com/select/0/vmui. По фичам смотрите доку https://docs.victoriametrics.com/single-server-victoriametrics/#prominent-features. Есть еще и кластер - там же в доке и он open source.
.
А почему не заббикс+Виктория-Метрикс?
Графана сверху закрывает вопрос визуализации.
Мудохался собрать конфиг с Fortigate генератором для Grafana , нажал один раз apt-update, все слетело.
А что можете посоветовать для мониторинга небольшого решения: одна БД (postgresql), nginx, и с пяток запущенных процессов (даже не докер)?
Все крутится на дохлой vps с 1Гб оперативке.
Есть какое-то не жрущее и простое решение для мониторинга подобных небольших инсталляций?
Prometheus как раз и подойдет, мониторить службы будет удобно
заббикс, mmonit, sensu, grafana и пару скриптов. Все зависит от того, насколько вы скриптописатель, разработчик и с какой системой работали.
Графана стала практически де-факто визуализатором разных метрик, но она может брать данные из любой базы. Вроде для постгреса бесплатный коннектор даже.
Наполнять данные для графаны надо чем-то, тут разные есть варианты, начиная от банальных шелл/перл/питон скриптов, и вплоть до прямого обращенгия приложения в базу. Мониторинг вообще такое общее слово, что без детализации можно сотни предположений делать
Возможно Вам подойдёт Munin? Достаточно простое клиент-серверное решение; мало жрущее; хранение и визуализация на RRD построена. Я для дома и небольших инсталляций таким пользуюсь лет 15, доволен.
Полезная тема и статья, плюсую.
Технические спецификации и код можно было бы вынести в drop-down чтобы было не так тяжело листать (из оформительского).
но в целом все гуд
Для таких как вы поясню, единственно интуитивно понятный для человека интерфейс - это женская грудь, и при этом всё равно часто случаются сбои. Всему остальному НАДО учиться.
Кратковременное хранение данных
Странное заявление. У prometheus плотность хранения примерно 1-2 байта на семпл. А у zabbix сколько? Сдается мне что значительно хуже.
Касательно downsampling - в некотором роде справедливо. Но так же справедливо считать thanos, где он есть, вариантом prometheus.
Нужно настраивать и администрировать два или больше отдельных компонента (Prometheus и Grafana) плюс Alertmanager
Вы так же упустили максимально близкий к zabbix случай, когда нет alertmanager. А алерты конфигурируются не в коде prometheus, а навозюкиваются мышкой в grafana. Что может быть проще для новичков. Уверен в grafana тоже достаточно много интеграций.
А еще prometheus способен работать в режиме agent mode (и даже в отличии от zabbix докачивать 2 часа метрик после падения связи), и в таком случае не требуются отталкивающее многих в небольших инсталяциях централизованное динамическое SD. Я, например, поступаю именно так. У меня не слишком много инстансов (примерно 200) и они находятся в паре десятков не связанных сетей за NAT. Просто раскладываю с помощью ansible prometheus agent (45Mb RSS) на каждый инстанс и делаю везде одинаковый (за исключением лейблов инстанса) статический конфиг с remote write и docker SD. А там уж какие контейнеры были подняты на хосте - то и "скребется".
То есть Prometheus на инстансах создают изолированные базы метрик и высылают их корневому серверу в http запросах?
Заббикс тоже умеет данные докачивать. Всё зависит от настроек прокси-серверов на площадках. Зададите им большой кеш и время хранения метрик, и они тоже после потери связи м сервером на него данные закинут в том же порядке, в котором их получили. И агент с проксёй точно так же взаимодействует. Итого, Заббикс тоже позволяет не терять данные при потере связи на период до нескольких часов.
.
На мой взгляд есть некоторые моменты с которыми не совсем согласен. (Возможно подсвечу некоторые моменты):
Очепятка в виде - "Graphana".
"Хранение данных: Использует реляционные БД для хранения данных ". Он конечно использует реляционные, но в больших инсталляциях используется преимущественно PostgreSQL + TimescaleDB (Не забывая сделать тюнинг). (https://www.zabbix.com/documentation/6.0/ru/manual/appendix/install/timescaledb)
"Масштабируемость: На больших объемах данных может возникнуть проблема масштабируемости и производительности." Используете распределенную архитектуру, в виде Zabbix Proxy. Тюните под свои нужды и возможности. Как Базу данных, так и сам Proxy + HA. Единственное, это довольно ресурсоемко.
(https://www.zabbix.com/documentation/6.0/ru/manual/concepts/server/ha), это больше к серверам но по сути - отправная точка.
"Кратковременное хранение данных: Преимущественно ориентирован на кратковременное хранение данных, хотя интеграция с внешними хранилищами позволяет решить эту проблему." Берем и используем Prometheus - Federation. (https://prometheus.io/docs/prometheus/latest/federation/)
Так же - Интеграция k8s + Zabbix. Пока сам не оттестировал но вполне не плохое решение. Понятное дело то что Prometheus хорош в мониторинге k8s, но и Zabbix от него не отстает.
(https://blog.zabbix.com/monitoring-kubernetes-with-zabbix/25055/)
Публикации
Zabbix vs Prometheus. Что выбрать для гетерогенной инфраструктуры?