Google ACE: Monitorowanie, rejestrowanie zdarzeń i rozwiązywanie problemów operacyjnych — Przewodnik do nauki

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Część Google Associate Cloud Engineer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Doskonałość operacyjna w Google Cloud zależy od przekształcania danych telemetrycznych w działania. Monitorowanie, Logowanie i Rozwiązywanie Problemów wspólnie dostarczają sygnałów, zabezpieczeń i przepływów pracy, które utrzymują niezawodność usług. Ta sekcja obejmuje podstawowe usługi obserwowalności, narzędzia diagnostyczne, praktyki niezawodności oraz operacje związane z incydentami, wraz z uzasadnieniem projektowym, kompromisami i typowymi trybami awarii.

Podstawy Monitorowania i Alertów

Cloud Monitoring przyjmuje szeregi czasowe z usług Google Cloud, agentów i metryk niestandardowych, aby dostarczać pulpity nawigacyjne, kontrole dostępności, SLO i alerty.

• Metryki i kardynalność

  • Typy monitorowanych zasobów (np. gce_instance, aws_ec2_instance, global) określają wymiary, takie jak projekt, region i ID instancji.
  • Minimalizuj nieograniczone wartości etykiet (np. user_id), aby zapobiec eksplozjom wysokiej kardynalności, które spowalniają zapytania i zwiększają koszty.
  • Preferuj metryki dystrybucji dla opóźnień (p50/p90/p99) i używaj okien wyrównywania (alignment windows) dla spójnych agregacji.

• Pulpity nawigacyjne

  • Używaj wbudowanych pulpitów nawigacyjnych usług, aby szybko zacząć. Twórz niestandardowe pulpity, aby grupować metryki z różnych projektów. Organizuj panele według objawów (opóźnienie, błędy, nasycenie) przed przyczyną (CPU, pamięć).
  • Unikaj wykresów dla pojedynczych instancji we flotach; agreguj według usługi, strefy lub MIG, aby zredukować szum i wzmocnić sygnał.

• Polityki alertów

  • Projektuj alerty oparte na objawach, powiązane z doświadczeniem użytkownika: wypalanie SLO dostępności, percentyle opóźnień, wskaźniki błędów. Używaj alertów z wieloma oknami i wieloma wskaźnikami wypalania (multi-window, multi-burn-rate), aby wychwycić szybkie i wolne wypalanie (np. 2% w ciągu 1 godziny i 5% w ciągu 5 minut).
  • Ustawiaj rozsądne limity częstotliwości powiadomień i zachowania automatycznego zamykania. Używaj adnotacji do automatycznego łagodzenia incydentów, aby dokumentować procedury (runbooki).
  • Używaj alertów o braku metryki dla krytycznych zadań wsadowych i potoków danych o ścisłych harmonogramach.
  • Metryki oparte na logach wspierają alerty dla zdarzeń aplikacyjnych lub bezpieczeństwa (np. powtarzające się permissionDenied).

• Kanały powiadomień

  • Konfiguruj kanały według wagi (severity): paging dla SEV1 (dyżur, SMS, telefon), czat dla SEV2/3, e-mail lub webhooki dla niskiego priorytetu. Użyj Pub/Sub do integracji z systemami ticketowymi lub automatyzacją.
  • Testuj kanały okresowo; nieaktualne kanały to cichy tryb awarii.

• Kontrole dostępności i monitorowanie syntetyczne

  • Kontrole HTTP(S) i TCP z globalnych punktów obserwacyjnych weryfikują zewnętrzną osiągalność. Łącz kontrole z dopasowaniem treści, aby wykrywać częściowe awarie.
  • Używaj prywatnych kontroli dostępności poprzez łączność hybrydową lub Private Service Connect dla usług wewnętrznych.
  • Tryby awarii: kontrole mogą zawieść z powodu opóźnienia DNS TTL, problemów z rotacją certyfikatów TLS lub awarii ograniczonych do regionu; potwierdź za pomocą metryk przed wysłaniem powiadomienia (paging).

• Monitorowanie wielu projektów

  • Użyj jednego obszaru roboczego (workspace) Cloud Monitoring i połącz wszystkie projekty, aby uzyskać skonsolidowane pulpity nawigacyjne i alerty. Upraszcza to zarządzanie SLO dla całej floty i redukuje duplikację.

Logowanie, Audyt i Diagnostyka Aplikacji

Cloud Logging to router, magazyn i płaszczyzna zapytań dla logów platformy i aplikacji. Uzupełniające narzędzia APM (Error Reporting, Trace, Profiler) przyspieszają izolację pierwotnej przyczyny.

