Wstęp

Monitorowanie urządzeń Cisco nabiera rumieńców. Posiadamy już odpowiednie narzędzia do zbierania informacji i ich wyświetlania. Jest jeszcze jednak pewna rzecz, o której warto pamiętać. Urządzenia sieciowe nie tylko wystawiają swoje dane na zewnątrz pozwalając je czytać i modyfikować (SNMP Get i SNMP Set), ale także potrafią wysłać w przestrzeń wskazaną przez administratora pewną informację o zdarzeniu. Przydatne jest to w naprawdę bardzo wielu przypadkach. Począwszy od informacji, że ktoś zmienia konfigurację routera, po potrzebę zmiany tuszu w drukarce. Aby udało się nam przeprowadzić poprawnie te operacje pobierania zdarzeń do Operations Managera, musimy skonfigurować najpierw urządzenie i system operacyjny, a następnie utworzyć reguły pobierające dane. Będziemy dziś zajmować się dwoma typami reguł – jedną już znamy, generującą zdarzenie w konsoli. Druga będzie jedynie pobierała zdarzenia celem ich gromadzenia. Te także możemy wyświetlić w konsoli.

Zatem kroki, które należy przedsięwziąć to:

• Konfiguracja urządzenia sieciowego
• Konfiguracja systemu operacyjnego, który działa jako proxy dla monitorowania urządzeń
• Tworzenie reguł dla zdarzeń
• Tworzenie widoku dla kolekcji zdarzeń
• Tworzenie reguł alertowych

Konfiguracja urządzenia sieciowego

Urządzenie sieciowe, jeśli jest nowe, nie ma ustawionych parametrów wysyłania trapów SNMP, nie będzie tego robić. Zanim jednak przejdziemy do konfiguracji urządzenia, przyjrzyjmy się, czym jest ten trap, o którym ciągle mowa.

Trap to specyficzny pakiet SNMP (składający się z kilku OID-ów tj. ciągów drzewa numerycznego) który zawiera informacje o istotnych z punktu widzenia agenta wydarzeniach jakie dzieją się na monitorowanym systemie. Jest on  wysyłany z urządzenia sieciowego (agenta) do innego systemu, np. monitorującego lub zarządzającego, aby zwrócić uwagę na pewne zdarzenie zachodzące w systemie. Trap wysyłany jest z następującymi danymi (w zależności od rodzaju zdarzenia): timetick (czas zdarzenia od uruchomienia urządzenia w milisekundach), OID (identyfikator drzewa, którego dotyczy zdarzenie), komunikat (nie zawsze, string z informacją o zdarzeniu) oraz inne komunikaty specyficzne dla danego typu trapu. Jeśli np. uruchomimy wysyłanie trapów w przypadku wejścia w tryb konfiguracji routera, oprócz czasu i OIDu dostaniemy informację, czego dotyczy konfiguracja i skąd nastąpiło wejście w ten tryb.

Ważne też jest, że komunikaty SNMP Trap wysyłane są nie na port 161, a na port 162.

Rysunek 1 - Kierunki i porty protokołu SNMP

Mając już podstawową wiedzę na temat protokołu SNMP, należy skonfigurować na routerze wysyłanie trapów SNMP, dzięki czemu dostaniemy w konsoli Operations Managera dziennik zdarzeń. Należy zacząć od tego, aby wszystkie firewalle miały przepuszczony ruch na porcie 162. Bez tego ani rusz. Przypuszczając, że wszystko jest gotowe, należy zalogować się na urządzeniu sieciowym i skonfigurować trapy.

Tym sposobem włączamy wysyłanie wszystkich trapów, a dodatkowo kierujemy je na nasz serwer OpsMgr. Community name jest public, co oznacza, że Operations Manager będzie także wiedzieć, że od tego urządzenia ma przyjmować trapy. Jeśli dla trapów zmienilibyśmy community name, w każdej regule czy monitorze dotyczącym trapów musielibyśmy podawać tę nową nazwę, a tak mamy na razie spokój.

Konfiguracja systemu operacyjnego

