Obecnie aplikacje stają się coraz bardziej złożone i składają się z rosnącej liczby technologii. Monitorowanie ich może być trudne, zwłaszcza w chmurze. Nawet w przypadku dość prostej data warehouse z ETL/ELT pipelines powinieneś być w stanie monitorować database, orchestrator, processing engine itp. Na szczęście platforma GCP ma dobry serwis do monitoringu i alertów. Do tego tutoriala została stworzona HTTP Cloud Function.

GCP Logging
Monitoring nie może być przeprowadzony bez odpowiedniego logging. GCP zapewnia dobrą jakość logów dla serwisów GCP i umożliwia dodawanie własnych logów aplikacji, np. logów Pythona w Cloud Function processing. Można je łatwo przeszukiwać za pomocą przyjaznego interfejsu użytkownika (UI):
Logi aplikacji są niezwykle ważne do debugowania i tworzenia log-based metrics, które później mogą być używane do monitorowania naszego środowiska GCP.

Metrics
GCP zapewnia ogromną liczbę metrics do monitorowania out of the box, w tym zarówno natywne serwisy, takie jak BigQuery, Cloud Function, Composer itp., jak i serwisy takie jak AWS, Kubernetes. Spójrz tylko na wykresy z CF executions.
Istnieje również sposób tworzenia własnych metrics na podstawie logów, które mogą być później używane w monitoringu i alertach. Monitorowanie metrics z wielu projektów jest również dostępne dzięki użyciu scoping projects.

Log based metrics
Logi mogą być używane do tworzenia counters, distributions lub Boolean metrics. Na początku najbardziej przydatne mogą być pierwsze dwa, które mogą być używane do:
- liczenia liczby logów spełniających określony warunek lub distribution, np. liczby uruchomionych jobs
- śledzenia czasu wykonania job i jego historycznych distributions
Tworzenie metrics umożliwia również dodawanie labels do metrics, jednak należy to robić ostrożnie, ponieważ storage może szybko rosnąć, a co za tym idzie, również koszt. Poniżej znajduje się przykład log-based metric liczącej komunikaty traceback Cloud Function (błędy).
Warto zauważyć:
- metrics nie mogą być obliczane dla historycznych logów
- nowe metrics są widoczne od razu w metrics explorer, ale mogą być nieaktywne przez pewien czas, dopóki nowe logi spełniające warunki metric nie zostaną przetworzone
Monitoring z GCP
GCP umożliwia monitorowanie aplikacji na wiele sposobów, używając Cloud Monitoring lub Error Reporting services. Są one niezwykle przydatne i mogą być używane oddzielnie, w zależności od przypadku użycia.

Cloud MonitoringCloud Monitoring umożliwia zbieranie i monitorowanie GCP metrics, które później mogą być przeglądane za pomocą dashboards. Metrics mogą być analizowane oddzielnie, w grupach lub nawet dla serwisów poprzez zdefiniowane SLO (Service Level Objective). Serwisy mogą być dodawane ręcznie, jeśli nie zostaną wykryte automatycznie.

GCP AlertingGCP Alerting to potężna funkcja, która pomaga proaktywnie monitorować aplikacje i systemy poprzez ustawianie alerting policies. Te policies powiadamiają Cię, gdy zostaną spełnione określone warunki, takie jak nietypowe wartości metric lub brakujące metrics, zapewniając, że możesz rozwiązywać problemy, zanim się nasilą.


Po utworzeniu, gdy wystąpi problem, otrzymasz wiadomość e-mail jak poniżej.

Możesz także przejść do alerty/incydentów i łatwo przejść do odpowiednich dzienników związanych z problemem:

Sprawdzanie czasu pracy
Sprawdzanie czasu pracy to kolejny łatwy sposób monitorowania aplikacji. Dzięki niemu możesz zweryfikować dostępność swojej usługi. Nawet prywatne adresy IP i/lub usługi mogą być monitorowane, jednak istnieją pewne ograniczenia. W najgorszym przypadku sprawdzenie brakujących wskaźników można skonfigurować w celu wywołania alarmu. W poniższym przykładzie weryfikujemy stronę internetową naszej firmy.

Jak widać po kilku minutach wszystkie kontrole przechodzą

Raportowanie błędów GCP
Raportowanie błędów GCP umożliwia monitorowanie środowiska pod kątem błędów, które są automatycznie agregowane w grupy w celu łatwiejszego zarządzania. Ta funkcja pomaga szybko zidentyfikować nowe typy błędów i podejmować działania w razie potrzeby.
GCP umożliwia również monitorowanie środowiska pod kątem błędów, które później są agregowane w grupy. Pozwala to łatwo odkrywać nowe rodzaje błędów i reagować w razie potrzeby.

Warto zauważyć, że interfejs użytkownika jest przyjazny dla użytkownika i możesz przejść do dzienników aplikacji za pomocą zaledwie kilku kliknięć. Poniższy rysunek pokazuje szczegółowe informacje o grupie błędów:

Warto wspomnieć, że aby usługa wykrywała błędy aplikacji, dzienniki muszą zawierać ślad stosu lub być obiektem ReporteDerOrEvent.
Przyszłość inżynierii danych - trendy do obserwacji w 2025 roku
Jaka jest wiarygodność danych? Definicja i przykłady
Rozwój testowy w Pythonie przy użyciu Pytest