• Routing logów, buckety, ujścia i retencja

  • Kieruj za pomocą ujść (sinks) do bucketów z logami (domyślnych lub niestandardowych), BigQuery (analityka), Pub/Sub (przetwarzanie strumieniowe) lub Cloud Storage (archiwizacja).
  • Używaj bucketów z logami o zasięgu regionalnym, aby zapewnić rezydencję danych i wydajność. Zastosuj CMEK, jeśli jest to wymagane przez przepisy.
  • Ustaw retencję dla każdego bucketa (np. 30–90 dni dla operacji, wieloletnia dla audytu). Dłuższa retencja zwiększa koszty; filtruj agresywnie, aby kontrolować wydatki.
  • Wykluczenia redukują przyjmowanie szczegółowych logów (np. kontroli stanu). Weryfikuj filtry, aby uniknąć niezamierzonego odrzucania krytycznych logów.

  Przykład: utwórz ujście BigQuery dla logów audytowych

undefined

Przykład: utwórz wykluczenie

undefined

• Zapytania i Log Explorer

  • Używaj zaawansowanych filtrów dla resource.type, severity, etykiet i ładunków JSON. Zapisuj zapytania dla typowych ścieżek diagnostycznych (błędy uruchomienia, permissionDenied, quotaExceeded).
  • Twórz metryki dystrybucji i licznikowe oparte na logach na potrzeby alertów i pulpitów nawigacyjnych.

• Cloud Audit Logs

  • Logi aktywności administratora (Admin Activity): zawsze włączone, bez opłat za przyjmowanie; rejestrują operacje zapisu administracyjnego (np. createInstance).
  • Logi dostępu do danych (Data Access): rejestrują operacje odczytu i zapisu w płaszczyźnie danych (np. storage.objects.get). Domyślnie wyłączone dla wielu usług; włączaj selektywnie, ponieważ wolumen i koszt mogą być wysokie.
  • Logi zdarzeń systemowych (System Event): działania systemu Google (np. autoscaler, migracja na żywo w ramach konserwacji).
  • Logi odmowy przez politykę (Policy Denied): jawne zapisy odmów polityk IAM i organizacji. Kluczowe dla rozwiązywania problemów z dostępem i przeglądów bezpieczeństwa.
  • Kieruj logi audytowe do BigQuery w celu retencji i dochodzeń; indeksuj etykiety takie jak authenticationInfo.principalEmail w celu atrybucji.

• Error Reporting, Trace i Profiler

  • Error Reporting automatycznie grupuje ślady stosu (stack traces) według usługi i wersji; zintegruj z kanałami powiadomień dla nowych grup błędów i nagłych wzrostów.
  • Cloud Trace zbiera rozkłady opóźnień żądań i spany; ustaw próbkowanie (sampling), aby zrównoważyć narzut i wierność (np. 1 na 1000 dla usług o wysokim QPS, z próbkowaniem opartym na ogonie (tail-based), jeśli używasz kolektorów OpenTelemetry).
  • Profiler zapewnia niskonarzutowe, ciągłe profilowanie CPU/sterty w środowisku produkcyjnym. Ogranicz do gorących ścieżek (hot paths) lub reprezentatywnych obciążeń, aby kontrolować wolumen danych i narzut. Użyj mapowania źródeł (source mapping) dla czytelnych grafów wywołań.
  • Kompromisy: wyższe próbkowanie poprawia diagnostykę, ale zwiększa koszt i potencjalne ujawnienie danych PII; czyść wrażliwe pola i używaj tokenizacji.

Rozwiązywanie problemów z usługami, zasobami i siecią

Efektywne rozwiązywanie problemów przechodzi od objawów do granic systemu, a następnie do zasobów i zależności.

• Kondycja usług zarządzanych, status usług, limity (quotas), incydenty regionalne

  • Sprawdź, czy incydent nie pochodzi z wyższego poziomu (upstream): sprawdź kondycję usługi i najnowsze komunikaty regionalne. Szukaj nagłych wzrostów liczby błędów, podwyższonej latencji lub błędów związanych z limitami.
  • Limity (quotas) są określane na poziomie projektu i często na poziomie regionu; błędy quotaExceeded i rateLimitExceeded w logach wskazują na dławienie (throttling). Wnioskuj o zwiększenie limitów przed okresami szczytowego obciążenia.
  • Tryb awarii: częściowe awarie regionalne mogą objawiać się jako sporadyczne błędy; tam, gdzie to możliwe, konfiguruj przełączanie awaryjne (failover) między regionami.

