Главная » Хабрахабр » [Из песочницы] Zabbix — мониторинг OSPF соседей средствами SNMPv3 TRAPs, боль и отчаяние

[Из песочницы] Zabbix — мониторинг OSPF соседей средствами SNMPv3 TRAPs, боль и отчаяние

Техническое задание

Имеется сеть географически разбросанных дата-центров с вагоном VRF и постоянно изменяющимся списком OSPF соседей. Необходимо отслеживать их:

  1. Состояние, делать alarm если состояние соседа не FULL
  2. Количество, то есть если сосед пропал, нужно также делать alarm

Система мониторинга уже есть — Zabbix 3.4, желательно использовать именно её, ОС Linux Debian 9.x

Пробуем с наскока

Протокол распространенный, система мониторинга известная, наверняка я не первый кто хочет решить эту задачу и скорее всего она уже решена.

Счастье то какое — сейчас я его импортирую, причешу под свои нужды и всё будет оки доки.
Проверяем как работает — вроде все хорошо, состояния отслеживаются, но вот когда сосед уходит в состояние DOWN, мы получаем от Zabbix «очень» информативное сообщение Вколачиваем в поиск «zabbix ospf» и первая же ссылка ведет на шаблон.

No Such Instance currently exists at this OID

и инфо

The item is not discovered anymore and will be deleted in 29d 23h 57m (on 2018-08-19 at 08:52)

Что произошло — проблема старая и известная на форумах — когда пропадает OSPF сосед, то все OID, связанные с ним, просто удаляются на сетевом железе.

Да, решение есть — создать триггер nodata, ок создаем:

].nodata(120)}=0

Видим в дашборде:

OSPF neighbor 192.168.192.168 missing data

В принципе… юзабельно

Конечно, это можно порешать с помощью SNMP context, но как-то совсем не захотелось идти таким путем — это надо по всем железкам пройтись, каждому OSPF процессу или VRF вколотить контекст, потом в шаблоне сделать копии Discovery для каждого контекста свою, в целом многовато возни и при добавлении новых OSPF процессов надо в нескольких местах что-то менять. Но из коробки LLD обнаруживает только соседей из default VRF. Есть упоминание о некоем CISCO-CONTEXT-MAPPING-MIB, из которого можно выдернуть все соответствия контекстов и OSPF/VRF, но как эту конструкцию прикрутить к LLD и моему случаю я не сообразил. Можно конечно обложиться скриптами и через Zabbix API всё это менять, но не хотелось особого кастома, а хотелось по максимуму использовать только встроенную в Zabbix функциональность. Если кто-то умеет так круто готовить Zabbix, то добро пожаловать в комментарии, а лучше в полноценную отдельную статью.

Пробуем со второго наскока

После пары часов поисков в интернетах по намекам на форумах и из закромов памяти всплыла тема про SNMP TRAP — это когда не мы опрашиваем железку, а железка сама присылает информацию об изменении чего-либо. Да и походу поддержка этого добра есть в нашей системе мониторинга из коробки, оборудование тоже умеет сразу и как раз для моего случая.

С первых строк документация по мониторилке смутила длинным списком:

The workflow of receiving a trap: 1. snmptrapd receives a trap 2. snmptrapd passes the trap to SNMPTT or calls Perl trap receiver 3. SNMPTT or Perl trap receiver parses, formats and writes the trap to a file 4. Zabbix SNMP trapper reads and parses the trap file 5. For each trap Zabbix finds all “SNMP trapper” items with host interfaces matching the received trap address. Note that only the selected “IP” or “DNS” in host interface is used during the matching. 6. For each found item, the trap is compared to regexp in “snmptrap[regexp]”. The trap is set as the value of all matched items. If no matching item is found and there is an “snmptrap.fallback” item, the trap is set as the value of that. 7. If the trap was not set as the value of any item, Zabbix by default logs the unmatched trap. (This is configured by “Log unmatched SNMP traps” in Administration → General → Other.)

