Zagadnienie monitoringu aplikacji oraz jej utrzymania w całym cyklu życia jest bardzo obszerne. Dotyczy nie tylko perspektywy technicznej czy narzędziowej, od której warto zacząć omawiać ten temat, a o której będzie w dalszej części artykułu, lecz także perspektywy zarządzania portfolio aplikacji z poziomu całej organizacji.
Mowa tu przede wszystkim o konieczności zachowania odpowiedniego poziomu usług (SLA, SLI), optymalizacji nakładów na utrzymanie oraz bezproblemowym wdrażaniu nowych funkcjonalności bez negatywnego wpływu na istniejące systemy. Sprawdzamy tym samym, jak wdrażana funkcjonalność wpływa na to, co już mamy.
Bez kluczowych narzędzi, które oferuje nam Google Cloud Platform, zarządzanie aplikacją, biorąc pod uwagę wszystkie te czynniki, nie byłoby tak proste. Przyjrzyjmy się więc na wstępie zagadnieniu z poziomu dewelopera i omówmy, jakie narzędzia oferuje nam Google oraz w jaki sposób optymalnie je wykorzystać później na wyższych poziomach.
Jako developerzy doskonale radzimy sobie z szukaniem błędów w programach uruchomionych lokalnie. IDE są wyposażone w debuggery, dzięki którym możemy zatrzymywać działanie kodu w dowolnym miejscu lub pod ustalonym warunkiem i szczegółowo prześledzić wykonywane instrukcje. Zawsze możemy też skorzystać ze starego, dobrego pisania po konsoli.
Co jednak w przypadku, gdy nasza aplikacja znajduje się w środowisku takim jak chmura, nad którym nie mamy pełnej kontroli? Gdy okazuje się, że zachowuje się dziwnie lub zwraca nieprawidłowe wyniki? Google Cloud Platform (GCP) daje nam kilka rozwiązań, które właściwie użyte pozwolą nam w prosty sposób znaleźć usterkę, zmierzyć wydajność całego systemu, a także reagować automatycznie na krytyczne błędy, powiadamiając zespół utrzymaniowy.
Surowe dane, czyli logowanie zachowania aplikacji u źródła
Obecnie projekty wykorzystujące dziesiątki zależności nie są niczym nadzwyczajnym. Posiadanie setek kontenerów czy wirtualnych maszyn, które komunikują się między sobą, nie jest problemem, biorąc pod uwagę popularną architekturę mikroserwisów. Ale w jaki sposób odnaleźć błąd w aplikacji, jeśli użytkownik zgłasza problem z otrzymaniem prawidłowego wyniku? Jak odnaleźć się w całym tym systemie, skoro przetwarzamy tysiące transakcji w ciągu sekundy? Z pomocą przychodzi nam GCP Cloud Logging.
GCP Cloud Logging to usługa oferowana przez Google Cloud Platform, która umożliwia:
- zbieranie,
- przechowywanie,
- przeglądanie i analizowanie logów aplikacji oraz systemu.
Tworząc aplikację, warto zadbać o prawidłowe użycie mechanizmu logowania. Nie jest łatwo właściwie wychwycić tylko te najważniejsze, newralgiczne informacje. Jednak później takie postępowanie odwdzięczy się nam i w jednoznaczny sposób wskaże nam miejsce błędu w naszym kodzie.
W aplikacji warto zadbać o prawidłowy poziom logowania. Należy unikać logowania dużych obiektów, logować wyjątki, dane krytyczne z punktu działania aplikacji, operacje na zbiorach danych (np.: modyfikacje bazy danych, przesyłanie obiektów do storage itp.), czy informacje ważne z punktu widzenia biznesu.
Wyszukiwanie i filtrowanie dzienników
Cloud Logging udostępnia narzędzia do wyszukiwania i filtrowania dzienników. Można to zrobić na dwa sposoby:
- poprzez przyjazny dla użytkownika interfejs graficzny, dzięki któremu możemy „wyklikać” interesujące nas filtry, np.: zawężenie do konkretnego kontenera, adresu IP, daty i godziny czy słowa kluczowego użytego w logu,
- poprzez tworzenie zapytań w języku Log Query Language, który umożliwia filtrowanie i agregowanie dzienników. Log Query Language jest oparty na języku SQL i umożliwia m.in.: wybieranie konkretnych pól dziennika, porównywanie ich wartości czy grupowanie wpisów.
W GCP Cloud Logging dzienniki są zapisywane w formacie JSON. Każdy wpis w dzienniku składa się z kilku pól, takich jak:
- „timestamp” – data i godzina zdarzenia,
- „severity” – stopień poważności zdarzenia (np. „ERROR”, „WARNING”, „INFO”),
- „message” – treść dziennika,
- „logName” – nazwa dziennika, do którego zostało dodane zdarzenie,
- „resource” – zasób, który jest powiązany z zdarzeniem (np. adres IP maszyny wirtualnej lub nazwa kontenera).
Dodatkowe pola
Oprócz powyższych pól, dzienniki w GCP Cloud Logging mogą zawierać dodatkowe pola, takie jak nagłówki HTTP, identyfikator żądania (X-Request-ID) i informacje o aplikacji.
X-Request-ID to opcjonalny, nieoficjalny nagłówek HTTP, który wykorzystywany jest do identyfikacji pojedynczego żądania HTTP. Warto zadbać, aby taki identyfikator był prawidłowo przesyłany do dzienników zdarzeń. Głównym celem użycia tego nagłówka jest umożliwienie łatwiejszego śledzenia i rozwiązywania problemów z żądaniami HTTP.
Dzięki niemu możliwe jest łatwe grupowanie (agregacja) wpisów dziennika związanych z pojedynczym żądaniem HTTP, co ułatwia ich przeglądanie i analizowanie. Wystarczy, że operacja, która zakończyła się błędem, zwróci użytkownikowi wartość w/w nagłówka, a my w łatwy sposób będziemy w stanie odfiltrować dane dotyczące tylko tego konkretnego żądania. W połączeniu z umiejętnym logowaniem newralgicznych danych z serwisu będziemy mogli jednoznacznie określić, w którym miejscu pojawił się błąd.
Cloud Logging jako zaawansowane narzędzie
Cloud Logging to rozbudowane narzędzie, które posiada wiele zaawansowanych mechanizmów. Może być integrowane z różnymi źródłami danych, takimi jak: aplikacje, usługi GCP, maszyny wirtualne i kontenery. Posiada rozwinięte narzędzia do analityki np.: BigQuery czy Data Studio, dzięki którym możliwe jest tworzenie złożonych zapytań i raportów z dzienników. Usługa oferuje również rozwiązania do powiadamiania odpowiednich użytkowników oraz usług o określonych zdarzeniach, używając wcześniej zdefiniowanych reguł oraz wzorców, co pozwala na szybsze reagowanie w przypadku wystąpienia błędów.
Znajomość GCP Cloud Logging oraz umiejętność poruszania się po podstawowych jego funkcjonalnościach nie raz odwdzięczy się nam szybkim znalezieniem błędu. W mojej opinii powinno być używane jako jedno z pierwszych w przypadku rozpoczynania śledztwa dotyczącego błędów czy niestabilności w działaniu aplikacji.
Definiowanie progów kluczowych parametrów, czyli metryki
Jeśli chodzi o metryki, podstawowym pytaniem nie jest to, jak je stworzyć, lecz to, co te metryki powinny zawierać, tak aby pozwoliły na rzetelny monitoring naszej aplikacji.
GCP dostarcza wiele narzędzi, które to są dobrze opisane i naprawdę bardzo łatwo można się ich nauczyć, aczkolwiek nie to jest celem naszych rozważań. Przychodzi taki czas, kiedy dostajemy informacje o tym, iż coś działa zbyt wolno lub błędnie. Chcemy wówczas, aby metryki pozwoliły nam szybko znaleźć źródło tego problemu, żeby następnie sprawnie go poprawić, nie generując przy tych skomplikowanych rozwiązań, które mogłyby w dalszej części prowadzić do powstania kolejnych błędów.
Metryki i monitoring
Generalnie, każda definicja metryki ma jakiś wpływ na wydajność aplikacji. Nie należy więc przesadzać z dodawaniem metryk, które nic nie wniosą do przyszłego monitoringu. Na początku musimy spojrzeć na aplikację i zastanowić się, co chcemy monitorować, co pozwoli nam na szybkie wykrycie problemu oraz określenie miejsca jego występowania.
Na pewno warto monitorować zależności zewnętrzne aplikacji, jeśli takie istnieją, oraz pule połączeń do nich zdefiniowane tak, aby jednoznacznie stwierdzić, czy dany zasób działa oraz czy nasza aplikacja w pełni go wykorzystuje. Nie ma jednego uniwersalnego sposobu, co należy monitorować. Każda aplikacja jest inna, używa czegoś innego oraz inne elementy będą dla niej krytyczne oraz mogą być potencjalnym miejscem, na które należy zwrócić uwagę podczas produkcyjnego działania.
Narzędzie Metric Explorer dostarczone przez Google Cloud Platform pozwala na szybkie i łatwe wizualizowanie dodanych wcześniej do aplikacji metryk. Możemy wybrać zdefiniowanę metrykę, zrobić jej wizualizację, dodać odpowiednie filtry oraz grupowania tak, aby przedstawić dana metrykę w czasie. Dzięki temu później możemy obserwować, jak dana metryka zachowuje się podczas działania aplikacji. Często pozwala to określić, że z naszą aplikacją dzieje się coś niedobrego. Przykładowo – gdy zwiększa się nasze użycie pamięci, a pamięć nie jest odpowiednio czyszczona.
Operations Suite dostarcza narzędzia pozwalające na pełen monitoring aplikacji oraz integrację z nim. Jednym z narzędzi jest Cloud Logging, będący serwisem pozwalającym na zbieranie logów z aplikacji oraz zapisywanie ich przy pomocy Cloud Storage. GCP dostarcza również GUI pozwalające na przeszukiwanie wcześniej zebranych z aplikacji logów w celu pozyskania informacji takich jak:
- stan aplikacji,
- występujące błędy,
- weryfikacje czasów przetwarzania poszczególnych requestów.
Integracja ze stackdriverem dostarcza kilkunastu gotowych metryk opisujących stan naszego środowiska zdeployowanego w GCP. W zależności od wybranej platformy dostajemy w pełni działającą integrację z monitoringiem lub musimy ja ręcznie zainstalować.
Wizualizacja zachowania aplikacji poprzez dashboardy
W GCP dashboardy są w pełni konfigurowalnym narzędziem, dającym możliwość tworzenia i grupowania wykresów. Wykresy te mogą dotyczyć zarówno podstawowych informacji (zużycie procesora lub pamięci), jak i wizualizować specyficzne dla aplikacji metryki, np. po to, aby zidentyfikować źródło problemów z wydajnością. Przykładowo – może dochodzić do sytuacji, w której aplikacja wystawiająca REST-owe API zwraca timeouty dla requestów.
Aplikacja ta komunikuje się z kilkoma systemami zewnętrznymi oraz bazą danych. Analizowanie logów w celu identyfikacji problemu jest w tym przypadku trudne i nieskuteczne. Jeśli jednak zbudujemy dashboard z wykresami czasu odpowiedzi z poszczególnych komponentów dla jednego requestu, szybko możemy zaobserwować, że np. najwięcej czasu zajmuje zapytanie do bazy danych. W ten sposób zawęzimy obszar poszukiwań problemu do konkretnego momentu przetwarzania i możemy skupić się np. na optymalizacji naszych zapytań SQL.
Te same dashboardy można wykorzystywać w różnych środowiskach (deweloperskim, testowym, produkcyjnym itp.). Takie podejście pozwala na identyfikację i poprawę błędów przed wdrożeniem systemu na produkcję, a także na łatwą replikację bugów zaobserwowanych u klientów do środowiska deweloperskiego.
Tworzenie dashboardów
Dashboardy możemy utworzyć na 2 sposoby:
- używając istniejącego w GCP kreatora,
- napisać plik JSON z szablonem.
W kreatorze możemy łatwo „wyklikać” potrzebny nam wykres. Wybieramy metrykę, sposób grupowania (np. po rodzaju zapytania HTTP, przez co otrzymamy osobne wizualizacje dla GET-ów, POST-ów) oraz sposób agregacji danych w zdefiniowanym okienku czasowo (np. chcielibyśmy uśrednić czas odpowiedzi serwisu w 5-minutowym przedziale).
Jeśli potrzebujemy przetwarzać dane w bardziej skomplikowany sposób niż sumując, uśredniając itp., możemy sami napisać kod funkcji w języku MQL (Monitoring Query Language). Kreator ma jednak pewne ograniczenia, np. nie pozwala na wizualizację kilku rodzajów danych na tym samym wykresie, jeśli używamy MQL. W takim przypadku musimy wybrać podejście z konfiguracją w JSON-ie.
Dobrą praktyką jest trzymanie pliku z szablonem w repozytorium przy kodzie aplikacji. Sprawę ułatwia fakt, że stworzony dashboard możemy wyeksportować z poziomu konsoli GCP właśnie w wymaganym JSON-owym formacie.
Wykresy są bardzo przyjazne dla użytkownika, dzięki temu, że można zmienić zakres czasowy (1h, 6h etc.) lub uzyskać wartość dla określonego okresu bez konieczności zmian konfiguracji. Można je również grupować w rozwijalne i zatytułowane sekcje, co bardzo poprawia czytelność dashboradów.
Powiadamianie zespołu utrzymaniowego, czyli alerty
Często w aplikacjach produkcyjnych w wyniku użycia systemu przez użytkowników dowiadujemy się o problemie na środowisku. Po zgłoszeniu błędu musimy przeprowadzić analizę, „grzebać” w logach aplikacji i samemu próbować odkryć źródło problemu.
Alerty wychodzą naprzeciw takim problemom oraz pozwalają na optymalne skrócenie potencjalnego czasu naprawy i wdrożenia na środowisko. Poprzez zapięcie alertów na logach lub odpowiednich metrykach, które są eksportowane z aplikacji, środowisko jest w stanie zasygnalizować problemy z aplikacją (np. brak połączenia z bazą danych, aplikacja rzuca same błędu danego typu etc.).
Jak wspomniałem wyżej, alert można zdefiniować na podstawie logów lub metryk. Alerty na podstawie logów tworzy się bardzo prosto z poziomu eksploratora logów, klikając przycisk „Create Alert”. Używając generatora tworzenia alertów, możemy wyfiltrować interesujący nasz log, podpiąć pod alert i gotowe.
Tworzenie alertów
Natomiast procedura przygotowania alertów na podstawie metryk wygląda trochę inaczej. Z poziomu okna Cloud Monitoring w sekcji Alerting tworzymy Alerting Policy i konfigurujemy metrykę, na której będzie bazować alert. W tym celu można użyć metryk zdefiniowanych domyślnie – przykładowo metryki wysyłane przez aplikację z kontenera lub metryki, które zdefiniowaliśmy sami. W tym miejscu można wyklikać konfigurację takiej metryki (np. zużycie CPU powyżej 80% przez 5 minut), używając interfejsu użytkownika dostarczonego nam przez Google. Pozwala on na generowanie prostych warunków lub użyć tzw. MQL, który umożliwi nam tworzenie bardziej złożonych warunków dla naszego alertu.
Dla każdego warunku wymagane jest również zdefiniowanie triggera, który będzie wyzwalał alert. Mamy tutaj kilka opcji do wyboru m.in wyzwalanie za każdym razem, gdy warunek zostanie spełniony, warunek zostanie spełniony procentowo lub ilościowo w danych przedziale czasowy. Tak zdefiniowany trigger jest już gotowy do działania. Możemy go jeszcze rozbudować o okna ponownego przetestowania warunku (użyteczne, gdy alert ma skłonności do bycia fałszywie pozytywny) oraz informacje o tym, jak warunek powinien reagować na braki w danych (brakujące dane powinny być traktowane jako spełniające lub nie warunek zdefiniowany dla alertu).
Na sam koniec zostało nam podłączenie naszego alertu do dowolnego kanału notyfikacji udostępnionego nam przez Google. Są to podstawowe jak e-mail, SMS, Slack lub bardziej wyszukane typu Pub/Sub, WebHook lub PagerDuty Services.
Tak utworzony alert na platformie GCP ułatwi zadanie zespołowi utrzymującemu produkcję. Dzięki informacji prosto z platformy, która wystawia wstępną diagnostykę i informację o tym, że coś niedobrego dzieję się z naszą aplikacją. Pozwala to w znacznym stopniu zredukować czas niezbędny do naprawy problemu występującego na środowisku.
Podsumowanie
Observability, czyli wieloaspektowy i wielowymiarowy pogląd na zachowanie i stan aplikacji oraz środowiska, stanowi nieodłączny element ekosystemów chmurowych, ułatwiając krojenie rozwiązań szytych na miarę, przynosząc korzyści zarówno zespołowi deweloperskiemu jak i całej organizacji. Pomaga szybko, w jednym miejscu, diagnozować problemy i równie szybko reagować na ich pojawienie się. Ułatwia utrzymanie odpowiednich wskaźników poziomu jakości usług produktów krytycznych biznesowo w nowoczesnym, szybko zmieniającym się świecie.
***
Jeśli interesują Cię zagadnienia chmury, to polecamy też inne artykuły naszych ekspertów z tego obszaru.
Zostaw komentarz