Вычисляемое значение на основе итемов LLD

[Aleksandrs]

Добрый день.
Есть дефолтный LLD шаблон для снятие инфы с сетевых устройств. В нем есть прототим элементов данных, например: Incoming traffic on interface {#SNMPVALUE} с ключем ifInOctets[{#SNMPVALUE}] - и так на все найденные порты.
Подскажите как сделать вычисляемый элемент данных, который показывал сумму входящего траффика на всех портах?
P.S. Макрос: {#SNMPVALUE} совпадает с eth*

[Aleksandrs]

хотел добавить, что одним из решением вопроса является вычисляемый итем с формулой: last("ifInOctets[eth0]")+last("ifInOctets[eth1]")+last("ifInOctets[eth2]") и т.д.
А как сделать его под шаблон, чтобы вычисляемое значение считал все значения, совпадающие с ключем ifInOctets[eth*] ?

[Igor24]

меня такой же вопрос интересует.

[Dmitriy Pimkin]

Сталкивался с такой задачей и не найдя приемлемого решения реализовал через ODBC.
Главное ограничить глубину, на которую запрос лезет в историю и на партиционированной базе вполне нормально работает.

[Igor24]

Dmitriy, если не затруднит, а можно по-подробнее?

[Semiadmin]

Если требуется только графическое представление этой суммы, то можно воспользоваться Графаной, там есть возможность просуммировать отобранные регуляркой графики.
Если сумма нужна в Zabbix'е, то в 4.2 возможен такой трюк. Делаете текстовый айтем, у которого SNMP OID выглядит как у LLD, т.е. начинается со слова discovery. В него должен попасть JSON с требуемыми значениями трафика. Потом в препроцессинге через JS суммируете нужное.

[Dmitriy Pimkin]

Пишем SQL запрос, который выбирает из таблицы history_uint последние значения элементов данных, у которых items.key_ like 'ifInOctets[%' and hosts.host ='{HOST.HOST}' and history_uint.clock > (текущее время минус небольшой интервал, перекрывающий несколько интервалов обновления ifInOctets, я брал 5-10 минут)
и суммирует их.
Можно добавить проверки на то, что элемент данных включен, не сломан, хост не в майнтенансе и тп,

Создаем элемент данных с типом Database monitor и заносим туда этот запрос.

Главное суммировать не все возвращенные значения, а как то их отсортировать и взять последние по каждому ключу, например в постгресе нам поможет http://www.postgresqltutorial.com/po...ql-row_number/
что то типа добавляем в выборку поле

row_number() over (partition by history_uint.itemid order by history_uint.clock desc) as rn​​​​​​​

и потом выбираем

select sum(sumtable.value) as inOctetsSum from (наш запрос) sumtable where subtable.rn = 1;​​​​​​​

[Dmitriy Pimkin]

Если требуется только графическое представление этой суммы, то можно воспользоваться Графаной, там есть возможность просуммировать отобранные регуляркой графики.
Если сумма нужна в Zabbix'е, то в 4.2 возможен такой трюк. Делаете текстовый айтем, у которого SNMP OID выглядит как у LLD, т.е. начинается со слова discovery. В него должен попасть JSON с требуемыми значениями трафика. Потом в препроцессинге через JS суммируете нужное.

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

JSON с требуемыми значениями трафика

А то может я упустил в изысканиях своих какой нибудь хитрый функционал.

[Semiadmin]

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

А то может я упустил в изысканиях своих какой нибудь хитрый функционал.

JSON формирует SNMP LLD, которое надо натравить на правильный OID (MIB), или даже несколько. Только в нашем случае результат действия SNMP LLD будет получать текстовый айтем. Кстати, прототип айтема для трафика по отдельным интерфейсам можно в этом случае переделать на зависимый и получать из того же JSON, чтобы меньше сетевое устройство дергать.

[Dmitriy Pimkin]

JSON формирует SNMP LLD, которое надо натравить на правильный OID (MIB), или даже несколько. Только в нашем случае результат действия SNMP LLD будет получать текстовый айтем. Кстати, прототип айтема для трафика по отдельным интерфейсам можно в этом случае переделать на зависимый и получать из того же JSON, чтобы меньше сетевое устройство дергать.

ок, получили вы JSON с значениями каунтеров на интерфейсах, но это не значения трафика, разве из JS в препроцессинге можно получить доступ к предыдущему значению элемента данных?

[Semiadmin]

ок, получили вы JSON с значениями каунтеров на интерфейсах, но это не значения трафика, разве из JS в препроцессинге можно получить доступ к предыдущему значению элемента данных?

Думаю, можно применить change per second к полученной сумме, следующим шагом препроцессинга.

[Dmitriy Pimkin]

Думаю, можно применить change per second к полученной сумме, следующим шагом препроцессинга.

Не хотелось бы разочаровывать, но думаете вы неправильно, counter имеет свойство переполнятся и сбрасываться на ноль. И если при применении change per second к одиночному счетчику это учитывается, то к сумме это применять бесполезно.
Надеюсь не надо объяснять почему.

[Semiadmin]

Не хотелось бы разочаровывать, но думаете вы неправильно, counter имеет свойство переполнятся и сбрасываться на ноль. И если при применении change per second к одиночному счетчику это учитывается, то к сумме это применять бесполезно.
Надеюсь не надо объяснять почему.

Ну, значит, в этом случае способ не сработает.

[Dmitriy Pimkin]

Ну, значит, в этом случае способ не сработает.

увы, да.

но вот за трюк:

Делаете текстовый айтем, у которого SNMP OID выглядит как у LLD, т.е. начинается со слова discovery.

все равно спасибо, это позволит мне в паре мест обойтись без внешних скриптов, надо только JS подучить.