Мониторинг реестра РКН

[evs]

Теперь понятно, в чем отличие. В домене. Значит, нужно 2 LLD макроса в ключе прототипа - ip и домен.

А можно поточнее, как именно создавать итем и какого типа с какими ключами, на примерах? Хорошо бы было, чтоб данные у итема брались из макросов LLD, а не запрашивались заново: по сути-то всё, что нужно для триггера проблемы уже в дискавери приходит.

[Semiadmin]

Тогда вернемся к вопросу: откуда предполагается брать список ip хоста? Дискаверить? Читать подготовленный вручную список?

[evs]

Тогда вернемся к вопросу: откуда предполагается брать список ip хоста? Дискаверить? Читать подготовленный вручную список?

Читать подготовленный список с каждого хоста

[Semiadmin]

Тут возможны варианты, надо смотреть и на производительность, т.к. препроцессинг файла в 5M - дело нелегкое. Я бы, наверное, попробовал загнать список ip в user macro хоста (не хватит 255 символов - склеить из нескольких oser macros), в js-препроцессинге отфильтровать из выгрузки только нужные ip с соответствующими доменами, получить на выходе отфильтрованный json и в зависимом LLD сделать LLD macros {#IP} и {#DOMAIN}. И прототип зависимого айтема, получающего для каждой пары ip-домен из очередной выгрузки через JSONPath или длину найденного массива, т.е. 1 (запись есть), или ошибку, для которой можно через Custom on fail вернуть 0 (записи уже нет).

[evs]

Тут возможны варианты, надо смотреть и на производительность, т.к. препроцессинг файла в 5M - дело нелегкое. Я бы, наверное, попробовал загнать список ip в user macro хоста (не хватит 255 символов - склеить из нескольких oser macros), в js-препроцессинге отфильтровать из выгрузки только нужные ip с соответствующими доменами, получить на выходе отфильтрованный json и в зависимом LLD сделать LLD macros {#IP} и {#DOMAIN}. И прототип зависимого айтема, получающего для каждой пары ip-домен из очередной выгрузки через JSONPath или длину найденного массива, т.е. 1 (запись есть), или ошибку, для которой можно через Custom on fail вернуть 0 (записи уже нет).

Вот из-за того, что парсить такое постоянно заббиксом довольно затратная задача, я подумал, что лучше будет, если этим будут заниматься сами хосты. Сейчас у меня уже есть юзерскрипт, который попросту грепит из файла выгрузки строки в которых содержатся собственные IP адреса, в итоге получаем, что уже на этапе дискаверинга в заббикс от заббикс агента приходят все нужные данные по каждому хосту (т.е. каждый сервер отдает короткий список записей, которые относятся только к нему самому или же OK в случае, если записей вообще не обнаружено). Осталось понять как правильно создать айтемы, вот на этом этапе и появляется непонимание: какой должен быть тип создаваемого прототипа, его ключ и как именно из макросов LLD передавать данные в сами айтемы. Я не очень понял зачем загонять список IP в макро и каким образом делается js-препроцессиннг в заббиксе. Проще говоря, заббикс агент отдаёт по ключу юзерскрипта текстовое содержимое, как в примерах с Телеграмом выше, и что мне теперь с ними делать? В LLD они загоняются по этому ключу, но айтемы создать не понимаю как.

[Semiadmin]

Если агент уже отдает в айтем фильтрованный JSON, то дальше можно сделать так.
Создаем зависимое от этого айтема LLD rule, в препроцессинге Discard unchanged with heartbeat, чтоб не пересчитывалось без надобности, в LLD macros - 2 макроса:
{#IP} $.['1']
{#DOMAIN} $.['2']
Прототип зависимого айтема:
record[{#IP},{#DOMAIN}] , тип Numeric (unsigned), в препроцессинге JSONPath $.[?(@.['1']=="{#IP}" && @.['2']=="{#DOMAIN}")].['5'].length()
Для надежности можно добавить Custom on fail, Set value to 0.
Прототип триггера по вкусу.