Comments 15
А зачем указывать идентификаторы шаблонов и групп? Для человека удобнее писать все-таки имена…
Видимо в API оно фигурирует в виде ID
Никто не мешает отрезолвить имя в ID
ИМХО, 5 цифр ID лучше, чем длинное название шаблона. Я думаю, проще посмотреть список доступных групп/шаблонов и указать их ID.
Во первых мнемоническое обозначение легче запомнить, во вторых если экономите на количестве символов то можно использовать названия шаблонов длинной менее 5 символов, в третьих при использовании кластерезации в заббиксе идентификаторы будут 16-значными.
Согласен, насчет кластеризации — весомый аргумент. Можно делать и так, с названиями. Кому как удобнее, опять-таки.
Стоит добавить, что ИД групп можно взять запросом к заббикс API, причём возможности поиска весьма обширны.
При добавлении хоста, требуются ИД групп для использования индексов БД и схожести передоваемых структур с другими методами API, а так же во избижании ошибок.
В целом API расчитан что ИД будут доставаться средствами самого же API и юзеру их знать не нужно.
П.С. инфа на правах екс забикс разраба.
При добавлении хоста, требуются ИД групп для использования индексов БД и схожести передоваемых структур с другими методами API, а так же во избижании ошибок.
В целом API расчитан что ИД будут доставаться средствами самого же API и юзеру их знать не нужно.
П.С. инфа на правах екс забикс разраба.
А чем discovery плох? Создал правила обнаружения, сделал необходимые действия по необходимым условиям и будет счастье, также автоматом можно хосты удалять.
Условия
действия
«Выполнять удалённые команды на текущем узле сети» скрипт в который уходит ip добавленного узла и который переименовывает добавленный узел. Необходимо, так как добавленный узел был обнаружен по ip и имя его будет видно как ip что несколько неудобно, лучше его преобразовать в hostname. Все достаточно тривиально настраивается, заморочка только со скриптом.
ЗЫ А я через zabbix api пытаюсь подружить Zabbix и NOC. Пока все это сделано на bash с использованием прямых запросов к БД zabbix и БД NOC. Очень хочется чтобы все обнаруженные узлы сразу АВТОМАТОМ попадали в систему управления NOC. Пока это сделано скриптом который сравнивает узлы в заббиксе и ноке и недостающие добавляет в нок.
Условия
олученное значение содержит "S2300"
Состояние обнаружения = "Доступен"
Тип сервиса = "SNMPv2 агент"
IP адрес узла сети = "ххх.ххх.ххх.2-254"действия
Выполнять удалённые команды на текущем узле сети
Добавить узел сети
Добавить в группы узлов сети: FTTB
Добавить в группы узлов сети: FTTB Центр
Присоединить к шаблонам: Template_Huawei-S2300
«Выполнять удалённые команды на текущем узле сети» скрипт в который уходит ip добавленного узла и который переименовывает добавленный узел. Необходимо, так как добавленный узел был обнаружен по ip и имя его будет видно как ip что несколько неудобно, лучше его преобразовать в hostname. Все достаточно тривиально настраивается, заморочка только со скриптом.
ЗЫ А я через zabbix api пытаюсь подружить Zabbix и NOC. Пока все это сделано на bash с использованием прямых запросов к БД zabbix и БД NOC. Очень хочется чтобы все обнаруженные узлы сразу АВТОМАТОМ попадали в систему управления NOC. Пока это сделано скриптом который сравнивает узлы в заббиксе и ноке и недостающие добавляет в нок.
У нас есть скрипты, которые запускают новую ноду и привязывают все необходимое в заббиксе. На мой взгляд, это более гибкая схема, чем при необходимости в discovery добавлять новые правила и т.д.
У каждого свой подход, я стремлюсь к полной автоматизации.
да и у меня уже Zabbix 2.0.1rc2
Sign up to leave a comment.
Массовое добавление/удаление хостов в Zabbix при помощи API