• Kondycja zasobów i diagnostyka maszyn wirtualnych

  • Korzystaj z operacji na instancjach, zdarzeń konserwacyjnych i kontroli kondycji (health checks). W przypadku MIGs, sprawdzaj restarty w ramach automatycznego leczenia (autohealing) i błędy kontroli kondycji, aby wyizolować wadliwe obrazy lub konfiguracje.

  • Konsola szeregowa maszyny wirtualnej do odczytu komunikatów rozruchowych i jądra (kernel):

undefined

- Częste przyczyny: `kernel panics`, błędne wpisy w `fstab` blokujące rozruch, nieprawidłowe konfiguracje sieciowe, błędna konfiguracja OS Login powodująca problemy z SSH.

• Zapewnij dostęp za pomocą OS Login z kluczami SSH per użytkownik i rolami IAM (compute.osLogin lub compute.osAdminLogin), aby umożliwić przypisywanie dostępu.

• Logs Explorer do analizy awarii

  • Zacznij od logów z objawami (np. 5xx, deadlineExceeded), filtruj według etykiet zasobów, a następnie skoreluj ze zmianami we wdrożeniach i logami dotyczącymi limitów. Użyj widoków histogramu, aby zlokalizować punkty zmiany.

• Obserwowalność sieci

  • VPC Flow Logs: próbkowanie ruchu 5-krotki (5-tuple) per-VNIC; włączane na poziomie podsieci. Dostosuj próbkowanie (np. 0.5) i opcje metadanych, aby zrównoważyć wydajność i szczegółowość.

undefined

• Logowanie zapory sieciowej (firewall): przechwytuj decyzje o zezwoleniu/odrzuceniu (allow/deny) dla krytycznych reguł, aby diagnozować nieoczekiwane blokady lub przesłanianie reguł (shadowing).

undefined

• Connectivity Tests: modeluj i weryfikuj osiągalność między sieciami VPC, peeringiem, Cloud VPN, Cloud Interconnect oraz przez reguły zapory sieciowej. Przydatne do walidacji przed wprowadzeniem zmian i do wstępnej analizy incydentów (triage).

undefined

• Sygnały uzupełniające: logi z Cloud NAT i load balancerów do diagnozowania problemów z ruchem wychodzącym (egress) i na brzegu sieci (edge). Tryby awarii obejmują routing asymetryczny, brakujące trasy, nieprawidłową kolejność reguł zapory sieciowej i ograniczenia wynikające z polityk (policy constraints).

Niezawodność, SLO i operacje związane z incydentami

Dyscyplina operacyjna łączy telemetrię z celami dotyczącymi wpływu na użytkownika i spójnym zarządzaniem incydentami.

• SLO, budżety błędów i punkty odniesienia

  • Definiuj SLO w oparciu o SLI zorientowane na użytkownika (dostępność, opóźnienie, poprawność). Przykład: 99,9% żądań odczytu zakończonych w czasie poniżej 200 ms w ciągu 30 dni.
  • Śledź budżety błędów i projektuj zagregowane pulpity nawigacyjne (dashboards) według usług i wersji wydania. Uzależniaj wdrożenia (rollouts) od zużycia budżetu.
  • Ustal bazowe wskaźniki wydajności (baselines) przed wzrostem ruchu; regresje są wykrywane przez odchylenie od normy, a nie przez wartości bezwzględne.

• Redukcja szumu informacyjnego w alertach

  • Preferuj alerty na poziomie usługi zamiast na poziomie instancji. Używaj warunków opartych na tempie zmian (rate-of-change) i percentylach. Stosuj ograniczanie powiadomień (throttling), automatyczne zamykanie incydentów i wyciszanie alertów podczas okien serwisowych.
  • Deduplikuj alerty za pomocą wspólnych etykiet i polityk; używaj routingu uwzględniającego zależności, aby uniknąć powiadamiania (paging) zarówno w przypadku bazy danych, jak i aplikacji w ramach tego samego incydentu.

• Przepływ pracy reakcji na incydenty

  • Przeprowadź weryfikację (triage) i określ wagę incydentu; przypisz role (dowodzący incydentem, zespół operacyjny, komunikacja, protokolant).
  • Ścieżki eskalacji: dyżury (on-call), eksperci dziedzinowi (SME) i wsparcie dostawcy (w zgłoszeniach do supportu podawaj ID projektu, ID zapytań, znaczniki czasu i regiony).
  • Komunikacja: utrzymuj jedno źródło prawdy (kanał czatu i dokument incydentu). Dostarczaj okresowe aktualizacje dla interesariuszy, zawierające informacje o wpływie, działaniach mitygujących i przewidywanym czasie rozwiązania (ETA).
  • Scenariusze mitygacji (playbooks): wycofanie zmiany (rollback), przełączenie awaryjne (failover), wyłączenie flagi funkcyjnej (feature flag) lub dodanie zasobów. Preferuj odwracalne zmiany o małym zasięgu (blast radius).

