Google ACE: Monitoring, logging en operationele probleemoplossing — Studiegids

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

Onderdeel van de Google Associate Cloud Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Operationele uitmuntendheid op Google Cloud is afhankelijk van het omzetten van telemetrie in actie. Monitoring, Logging en Troubleshooting bieden samen de signalen, vangrails en workflows die services betrouwbaar houden. Dit gedeelte behandelt de kerndiensten voor observability, diagnostische tools, betrouwbaarheidspraktijken en incidentoperaties, inclusief ontwerpredenen, afwegingen en veelvoorkomende faalscenario’s.

Fundamenten van Monitoring en Alarmering

Cloud Monitoring neemt tijdreeksen op van Google Cloud-services, agents en aangepaste metrics om dashboards, uptime-controles, SLO’s en alarmering te bieden.

• Metrics en kardinaliteit

  • Gemonitorde resourcetypes (bijvoorbeeld gce_instance, aws_ec2_instance, global) bepalen de scope van dimensies zoals project, regio en instance-ID.
  • Minimaliseer ongelimiteerde labelwaarden (bijvoorbeeld user_id) om explosies van hoge kardinaliteit te voorkomen die query’s vertragen en de kosten verhogen.
  • Geef de voorkeur aan distributiemetrics voor latentie (p50/p90/p99) en gebruik alignment-vensters voor consistente rollups.

• Dashboards

  • Gebruik ingebouwde service-dashboards voor een snelle start. Maak aangepaste dashboards om metrics van verschillende projecten te groeperen. Organiseer panelen op symptoom (latentie, fouten, verzadiging) vóór oorzaak (CPU, geheugen).
  • Vermijd grafieken per instance voor groepen machines; aggregeer per service, zone of MIG om ruis te verminderen en het signaal te versterken.

• Alarmeringsbeleid

  • Ontwerp symptoomgebaseerde meldingen die gekoppeld zijn aan de gebruikerservaring: SLO-burn van beschikbaarheid, latentiepercentielen, foutpercentages. Gebruik multi-window, multi-burn-rate meldingen om snelle en langzame burn te detecteren (bijvoorbeeld 2% over 1 uur en 5% over 5 minuten).
  • Stel redelijke limieten voor meldingsfrequentie en automatisch sluitgedrag in. Gebruik annotaties voor automatische incidentmitigatie om runbooks te documenteren.
  • Gebruik meldingen voor afwezige metrics voor kritieke batchtaken en datapijplijnen met strikte schema’s.
  • Op logs gebaseerde metrics ondersteunen meldingen voor applicatie- of beveiligingsevenementen (bijvoorbeeld herhaalde permissionDenied).

• Meldingskanalen

  • Configureer kanalen per ernstgraad: paging voor SEV1 (on-call, sms, telefoon), chat voor SEV2/3, e-mail of webhooks voor lage prioriteit. Gebruik Pub/Sub voor integratie met ticketingsystemen of automatisering.
  • Test kanalen periodiek; verouderde kanalen zijn een stille faalmodus.

• Uptime-controles en synthetische monitoring

  • HTTP(S)- en TCP-controles vanaf wereldwijde observatiepunten verifiëren de externe bereikbaarheid. Koppel controles aan content-matching om gedeeltelijke storingen te detecteren.
  • Gebruik private uptime-controles via hybride connectiviteit of Private Service Connect voor interne services.
  • Faalscenario’s: controles kunnen mislukken door DNS TTL-vertraging, problemen met TLS-certificaatrotatie of regio-specifieke storingen; bevestig met metrics voordat je een paging-actie start.

• Multi-project monitoring

  • Gebruik één enkele Monitoring-workspace en koppel alle projecten voor geconsolideerde dashboards en meldingen. Dit vereenvoudigt SLO’s voor de gehele vloot en vermindert duplicatie.

Logging, Audit en Applicatiediagnostiek

Cloud Logging is de logrouter, opslag- en query-laag voor platform- en applicatielogs. Aanvullende APM-tools (Error Reporting, Trace, Profiler) versnellen de isolatie van de hoofdoorzaak.

• Log-routering, buckets, sinks en retentie

  • Routeer met sinks naar log-buckets (standaard of aangepast), BigQuery (analyse), Pub/Sub (streamverwerking) of Cloud Storage (archivering).
  • Gebruik regionaal gescoopte log-buckets voor dataresidentie en prestaties. Pas CMEK toe indien vereist door compliance.
  • Stel retentie per bucket in (bijvoorbeeld 30-90 dagen voor operationele logs, meerdere jaren voor auditlogs). Langere retentie verhoogt de kosten; filter agressief om de uitgaven te beheersen.
  • Uitsluitingen verminderen de opname van uitgebreide logs (bijvoorbeeld health checks). Valideer filters om te voorkomen dat kritieke logs onbedoeld worden verwijderd.

  Voorbeeld: maak een BigQuery-sink voor auditlogs

