переполнение целочисленного значения?

[pupkin.ivan]

Пытаюсь мониторить принтера Brother и он выдаёт для криво перезаправленных картриджей значение 18446744073709551616 в счётчике тонера (Числовой (целое положительное)). И на этом значении не работают все функции: diff, change, <, > и т.д.

Непрерывно поступает значение 18446744073709551616.
Срабатывает триггер: "Картридж был заменён (last: {ITEM.VALUE1}, prev: {ITEM.VALUE2}, diff: {ITEM.VALUE3})"

Определён как: "({Template Printer MFP Brother:toner_current.last(#1)}>{Template Printer MFP Brother:toner_current.last(#2)})&({Template Printer MFP Brother:toner_current.diff(0)}=1)"

При этом выражения {ITEM.VALUEnn} с сработавшем триггере разворачиваются в "Картридж был заменён (last: 18446744073709551616, prev: 18446744073709551616, diff: 18446744073709551616)"

Попытки явно отсечь это значение в триггере или обыграть ситуацию (>0 & <10000000) тоже проваливаются.

Есть идеи, что делать?

[Zentarim]

http://dev.mysql.com/doc/refman/5.0/...ger-types.html

Вы такое значение даже в базу записать не сможете.

Кстати, а какое значение вы наблюдаете в "последних данных" по этом элементу?

[pupkin.ivan]

"- суслика видишь?
- нет.
- а он есть!"

Я эти цифры взял из веб-интерфейса заббикса, а он всё берёт из базы данных mysql. Такое же значение в последних данных. Что и как он внутри себя преобразует -- тайна, доступная лишь избранным, на внимание коих и уповаю

[Zentarim]

Если вы такие числа в данных наблюдаете, а в триггерах оно не работает - то вам лучше сразу на багтрекер писать.

Вы, конечно, можете сами посмотреть, какие значения может обработать сервер... Однако мне кажется, что вы бы в таком случае на форуме не отписывались

[filipp.sudanov]

Если есть подозрение, что значение искажается при записи в базу, можно попробвать поменять тип хранения на character и посмотреть что тогда будет в "последних данных"

[Zentarim]

Если есть подозрение, что значение искажается при записи в базу, можно попробвать поменять тип хранения на character и посмотреть что тогда будет в "последних данных"

Если я правильно понял - значение в базу каким-то образом попало, но триггер по нему не срабатывает.

У меня складывается ощущение, что элемент данных вообще текстовый, хотя автор утверждает, что это не так.

[Jimson]

Я эти цифры взял из веб-интерфейса заббикса, а он всё берёт из базы данных mysql.

Может таки посмотреть что выдает непосредственно элемент данных?
Это snmp или что?

[pupkin.ivan]

Это SNMP и в ответ приходит -3:
Printer-MIB:rtMarkerSuppliesLevel.1.1 = INTEGER: -3
Элемент заведён именно как целое положительное.
В базу кладётся именно что 18446744073709551613


select from_unixtime(clock), value, ns from history_uint where itemid=80020 order by clock desc limit 5;

2014-08-12 09:18:58 18446744073709551613 483118039
2014-08-12 06:13:40 18446744073709551613 36284807
2014-08-12 05:51:13 18446744073709551613 728631166
2014-08-12 01:18:58 18446744073709551613 738666233
2014-08-11 21:18:58 18446744073709551613 745059866

Таблица в базе такова:
CREATE TABLE IF NOT EXISTS `zabbix`.`history_uint` (
`itemid` BIGINT(20) UNSIGNED NOT NULL,
`clock` INT(11) NOT NULL DEFAULT '0',
`value` BIGINT(20) UNSIGNED NOT NULL DEFAULT '0',
`ns` INT(11) NOT NULL DEFAULT '0',
INDEX `history_uint_1` (`itemid` ASC, `clock` ASC))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8)

версия mysql 5.6, ubuntu 12.04.

[pupkin.ivan]

в качестве обходного решения можно перейти на float, но баг остаётся багом: для данного типа значений механизм оценки значений триггеров сбоит при любой операции.

[filipp.sudanov]

А что сбоит, если перейти на float?

[pupkin.ivan]

ничего, кроме того что внезапно нашёлся баг в оценщике триггеров, который не смог прожевать значение из базы и узнать об этом я смог только наткнувшись на постоянно горящий триггер. Я уже перевёл на float и потерял старую динамику, хотя её можно перетащить ручками из таблицы в таблицу.

[filipp.sudanov]

Нашлось в баг треккере: https://support.zabbix.com/browse/ZBX-1274

[Jimson]

Народ поясните тупому в чем заключается баг.
У вас есть SNMP данные типа INTEGER, по спецификации это signed integer, вы засунули эти данные в unsigned int64 и получили кашу. Бага то в чем заключается?

[aib]

Бага заключается в том, что спецификация не совсем верно поддерживается производителями принтера.

Вместо возвращения целого положительного числа - как положено по спецификации - они возвращают "Отрицательное целое число" (чтобы показать, что картридж перезаправлен пиратским способом, например)

И это вражеское действие ломает логику доверчивого Zabbix Server'a, который строго следует спецификациям и не проверят входные данные.

[Jimson]

Бага заключается в том, что спецификация не совсем верно поддерживается производителями принтера.

Вместо возвращения целого положительного числа - как положено по спецификации - они возвращают "Отрицательное целое число" (чтобы показать, что картридж перезаправлен пиратским способом, например)

И это вражеское действие ломает логику доверчивого Zabbix Server'a, который строго следует спецификациям и не проверят входные данные.

Нет, на сколько я вижу и знаю все не так. Во первых SNMP агент принтера честно отдает тип, из сообщения выше:

Это SNMP и в ответ приходит -3:
Printer-MIB:rtMarkerSuppliesLevel.1.1 = INTEGER: -3

INTEGER это signed int

Во вторых Zabbix никогда не проверял тип возвращаемый SNMP, он просто пытается преобразовать то что получил от агента к типу элемента данных. Zabbix совершенно замечательно сохраняет полученные STRING в int64 или float, INTEGER в float и т.п.

Автор задал тип элемента данных целочисленный и получил переполнение. Мне не понятно в чем "бага" и про что приведенный выше ZBX.