Zanim Operations Manager przejmie trapy od urządzenia sieciowego, potrzeba jeszcze jednego kroku. Na systemie, który służy jako proxy dla odbioru wiadomości z routera (w naszym przypadku jest to Management Server) musimy dokonfigurować usługę SNMP Trap. Od wersji Windows 2008, usługa ta jest domyślnie instalowana, lecz jest wyłączona i dodatkowo działa w trybie Manual. Na nasze potrzeby musimy to zmienić. Uruchamiamy zatem przystawkę services.msc.

Rysunek 2 - SNMP Trap w Windows Server 2008 R2

We właściwościach tej usługi przestawiamy tryb uruchomienia (Startup Type) na Automatic i uruchamiany usługę.

Rysunek 3 - Właściwości usługi SNMP Trap

System operacyjny jest już teraz gotowy do działania. Teraz musimy skonfigurować Operations Managera, aby odbierał zdarzenia. Do dzieła!

Kolekcjonowanie zdarzeń

Czasami wydaje nam się, że Operations Manager to tylko narzędzie do alarmowania o pewnych zdarzeniach w systemie. Nic bardziej mylnego. Jeśli chcemy, nasz system będzie centralnym punktem przeglądania wszystkich logów z systemów operacyjnych. Trzeba jednak do tego dość dużej przestrzeni dyskowej na bazę danych. Zdarzenia bowiem nie musza generować alarmów, a możemy przechowywać je po prostu w formie zdarzeń. Jak nie musimy generować alarmów na podstawie Event Loga, tak nie musimy tego robić dla trapów SNMP. Oczywiście potem zrobimy sobie i regułę, ale na początek dobrze wiedzieć co w ogóle przychodzi do naszego systemu i czy któreś zdarzenia warte są zachodu, aby alarmować o ich przyjściu.

Najprościej będzie utworzyć regułę, która będzie wyświetlała dosłownie wszystkie trapy, które pojawiły się na interfejsie systemu operacyjnego z urządzenia sieciowego. Przechodzimy więc do panelu Authoring. Tam tworzymy nową regułę.

Rysunek 4 - Tworzenie nowej reguły

Jako typ reguły wybieramy tym razem Collection Rules (jak w przypadku wydajności), ale tym razem Event Based i SNMP Trap (Event). Całość zapisujemy do naszego Management Packa od Cisco.

Rysunek 5 - Wybór typu reguły - kolekcja zdarzeń SNMP Trap

Następnie podajemy poszczególne właściwości reguły:

· Rule Name: Gather all SNMP Traps from Cisco

· Rule Category: Event Collection

· Rule Target: SNMP Network Device

· Rule is enabled: TRUE

Rysunek 6 - Właściwości reguły kolekcjonującej

Ostatnim krokiem jest wybranie odbioru wszystkich trapów, niezależnie od tego, jakiego OIDa one dotyczą. Jeśli podalibyśmy inny community string dla trapów, tutaj też należy go podać.

Rysunek 7 - Pobieranie wszystkich trapów SNMP

Po ukończeniu tego zadania nasz system zaczął już pobierać stosowne informacje od swojego kolegi – routera Cisco. Teraz przydałoby się wykonać coś, co spowoduje wysłanie tego trapa. Co zrobić najprościej i być pewnym, że taka informacja się pojawi? Najbardziej brutalnie – zrestartować urządzenie w trybie „na chama”, czyli albo hard reset z przycisku, albo zabawić się w wyciągnięcie wtyczki. Ja korzystam do testów z wirtualnego środowiska GNS3 dla urządzeń sieciowych, gdzie takich sprzętowych machlojek nie ma, muszę zatem zatrzymać urządzenie i je uruchomić z powrotem.

Przez ten czas uruchamiania się routera, zajmiemy się stworzeniem widoku dla naszych zdarzeń. W panelu Monitoring otwieramy menu kontekstowe naszego drzewa Cisco Devices i wybieramy nowy widok typu Event View.

Rysunek 8 - Tworzenie widoku zdarzeń dla Cisco Devices

