Blog > Komentarze do wpisu

Monitoring środowiska IT - cz.1

Witam po krótkiej przerwie. 

 

Dzisiaj coś co spędza sen z powiek każdemu administratorowi/operatorowi jakiegokolwiek systemu - czy moje środowisko działa poprawnie/jest dostępne dla użytkowników/działa sieć/działa serwer (niepotrzebne skreślić). A z biznesowego punktu widzenia - czy nasza aplikacja jest dostępna dla wszystkich użytkowników i pracuje poprawnie (realizuje zamierzony cel biznesowy). Można by sądzić, że rozwiązań do monitoringu jest pełno i tylko wybierać. Otóż nie jest to wcale takie proste i oczywiste. 

Jest mnóstwo narzędzi do monitoringu sieci. Chociażby darmowe Nagios i Cacti, poprzez komercyjne typu WhatsUp, Op5Monitor, HP NNM, Cisco Prime Infrastructure. Tak samo wybór rozwiązań dla hardware typowo serwerowego (klatki blade, serwery standalone, macierze, SAN) jest nieprzebrany. Każdy vendor ma swoje rozwiązanie mniej lub bardziej kompatybilne z innymi rozwiązaniami. Nasuwa się nieodparcie obraz totalnego chaosu i wyboru między kiłą a cholerą. 

Kolejnym problemem jest brak rozwiązań naprawdę end-to-end. Jeżeli chcielibyśmy stworzyć sobie monitoring powiedzmy aplikacji www i sprawdzać wszystkie parametry łącznie z user experience to jesteśmy w kropce. Nie ma kompleksowego rozwiązania które potrafiło by zebrać wszystkie niezbędne informacje i przedstawić je w zjadliwej formie. 

Co powinno się składać na taki monitoring usługi? Zacznijmy od samej góry. Mamy sondę w sieci użytkowników. Odpalamy na niej system operacyjny i przykładową operację wykonywaną przez użytkownika. Niech będzie to otwarcie przeglądarki, wejście na stronę, wpisanie przykładowych danych w formularzu i wysłanie ich na serwer. Tu mamy pierwszy problem. Żaden ze znanych mi kombajnów monitorujących nie potrafi ogarnąć takiej funkcjonalności. Większość wspiera się zewnętrznym oprogramowaniem i pobiera z niego tylko końcowy wynik (działa/nie działa). A fajnie byłoby już na tym etapie otrzymać informację, czy klientowi otworzyła się strona (bo może ma problemy z DNS), ile czasu trwało jej władowanie (czy może otrzymał 404 Page not Found), ile trwało wysłanie formularza i ile czasu zajęło zanim użytkownik otrzymał maila z potwierdzeniem np rejestracji. Jest kilka komercyjnych rozwiązań potrafiących wykonać taką operację, ale nie ma róży bez kolców. Te które miałem okazję widzieć albo wymagają pełnego klienta (stawiamy pełnego PC z oprogramowaniem) albo odtwarzają nagrany ruch sieciowy. Każde podejście ma swoje wady i zalety. Nie będę tego szczegółowo omawiał, ale największy problem to stworzenie makra które po np zmianie pozycji jednego przycisku się nie rozsypie.

A to jeszcze nie wszystko bo fajnie byłoby mieć monitoring całej drogi do aplikacji, czyli całej sieci na drodze user-serwer, samego serwera (począwszy od elementów fizycznych na systemie skończywszy), bazy danych, aplikacji samej w sobie i jeszcze do tego informacje środowiskowe z serwerowni. 

Można zrobić taki monitoring np przy pomocy HP Operations czy Op5Monitora. Tylko, że będzie to zlepek kilku jak nie kilkunastu osobnych rozwiązań polepionych na taśmę izolacyjną i ślinę a na koniec machnięte sprayem na zielono. Rozwiązanie Op5 jest tak naprawdę Nagiosem ze wsparciem i kilkoma nakładkami graficznymi. Nic odkrywczego. Co potrafi zrobić Nagios wszyscy wiemy. Co do HP to sytuacja jest jeszcze ciekawsza. Rozwiązanie cierpi na podstawową chorobę nowoczesnych aplikacji pisanych przez vendorów sprzętu - jest napisana w Javie. A przez to jest niesamowicie powolna w działaniu i wymaga kosmicznych zasobów. Druga prawda o aplikacjach w Javie jest taka, że działają poprawnie tylko w wersji Javy w której zostały napisane. Każda nowsza wersja spowoduje nie działanie przynajmniej kilku funkcji. Dobrze, jeżeli w ogóle się uruchomi. 

A teraz kilka narzekań z podwórka sieciowego. Zadanie pozornie proste. Mamy protokół BGP w którym od naszych peerów dostajemy tablice z prefixami. Chcemy sobie zmonitorować czy któryś z naszych peerów przypadkiem nie wysiadł. Nie możemy zrobić tego wprost, gdyż najczęściej awaria nie występuje bezpośrednio na routerze z którym się peerujemy tylko gdzieś dalej w szkielecie operatora. Sumarycznie od naszego peera zamiast otrzymywać powiedzmy 500 prefixów otrzymujemy 2. I tu zaczyna się problem. Peer jest w stanie established, pakiety hello przychodzą, a łącze nie działa. Możemy tego nie zauważyć dopóki się nie zalogujemy na roter i nie sprawdzimy ręcznie czy przypadkiem nasz peer nie przysyła nam zbyt mało prefixów. Niestety routery Cisco nie mają w swojej bazie MIB takiego wpisu który podawałby bezpośrednio ilość otrzymanych tras od danego peera. Ale istnieje inna droga. Dla każdego peera jest dostępna cała gałąź OID z wszystkimi otrzymanymi trasami. Odpowiedź na postawione pytanie nasuwa się sama - zróbmy snmpbulkget albo snmwalk po konkretnej gałęzi i zliczmy ile rekordów nam zwróci. I tu pojawia się problem bez ręcznego rzeźbienia skryptów np w pythonie nie jesteśmy w stanie zrobić tak prostej rzeczy. 

Wydaje mi się po tym co widziałem na wizytach referencyjnych, że jest to dość poważna luka na rynku IT. Ktoś kto opracuje kompleksowy system monitoringu będzie naprawdę bogaty.

 

Pozdrawiam

AB

niedziela, 07 grudnia 2014, adikb

Polecane wpisy

TrackBack
TrackBack w tym blogu jest moderowany. TrackBack URL do wpisu:
stat4u