• Przegląd poincydentalny i analiza przyczyn źródłowych (RCA)

  • Oparty na dowodach: koreluj metryki, logi, ślady (traces) i zdarzenia zmian. Uwzględnij, jakie sygnały detekcji zadziałały (lub nie), dlaczego, oraz czas potrzebny na wykrycie/mitygację.
  • Zidentyfikuj czynniki sprzyjające, a nie tylko bezpośrednią przyczynę. Zapisz konkretne zadania do wykonania z przypisanymi właścicielami i terminami; odpowiednio zaktualizuj runbooki i alerty.
  • Kultura „bez obwiniania” (blameless culture) zachęca do pełnej transparentności i wprowadzania systemowych poprawek.

• Runbooki operacyjne

  • Struktura: wyzwalacz i detekcja, drzewo szybkiej diagnozy, bezpieczne działania mitygujące, kroki wycofania/przywrócenia, weryfikacja i kryteria zakończenia.
  • Przygotuj polecenia i filtry gotowe do skopiowania; zweryfikuj zasadę najmniejszych uprawnień (least-privilege) w IAM dla osób reagujących (na przykład storage.objectCreator dla kopii zapasowych z uprawnieniami tylko do zapisu; dedykowane konta serwisowe dla tożsamości obciążeń).
  • Wersjonuj runbooki w ramach zarządzania zmianą; testuj je podczas symulacji awarii (game days).

Praktyczny scenariusz problemu

Firma Northwind Outfitters prowadzi regionalną platformę e-commerce na Google Cloud. Po niedawnym gwałtownym wzroście ruchu użytkownicy sporadycznie zgłaszają przekroczenia limitu czasu przy finalizacji zakupu (checkout) i powolne wyszukiwanie produktów. Zespół operacyjny musi szybko przywrócić niezawodność, zredukować szum w alertach i wzmocnić diagnostykę w wielu projektach.

Podejście:

1. Skonsoliduj monitoring pomiędzy projektami

• Działanie: Utwórz pojedynczy obszar roboczy (workspace) w Monitoring i połącz z nim projekty prod, payments i search. Zbuduj pulpit nawigacyjny „Ścieżka Użytkownika” (User Journey), pokazujący dostępność, opóźnienia i wskaźniki błędów dla procesów finalizacji zakupu i wyszukiwania.
• Uzasadnienie: Scentralizowana widoczność wspiera weryfikację (triage) na poziomie usług i pozwala korelować problemy międzyusługowe (na przykład opóźnienia w wyszukiwaniu kaskadujące na przekroczenia limitu czasu przy finalizacji zakupu).

2. Wdróż SLO i alerty oparte na tempie zużycia budżetu (burn-rate)

• Działanie: Zdefiniuj SLO: 99,9% finalizacji zakupu poniżej 400 ms, 99,95% wyszukiwań poniżej 250 ms. Utwórz alerty oparte na tempie zużycia budżetu (burn-rate) w wielu oknach czasowych (2% w ciągu 1 godziny i 5% w ciągu 5 minut) dla SLI opóźnienia i wskaźnika błędów. Powiadamiaj dyżur (on-call) przez pager, a interesariuszy przez czat.
• Uzasadnienie: Alerty oparte na burn-rate wychwytują szybkie regresje i długotrwałe, powolne zużywanie budżetu, nie generując powiadomień (paging) przy normalnych wahaniach.

3. Dodaj syntetyczne testy dostępności (uptime checks) z weryfikacją treści

• Działanie: Skonfiguruj testy dostępności TCP i HTTPS dla publicznych punktów wejścia oraz prywatny test dostępności dla wewnętrznego API płatności, weryfikując, czy treść odpowiedzi zawiera „ok”.
• Uzasadnienie: Wykrywa problemy z osiągalnością i częściowe awarie, takie jak błędnie skierowany ruch do backendu lub zdegradowane usługi nadrzędne (upstreams).

4. Uściślij routing i retencję logów