undefined

Voorbeeld: maak een uitsluiting

undefined

• Query’s en Log Explorer

  • Gebruik geavanceerde filters op resource.type, severity, labels en JSON-payloads. Sla query’s op voor veelvoorkomende triage-paden (opstartfouten, permissionDenied, quotaExceeded).
  • Maak op logs gebaseerde distributie- en tellermetrics voor alarmering en dashboards.

• Cloud Audit Logs

  • Admin Activity-logs: altijd ingeschakeld, geen kosten voor opname; registreren administratieve schrijfbewerkingen (bijvoorbeeld createInstance).
  • Data Access-logs: registreren lees- en schrijfbewerkingen op de data-plane (bijvoorbeeld storage.objects.get). Standaard uitgeschakeld voor veel services; schakel selectief in omdat het volume en de kosten hoog kunnen zijn.
  • System Event-logs: Google-systeemacties (bijvoorbeeld autoscaler, live migratie voor onderhoud).
  • Policy Denied-logs: expliciete registraties van IAM- en organisatiebeleid-weigeringen. Cruciaal voor het oplossen van toegangsproblemen en voor beveiligingsreviews.
  • Routeer auditlogs naar BigQuery voor retentie en onderzoek; indexeer labels zoals authenticationInfo.principalEmail voor attributies.

• Error Reporting, Trace en Profiler

  • Error Reporting groepeert automatisch stack traces per service en versie; integreer met meldingskanalen voor nieuwe foutgroepen en plotselinge pieken.
  • Cloud Trace verzamelt distributies en spans van request-latentie; stel sampling in om de overhead en de nauwkeurigheid in evenwicht te houden (bijvoorbeeld 1 op 1000 voor services met hoge QPS, met tail-based sampling bij gebruik van OpenTelemetry collectors).
  • Profiler biedt continue CPU/heap-profiling met lage overhead in productie. Beperk tot hot paths of representatieve workloads om datavolume en overhead te beheersen. Gebruik source mapping voor leesbare call graphs.
  • Afwegingen: hogere sampling verbetert de diagnostiek maar verhoogt de kosten en de potentiële blootstelling van PII; gevoelige velden opschonen en tokenisatie gebruiken.

Probleemoplossing voor Services, Resources en Netwerken

Efficiënte probleemoplossing begint bij symptomen, gaat dan naar systeemgrenzen, en vervolgens naar resources en afhankelijkheden.

• Status van beheerde services, servicestatus, quota’s, regionale incidenten

  • Valideer of een incident upstream plaatsvindt: controleer de servicestatus en recente regionale adviezen. Zoek naar pieken in foutmeldingen, verhoogde latency of quotafouten.
  • Quota’s zijn per project en vaak per regio; quotaExceeded en rateLimitExceeded in logs duiden op throttling. Vraag verhogingen aan voorafgaand aan piekmomenten.
  • Faalmodus: gedeeltelijke regionale storingen kunnen zich voordoen als intermittente fouten; configureer waar mogelijk multi-regionale failover.

• Status van resources en VM-diagnostiek

  • Gebruik instance-operaties, onderhoudsgebeurtenissen en health checks. Inspecteer voor MIGs de autohealing-restarts en mislukte health checks om foute images of configuraties te isoleren.

  • VM seriële console voor opstart- en kernelberichten:

undefined

- Veelvoorkomende oorzaken: kernel panics, foute fstab-vermeldingen die het opstarten blokkeren, incorrecte netwerkconfiguraties, misconfiguratie van OS Login die SSH-fouten veroorzaakt.

• Zorg voor OS Login met per-gebruiker SSH-sleutels en IAM-rollen (compute.osLogin of compute.osAdminLogin) voor toewijsbare toegang.

• Logs Explorer voor foutanalyse

  • Begin met symptoomlogs (5xx, deadlineExceeded), pivoteer op resource-labels en correleer vervolgens met wijzigingen in deployments en quotalogs. Gebruik histogramweergaven om veranderingspunten te lokaliseren.

• Netwerk-observeerbaarheid

  • VPC Flow Logs: per-VNIC sampling van 5-tuple verkeer; schakel in op subnets. Pas de sampling (bijvoorbeeld 0.5) en metadata-opties aan voor een balans tussen prestaties en detailniveau.