We właściwościach widoku podajemy następujące informacje:

· Name: Cisco Traps

· Show data related to: SNMP Network Device

· Select conditions: generated by specific rules

Po wybraniu warunku, klikamy w słowo specific i wybieramy naszą regułę: Gather all SNMP Traps from Cisco. Dzięki temu w naszym widoku będą wiadomości tylko z naszej reguły, a nie np. wszystkie zdarzenia (jeśli mielibyśmy ich więcej) dotyczące urządzeń zarządzanych przez SNMP.

Rysunek 9 - Właściwości widoku zdarzeń

Nasz widok jest gotowy, a nawet mamy już wiele informacji o wydarzeniach związanych z restartem urządzenia sieciowego.

Rysunek 10 - Zdarzenia zebrane z urządzenia sieciowego

Pragnę tylko wyjaśnić, że reguła na początku nazywała się Test, dopiero potem została przemianowana na ładniejszą nazwę, stąd pozostałość słówka w wartości Generating Rule. Zwróćmy jednak uwagę na to, co pojawia się we właściwościach zdarzenia. W pierwszej tabeli mamy to, co zwykle – właściwości trapu SNMP, tak samo jak mieliśmy w przypadku SNMP Get przy regułach i monitorach. Ważniejsza dla nas jest tabela numer dwa. Są tam cztery wartości, chociaż z powodu niedoskonałości protokołu SNMP pojawiła się jedna wartość dwukrotnie. Tym się jednak nie przejmujemy. Jakie informacje posiadamy?

1.3.6.1.4.1.9.2.1.2.0 – whyReload – bardzo ważna informacja, właściwie najważniejsza; przy restarcie urządzenia ten parametr mówi nam o tym, dlaczego urządzenie zostało zrestartowane.

1.3.6.1.2.1.1.3.0 – upTime – czas od ostatniego restartu w milisekundach, czyli czas życia urządzenia

1.3.6.1.6.3.1.1.4.1.0 – snmpTrapOID – identyfikator informujący nas… że jest to trap. Wartość tego OIDa jest także OIDem mówiącym o tym, jakie zdarzenie nastąpiło. W naszym przypadku OID z końcówką 5.1 oznacza tzw. coldStart, czyli restart urządzenia z możliwością zmiany jego konfiguracji.

Dla nas są to bardzo ważne informacje. Cold Start zawsze wiąże się z restartem lub przeładowaniem konfiguracji urządzenia i może świadczyć o bardzo poważnym problemie. Chyba do tego potrzebny będzie jakiś alarm. Bardziej szczegółowego rozbicia informacji możemy zażądać poprzez przycisk View Event Data w prawym górnym rogu tabeli. Otrzymamy wtedy widok XML, który… w pewnym sensie nam się przyda.

Rysunek 11 - Widok XML trapu SNMP

W tym widoku widzimy coś, co powinniśmy pamiętać z monitorów – porównywaliśmy wartości SnmpVarBind[1] z pewnym ciągiem i na tej podstawie generowaliśmy alarm. Tutaj też musimy posiadać takie wartości, ale widzimy, że w jednym trapie mamy aż cztery SnmpVarBind. Nic trudnego. Zaraz się przekonamy jak to ugryźć.

Raportowanie o problemie

SNMP Trap o restarcie urządzenia jest bardzo ważny z punktu widzenia operatora systemu monitorowania. Może równie dobrze posiadać informację o braku komunikacji z serwerem, ale dzięki informacji o restarcie urządzenia, dostanie jaśniejszy obraz, co jest tego przyczyną. Zajmijmy się teraz przygotowaniem odpowiedniej reguły reagującej na restart. Z panelu Authoring ponownie wybieramy tworzenie nowej reguły (Rysunek 4). Z typu reguł wybieramy Alert Generating Rules, Event Based, Snmp Trap (Alert).

Rysunek 12 - Nowa reguła alarmująca o SNMP Trap

Ponownie wypełniamy podstawowymi danymi informację o regule z tym wyjątkiem, że jako kategorię wybieramy Alert. Regułę nazwijmy Router Reloaded.

