Сейчас мои кластеры живут на zabbix. Перестало хватать в последнее время отображения информации, стал думать о поднятии Graphana. И возник вопрос о Prometheus.
Посмотрел. Prometheus вроде меньше ест ресурсов:
Zabbix Agent:
Memory: ~10-20MB RAM
CPU: 0.1-1% (depends on checks frequency)
Active checks create constant connection to server
Runs more processes for data collection
More intensive for disk I/O due to frequent checks
Windows Exporter (Prometheus):
Memory: ~5-15MB RAM
CPU: 0.1-0.5% (typically lower than Zabbix)
No persistent connections (pull model)
Single process for metrics exposure
Less disk I/O impact
Metrics are collected only when scraped
Мне думается, что ничего лучше netdata, нету в 2025м. Grafana нужна если нужны специальные графики, а скорее тебе или какому-то другому человеку просто удобно именно там их создавать
У netdata были проблемы, что до какого-то времени это был только мониторинг в реальном времени, но с cloud решением это решено из коробки, без необходимости связывания netdata, например с той же Grafana (я в свое время использовал связку netdata, InfluxDB, Grafana, когда netdata cloud еще не существовало)
ЕМНИП, можно натравить графану на метрики из заббикса.
Но честно, скажу как действующий админ Unix – это мне не кажется проблемой.
Вот чего мне не хватает в стандартном Zabbix, так это детального попроцессового мониторинга потребления RAM, CPU, IO, чтобы можно было сказать «ага, вот именно эти процессы этого ПО виноваты».
Удивлён, что заббиксом ещё пользуются. В наших облачно-кубернетесовых эмпиреях уже давно прометей вытеснил всех тотально, ничего другого не осталось. Всё-таки IT — довольно большая штука.
Да всплывают решения 10-15-20 лет без присмотра… И самое интересное, что сделаны умными людьми, да вот совсем на них болт клали, теперь надо усилия прилагать.
Мне тут девопс воткнул прометея на PostgreSQL. Несовместим с 17й версией. Ну, как «несовместим», запросы шлёт, которые в 17м ПГ не работают. Да и остальные запросы какие-то мутные и не обязательные, на мой взгляд.
Не бегать же к девопсу за каждым чихом с просьбами перенастроить Прометей.
В итоге - уговорил девопса отцепить прометей совсем от моего ПГ. Сам вручную наваял процедур с нужными мне данными и рисую их в Графане прямиком из БД.
В итоге - уговорил девопса отцепить прометей совсем от моего ПГ. Сам вручную наваял процедур с нужными мне данными и рисую их в Графане прямиком из БД.
Хмм, странный опыт. Я то мониторю psql, mssql, mysql, redis…
кек, чёт ты не туда свернул. Меня конкретно интересует шыло-на-мыло. Zabbix с Graphana или вообще за квартал перекатить на альтернативы. Вот и собираю истории, кто чем и куда.
Довольно странно. По идее, связка стандартная, должно работать.
вручную наваял процедур с нужными мне данными и рисую их в Графане прямиком из БД.
Если вас устраивает, то и замечательно. Но возможно, вам будет удобнее реализовать свой prometheus exporter. Это элементарно делается, а если все данные в прометее, то и тревоги с уведомлениями будут там же.
Там ещё какие-то запросы смущали. Из серии «скажи мне, девопс, зачем твой Прометей мониторит то, что у меня в ПГ даже не включено?».
Но да, я осознаю, что я не в струе. Мне б по-старинке - дали бы машинок под БД. Без этих ваших Куберов-облаков-девопсов. Я б сам с этим БД-хозяйством разбирался, как мне удобно. Но не дадут точно.
Мне б по-старинке - дали бы машинок под БД. Без этих ваших Куберов-облаков-девопсов.
Если есть инфраструктура, значит за ней нужно приглядывать, причём если инфраструктура большая, то нужны всякие замороченные правила, если упал dev, то и хрен бы с ним, а если stage, то орать, а prod — так орать как резаный днём и будить дежурного инженера ночью, но про заваленный backup ночью орать не надо, подождёт до утра. И тут очень легко развести такой бардак, что сам не разберёшься. Поэтому имеет смысл ввести единообразыне правила и им следовать: в нашем случае, все метрики в прометее, все тревоги в alertmanager’е, все оповещения в opsgenie (не помню почему там, должно быть корпоративная политика).
Спасибо, комментарий со ссылкой уже позже увидел ниже. Просто сначала испугался, что обратную совместимость похерили где-то значительно.
14->17 это вы смело.
У меня там практически только чтение, данных немного (не больше 1 Тб). Разверну рядом со старой версией 17, перелью данные (не решил пока, как проще сделать), потом переключу и все. Не хайлоад же с кучей данных, переживать не о чем.
Не лень. Только не могу советовать, далеко не Гуру.
Лично я в восторге от логической репликации. Из 14 в 17 чудненько переливаются данные (вот прям сейчас у меня). Но не уверен, что это оптимальный вариант для вас.
В теории если у вас просто таблицы и сама схема развернётся без ошибок, то дальше уже всё просто через wal_level=logical.
Те приключения, какие мне попадались в переходах между версиями, касались процедур/функций и шибко хитрых запросов в них. То самописные агрегатки разваливаются, то внезапно перестают работать подзапросы и надо переписывать на LEFT JOIN LATERAL.
Было большое приключение, когда ПГ поменял поведение по умолчанию для jit.
С голыми таблицами, возможно, и 14 на 17 переедет спокойно.
может кто и продаёт из музея , но с учетом цены и сложности доставки, лучше купить на органических светодиодах
только если очень чувствительные глаза и фанат последних плазм панасоника, можно помониторить объявления, с малым пробегом редкость, на прошлой неделе была 3к часов за 150к рублей
ВСЕ относительно! Вселенская истина между прочим.
Для него она новая, и пустяк, что для когото она старая. Для этого когото она новая, а для тех инженегров запустивших первый прототип плазмы она в неведомом прошлом, эта «новая» уже старая. ГДЕ тот новый первый прототип, я спрашиваю!? То то и оно, он уже тоже старый. Ну, после второго включения для диррехтара.
PS: Со СНГ!
PPS: Л - логика.
PPPS: Прошу простить за не трезвый образ, но не пригашенные ассоциации думаю еще менее легки для восприятия.
PPPPS: Еще раз, со Старым Новым Годом! (ц Штирлиц)