То есть один демон принимает TRAP, передает его другому демону, тот его парсит, кладет в лог с нужным форматом и забикс уже читает лог и принимает решение что делать дальше. Как-то уже выглядит ни разу не проще чем даже руками пройтись и везде нарисовать SNMP context, но да ладно, попробуем. Читаем внимательно доку по мониторилке и понимаем что только с её помощью ничего настроить не получится, вообще есть у Zabbix такой прикол — документация настолько минимально описывает возможности и нюансы системы, что скорее больше запутывает чем учат. Хотя их можно понять — софтина бесплатная, а деньги как-то надо зарабатывать, вот на поддержке и зарабатывают. В интернетах встречаются статьи с описанием как это настроить раз два, но ни по одной статье у меня не получилось настроить от и до, пришлось собирать информацию из разных источников по крупицам. Это всё лирика, погнали делать хардкор.

Настраиваем сетевую железку

Перед тем как что-то крутить на хосте с мониторилкой, настоятельно рекомендую первым делом настроить сетевую железку и убедиться что TRAP реально прилетает от железки на сервер — поначалу я этого не проверил, что выпило много нервов, крови и времени. У меня под рукой вагон Cisco Nexus, так что примеры буду приводить для этой серии. У кого Catalyst, ASR, ASA и прочее — извиняйте, я не солнышко, всех не обогрею, читайте доки как это настроить сами, синтаксис будет похож, но со своими нюансами.

snmp-server contact noc@example.com
snmp-server location Room1
snmp-server source-interface traps loopback1

Важно в дальнейшем при настройке TRAP в Zabbix, чтобы адрес с которого отправляется TRAP был равен адресу SNMP интерфейса в настройках хоста в Zabbix.

snmp-server user Zabbix network-operator auth sha string priv aes-128 string

Используйте 3 версию протокола везде где только можно, в режиме authPriv (шифрование и аутентификация), это не так сложно настроить как кажется. Забудьте про 1 и 2 версии протокола — когда вам прилетит нежданчик по причине отсутствия шифрования и по сути аутентификации в этих версиях протокола — просто вопрос времени (community строка в них передается в открытом виде, более того регулярно вижу что это настроено public/private). Параметр network-operator позволяет дать права юзеру только на чтение.

snmp-server host 192.168.192.168 traps version 3 priv Zabbix
snmp-server host 192.168.192.168 use-vrf default
snmp-server host 192.168.192.168 source-interface loopback1
no snmp-server enable traps ospf lsa
snmp-server enable traps ospf
no snmp-server enable traps entity entity_mib_change
no snmp-server enable traps entity entity_module_status_change
no snmp-server enable traps entity entity_power_status_change
no snmp-server enable traps entity entity_module_inserted
no snmp-server enable traps entity entity_module_removed
no snmp-server enable traps entity entity_unrecognised_module
no snmp-server enable traps entity entity_fan_status_change
no snmp-server enable traps entity entity_power_out_change
no snmp-server enable traps link linkDown
no snmp-server enable traps link linkUp
no snmp-server enable traps link extended-linkDown
no snmp-server enable traps link extended-linkUp
no snmp-server enable traps link cieLinkDown
no snmp-server enable traps link cieLinkUp
no snmp-server enable traps link connUnitPortStatusChange
no snmp-server enable traps bfd session-up
no snmp-server enable traps link delayed-link-state-change
no snmp-server enable traps bfd session-down
no snmp-server enable traps rf redundancy_framework
no snmp-server enable traps license notify-license-expiry
no snmp-server enable traps license notify-no-license-for-feature
no snmp-server enable traps license notify-licensefile-missing
no snmp-server enable traps license notify-license-expiry-warning
no snmp-server enable traps upgrade UpgradeOpNotifyOnCompletion
no snmp-server enable traps upgrade UpgradeJobStatusNotify
no snmp-server enable traps rmon risingAlarm
no snmp-server enable traps rmon fallingAlarm
no snmp-server enable traps rmon hcRisingAlarm
no snmp-server enable traps rmon hcFallingAlarm
no snmp-server enable traps entity entity_sensor
no snmp-server enable traps generic coldStart
no snmp-server enable traps generic warmStart

Я специально отключил все TRAP кроме OSPF, чтобы при диагностике почему что-то не работает, мне не пришлось вычитывать из дебага много лишней информации.

Стартуем снифер на хосте с мониторингом: Как проверить работают ли TRAP — очень просто — надо что-нибудь сломать.

