Мониторинг в 2025?

Если твои первые вопросы о «как мониторить винду/хост», то Прометей тебе не нужен.

Спасибо за ответ.

Сейчас мои кластеры живут на 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

firkax, и? У меня сотни vm, где есть и windows сервера.

Короче, накину Graphana поверх Zabbix, а дальше посмотрим.

И что?

Ставить go-хлам вместо нормального мониторинга из-за этого?

А что порекомендуешь? Я так ELK да Zabbix использую… Но сейчас что-то не хватает.

Чего именно не хватает то?

На плазму хочется вывести нормальную метрику, чтобы видеть общую картину. У Zabbix с этим (особенно на lts, да не самой свежей) - беда.

НУ и некие самописные правила мне не нравятся.

На плазму хочется вывести нормальную метрику

Плазма выгорит от статичной картинки!

НУ и некие самописные правила мне не нравятся.

Тогда страдай. Ты хочешь скачать нечто из инета и просто запустить, из этого никогда ничего хорошего не получается.

Сперва определись, чего именно тебе не хватает, потом ищи инструменты.

Ты хочешь скачать нечто из инета и просто запустить

Странное определение моих скриптов по получении метрики (bash, pwshell)

Сперва определись, чего именно тебе не хватает, потом ищи инструменты.

Vsevolod-linuxoid

Ищу, мне dashboards в Zabbix не нравятся, куцые.

Куплю новую ))

Куплю новую ))

Практически невозможно купить новую, их перестали делать лет 10 назад )

Мне думается, что ничего лучше netdata, нету в 2025м. Grafana нужна если нужны специальные графики, а скорее тебе или какому-то другому человеку просто удобно именно там их создавать

https://grafana.com/grafana/plugins/netdatacloud-netdata-datasource

У netdata были проблемы, что до какого-то времени это был только мониторинг в реальном времени, но с cloud решением это решено из коробки, без необходимости связывания netdata, например с той же Grafana (я в свое время использовал связку netdata, InfluxDB, Grafana, когда netdata cloud еще не существовало)

ЕМНИП, можно натравить графану на метрики из заббикса.

Но честно, скажу как действующий админ Unix – это мне не кажется проблемой.

Вот чего мне не хватает в стандартном Zabbix, так это детального попроцессового мониторинга потребления RAM, CPU, IO, чтобы можно было сказать «ага, вот именно эти процессы этого ПО виноваты».

ДА там один плагин докидываешь и всё, по началу.

И мне. Графики без процентов, ugly mode…

Спасибо, почитаю о netdata.

Поделитесь опытом перехода с Zabbix

Зачем?

Удивлён, что заббиксом ещё пользуются. В наших облачно-кубернетесовых эмпиреях уже давно прометей вытеснил всех тотально, ничего другого не осталось. Всё-таки IT — довольно большая штука.

Да всплывают решения 10-15-20 лет без присмотра… И самое интересное, что сделаны умными людьми, да вот совсем на них болт клали, теперь надо усилия прилагать.

уже давно прометей вытеснил всех тотально,

Мне тут девопс воткнул прометея на PostgreSQL. Несовместим с 17й версией. Ну, как «несовместим», запросы шлёт, которые в 17м ПГ не работают. Да и остальные запросы какие-то мутные и не обязательные, на мой взгляд.

Не бегать же к девопсу за каждым чихом с просьбами перенастроить Прометей.

В итоге - уговорил девопса отцепить прометей совсем от моего ПГ. Сам вручную наваял процедур с нужными мне данными и рисую их в Графане прямиком из БД.

В итоге - уговорил девопса отцепить прометей совсем от моего ПГ. Сам вручную наваял процедур с нужными мне данными и рисую их в Графане прямиком из БД.

Хмм, странный опыт. Я то мониторю psql, mssql, mysql, redis…

И у меня тоже есть саморисные скрипты на Zabbix.

Тогда лей elk в clickhouse, а из него смотри powerbi. (Какой вопрос, такой ответ)

кек, чёт ты не туда свернул. Меня конкретно интересует шыло-на-мыло. Zabbix с Graphana или вообще за квартал перекатить на альтернативы. Вот и собираю истории, кто чем и куда.

Довольно странно. По идее, связка стандартная, должно работать.

вручную наваял процедур с нужными мне данными и рисую их в Графане прямиком из БД.

