Monitorowanie aplikacji w chmurze

Wskaźniki danych testowych

Po skompletowaniu danych testowych konieczne jest określenie, czy dane te wskazują, że coś działa niepoprawnie lub czy należy wykonać więcej prób. Najprostsze sprawdzenie, czy jest jakakolwiek odpowiedź z witryny? Brak często oznacza duży problem. Kolejnym wskaźnikiem są progi czasowe - wiele ośrodków stawia sobie za cel generowanie odpowiedzi w określonym czasie. Jeżeli są zbyt długie, generowany jest alarm. Często koreluje się odpowiedzi z dwóch różnych testów i upewnienia się, czy są wzajemnie zgodne.

Nie zawsze jednak trzeba martwić się o okazjonalne spowolnienie odpowiedzi, ale zbyt długi średni czas odpowiedzi oznacza problem. Progi statystyczne mogą być bardziej wymyślne - alarm jest generowany także, gdy średnia lub wartość środkowa (mediana) czasu odpowiedzi pozostaje stabilna, ale zbyt wolnych odpowiedzi jest za dużo.

Powszechnym testem jest sprawdzanie połączenia pomiędzy bazą danych i użytkownikiem. Do bazy danych witryn spersonalizowanych ładowane są odpowiednie nazwy oraz profile i następnie kontroluje się, czy otrzymane odpowiedzi mają poprawne nazwy i adresy.

Interpretacja zdarzeń

Jeżeli testy sugerują, że coś jest nie tak, system będzie generował zdarzenie i uruchamiał odpowiednią ścieżkę postępowania. Wczesne systemy jedynie rejestrowały zdarzenia, zmuszając administratorów do studiowania ich długich list. Obecne narzędzia mają opracowaną strukturę do klasyfikacji zdarzeń i mechanizmy uruchamiające inne testy w reakcji na zdarzenia. Są to m.in. wyzwalacze, skrypty, sztuczna inteligencja, adaptacyjne rejestrowanie oraz alarmy wielokanałowe.

Niektóre zdarzenia powinny wyzwalać alarmy bezpośrednio. Jeżeli test wykazuje poważny problem, zdarzenie jest wyświetlane w eksponowanym miejscu pulpitu, a powiadomienie wysyłane pocztą lub w postaci komunikatu tekstowego.

W niektórych przypadkach sensowne jest wykonanie wnikliwej oceny problemu. Skrypty pozwalają na zaprogramowanie systemu do działania według określonego schematu, dostosowanego do aktualnych potrzeb. Mogą np. zarządzać dodatkowe testy i reakcje na ich rezultaty. Skrypty pozwalają także na budowanie skomplikowanych planów alertów. Powiadomienie o umiarkowanym spowolnieniu może być np. przekazywane tylko niektórym osobom, ale duże spowolnienie może generować alarmy do wszystkich.

Bardziej zaawansowane systemy wykorzystują do interpretacji dużej liczby wyników algorytmy sztucznej inteligencji (AI). Są to często rozwiązania eksperymentalne, ale mogą wykrywać powiązania umykające ludzkiej uwadze. I tak np. bardzo szybki czas odpowiedzi z jednego systemu może wskazywać problem powstały w całkiem innej części ośrodka - z powodu błędu, szybkie maszyny nie zostały obciążone przypisanymi im zadaniami. System AI może znaleźć ten rodzaj korelacji. Do interpretacji wyników algorytmów AI zazwyczaj potrzeby jest jednak człowiek. Ostatecznie to najczęściej administrator musi zdecydować, jak zadziałać w sprawie wykrytego przez AI problemu.

Wiele zdarzeń jest niewartych uwagi - ale nie wszystkie. Dobry system śledzi zdarzenie aż do momentu, gdy problem zostanie rozwiązany. Gdy problem się pojawi, system adaptacyjnego rejestrowania zdarzeń może także zapisywać statystyki (np. obciążenia systemu), co pozwoli potem administratorowi podjąć trafną decyzje.

Zespoły opiekujące się systemem nie muszą wiedzieć o wszystkich zdarzeniach. System skriptingu pozwala określać, kto powinien dowiedzieć się o danym zdarzeniu. Poziom alarmu może zmieniać się także w zależności od ważności zdarzenia. Problem z bazą danych może generować alarm do administratora bazy danych przez wszystkie dostępne kanały alarmów (SMS, e-mail, telefon, itp.), ale już do szefa działu IT tylko kanałem poczty elektronicznej.

Monitorowanie aplikacji w chmurze

TOP 200