Ну вот и попробовал в действии новый Zabbix 1.6. Надо сказать, что перед релизом разработчики поменяли что-то в формате базы данных. Поэтому накатить 1.6 поверх 1.5beta не получилось, пришлось поставить «с нуля». Соответственно, потерялись все данные о хостах, заводил всё по-новому. Странно, что про это ничего не написали в документации, и скрипт есть только для перехода с версий 1.4, а про 1.5 — ничего не говорится. Видимо, считается, что бета-тестеры — люди самостоятельные и сознательные, для продакшена будут ставить релиз 1.6, а тестовую бету просто снесут. Примечательно, что изменение формата базы данных произошло не по выходу 1.6, а чуть раньше — где-то в последних версиях 1.5beta. Я долго и безуспешно пытался понять, почему у меня пропали оповещения. Оказалось, что как раз из-за изменения базы. После переустановки всё заработало. Ну да ладно! Поставил, завёл. Установка как всегда, стандартная — ничего нового со времён версии 1.1.
Что бросилось в глаза?
Появилось очень много различных новых шаблонов. Теперь «из коробки» поддерживаются следущие устройства (шаблоны):
Template_APC_Automatic_Transfer_Switch, Template_APC_Battery, Template_App_MySQL, Template_C3750-48TS, Template_Cisco_2960, Template_Cisco_837, Template_Cisco_877, Template_Cisco_PIX, Template_Cisco_PIX515E, Template_Cisco_PIX_525, Template_Dell_OpenManage, Template_Dell_PowerConnect_5224, Template_Dell_PowerConnect_5324, Template_Dell_PowerConnect_6248, Template_Dell_PowerEdge, Template_FreeBSD, Template_Hibernate, Template_HPUX, Template_HP_ColorLaserJet, Template_HP_InsightManager, Template_HP_Procurve, Template_IPMI_Sun_Fire_X4100_M2, Template_Java, Template_Linux, Template_MacOS_X, Template_Microsoft_Exchange_2003, Template_Microsoft_Exchange_2007, Template_Microsoft_SQLServer_2005, Template_NetScreen_25, Template_Netware, Template_OpenBSD, Template_pfSense, Template_SNMPv1_Device, Template_SNMPv2_Device, Template_Solaris, Template_Standalone, Template_Tomcat, Template_Tru64, Template_Windows, Template_3COM_3824, Template_3COM_4400, Template_AIX
Поскольку мне столько разных устройств мониторить не нужно, лишние шаблоны я просто удалил — чтобы «не путались под ногами». А если понадобятся — всегда ведь можно раскатать с дистрибутива. Далее, переименовал оставшиеся Template_* в T_* — тоже, чтобы не загромождали экран. В шаблонах проредил Item‘ы и Trigger‘ы, создал несколько своих шаблонов, расставил удобные мне времена опросов и пороги срабатывания — в общем, «заточил» систему под себя.
Теперь у меня есть большое желание попробовать zabbix proxy — cпециальные процессы, которые позволят мониторить хосты, находящиеся в локальных сетях за фаерволами и/или с приватными адресами.
Общее впечатление. Новая система, несмотря на «круглую» версию, работает весьма устойчиво. Пока я ею доволен.
Возможно, вас заинтересует:
- Обзор системы мониторинга Zabbix Zabbix (http://www.zabbix.com) – универсальная система мониторинга, позволяющая наблюдать различные...
- Zabbix-1.6.2 вышел Только что, прямо в ночь зарелизило Zabbix до...
- Устанавливаем систему мониторинга zabbix Итак, поговорив немного о возможностях системы мониторинга zabbix, приступим...
- Zabbix-1.6.1 Первая версия со времени выхода новой стабильной ветки zabbix-1.6....
- Zabbix-1.4.6 Когда рабочий день закончился, на город обрушился вечер и...
- Zabbix 1.8 Пока мы, ничего не подозревая, юзали версию Zabbix-1.6, и...
Скажите пожайлуйста, а можно ли в zabbix на выбранный Item (или на несколько Item-ов сразу) повесить свой wrapper, который бы мог обрабатывать проходящий через него поток данных по своей собственной методике? Есть ли какое-либо АПИ на этот счет или что-то подобное? Мне надо чтобы что-то само считалось по моей методике без участия оператора и всяких там графиков и диаграмм. Спасибо заранее за ответ.
Данные, полученные от Item’ов, можно обрабатывать в Триггерах: подсчитывать, например, среднее значение, минимум или максимум за какой-то период и принимать решение о срабатывании не по текущему (последнему) значению, а на основе вычисленного (среднего, мин, макс).
Да, я читал про это в Вашей статье от 17.09. Однако, обработка в Trigger означает обязательное помещение моего обработчика на СЕРВЕРНУЮ машину. Однако я бы хотел «прицепиться» моим «перехватчиком» на машине АГЕНТА и там подсчитывать по проходящему потоку данных СВОИ цифры и осталять их ЛОКАЛЬНО на машине агента для consuming-а здесь же локально. Чтобы не загромождать центральную базу данных слишком большим потоком. Другими словами, я хотел бы собирать на агенте гораздо больше данных, чем их отправлять в «центр», причем с применением СВОИХ собственных методов обработки, а не только тех базовых, что предложены «par default».
Ааа! Идея примерно понятна.
) Вся информация накапливается в базе данных сервера и там же обрабатывается.
«А если результат одинаковый, зачем платить больше?» (с)
1) Идеология zabbix — агенты достаточно тупы и просты, всё делается на сервере (видимо, предполагается мониторить 486 машины
2) По поводу перехвата потока — ничего не скажу, тем более, сейчас в 1.6 они опять чего-то там перекуролесили, добавили сжатие и слияние всех данных в один поток (скорее всего, для того, чтобы можно было через zabbix-прокси пропускать).
3) Тем не менее, выход (наколенный) есть: можно написать свой плагин для агента на шелле (для никсов, естественно), который не только будет отдавать серверу данные, но и писать их на клиентской машине, например, в текстовые файлы. Но это ведь можно и без зеббикса делать
Спасибо за ответ. А жаль, что так не получится, тем более, что под Виндой это не так очевидно. А то, вроде, zabbix – приятная штука (судя по описаниям) – чего-то боязно мне к монстрам таким как nagios с такими моими предложениями подступаться… Кстати, опять у меня вопрос: вы говорите «плагин для агента на шелле». Значит, можно плагины для агентов писать! Это обнадеживает, но поечму только на шелле? А почему на «С» нельзя, что, нету АПИ открытого для «С»? Или еще какие-то другие причины более гдубокие есть? Merci pour votre réponse.
Да, всё верно: писать можно на чём угодно, главное — stdin/stdout.
И, кстати, ещё один аргумент «за» хранение данных на сервере: если клиент умер и мы ничего с него не можем уже взять (например, файловая система), всегда можно посмотреть его посмертные параметры в мониторинге — сервер-то жив.
плагины это что угодно на чем угодно, умеющее в std_out говорить.
test.bat
–начало–
echo 1
–конец–
zabbix_agentd.conf
UserParameter=test,c:\test.bat
можно передавать параметры
UserParameter=test,c:\test.bat $1 $2 $3
далее либо заббикс собирает агентом zabbix_agentd
либо вы посылаете заббиксу сендером zabbix_sender
Поставил…
Откровенно огорчен, что он не знаком с Nortel свитчами… а так – оаставил бы на мониторинг
Ну, всегда самому можно сварганить шаблон, чтобы по SNMP мониторил хоть Нортел, хоть Телесин. Или дождаться, пока это сделает ещё кто-нибудь