Техническое задание
Имеется сеть географически разбросанных дата-центров с вагоном VRF и постоянно изменяющимся списком OSPF соседей. Необходимо отслеживать их:
- Состояние, делать alarm если состояние соседа не FULL
- Количество, то есть если сосед пропал, нужно также делать alarm
Система мониторинга уже есть — Zabbix 3.4, желательно использовать именно её, ОС Linux Debian 9.x
Пробуем с наскока
Протокол распространенный, система мониторинга известная, наверняка я не первый кто хочет решить эту задачу и скорее всего она уже решена.
Вколачиваем в поиск «zabbix ospf» и первая же ссылка ведет на шаблон. Счастье то какое — сейчас я его импортирую, причешу под свои нужды и всё будет оки доки.
Проверяем как работает — вроде все хорошо, состояния отслеживаются, но вот когда сосед уходит в состояние DOWN, мы получаем от Zabbix «очень» информативное сообщение
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, ок создаем:
{Template - SNMPv3 - OSPF Discovery:ospfNbrState[{#SNMPVALUE}].nodata(120)}=0Видим в дашборде:
OSPF neighbor 192.168.192.168 missing dataВ принципе… юзабельно
Но из коробки LLD обнаруживает только соседей из default VRF. Конечно, это можно порешать с помощью SNMP context, но как-то совсем не захотелось идти таким путем — это надо по всем железкам пройтись, каждому OSPF процессу или VRF вколотить контекст, потом в шаблоне сделать копии Discovery для каждого контекста свою, в целом многовато возни и при добавлении новых OSPF процессов надо в нескольких местах что-то менять. Можно конечно обложиться скриптами и через Zabbix API всё это менять, но не хотелось особого кастома, а хотелось по максимуму использовать только встроенную в Zabbix функциональность. Есть упоминание о некоем CISCO-CONTEXT-MAPPING-MIB, из которого можно выдернуть все соответствия контекстов и OSPF/VRF, но как эту конструкцию прикрутить к LLD и моему случаю я не сообразил. Если кто-то умеет так круто готовить 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, как будто изменения не применяются. Оказалось что после их изменения надо рестартовать не snmptt.serivce, а snmpd.service — этот нюанс прилично попил моей крови и попилил нервов во время дебага.
Проверьте что у вас все демоны запущены:
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, потому что именно шаблонами надо пользоваться всегда когда это возможно. Покажу картинками, халява копи-пастинга закончилась, но покрашу места на которые нужно обратить внимание.
Создаем шаблон:
Тут просто даем вменяемое имя
Создаем Item
Важно — ключ должен быть таким, то, что указано в квадратных скобках это то, что будет искать 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
Состояний у соседа может быть несколько:
1 : down
2 : attempt
3 : init
4 : twoWay
5 : exchangeStart
6 : exchange
7 : loading
8 : fullВообще не принципиально в каком именно состоянии находится сосед, если это состояние не FULL, т. к. чтобы это продиагностировать, придется всё-равно идти на железку, читать логи, вводить какие-то команды. Так что триггер будет один и будет возбуждаться только когда в TRAP состояние соседа не FULL.
Прежде чем повесить шаблон на конкретный хост, убедитесь, что у хоста настроен корректный SNMP интерфейс с правильным IP адресом, иначе трапы будут в логе /var/log/snmptt/snmptt.log, но Zabbix их «не привяжет» к хосту. В этом случае в логе Zabbix сервера /var/log/zabbix/zabbix_server.log будет сообщение вида:
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, видим
Триггер тоже сработал
Теперь положим двух соседей
В дашборде видим что случилось две проблемы, это хорошо, и даже два письма прилетит на эту тему при настроенном оповещении.
Всё здорово, всё работает, а вот и вишенка на торте в завершении.
Конечно, можно Item руками настроить чтобы отслеживать конкретного соседа, можно еще чего-нибудь скриптануть, можно вернуться к SNMP контекстам из самого начала статьи. Еще есть мысль нарисовать скрипт, который будет ходить по SSH/API на сетевые железки, собирать инфу обо всех соседях, делать «рабочий» слепок, анализировать diff между проверками и писать в лог что не так, далее лог можно скормить мониторилке… сложно. Хотелось то минимум костылей и кастома. Если вы знаете вменяемый способ решения этой задачи или считаете что я всё сделал неправильно, опять же прошу в комментарии, а лучше в ответную статью.
Автор: Андрей