Rysunek 13 - Właściwości reguły alarmującej

Teraz musimy wybrać, co będzie powodowało zapalenie się alarmu. Oczywiście odpowiedni OID (nie wybieramy All Traps, bo dostaniemy zalew niepotrzebnych alarmów w konsoli). Który jednak OID wpisać? Moduł SNMP Trap na szczęście ma trochę rozumu i sprawdza, który SnmpVarBind posiada jako typ OID i ten właśnie musimy wpisać. Zapada tu jednak pytanie – skoro przy SNMP Get podawaliśmy na początku kropkę, a teraz jej nie podajemy, to gdzie podziała się konsekwencja? Niestety ulotniła się i trzeba z tym żyć. OID tu podajemy bez poprzedzającej kropki.

Rysunek 14 - Konfiguracja OID trapu SNMP

Ostatnim krokiem jest dokonanie odpowiedniego wpisu w treść alarmu. Ponieważ chcemy, aby to uzupełniało się samoistnie, znów dokonujemy wyboru odpowiednich pól automatycznego uzupełniania danymi tak, aby treść alarmu była znamienna. Można to zrobić np. tak:

Router has been restarted or reloaded. Received SNMP Trap „coldStart” (OID: $Data/EventData/DataItem/SnmpVarBinds/SnmpVarBind[3]/Value$)

Detailed information: $Data/EventData/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value$

Device Uptime: $Data/EventData/DataItem/SnmpVarBinds/SnmpVarBind[2]/Value$

Jak widać, będziemy tutaj mieli do czynienia z wszystkimi trzeba wartościami SnmpVarBind, które łatwo zweryfikować przy pomocy albo tabeli, albo pliku XML z rysunków 10 i 11.

Rysunek 15 - Właściwości alarmu dla trapu SNMP

Dodatkowo, jeśli wiemy, że nasze urządzenie w przypadku jakiegoś innego trapu może go generować dość często, a nie chcemy mieć wielu takich samych alarmów w konsoli, a jedynie zwiększenie jego licznika, w oknie właściwości alarmu możemy wcisnąć Alert suppression. Pozwoli to nam na wybranie odpowiedniego parametru, który jeśli się powtórzy, zwiększy licznik nie powodując pojawienia się dodatkowego komunikatu.

Problematyczne jest to, że kreator jest dostosowany TYLKO do zdarzeń z Event Loga. Aby móc robić powielanie zdarzeń z trapu SNMP, należy wybrać przycisk Advanced i w każdej linijce wpisać parametry, które będą powielane. W naszym przypadku będzie to treść komunikatu oraz IP urządzenia. Parametry te najłatwiej wybrać z widoku XML (Rysunek 11).

$Data/EventData/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value$

$Data/EventData/DataItem/Source$

Rysunek 16 - Wybór zaawansowanego powielania alarmów

To już koniec. Po pozamykaniu naszego kreatora i ponownym restarcie urządzenia sieciowego oczekujemy na finał. Po około 2-3 minutach urządzenie ponownie wysłało trapy (możemy to sprawdzić w widoku Cisco Events), ale w widoku Cisco Alerts mamy także pewną ciekawą informację…

Rysunek 17 - Alarm o restarcie urządzenia

Ja sobie jeszcze pozmieniałem treść alarmu, ale w Waszym przypadku będzie to wyglądało jeszcze ładniej. Prawda, że nie jest to trudne? A jakie przydane!

Podsumowanie

Jesteśmy na finale monitorowania urządzeń sieciowych przy pomocy protokołu SNMP. Do dyspozycji mamy zdarzenia, reguły kolekcjonujące i wydajnościowe oraz monitory. Wszystko mamy posegregowane w widokach. Teraz nasz operator ma o wiele większą możliwość zdecydowania o tym, kogo poinformować o problemie. Nie zadzwoni i nie powie „Nie ma pinga”, a „Zrestartował się taki i taki router”. W następnym artykule poznamy jeszcze kilka udogodnień, jakie można zastosować przy takim podstawowym monitorowaniu urządzeń.