SS
но мне надо все, а не только 2
Size: a a a
2020 March 16
AG
тогда метрика должна получать значение конкретного типа трафика, и так по каждому порту
SS
это понятно
AG
но мне надо все, а не только 2
делайте метрики столько метрик, сколько нужно, в чем проблема ?
SS
их оч много
SS
ну и к тому же, на одном интерфейсе он есть, а на другом интерфейсе его нет
AG
их оч много
с ходу и не придумать ничего, найти mib файл и в нем посмотреть структуру, вдруг можно будет забрать из другой ветки SNMPINDEX тех самых "типов трафиков"
SS
ну программку писать для sender...
s
их оч много
т.е. вы не знаете точный набор нужных вам метрик изначально?
SS
могу вытащить
AG
т.е. вы не знаете точный набор нужных вам метрик изначально?
я так понял набор может меняться, на одном порту он может быть, на другом порту метрики может не быть
AG
их оч много
у меня есть правило для сбора метрик, на каких то портах нет нужных данных, ну ничего страшного, на хосте создаются метрики, которые не содержат никаких данных, а порты с поддержкой сбора метрики возвращают нужные значения
AG
просто я еще не встречал такой структуры oid веток, что бы в oid номер порта был не последним 😞
SS
1109 параметра трафика :)
AG
1109 параметра трафика :)
зачем так много то о_О ?
s
могу вытащить
ну вот если у вас есть список oid нужных метрик, их наименования, то делайте lld вида
discovery[{#CNPDSTATUS}, 1.3.6.1.4.1.9.9.244.1.1.1.1.1]
filter {#CNPDSTATUS}=1
и прототипы на каждую метрику с oid 1.3.6.1.....{SNMPINDEX}.блабла
discovery[{#CNPDSTATUS}, 1.3.6.1.4.1.9.9.244.1.1.1.1.1]
filter {#CNPDSTATUS}=1
и прототипы на каждую метрику с oid 1.3.6.1.....{SNMPINDEX}.блабла
AG
это прям реально все необходимо для анализа и мониторинга ?
SS
этого я не знаю, хочется какой-то baseline собрать за неделю например или месяц
AG
этого я не знаю, хочется какой-то baseline собрать за неделю например или месяц
ну странно, мне лично сетевики говорили что им нужно, аля трафик на порту, ddm, ppx и прочее
AG
я уже писал правила из конкретных нужд