undefined

• Firewall-logging: leg allow/deny-beslissingen vast voor kritieke regels om onverwachte blokkades of ‘shadowing’ te diagnosticeren.

undefined

• Connectivity Tests: modelleer en verifieer de bereikbaarheid over VPC’s, peering, Cloud VPN, Cloud Interconnect en firewallregels. Nuttig voor validatie vóór wijzigingen en voor triage bij incidenten.

undefined

• Aanvullende signalen: Cloud NAT- en load balancer-logs voor egress- en edge-problemen. Faalmodi omvatten asymmetrische routing, ontbrekende routes, verkeerd geordende firewallregels en beleidsbeperkingen.

Betrouwbaarheid, SLO’s en Incident Operations

Operationele discipline koppelt telemetrie aan doelstellingen voor gebruikersimpact en een consistente afhandeling van incidenten.

• SLO’s, foutbudgetten en baselines

  • Definieer SLO’s op basis van gebruikersgerichte SLI’s (beschikbaarheid, latency, correctheid). Voorbeeld: 99,9% van de leesverzoeken wordt binnen 200 ms voltooid over een periode van 30 dagen.
  • Houd foutbudgetten bij en ontwerp ‘rollup’-dashboards per service en releaseversie. Blokkeer rollouts op basis van het verbruik van het budget.
  • Stel performance-baselines vast voordat het verkeer toeneemt; regressies worden gedetecteerd door afwijking, niet door absolute waarden.

• Reductie van alert-ruis

  • Geef de voorkeur aan alerts op serviceniveau boven alerts op instanceniveau. Gebruik condities gebaseerd op veranderingssnelheid en percentielen. Pas ’notification throttling’, het automatisch sluiten van incidenten en het dempen van alerts toe voor onderhoudsvensters.
  • Dedupliceer alerts via gemeenschappelijke labels en beleidsregels; gebruik afhankelijkheidsbewuste routering om te voorkomen dat zowel de database als de applicatie worden gepaged voor hetzelfde incident.

• Workflow voor incidentrespons

  • Voer triage uit en bepaal de ernst; wijs rollen toe (incident commander, operations, communications, notulist).
  • Escalatiepaden: wachtdienstschema’s, vakexperts en leveranciersondersteuning (vermeld project-ID, request-ID’s, timestamps en regio’s in supporttickets).
  • Communicatie: onderhoud een ‘single source of truth’ (chatkanaal en incidentdocument). Geef periodieke updates aan stakeholders met informatie over de impact, mitigatie en ETA’s.
  • Mitigatie-playbooks: rollback, failover, uitschakelen van feature flags of capaciteit toevoegen. Geef de voorkeur aan omkeerbare wijzigingen met een kleine ‘blast radius’.

• Post-incident review en RCA

  • Bewijsgestuurd: correleer metrics, logs, traces en wijzigingsevents. Beschrijf welke detectiesignalen zijn afgegaan, waarom wel of niet, en de ’time-to-detect/mitigate’.
  • Identificeer bijdragende factoren, niet alleen de directe oorzaak. Leg concrete actiepunten vast met eigenaren en deadlines; werk runbooks en alerts dienovereenkomstig bij.
  • Een ‘blameless’ cultuur moedigt volledige openheid en systemische oplossingen aan.

• Operationele runbooks

  • Structuur: trigger en detectie, snelle diagnoseboom, veilige mitigaties, rollback-/herstelstappen, verificatie en exitcriteria.
  • Houd commando’s en filters gereed om te kopiëren en plakken; verifieer ’least-privilege’ IAM voor responders (bijvoorbeeld storage.objectCreator voor write-only back-ups; toegewijde service accounts voor workload identity).
  • Versiebeheer runbooks met change management; test ze tijdens ‘game days’.

Praktijkscenario

Northwind Outfitters beheert een regionaal e-commerceplatform op Google Cloud. Na een recente piek in het verkeer melden gebruikers met tussenpozen time-outs bij het afrekenen en trage zoekopdrachten naar producten. Het operations-team moet snel de betrouwbaarheid herstellen, alert-ruis verminderen en de diagnostiek over meerdere projecten heen versterken.

Aanpak:

1. Consolideer monitoring over projecten heen

• Actie: Maak één Monitoring-workspace en koppel de prod-, payments- en search-projecten. Bouw een ‘User Journey’-dashboard dat beschikbaarheid, latency en foutpercentages voor afrekenen en zoeken toont.
• Reden: Gecentraliseerd inzicht ondersteunt triage op serviceniveau en correleert problemen tussen services (bijvoorbeeld zoeklatency die doorwerkt in time-outs bij het afrekenen).