root@dc-zbx:~# tcpdump -i bond0 udp port 162
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 262144 bytes

Находим на железке живых соседей:

SW# show ip ospf neighbors vrf all OSPF Process ID 10 VRF default Total number of neighbors: 4 Neighbor ID Pri State Up Time Address Interface 192.168.0.242 1 FULL/ - 01:47:17 172.17.0.10 Vlan1427 192.168.0.222 1 FULL/ - 18w1d 172.17.0.6 Vlan1426 192.168.1.149 1 FULL/ - 5w0d 172.17.0.30 Vlan1473 192.168.1.146 1 FULL/ - 3d00h 172.17.0.58 Vlan1404 OSPF Process ID 100 VRF OSPF100 Total number of neighbors: 4 Neighbor ID Pri State Up Time Address Interface 192.168.1.149 1 FULL/ - 5w0d 172.17.0.34 Vlan1474 192.168.0.220 1 FULL/ - 13w3d 172.17.0.54 Vlan1479 192.168.0.240 1 FULL/ - 13w3d 172.17.0.46 Vlan1477 192.168.1.146 1 FULL/ - 3d00h 172.17.0.62 Vlan1405 OSPF Process ID 200 VRF Dia Total number of neighbors: 2 Neighbor ID Pri State Up Time Address Interface 10.65.0.252 1 FULL/ - 17w2d 172.17.0.18 Vlan1450 172.17.0.26 1 FULL/ - 17w0d 172.17.0.26 Vlan1452 OSPF Process ID 216 VRF Dev Total number of neighbors: 2 Neighbor ID Pri State Up Time Address Interface 10.255.255.94 1 FULL/ - 18:59:59 10.216.0.73 Vlan1641 10.216.0.82 1 FULL/ - 18:59:54 10.216.0.82 Vlan1643

И уроним кого-нибудь

interface vlan 1643 shutdown

Видим в снифере:

11:08:20.001942 IP 192.168.192.169.22095 > dc-zbx.example.com.snmp-trap: F=ap U="Zabbix" [!scoped PDU]39_d1_7c_19_b3_d9_f8_31_32_8e_c9_39_c2_3a_db_d8_28_26_c6_0b_01_55_b6_fa_5e_f5_38_66_f9_6f_3f_c0_98_cb_57_93_5a_50_8e_50_90_79_f3_9b_ec_ec_d7_9f_e8_ac_f6_fd_79_ac_95_ff_71_73_32_70_52_66_a5_7d_b3_c4_39_d0_1c_7f_a6_38_ea_d7_61_c0_2f_12_ee_db_d9_07_40_8c_a8_48_57_e9_e5_56_12_3f_ec_f9_34_65_09_96_86_f6_d2_93_06_45_fa_95_ea_36_5a_82_2f_30_8f_02_03_59_07_5f_d8_a6_1c_f2_5a_be_7d_09_15_ef_05_00_83_fd_ea_ac_2a_3b_86_0f_86_e5_3b_93_3a_68_6d_33_99_e2_46_2b_9d_6a_1e_5d_9e_d9_93_56_51_5e_ff_9e_77_4c_cb

Если вы в снифере ничего не увидели, диагностируйте, потому что иначе смысла продолжать дальше никакого не будет, вы просто не поймете на каком из этапов у вас что-то не работает.
Если под рукой нет железки или нельзя трогать продакшен, то TRAP можно сгенерировать с любой другой тачки, например вот так:

snmptrap -v 1 -c neveruseme 127.0.0.1 '.1.3.6.1.6.3.1.1.5.3' '0.0.0.0' 6 33 '55' .1.3.6.1.6.3.1.1.5.3 s "teststring000"
snmptrap -v3 -l authPriv -u Zabbix -a SHA -A abyrvalg -x AES -X pechka -e 0x8000000001020305 192.168.192.168 0 linkUp.0

Настройка SNMPd, SNMPTRAPd, SNMPTT

Нам понадобятся в системе пакеты:

apt install snmp snmp-mibs-downloader snmpd snmptrapd snmptt

Я не стал ориентироваться на Perl trap receiver, а выбрал SNMPTT по личным и субъективным причинам. Итак, в доке написано:

1. snmptrapd receives a trap

