2.2.0 items.lastvalue

[novoselov.ai]

В табличке items было удобное поле lastvalue и items.prevvalue
Всегда легко было получить последнее значение запросом. Убрали...
Как теперь получать? Ктото уже разобрался?

БД Postgresql

[noname]

Я включил отладку в веб-интерфейсе и в моем случае (база данных MariaDB) :
(SELECT * FROM history_uint h WHERE h.itemid='150461' ORDER BY h.clock DESC LIMIT 2 OFFSET 0);

[novoselov.ai]

Я включил отладку в веб-интерфейсе и в моем случае (база данных MariaDB) :
(SELECT * FROM history_uint h WHERE h.itemid='150461' ORDER BY h.clock DESC LIMIT 2 OFFSET 0);

Всё правильно, но у меня было чтото такое

SELECT
(CAST(items.lastvalue as bigint)+CAST(items.prevvalue as bigint))/2/1024/1024 as inx, hosts.snmp_available
FROM
items,hosts,interface
WHERE
items.hostid=hosts.hostid and interface.ip='$dstart' and items.key_ = 'ifHCOutOctets.$dstartport' and interface.hostid = hosts.hostid limit 1

тоесть по двум параметрам - ип устройства и номеру порта - получалось последнее и предпоследнее значение загруски канала (точнее их сумма/2/1024/1024).

$dstart
$dstartport

кроме того сейчас придется еще и выбирать из какой таблицы с историей выковыривать данные...

[noname]

Ну если речь идет об ifHC(In|Out)Octets, то history_uint. Я тоже делал одним запросом, теперь придется получать дополнительно пары ключ-значение из history_uint.

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

P.S. вот тут посмотри:

https://www.zabbix.com/documentation/2.2/manual/api/reference/history/get

[Jimson]

Проблема API в том что у вас появляется неимоверно жирная прослойка httpd+php которая по мимо прочего сделает еще с десяток дополнительных обращений к базе/кэшу для проверки прав и верификации данных. При написании различных frontend расширений или генераторов отчетов это не страшно и даже полезно, но если люди дописывают специфический функционал, то накладные расходы надо минимизировать и как следствие или надо патчить сишный код сервера и добавлять нужные фичи туда или писать костыль, который будет делать то что нужно читая и записывая данные напрямую в бд.

Чисто теоритически (мне не нужно было никогда лазить в базы за lastvalue) то что это поле удрали правильно, надо хотя бы пытаться привести схему к 3NF, а эти поля явно нужны были только для ускорения расчета дельт и вычисления функции last(0). С другой стороны выборка последнего значения из history_* с использованием сортировки и при этом все равно надо выбрать itemid из items явно дает значительную дополнительную нагрузку на БД, а значит расчет на более эфективную работу собственного zabbix кэша. Хз, видимо тестили и раз заявляют что производительность 2.2 стала выше, то видимо проблему решили. А вот костылям прийдется обломаться, если данные по нужным им элементам данных попадают в базу мимо этих костылей, т.е. нет возможности реализовать свой кэш.

[zalex_ua]

.... Хз, видимо тестили и раз заявляют что производительность 2.2 стала выше, то видимо проблему решили.

Именно, в 2.2 ушли полностью от частых апдейтов таблицы items, а это была большая проблема на больших инсталляциях.

[noname]

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

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

P.S. А вот скрипты с использованием API, где не было необходимости в очень быстрых запросах работают до сих пор

[Jimson]

Именно, в 2.2 ушли полностью от частых апдейтов таблицы items, а это была большая проблема на больших инсталляциях.

сорри за лень
а как решили проблемы расчета дельт? ведь она считалась по lastvalue, а в history сохраняется дельта, а не последнее значение каунтера