именно

в influx они должны попасть как значения осмысленных тегов

поэтому до того как данные попадут в influx - должен отработать особый методо сбора нужной инфы, к какому объекту привязать данный метод выбирается на уровно шаблона, а какой шабон использовать для этого объекта можно определить по oid железки

или смысла не будет

"особый метод сбора" в терминах NOC называется "discovery"

:)

нет, скорее профиль

discovery - это общее понятие

которое обозначет процесс сбора черти-чего с черти-чего

:)

по логике вещей в box discovery должен быть какой-то метод

который возьмет все метрики, которые мы хотим получить с железки

сейчас, просто, не понятно, как написать свой discovery для метрик не очень бы, хотелось, править код НОКа для этого, а просто дописать своё

пройдется по железке и выдаст какие-то хинты

у каждого продукта есть свой системид

сейчас у нас ifindex'ы так передаются в get_metrics

vendor oid

@akubatkin в ноке и так понятно кто вендор. Для этого в MO есть профили

и скрипты пишутся жёстко под вендора

эти oid'ы жестко забиты в скриптах

на скриншоте - описание какие методы сбора ip/mac применять к конкретной модели коммутатора, это плагин мактрак в какти

кстати, как вариант -- в caps discovery выносить

и пусть он и capabitity выдает, и отображения

в NOC'е проще

хочешь mac - дергай get_mac_address_table

остальное уже - не твое дело :)

caps будет возвращать scope? а кто будет hints формировать?

ну вот надо подумать

или будет привязка scope <-> discovery script?

по логике вещей с твоими политиками - он должен просечь, что они есть вообще

и выдернуть mapping'и

ну да

теоретически эти mapping'и можно вернуть как capability

и там же и хранить

ну или возвращать как capability, но хранить отдельно

теоритически да... но всяких разные табличек в SNMP гора целая

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

не хотелось бы всё сосредотачивать в caps

caps - это централизованный механизм

эти data query - это как раз прослойки перед стандартным хранением инфы

который показывает, что есть на железке

да

и caps'ы передаются в каждый скрипт

по логике вещей mapping'и всякие -- там же могут собираться

другое дело, что хранить их стоит отдельно

ну, основная проблема это хранение

и привязка его к скрипту

да ну ладно, какая это проблема?

делаем коллекцию ObjectMappings

в плане что сейчас это не хранится нигде:)

и спокойно сохраняем там

и через scope передаём в get_metrics, а в нём пишем метод, дополняющий словарь SNMP_OIDS ?

можно и шаблоны в словаре сделать

кстати, также можно шаблоны реализовать, создать коллекцию шаблонов. И сделать привязку scope <-> шаблон

шаблоны oid'ов

в плане .1.2.3.4.5.6.{X}.{Y} ?

1.2.3.4.5.{{ mappings.policy.get("x") }}

пока внедрял в какти шаблоны для сбора инфы с ssr - наткнулся на то, индекс oid может быть и не повторяющимся, а string в hex :)

например так были зашифрованы названия процессов

имена

@akubatkin это можно в скрипте разрулить

для этого в xml-шаблоне какти надо было делать типа такого <name>Get rbnCpuProcTable Information</name> <description>Get SNMP based cpu process information from the RBN-CPU-METER-MIB::rbnCpuProcTable</description> <index_order>rbnCpuProcName</index_order> <oid_index>.1.3.6.1.4.1.2352.2.6.3.1.1.1</oid_index> <oid_index_parse>OID/REGEXP:^.{29}(.*)</oid_index_parse> т.е. oid - 29символов, а остальное будет считаться индексом

http://docs.cacti.net/howto:data_query_templates#snmp_index_is_present - как в какти разруливаются нестандартные ситуации с индексами

1) отрабатывает get_capabilities - он проверяет что данные имеет смысл собираить, возвращает список scope 2) в базу пишутся в коллекцию ObjectMappings 3) на основании поля Scope в Metric Type мы передаём в get_metric необходимые scope 4) get_metrics отрабатывает и возвращает данные Требования 1. Надо дописать get_capabilities 2. Необходимо где-то хранить шаблоны, можно сделать, как остальные коллекции

пока я не понял вопрос с mapping'ами... у нас caps не разрасётся их собирать?

или это можно вынести в отдельную структуру?

пусть спросит vendor oid и затем по нему уже узнает, что еще надо опросить

Vendor oid у нас и так есть:) когда заводится MO ему он назначается

все скрипты пишутся под конкретного вендора сразу

:) а ведь mo может автозаводиться по vendor oid :)

т.е. он у нас есть

раз оно по нему автозавелось

у нас выбор профиля работает, в том числе, и по oid

я что-то пропустил или в микросервисах работает автодискавери mo? т.е. не надо заводить mo? пропингуется, опросится и сам заведется с нужными профилями?

@akubatkin да, работает такое

и если железка поменяет личину - это отработается

автоматически

эту гуд, не знал, когда тестировал на старом - этого вроде бы не было

появилось в микросервисах

можешь написать статью:)

как сломаю себе голову, как в продакшн поставить башню на сервер с другими сервисами, так обязательно эту тему изучу

@dvolodin 1) отрабатывает get_capabilities - он проверяет что данные имеет смысл собираить, возвращает список scope, пригодных для сбора 2) они пишутся в коллекцию ObjectMappings 3) на основании поля Scope в Metric Type мы передаём в get_metric необходимые scope 4) get_metrics отрабатывает и возвращает данные Требования 1. Надо дописать get_capabilities 2. Необходимо где-то хранить шаблоны, можно сделать, как остальные коллекции пока я не понял вопрос с mapping'ами... у нас caps не разрасётся их собирать? или это можно вынести в отдельную структуру?

:) и про это тоже напиши)))))

"NOC. Как сломать себе голову"

mapping'и в отдельную структуру

Шаблоны, у нас будут в get_metrics обитать?

наверное

там им и место

ну... по сути да

у нас get_metric как коллекция шаблонов получается:)

:) в какти есть graph_templates,data_templates,host_templates, помио data_query и data_input_method :)

шаблоны кругом, задачи разные

как раз как было до микросервисов в НОКе

там не только шаблоны, но и логика

шаблоны - один из способов получить результат

второй способ писать свой скрипт)

ну, фактически, шаблоны -- это некий DSL