Monitoring pomocí nástrojů z balíku Net-SNMP

17. 1. 2007 | Lukáš Zapletal | Systém | 21527×

Protokol SNMP umožňuje monitorovat a konfigurovat libovolná zařízení, která jej podporují. Veliký význam to má v oblasti sítí, internetu, počítačů a různých jiných hardwarových zařízení (od špičkových přepínačů firmy Cisco až po kávovary s ethernetovou přípojkou).

Článek byl vydán ve spolupráci s časopisem LinuxEXPRES.

---

Standardním balíkem pro práci s protokolem SNMP je v linuxových systémech Net-SNMP. Není samozřejmě jediný, ale já si ho vybral pro dobrou stabilitu, škálovatelnost a širokou možnost rozšiřování. Je k dispozici na mnoha distribucích jako binární balíček, tudíž je instalace hračkou. Obsahuje jak SNMP démona, tak i nástroje pro dotazování a nastavování hodnot.

Základní konfigurace

Po instalaci je na mnoha distribucích konfigurace nastavena přísně -- v podstatě není povoleno nic, nebo maximálně čtení větve .iso.org.dod.internet.mgmt.mib-2.system (SNMPv2 MIB) přes community string "public". Vrhněme se tedy na úpravu konfiguračního souboru tak, aby SNMP démon vracel nějaké ty zajímavé hodnoty (vytížení procesoru, paměť, volné místo na svazcích atd).

Nebudu zde popisovat samozřejmé konfigurační hodnoty, jako je například port nebo rozhraní, na kterém má démon naslouchat, či snad efektivního uživatele pro běh. Snad jen upozorním, abyste při nastavování firewallu nezapomněli, že protokol SNMP běhá na UDP (port 161).

Nejzákladnější konfigurace bezpečnosti se provádí pomocí rouser/rwuser resp. rocommunity/rwcommunity. Můžete jednoduše specifikovat, které community řetězce a kteří uživatelé (vizte níže) mohou přistupovat do jakých částí stromu. Typicky se může použít například nastavení, které povolí přístup pouze pro čtení pro celou MIB databázi ze sítě 10.10.10.0 s community řetězcem "tajnyklic":

rocommunity tajnyklic 10.10.10.0/24

Je nutné si uvědomit, že toto není zrovna nejbezpečnější nastavení pro zápisy (vzdálenou konfiguraci), tudíž lze tento přístup doporučit jen pro read-only přístup, tedy jednoduchý monitoring. Pokud si ani nechcete pamatovat tajný klíč, použijte "public", což je implicitní klíč, který klienty obvykle předpokládají.

Protokol SNMPv3 přidal pokročilejší podporu pro autentifikaci i autorizaci (tzv. VACM). Pro tyto účely nastudujte konfigurační hodnotu createUser (pokud byste chtěli přidávat jednotlivé uživatele). Nám však postačí přístup přes community řetězce, takže využijeme místo rocommunity (a podobných) příkazů spíše ty nové, které je dobře zastoupí: com2sec, group, view a access.

Tyto konfigurační hodnoty umožňují namapovat community řetězce na skupiny a těmto skupinám umožnit pohledy (view) do MIB stromu (access). Typická přednastavená konfigurace u většiny linuxových distribucí je:

#com2sec paranoid  default         public
#com2sec readonly  default         public
#com2sec readwrite default         private

group MyROSystem v1        paranoid
group MyROSystem v2c       paranoid
group MyROSystem usm       paranoid
group MyROGroup v1         readonly
group MyROGroup v2c        readonly
group MyROGroup usm        readonly
group MyRWGroup v1         readwrite
group MyRWGroup v2c        readwrite
group MyRWGroup usm        readwrite

view all    included  .1                               80
view system included  .iso.org.dod.internet.mgmt.mib-2.system

access MyROSystem ""   any   noauth   exact  system none   none
access MyROGroup ""    any   noauth   exact  all    none   none
access MyRWGroup ""    any   noauth   exact  all    all    none

Jsou k dispozici tři mapování: nejomezenější, které zobrazuje pouze mib-2.system větev; pouze pro čtení (celý strom); kompletní přístup do celého stromu (včetně zápisu). Stačí odkomentovat první, druhý resp. třetí řádek v konfiguraci. Pokud chcete monitorovat linuxový server, odkomentujte druhý řádek, změňte community string (klíč) a eventuálně připište rozsah IP adres, ze kterých bude čtení hodnot povoleno:

com2sec readonly default 10.10.10.0/24 tajnyklic

V následujícím textu budu předpokládat, že máte povolen přístup pro čtení z localhostu s community řetězcem "public".

