Низкоуровневое обнаружение это хорошо, но как уже правильно заметили на трекере толку от него на больших железках ноль.
У меня опрашиваемая железка отдает информацию по ~1000 устройствам, по каждому устройству можно собрать только предельно важную информацию (10-15 OID), а можно собрать и детальную информацию. Что из себя представляет такой хост с LLD шаблоном я думаю можно не рассказывать, слезы да и только. Но если бы только с хостом были проблемы, созданные графики некуда приткнуть, только по штучно их рассовывать на мапам.
Но это не все проблемы, во первых, невозможно назначить права что бы разграничить видимость мониторящихся таким образом устройств, во вторых, и самое главное, нельзя получить разную детализацию по объектам, шаблон один и как только LLD обнаружило новый объект, то шаблон применяется к нему, т.о. все объекты всегда опрашиваются одним набором элементов.
Интересный момент, если объект более не обнаруживается (не дискаверится правилом LLD), то все соответсвующие элементы данных переходят в состояние "не поддерживается" и, внимание ! они продолжают мониторится по таймеру "обновления неподдерживаемых элементов", а точнее забикс тупо стучится в несуществующие OID.
Вот мне интересно, а если бы OID данных не пропали, он бы продолжил набивать "необнаруживаемый объект" данными? А еще интересно, когда LLD повторно обнаруживает объект, то элементы данных принудительно переводятся в активное состояние или они так и ждут таймера "обновления"?
Наверно это надо репортить, но мне как то не хочется, так как все равно это все пустое, и немного обидно из-за того что бьешься об одни и теже проблемы, жалко что ли обсудить с народом что из себя должен представлять SNMP мониторинг.
Щас сяду переделывать шаблоны, опять по старинке: шаблон будет соответсвовать одному устройству, идентификатор в SNMP дереве прописывается в пользовательском макросе на хосте. А LLD видимо прийдется городить внешними скриптами.
В довершении, пользовательсткие макросы в SNMP_OID которые так просили, и которые так просто реализовать, полсотни дублей в трекерной системе, два года ожидания, и ... и их нету, не поддерживается. Спасибо, епт.
patch-poller.c_snmpoid_macros:
P.S. Видел вопрос по портам FreeBSD zabbix2*, судя по PR которые я читал рабочих портов ждать еще долго, прикладываю свои. Это порты для nigtly stable релизов которые выкладываются тут http://www.zabbix.com/developers.php
Для сборки смотрите какая версия нынче стабильная (2.0.3rc1) и какая ревизия выложена (в данный момент вижу 29675). Версия если изменится то надо будет поправить PORTVERSION в zabbix2-server/Makefile, а ревизию можете вписать, а можете и с командной строки указать при сборке:
make PORTREVISION=29675 install cllean
Мелкие патчи лежат в files/ заментаренные, если понадобится уберите точку из имени файла.
У меня опрашиваемая железка отдает информацию по ~1000 устройствам, по каждому устройству можно собрать только предельно важную информацию (10-15 OID), а можно собрать и детальную информацию. Что из себя представляет такой хост с LLD шаблоном я думаю можно не рассказывать, слезы да и только. Но если бы только с хостом были проблемы, созданные графики некуда приткнуть, только по штучно их рассовывать на мапам.
Но это не все проблемы, во первых, невозможно назначить права что бы разграничить видимость мониторящихся таким образом устройств, во вторых, и самое главное, нельзя получить разную детализацию по объектам, шаблон один и как только LLD обнаружило новый объект, то шаблон применяется к нему, т.о. все объекты всегда опрашиваются одним набором элементов.
Интересный момент, если объект более не обнаруживается (не дискаверится правилом LLD), то все соответсвующие элементы данных переходят в состояние "не поддерживается" и, внимание ! они продолжают мониторится по таймеру "обновления неподдерживаемых элементов", а точнее забикс тупо стучится в несуществующие OID.
Вот мне интересно, а если бы OID данных не пропали, он бы продолжил набивать "необнаруживаемый объект" данными? А еще интересно, когда LLD повторно обнаруживает объект, то элементы данных принудительно переводятся в активное состояние или они так и ждут таймера "обновления"?
Наверно это надо репортить, но мне как то не хочется, так как все равно это все пустое, и немного обидно из-за того что бьешься об одни и теже проблемы, жалко что ли обсудить с народом что из себя должен представлять SNMP мониторинг.
Щас сяду переделывать шаблоны, опять по старинке: шаблон будет соответсвовать одному устройству, идентификатор в SNMP дереве прописывается в пользовательском макросе на хосте. А LLD видимо прийдется городить внешними скриптами.
В довершении, пользовательсткие макросы в SNMP_OID которые так просили, и которые так просто реализовать, полсотни дублей в трекерной системе, два года ожидания, и ... и их нету, не поддерживается. Спасибо, епт.
patch-poller.c_snmpoid_macros:
Code:
--- src/zabbix_server/poller/poller.c.orig 2012-08-21 18:18:56.000000000 +0400
+++ src/zabbix_server/poller/poller.c 2012-08-21 18:19:07.000000000 +0400
@@ -642,6 +642,8 @@
errcodes[i] = NOTSUPPORTED;
continue;
}
+ substitute_simple_macros(NULL, NULL, &items[i].host, NULL, NULL,
+ &items[i].snmp_oid, MACRO_TYPE_SNMP_OID, NULL, 0);
break;
case ITEM_TYPE_SSH:
ZBX_STRDUP(items[i].publickey, items[i].publickey_orig);
Для сборки смотрите какая версия нынче стабильная (2.0.3rc1) и какая ревизия выложена (в данный момент вижу 29675). Версия если изменится то надо будет поправить PORTVERSION в zabbix2-server/Makefile, а ревизию можете вписать, а можете и с командной строки указать при сборке:
make PORTREVISION=29675 install cllean
Мелкие патчи лежат в files/ заментаренные, если понадобится уберите точку из имени файла.
Comment