Начинать надо именно с его настройки, а не лезть сразу создавать Item в морде Zabbix. Почему так — нужно подниматься по тем же ступенькам, что идёт TRAP. В предыдущем разделе мы убедились что TRAP в принципе прилетает с железки, теперь мы будем добиваться того, чтобы он хотя бы был принят первым демоном — snmptrapd. Помнится давно настраивал postfix+dovecot+еще чего-то там. И промудохался я недели две — там тоже один демон принимает коннект, другой парсит письмо, третий кладет его в очередь, четвертый в папку к юзеру и так далее, и у меня ничего не получалось. А всё потому, что настраивал то с середины, то с конца, то с начала, а надо было начать с телнета на 25 порт и просмотра дебага лисенера

Лезем в /etc/snmp/snmptrapd.conf и удаляем, а лучше комментируем там всё что нам не понятно и не интересно, оставляем одну строку

disableAuthorization yes

Стопаем сервис

systemctl stop snmptrapd.service

Запускаем в ручном режиме

root@dc-zbx:~# snmptrapd -f -Lo
NET-SNMP version 5.7.3 AgentX subagent connected
NET-SNMP version 5.7.3

Снова пробуем сломать OSPF как в примере выше и видим:

2018-07-20 11:38:38 UNKNOWN [UDP: [192.168.192.169]:22095->[192.168.192.168]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1355817272) 156 days, 22:09:32.72 SNMPv2-MIB::snmpTrapOID.0 = OID: OSPF-TRAP-MIB::ospfNbrStateChange OSPF-MIB::ospfRouterId = IpAddress: 10.216.0.74 OSPF-MIB::ospfNbrIpAddr = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrAddressLessIndex = INTEGER: 0 OSPF-MIB::ospfNbrRtrId = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrState = INTEGER: down(1)

Если не видим, то ищем причину почему. Если вы хотите, чтобы у вас были такие же красивые записи, а не набор OID вида 1.3.6.1.2.1.14.10.1.6, то в /etc/snmp/snmp.conf добавьте следующее:

mibs +OSPF-MIB
mibs +OSPF-TRAP-MIB
mibs +OSPFV3-MIB
mibdirs +/usr/share/snmp/mibs/ietf/

И передерните SNMPd

systemctl restart snmpd.service