2. Implementeer SLO’s en burn-rate alerting

• Actie: Definieer SLO’s: 99,9% afrekenen onder 400 ms, 99,95% zoeken onder 250 ms. Maak ‘multi-window burn alerts’ (2% over 1 uur en 5% over 5 minuten) op latency- en foutpercentage-SLI’s. Breng de wachtdienst op de hoogte via paging, stakeholders via chat.
• Reden: Burn-rate alerts detecteren snelle regressies en aanhoudende ‘slow burns’ zonder te pagen bij normale variatie.

3. Voeg synthetische uptime checks met content match toe

• Actie: Configureer TCP- en HTTPS-uptime checks voor de publieke entrypoints en een private uptime check naar de interne payment-API, die valideert dat de response body ‘ok’ bevat.
• Reden: Detecteert bereikbaarheid en gedeeltelijke storingen zoals verkeerd gerouteerde backends of verslechterde upstreams.

4. Scherp logging-routes en retentie aan

• Actie: Maak toegewijde log buckets: ops (90 dagen), security-audit (2 jaar, CMEK). Routeer Admin Activity-, Data Access-, System Event- en Policy Denied-logs naar BigQuery via sinks voor analyse. Voeg uitsluitingen toe voor ‘spraakzame’ health checks.
• Reden: Een juiste bewaartermijn beheerst de kosten; BigQuery maakt snelle forensische analyse mogelijk. Uitsluitingen verminderen ruis zonder kritiek bewijs te verliezen.

5. Schakel applicatiediagnostiek in

• Actie: Instrumenteer services met OpenTelemetry voor Trace; schakel Error Reporting in voor backend en frontend; rol Profiler uit naar de checkout-service met CPU- en heap-profielen met conservatieve sampling.
• Reden: Traces identificeren ‘hot paths’ met hoge latency; Error Reporting licht nieuwe foutgroepen uit; Profiler onthult CPU-conflicten en geheugenlekken met lage overhead.

6. Versterk netwerk-observeerbaarheid

• Actie: Schakel VPC Flow Logs in op prod-subnetten (0.5 sampling, include-all metadata) en firewall-logging op allow/deny-regels voor ingress naar search en payments. Maak Connectivity Tests aan van de web-tier naar search en van payments naar Cloud SQL.
• Reden: Flow- en firewall-logs leggen drops, retransmits en ‘shadowed rules’ bloot; Connectivity Tests valideren bereikbaarheid en identificeren misconfiguraties.

7. Diagnostiek op resourceniveau en veilige toegang

• Actie: Inspecteer voor instabiele VM’s opstartproblemen met de seriële console:

undefined

• Als SSH vereist is, dwing dan OS Login af en verleen compute.osAdminLogin aan de ‘ops-admins’-groep. Elke beheerder gebruikt zijn eigen SSH-sleutel.
• Reden: Seriële logs onthullen kernel- en init-fouten. OS Login met sleutels per gebruiker zorgt voor toerekenbare ’least-privilege’-toegang.

8. Verificatie van quota en regionale status

• Actie: Controleer recente quotaExceeded-events in logs; verhoog de regionale API- en IP-quota voor search-autoscaling. Controleer de service-statusadviezen voor de getroffen regio; verplaats tijdelijk verkeer met load balancer-weging.
• Reden: ‘Quota throttling’ en regionale incidenten zijn veelvoorkomende bronnen van intermitterende storingen; proactief schalen en verkeerssturing beperken de impact.

9. Ruisreductie en runbook-updates

• Actie: Vervang per-instance CPU-alerts door ‘saturation alerts’ op serviceniveau. Voeg onderhoudsvensters toe om niet-actionable alerts te dempen. Werk runbooks bij met nieuwe triage-query’s, trace-dashboards en rollback-procedures.
• Reden: Vermindert ‘paging fatigue’ en versnelt consistente, veilige reacties.

10. Post-incident review en acties

• Actie: Voer een ‘blameless’ review uit. Correleer burn-rate-incidenten met toegenomen ’tail latency’ bij het zoeken en een recente index-rollout. Actiepunten: voeg canary releases toe voor de zoekfunctie, ‘guardrails’ voor de indexgrootte en ‘headroom’ voor de autoscaler; committeer aan periodieke tests van het alert-kanaal.
• Reden: Een bewijsgestuurde RCA voorkomt herhaling en verbetert detectie, mitigatie en veerkracht.

← Implementatie · Alle domeinen · Beveiliging →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Google →