Takže abych to shrnul -- stačí nainstalovat balíček net-snmp a odkomentovat (resp. modifikovat) jeden řádek. Je možné efektivně namapovat community řetězce a uživatelské účty na jednotlivé pohledy. K dispozici jsou také uživatelské skupiny, takže možnosti jsou široké.

Monitoring systému

Díky databázi HOST-RESOURCES-MIB můžete získávat hodnotné informace o systému, na kterém běží SNMP démon. Ten tyto informace zjišťuje automaticky a není třeba nic konfigurovat -- stačí pouze povolit přístup k dané větvi (pokud jste tedy odkomentovali v konfiguraci druhý řádek, jak jsem radil).

A jak tyto informace získáte? V balíku Net-SNMP je připraven řádkový klient, se kterým můžete pohodlně pracovat. Automaticky načítá všechny MIB soubory v distribuci a výsledky přehledně zobrazuje. Podívejme se, co všechno nám SNMP server poskytne:

snmpwalk -v 1 -c public localhost \
iso.org.dod.internet.mgmt.mib-2.host

Jelikož je to poměrně dost informací (v závislosti na tom, kolik máte spuštěných procesů, připojených svazků a podobně), výstup vám nejspíše "uteče" z obrazovky. Můžete se dotazovat na konkrétní hodnoty, například uptime systému: iso.org.dod.internet.mgmt.mib-2.host.hrSystem.hrSystemUptime, kde by odpověď mohla být:

HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (54741321)12:13:14.15

Doplňující systémové informace

Démon z balíku Net-SNMP může poskytovat dodatečné informace o systému, které nejsou součástí větve HOST-RESOURCES-MIB. Jsou nadefinovány v souboru UCD-SNMP-MIB (Net-SNMP se dříve jmenoval UCD-SNMP). Pomocí této nové větve (iso.org.dod.internet.private.enterprises.ucdavis) můžete získávat detailnější informace o procesoru, o konkrétních procesech, paměti, disku, zátěži a souborech (včetně možnosti sledování logů pomocí regulárních výrazů). Veškeré poskytované informace lze dodatečně konfigurovat, popis je v sekci SYSTEM INFORMATION manuálové stránky pro snmpd.conf.

Tyto informace získáte příkazem snmpwalk -v 1 -c public localhost \
iso.org.dod.internet.private.enterprises.ucdavis

Kromě UCD-SNMP-MIB ve výpisu uvidíte také další informace z MIB souborů UCD-DISKIO-MIB nebo UCD-DLMOD-MIB. To jsou experimentální měření, která budou později patrně zařazeny do hlavní větve.

Pokud by vám nevoněla příkazová řádka, můžete si nainstalovat grafického klienta tkmib, ale jelikož se jedná o Perl/TK, tak z tohoto programu určitě nebudou nadšeni uživatelé vyžadující eye-candy vzhled. No a nic vám nebrání v použití profesionálních SNMP nástrojů, které se dají koupit pro Windows, MacOS i Linux.

Rozšiřování o nové funkce

Co by to bylo za SNMP daemona, kdyby uměl poskytovat jen pár informací o systému. Pokud jste k počítači připojili hardwarový teploměr, jistě by bylo záhodno naměřené teploty zveřejňovat pomocí SNMP. Nebo máte aplikaci, kterou je třeba monitorovat či dokonce vzdáleně konfigurovat. I na to se SNMP perfektně hodí.

Nejjednodušší variantou je konfigurační volba exec, která zajistí spuštění skriptu a jeho výstup, návratovou hodnotu a další údaje exportuje ve větvi iso.org.dod.internet.private.enterprises.ucdavis.extTable. Například konfigurace

exec echotest /bin/echo hello world

by způsobila exportování následujících hodnot:

$ snmpwalk -v 1 -c public localhost .1.3.6.1.4.1.2021.8
UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
UCD-SNMP-MIB::extNames.1 = STRING: echotest
UCD-SNMP-MIB::extCommand.1 = STRING: /bin/echo hello world
UCD-SNMP-MIB::extResult.1 = INTEGER: 0
UCD-SNMP-MIB::extOutput.1 = STRING: hello world
UCD-SNMP-MIB::extErrFix.1 = INTEGER: 0
UCD-SNMP-MIB::extErrFixCmd.1 = STRING:

Pro zkrácení výstupu jsem použil číselný zápis zmíněného OIDu (ucdavis.extTable). Takto si můžete nadefinovat množství skriptů, SNMP server naměřené hodnoty uchovává v paměti cache po dobu 30 sekund (toto chování lze ovlivnit SNMP set příkazem). Pomocí parametru MIBOID můžete také změnit větev, ve které budou ext* hodnoty exportovány.

