LINUX.ORG.RU
ФорумAdmin

(Есть ли) система мониторинга, обсчитывающая граф объектов мониторинга?

 , ,


0

6

Знаю, что есть такое в Spectrum и там это довольно удобно реализовано, но в открытых/бесплатных системах мониторинга не встречал.

В самом общем виде нужно следующее:

1) Инструменты, позволяющие тем или иным способом выстраивать объекты мониторинга в связные графы, показывая таким образом зависимости между объектами в различных разрезах ресурсно-сервисной модели

2) Движок системы мониторинга должен быть привязан к графам рессурсно-сервисной модели и способен делать «свёртки» триггеров на основании РСМ. Классический пример: если «упал» маршрутизатор, недоступность сетевого железа за ним не должна порождать миллиард триггеров и лавину всевозможного флуда

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

В очень условно opensource'ном Zabbix'е, например, ресурсно-сервисная модель живёт вообще отдельно от так называемых «карт»/maps - при этом РСМ - это абстрактное дерево, где только листья привязаны хоть к чему-то, вся остальная структура висит в полном вакууме.

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

★★★★★

Последнее исправление: DRVTiny (всего исправлений: 1)

Классический пример: если «упал» маршрутизатор, недоступность сетевого железа за ним не должна порождать миллиард триггеров и лавину всевозможного флуда

В zabbix если падает маршрутизатор то триггеры которые за ним не срабатывают! (Подписался)

petav ★★★★★
()
Ответ на: комментарий от petav

Триггеры за ним - это триггеры хостов, которые в Zabbix'е просто объекты в полном вакууме, а фактически хосты, доступ к которым осуществляется через маршрутизатор. Маршрутизатор упал - все триггеры some.nodata(), icmp.ping.last(), agent.ping.last() и прочая, и прочая - на лицо.

DRVTiny ★★★★★
() автор топика

Классический пример: если «упал» маршрутизатор, недоступность сетевого железа за ним не должна порождать миллиард триггеров и лавину всевозможного флуда

такое есть в netxms

ventilator ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.