Monitorowanie oprogramowania – wszystko, co chcecie wiedzieć, ale boicie się zapytać

30 października, 2020

Wszystko co chcielibyście wiedzieć o monitorowaniu oprogramowania, ale boicie się zapytać

Monitorowanie to ostatni etap w cyklu życia projektu software wg idei DevOps. Etap, należy dodać, niejednokrotnie zaniedbany albo nawet całkowicie porzucany. Z kolei DevOps… osobna i obszerna historia. Wychodzę z założenia, że ta idea jest Ci znana. Jeśli jednak nie – oto long story short:

DevOps to zestaw praktyk, które stosujemy w tworzeniu i rozwijaniu projektów software. Efektem tych technik jest m.in. zmniejszenie barier pomiędzy osobami spełniającymi różne role w projekcie (np. pomiędzy programistami a administratorami, jak również pomiędzy administratorami a project managerami). 

Wszystko to służy szybszemu adaptowaniu się do zmian, które są nieuchronne w każdym długotrwałym projekcie software. Podstawą DevOps jest przewidywalny, zapętlony i maksymalnie zautomatyzowany cykl życia projektu. Nie oznacza to jednak, że każda osoba pracująca nad projektem robi wszystko naraz, a odpowiedzialność na temat zadań poszczególnych członków zespołu ulega rozmyciu. To błędne pojmowanie idei DevOps.  

monitorowanie oprogramowania

Co ma monitorowanie do wiatraka?

Etap monitorowania wpasowuje się w DevOps w naturalny sposób. Dostosowanie do zachodzących zmian – na przykład reagowanie na zmieniające się z czasem potrzeby użytkowników aplikacji – nie będzie możliwe bez posiadania pełnej wiedzy na temat działania oprogramowania i interakcji ze strony jego użytkowników.

Monitorowanie prowadzi do nabycia tzw. situational awareness, czyli po naszemu “świadomości sytuacyjnej”. Termin ten jest zapożyczony z programów szkoleniowych dla służb mundurowych i oznacza w skrócie bycie przygotowanym z wyprzedzeniem na zagrożenie. Ciągłe monitorowanie naszych aplikacji zmniejsza zatem ryzyko, że coś pójdzie nie tak. 

Ok, ale czym jest monitorowanie tak już od strony praktycznej?

Zaliczymy w jego poczet przede wszystkim techniczne parametry działania aplikacji (ilość obsługiwanych żądań HTTP, poziom zużycia pamięci RAM, poziom wykorzystania CPU, ilość przestrzeni wykorzystywanej przez dane aplikacji) przydatne programistom.

Do tego dochodzą również parametry specyficzne dla zadań wykonywanych przez aplikację (ilość zalogowanych użytkowników, ilość obsłużonych zadań, ilość sprzedanych produktów, ilość wygenerowanych plików) przydatne dla właścicieli projektu. 

Wdrożenie narzędzi monitorujących aplikacje niesie za sobą wiele korzyści. Oto najważniejsze z nich:

  • wiedza o bieżącej dostępności aplikacji – jeśli aplikacja wejdzie w tryb offline, dowiemy się tego wcześniej, niż zaczną nam to zgłaszać użytkownicy; 
  • dostęp do danych danych na temat wykorzystywanych przez aplikację zasobów – w zależności od czasu oraz innych czynników, jak chociażby  ilość aktywnych użytkowników;
  • pomoc w diagnozowaniu problemów z wydajnością aplikacji;
  • uzyskanie informacji o zmianach w pracy aplikacji, w zależności od zmian w środowisku działania (zmiana konfiguracji u dostawcy infrastruktury serwerowej może diametralnie wpłynąć na działanie aplikacji);
  • wgląd w występowanie zdarzeń charakterystycznych dla logiki biznesowej danej aplikacji (ilu użytkowników wykonało akcję X w przedziale czasowym od Y do Z);
  • większa przejrzystość i wyrównanie poziomu wiedzy o kondycji aplikacji pomiędzy osobami posiadającymi różne role w projekcie;
  • możliwość dalszego planowania na podstawie danych;
  • większa transparentność dla właściciela projektu – może sam sprawdzać jak działa aplikacja, co zwiększa zaufanie  pomiędzy stakeholderami. 