• Działanie: Utwórz dedykowane zasobniki (buckets) na logi: ops (90 dni), security-audit (2 lata, z CMEK). Przekieruj logi Admin Activity, Data Access, System Event i Policy Denied do BigQuery za pomocą ujść (sinks) w celach analitycznych. Dodaj wykluczenia dla generujących dużo wpisów kontroli stanu (health checks).
• Uzasadnienie: Odpowiednio dobrana retencja kontroluje koszty; BigQuery umożliwia szybką analizę śledczą (forensics). Wykluczenia redukują szum bez utraty kluczowych dowodów.

5. Włącz diagnostykę aplikacji

• Działanie: Zinstrumentuj usługi za pomocą OpenTelemetry w celu śledzenia (Trace); włącz Error Reporting dla backendu i frontendu; wdróż Profiler w usłudze finalizacji zakupu z profilowaniem CPU i sterty (heap) przy konserwatywnym próbkowaniu.
• Uzasadnienie: Ślady (traces) identyfikują ścieżki o wysokim opóźnieniu; Error Reporting wyróżnia nowe grupy błędów; Profiler ujawnia rywalizację o CPU i wycieki pamięci przy niskim narzucie.

6. Wzmocnij obserwowalność sieci

• Działanie: Włącz VPC Flow Logs na podsieciach produkcyjnych (próbkowanie 0.5, uwzględnij wszystkie metadane) oraz logowanie zapory sieciowej (firewall) dla reguł zezwalających/blokujących ruch przychodzący do usług wyszukiwania i płatności. Utwórz Connectivity Tests z warstwy webowej do usługi wyszukiwania oraz z usługi płatności do Cloud SQL.
• Uzasadnienie: Logi przepływu (flow logs) i zapory sieciowej ujawniają odrzucone pakiety, retransmisje i przesłonięte reguły; Connectivity Tests weryfikują osiągalność i identyfikują błędne konfiguracje.

7. Diagnostyka na poziomie zasobów i bezpieczny dostęp

• Działanie: W przypadku niestabilnych maszyn wirtualnych, badaj problemy z uruchamianiem za pomocą konsoli szeregowej:

undefined

• Jeśli wymagany jest dostęp SSH, wymuś użycie OS Login i nadaj uprawnienie compute.osAdminLogin grupie „ops-admins”. Każdy administrator używa własnego klucza SSH.
• Uzasadnienie: Logi z konsoli szeregowej ujawniają błędy jądra (kernel) i procesu inicjującego (init). OS Login z kluczami per-użytkownik zapewnia przypisywalny dostęp zgodny z zasadą najmniejszych uprawnień.

8. Weryfikacja limitów (quota) i stanu regionu

• Działanie: Przejrzyj ostatnie zdarzenia quotaExceeded w logach; podnieś regionalne limity API i adresów IP dla autoskalowania usługi wyszukiwania. Sprawdź komunikaty o stanie usług dla dotkniętego regionu; tymczasowo przenieś ruch za pomocą wag w load balancerze.
• Uzasadnienie: Dławienie przez limity (quota throttling) i incydenty regionalne są częstymi źródłami sporadycznych awarii; proaktywne skalowanie i sterowanie ruchem łagodzą ich skutki.

9. Redukcja szumu i aktualizacja runbooków

• Działanie: Zastąp alerty CPU per-instancja alertami o nasyceniu na poziomie usługi. Dodaj okna serwisowe, aby wyciszyć alerty niewymagające działania. Zaktualizuj runbooki o nowe zapytania do weryfikacji (triage), pulpity nawigacyjne śladów (traces) i procedury wycofywania zmian (rollback).
• Uzasadnienie: Redukuje zmęczenie powiadomieniami (paging fatigue) i przyspiesza spójne, bezpieczne reakcje.

10. Przegląd poincydentalny i działania naprawcze

• Działanie: Przeprowadź przegląd poincydentalny w kulturze „bez obwiniania”. Skoreluj incydenty związane ze zużyciem budżetu (burn-rate) ze zwiększonym opóźnieniem krańcowym (tail latency) w wyszukiwaniu i niedawnym wdrożeniem nowego indeksu. Działania do wykonania: dodaj wdrożenia kanarkowe (canary releases) dla wyszukiwania, zabezpieczenia (guardrails) dotyczące rozmiaru indeksu i zapas mocy (headroom) w autoskalerze; zobowiąż się do okresowych testów kanałów alertów.
• Uzasadnienie: Analiza przyczyn źródłowych (RCA) oparta na dowodach zapobiega ponownemu wystąpieniu problemu i poprawia wykrywanie, mitygację i odporność systemu.

← Wdrażanie · Wszystkie domeny · Bezpieczeństwo →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Google →