Marcin Kuczera - Leon Language: Polish Praktyczny przykład wykorzystania trapów SNMP, możliwość tworzenia ciekawych narzędzi i 'robienie dobrze' klientowi oraz sobie. Zarejestruj się na kolejną edycję PLNOG już dzisiaj: krakow.plnog.pl

1. PLNOG 14, Warszawa, 2 marca 2015
● o mnie
● dlaczego ten temat ?
Optymalizacja rozwiązywania problemów
sieciowych
Czyli
Na czym się skupić w pierwszej kolejności ?

2. PLNOG 14, Warszawa, 2 marca 2015
Co może raportować:
● switch ?
● port down, port up, alarm termiczny, uszkodzenia wentylatorow,
dhcp snooping, poziomy krytyczne DDMI, etc..
● router ?
● port down, port up, bgp neighbour down/up, uszkodzenia
wentylatorow, restarty procesów, etc..
● radiolinia ?
● Loss of Signal, zmiana modulacji (degradacja sygnału),
uszkodzenia sprzętu, etc..
SNMP Traps – znany i przydatny
mechanizm

3. PLNOG 14, Warszawa, 2 marca 2015
SNMP Traps – zbieramy informacje
DUŻO INFORMACJI !
TRAP Collector
Management
IP Network

4. PLNOG 14, Warszawa, 2 marca 2015
Co robimy z odebranym TRAPem ?
TRAP
MIB Library
Rodzaje
Zdarzeń (db)
Definicje
Zdarzeń(db)
Lista/baza
zdarzeń/alarmów
Logowanie
do pliku (raw data)
+ baza zdefiniowanych
urządzeń

5. PLNOG 14, Warszawa, 2 marca 2015
Typy zdarzeń

6. PLNOG 14, Warszawa, 2 marca 2015
Typy zdarzeń

7. PLNOG 14, Warszawa, 2 marca 2015
Definicje zdarzeń

8. PLNOG 14, Warszawa, 2 marca 2015
Definicje zdarzeń

9. PLNOG 14, Warszawa, 2 marca 2015
Widok Alarmów

10. PLNOG 14, Warszawa, 2 marca 2015
Widok alarmów

11. PLNOG 14, Warszawa, 2 marca 2015
Wady wady wady (czynnik ludzki)
- Dużo się dzieje
- Zajmuje dużo czasu
- Opisywanie, weryfikowanie
- Trudne do egzekwowania
- Powtarzajace się zdarzenia….. WŁAŚNIE !
Jak to się sprawdza w praktyce ?

12. PLNOG 14, Warszawa, 2 marca 2015
1. Pojawia się i znika – auto-zamykanie, nie
zauważamy
2. Pojawia się i znika, ale dużo się dzieje
więc nie zauważamy
3. Pojawia się i znika, zauważyliśmy, ale
skoro zniknął (alarm się zamknął) to
znaczy że nie ma problemu
Czas życia pojedynczego problemu

13. PLNOG 14, Warszawa, 2 marca 2015
Jak „samonaprawiające” się awarie
wpływają na inne aspekty
działalności ?
1. Baza wifi flapuje -> abonenci są rozłączani
-> wzywają serwis -> kilometry=koszty ->
dużo abonentów=dużo kosztów..
2. Restartuje się switch abonencki –
konsekwencje jak wyżej
Efekty:
- Serwis nie wyrabia, pracownicy źli
- Klienci wściekli, serwis nieskuteczny
- Problem nie rozwiązany, bo nie znamy źródła problemu !

14. PLNOG 14, Warszawa, 2 marca 2015
Mamy bazę problemów
- od czego zacząć ?

15. PLNOG 14, Warszawa, 2 marca 2015
A może by tak zrobić statystyki ?
„top 10” z ostatniego miesiąca
- definiujemy czasookres
- definiujemy ilość zdarzeń na liście

16. PLNOG 14, Warszawa, 2 marca 2015
Jak to w praktyce wygląda ?

17. PLNOG 14, Warszawa, 2 marca 2015
To do !
- Tworzenie tzw „Network Service Request”
NSR na podstawie zdarzeń ze statystyk
- „wyłączanie” pewnych zdarzeń ze
statystyk
- Informacje – alarmy dla nowych zdarzeń
w przypadku rozwiązanych problemów
- Agregacja zdarzeń w jeden zdefiniowany
alarm

18. PLNOG 14, Warszawa, 2 marca 2015
Pytania
?

19. PLNOG 14, Warszawa, 2 marca 2015
W przypadku pytań:
Marcin Kuczera
E-mail: marcin.kuczera@leon.pl