guzik » SNMP

O (Net-)SNMP jeszcze trochę

guzik — Sun, 18 Dec 2011 13:36:38 +0000

O SNMP pisałem już kilka razy. Tym razem notka o rozszerzeniu możliwości serwera (Net-SNMP) i prezentacji danych we własnych OID’ach.

Najprościej wykonać to można dodając do konfiguracji dyrektywę extend (kiedyś exec lub sh). Składnia wygląda tak:

extend [MIBOID] NAME PROG ARGS

A na przykładzie:

extend .1.3.6.1.4.1.31337 Test /root/scripts/test.sh testarg1

Przy okazji pozdrawiam firmę Union & Comstar, której PEN (Private Enterprise Number) pożyczyłem :-)
Wadą tego rozwiązania jest fakt, że każdy wynik zwracany przez zewnętrzny program (printf czy echo) traktowany jest jak STRING. Gdy chcemy uzyskać INTEGER możemy wprawdzie posłużyć się kodem wyjścia, ale mamy do dyspozycji zakres 0-255. Do pomiaru temperatury w serwerowni czy na procesorze się może przyda, ale do sprawdzenia pamięci wykorzystywanej przez dany proces już niekoniecznie.

Net-SNMP umożliwia nam wykorzystanie Perl’a – a konkretnie modułu NetSNMP::agent, do tworzenia własnych wtyczek (chyba dla Python też jest wsparcie).
Jako że kiepski ze mnie programista, a w szczególności programista Perl, postaram się wspierać swój przekaz kodem. I tak stworzenie agenta możemy wykonać następująco:

use NetSNMP::agent;
my $agent = new NetSNMP::agent();

Następnie tworzymy funkcję i rejestrujemy ją, by użyć przy wywołaniu konkretnego OID’a:

sub callback_function { my ($handler, $registration_info, $request_info, $requests) = @_; my $request; for($request = $requests; $request; $request = $request->next()) { my $oid = $request->getOID(); if ($oid == new NetSNMP::OID(".1.3.6.1.4.1.31337.1.1.0")) { $request->setValue(ASN_INTEGER, hex(substr $valstring, 4, 2)-40); } }
$agent->register("callback function", ".1.3.6.1.4.1.31337.1", \&callback_function);

Funkcja jest wywoływana z czteroma parametrami: HANDLER, REGISTRATION_INFO, REQUEST_INFO, i REQUESTS. REQUEST_INFO może zawierać dwa tryby – MODE_GET i MODE_GETNEXT. Oczywiście przy jednokrotnym sprawdzaniu OID’a (np. przez Cacti) nie ma to znaczenia, ale gdybyśmy chcieli sprawdzić całe drzewo używając np. snmpwalk, to przy MODE_GETNEXT musimy podać adres kolejnego OID’a, który ma być sprawdzony po bieżącym. W przeciwnym razie snmpwalk skończy odczyt.

$request->setOID(".1.3.6.1.4.1.31337.1.1.1");

W odpowiedzi agent może zwrócić jeden spośród dwudziestu typów danych. Ja używam jedynie ASN_INTEGER i ASN_OCTET_STR. Resztę można znaleźć w dokumentacji.

Po stworzeniu modułu dodajemy jego wywołanie do Net-SNMP w pliku snmpd.conf:

perl do "/root/scripts/test.pl"

Następnie restartujemy demona i możemy odczytywać nasze dane. Należy pamiętać, że po każdej zmianie wtyczki niezbędne jest ponowne przeładowanie.

Czytaj też:

SNMP – co potrafi moje urządzenie?

guzik — Wed, 14 Dec 2011 04:00:09 +0000

SNMP (Simple Network Management Protocol) to protokół służący do zarządzania urządzeniami sieciowymi. Za pomocą SNMP możemy pobierać informacje z urządzenia (Get, GetNext) lub wysyłać do niego konfigurację (Set). Urządzenia same również mogą się komunikować z nami wysyłając sygnał (Trap) do serwera SNMP.
Każdy komunikat to osobna zmienna – tzw. OID (Object IDentifier). Zmienne tworzą bazę zwaną MIB (Management Information Base), w której rozmieszczone są w strukturze drzewiastej. Nazwa zmiennej ma odwzorowanie na adres w postaci numerycznej, gdzie każdy poziom oddzielony jest kropką. Np.:

sysDescr.0 (1.3.6.1.2.1.1.1.0) – nazwa urządzenia,
sysUpTimeInstance (1.3.6.1.2.1.1.3.0) – czas od uruchomienia,
sysLocation.0 (1.3.6.1.2.1.1.6.0) – lokalizacja.

Zmienne przechowują konkretny rodzaj danych. Dla powyższych będzie to odpowiednio STRING, Timeticks i ponownie STRING. Mogą występować również inne typy, np. INTEGER, Gauge32 czy Counter32. W szczególnym przypadku możemy dostać zmienną typu OID czyli wskazanie na adres w drzewie.
Więcej na temat SNMP można znaleźć w RFC 1157. Ja chciałbym się skupić na tym ostatnim typie, bo to jest odpowiedź na tytułowe pytanie.

Istnieje specjalny OID, który jest wskazaniem na gałąź zawierającą zmienne dotyczące konkretnego modelu sprzętu danego producenta. W sysObjectID.0 (1.3.6.1.2.1.1.2.0) znajduje się OID, pod którym należy szukać szczególnych danych dotyczących konkretnego urządzenia. To co dostajemy w standardzie (np. za pomocą zwykłego odczytu snmpwalk) to ogólnie zdefiniowane wartości, tak jak wspomniane wcześniej nazwa urządzenia, lokalizacja czy ruch na interfejsach sieciowych. Dopiero to, na co wskazuje sysObjectID.0 może wyciągnąć z naszego urządzenia dane, których szukamy.

W sysObjectID.0 może znajdować się np. taka wartość: enterprises.211.1.21.1.60 (1.3.6.1.4.1.211.1.21.1.60). Jak widać część jest rozwiązywana na tekst, a część pozostaje w postaci numerycznej (używam snmpwalk). Dzieje się tak dlatego, że pierwszy człon po nazwie to identyfikator producenta (a później jego gałęzie), o których snmpwalk nic nie wie. Identyfikatory nadawane są producentom sprzętu (takim jak Royal Bank of Canada czy Samodzielny Publiczny Centralny Szpital Kliniczny :>) przez IANA, a ich lista jest publicznie dostępna.

Dwa piwa dla pierwszej osoby, która w komentarzu opisze w jaki sposób zdobyć swój numer, cztery dla tego kto znajdzie się w bazie do końca roku (chyba, że czas na umieszczenie jest dłuższy; na dzień dzisiejszy jest tam niespełna 1% firm, czyli ~300, których adres kontaktowy kończy się na „.pl”).

Kiedyś w artykule Xerox Phaser 6180DN jako czujnik temperatury i wilgotności opisałem moją walkę o wyciągnięcie wskazań temperatury i wilgotności z czujników wewnętrznych drukarki. Nie pamiętam czy posłużyłem się SNMP i gałęzią odpowiednią dla tego modelu. Teraz nie mam już pod ręką tego modelu. Piwo dla osoby, która sprawdzi czy może to tam jest.

Jeśli nie potrafimy się odnaleźć w specyficznych wartościach zwracanych przez urządzenie, można posiłkować się bazą opisową dostarczaną przez producentów sprzętu. Plik taki kopiujemy do /usr/share/snmp/mibs, a następnie przy wywołaniu snmpwalk czy snmpget podajemy nazwę bazy (jedna z pierwszych linii, tuż przed DEFINITIONS ::= BEGIN; często też nazwa samego pliku), np. tak:

snmpget -On -c public -v 1 -m FJDARY-E60 host fjdaryPfcmCount.0

Przy okazji – przełącznik -On nie rozwiązuje nazw i pokazuje je w postaci numerycznej.
Jeśli producent bazy nie dostarcza (niestety zdarzają się tacy) pozostaje nam samodzielne zgadywanie.

Zobacz także:

Using SNMPwalk and a vendor MIB file

Chcecie kaktusów? To macie – czyli Cacti i dane pobierane przez SNMP

guzik — Tue, 13 Sep 2011 19:56:14 +0000

Jak narysować wykres dowolnego OID? Nic prostszego – w ustawieniach Cacti (console) wybieramy z menu New Graphs. Następnie na formularzu po prawej stronie wybieramy żądaną maszynę, a z szablonów – SNMP – Generic OID Template i zatwierzamy przyciskiem Create. Na koniec uzupełniamy formularz dotyczący konkretnego wykresu, w którym podajemy OID, z którego pobierane będą dane numeryczne.
Po więcej szczegółów odsyłam do Graph a Single SNMP OID.

Co w przypadku, gdy wartość, którą chcemy zwizualizować trzeba poddać pierw jakiejś operacji matematycznej (np. podzielić przez 10 jak w przypadku napięcia baterii w UPS Sentry z modułem NetMan)? Otóż w takim przypadku najlepiej stworzyć swój własny szablon.
Ja wybieram jako źródło wspomniany SNMP – Generic OID Template, kopiuję go (Graph Templates -> Choose an action -> Duplicate) i zmieniam wg uznania. Funkcję matematyczną podajemy już w edycji szablonu, a stosuje się ją do konkretnego elementu wykresu (Graph Item -> CDEF Function).
Domyślnie jest kilka funkcji – np. mnożenie przez 1024 (Multiply by 1024) lub zamiana bajtów w bity (mnożenie przez 8; Turn Bytes into Bits), ale nic nie stoi na przeszkodzie, by stworzyć własną (lub najszybciej – skopiować istniejącą). Robi się to w Management -> Graph Management -> CDEFs. Konstrukcja jest prosta, polecam naukę z dostarczonych przykładów.

OK, przytoczony w przykładzie UPS podaje obciążenie każdej (spośród trzech) faz osobno. Jak zobaczyć je wszystkie na jednym wykresie, by można było między sobą łatwo porównać? Jest wiele dróg, którymi można dojść do tego celu. Proponuję stworzyć Data Template dla każdego OID, którego wartość chcemy umieścić na wykresie i podłączyć to w szablonie wykresu jako kolejny element.
Można też przypisać wiele szablonów SNMP – Generic OID Template i przy tworzeniu konkretnego wykresu podawać żądany OID (szablon ma zaznaczoną opcję Use Per-Data Source Value). Pierwszy sposób, to wg mnie mniej klikania przy dodawaniu nowego urządzenia w przyszłości, no i zawsze możemy taki gotowy szablon wyeksportować, by pochwalić się nim społeczności.

I na koniec polecam przejrzenie gotowych szablonów dostarczonych wraz z Cacti. Na ich podstawie dobrze się uczyć tworzenia własnych.

UPS Aros & SNMP

guzik — Fri, 02 Sep 2011 22:08:58 +0000

W temacie monitoringu pisałem już wielokrotnie, tym razem informacja jak czuwać nad parametrami pracy zasilaczy awaryjnych firmy Aros.

Mam pod opieką modele Sentry ST60 z modułem NetMan 101/102 plus. Moduł umożliwia odczyt niezbednych wartości przez prostą stronę WWW lub za pomocą protokołu SNMP. Oczywiscie dla Nagios lub Cacti przyda się ten drugi sposób.
Poniżej odpowiednie identyfikatory (OID) wraz z opisem i sposobem wykorzystania.

.1.3.6.1.2.1.33.1.2.3.0 szacowany czas podtrzymania (w minutach)
.1.3.6.1.2.1.33.1.2.4.0 naładowanie baterii w procentach
.1.3.6.1.2.1.33.1.2.5.0 napięcie baterii (dziesięciokrotność)
.1.3.6.1.2.1.33.1.2.7.0 temperatura pracy urządzenia
.1.3.6.1.2.1.33.1.3.3.1.2.1 częstotliwość napięcia wejściowego, pierwsza faza (dziesięciokrotność)
.1.3.6.1.2.1.33.1.3.3.1.2.2 częstotliwość napięcia wejściowego, druga faza (dziesięciokrotność)
.1.3.6.1.2.1.33.1.3.3.1.2.3 częstotliwość napięcia wejściowego, trzecia faza (dziesięciokrotność)
.1.3.6.1.2.1.33.1.3.3.1.3.1 napięcie wejściowe, pierwsza faza
.1.3.6.1.2.1.33.1.3.3.1.3.2 napięcie wejściowe, druga faza
.1.3.6.1.2.1.33.1.3.3.1.3.3 napięcie wejściowe, trzecia faza
.1.3.6.1.2.1.33.1.4.2.0 częstotliwość napięcia wyjściowego (dziesięciokrotność)
.1.3.6.1.2.1.33.1.4.4.1.2.1 napięcie wyjściowe, pierwsza faza
.1.3.6.1.2.1.33.1.4.4.1.2.2 napięcie wyjściowe, druga faza
.1.3.6.1.2.1.33.1.4.4.1.2.3 napięcie wyjściowe, trzecia faza
.1.3.6.1.2.1.33.1.4.4.1.5.1 procentowe obciążenie wyjścia, pierwsza faza
.1.3.6.1.2.1.33.1.4.4.1.5.2 procentowe obciążenie wyjścia, druga faza
.1.3.6.1.2.1.33.1.4.4.1.5.3 procentowe obciążenie wyjścia, trzecia faza
.1.3.6.1.2.1.33.1.5.1.0 częstotliwość bajpasu (dziesięciokrotność)
.1.3.6.1.2.1.33.1.5.3.1.2.1 napięcie bajpasu, faza pierwsza
.1.3.6.1.2.1.33.1.5.3.1.2.2 napięcie bajpasu, faza pierwsza
.1.3.6.1.2.1.33.1.5.3.1.2.3 napięcie bajpasu, faza pierwsza

Dołączenie szacowanego czasu podtrzymania i temperatury pracy urządzenia do konfiguracji Nagios:

define command{ command_name check_snmp command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o $ARG1$ -C $ARG2$ -P $ARG3$ $ARG4$ }
define service { use generic-service host_name UPS service_description UPS Autonomy Time check_command check_snmp!mib-2.33.1.2.3.0!public!2c!-w 15:9999 -c 2:9999 }
define service { use generic-service host_name UPS service_description UPS Temperature check_command check_snmp!mib-2.33.1.2.7.0!public!2c!-w 20:25 -c 15:32 }

Monitorowanie czasu podtrzymania jest zrozumiałe, progi jakie ustawiłem, to 15 min dla ostrzeżenia i 2 minuty dla błędu krytycznego. Poniżej tego czasu generator, z którym współpracują może nie być w stanie się uruchomić. Oczywiście te parametry trzeba dopasować do swojej struktury. Należy pamiętać, że ta wartość to szacowany czas na podstawie obciążenia w momencie pomiaru.

Jeśli chodzi o temperaturę, to odczyt z tego OID da nam przybliżoną wartość dla okolic urządzenia, gdzie zazwyczaj stoją baterie, których to producenci zalecają 20 – 22 stopni Celsjusza. Naturalnie można to sprawdzać innym urządzeniem, ale skoro producent zamontował czujnik w UPS, to czemu by z niego nie skorzystać.
Temperatura ma duży wpływ na żywotność ogniw, więc warto utrzymywać ją w odpowiednim zakresie i zapewnić wentylację pomieszczenia, w którym się znajdują.
Organizacja ASHARE (American Society of Heating, Refrigerating and Air-Conditioning Engineers) wydała dokument pt. Thermal Guidelines for Data Processing Environments, w którym opisane są warunki, jakie powinny panować m. in. w serwerowni. Esencja z niego została zawarta w polskojęzycznym artykule, który na swojej stronie prezentuje firma EP&M.

Monitorowanie systemów Windows w Cacti

guzik — Thu, 17 Dec 2009 13:27:11 +0000

Oprócz monitorowania wartości progowych różnych systemów za pomocą Nagios, pojawiła się potrzeba sprawdzania ich dobowego obciążenia. Cacti, z którym miałem już wcześniej styczność, okazał się wystarczający. Ładnie wygląda i ma dużo fajnych wodotrysków :-)