Last but not least –  na podstawie danych zbieranych z systemu monitorowania, możemy wyodrębniać trendy zachodzące w obserwowanym systemie i następnie reagować na nie z wyprzedzeniem. 

Wychodząc jednak nieco poza działkę samego DevOps – przykłady dobrych praktyk w pracy nad projektami software pokazują, że warto uzupełniać monitorowanie feedbackiem od użytkowników aplikacji. W ten sposób uzyskamy pełne spektrum danych, dzięki którym można podejmować dalsze trafne działania.

Jedna z podstawowych zasad związanych  z monitorowaniem brzmi:

You can’t manage what you don’t measure.

Zatem dla jak najlepszych praktyk zarządzania aplikacją, potrzebujemy odpowiednich narzędzi do mierzenia różnych aspektów jej działania. Przyjrzyjmy się im nieco bliżej.

Alertowanie – a na co to komu? 

Celem monitorowania na pewno nie jest bezustanne wpatrywanie się w dashboard z wykresami pokazującymi działanie aplikacji. Ale alertowanie już tak. Jest to funkcja powiadamiania o tym, że wystąpiło jakieś zdarzenie, które powinno nas zaniepokoić lub po prostu zwrócić naszą uwagę (bo np. wymaga podjęcia określonego działania). Większość z popularnych obecnie narzędzi dostarcza możliwość do notyfikowania o zdarzeniach poprzez:

  • wiadomości e-mail
  • powiadomienia w narzędziach służących do komunikacji w firmie (slack / mattermost)
  • notyfikacje na telefon oraz SMS

Umiejętne alertowanie pozwala uniknąć zalania naszej skrzynki e-mail tysiącami wiadomości o zaistniałym zdarzeniu. Ponadto dzięki narzędziom do monitorowania, powinniśmy mieć pełny obraz sytuacji wtedy, gdy interesujące zdarzenie faktycznie wystąpi. Przydatna jest również możliwość przeglądania wstecz danych wstecz  – od punktu startowego, którym jest wybrane zdarzenie.

“Wincyj” danych! 

Każde narzędzie dające dostęp do większej ilości danych na temat działania aplikacji, może stać się częścią naszego systemu monitorowania. Chociażby znane Google Analytics spełni taką rolę. W tym artykule skupimy się jednak na narzędziach, które działają w znacznej mierze po stronie serwera, przez co są bardziej wiarygodne i monitorują działanie aplikacji w czasie pseudo rzeczywistym. 

Grafana i Prometheus

Dwa narzędzia, które doskonale uzupełniają się nawzajem i bardzo często są wykorzystywane równolegle. Prometheus służy do zbierania danych i zapisywania ich w specjalnym formacie (wspiera kilka różnych rodzajów baz danych). Z kolei Grafana stanowi narzędzie do wizualizowania danych pobieranych z różnorodnych źródeł (w tym z bazy danych tworzonej przez Prometheus).

Wdrożenie polega na wprowadzeniu do danej aplikacji endpointu API, który zwraca aktualne statystyki na temat działania aplikacji. Tenże endpoint jest odpytywany w regularnych odcinkach czasu (np. co kilka sekund) przez Prometheus, który następnie zapisuje pobrane dane w formacie umożliwiającym ich analizę w późniejszym terminie. 

Przed samym wdrożeniem należy jednak zastanowić się, jakie pomiary chcemy wykonywać (i następnie wizualizować). Konieczna będzie również modyfikacja (lub instrumentacja) samej aplikacji, aby wyposażyć endpoint w pożądane przez nas dane. Tu z pomocą przychodzą gotowe biblioteki  dostępne dla różnych języków programowania. Umożliwiają one kolekcjonowanie pomiarów na poziomie kodu źródłowego aplikacji.

Drugi element stanowi Grafana. Można jej użyć do wizualizowania wielu różnych źródeł danych (nie tylko Prometheus) – nawet tych zaciąganych z MySQL oraz PostgreSQL. Grafana umożliwia tworzenie customowych dashboardów z wykresami generowanymi w oparciu o zebrane wcześniej dane.

