Zabbix - memantau tetangga OSPF menggunakan SNMPv3 TRAP, rasa sakit dan keputusasaan

Kerangka Acuan


Ada jaringan pusat data yang tersebar secara geografis dengan mobil VRF dan daftar tetangga OSPF yang selalu berubah. Anda perlu melacaknya:

  1. Nyatakan, lakukan alarm jika keadaan tetangga tidak LENGKAP
  2. Kuantitas, yaitu, jika tetangga hilang, Anda juga harus melakukan alarm

Sistem pemantauan sudah ada - Zabbix 3.4, diinginkan untuk menggunakannya, Linux OS Debian 9.x

Kami mencoba dengan cepat


Protokolnya tersebar luas, sistem pemantauannya diketahui, saya mungkin bukan yang pertama yang ingin menyelesaikan masalah ini, dan kemungkinan besar sudah diselesaikan.

Kami masuk ke pencarian untuk "zabbix ospf" dan tautan pertama mengarah ke templat . Kebahagiaan adalah apa - sekarang saya mengimpornya, menyisirnya untuk kebutuhan saya dan semuanya akan menjadi dermaga yang baik.
Kami memeriksa cara kerjanya - semuanya tampak baik-baik saja, negara dimonitor, tetapi ketika tetangga masuk ke kondisi BAWAH, kami mendapatkan pesan "sangat" informatif dari Zabbix

No Such Instance currently exists at this OID 

dan info

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

Apa yang terjadi - masalahnya sudah lama dan dikenal di forum - ketika tetangga OSPF menghilang, maka semua OID yang terkait dengannya hanya dihapus pada perangkat keras jaringan.