Если вас устраивает, то и замечательно. Но возможно, вам будет удобнее реализовать свой prometheus exporter. Это элементарно делается, а если все данные в прометее, то и тревоги с уведомлениями будут там же.

Похоже уже починили: https://github.com/prometheus-community/postgres_exporter/issues/1060

Осенью история была.

Там ещё какие-то запросы смущали. Из серии «скажи мне, девопс, зачем твой Прометей мониторит то, что у меня в ПГ даже не включено?».

Но да, я осознаю, что я не в струе. Мне б по-старинке - дали бы машинок под БД. Без этих ваших Куберов-облаков-девопсов. Я б сам с этим БД-хозяйством разбирался, как мне удобно. Но не дадут точно.

Мне б по-старинке - дали бы машинок под БД. Без этих ваших Куберов-облаков-девопсов.

Если есть инфраструктура, значит за ней нужно приглядывать, причём если инфраструктура большая, то нужны всякие замороченные правила, если упал dev, то и хрен бы с ним, а если stage, то орать, а prod — так орать как резаный днём и будить дежурного инженера ночью, но про заваленный backup ночью орать не надо, подождёт до утра. И тут очень легко развести такой бардак, что сам не разберёшься. Поэтому имеет смысл ввести единообразыне правила и им следовать: в нашем случае, все метрики в прометее, все тревоги в alertmanager’е, все оповещения в opsgenie (не помню почему там, должно быть корпоративная политика).

И тут очень легко развести такой бардак, что сам не разберёшься.

И это правда. А потом, если что-то не так, привыкают к крикам и игнорят вопли дежурные инжонеры )))

запросы шлёт, которые в 17м ПГ не работают.

Которые работали в предыдущих версиях постгрес? Что за запросы такие, можно подробнее? А то хочу 14->17 как раз.

Так выше же ссылка есть на issue.

Там ERROR: column "checkpoints_timed" does not exist at character 10 В 17м это поле переехало в другую таблицу.

14->17 это вы смело.

Впрочем, если вы тоже используете ПГ в качестве «хранилки таблиц», как сейчас принято кругом - может и не страшно.

ГитЛаб вон до сих пор почему-то на 14м сидит по умолчанию. Как раз вот ковыряюсь в их докере, пытаюсь понять зачем им обязательно 14й там.

Спасибо, комментарий со ссылкой уже позже увидел ниже. Просто сначала испугался, что обратную совместимость похерили где-то значительно.

14->17 это вы смело.

У меня там практически только чтение, данных немного (не больше 1 Тб). Разверну рядом со старой версией 17, перелью данные (не решил пока, как проще сделать), потом переключу и все. Не хайлоад же с кучей данных, переживать не о чем.

Ты хочешь скачать нечто из инета и просто запустить, из этого никогда ничего хорошего не получается.

Получается, если это netdata =)

Ну я просто разработчик BI и всего такого, и с этой стороны смотрю

Укусил)) но BI тоже разный. По задаче ближе админство и devops.

Получается, если это netdata =)

anonymous_sama Уже почитал, стало совсем интересно развернуть и пробовать.

перелью данные (не решил пока, как проще сделать)

Посоветуй если не лень, как сделать, если обе версии на одном хосте? Просто pg_upgrade или что попроще есть

И вообще начитался сейчас, что надо 14->15->16->17 обновлять. Там так все серьезно, или можно забить?

А то даже макском Технические работы вечером 15-го и 16-го ноября 2022 (комментарий)

Не лень. Только не могу советовать, далеко не Гуру.

Лично я в восторге от логической репликации. Из 14 в 17 чудненько переливаются данные (вот прям сейчас у меня). Но не уверен, что это оптимальный вариант для вас.

В теории если у вас просто таблицы и сама схема развернётся без ошибок, то дальше уже всё просто через wal_level=logical.

Те приключения, какие мне попадались в переходах между версиями, касались процедур/функций и шибко хитрых запросов в них. То самописные агрегатки разваливаются, то внезапно перестают работать подзапросы и надо переписывать на LEFT JOIN LATERAL.

Было большое приключение, когда ПГ поменял поведение по умолчанию для jit.

С голыми таблицами, возможно, и 14 на 17 переедет спокойно.

Но - я вам ничего не советовал )

логической репликации

Это про всякие CREATE SUBSCRIPTION?

Сложно-непонятно (точнее понятно, но лень). В любом случае спасибо.