Existuje několik variant příkazu exec (sh, extend, extendfix), ale v podstatě dělají podobnou práci (jen jinak exportují výsledky). Jenže co kdybyste potřebovali si vytvořit vlastní větev se specifickou strukturou (nebo využít některý ze standardních MIB souborů)? I v takovém případě má Net-SNMP řešení.

Tím je konfigurační hodnota pass a pass_persist. Má dva parametry: kořen substromu, který bude mít skript na starosti, a cestu k samotnému skriptu. Pomocí parametrů -g, -n a -s daemon zjišťuje resp. nastavuje hodnoty (GET, GETNEXT a SET), program musí pomocí standardního výstupu na třech řádcích vracet postupně OID, typ hodnoty a vlastní hodnotu (v případě SET se jen ukončí případně vypíše chybu).

Volba pass_persist funguje jen trošičku odlišně -- daemon s programem komunikuje pomocí standardního vstupu a očekává, že se program po přečtení hodnot hned neukončí. Toto výrazně zvyšuje výkon, protože se nemusí pro každou hodnotu spouštět nová instance programu.

Mezi další možnosti rozšiřování patří vkládaný interpret Perlu (ten se ale obvykle v binárních distribucích balíku nenachází), dynamicky nahrávaná knihovna (dlmod) nebo program komunikující se serverem po lokálním socketu protokolem AgentX (v balíku Net-SNMP zatím označeno jako experimentální).

Management Information Base

Pokud chcete rozšiřovat SNMP o vlastní objekty, musíte vytvořit takzvaný MIB soubor. Bez něj server neví, jaké hodnoty (OIDy) má pomocí skriptů zjišťovat. Psaní MIB souborů je tak trochu alchymie -- používá se zde poněkud "ukecaná" a nepřehledná notace a dokumentace ohledně tvorby vlastních MIBů je na internetu jako šafránu.

Pro své účely si můžete zdarma zaregistrovat vlastní "jmenný prostor" ve větvi enterprises přidělované společností IANA. Poté definujete vlastní struktury, které lze pomocí MIB vytvořit: objekty (listové, sloupcové), tabulky, řádky. K tomuto účelu lze použít nějaký z profesionáloních nástrojů pro tvorbu MIB databází, ale jelikož jsou tyto programy poměrně drahé a MIB jsou obyčejné textové soubory, postačí textový editor (např. Vim zvýrazňuje syntaxi, pokud má soubor příponu .mib).

Není účelem tohoto textu proniknout do tajů tvorby MIB, proto mohu pouze odkázat na článek Understanding SNMP MIBs, David Perkins, 1998 a knihu Understanding SNMP MIBs, David Perkins a Evan McGinnis o této problematice.

Pokud vytvoříte vlastní MIB soubor a distribuujete jej klientským programům (v případě snmpwalk je to /usr/share/snmp/mibs), programy budou hodnoty zobrazovat přehledně, včetně popisů (a pro nastavování budou také kontrolovat správnost vstupů).

Závěr

Co mi v balíku Net-SNMP chybělo, byla možnost dynamické správy skupin, uživatelů a pohledů (např. přímo pomocí SNMP). Jedinou možností je prozatím zásah do konfiguračního souboru a možnost rozšiřování v této oblasti bohužel zatím žádná není.

Vůbec jsem se nevěnoval oblasti aktivního monitoringu (tzv. trapping), kdy server sám rozesílá informace. I zde jsou u Net-SNMP poměrně široké možnosti.

Pro sběr informací ze serveru můžete využít některou z webových aplikací, například Nessus, MRTG nebo Cacti. Tyto programy jsou schopny napsat vám například SMS, když dojde k nějaké neočekávané události (zaplnění disku, pád aplikace).

       

Komentáře

[petr_p]

Rad bych doplnil, ze SNMP je uzpusobeno k prenosu nad nespolehlivym kanalem. Z toho duvodu funguje treba i nad Ethernetem. Takze neni problem komunikovat se zarizenimi, ktere nemaji ani IP adresu.

[DjAARA]

Ano, UDP je opravdu vhodné na komunikaci po nespolehlivém kanále. A porty 161, 162 taky budou určitě dostupné nad čistým ethernetem a bez IP adresy.

OMG

[petr_p]

Samozrjme, ze UDP porty nepotrebuji, kdyz nechci UDP.

Doporucuji k nahlednuti 5. kapitolu RFC 1270, pripadne specifikaci SNMP nad Ethernetem v podobe RFC 1089 nebo RFC 1161, kde se rozepira adresace na jinych transportnich protokolech. Dale mame SNMP nad IPX (RFC 1420) atd.

[Kadži]

Zvláštní, že si toho za tři dny nikdo nevšiml, ale v kapitole „Monitoring systému“ je v adrese odkazu znak navíc.

[Robert Krátký]

Dík, opraveno.