Ya, ada solusi - buat pemicu nodata, ok buat:

 {Template - SNMPv3 - OSPF Discovery:ospfNbrState[{#SNMPVALUE}].nodata(120)}=0 

Kita lihat di dashboard:

 OSPF neighbor 192.168.192.168 missing data 

Pada dasarnya ... dapat digunakan

Tapi di luar kotak, LLD hanya mendeteksi tetangga dari VRF default. Tentu saja, ini dapat diatasi dengan menggunakan konteks SNMP , tetapi entah bagaimana saya tidak ingin pergi dengan cara ini sama sekali - kami harus melalui semua bagian besi, menyuntikkan konteks ke setiap proses OSPF atau VRF, kemudian membuat salinan Discovery untuk setiap konteks dalam template kami, secara umum itu sedikit banyak Repotnya dan saat menambahkan proses OSPF baru, Anda perlu mengubah sesuatu di beberapa tempat. Anda dapat, tentu saja, dikelilingi oleh skrip dan melalui Zabbix API semua ini dapat diubah, tetapi saya tidak ingin kebiasaan khusus, tetapi saya hanya ingin menggunakan fungsi yang dibangun ke dalam Zabbix secara maksimal. Ada yang menyebutkan tentang CISCO-CONTEXT-MAPPING-MIB, dari mana Anda dapat menarik semua korespondensi antara konteks dan OSPF / VRF, tapi saya tidak tahu bagaimana cara mempercepat desain ini ke LLD. Jika seseorang tahu cara memasak Zabbix dengan sangat keren, maka selamat datang di komentar, dan lebih baik untuk artikel terpisah yang lengkap.

Kami mencoba dari serangan kedua


Setelah beberapa jam mencari di Internet untuk mendapatkan petunjuk di forum dan keluar dari tempat memori, sebuah topik muncul tentang SNMP TRAP - ini adalah saat kami tidak menginterogasi sepotong besi, tetapi sepotong besi mengirimkan informasi tentang mengubah sesuatu. Ya, dan dukungan kampanye untuk hal ini ada di sistem pemantauan kami di luar kotak , peralatan juga dapat segera dan hanya untuk kasus saya.

Dari baris pertama, dokumentasi pemantauan dikacaukan oleh daftar panjang:

 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 byLog unmatched SNMP traps” in Administration → General → Other.) 

Yaitu, satu daemon menerima TRAP, meneruskannya ke daemon lain, mem-parsingnya, meletakkannya di log dengan format yang diinginkan, dan zabix sudah membaca log dan memutuskan apa yang harus dilakukan selanjutnya. Entah bagaimana itu sudah terlihat tidak pernah lebih mudah daripada berjalan dengan tangan Anda dan menggambar konteks SNMP di mana-mana, tapi oh well, mari kita coba. Kami dengan hati-hati membaca dokumen pemantauan dan memahami bahwa hanya dengan bantuannya tidak ada yang dapat dikonfigurasikan, secara umum Zabbix memiliki lelucon seperti itu - dokumentasi menggambarkan kemampuan dan nuansa sistem sehingga minimal sehingga lebih membingungkan daripada diajarkan. Meskipun mereka dapat dipahami - perangkat lunak ini gratis, tetapi entah bagaimana Anda perlu mendapatkan uang, tetapi mereka mendapatkan uang dengan dukungan. Ada artikel di Internet dengan deskripsi tentang cara mengatur ini sekali atau dua kali , tetapi saya tidak dapat mengatur dari satu artikel ke yang berikutnya, saya harus mengumpulkan informasi dari berbagai sumber sedikit demi sedikit. Ini semua lirik, mereka melaju untuk melakukan hardcore.

Kami mengkonfigurasi sepotong jaringan besi


Sebelum Anda memutar sesuatu pada host dengan pemantauan, saya sangat menyarankan Anda mengkonfigurasi perangkat keras jaringan terlebih dahulu dan memastikan bahwa TRAP benar-benar datang dari perangkat keras ke server - pada awalnya saya tidak memeriksa bahwa ia minum banyak saraf, darah dan waktu. Saya memiliki mobil Cisco Nexus, jadi saya akan memberikan contoh untuk seri ini. Siapa pun yang memiliki Catalyst, ASR, ASA, dan sebagainya - maaf, saya bukan matahari, saya tidak akan memanaskan semuanya, membaca dok tentang cara mengonfigurasikannya sendiri, sintaksisnya akan serupa, tetapi dengan nuansa tersendiri.

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

Adalah penting di masa depan, ketika mengkonfigurasi TRAP di Zabbix, bahwa alamat dari mana TRAP dikirim sama dengan alamat SNMP dari antarmuka di pengaturan host di Zabbix.

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

Gunakan versi 3 protokol sedapat mungkin, dalam mode authPriv (enkripsi dan otentikasi), tidak sesulit untuk dikonfigurasikan. Lupakan versi 1 dan versi 2 protokol - ketika orang tak terduga tiba karena kurangnya enkripsi dan pada dasarnya otentikasi dalam versi protokol ini - itu hanya masalah waktu (string komunitas ditransmisikan dalam bentuk yang jelas, apalagi, saya secara teratur melihat bahwa itu dikonfigurasi publik / pribadi). Parameter operator jaringan memungkinkan Anda memberikan izin hanya-baca bagi pengguna.

 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 

Saya secara khusus menonaktifkan semua TRAP kecuali OSPF, sehingga ketika mendiagnosis mengapa sesuatu tidak berfungsi, saya tidak perlu membaca banyak informasi yang tidak perlu dari debug.

Cara memeriksa apakah TRAP berfungsi sangat sederhana - Anda perlu memecahkan sesuatu. Kami memulai sniffer pada host dengan memonitor:

 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 

Kami menemukan pada sepotong tetangga besi hidup:

 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 

Dan jatuhkan seseorang

 interface vlan 1643 shutdown 

Kita melihat di sniffer:

 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 

Jika Anda tidak melihat apa pun di sniffer, lakukan diagnosa, karena jika tidak, tidak ada alasan untuk melanjutkan, Anda tidak akan mengerti pada tahap mana sesuatu tidak bekerja untuk Anda.
Jika tidak ada sepotong besi di tangan atau produksi tidak dapat disentuh, maka TRAP dapat dihasilkan dari mobil lain, misalnya, seperti ini:

 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 

Konfigurasikan SNMPd, SNMPTRAPd, SNMPTT


Kami akan membutuhkan paket dalam sistem:

 apt install snmp snmp-mibs-downloader snmpd snmptrapd snmptt 

Saya tidak fokus pada receiver perangkap Per, tetapi memilih SNMPTT untuk alasan pribadi dan subyektif. Jadi, dermaga berkata:

 1. snmptrapd receives a trap 

Kita perlu memulai dengan konfigurasinya, dan tidak segera naik untuk membuat Item di wajah Zabbix. Mengapa begitu - Anda harus naik ke langkah yang sama dengan TRAP. Pada bagian sebelumnya, kami memastikan bahwa TRAP pada dasarnya berasal dari sepotong besi, sekarang kami akan memastikan bahwa itu paling tidak diterima oleh daemon pertama - snmptrapd. <lyric> Saya ingat mengatur postfix + dovecot + sesuatu yang lain di sana sejak lama. Dan saya merajuk selama sekitar dua minggu - di sana juga, satu iblis menerima koneksi, yang lain mem-parsing surat itu, yang ketiga memasukkannya ke dalam antrian, yang keempat di folder ke pengguna, dan seterusnya, dan saya tidak berhasil. Dan semua karena saya menyetel dari tengah, dari akhir, dari awal, tapi saya harus mulai dengan telnet ke port 25 dan melihat debugger the foxer </ lyric>

Kami naik ke /etc/snmp/snmptrapd.conf dan menghapusnya, tetapi kami mengomentari segala sesuatu yang kami tidak mengerti dan tidak tertarik, kami meninggalkan satu baris

 disableAuthorization yes 

Hentikan layanan

 systemctl stop snmptrapd.service 

Jalankan dalam mode manual

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

Sekali lagi, coba hancurkan OSPF seperti pada contoh di atas dan lihat:

 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) 

Jika kita tidak melihat, maka kita mencari alasannya. Jika Anda ingin memiliki catatan indah yang sama, dan bukan satu set OID dari formulir 1.3.6.1.2.1.14.10.1.6, kemudian tambahkan yang berikut ke /etc/snmp/snmp.conf:

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

Dan mendistorsi SNMPd

 systemctl restart snmpd.service 

Secara lebih rinci cara mengunduh file MIB dengan sedikit rasa sakit dan memberi mereka ke SNMPd Anda dapat dibaca [di sini] (https://wiki.debian.org/SNMP).

Sekarang kita kencangkan otentikasi, kita naik lagi di /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 adalah engineID, dapat dilihat pada perangkat keras jaringan:

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

Kami mengulangi percobaan lagi, tetapi sekarang kami masih menangkap debug tentang 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) 

Jika pada tahap ini Anda melihat kesalahan otorisasi dalam debug, periksa engineID dengan hati-hati dan bahwa pengguna yang dibuat pada perangkat keras cocok dengan yang kami gambar di konfigurasi /etc/snmp/snmptrapd.conf. Ngomong-ngomong, ya, untuk setiap bagian dari besi Anda harus membuat pengguna Anda sendiri dengan engineID-nya, atau membuatnya sama pada semua bagian besi dengan tangan Anda, jika potongan-potongan besi memungkinkan ini dilakukan.

Saya dapat melihat baris di debug:

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

Mengapa saya tidak mengerti, meskipun dengan semua ini, TRAP diterima dan dapat diproses lebih lanjut. Jika Anda tahu apa yang saya lakukan salah, silakan komentar.

Sekarang kita mengambil SNMPTT - ia memiliki dua ini dan conf config. Di bagian pertama kita tentukan parameter daemon itu sendiri, di bagian kedua kita tentukan parameter untuk menerima dan memproses setiap tangga tertentu.

Kami naik ke file /etc/snmp/snmptt.ini dan menggambar hal-hal berikut:

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

Format tanggal dan waktu adalah urusan bisnis, yang paling penting, gunakan yang sama di mana-mana.

 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 

Mengapa log tidak sama dengan banyak artikel di Internet? Karena dok berkata, "Jika parameter systemd PrivateTmp digunakan, file ini tidak mungkin berfungsi di / tmp.", Saya tidak ingin masuk lagi ke rake jika diperingatkan sebelumnya, jadi saya akan segera beralih ke jalur normal ke file.

Selanjutnya, buka /etc/snmp/snmptt.conf, hapus semua yang tidak kita butuhkan dan / atau tidak mengerti, kita hanya menyisakan ini:

 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 

Dalam formulir ini, karena Zabbix akan mengharapkan format seperti itu di log. Dari mana $ 2 dan $ 5 berasal, Anda dapat mengetahui apakah Anda melihat format pesan TRAP , lihat:

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

Komponen Perangkap ini adalah parameter yang dapat dimasukkan ke dalam format log dalam urutan $ 1, $ 2 ...

Selama showdown dengan semua hal ini, saya perhatikan bahwa setelah mengubah pengaturan SNMPTT, seolah-olah perubahan itu tidak diterapkan. Ternyata setelah perubahan mereka perlu me-restart bukan snmptt.serivce, tetapi snmpd.service - nuansa ini layak meminum darah saya dan meminum saraf saya selama debug.

Pastikan Anda menjalankan semua daemon:

 systemctl status snmpd snmptrapd snmptt 

Jika semuanya baik-baik saja, coba lagi untuk memecah OSPF dan pergi ke log /var/log/snmptt/snmptt.log, akan terlihat seperti ini:

 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 yang tidak kami konfigurasikan di config /etc/snmp/snmptt.conf akan masuk ke log /var/log/snmptt/snmpttunknown.log, tetapi hanya dari perangkat keras yang pengguna dan engineID yang benar dikonfigurasi dalam konfigurasi yang sama. Artinya, dari kelenjar kiri, TRAP hanya akan diam-diam dijatuhkan, jika Anda ingin matan dan tanya jawab, maka di sini Anda memiliki dok waras yang tidak biasa di net-snmp, perbedaan antara TRAP dan INFORM masih dijelaskan dengan baik di sana, melihat ke depan, lebih baik menggunakan INFORM, dll. ada beberapa jenis kontrol pengiriman di sana, tetapi berfungsi melalui UDP melalui UDP.

Dan baru sekarang kita naik untuk mengkonfigurasi monitor kita.

Pengaturan Zabbix



Pertama-tama, pastikan bahwa dalam konfigurasi /etc/zabbix/zabbix_server.conf, pemantauan diatur ke log SNMPTT yang benar dan Zabbix sendiri memulai setidaknya satu Trapper SNMP:

SNMPTrapperFile=/var/log/snmptt/snmptt.log
StartSNMPTrapper=1


Sebagai permulaan, saya membuat Item langsung pada host, sehingga lebih cepat dan lebih mudah untuk menangkap efek khusus, di sini saya akan segera menulis cara membuat Template, karena itu adalah template yang harus digunakan kapan pun memungkinkan. Saya akan menunjukkan gambar-gambarnya, freebie salin-tempel sudah selesai, tetapi saya akan mengecat tempat-tempat yang perlu Anda perhatikan.

Buat templat:

gambar

Di sini kita hanya memberikan nama yang waras

Buat Barang

gambar

Penting - kuncinya harus seperti itu, apa yang ditunjukkan dalam tanda kurung adalah apa yang akan dicari Zabbix di log, kami mengonfigurasi format log di /etc/snmp/snmptt.conf dan menulis di sana:

 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 

Sebenarnya dalam log, ini adalah kata ajaib "OSPF" dan muncul:

 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 

Format tanggal yang kami tentukan dalam konfigurasi /etc/snmp/snmptt.ini:

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

Apa yang saya tulis di atas - gunakan format apa pun yang nyaman bagi Anda, hal utama adalah bahwa itu cocok di tempat yang tepat.

Buat Pemicu

gambar

Seorang tetangga mungkin memiliki beberapa negara :

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

Tidak masalah apa pun keadaan negara tetangga itu, jika keadaan ini tidak LENGKAP, karena untuk mendiagnosis ini, Anda masih harus pergi ke sepotong besi, membaca log, memasukkan beberapa perintah. Jadi pemicunya akan menjadi satu dan akan bersemangat hanya ketika di TRAP keadaan tetangga tidak FULL.

Sebelum menggantung templat pada host tertentu, pastikan host dikonfigurasikan dengan antarmuka SNMP yang benar dengan alamat IP yang benar, jika tidak tangga akan berada di log /var/log/snmptt/snmptt.log, tetapi Zabbix tidak akan "mengikat" mereka ke host. Dalam hal ini, dalam log Zabbix dari server /var/log/zabbix/zabbix_server.log akan ada pesan berupa:

 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 


Pergi ke Data terbaru, lihat

gambar

Pemicu juga berhasil

gambar

Sekarang taruh dua tetangga

gambar

Di dasbor, kami melihat bahwa dua masalah terjadi, ini bagus, dan bahkan dua huruf akan tiba pada topik ini dengan pemberitahuan yang dikonfigurasi.

Semuanya bagus, semuanya bekerja, dan inilah ceri pada kue di akhir.

Keputusasaan
Sekarang kita mengambil dan membesarkan satu tetangga. Pada saat yang sama, kedua masalah akan hilang di dasbor sekaligus. Ini bukan bug, ini fitur. Saya tidak sengaja melihat nuansa seperti itu ketika saya menguji templat. Akibatnya, ternyata jika beberapa tetangga jatuh, dan kemudian salah satu dari mereka naik, atau bahkan jika tetangga naik, yang tidak ada sebelumnya, maka pemantauan akan berubah menjadi hijau.
Tentu saja, Anda dapat mengonfigurasi Item dengan tangan Anda untuk melacak tetangga tertentu, Anda masih dapat membuat skrip sesuatu, Anda dapat kembali ke konteks SNMP dari awal artikel. Masih ada ide untuk menggambar skrip yang akan pergi SSH / API ke kelenjar jaringan, mengumpulkan informasi tentang semua tetangga, membuat gips "bekerja", menganalisis perbedaan antara cek dan menulis apa yang salah dalam log, maka log dapat diumpankan ke monitor ... sulit. Saya ingin kruk dan kebiasaan minimum. Jika Anda tahu cara yang masuk akal untuk menyelesaikan masalah ini atau berpikir bahwa saya melakukan semuanya dengan salah, sekali lagi saya bertanya dalam komentar, tetapi lebih pada artikel tanggapan.


UPD: kolega kami menyarankan kami untuk mengatasinya dan mencoba menerapkan rencana kami menggunakan konteks SNMP . Ada permintaan, akan ada pasokan. Ke depan bisa saya katakan - iblis tidak begitu mengerikan, ayo pergi.
Pada sepotong jaringan besi kita menggambar perintah ajaib:

snmp-server context {snmp context name} instance {protocol instance} vrf {vrf name}

Nama parameter perlu klarifikasi
{snmp context name} - nama konteks SNMP yang akan digunakan dalam permintaan.
{protocol instance} dan {vrf name} yang kami ambil dari konfigurasi proses OSPF yang dikonfigurasi:

router ospf {protocol instance}
..
vrf {vrf name}
..


Ada ketakutan bahwa setelah pengaturan seperti itu kita akan menghancurkan Item yang sudah dikonfigurasi melalui SNMP dengan konteks kosong, tapi saya memeriksa bahwa pengaturan hanya mempengaruhi output data melalui OSPF-MIB, sedangkan misalnya dari bagian IF-MIB semuanya terus dikembalikan seperti sebelumnya dengan konteks kosong. Jika Anda tidak memiliki Nexus, saya sarankan memeriksa titik ini sekali lagi - kemungkinan perilakunya akan berbeda.

Sekarang putar template di Zabbix.
Anda harus membuat aturan Discovery baru dengan konteks:

gambar

Prototipe Item Baru juga dengan konteks

gambar

Dan dua pemicu - yang pertama - untuk alarm jika tetangga dalam keadaan apa pun kecuali LENGKAP:

gambar

dan yang kedua - jika tetangga hilang:

gambar

Source: https://habr.com/ru/post/id417813/


All Articles