Konfiguracja jest intuicyjna, przez co banalna. Wszystkie wartości, które mnie interesują można odczytać ze zdalnych systemów przez SNMP, a to daje duże możliwości – od przełączników sieciowych, poprzez serwery *nix i Windows do drukarek i innych urządzeń. Poniżej krótki przepis jak podłączyć system Windows do Cacti.

Niezbędne będzie doinstalowanie usługi SNMP (jest w składnikach Windows – Monitorowanie i zarządzanie). Można to zrobić zarówno na stacji roboczej (próbowałem na Windows XP), jak i na serwerze. Po pełny opis odsyłam do stron Microsoft: HOW TO: Configure the Simple Network Management Protocol (SNMP) Service in Windows Server 2003.
Lista plików, które są niezbędne do zainstalowania tej usługi (nie zawsze napęd jest dostępny, więc można skopiować tylko te):

Microsoft Windows Server 2003 wersja 32 bit

i386\accserv.mi_ i386\authserv.mi_ i386\dhcp.mi_ i386\evntagnt.dl_ i386\evntcmd.ex_ i386\evntwin.ex_ i386\ftp.mi_ i386\hostmib.dl_ i386\hostmib.mi_ i386\http.mi_ i386\inetsrv.mi_ i386\ipforwd.mi_ i386\lmmib2.dl_ i386\lmmib2.mi_ i386\mcastmib.mi_ i386\mib_ii.mi_ i386\mipx.mi_ i386\mripsap.mi_ i386\msft.mi_ i386\msipbtp.mi_ i386\msiprip2.mi_ i386\nipx.mi_ i386\rfc2571.mi_ i386\smi.mi_ i386\snmp.ex_ i386\snmpmib.dl_ i386\snmptrap.ex_ i386\wfospf.mi_ i386\wins.mi_

