Monitoring sítě - Observium a LLDP

29.11.2016 10:38 | Přečteno: 3750× | Za vším hledej Linux |

Kolega už delší čas monitoruje switche i jiná zařízení přes Observium, které si z nich vytahuje data přes SNMP. Ty následně analyzuje a zpracovává do nejrůznějších tabulek a grafů. Mně se obzvláště zalíbilo, že Observium umí zpracovat také informace o síťových portech. Napadlo mě, že by nebylo špatné takto monitorovat i linuxové stroje. Trochu jsem zapídil po netu a po rozběhání mne výsledek nadchnul natolik, že jsem se rozhodl o něj s vámi podělit prostřednictvím tohoto blogpostu.

Agent (server), který je dotazován přes SNMP protokol je pasivní. Tzn. že nedělá nic, dokud mu nepřijde SNMP dotaz - teprve na jeho základě zjistí odpovídající informace a odešle zpět.

Součástí dotazu je tzv. OID (Object Identifier) - řetězec čísel oddělených tečkami, který představuje dotazovanou větev informačního stromu. Čím víc je OID specifikovaný (a delší), tím menší objem informací SNMP démon vrací.

U debianu jsou v konfiguračním souboru /etc/snmp/snmpd.conf ve výchozím stavu nakonfigurovány tyto OID řetězce:

view   systemonly  included   .1.3.6.1.2.1.1
view   systemonly  included   .1.3.6.1.2.1.25.1

Tyto (a další) OID řetězce jsou definovány prostřednictvím MIB souborů. Pokud stroj dotazovaný přes SNMP nemá příslušný MIB (Management information base) k dispozici, nezná ani informace pro příslušné OID.

Problém u SNMP je, že pokud je OID příliš obecný, nemusí agent vracet všechna data najednou. Monitorování přes SNMP se nehodí pro sledování stroje v reálném čase, protože agent vyžaduje na zpracování dotazu určitý čas. Také je nutné aby se klient v pravidelných intervalech sám aktivně dotazoval serveru, a tato komunikace mohla v minulosti - v případě většího počtu strojů - generovat provoz, který je ovšem z dnešního hlediska víceméně zanedbatelný.

SNMP protokol v současné době existuje ve třech verzích:

• SNMP v1 - je původní implementace, která se objevila ve formě RFC r. 1988. Klient se jeho prostřednictvím dotazuje agenta, který běží jako server a pasivně čeká na dotazy, a ten mu obratem vrací odpovídající informace. Klíčový problém této verze byl především v tom, že neuměla dotazy a odpovědi agregovat, komunikace probíhala pouze jednosměrně (žádné potvrzení o příjmu) a jen s chatrným zabezpečením - pro ověření klienta vůči serveru používá pouze tzv. "communtity string", textový řetězec, kterým se klient ověřuje vůči serveru. Defakto plaintextové heslo, které se volně motá po síti.
• SNMP v2c - Objevilo se několik verzí, které měly problémy SNMPv1 vyřešit. Oficiální verze 2 se objevila v dubnu 1993, ovšem implementace zvoleného modelu zabezpečení byla příliš komplikovaná, proto se místo něj ujala komunitní verze, která implementovala vše, mimo něj.
• SNMP v3 - Bylo ve formě RFC přijato r. 2004. A řeší tři základní problémy komunitní verze: Ověřování, zabezpečení komunikace a zajištění integrity přenášených dat.

K tomu, aby bylo možné přes Observium monitorovat linuxový stroj, stačí doinstalovat a nakonfigurovat snmpd démona. U distribucí co používají APT stačí:

apt-get install snmpd

Ve výchozím stavu naslouchá SNMP démon pouze na localhostu, pro monitorování přes Observium je třeba změnit konfiguraci tak, aby naslouchal dotazům zvenčí a doplnit základní údaje (sysLocation, sysContact, sysDescr)

LLDP

Cílem tohoto blogpostu ale není podrobně rozebírat konfiguraci SNMP, ale upozornit na LLDP (Link Layer Discovery Protocol), otevřenou verzi protokolu, jehož prostřednictvím si mezi sebou mohou po síti vyměňovat sousedící zařízení informace o názvu síťového zařízení, verzi jeho softwaru, nastavení IP, VLAN apod.

Pro linux totiž existuje softwarová implementace LLDP (Link Layer Discovery Protocol) - démon lldpd - který umí spolupracovat se SNMP démonem. Instalace je jednoduchá a nevyžaduje mnoho závislostí.:

apt-get install lldpd

Aby spolupracoval se snmp, musí být démon lldpd spuštěn s příslušnými parametry - k tomu stačí odkomentovat nastavení proměnné DAEMON_ARGS v souboru /etc/default/lldpd. A konfiguraci SNMP démona rozšířit o následující OID řetězce:

view   systemonly  included   .1.0.8802
view   systemonly  included   .1

Pak, po restartu, začne SNMP vracet informace, které umí Observium zpracovat a vizualizovat. Ilustrační obrázky, jak taková vizualizace vypadá jsou v příloze.

K čemu je to dobré?

