Wstęp

Jak zostało przedstawione w pierwszej części serii artykułów o monitorowaniu sieci, badanie dostępności urządzeń sieciowych out-of-the-box jest bardzo ubogie i sprowadza się do badania jednego elementu – dostępności. Żeby to jeszcze był ping… Zamiast tego mamy sprawdzanie odpowiedzi na protokół snmp specyficznego OID .1.3.6.1.2.1.1.5.0, czyli w skrócie sysName. Mamy zatem rozumieć, że jedynym wyznacznikiem dostępności urządzenia staje się prosty test snmp. A jeśli administrator wyłączy SNMP? Czy urządzenie jest wyłączone? Zapewne nie. Oczywiście możemy badać output polecenia ping do badania wszystkich urządzeń sieciowych – jest nawet gotowy Management Pack, który bardzo sprawnie sobie z tym radzi - opslogix.com/ping. Wystarczy wgrać Management Pack, podać listę urządzeń i sprawdzać, które nie odpowiada. Czy to wszystko? A stan interfejsów? Pamięć? Temperatura? Procesor? To wszystko postaramy się zmonitorować w naszej serii artykułów.

Monitory i reguły

Operations Manager jest o tyle dobrym narzędziem, że pozwala na dość szerokie spektrum rozszerzania funkcjonalności. Dla urządzeń sieciowych możemy tworzyć nowe klasy, ich atrybuty, reguły, zadania i monitory. W tym artykule zajmiemy się ostatnim rodzajem workflow – monitorami.

Często wiele osób zadaje pytanie, czym się różnią monitory od reguł. Pytanie jest dość ważne z tego powodu, że w MOM 2005 były tylko reguły. Reguły w OpsMgr służą do zbierania wszystkiego, co się rusza i pozwala na zbieranie. Możemy zatem zbierać dane wydajnościowe, zdarzenia z event log, wpisy z plików, zdarzenia WMI, informacje przekazane z syslogów lub napisać własny skrypt, który coś zwróci. Efektem ubocznym takiego zebrania może być alarm na konsoli, ale nie jest to główny cel działania reguł. Można śmiało powiedzieć, że jest to taki scentralizowany prosty harmonogram zadań.

Monitory to już zupełnie inna bajka – służą one do zapalania lampek przy obiektach, które zostały wykryte. Jeśli zatem zabraknie Wam miejsca na dysku, monitor zareaguje alarmem w konsoli i zapaleniem się czerwonej lampki przy obiekcie komputer.domena.local. Gdy tylko administrator usunie zbędne pliki, po godzinie system znów sprawdzi ilość wolnego miejsca i gdy będzie satysfakcjonująca, zgasi alarm i zmieni kolor lampki na zielony.

Co zatem może być monitorem w naszym urządzeniu sieciowym? Na przykład poziom wykorzystania procesora albo mnogość błędnych pakietów TCP na interfejsach ogółem. Przekroczenie pewnego poziomu spowoduje zapalenie się lampki na kolor żółty lub zielony. Na początek mamy jedynie dostępność:

Rysunek 1 - Monitor urządzenia sieciowego

Rysunek 2 - Widok urządzenia sieciowego w Operations Manager 2007 R2

Rozpoczynamy monitorowanie

Warto zatem zmonitorować procesor takiego urządzenia. Zużycie procesora może być zarówno zbierany jako dana wydajnościowa, jak i badany w kontekście monitora. Dzisiaj zajmiemy się monitoringiem. Na początek musimy wiedzieć, jaka zmienna OID odpowiada za monitorowanie procesora. Możemy posłużyć się poczciwą przeglądarką i znaleźć na witrynie Cisco.com odpowiadający nam artykuł. cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094a94.shtml jest jasno napisane, że nowe iOS (systemy operacyjne dla urządzeń sieciowych) obsługują trzy zmienne – zmienne dostarczają nam średnich danych z ostatnich 5 sekund, 1 minuty lub 5 minut. Dla nas do testów najlepsza będzie zmienna 1 minutowa, a więc OID .1.3.6.1.4.1.9.9.109.1.1.1.1.7.1 o nazwie cpmCPUTotal1minRev. Warto także przetestować, czy ta nasza zmienna zwraca poprawną wartość. Po instalacji pakietu Net-SNMP – dostępny za darmo w sieci – możemy wykonać polecenie:

snmpwalk –v2c –c public 192.168.100.50 .1.3.6.1.4.1.9.9.109.1.1.1.1.7.1

Polecenie to powoduje wykonanie zapytania do urządzenia o adresie 192.168.100.50, community string to „public”, wersja SNMP to 2c i OID, o który pytamy to .1.3.6.1.4.1.9.9.109.1.1.1.1.7.1. W zwrotce ujrzymy coś podobnego do

enterprises.9.9.109.1.1.1.1.7.1 = 2

Co oznacza, że obciążenie procesora w ostatniej minucie wyniosło 2%. To jest zatem to, o co nam chodziło. Przejdźmy więc do konsoli SCOM i stwórzmy nasz pierwszy monitor. Przechodzimy do panelu Authoring. Z lewego menu wybieramy prawym przyciskiem myszy Monitors i otwieramy kreator przechodząc do Create a Monitor a Unit Monitor.

Rysunek 3. Otwarcie kreatora monitoru

