Расширяем snmp lld скриптами

[DeeZ]

Кажется начинаю понимать свою ошибку.
Получается мой скрипт должен возвращать только что то типа:

./dnsstat.py 
{"data":[
{"{#DNSTYPE}":"A","{#DNSTAGS}":"1"},
{"{#DNSTYPE}":"NS","{#DNSTAGS}":"1"},
{"{#DNSTYPE}":"CNAME","{#DNSTAGS}":"1"},
{"{#DNSTYPE}":"SOA","{#DNSTAGS}":"1"},
{"{#DNSTYPE}":"PTR","{#DNSTAGS}":"1"},
{"{#DNSTYPE}":"MX","{#DNSTAGS}":"1"},
{"{#DNSTYPE}":"TXT","{#DNSTAGS}":"1"},
{"{#DNSTYPE}":"AAAA","{#DNSTAGS}":"1"},
{"{#DNSTYPE}":"CNAME","{#DNSTAGS}":"2"},
{"{#DNSTYPE}":"SOA","{#DNSTAGS}":"2"},
{"{#DNSTYPE}":"PTR","{#DNSTAGS}":"2"},
{"{#DNSTYPE}":"MX","{#DNSTAGS}":"2"},
]}

По #DNSTAGS я смогу фильтровать при дискавере (2=cache).