Oba narzędzia przynależą do świata free software. W przypadku Grafany istnieje możliwość skorzystania z usługi SaaS.

Zalety dla zespołu:

  • możliwość zbierania customowych rodzajów metryk charakterystycznych dla logiki biznesowej danej aplikacji;
  • Grafana posiada gotowe do zaimportowania zestawy dashboardów dla popularnych stacków technologicznych;
  • zarówno Prometheus jak i Grafana zawierają moduły umożliwiające alertowanie po przekroczeniu konfigurowalnych wartości granicznych dowolnych metryk.

Wady:

  • wdrożenie niewątpliwie wymaga prac programistycznych, bo wiąże się z modyfikacją samej aplikacji
  • w przypadku użycia wersji self-hosted: nakłady na infrastrukturę oraz w czas poświęcony na wdrożenie się w oba narzędzia
  • to rozwiązanie wymaga wcześniejszej nauki przez osoby techniczne, i przekazanie wiedzy osobom, które docelowo będą z niego korzystać 

We współpracy z naszym zespołem nie trzeba jednak aż tak bardzo zwracać uwagi na wyżej wymienione mankamenty. Dlaczego? Otóż 1000software.house to doświadczony zespół programistyczny, również jeśli chodzi o wdrażanie i konfigurowanie tego rozwiązania od A do Z. Z przyjemnością i – co najważniejsze – skutecznie zajmiemy się kwestią monitoringu software 🙂

Elastic Stack

Jest to zestaw kooperujących ze sobą narzędzi napisanych głównie w Javie (więc mających wysokie wymagania sprzętowe). Elastic Stack składa się z:

  • Elasticsearch – baza danych NoSQL zaprojektowana pod kątem skalowania na wiele serwerów i składowania ogromnych ilości danych
  • Kibana – narzędzie do wizualizacji danych składowanych w bazie Elasticsearch
  • Beats oraz Logstash – komponenty do wyciągania danych z logów aplikacji, wstępnej analizy i przesyłania ich do Elasticsearch

Jeśli chcemy użyć Elastic Stack w wersji self-hosted, to nie bez znaczenia jest fakt, że jego narzędzia produkowane są przez jedną firmę. Dzięki temu ich uruchomienie nie jest problemem nawet dla średnio zaawansowanego administratora systemów. Problemy mogą pojawić się za to wtedy, gdy chcemy przechować dużą ilość danych lub obsłużyć dużą ilość ruchu. W tym przypadku trzeba mieć świadomość, że utrzymanie tego rozwiązania w wydajny sposób, wymaga większej ilości uwagi. Jeśli zatem zespół nie posiada pełnoetatowego administratora systemów, lepsze będzie skorzystanie z wersji SaaS.

Kibana posiada szeroki wachlarz prezentowania danych. Można na przykład za jej pomocą stosunkowo łatwo wizualizować współrzędne  geograficzne w postaci map ciepła (ang. heat map). Nie sposób oddać w kilku słowach tego, jakie możliwości posiada Elastic Stack. Zachęcam zatem do zapoznania się z bogatą dokumentacją tego projektu już we własnym zakresie. 

Zalety dla zespołu:

  • bogata dokumentacja na stronie twórców produktu
  • każdy, kto posiada dostęp do panelu Kibana, może analizować dane na własną rękę oraz tworzyć własne wizualizacje
  • bardzo rozbudowane i uniwersalne narzędzie – możliwość zbierania wszelkich rodzajów danych
  • dobrze zintegrowane ze sobą komponenty – jasna ścieżka co do sposobu początkowego uruchomienia

