Динамическое присвоение имени графику

[KipyatkOFF]

Собственно здравствуйте.

Использую версию Zabbix 1.8.3 на Fedora Linux 14 x86_64
Создал шаблоны и графики для устройств, всё работает и рисуется. Полёт нормальный.
Есть ли возможность в имени графика указать значение аля {HOSTCONN:ifDescr.1} или {Template_Device:ifDescr.1}, чтобы при просмотре комплексных графиков имя графика соответствовало шаблону: <Хост>: <Описание порта (ifDescr.1)> - <Номер порта> ?

[Jimson]

https://support.zabbix.com/browse/ZBXNEXT-1

P.S. номер запроса застравляет задуматься

[zalex_ua]

Есть ли возможность в имени графика указать значение аля {HOSTCONN:ifDescr.1} или {Template_Device:ifDescr.1}, чтобы при просмотре комплексных графиков имя графика соответствовало шаблону: <Хост>: <Описание порта (ifDescr.1)> - <Номер порта> ?

Эх, подолью ка я маселка в огонь по поводу грядущей версии 2.0 и ее возможностей
Открываю немного приватность, ну и черт с ней с этой приватностью.

Это не ZBXNEXT-1, это нечто другое - "Низкоуровневое обнаружение" !

Что имеем:

Результат:


Что это? - например в моем случае, все порты, которые имеют настроенные описания (Port Description), автоматически заносятся в мониторинг, с возможностью автоматического внесения этих Description в именах элементов данных, именах графиков, триггеров.

Меняя Description портов в коммутаторе - они автоматически меняются в Заббиксе во всех соответствующих местах !

Нравится?
СТОП, ко мне никаких вопросов, все дружно ждем публикации мануалов и тогда обсуждаем.

[KipyatkOFF]

2 zalex_ua:
Ох уж и точно масло в огонь ))
Меня дежурная смена уже убить хочет за то, что вместо дескрипшна порта им выдаётся "Port 1 Traffic" )))

[dima_dm]

2 zalex_ua:
Ох уж и точно масло в огонь ))
Меня дежурная смена уже убить хочет за то, что вместо дескрипшна порта им выдаётся "Port 1 Traffic" )))

А пока нет такой фичи, я решаю эту задачу так

http://www.zabbix.com/forum/showthread.php?t=15400

[Jimson]

1) low level discovery не решит проблему описанную в ZBXNEXT-1, так как на графике надо указывать и наименование порта и дескрипшен.

2) дискаверинг по дескрипшену нормально отработает если есть одинаковые дескрипшены ? сомниваюсь

3) автоматизированное построение xml по всему что есть на железке так же слабо помогает в задаче SNMP мониторинга, во первых не всегда нужно все, во вторых, так как zabbix поддерживает разграничение прав только по хостам (группам хостов), прийдется один SNMP агент опрашивать с разных "хостов"

4) не забываем про то что SNMP мониторинг и "графики загрузки портов моего каталиста на 24 порта" не одно и тоже, для примера: "GigabitEthernet2/0/4.867", "ATM4/1.630"

5а) есть ZBXNEXT с пачем где реализовывается поддержка user macros в graph descriptions, не могу найти, точнее некогда искать, сорри

5б) так как graph descriptions носит лишь информационный характер и никаким боком не затрагивает собственно процесс мониторинга необходимый функционал наверняка можно дописать самому на php, думаю те кому это действительно было очень нужно уже это сделали, но не делятся так как "костылями" делиться не красиво

[dima_dm]

3) автоматизированное построение xml по всему что есть на железке так же слабо помогает в задаче SNMP мониторинга, во первых не всегда нужно все, во вторых, так как zabbix поддерживает разграничение прав только по хостам (группам хостов), прийдется один SNMP агент опрашивать с разных "хостов"

4) не забываем про то что SNMP мониторинг и "графики загрузки портов моего каталиста на 24 порта" не одно и тоже, для примера: "GigabitEthernet2/0/4.867", "ATM4/1.630"

Автоматизированное построение xml решит эту задачу, т.к. в коде XML генератора вы можете заложить любую логику, которая вам нужна.
P.S. Сейчас разумнее писать не xml генератор, а использовать Zabbix API, т.к. XML импорт/экспорт как-то вяло развивается. Либо XML импорт через Zabbix API.

[Jimson]

Автоматизированное построение xml решит эту задачу, т.к. в коде XML генератора вы можете заложить любую логику, которая вам нужна.

если роутеров парочка, то возможно да
в противном же случае "конфигурация" забикса превратится в директорию скриптов-костылей и сопровождать это все сможет только тот кто эти скрипты написал

да и какая разница тогда между подкостыливаем сторонних скриптов генерящих xml-ы, которые затем надо импортировать, и тем что бы просто докостылить раскрытие item-macros в php frontend ?

[dima_dm]

если роутеров парочка, то возможно да
в противном же случае "конфигурация" забикса превратится в директорию скриптов-костылей и сопровождать это все сможет только тот кто эти скрипты написал

да и какая разница тогда между подкостыливаем сторонних скриптов генерящих xml-ы, которые затем надо импортировать, и тем что бы просто докостылить раскрытие item-macros в php frontend ?

В том-то и дело, что у меня этих роутеров десятки тысяч, и руками это ввести и поддерживать физически невозможно. А так один скрипт с логикой, файл с описанием роутеров в формате
IP SNMP_community другие дополнительные параметры ...
И всё крутиться и работает автоматически из cron.
Сейчас проблема в автоматическом импорте конфигурации через Zabbix API, я жду выхода финальной Zabbix 1.8.4, там должно быть исправлено.
P.S. А раскрытие макросов только снижает общую производительность системы.

[Jimson]

