В продолжении темы, а точнее апдейт срипта и шаблонов, а так же принципа "фильтрации".
1) Я изначально все это задумывал с таким расчетом что бы можно было не только эзернет свичи опрашивать, но и MPLS маршрутизаторы. Если я "натравлю" SNMP_Interfaces шаблон на PE router, то получу сотни интерфейсов у одного хоста и большинство этих интерфейсов будут линки на клиеские CE routers. Смысл такого "мега хоста" лично от меня ускользает, для мониторинга бэкбона достаточно мониторить только собственные физические линки, а для мониторинга клиенских VRF нужно "разделить" этот PE на кучу хостов (один хост - один VRF), в этом случае можно и клиенту показать этот хост и схему для клиента сделать.
2) Фильтрация LLD через стандартный механизм регулярных выражений не удобна. Простой пример, у нас есть шаблон универсальный, мы можем маркировать интерфейсы (на оборудовании которое поддерживает изменение дескрипшенов через конфиг), все клево, но есть оборудование на котором нужно мониторить только интерфейсы определенного типа и дескрипшены оно не поддержкивает. В моем случае появились какие то мотороловские WiFi точки, нужно снимать данные только с интерфейсов radio1 и radio2. Как быть?
Первое решение это сделать "наследника" от SNMP_Interfaces и изменить фильтр, но если вы после этого начнете менять фильтр SNMP_Interfaces то он обновится и у "наследника". Следить за этим стремно.
3) Наглядная демострация использования макросов, как на мой взгляд нужно делать универсальные шаблоны.
Итак.
a) Глобальный regex я использую в качестве шаблона LLD только для разделения Counter64/Counter32 интерфейсов, для детекта "физических" интерфейсов и для отфильтровки AdminDown.
b) Макрос {$LLD_IF_FLAG} перенесен в шаблон, смысла его объявлять глобально не вижу, лучше пусть будет все в одном месте. Значение по умолчанию '[D]' - если эта подстрока есть в дескрипшене интерфейса то шаблон "увидит" этот интерфейс. Этот макрос теперь можно "отключить", если значение этого макроса пустая строка или 0 (ноль), то скрипт не пытается искать подстроку и при этом считает что все интерфейсы "помечены". По другому скажу: если макрос переопределен в 0, то скрипт для всех интерфейсов добавит ",FLAG," в {#IFTAGS}, а следовательно глобальное регулярное выражение (см. пункт a) дает совпадение со всеми интерфейсами.
c) Макрос дополнительной фильтрации {$LLD_IF_REGEX}. Скрипт не проверяет валидность этого агрумента, будьте аккуратны. Фильтрация осуществляется через обычный перловый regexp по {#IFTAGS}. Значение по умолчанию 0 (ноль), срипт ничего не сравнивает и не отфильтровывает.
В качестве примера по пунктам a, b, и c: мне нужно для определенного хоста отмониторить интерфейсы radio1 и radio2, при этом маркировать через дескрипшен я не могу или не хочу. В таком случае для этого хоста мы переопределяем макросы:
{$LLD_IF_FLAG} = 0
{$LLD_IF_REGEX} = ,radio[12],
Мы отключили фильтрацию по "флагу" в дескрипшене и включили обычную regex фильтрацию. В JSON мы получим два объекта, интерфейсы radio1 и radio2.
d) Новый макрос {$MPLS_VRF_RD} для фильтрации по RD (объяснять что такое RD не буду, кому надо и так знают). По умолчанию значение 0, т.е. фильтрация отключена и скрипт не "выкачивает" требуемые для этой фильтрации индексы.
Приведу пример. Есть у нас хост BIG_PE_RTR, адрес у него 10.0.0.1, интерфейсы мониторим через шаблон, макросы стандартные. Таким образом на хосте BIG_PE_RTR у нас отдискаверятся только интерфейсы у которых в дескрипшене установлен флаг '[D]', а выставим мы этот флаг только на бэкбонных интерфейсах, в том числе на всяких там транках на Трастелеком, Ростелеком, Комкор и прочих, а вот интерфейсы в сторону CE мы помечать не станем.
Затем мы создадим еще один хост BIG_PE_RTR_VPN123, адрес у него будет тот же 10.0.0.1, и макросы мы у него зададим следующие:
{$LLD_IF_FLAG} = 0
{$MPLS_VRF_RD} = 12345:123
Итак, мы отключили фильтрацию по флагу, и включили фильтрацию по RD. В итоге на хосте BIG_PE_RTR_VPN123 у нас задискаверятся только те интерфейсы, которые "ip forwarded vrf VPN123", а точнее те которые forwarded в VRF с RD равным "12345:123". Вуаля.
e) Используем макросы в триггерах.
{$IF_LOAD_HYSTERESIS} = 0.10
{$IF_LOAD_THRESHOLD} = 0.75
Несколько триггеров в шаблоне, проверяем загрузку интерфейсов, смысл макросов думаю понятен, как и то что мы их можем переопределять как на хостах, так и сделав шаблон-наследник. Загрузка сравнивается с ifSpeed/ifHCSpeed, который в свою очередь вы можете задать явно в конфигурации оборудовании, ну во всяком случае на cisco IOS параметр bandwidth поддерживается для всех интерфейсов в том числе для сабинтерфейсов. По умолчанию ifSpeed равен скорости интерфейса.
P.S. Если кто то решит "апгрейдится", то сразу предупреждаю, что простая замена "шаблона" поломает вам дискаверинг, будете плакать. Связано это с тем что отдискаверенные элементы "привязаны" к ID правила дискаверинга, следовательно что бы все проапгрейдилось как надо правила дискаверинга (ключи этих элементов) не должны изменится. Ключем для правила дискаверинга как и для любой "внешней проверки" выступает сам скрипт с параметрами. Вообщем я поменял и имя скрипта и добавил параметры, так что просто так нифига не получится. Что бы "проапгрейдится" прийдется отключить шаблон без удаления элементов, затем вручную изменить правила LLD (можно предварительно деактивировать само правило LLD, а затем уже спокойно менять), изменяем "ключ" правила через cut&paste, иначе кто то точно будет плакать, ну и затем подключаем новый шаблон. Если новый шаблон подключился и при этом у нас не создались новые правила, а старые при этом получили принадлежность шаблону, значит у вас все получилось.
1) Я изначально все это задумывал с таким расчетом что бы можно было не только эзернет свичи опрашивать, но и MPLS маршрутизаторы. Если я "натравлю" SNMP_Interfaces шаблон на PE router, то получу сотни интерфейсов у одного хоста и большинство этих интерфейсов будут линки на клиеские CE routers. Смысл такого "мега хоста" лично от меня ускользает, для мониторинга бэкбона достаточно мониторить только собственные физические линки, а для мониторинга клиенских VRF нужно "разделить" этот PE на кучу хостов (один хост - один VRF), в этом случае можно и клиенту показать этот хост и схему для клиента сделать.
2) Фильтрация LLD через стандартный механизм регулярных выражений не удобна. Простой пример, у нас есть шаблон универсальный, мы можем маркировать интерфейсы (на оборудовании которое поддерживает изменение дескрипшенов через конфиг), все клево, но есть оборудование на котором нужно мониторить только интерфейсы определенного типа и дескрипшены оно не поддержкивает. В моем случае появились какие то мотороловские WiFi точки, нужно снимать данные только с интерфейсов radio1 и radio2. Как быть?
Первое решение это сделать "наследника" от SNMP_Interfaces и изменить фильтр, но если вы после этого начнете менять фильтр SNMP_Interfaces то он обновится и у "наследника". Следить за этим стремно.
3) Наглядная демострация использования макросов, как на мой взгляд нужно делать универсальные шаблоны.
Итак.
a) Глобальный regex я использую в качестве шаблона LLD только для разделения Counter64/Counter32 интерфейсов, для детекта "физических" интерфейсов и для отфильтровки AdminDown.
b) Макрос {$LLD_IF_FLAG} перенесен в шаблон, смысла его объявлять глобально не вижу, лучше пусть будет все в одном месте. Значение по умолчанию '[D]' - если эта подстрока есть в дескрипшене интерфейса то шаблон "увидит" этот интерфейс. Этот макрос теперь можно "отключить", если значение этого макроса пустая строка или 0 (ноль), то скрипт не пытается искать подстроку и при этом считает что все интерфейсы "помечены". По другому скажу: если макрос переопределен в 0, то скрипт для всех интерфейсов добавит ",FLAG," в {#IFTAGS}, а следовательно глобальное регулярное выражение (см. пункт a) дает совпадение со всеми интерфейсами.
c) Макрос дополнительной фильтрации {$LLD_IF_REGEX}. Скрипт не проверяет валидность этого агрумента, будьте аккуратны. Фильтрация осуществляется через обычный перловый regexp по {#IFTAGS}. Значение по умолчанию 0 (ноль), срипт ничего не сравнивает и не отфильтровывает.
В качестве примера по пунктам a, b, и c: мне нужно для определенного хоста отмониторить интерфейсы radio1 и radio2, при этом маркировать через дескрипшен я не могу или не хочу. В таком случае для этого хоста мы переопределяем макросы:
{$LLD_IF_FLAG} = 0
{$LLD_IF_REGEX} = ,radio[12],
Мы отключили фильтрацию по "флагу" в дескрипшене и включили обычную regex фильтрацию. В JSON мы получим два объекта, интерфейсы radio1 и radio2.
d) Новый макрос {$MPLS_VRF_RD} для фильтрации по RD (объяснять что такое RD не буду, кому надо и так знают). По умолчанию значение 0, т.е. фильтрация отключена и скрипт не "выкачивает" требуемые для этой фильтрации индексы.
Приведу пример. Есть у нас хост BIG_PE_RTR, адрес у него 10.0.0.1, интерфейсы мониторим через шаблон, макросы стандартные. Таким образом на хосте BIG_PE_RTR у нас отдискаверятся только интерфейсы у которых в дескрипшене установлен флаг '[D]', а выставим мы этот флаг только на бэкбонных интерфейсах, в том числе на всяких там транках на Трастелеком, Ростелеком, Комкор и прочих, а вот интерфейсы в сторону CE мы помечать не станем.
Затем мы создадим еще один хост BIG_PE_RTR_VPN123, адрес у него будет тот же 10.0.0.1, и макросы мы у него зададим следующие:
{$LLD_IF_FLAG} = 0
{$MPLS_VRF_RD} = 12345:123
Итак, мы отключили фильтрацию по флагу, и включили фильтрацию по RD. В итоге на хосте BIG_PE_RTR_VPN123 у нас задискаверятся только те интерфейсы, которые "ip forwarded vrf VPN123", а точнее те которые forwarded в VRF с RD равным "12345:123". Вуаля.
e) Используем макросы в триггерах.
{$IF_LOAD_HYSTERESIS} = 0.10
{$IF_LOAD_THRESHOLD} = 0.75
Несколько триггеров в шаблоне, проверяем загрузку интерфейсов, смысл макросов думаю понятен, как и то что мы их можем переопределять как на хостах, так и сделав шаблон-наследник. Загрузка сравнивается с ifSpeed/ifHCSpeed, который в свою очередь вы можете задать явно в конфигурации оборудовании, ну во всяком случае на cisco IOS параметр bandwidth поддерживается для всех интерфейсов в том числе для сабинтерфейсов. По умолчанию ifSpeed равен скорости интерфейса.
P.S. Если кто то решит "апгрейдится", то сразу предупреждаю, что простая замена "шаблона" поломает вам дискаверинг, будете плакать. Связано это с тем что отдискаверенные элементы "привязаны" к ID правила дискаверинга, следовательно что бы все проапгрейдилось как надо правила дискаверинга (ключи этих элементов) не должны изменится. Ключем для правила дискаверинга как и для любой "внешней проверки" выступает сам скрипт с параметрами. Вообщем я поменял и имя скрипта и добавил параметры, так что просто так нифига не получится. Что бы "проапгрейдится" прийдется отключить шаблон без удаления элементов, затем вручную изменить правила LLD (можно предварительно деактивировать само правило LLD, а затем уже спокойно менять), изменяем "ключ" правила через cut&paste, иначе кто то точно будет плакать, ну и затем подключаем новый шаблон. Если новый шаблон подключился и при этом у нас не создались новые правила, а старые при этом получили принадлежность шаблону, значит у вас все получилось.
Attached Files
Comment