Забавно. Я бы сказал, что нет, неправильно. ) Это он их кеша достаёт получается?

а там точно dependent item а не calculated?

Конечно

Это будет использоваться для эскалации. Почитайте документацию. Если step 0 то этот параметр игнорируется

Скорее раз в 5 минут берет last() в родительском

У меня вообще зреет bastpractice вешать на родительские nodata() триггер. :)

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

Видимо, мастер-айтем не совсем перестал получать данные, раз зависимые формируются, хоть и пустые. Проверил в варианте, когда мастер перестал получать данные вообще (trapper), зависимый с хартбитом ничего не генерит

Подскажите пожалуйста нормальную статью о прикручивании уведомлений от Zabbix в Телеграмм. Какой то мусор сплошной.

Спасибо!

так я не про историю, я про то, что в мастер айтем не пришли данные. история там не хранить это как раз еще один bestpractice 🙂

Нет истории - нет и триггера. Но можно сделать зависимый айтем, получающий, скажем, 1 каждый раз, когда мастер-айтем получил данные. Аналог agent.ping, и на него триггер с nodata

все, понял. спасибо

Всем привет! В этот четверг 17 сентября, совместно с Softline, я буду проводить вебинар по Grafana. Рассмотрим такие темы как observability, MTTR vs MTBF, а также я сделаю небольшое демо Metrics/Logs/Tracing где покажу, как с помощью Grafana можно эффективно искать корреляции между метриками (Prometheus), логами (Loki) и трейсами (Jaeger). Вебинар бесплатный, требуется предварительная регистрация. https://softline.ru/events/web_2020_grafana_200917

Есть группа хостов Hypervisors, в ней items:
vpoller["host.perf.metric.get", "{$VSPHERE.HOST}", "{HOST.NAME}", "value", "", "", "", "datastore.totalReadLatency.millisecond.average", "<uuid>", ""],
где uuid заполняется из discovery.

Есть группа хостов Datastores, у которых есть aggregate item, где нужно посчитать среднее из этих items из Hypervisors для каждого uuid выше, при это uuid для каждого хоста подставляется из {HOST.HOST}:

grpavg["Hypervisors","{$HYPERVISOR_DATASTORE_READ_LATENCY}",last]

(в макрос я запихал ключ item выше)

Загвоздка в том что в этом ключе часть макросов не должна раскрываться ({HOST.NAME}, {$VSPHERE.HOST}), а {HOST.HOST} на месте uuid - должен.

Как оформить такой aggregate?

Не уверен, что осознал задачу, но предполагаю, что она связана с агрегированием айтемов, ключи которых оказываются уникальными после раскрытия макросов типа {HOST.HOST}. Простейший пример: в шаблоне icmpping[{HOST.IP}], после раскрытия макроса на хостах - все ключи различны и не агрегируются. Решение -  сделать в шаблоне зависимый айтем, например, icmp.ping, дублирующий основной, и агрегировать его. Полагаю,  и тут можно пойти подобным путем.

идея с dependent сработала, спасибо!

Зарегался, но попасть не смогу - киньте пожалуйста куда нибудь запись

Я не из Софтлайна, записывать тоже не буду, сорри.