Но далее мне нужен еще один скрипт, который будет задан в протипе данных, и будет выполняясь (например dns.get.count[#DNSTYPE}]) возвращть только цифру.
Верно?

Если с dns.get.count все понятно. я прописваю в zabbix_agentd.conf
UserParameter=dns.get.count[*],/usr/lib/zabbix/externalscripts/dnsgetcount.sh "$1"

То где и как прописывать dnsstat.py ? так же в UserParameter?

[sadman]

То где и как прописывать dnsstat.py ? так же в UserParameter?

Определитесь, где у вас скрипты будут лежать - на удаленном узле или на том же, где и Zabbix. В первом случае и Discovery Rule и элементы данных должны работать через UserParameter, во втором - их можно и через External Script запустить и через UserParameter локального агента.

Через агента ключи получаются покрасивее и поудобнее для использования в триггерах. Особенно, если в скрипт много параметров передавать надо.

[Jimson]

Очевидно что DNS сервера находятся не там же где забикс, так что скорее всего проверки будут через агента.
Если одни и тот же скрипт умеет отдавать и LLD JSON для правила (например по параметру "lld") и данные, то достаточно того UserParameter что указан выше, а в шаблоне будет правило типа "забикс агент активный/пасивный" с ключем dns.get.count[lld] и прототип элемента данных типа "забикс агент активный/пасивный" с ключом dns.get.count[{#DNSTYPE}]

[Melanxolik]

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

Суть проблемы вот в чем:

       
 {
            "{#IFALIAS}": "LAG_3R41_1",
            "{#IFDESCR}": "GigabitEthernet1/1/41",
            "{#IFINDEX}": "41",
            "{#IFLEVEL}": 4,
            "{#IFSPEED}": "0Mbit",
            "{#IFTAGS}": "GigabitEthernet1/1/41,Type:6,AdminStatus:up,FLAG,ifSpeedShort:0,ifSpeedSTR:0Mbit,ifLevel:4,Physical,Counter64",
            "{#IFTRIGERPACKETS}": "",
            "{#IFTRIGERTRAFFIC}": ""
},

Все красиво, как надо, нужный параметр прилетает: "{#IFLEVEL}": 4

А теперь каким-то интересным способом надо сделать:

{SNMP_Interfaces_Python:ifHCAdminStatus[{#IFDESCR}].last()}#2 & {SNMP_Interfaces_Python:ifHCOperStatus[{#IFDESCR}].last()}#1 & {SNMP_Interfaces_Python:{#IFLEVEL}.last()}=4

Но вот в чем проблема, {SNMP_Interfaces_Python:{#IFLEVEL}.last()}=4
здесь мы обращаемся к lld элементу, а не к прототипу элемента данных, а забикс такого не умеет, может есть какой-то вариант как создать элемент данных из результатов lld,


хм. несочтите за бред, но сделал так:

{SNMP_Interfaces_Python:ifHCAdminStatus[{#IFDESCR}].last()}#2 & {SNMP_Interfaces_Python:ifHCOperStatus[{#IFDESCR}].last()}#1 & {#IFLEVEL}=4

в итоге прилетело:

{sw01-center:ifHCAdminStatus[GigabitEthernet1/1/43].last()}#2 & {sw01-center:ifHCOperStatus[GigabitEthernet1/1/43].last()}#1 & 4=4

выглядит бредово, но если вконце 4=4 то тригер срабатывает и все вроде идет как надо.

[Jimson]

Мы уже обсуждали подобный вопрос несколько недель назад. Ты хочешь получать данные из JSON LLD, а это не верно, правило LLD возвращает описание "объектов", а не их "состояние".
С другой стороны, я использовал некоторые данные об "объекте" для фильтров, например, ifAdminStatus, для чего и был придуман {IFTAGS}. Но фильтры и триггеры это несколько разные вещи, так что да, ты хочешь изобразить что то очень странное.
Твоя "4" должна быть данными, если я правильно понял, и по этим данным еще и триггер хочется, в таком случае должен быть во-первых прототип элемента данных SNMP_Interfaces:ifLevel[{#IFDESCR}] типа "траппер", во-вторых кто то должен присылать значения для этого элемента данных.
Совместить LLD-rule скрипт и отправку данных типа траппер не получится.

P.S. тот триггер что ты изобразил будет обновляться при каждом изменении "level" и, подозреваю, результат тебя не очень устроит, так как измененный триггер это ни ОК, ни ПРОБЛЕМА, это нечто среднее.

PP.S. попытаться совместить LLD-rule скрипт с отправкой данных траппер-элементу можно, в двух случаях
1) LLD-rule скрипт это не внешняя проверка, а тоже траппер, тогда скрипт вначале отправляет JSON, затем отправляет данные для "level" по каждому "объекту", затем завершает работу. Естественно такой скрипт должен кто то запускать, например cron
2) тебя устроит что для вновь созданных "объектов" данные "level" ты не получить, "level" придет только во время следующего запуска LLD-rule, в таком случае скрипт вначале отсылает все "level", а затем, как обычно, возвращает в stdout JSON

[Melanxolik]

Согласен на 100 процентов, но задачка не много не та, сейчас попробую описать саму суть:

Есть порты коммутаторов, на каждый порт сейчас приходится порядка 12 тригеров, если бы забикс умел применять фильтр к тригеру их было бы гораздо меньше: 2-4.
На порт вешаются все тригера независимо от условий (я бы эту фичу конечно зареквестил, вот если бы её реализовали было в обще шикарно, сразу кучу лишних тригеров отсеилось бы на стадии создания обьектов).
То есть о чем я:
есть основные фильтры дискаверинга, а теперь к тригеру применяем доп фильтр где мы говорим, создавать тригер в котором ifLevel:4 и т.д. это значительно уменьшит количество тригеров на портах.

Суть проблемы дальше:
надо отсеть критически важные порты от обычных второстепенных портов, тут как раз и помогает их ifLevel который для критически важных равен 4. ifLevel меняется только на стадии дискавернинга, его нет смысла трапить без остановки.

Может попробовать запулить фичреквест на выделенные фильтры для тригеров? это очень удобно как мне кажется.

Опять же, продолжая тему зачем этот огород:
мне жутко не удобно каждый раз управлять тригерами загрузки порта из забикса, по этому подумал что это можно делать прямо из lld, всего лишь присылая нужные изначальные значения для портов на стадии lld

[yukra]

Согласен на 100 процентов, но задачка не много не та, сейчас попробую описать саму суть:

Есть порты коммутаторов, на каждый порт сейчас приходится порядка 12 тригеров, если бы забикс умел применять фильтр к тригеру их было бы гораздо меньше: 2-4.
На порт вешаются все тригера независимо от условий (я бы эту фичу конечно зареквестил, вот если бы её реализовали было в обще шикарно, сразу кучу лишних тригеров отсеилось бы на стадии создания обьектов).
То есть о чем я:
есть основные фильтры дискаверинга, а теперь к тригеру применяем доп фильтр где мы говорим, создавать тригер в котором iflevel:4 и т.д. это значительно уменьшит количество тригеров на портах.

Суть проблемы дальше:
надо отсеть критически важные порты от обычных второстепенных портов, тут как раз и помогает их iflevel который для критически важных равен 4. Iflevel меняется только на стадии дискавернинга, его нет смысла трапить без остановки.

Может попробовать запулить фичреквест на выделенные фильтры для тригеров? это очень удобно как мне кажется.

Опять же, продолжая тему зачем этот огород:
мне жутко не удобно каждый раз управлять тригерами загрузки порта из забикса, по этому подумал что это можно делать прямо из lld, всего лишь присылая нужные изначальные значения для портов на стадии lld

Я для себя реализовал это так: есть 2 шаблона, первый идет только физические интерфейсы (не особо мне интересные) и навешивает триггеры на них, второй ищет логические (более приоритетные) и навешивает на них другие триггеры. При это "шаблоны" различаются только разными фильтрами и разными айтемами\триггерами.

[Melanxolik]

Понимаю, но здесь айтимы одинаковые и дублировать их смысла нету, это явно не логичное действие.

[yukra]

Понимаю, но здесь айтимы одинаковые и дублировать их смысла нету, это явно не логичное действие.

Зато работает уже "вчера"

[Jimson]

А ты пробовал в несколько правил это сделать? Если первое правило с прототипами ЭД, а второе/третье/etc только с триггерами. Попробуй.
Триггеры они вообще в воздухе висят, их с элементами данных связывают "формулы". Вот с графиками такое не прокатит, а с триггерами очень даже может быть.

[DeeZ]

Суть проблемы дальше:
надо отсеть критически важные порты от обычных второстепенных портов, тут как раз и помогает их ifLevel который для критически важных равен 4.

Если я правильно понял, то вам нужно сделать 2 дискавери правила. в одном задать фильтра ifLevel=4. В нем создавать нужные важные ЭД и тригеры.
Во втором дискавери задать фильтр ifLevel<>4 и там уже джелать только ныжне (например трафик без тригеров).
Одинаковых названий не будет, тк у вас правила дискавери вернут разные множества а в сумме получите все порты.

(У себя фильтрую по дескритору но прямо в тригере, что не верно. пока писал вам, подумал что надо и у себя переделать дискавери)

[Melanxolik]

Народ я прекрасно вас понимаю, но давайте смотреть реалиям в глаза, завтра будет ifLevel3, ifLevel2 и т.д. тогда прийдется создать еще пачку фильтров с кучей дубликатов, понятно что на текущей стадии по другому просто не получится, тут в трекере уже поднял эту тему и есть примерно похожая тема, человек просил примерно такое же, надеюсь тема незаглохнет и её сдвинут сместа.
LLD это очень классная штука, но плодить элементы из-за разных тригеров не серьзно, нужны фильтры на тригеры и правильно заметили, возможно и на графики, хотя бы на первом этапе, это было бы просто шикарным решением.

[Jimson]

нужны фильтры на тригеры

Это невозможно. Для начала триггер должен обзавестись прямой связностью с кем либо, а ее нет и врядли появится когда-нибудь. То к чему относится триггер определяется лишь тем что ты напишешь в его выражении.
Зайди в свой шаблон, в правило обнаружения, прототипы триггеров, создать триггер, и напиши в выражении
{Zabbix_server:blabla.func()} = 1
Триггер создастся, но в прототипах его не будет, внезапно. Триггер ни с чем не связан, ни с правилами, ни с шаблонами, ни с хостами, связность есть только у элементов данных, а триггер это "формула", которая использует какие то элемента данных. Ты запросто можешь создать триггер который использует элементы данных из разных шаблонов и разных правил LLD, и такой триггер у тебя отобразится во всех правилах и всех шаблонах, элементы данных которых ты использовал в выражении.

Единственный нормальный способ это элемент данных Level.

[tuban]

Всем привет. Такой вопрос:
Если, с помощью данного скрипта я буду передавать скорость интерфейса в макрос, например #ifspeed, как можно написать триггер используя данное значение?

Сейчас я снимаю эти данные через отдельный элемент данных, но мне кажется можно и по другому? Или нет?

[Firm]

В 3-ей версии реализованы шаблоны для Applications.