Более подробно как с наименьшей болью скачать MIB файлы и скормить их вашему SNMPd можно прочитать [тут](https://wiki.debian.org/SNMP).

Теперь прикрутим аутентификацию, лезем снова в /etc/snmp/snmptrapd.conf

traphandle default snmptthandler
#disableAuthorization yes
# 192.168.192.169
createUser -e 0x80000009038d604a6a82a3 Zabbix SHA string AES
authuser log,execute,net Zabbix

-e 0x80000009038d604a6a82a3 — это engineID, его можно посмотреть на сетевой железке:

SW# sh snmp engineID Local SNMP engineID: [Hex] 80000009038F604D6A82A1 [Dec] 128:040:000:109:003:140:096:079:106:131:160

Снова повторяем эксперимент, но теперь еще ловим дебаг касательно USM:

root@dc-zbx:~# snmptrapd -f -Lo -Dusm
registered debug token usm, 1
usmUser: created a new user Zabbix at 80 00 00 09 03 8F 60 4F 6B 82 A5 NET-SNMP version 5.7.3 AgentX subagent connected
NET-SNMP version 5.7.3 usm: USM processing begun...
usm: match on user Zabbix
usm: no match on engineID (80 00 00 09 03 8F 60 4F 6B 82 A5 )
usm: match on user Zabbix
usm: Verification succeeded.
usm: USM processing completed.
2018-07-20 11:50:07 UNKNOWN [UDP: [192.168.192.169]:22095->[192.168.192.168]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1355886163) 156 days, 22:21:01.63 SNMPv2-MIB::snmpTrapOID.0 = OID: OSPF-TRAP-MIB::ospfNbrStateChange OSPF-MIB::ospfRouterId = IpAddress: 10.216.0.74 OSPF-MIB::ospfNbrIpAddr = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrAddressLessIndex = INTEGER: 0 OSPF-MIB::ospfNbrRtrId = IpAddress: 10.216.0.82 OSPF-MIB::ospfNbrState = INTEGER: down(1)

Если на этом этапе вы видите ошибки авторизации в дебаге, внимательно проверяйте engineID и что созданные на железке пользователи совпадают с теми, что мы нарисовали в конфиге /etc/snmp/snmptrapd.conf. Кстати да, для каждой железки придется создавать своего пользователя со своим engineID, или руками сделать его одинаковым на всех железках, если железки такое позволят сделать.

У меня в дебаге видно строчку:

usm: no match on engineID (80 00 00 09 03 8F 60 4F 6B 82 A5 )

Почему так я не понял, хотя при всем этом TRAP принимается и попадает на дальнейшую обработку. Если знаете что я сделал не так, прошу в комментарии.

В первом определяем параметры работы самого демона, во втором определяем параметры получения и обработки каждого определённого трапа. Теперь беремся за SNMPTT — у него два конфига ini и conf.

Лезем в файл /etc/snmp/snmptt.ini и рисуем следующие вещи:

mode = daemon
net_snmp_perl_enable = 1
date_time_format = %Y %m %d %H:%M:%S

Формат даты и времени дело хозяйское, главное используйте везде одинаковый.

log_file = /var/log/snmptt/snmptt.log
log_system_file = /var/log/snmptt/snmpttsystem.log
unknown_trap_log_enable = 1
unknown_trap_log_file = /var/log/snmptt/snmpttunknown.log

Почему лог не такой как во многих статьях в интернетах? Потому что в доке было сказано «If systemd parameter PrivateTmp is used, this file is unlikely to work in /tmp.», не хочу лишний раз вставать на грабли, если об этом заранее предупреждают, так что меняю сразу на нормальный путь до файла.

Далее идем в /etc/snmp/snmptt.conf, убираем всё что нам не нужно и/или не понятно, оставляем только это:

EVENT ospfNbrStateChange .1.3.6.1.2.1.14.16.2.2 "OSPF" Normal
FORMAT ZBXTRAP $aA OSPF neighbor with IP addr $2 changed state to $5

В таком виде потому, что Zabbix будет ожидать в логе именно такой формат. Откуда берутся $2 и $5 можно узнать если посмотреть формат TRAP сообщения, глядим:

Object ospfNbrStateChange
OID 1.3.6.1.2.1.14.16.2.2
MIB OSPF-TRAP-MIB ;
Trap Components ospfRouterId ospfNbrIpAddr ospfNbrAddressLessIndex ospfNbrRtrId ospfNbrState

Вот эти Trap Components и есть параметры которые можно пихать в формат лога по порядку $1, $2…

Оказалось что после их изменения надо рестартовать не snmptt.serivce, а snmpd.service — этот нюанс прилично попил моей крови и попилил нервов во время дебага. В ходе разборок со всем этим добром я заметил что после изменения настроек SNMPTT, как будто изменения не применяются.

Проверьте что у вас все демоны запущены:

systemctl status snmpd snmptrapd snmptt

Если всё ок, пробуем снова сломать OSPF и идем в лог /var/log/snmptt/snmptt.log, будет подобное:

2018 07 19 15:10:52 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to down
2018 07 19 15:12:28 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart
2018 07 19 15:12:34 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to full
2018 07 19 15:22:41 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to down
2018 07 19 15:25:38 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart

Те TRAP, которые мы не настроили в конфиге /etc/snmp/snmptt.conf попадут в лог /var/log/snmptt/snmpttunknown.log, но только от той железки, для которой настроен правильный юзер и engineID в этом же конфиге. То есть от левых железок TRAP будут просто silently dropped, если хочется матана и разбора полетов, то вам сюда — на редкость вменяемая дока по net-snmp, там еще неплохо описано различие между TRAP и INFORM, забегая вперед, лучше использовать INFORM, т. к. там какой-никакой контроль доставки есть, а SNMP он же по UDP работает.

И только теперь лезем настраивать нашу мониторилку.

Настройка Zabbix

Для начала я создавал Item прямо на хосте, чтобы быстрее и проще ловить спецэффекты, сюда же напишу сразу как создать Template, потому что именно шаблонами надо пользоваться всегда когда это возможно. Покажу картинками, халява копи-пастинга закончилась, но покрашу места на которые нужно обратить внимание.

Создаем шаблон:

image

Тут просто даем вменяемое имя

Создаем Item

image

Важно — ключ должен быть таким, то, что указано в квадратных скобках это то, что будет искать Zabbix в логе, формат лога мы настраивали в /etc/snmp/snmptt.conf и писали там:

EVENT ospfNbrStateChange .1.3.6.1.2.1.14.16.2.2 "OSPF" Normal
FORMAT ZBXTRAP $aA OSPF neighbor with IP addr $2 changed state to $5

Собственно в логе это волшебное слово «OSPF» и появляется:

2018 07 19 15:25:38 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - ZBXTRAP 192.168.192.169 OSPF neighbor with IP addr 10.216.0.82 changed state to exchangeStart

Формат даты мы определяли в конфиге /etc/snmp/snmptt.ini:

date_time_format = %Y %m %d %H:%M:%S

О чем я и писал выше — используйте любой удобный вам формат, главное чтобы он совпадал в нужных местах.

Создаем Trigger

image

Состояний у соседа может быть несколько:

1 : down
2 : attempt
3 : init
4 : twoWay
5 : exchangeStart
6 : exchange
7 : loading
8 : full

Вообще не принципиально в каком именно состоянии находится сосед, если это состояние не FULL, т. к. чтобы это продиагностировать, придется всё-равно идти на железку, читать логи, вводить какие-то команды. Так что триггер будет один и будет возбуждаться только когда в TRAP состояние соседа не FULL.

В этом случае в логе Zabbix сервера /var/log/zabbix/zabbix_server.log будет сообщение вида: Прежде чем повесить шаблон на конкретный хост, убедитесь, что у хоста настроен корректный SNMP интерфейс с правильным IP адресом, иначе трапы будут в логе /var/log/snmptt/snmptt.log, но Zabbix их «не привяжет» к хосту.

19972:20180720:091722.896 unmatched trap received from "192.168.192.169": 2018 07 20 09:17:21 .1.3.6.1.2.1.14.16.2.2 Normal "OSPF" 192.168.192.169 - OSPF neighbor with IP addr 10.64.0.10 changed state to exchangeStart

Идем в Latest data, видим

image

Триггер тоже сработал

image

Теперь положим двух соседей

image

В дашборде видим что случилось две проблемы, это хорошо, и даже два письма прилетит на эту тему при настроенном оповещении.

Всё здорово, всё работает, а вот и вишенка на торте в завершении.

Отчаяние

При этом в дашборде исчезнут сразу обе проблемы. Сейчас мы берем и поднимаем одного соседа. Такой нюанс я случайно заметил когда тестировал шаблон. Это не баг, это фича. Еще есть мысль нарисовать скрипт, который будет ходить по SSH/API на сетевые железки, собирать инфу обо всех соседях, делать «рабочий» слепок, анализировать diff между проверками и писать в лог что не так, далее лог можно скормить мониторилке… сложно. В итоге получается, что если у нас упадет несколько соседей, а потом один из них поднимется, или даже если поднимется сосед, которого раньше вовсе не существовало, то мониторинг позеленеет.
Конечно, можно Item руками настроить чтобы отслеживать конкретного соседа, можно еще чего-нибудь скриптануть, можно вернуться к SNMP контекстам из самого начала статьи. Если вы знаете вменяемый способ решения этой задачи или считаете что я всё сделал неправильно, опять же прошу в комментарии, а лучше в ответную статью.
Хотелось то минимум костылей и кастома.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Сегодня MIPS стал Open Source, против RISC/V и ARM. Как Россия повлияла на стратегию американской процессорной компании

То, о чем говорили сторонники Open Source с 1980-х — свершилось! Сегодня архитектура процессоров MIPS стала Open Source. Учитывая, что такие компании как Broadcom, Cavium, китайский ICT и Ingenic платили MIPS за архитектурную лицензию (право сделать совместимую по системе команд ...

Вышла новая версия Unity 2018.3

Вышла новая версия Unity, которая уже доступна для пользователей. Unity 2018.3 содержит более 2000 новых функций, исправлений и улучшений, включая улучшенный воркфлоу префабов, Visual Effect Graph (Preview) и обновленную систему Terrain, которые дают разработчикам возможность повысить производительность и создавать многогранные ...