Microsoft Windows Server 2003 wersja 64 bit

amd64\accserv.mi_ amd64\authserv.mi_ amd64\dhcp.mi_ amd64\evntagnt.dl_ amd64\evntcmd.ex_ amd64\evntwin.ex_ amd64\ftp.mi_ amd64\hostmib.dl_ amd64\hostmib.mi_ amd64\http.mi_ amd64\inetsrv.mi_ amd64\ipforwd.mi_ amd64\lmmib2.dl_ amd64\lmmib2.mi_ amd64\mcastmib.mi_ amd64\mib_ii.mi_ amd64\mipx.mi_ amd64\mripsap.mi_ amd64\msft.mi_ amd64\msipbtp.mi_ amd64\msiprip2.mi_ amd64\nipx.mi_ amd64\rfc2571.mi_ amd64\smi.mi_ amd64\snmp.ex_ amd64\snmpmib.dl_ amd64\snmptrap.ex_ amd64\wfospf.mi_ amd64\wins.mi_ i386\wsnmp.ex_

Microsoft Windows XP Professional wersja 32 bit

i386\accserv.mi_ i386\authserv.mi_ i386\dhcp.mi_ i386\ftp.mi_ i386\hostmib.mi_ i386\http.mi_ i386\inetsrv.mi_ i386\ipforwd.mi_ i386\lmmib2.mi_ i386\mcastmib.mi_ i386\mib_ii.mi_ i386\mipx.mi_ i386\mripsap.mi_ i386\msft.mi_ i386\msipbtp.mi_ i386\msiprip2.mi_ i386\nipx.mi_ i386\smi.mi_ i386\wfospf.mi_ i386\wins.mi_

Tak jak podano we wspomnianej dokumentacji – do odczytów niezbędne będzie podanie nazwy wspólnoty (community) oraz hostów, z których akceptujemy żądania (w oknie właściwości usługi SNMP). I już!