Wady:

  • w wersji self hosted – więcej pracy dla administratorów w przypadku dużego ruchu i  dużej ilości danych
  • uniwersalność tego narzędzia powoduje, że jego wdrożenie wymaga podjęcia wielu decyzji i przemyślanego sposobu użytkowania
  • w przypadku użycia wersji darmowej oprogramowania – trzeba liczyć się z ograniczeniami dotyczącymi zarządzania dostępem oraz uprawnieniami dla wielu użytkowników (istotne dla większych przedsiębiorstw i korporacji)
  • Elastic Stack – podobnie jak Grafana i Prometheus  – jest narzędziem, którego najpierw muszą nauczyć się osoby techniczne, aby potem przekazać wiedzę pozostałym członkom zespołu

Sentry

Podstawowa funkcją Sentry to zbieranie informacji i konfigurowalne alertowanie o nieoczekiwanych błędach zachodzących w naszych aplikacjach. Sentry umożliwia rejestrowanie błędów zachodzących zarówno po stronie serwera, jak i przeglądarki internetowej. Integracja z Sentry jest relatywnie prosta – istnieją gotowym do użycia biblioteki, które są dostępne w praktycznie każdym popularnym języku programowania a sama integracja polega na wklejeniu gotowego fragmentu kodu w odpowiednie miejsce aplikacji.

Oprócz zbierania informacji o błędach i wyjątkach, Sentry umożliwia zalogowanie eventów charakterystycznych dla danej aplikacji i można je  – oczywiście z pewnymi ograniczeniami – instalować we własnej infrastrukturze. Należy jednak pamiętać o tym, że jest to produkt własnościowy (z długą historią open-source), który pełnię funkcjonalności posiada dopiero w najdroższych płatnych planach.

Zalety dla zespołu:

  • relatywnie prosta integracja z istniejącymi projektami
  • przejrzyste alertowanie o błędach występujących w aplikacjach 
  • informowanie o nowych błędach poprzez e-mail w inteligentny i konfigurowalny sposób

Wady:

  • pełne informacje o błędach w Sentry są nierzadko trudne do zinterpretowania przez osoby nietechniczne 
  • w przypadku korzystania z usługi SaaS:
    • zaawansowana analiza danych tylko w wyższych planach
    • historia zbieranych błędów – w najniższym planie tylko do 3 miesięcy wstecz 

Mamy coś jeszcze? 

Oczywiście, że mamy! Przedstawiliśmy jedynie kilka narzędzi z całego dostępnego spektrum. Poniżej znajdziecie linki do innych przydatnych usług, które znamy, testowaliśmy i uważamy za warte uwagi

  • uptimerobot – niewielkie narzędzie do badania statusu dostępności aplikacji oraz ważności certyfikatów TLS. Posiada możliwość alertowania przez SMS (w płatnym planie)
  • datadog – jedna z bardziej popularnych obecnie usług do kompleksowego monitorowania wszelkich rodzajów systemów oraz aplikacji 
  • twój dostawca infrastruktury – bo dlaczego nie? Często zapominamy o tym, że większość dostawców infrastruktury serwerowej posiada możliwość przeglądania wykresów zużycia wybranych zasobów. Trudno oczekiwać by były to dane specyficzne dla naszych aplikacji, do tego wyposażone w funkcje alertowania. Natomiast nawet tego typu wykresy pomagają w określeniu ogólnego stanu naszej aplikacji.

I to by było na tyle. Mam nadzieję, że ten artykuł okazał się pomocny i wyjaśnił wiele kwestii związanych z monitorowaniem oprogramowania. Na koniec chciałabym podziękować za uwagę i zaprosić do kontaktu, jeśli już wiesz, że monitorowanie to niezbędny element w prowadzeniu biznesu online. Ja i specjaliści w 1000software.house z przyjemnością zajmiemy się tą kwestią dla Ciebie! 

Przydatne linki / referencje:

Sharing is caring!

1000ideas

Od ponad 10 lat skutecznie przekładamy pomysły na kreatywne kampanie i rozbudowane projekty technologiczne dla Klientów z Polski i ze świata.

Autor

Michał

IT Developer.
W gąszczu technologii czuje się tak dobrze, jak we własnym ogrodzie. W pracy łączy wieloletnie doświadczenie developera i administratora systemów GNU\Linux. Najchętniej pracuje z rozwiązaniami open source. Chciałby tworzyć narzędzia, które zmieniają świat na lepsze.