кто-то не осилил партиционирование )

Кстати, а в чем заббикс собранные метрики для графиков хранит?

Кстати, а в чем заббикс собранные метрики для графиков хранит?

в SQL

"* у заббикс отвратительно работает ситуация, когда клиент не может получить данные или получает неожиданные значения (например NaN вместо 0). Он тупо банит клиента и это ужасно." я бы сказал так, надо писать скрипты, которые возвращают ожидаемые значения.

обожаю диагнозы по телефону. партицирование, тюнинг базы, тюнинг файловой системы, ssd. Это не панацея

а что панацея?

обожаю диагнозы по телефону. партицирование, тюнинг базы, тюнинг файловой системы, ssd. Это не панацея

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

зачем их обрабатывать, если легко и просто их можно ликвидировать?

отказаться от хранения TSD в SQL.

ШТОА???

ваш скрипт не должен слать говно

я умею тюнить базы :) Я с заббиксом с 1.4 версии

Не, ну пджди, любая мониторилка может ебануться

так вопрос не в том, что заббикс умирает. Как раз если бы он умирал - это было бы более заметно и легко обрабатываемо. Вопрос в том, что он молча скрывает информацию. И нигде кроме сервер-лога инфы не будет просто.

а вот по третьему пункту - у тебя сколько машин?

#zabbix #collectd #prometheus #мониторинг #telegraf #nagios #icinga #grafana Снять всю хуйню - collectd, telegraf, graphite. prometheus, influxdb (там варианты). Никаких бестов нет - там у всех есть свои косяки и плюсы Построить графики почти безалтернативно grafana Выслать алерты - nagios, icinga2, shinken. Обычно сейчас icinga2

золотой комментарий-хауту

сколько админов нужно, чтобы вкрутить ламп.. настроить мониторинг

а вот по третьему пункту - у тебя сколько машин?

А на дашборде что, по твоему, должно быть? Видосики с xvideos?

А на дашборде что, по твоему, должно быть? Видосики с xvideos?

А на дашборде что, по твоему, должно быть? Видосики с xvideos?

ну в Заббиксе так можно :))

ну в Заббиксе так можно :))

только ОЧЕНЬ медленно

только ОЧЕНЬ медленно

php-fpm + кеширование вместо апача пробовали?

php-fpm + кеширование вместо апача пробовали?

Поподробнее в месте php-fpm vs apache можно.

так стандартные вроде методики для php, весь интернет ими завален. fcgi+xcache и по памяти и по отзывчивости сильно лучше апчевого модуля

ну и, можно схитрить на nginx и например кешировать все GET'ы по хешу с fastcgi_cache_lock on; fastcgi_cache_use_stale error timeout updating;

чем это отличается от proxy_cache_use_stale и proxy_cache_lock?

https://toster.ru/q/41934

не, ну а чо: * у заббикс отвратительно работает ситуация, когда клиент не может получить данные или получает неожиданные значения (например NaN вместо 0). Он тупо банит клиента и это ужасно. * клиенты, увы, текут по памяти. Порой приходится их убивать * сервер довольно плохо масштабируется (говорю о 1.6 -> 2.4 - работал только с ними). В первую очередь выжираются диски. Постоянно приходится прикидывать, какие метрики мне прям нужны, а без каких я как-нибудь так проживу * прокси помогают масштабировать, но ломают выполнение задач на ноде. То есть приходится решать, что мне нужнее - масштабирование или выполнение задачи * очень, очень, очень неочевидный и неудобный UI. Кошмарное устройство выражений. Без толстого справочника хрен разберешься

