Witam wszystkich!
Nasza firma zajmuje się tworzeniem oprogramowania i późniejszą pomocą techniczną. Wsparcie techniczne wymaga nie tylko naprawiania błędów, ale także monitorowania wydajności naszych aplikacji.
Na przykład, jeśli jedna z usług uległa awarii, musisz automatycznie zarejestrować ten problem i zacząć go rozwiązywać, a nie czekać, aż niezadowoleni użytkownicy skontaktują się z pomocą techniczną.
Mamy małą firmę, nie mamy środków na badanie i utrzymywanie skomplikowanych rozwiązań do monitorowania aplikacji, potrzebowaliśmy znaleźć proste i skuteczne rozwiązanie.
Strategia monitorowania
Sprawdzenie funkcjonalności aplikacji nie jest łatwe, jest to zadanie nietrywialne, można by nawet powiedzieć twórcze. Szczególnie trudno jest zweryfikować złożony system wieloogniwowy.
Jak można zjeść słonia? Tylko w częściach! Używamy tego podejścia do monitorowania aplikacji.
Istota naszej strategii monitoringu:
Podziel aplikację na komponenty.
Utwórz kontrole kontrolne dla każdego komponentu.
Komponent uznaje się za sprawny, jeżeli wszystkie jego kontrole kontrolne zostały przeprowadzone bez błędów. Aplikacja jest uważana za sprawną, jeśli wszystkie jej komponenty działają.
Zatem każdy system można przedstawić w postaci drzewa komponentów. Złożone komponenty są dzielone na prostsze. Proste komponenty mają kontrole.
Benchmarki nie służą do przeprowadzania testów funkcjonalnych, nie są testami jednostkowymi. Kontrole kontrolne powinny sprawdzić, jak komponent czuje się w danym momencie, czy znajdują się w nim wszystkie zasoby niezbędne do jego funkcjonowania i czy nie występują jakieś problemy.
Nie ma cudów, większość kontroli będzie musiała zostać opracowana niezależnie. Ale nie bójcie się, ponieważ w większości przypadków jedno sprawdzenie zajmuje 5-10 linii kodu, ale możesz wdrożyć dowolną logikę i jasno zrozumiesz, jak działa sprawdzenie.
System monitorujący
Powiedzmy, że podzieliliśmy aplikację na komponenty, wymyśliliśmy i wdrożyliśmy kontrole dla każdego komponentu, ale co zrobić z wynikami tych kontroli? Skąd mamy wiedzieć, że jakaś kontrola się nie powiodła?
Będziemy potrzebować systemu monitorowania. Będzie wykonywać następujące zadania:
- Otrzymuj wyniki testów i wykorzystaj je do określenia stanu komponentów.
Wizualnie wygląda to jak podświetlanie drzewa komponentów. Elementy funkcjonalne zmieniają kolor na zielony, problematyczne na czerwony. - Wykonaj ogólne kontrole po wyjęciu z pudełka.
System monitorowania może sam przeprowadzić pewne kontrole. Po co wymyślać koło na nowo, wykorzystajmy je. Możesz na przykład sprawdzić, czy otwiera się strona internetowa lub czy serwer pinguje. - Wysyłaj powiadomienia o problemach do zainteresowanych.
- Wizualizacja danych monitoringowych, udostępnianie raportów, wykresów i statystyk.
Krótki opis systemu ASMO
Najlepiej wyjaśnić na przykładzie. Przyjrzyjmy się, jak zorganizowany jest monitoring pracy systemu ASMO.
ASMO to zautomatyzowany system wsparcia meteorologicznego. System pomaga specjalistom służb drogowych zrozumieć, gdzie i kiedy należy zastosować na drodze środki odladzające. System zbiera dane z punktów kontroli drogowej. Drogowym punktem kontroli jest miejsce na drodze, w którym zainstalowany jest sprzęt: stacja pogodowa, kamera wideo itp. Aby przewidzieć niebezpieczne sytuacje, system otrzymuje prognozy pogody ze źródeł zewnętrznych.
Zatem skład systemu jest dość typowy: strona internetowa, agent, sprzęt. Zacznijmy monitorować.
Rozbicie systemu na komponenty
W systemie ASMO można wyróżnić następujące elementy:
1. Konto osobiste
To jest aplikacja internetowa. Należy przynajmniej sprawdzić, czy aplikacja jest dostępna w Internecie.
2. Baza danych
Baza danych przechowuje dane ważne dla raportowania i należy zadbać o pomyślne utworzenie kopii zapasowych bazy danych.
3. Serwer
Przez serwer rozumiemy sprzęt, na którym działają aplikacje. Konieczne jest sprawdzenie stanu dysku twardego, pamięci RAM, procesora.
4. Agent
Jest to usługa systemu Windows, która wykonuje wiele różnych zadań zgodnie z harmonogramem. Musisz przynajmniej sprawdzić, czy usługa działa.
5. Zadanie agenta
Sama wiedza, że agent działa, nie wystarczy. Agent może pracować, ale nie wykonywać przydzielonych mu zadań. Podzielmy komponent agenta na zadania i sprawdźmy, czy każde zadanie agenta działa pomyślnie.
6. Drogowe punkty kontrolne (zbiornik wszystkich MPC)
Punktów kontrolnych na drodze jest wiele, dlatego połączmy wszystkie MPC w jeden element. Dzięki temu odczyt danych z monitoringu będzie wygodniejszy. Przeglądając status komponentu „systemu ASMO”, od razu będzie jasne, gdzie leżą problemy: w aplikacjach, sprzęcie czy w systemie maksymalnego sterowania.
7. Drogowy punkt kontrolny (jeden maksymalny limit)
Uznajemy, że ten komponent jest sprawny, jeśli wszystkie urządzenia w tym MPC są sprawne.
8. Urządzenie
Jest to kamera wideo lub stacja pogodowa instalowana przy maksymalnym limicie stężenia. Konieczne jest sprawdzenie, czy urządzenie działa prawidłowo.
W systemie monitorowania drzewo komponentów będzie wyglądać następująco:
Monitorowanie aplikacji internetowych
Podzieliliśmy więc system na komponenty, teraz musimy sprawdzić każdy komponent.
Aby monitorować aplikację internetową, stosujemy następujące kontrole:
1. Sprawdzenie otwarcia strony głównej
Kontrolę tę przeprowadza system monitorowania. Aby je wykonać, podajemy adres strony, oczekiwany fragment odpowiedzi oraz maksymalny czas realizacji żądania.
2. Sprawdzenie terminu płatności za domenę
Bardzo ważna kontrola. Gdy domena nie jest opłacona, użytkownicy nie mogą otworzyć witryny. Rozwiązanie problemu może zająć kilka dni, ponieważ... Zmiany DNS nie są stosowane natychmiast.
3. Sprawdzenie certyfikatu SSL
Obecnie prawie wszystkie strony internetowe korzystają z protokołu https w celu uzyskania dostępu. Aby protokół działał poprawnie, potrzebny jest ważny certyfikat SSL.
Poniżej komponent „Konto osobiste” w systemie monitoringu:
Wszystkie powyższe kontrole będą działać w większości aplikacji i nie wymagają kodowania. Jest to bardzo fajne, ponieważ możesz rozpocząć monitorowanie dowolnej aplikacji internetowej w 5 minut. Poniżej znajdują się dodatkowe kontrole, które można wykonać dla aplikacji internetowej, ale ich implementacja jest bardziej złożona i specyficzna dla aplikacji, dlatego nie będziemy ich omawiać w tym artykule.
Co jeszcze możesz sprawdzić?
Aby pełniej monitorować aplikację internetową, możesz wykonać następujące kontrole:
- Liczba błędów JavaScript w okresie
- Liczba błędów po stronie aplikacji internetowej (back-end) w danym okresie
- Liczba nieudanych odpowiedzi aplikacji internetowych (kod odpowiedzi 404, 500 itd.)
- Średni czas wykonania zapytania
Monitorowanie usługi Windows (agent)
W systemie ASMO agent pełni rolę harmonogramu zadań, który realizuje zaplanowane zadania w tle.
Jeśli wszystkie zadania agenta zakończą się pomyślnie, agent działa poprawnie. Okazuje się, że aby monitorować agenta, trzeba monitorować jego zadania. Dlatego też komponent „Agent” dzielimy na zadania. Dla każdego zadania utworzymy osobny komponent w systemie monitorowania, gdzie komponent „Agent” będzie „rodzicem”.
Komponent Agenta dzielimy na komponenty potomne (zadania):
Dlatego podzieliliśmy złożony komponent na kilka prostych. Teraz musimy wymyślić kontrole dla każdego prostego komponentu. Należy pamiętać, że komponent nadrzędny „Agent” nie będzie podlegał żadnej kontroli, ponieważ system monitorowania obliczy jego status niezależnie na podstawie statusu jego komponentów podrzędnych. Innymi słowy, jeśli wszystkie zadania zostaną zakończone pomyślnie, agent działa pomyślnie.
Zadań w systemie ASMO jest ponad sto, czy naprawdę konieczne jest wymyślanie unikalnych kontroli dla każdego zadania? Oczywiście kontrola będzie lepsza, jeśli wymyślimy i wdrożymy własne, specjalne kontrole dla każdego zadania agenta, jednak w większości przypadków wystarczy zastosowanie kontroli uniwersalnych.
System ASMO wykorzystuje wyłącznie uniwersalne kontrole zadań i to wystarczy do monitorowania wydajności systemu.
Sprawdzanie postępu
Najprostszą i najskuteczniejszą kontrolą jest kontrola wykonania. Kontrola sprawdza, czy zadanie zostało wykonane bez błędów. Wszystkie zadania mają tę kontrolę.
Algorytm weryfikacji
Po każdym wykonaniu zadania należy przesłać do systemu monitorującego wynik kontroli SUKCESU, jeśli wykonanie zadania powiodło się, lub BŁĄD, jeśli wykonanie zakończyło się błędem.
Ta kontrola może wykryć następujące problemy:
- Zadanie jest uruchamiane, ale kończy się niepowodzeniem z powodu błędu.
- Zadanie przestało działać, na przykład się zawiesiło.
Przyjrzyjmy się bardziej szczegółowo, jak rozwiązano te problemy.
Problem 1 — Zadanie działa, ale kończy się niepowodzeniem z powodu błędu
Poniżej przedstawiono przypadek, w którym zadanie zostało uruchomione, ale zakończyło się niepowodzeniem w godzinach od 14:00 do 16:00.
Rysunek pokazuje, że w przypadku niepowodzenia zadania natychmiast wysyłany jest sygnał do systemu monitorowania, a status odpowiedniej kontroli w systemie monitorowania staje się alarmowy.
Należy pamiętać, że w systemie monitorowania status komponentu jest zależny od statusu weryfikacji. Stan alarmu kontroli spowoduje zmianę wszystkich komponentów wyższego poziomu na alarm, patrz rysunek poniżej.
Problem 2 - Zadanie przestało być wykonywane (zamrożone)
Jak system monitorowania zrozumie, że zadanie utknęło?
Wynik kontroli ma okres ważności, na przykład 1 godzinę. Jeżeli minie godzina i nie będzie nowego wyniku testu, system monitorujący ustawi status testu na alarm.
Na powyższym zdjęciu światła zostały wyłączone o godzinie 14:00. O godzinie 15:00 system monitoringu wykryje, że wynik badania (z 14:00) jest zły, bo Upłynął czas ważności (jedna godzina), ale nie ma nowego wyniku, co powoduje przełączenie kontroli w stan alarmowy.
O godzinie 16:00 ponownie włączono światła, program zakończy zadanie i wyśle wynik wykonania do systemu monitorującego, status testu ponownie osiągnie sukces.
Jakiego czasu ważności kontroli powinienem użyć?
Czas istotności musi być większy niż okres realizacji zadania. Zalecam ustawienie czasu ważności 2-3 razy dłuższego niż okres wykonania zadania. Jest to konieczne, aby uniknąć otrzymywania fałszywych powiadomień, gdy na przykład zadanie trwało dłużej niż zwykle lub ktoś przeładował program.
Sprawdzanie postępu
System ASMO posiada zadanie „Wczytaj prognozę”, które co godzinę próbuje pobrać nową prognozę z zewnętrznego źródła. Dokładny czas pojawienia się nowej prognozy w systemie zewnętrznym nie jest znany, ale wiadomo, że dzieje się to 2 razy dziennie. Okazuje się, że jeśli przez kilka godzin nie będzie nowej prognozy, to jest to normalne, ale jeśli nie będzie nowej prognozy przez dłużej niż jeden dzień, to znaczy, że gdzieś się popsuło. Na przykład format danych w zewnętrznym systemie prognostycznym może się zmienić, dlatego ASMO nie zobaczy nowej publikacji prognozy.
Algorytm weryfikacji
Zadanie wysyła wynik kontroli SUKCESU do systemu monitorującego, gdy uda mu się uzyskać postęp (pobieranie nowej prognozy pogody). Jeśli nie ma postępu lub wystąpi błąd, nic nie jest wysyłane do systemu monitorującego.
Kontrola musi mieć taki okres ważności, aby w tym czasie gwarantowany był nowy postęp.
Należy pamiętać, że o problemie dowiemy się z opóźnieniem, gdyż system monitorujący czeka do momentu upłynięcia okresu ważności ostatniego wyniku skanowania. Dlatego okres ważności czeku nie musi być zbyt długi.
Monitorowanie baz danych
W celu kontroli bazy danych w systemie ASMO wykonujemy następujące sprawdzenia:
- Weryfikacja tworzenia kopii zapasowej
- Sprawdzanie wolnego miejsca na dysku
Weryfikacja tworzenia kopii zapasowej
W większości aplikacji ważne jest posiadanie aktualnych kopii zapasowych baz danych, aby w przypadku awarii serwera można było wdrożyć program na nowym serwerze.
ASMO tworzy kopię zapasową raz w tygodniu i wysyła ją do magazynu. Po pomyślnym zakończeniu tej procedury wynik kontroli powodzenia zostaje przesłany do systemu monitorowania. Wynik weryfikacji ważny jest przez 9 dni. Te. Do kontroli tworzenia kopii zapasowych wykorzystywany jest mechanizm „kontroli postępu”, o którym mówiliśmy powyżej.
Sprawdzanie wolnego miejsca na dysku
Jeżeli na dysku nie będzie wystarczającej ilości wolnego miejsca, baza danych nie będzie mogła poprawnie działać, dlatego ważne jest kontrolowanie ilości wolnego miejsca.
Do sprawdzania parametrów numerycznych wygodnie jest używać metryk.
Metryka jest zmienną numeryczną, której wartość przekazywana jest do systemu monitorującego. System monitorowania sprawdza wartości progowe i oblicza stan metryki.
Poniżej zdjęcie jak wygląda komponent „Baza Danych” w systemie monitorującym:
Monitorowanie serwera
Do monitorowania serwera używamy następujących kontroli i wskaźników:
1. Wolne miejsce na dysku
Jeśli zabraknie miejsca na dysku, aplikacja nie będzie mogła działać. Stosujemy 2 wartości progowe: pierwszy poziom to OSTRZEŻENIE, drugi poziom to ALARM.
2. Średnia wartość pamięci RAM w procentach na godzinę
Używamy średniej godzinnej, ponieważ... nie interesują nas rzadkie rasy.
3. Średni procent procesora na godzinę
Używamy średniej godzinnej, ponieważ... nie interesują nas rzadkie rasy.
4. Sprawdzenie pingu
Sprawdza, czy serwer jest online. System monitorowania może przeprowadzić tę kontrolę; nie ma potrzeby pisania kodu.
Poniżej zdjęcie jak wygląda komponent „Serwer” w systemie monitoringu:
Monitorowanie sprzętu
Powiem ci, w jaki sposób uzyskuje się dane. Dla każdego punktu kontroli drogowej (MPC) w planerze zadań przypisane jest zadanie, np. „Przegląd MPC M2 km 200”. Zadanie odbiera dane ze wszystkich urządzeń MPC co 30 minut.
Problem z kanałem komunikacyjnym
Większość sprzętu zlokalizowana jest poza miastem, do transmisji danych wykorzystywana jest sieć GSM, która nie działa stabilnie (sieć jest albo jej nie ma).
Ze względu na częste awarie sieci, początkowo sprawdzenie ankiety RPP w monitoringu wyglądało następująco:
Stało się jasne, że nie jest to skuteczna opcja, ponieważ pojawiało się wiele fałszywych powiadomień o problemach. Następnie zdecydowano się zastosować „kontrolę postępu” dla każdego urządzenia, tj. Do systemu monitorowania wysyłany jest tylko sygnał powodzenia, gdy urządzenie zostanie odpytane bez błędu. Czas przydatności ustalono na 5 godzin.
Teraz monitorowanie wysyła powiadomienia o problemach tylko wtedy, gdy nie można odpytać urządzenia przez dłużej niż 5 godzin. Z dużym prawdopodobieństwem nie są to fałszywe alarmy, ale prawdziwe problemy.
Poniżej zdjęcie jak wygląda sprzęt w systemie monitoringu:
Ważne!
Gdy sieć GSM przestanie działać, wszystkie urządzenia MDC nie będą odpytywane. Aby zmniejszyć liczbę e-maili z systemu monitorowania, nasi inżynierowie subskrybują powiadomienia o problemach z komponentami typu „MPC”, a nie „Urządzenie”. Dzięki temu możesz otrzymać jedno powiadomienie dla każdego MPC, zamiast otrzymywać osobne powiadomienie dla każdego urządzenia.
Ostateczny schemat monitorowania ASMO
Zbierzmy wszystko w jedną całość i zobaczmy, jaki mamy schemat monitorowania.
wniosek
Podsumujmy.
Co dało nam monitorowanie wyników ASMO?
1. Skrócił się czas usuwania usterek
O usterkach słyszeliśmy już wcześniej od użytkowników, ale nie wszyscy użytkownicy zgłaszają wady. Zdarzyło się, że o awarii jakiegoś elementu systemu dowiedzieliśmy się tydzień po jego pojawieniu się. Teraz system monitorowania powiadamia nas o problemach, gdy tylko problem zostanie wykryty.
2. Zwiększona stabilność systemu
Ponieważ defekty zaczęto eliminować wcześniej, system jako całość zaczął działać znacznie stabilniej.
3. Ograniczenie liczby wezwań do pomocy technicznej
Wiele problemów zostało już rozwiązanych, zanim użytkownicy się o nich dowiedzą. Użytkownicy zaczęli rzadziej kontaktować się z pomocą techniczną. Wszystko to ma dobry wpływ na naszą reputację.
4. Zwiększanie lojalności klientów i użytkowników
Klient zauważył pozytywne zmiany w stabilności systemu. Użytkownicy napotykają mniej problemów podczas korzystania z systemu.
5. Zmniejsz koszty wsparcia technicznego
Przestaliśmy przeprowadzać jakiekolwiek ręczne kontrole. Teraz wszystkie kontrole są zautomatyzowane. Wcześniej o problemach dowiadywaliśmy się od użytkowników, często trudno było zrozumieć, o jakim problemie mówi użytkownik. Teraz większość problemów zgłasza system monitoringu, powiadomienia zawierają dane techniczne, które zawsze wyjaśniają, co i gdzie poszło nie tak.
Ważne!
Nie możesz zainstalować systemu monitorowania na tym samym serwerze, na którym działają Twoje aplikacje. Jeśli serwer ulegnie awarii, aplikacje przestaną działać i nie będzie kogo o tym powiadomić.
System monitorowania musi działać na oddzielnym serwerze w innym centrum danych.
Jeśli nie chcesz korzystać z serwera dedykowanego w nowym centrum danych, możesz skorzystać z systemu monitorowania w chmurze. Nasza firma korzysta z systemu monitorowania w chmurze Zidium, ale możesz skorzystać z dowolnego innego systemu monitorowania. Koszt systemu monitorowania w chmurze jest niższy niż wynajem nowego serwera.
Polecane:
- Rozłóż aplikacje i systemy w formie drzewa komponentów tak szczegółowo, jak to możliwe, aby wygodnie było zrozumieć, gdzie i co jest uszkodzone, a kontrola była pełniejsza.
- Aby sprawdzić funkcjonalność komponentu, użyj testów. Lepiej zastosować wiele prostych kontroli niż jedną skomplikowaną.
- Skonfiguruj progi metryczne po stronie systemu monitorowania, zamiast zapisywać je w kodzie. Dzięki temu nie będziesz musiał ponownie kompilować, konfigurować ani ponownie uruchamiać aplikacji.
- W przypadku kontroli niestandardowych należy zachować margines czasu przydatności, aby uniknąć otrzymywania fałszywych powiadomień, ponieważ wykonanie niektórych kontroli trwało nieco dłużej niż zwykle.
- Staraj się, aby elementy systemu monitorowania zmieniały kolor na czerwony tylko wtedy, gdy na pewno występuje problem. Jeśli bez powodu zmienią kolor na czerwony, przestaniesz zwracać uwagę na powiadomienia systemu monitorującego, jego znaczenie zostanie utracone.
Jeśli nie korzystasz jeszcze z systemu monitoringu, zacznij! To nie jest tak trudne, jak się wydaje. Spraw sobie przyjemność patrząc na drzewo zielonych składników, które sam wyhodowałeś.
Powodzenia.
Źródło: www.habr.com