netdata 1.8.0

мне напомнило munin

Вебсокеты так и не завезли? Оно клепает HTTP-запросов раза в три больше среднего их количества на всех моих сайтах

Чем он лучше Glances?

Чем он лучше Glances?

Понятия не имею - что это?

что это?

Вот это.

Тут надо спрашивать, чем оно лучше zabbix.

Всё что угодно лучше вашего мышкотыкательного заббикса.

И тут надо спросить, чем оно лучше TICK стека или графаны в связке с TSDB.

Glances, я так понимаю это опять отображается в grafana а в netdata свой интерфейс, надо посмотреть может он будет удобней

Да нетдата это вещь, узнал о ней с приходом на новую работу, тут хоть и зоопарк со всего, типа телеграфов отдельно и в купе с TICK, ELK, aws местирики, карбоны всякие, куча самописного, но нетдату уважают больше всего. Вообще буд-то в другой реальности жил, кроме забикса и мунина то особо ничего и не знал, а тут такой пласт ПО оказываться развился.

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

это что??? бесплатно? и на линуксе?

прям неверится... точно не под макось и \ или за деньги?

смотрится как «сделано людьми для людей», а не как обычно в линуксе привычно уже «ты там сам в сырцах подправь, потому что релиз иначе ни у кого не собирается - ошибку вываливает!» :D

Объясните мне кто-нибудь, как выглядят те люди, которые сидят и неустанно пялятся в мониторы, следят, понимаешь, за графиками?

Меня всегда эта картина мира умиляла донельзя: вот сидит дежурный инженер и пялится в over 9000 графиков. Как только что-то пошло не так - он тут же начинает суетиться, но параллельно одним глазом нет-нет, да и поглядывает на 8999 оставшихся графиков - а вдруг там что-то пойдёт не так?

От любой системы мониторинга нужны всего две вещи:

1) Алертинг, который не засоряет мозги тысячами ненужных сообщений

2) Способность «отматывать историю назад» для разборок с проблемами пост-фактум и последующим «ручным обучением» системы мониторинга

Все эти «ой, блин, смотри какие графики» - это попытка заткнуть менеджменту рот, а нее решить проблему адекватной реакции на аварии и нештатные ситуации.

★ Extensible Anything you can get a number for, can be given to netdata, using its Plugin API (anything can be a netdata plugin, BASH, python, perl, node.js, java, Go, ruby, etc).

you can get a NUMBER for

Закапывайте.

https://www.dynatrace.com/capabilities/root-cause-analysis/ Вот, что действительно нужно 90% современных систем мониторинга, включая и Zabbix.

Все эти алерты по непонятным критериям на основе «автоматически созданных» метрик в бешенных количествах - это какая-то феерическая чушь собачья, для конторок, состоящих из погромистов в количестве 5-ти штук и одного изредка приходящего сисадмина.

Всё это заканчивается тысячей алертов, уходящих в /dev/null и тысячей графиков, из которых штук 5 вывешиваются на мониторы «для антуража».

Ясно, что для менеджмента в основном графики идут.

Но и сравнить гораздо удобнее на графиках, в той же графане.

Например, была проблем с приложением в 15:06. Открываем графики и смотрим, где была утечка - проблемы с сетью, кто-то напложил зомби-процессов или своп пошёл.

Скажи, пожалуйста, в каких 10% систем мониторинга есть определение источника проблем? Интересно. И как это должно выглядеть.

По ссылке система, очень похожая на тот же kapacitor или я не понял.

А определение «root cause» возможна только парсингом логов при проблеме и их интеллектуальная обработка. И то, если логирование нормальное.

«Определение источника» - понятие весьма неопределённое. Но в enterprise системах мониторинга и близких к ним всегда есть агрегация проблем и подавление шума. В этом плане очень удобной «фишкой» является сервисный мониторинг, когда вместо груды алертов ты можешь видеть конкрентный аффект на IT-подсистемы на разных уровнях. Это позволяет сразу понять, насколько критична проблема, на что он влияет, в принципе видеть целостную картину состояния инфраструктуры, а не просто кучу-малу каких-то предупреждений.

Мониторинг IT-сервисов есть в зачаточном виде (реализация отвратительная во всех аспектах) в Zabbix, в приличном - в ZenOSS, в удовлетворительном - Pandora FMS, эталонная по качеству - в HP OpenView. Сервисный мониторинг реализован в NetXMS. Сам не видел, не щупал, но по отзывам - тоже весьма развитый.

Относительно Root Cause в чистом виде - на уровне сетевого оборудования в том же Spectrum отлично реализован подобный функционал.

Собственно, а что в этом трудного-то? Если причинно-следственные взаимосвязи строятся вручную, а не каким-то забубёным машинным обучением, то всё сводится к довольно банальным алгоритмам на графах: проблема исключительно в том, чтобы сделать удобную визуализацию, интерактивный граф, с этим в общем-то только в крупных системах мониторинга типа того же OpenView и Tivoli справились. Например, в ZenOSS вырожденный случай такого дерева весьма примитивен: возможности обсчёта адекватные, а вот визуальщина, интерактивность на «3 с минусом».

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