не представляю себе 10к роутеров энтерпрайз класса, да хотя бы семитонников в одной сети
просьба уточнить о чем речь, 10к SOHO или именно 10к core-routers

[dima_dm]

не представляю себе 10к роутеров энтерпрайз класса, да хотя бы семитонников в одной сети
просьба уточнить о чем речь, 10к soho или именно 10к core-routers

Да разных, я уже писал, что работаю в провайдере, который входит в 5-ку крупнейших операторов мира, с покрытием 220 стран на 5 континетах.

[zalex_ua]

1) low level discovery не решит проблему описанную в ZBXNEXT-1, так как на графике надо указывать и наименование порта и дескрипшен.

то, что именно имел ввиду автор запроса ZBXNEXT-1, новая функциональность low level discovery (напомню что она появится в 2.0) как раз и решит.
У меня не большая инфраструктура и всего два типа коммутаторов D-link, поэтому я не большой знаток SNMP на разных устройствах, на разных типах устройств.
Вот что возвращается на IF-MIB::ifDescr для разных коммутаторов:

1-й [B]RMON Port  1 on Unit 1[/B] - с изменяющимися индексами интерфейсов и наверное юнитов с стеке
2-й [B]Ethernet Interface[/B] - здесь ничего не меняется.

Понятно что там есть vlan-ы, но я их сейчас не рассматриваю, так как большинство людей имеют ввиду физические интерфейсы.
Описание же порта, которое ручками прописываем в свойствах каждого порта, у меня можно получить по IF-MIB::ifAlias

Не знаю на сколько в реальной жизни целесообразно включать например в имя графика И ifDescr И ifAlias, я для себя не вижу такой необходимости. Соответственно и в запросе ZBXNEXT-1 фигурирует потребность в ifDescr ИЛИ ifAlias, так что перед тем как ссылаться на запрос, читай внимательней !

Дополнительно сообщаю, если я правильно понял, в low level discovery сейчас нет возможности опросить одновременно в пределах одного Правила например оба ifDescr и ifAlias, и включить их в название одного элемента данных, графика, триггера.

Вообще low level discovery - это новая философия, которую еще нужно осознать и понять в каких случаях она может быть эффективней и удобней идеологии шаблонов и всяческих способов экспорта/импорта.
На это нужно время и мнение многих пользователей.

Напомню что SNMP - это всего лишь одна из частей low level discovery.

2) дискаверинг по дескрипшену нормально отработает если есть одинаковые дескрипшены ? сомниваюсь

Критерием уникальности есть индекс ! А то что другое - это опционально и им может быть что угодно - ifDescr, ifSpeed ifOperStatus и т.д. по вашему желанию.
И вот по этому другому также можно опционально делать фильтрацию с помощью regexp, что в частности на моих картинках и сделано - если ifAlias НЕ пустое, значит начинаем автоматически мониторить.

P.S. А раскрытие макросов только снижает общую производительность системы.

В выше описываемом мною случае по отношению к low level discovery, не используется раскрытие макросов - дескрипшены портов, которые включаются в имена, записываются в БД прямо простым текстом в поле имен - проверено. Так что о предполагаемом падении производительности можно не опасаться.

[dima_dm]

В выше описываемом мною случае по отношению к low level discovery, не используется раскрытие макросов - дескрипшены портов, которые включаются в имена, записываются в БД прямо простым текстом в поле имен - проверено. Так что о предполагаемом падении производительности можно не опасаться.

Про макросы я писал Jimson.
Тут дело не только в дескрипшинах, на оборудование удаляются/добавляются новые модули, VLAN, изменяется конфигурация и все эти проблемы не удастся решить low level discovery. Т.к.изменение конфигурации тянет за собой формирование новых/удаление элементов данных, триггеров, графиков и т.д. Такую логику физически невозможно заложить в любое универсальное средство. Для себя я не вижу альтернативы динамическому формированию конфигурации из внешних скриптов, low level discovery сможет только упростить логику во внешних скриптах, но не заменить их.

[zalex_ua]

Пна оборудование удаляются/добавляются новые модули, VLAN, изменяется конфигурация и все эти проблемы не удастся решить low level discovery. Т.к.изменение конфигурации тянет за собой формирование новых/удаление элементов данных, триггеров, графиков и т.д. Такую логику физически невозможно заложить в любое универсальное средство. Для себя я не вижу альтернативы динамическому формированию конфигурации из внешних скриптов, low level discovery сможет только упростить логику во внешних скриптах, но не заменить их.

Да, я согласен. Только подмечу, что добавление новых "ресурсов" будет работать - проверено, а вот удаление, скажем так устаревших "ресурсов", - такого пока нету, и я по этому поводу разрабам написал чтобы подразмыслили в этом направлении.

Понятно, что внешние скрипты - это неограниченная мощь, но не всем они под силу. А справедливости ради отмечу что low level discovery это довольно гибкая штука, и еще рано говорить что оно что либо не умеет делать, и я почти уверен что там еще будут улучшения к выходу релиза 2.0

[dima_dm]

Понятно, что внешние скрипты - это неограниченная мощь, но не всем они под силу.

Вот именно по этой причине я призываю всех голосовать за

https://support.zabbix.com/browse/ZBXNEXT-10

И технология станет доступна каждому.
На мой взгляд не хватает для XML импорта нормальной фичи обновить. Т.е. если нет в новом шаблоне такого триггера/элемента данных/графика - удалять их. Если есть, но с другими настройками - заменить. Сейчас опция “Обновить Существующий” c "Добавить Пропущенный" работает очень странно, т.е. она все добавляет, но ничего не удаляет, и триггеры/графики начинают размножаться, элементы данных спасает от такого эффекта уникальные ключи, но они тоже только добавляются.