На самом деле видно, что вы им пользовались и пользовались продолжительно, но > у заббикс отвратительно работает ситуация, когда клиент не может получить данные или получает неожиданные значения (например NaN вместо 0). Он тупо банит клиента и это ужасно. Если у айтема тип int, а от агента получен str, этот _конкретный_ айтем просто помечается, как "Not supported" и некоторое время не чекается повторно. Предполагается, что раз айтем вернул белиберду, то чекалка на клиенте сломана/не настроена и не возвращает полезных данных, поэтому часто речекать её избыточно, всё-равно её исправление требует ручного внимания на этом сервере. На самом деле время речека невалидных айтемов регулируется в Administration -> General -> Refresh unsupported items (in sec), по умолчанию 300. Можно сделать сколько угодно. Клиенты "банятся" не за unsupported item, а при unreachable хосте. Раньше было больше условий, при которых хост мог стать unreachable (напр.: слишком высокий параметр таймаута ответа от агента, или таймаут ответа всего по одному айтему). В сегодняшних версиях с этим всё ок. > клиенты, увы, текут по памяти. Порой приходится их убивать Слышал об этом только про виндовые агенты. На версиях выше 2.4.5 я не видел репортов об этом/жалоб с проектов. > сервер довольно плохо масштабируется (говорю о 1.6 -> 2.4 - работал только с ними). В первую очередь выжираются диски. Как уже сказали, партиционирование. Сколько данных по метрикам, столько и сжирается. Больше всего в RDBMS жрут текстовые логи. > Постоянно приходится прикидывать, какие метрики мне прям нужны, а без каких я как-нибудь так проживу Это нормально для любого мониторинга. Задаётся, что нужно мониторить за год, а что лишь оперативно. Можно забить на это, но рост потребляемого объёма неизбежен на любой платформе. > прокси помогают масштабировать, но ломают выполнение задач на ноде. То есть приходится решать, что мне нужнее - масштабирование или выполнение задачи да, жаль, что прокси не умеет remote commands но remote commands плохая практика, но мы это уже обсудили; если задачи типовые, я бы добавлял их в userparameters, а с нынешними средствами всё это можно ещё и автоматизированно раскидывать > очень, очень, очень неочевидный и неудобный UI. Кошмарное устройство выражений. Без толстого справочника хрен разберешься Порог вхождения есть в любую технологию. Спустя время, нынешний уклад в интерфейсе становится интуитивным. Если бы кто придумал, как иначе (лучше) впихнуть все их представления в меню, это бы уже сделали.

>а с нынешними средствами всё это можно ещё и автоматизированно раскидывать имеется в виду что-то встроенное в заббикс? или чиф-паппет-энсибл?

На самом деле видно, что вы им пользовались и пользовались продолжительно, но > у заббикс отвратительно работает ситуация, когда клиент не может получить данные или получает неожиданные значения (например NaN вместо 0). Он тупо банит клиента и это ужасно. Если у айтема тип int, а от агента получен str, этот _конкретный_ айтем просто помечается, как "Not supported" и некоторое время не чекается повторно. Предполагается, что раз айтем вернул белиберду, то чекалка на клиенте сломана/не настроена и не возвращает полезных данных, поэтому часто речекать её избыточно, всё-равно её исправление требует ручного внимания на этом сервере. На самом деле время речека невалидных айтемов регулируется в Administration -> General -> Refresh unsupported items (in sec), по умолчанию 300. Можно сделать сколько угодно. Клиенты "банятся" не за unsupported item, а при unreachable хосте. Раньше было больше условий, при которых хост мог стать unreachable (напр.: слишком высокий параметр таймаута ответа от агента, или таймаут ответа всего по одному айтему). В сегодняшних версиях с этим всё ок. > клиенты, увы, текут по памяти. Порой приходится их убивать Слышал об этом только про виндовые агенты. На версиях выше 2.4.5 я не видел репортов об этом/жалоб с проектов. > сервер довольно плохо масштабируется (говорю о 1.6 -> 2.4 - работал только с ними). В первую очередь выжираются диски. Как уже сказали, партиционирование. Сколько данных по метрикам, столько и сжирается. Больше всего в RDBMS жрут текстовые логи. > Постоянно приходится прикидывать, какие метрики мне прям нужны, а без каких я как-нибудь так проживу Это нормально для любого мониторинга. Задаётся, что нужно мониторить за год, а что лишь оперативно. Можно забить на это, но рост потребляемого объёма неизбежен на любой платформе. > прокси помогают масштабировать, но ломают выполнение задач на ноде. То есть приходится решать, что мне нужнее - масштабирование или выполнение задачи да, жаль, что прокси не умеет remote commands но remote commands плохая практика, но мы это уже обсудили; если задачи типовые, я бы добавлял их в userparameters, а с нынешними средствами всё это можно ещё и автоматизированно раскидывать > очень, очень, очень неочевидный и неудобный UI. Кошмарное устройство выражений. Без толстого справочника хрен разберешься Порог вхождения есть в любую технологию. Спустя время, нынешний уклад в интерфейсе становится интуитивным. Если бы кто придумал, как иначе (лучше) впихнуть все их представления в меню, это бы уже сделали.

ну вот создатели prometeus придумали.

ну вот создатели prometeus придумали.