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

[evs]

Коллеги, а подскажите правильный подход для решения задачи.
Есть выгрузка из реестра РКН в CSV формате по адресу https://github.com/zapret-info/z-i
Нужно чтобы серверы, IP которых в их интерфейсах присутствуют в этой базе создавали в заббиксе проблемы, при чем отдельные проблемы по каждой из записей (их может быть несколько для одного IP адреса). В качестве оперативных данных думаю нужно чтобы использовалось что-то вроде IP-адрес на интерфейсе:заблокированный домен или домены.

С какой стороны подойти к решению этой задачи и какие инструменты лучше использовать?

[wins]

т.е. у вас есть ip (или днс?) записи в мониторинге, и вы хотите мониторить попадание этих записей в реестр ркн?

[evs]

Да, IP адреса попадают в реестр, и по каждой записи нужно чтоб создавалась отдельная проблема, висящая до тех пор, пока запись не исчезнет из CSV-файла. Привязка, соответственно, к тому хосту, на котором имеется поднятый сетевой интерфейс с IP адресом, находящимся в реестре.

[Semiadmin]

Предположим, у вас уже есть LLD rule, получающее ip-адреса сетевых интерфейсов хоста. Тогда остается сделать в нем прототип айтема с типом http agent, который будет считывать список РКН и в препроцессинге проверять наличие в списке своего ip, возвращая 0 или 1. Или количество записей. Если же нужно детально разбираться с каждой записью, то это уже внешними скриптами, ибо получаются вложенные LLD - LLD ip-адресов и LLD записей для каждого адреса.

[evs]

comment deleted

[evs]

Да, нужно именно разбираться с каждой записью. Нет возможности как-то триггерить сразу несколько проблем, если в данных несколько строк или по json?
Или же думаю, если юзерскриптами на каждом сервере таскать данные и из них оставлять только те строки, которые относятся к локальным интерфейсам, то как правильнее сами записи заводить, через LLD по каждой из записи? То есть, фактически, каждый сервер может отдавать CSV с теми записями, которые касаются его самого.

[Semiadmin]

Надо понять, как именно вы хотите разбираться с каждой записью. Можно, например, по результатам каждой проверки делать 2 прототипа зависимых айтемов - количество найденных записей и их список. Сделать триггер на изменение количества и использовать список для анализа. Если же дискаверить каждую запись, то вопрос - как находятся сами ip интерфейсов, через LLD? Вложенные LLD Zabbix пока не поддерживает, хотя внешними скриптами это решается.

[evs]

Надо понять, как именно вы хотите разбираться с каждой записью. Можно, например, по результатам каждой проверки делать 2 прототипа зависимых айтемов - количество найденных записей и их список. Сделать триггер на изменение количества и использовать список для анализа. Если же дискаверить каждую запись, то вопрос - как находятся сами ip интерфейсов, через LLD? Вложенные LLD Zabbix пока не поддерживает, хотя внешними скриптами это решается.

IP адреса не интерфейсов пока вообще дискаверятся, а вот работать с нужно именно с каждой записью отдельно. Поэтому я и думаю, может проще отдавать уже готовый список, который будет скриптом на самом сервере отрабатываться исходя из тех интерфейсов, которые на нём имеются? Я просто не очень понимаю как можно из айтема, который в себе содержит несколько записей, триггерить несколько независимых друг от друга проблем по каждой из записей: часть из них будут в состоянии Acknowledged, часть должны постоянно отслеживаться до тех пор, пока запись не исчезнет.

[Semiadmin]

Вот это знание об имеющихся на каждом сервере интерфейсах - оно как приобретается?

[evs]

Вот это знание об имеющихся на каждом сервере интерфейсах - оно как приобретается?

Юзерскрипт сам парсит конфигурацию интерфейсов на сервере и в переменные этого скрипта складывает массивом, как-то вот так.

[Semiadmin]

Т.е. они дискаверятся скриптом. Тогда можно добавить в скрипт парсинг выгрузки РКН, получая в результате прототип айтема с ключом вроде key[{#IP},{#RECORD}]. Для каждой записи создастся свой айтем и триггер.

[evs]

Т.е. они дискаверятся скриптом. Тогда можно добавить в скрипт парсинг выгрузки РКН, получая в результате прототип айтема с ключом вроде key[{#IP},{#RECORD}]. Для каждой записи создастся свой айтем и триггер.

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

[evs]

Т.е. они дискаверятся скриптом. Тогда можно добавить в скрипт парсинг выгрузки РКН, получая в результате прототип айтема с ключом вроде key[{#IP},{#RECORD}]. Для каждой записи создастся свой айтем и триггер.

Не очень понятно как должен выглядеть прототим айтема и какой у него тип. По идее само наличие задискаверенных записей уже нужно триггерить в проблему, а данные брать из макросов. Как это сделать на примере айтема? Сами записи прекрасно дискаверятся, получая в итоге с каждого сервера JSON со списком IP адресов и связанных с ними доменов в реестре, вроде такого:

[{
"1": "149.154.167.220",
"2": "api.telegram.org",
"3": "",
"4": "Таганский районный суд г. Москвы",
"5": "2-1779/2018",
"6": "2018-04-13"
}, {
"1": "149.154.167.99",
"2": "core.telegram.org",
"3": "",
"4": "Таганский районный суд г. Москвы",
"5": "2-1779/2018",
"6": "2018-04-13"
}
]

[Semiadmin]

Тут все просто, а вот как выглядят "несколько записей для одного ip-адреса"?

[evs]

Тут все просто, а вот как выглядят "несколько записей для одного ip-адреса"?

Да также:

149.154.167.99;t.me;;Таганский районный суд г. Москвы;2-1779/2018;2018-04-13
149.154.167.99;core.telegram.org;;Таганский районный суд г. Москвы;2-1779/2018;2018-04-13
149.154.167.99;desktop.telegram.org;;Таганский районный суд г. Москвы;2-1779/2018;2018-04-13

После CSV to JSON:

[{
"1": "149.154.167.99",
"2": "t.me",
"3": "",
"4": "Таганский районный суд г. Москвы",
"5": "2-1779/2018",
"6": "2018-04-13"
}, {
"1": "149.154.167.99",
"2": "core.telegram.org",
"3": "",
"4": "Таганский районный суд г. Москвы",
"5": "2-1779/2018",
"6": "2018-04-13"
}, {
"1": "149.154.167.99",
"2": "desktop.telegram.org",
"3": "",
"4": "Таганский районный суд г. Москвы",
"5": "2-1779/2018",
"6": "2018-04-13"
}
]

[Semiadmin]

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