easy_john
02-06-2009, 12:33
Небольшие итоги об установке zabbix 1.4.x в большой сети.
Для нас мониторинговая система должна отвечать двум задачам:
1. сообщать о выходе какой-либо метрики за пределы нормы (при этом быть достаточно настраиваемой, что бы не завалить однообразными письмами)
2. давать понимание того, что именно в прошлом, от чего стало плохо.
по первому пункту:
- не хватает продвинутой системы оповещения, например возможности повторного отправления сообщений, каждые N минут, пока триггер TRUE. А так же ограничения отправки писем, например не более N сообщений о событиях группы M в течении часа (суток).
- Очень важное: не хватает статистических формул (в основном для тестирования каналов связи): медианы и выборки "M значений за N времени > X". существующими математическими формулами такую статистику не повторить!
по второму:
- нет гибкой выборки периода отображения графиков. зачастую график за час, это слишком много, особенно, если нужно видеть уровень значений между двумя пиками.
Еще из тонкостей:
- наличие бесполезных вещей. например аудит (administration - audit). зачем знать что триггер изменен, если нет данных на что он зменился, а главное, каким он был до изменения?
- возникли трудности с каскадными зависимостями: мы не хотим получать оповещение о "недоступности сервиса, если недоступен весь хост", так же как "о всех хостах, если недоступен коммутатор к которому они подключены". Настройка таких зависимостей, хоть и реализуема теоретически, практически при наличии уже десятка коммутаторов и нескольких десятков серверов изменить все триггеры вручную нет никаких сил. Или я просто не нашел способа их грамотно настроить?
PS. Бегло поискал сhangelog 1.6.x на сайте, но не нашел. На rootconf слышал только, что вроде добавили возможность не заваливать письмам.. значит все остальные вопросы остаются в силе.
Для нас мониторинговая система должна отвечать двум задачам:
1. сообщать о выходе какой-либо метрики за пределы нормы (при этом быть достаточно настраиваемой, что бы не завалить однообразными письмами)
2. давать понимание того, что именно в прошлом, от чего стало плохо.
по первому пункту:
- не хватает продвинутой системы оповещения, например возможности повторного отправления сообщений, каждые N минут, пока триггер TRUE. А так же ограничения отправки писем, например не более N сообщений о событиях группы M в течении часа (суток).
- Очень важное: не хватает статистических формул (в основном для тестирования каналов связи): медианы и выборки "M значений за N времени > X". существующими математическими формулами такую статистику не повторить!
по второму:
- нет гибкой выборки периода отображения графиков. зачастую график за час, это слишком много, особенно, если нужно видеть уровень значений между двумя пиками.
Еще из тонкостей:
- наличие бесполезных вещей. например аудит (administration - audit). зачем знать что триггер изменен, если нет данных на что он зменился, а главное, каким он был до изменения?
- возникли трудности с каскадными зависимостями: мы не хотим получать оповещение о "недоступности сервиса, если недоступен весь хост", так же как "о всех хостах, если недоступен коммутатор к которому они подключены". Настройка таких зависимостей, хоть и реализуема теоретически, практически при наличии уже десятка коммутаторов и нескольких десятков серверов изменить все триггеры вручную нет никаких сил. Или я просто не нашел способа их грамотно настроить?
PS. Бегло поискал сhangelog 1.6.x на сайте, но не нашел. На rootconf слышал только, что вроде добавили возможность не заваливать письмам.. значит все остальные вопросы остаются в силе.