Лучше — date.

Не лучше, ибо без необходимости меняет условие пересчета триггера

Чиво?

ну триггер начнет пересчитываться не только при получении данных, а еще и каждые 30с, а оно надо?

Уверен?

конечно, это ж временнАя функция

что-то оно у меня так не сработало. или я не понял.
делал, правда, на тестовом элементе, который создавал руками, без LLD, не знаю важно ли это.

в описание элемента с JSON положил нужную строку, в триггере к зависимому элементу добавил фейковое условие (получается элемент №2 в выражении), в описание триггера написал "{ITEM.DESCRIPTION2}"
вызвал событие, на главной странице заббикса макрос не развернулся (т.е. так и написано "{ITEM.DESCRIPTION2}")

Нет такого макроса

поясни, пожалуйста.
я тут https://www.zabbix.com/documentation/current/ru/manual/appendix/macros/supported_by_location его нашёл

В описании триггера нужен макрос {ITEM.VALUE2}

В уведомлении нужен макрос {TRIGGER.DESCRIPTION}

понятно, т.е. в данном случае {ITEM.VALUE2} работает, а как понять - какие ещё работают?
мне от VALUE толку мало - вываливать в уведомление весь JSON будет не красиво.
или может быть есть возможность обработать это VALUE как-либо?
пока вижу только такой вариант:
вернуть в JSON нужную строку,
создать зависимый элемент, получающий эту строку,
создать фейковое условие на него,
и уже его VALUE брать.

но может есть вариант попроще?

{{ITEM.VALUE}.regsub(pattern, output)}

но тут регулярка, а в варианте с зависимым можно JSONPath

Да, мне кажется самым простым вариантом

🌟 Vyacheslav Ryzhevsky has reached level 2!

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

затупил, мне же всё равно её возвращать нужно.
да, тогда зависимый элемент лучше.
@vryzhevsky, @Oleg_Kostikov, спасибо

Добрый день! Н у нас zabbix 4.4. 2000 хостов,50000 элементов данных, 24000 триггеров. zabbix-server живёт на виртуальной машине. БД живёт на отдельной железки с аппаратным рейдом. Работает хусхипер, каждый час чистит историю. Место в БД занимает в районе 26гигов. Стоит задача перенести БД на виртуалку , физически она расположатся будет на том же гипервизоре где сам zabbix-server. Подскажите. Могут ли возникнуть проблемы при такой схеме?

Проблемы могут возникнуть при любой схеме, если вы не умеете "переносить БД на виртуалку".
Здесь тема заббикса проходит по касательной — если бы вместо заббикса был любой другой сервис, то вопросы были бы аналогичные.
Это обычная база данных, не какая-то космическая и необычная.