W oknie kreatora wybieramy typ monitora SNMP i pojedynczy monitor SNMP. Monitor zapisujemy w nowo-utworzonym Management Packu do tego celu – Cisco MP, który tworzymy na szybko klikając przycisk New i wpisując odpowiednie dane.

Rysunek 4. Wybór typu monitora

Następnie wpisujemy podstawowe dane takie jak nazwa monitora (pamiętajmy, że ta nazwa pojawi się jako nazwa alarmu w konsoli, więc dobrze jest, aby była dużo mówiąca o teście), opis, klasę oraz monitor, który będzie zmieniał się w zależności od naszego. Podając klasę (cel) należy wybrać SNMP Network Device. Domyślnie klasa ta nie jest widoczna, jako „pospolita”, chociaż jest to jedna z kilku klas dla urządzenia sieciowego. Przy wyborze należy zatem wybrać opcję View all argets.

Rysunek 5. Wybór klasy dla monitora

Gdy wybraliśmy klasę, powinniśmy zobaczyć następujące okno.

Rysunek 6. Ogólnie ustawienia monitora

Teraz przechodzimy do najważniejszej części naszego monitora – musimy zbudować zapytanie SNMP o nasz OID. Od tego jest kolejny krok kreatora. W oknie podajemy nasz OID i wskazujemy, czy community string jest taki sam jak podaliśmy w discovery, czy inny. Wypełniamy te dane i przechodzimy dalej. Pamiętamy cały czas, że OID zaczyna się od kropki poprzedzającej i dobrze, abyśmy jej nie zgubili nigdzie.

Rysunek 7. Wybór OID w monitorze - zapytanie 1

Dla pierwszego zapytania SNMP (widzimy na rysunku z lewej strony, że mamy do dyspozycji dwa), teraz tworzymy obróbkę jego wartości. Musimy podać, że nasz parametr jeśli będzie większy od 10 wygeneruje alarm, jeśli mniejszy, zgasi go. Niestety nigdzie nie znajdziemy co musimy wpisać w polu Parameter Name i jedyne, co pozostaje, to przepisanie poniższej formuły:

/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value

Jeśli w poprzednim krok (Rysunek 7) podaliśmy więcej niż jeden OID, gdyż np. chcemy monitorować dwie wartości, musimy w Parameter Name podać zmienne o kolejnych numerach [1], [2] itd., jednak w odwrotnej kolejności do wpisania OID. Oznacza to, że ostatni wpisany OID w kroku First SnmpProbe i Second SnmpProbe staje się SnmpVarBind[1]. Trochę dziwne, ale trzeba z tym żyć. Pozostaje nam teraz dodanie warunku i wartości do naszego kreatora.

Rysunek 8. Porównanie wartości

Te same kroki powtarzamy dla kolejnych dwóch kroków, czyli drugiej próbki, tylko zamiast operatora Greater than or equal to podajemy Less than. Używamy także tego samego OID. Następnie przypisujemy odpowiednie stany do naszych zapytań. Oczywiście w środowisku produkcyjnym to pierwsze zapytanie będzie powodowało alarm, ale dla celów testowych zrobimy tak, aby wartość procesora poniżej 10% była błędna.

Rysunek 9. Przypisanie stanu zdrowia do kondycji monitora

Osttnim krokiem jest utworzenie alarmu z tego stanu. Aby to zrobić, należy w ostatnim kroku kreatora zaznaczyć opcję Generate alerts for this monitor. Po tym należy wypełnić okno opcjami według własnego uznania, tj. automatyczne gaszenie alarmu, priorytet i ważność alarmu czy jego treść. Przy treści warto zastanowić się, czy nie skorzystać z funkcjonalności automatycznego uzupełniania treści parametrami. Do tego celu służy przycisk […] tuż obok okna Severity. Gdy w nie klikniemy pojawi nam się panel do wpisania treści wraz z podpowiedziami, jakich możemy użyć.

Rysunek 10. Treść alarmu monitora

Zatem wybierając pola IP Address i Device Name z menu Target uzupełniamy wartość głównego pola tak, aby powstała treść:

Powyższą wartość uzyskaliśmy poprzez wybranie z menu Data wartości SnmpVarBinds, SnmpVarBind i Value, a następnie podstawienie w miejsce podpowiedzi <<INT>> wartości 1. Taki alarm zapisujemy i oczekujemy na wynik.

Rysunek 11. Widok ustawień alarmu

Po kilku minutach na naszym ekranie pojawi się następujący alarm:

Rysunek 12. Alarm w konsoli dotyczący przeciążenia procesora

Stan zdrowia naszego routera także jest na czerwono, a kontekst alarmu dobrze przedstawiony jest w drzewie zdrowia (Health Explorer) obiektu.

Rysunek 13. Drzewo zdrowia obiektu routera

Podsmowanie

Takie monitorowanie jest dość toporne. Co jeśli chcielibyśmy monitorować setki interfejsów? To byłoby okropne. Musielibyśmy napisać 100 monitorów do każdego interfejsu osobno! Tak źle na szczęście nie jest, bo możemy wykryć klasę typu interfejs i dzięki niej zbudować jeden monitor. W następnym artykule pokażemy jednak najpierw jak zbudować reguły zbierające nam dane wydajnościowe na temat naszego urządzenia, takie jak wolna pamięć, utylizacja procesora czy temperatura.