na to, že pokud doinstalujete a spustíte také démona lldpd, bude Observium umět také vizualizovat síťové vazby mezi monitorovaným strojem a switchem (resp. dalším strojem)

Pro zařazení a popis stroje využívá Observium údaje, které mu vrací SNMP. Na straně monitorovacího stroje se nic dalšího neřeší

Spouštění virtuálních strojů zajišťuje Pacemaker, který je umí také zaživa migrovat. Řešil jsem tudíž otázku, jak zjistit kde virtuální stroj ve skutečnosti běží. Kontektivitu si však vždy bere přes openvswitch hostitele. A tak díky tomu, že Observium umí vizualizovat záznamy z LLDP, lze prakticky ihned zjistit přes jaký stroj virtuál komunikuje - tj. který stroj je aktuálním hostitelem.

V přehledu strojů lze také vizuálně snadno identifikovat, který stroj je fyzický a který virtuální. Viz obrázek v příloze, stroj charlie-brown je fyzický a drupal virtuální.

Ve výpisu síťových portů je vidět kromě jejich MAC adresy také uveden konkrétní port na switchi do kterého je zařízení připojeno. A to platí i pro virtuální porty. Ilustrační obrázek demonstruje jak to vypadá, když se o konektivitu na fyzickém stroji stará openvswitch.

Poslední, největší obrázek, pak demonstruje jak vypadá vizualizace portů a jejich zapojení.

Odkazy

• Článek o SNMP, Petra Boušky na samuraj-cz.com
• Jak číst OID (angl.)
• Článek Adama Přibyla o LLDP na root.cz
• PDF dokument Marka Pszczolky: Protokol LLDP srovnání s Cisco CDP a možnosti konfigurace na běžných platformách Cisco, Linux, Windows

       

Obrázky

Komentáře

[Max]

Taktéž jsem nad tímto přemýšlel, ale usoudil jsem, že bude lepší to řešit trochu více podrobněji globálněji (openflow, OpenNMS, Kibana ...).
Ještě uvidím, času málo, práce hodně.
Zdar Max

[vencour]

Přidal jsem do výběru.

[Vantomas]

Hmmm, to jsem neznal a moc se mi to líbí!

Bohužel demo je jen readonly, ale jak je to s definováním interfaců na daných hostech? Funguje discovery interfaců automaticky nebo se to musí definovat ručně? Jde mi o sledování WiFi AP, kde bych chtěl u jednotlivých klientů hlídat jejich úroveň signálů, bohužel SNMP ID těchto záznamů se mění podle toho v jakém pořadí se klienti připojují a pak se to musí matchovat ručně podle MAC adresy. Jak je to tedy třeba v případě těch hostů, kde se spouští virtuály a dynamicky se podle toho mění interfacy, které se sice jmenují ethX, ale opět záleží na pořadí, ve kterém se virtuály spouštěly? Podle toho si dokážu představit jak moc to půjde přiohnout na ty wifi klienty.

[Aleš Kapica]

Vše se zjišťuje automaticky. Konfiguruje se jen to co jsem uvedl. Ovšem jak si to Observium interně přežvykuje nevím.

Rozhraní detekuje taková jaká aktuálně existují. Abych byl konkrétní - u toho openvswitche se porty zakládají při spuštění virtuálu a ruší ukončení procesu qemu. Nedělá to libvirt, ale můj agent pro Pacemaker.

[Vantomas]

A pro představu, o co mi jde, třeba takováto situace:

Mám virtuál, který je jako fileserver, při spuštění virtuálu se mu vytvoří interface eth3 a potom mám virtuál pro DNS server a ten má interface eth4. Na fileserveru se valí hromada trafficu, desítky nebo stovky megabitů, kdežto na DNS je trvale 100kbit/s. A teď provedu restart hosta, kde virtuály běží a po rebootu má fileserver eth4 a DNS server eth3, jak to vypadá na grafu trafficu v Observium? Vidím tam za posledních 24 hodin, že tam teklo stovky megabitů a najednou graf klesne a drží se to na těch 100kbit nebo to Observium pozná a graf má správnou kontinuitu a jména těch interfaců se správně přejmenují?

[MP]

Ja jsem z Observium presel na LibreNMS, coz je klon Observia. Bezi mi na tom z drivejska i monitoring Xen serveru, ktery toci interface pro VMs, toci tak 3 ciselne sety vifXX.X, co se na to ted divam. No a vysledek je ten, ze up je prave jeden aktivni set, vse ostatni je down. Takze bych predpokladal, ze ve vasem prikladu k prejmenovavani interface urcite nedojde. Ono asi zalezi na tom, jaky OID ma ta eth3 a pak eth4, pokud odlisna, neni co resit.

[Vantomas]

Hm jasně, prošlo mi to pak hlavou, že vzhledem k tomu, že to ještě spouští pacemakerem, tak to Observium nemá moc jak poznat, že je tam nějaký, stále stejný, virtuál a změnil se mu VIF. Možná ve spolupráci s libvirt by to Observium poznalo, mě to třeba u Munin+libvirt pozná a graf se ukazuje správně.