Google ACE: Überwachung, Protokollierung und operative Fehlerbehebung — Lernleitfaden

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

Teil des Google Associate Cloud Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Operationale Exzellenz in Google Cloud hängt davon ab, Telemetriedaten in Maßnahmen umzusetzen. Monitoring, Logging und Troubleshooting liefern zusammen die Signale, Leitplanken und Workflows, die die Zuverlässigkeit von Diensten gewährleisten. Dieser Abschnitt behandelt die zentralen Observability-Dienste, Diagnose-Tools, Praktiken zur Zuverlässigkeit und den Umgang mit Incidents, einschließlich Design-Grundlagen, Kompromissen und häufigen Fehlermodi.

Grundlagen von Monitoring und Benachrichtigungen

Cloud Monitoring erfasst Zeitreihen von Google Cloud-Diensten, Agents und benutzerdefinierten Metriken, um Dashboards, Verfügbarkeitsprüfungen, SLOs und Benachrichtigungen bereitzustellen.

Metriken und Kardinalität
- Überwachte Ressourcentypen (z. B. gce_instance, aws_ec2_instance, global) definieren Dimensionen wie Projekt, Region und Instanz-ID.
- Minimieren Sie ungebundene Label-Werte (z. B. user_id), um Explosionen hoher Kardinalität zu vermeiden, die Abfragen verlangsamen und die Kosten erhöhen.
- Bevorzugen Sie Verteilungsmetriken für Latenz (p50/p90/p99) und verwenden Sie Alignment-Fenster für konsistente Rollups.
Dashboards
- Nutzen Sie die integrierten Service-Dashboards für einen schnellen Einstieg. Erstellen Sie benutzerdefinierte Dashboards, um projektübergreifende Metriken zu gruppieren. Organisieren Sie Panels nach Symptom (Latenz, Fehler, Sättigung) vor der Ursache (CPU, Arbeitsspeicher).
- Vermeiden Sie Diagramme pro Instanz für Flotten; aggregieren Sie nach Dienst, Zone oder MIG, um Rauschen zu reduzieren und das Signal zu verstärken.
Benachrichtigungsrichtlinien
- Entwerfen Sie symptom-basierte Benachrichtigungen, die an die User Experience gekoppelt sind: SLO-Burn-Rate der Verfügbarkeit, Latenzperzentile, Fehlerraten. Verwenden Sie Multi-Window- und Multi-Burn-Rate-Benachrichtigungen, um schnellen und langsamen Burn zu erfassen (z. B. 2 % über 1 Stunde und 5 % über 5 Minuten).
- Legen Sie angemessene Limits für die Benachrichtigungsrate und ein automatisches Schließverhalten fest. Verwenden Sie Annotationen zur automatischen Incident-Mitigation, um Runbooks zu dokumentieren.
- Verwenden Sie Benachrichtigungen bei fehlenden Metriken für kritische Batch-Jobs und Datenpipelines mit strengen Zeitplänen.
- Log-basierte Metriken unterstützen Benachrichtigungen für Anwendungs- oder Sicherheitsereignisse (z. B. wiederholte permissionDenied).
Benachrichtigungskanäle
- Konfigurieren Sie Kanäle je nach Schweregrad: Paging für SEV1 (On-Call, SMS, Telefon), Chat für SEV2/3, E-Mail oder Webhooks für niedrige Priorität. Verwenden Sie Pub/Sub für die Integration mit Ticketing- oder Automatisierungssystemen.
- Testen Sie Kanäle regelmäßig; veraltete Kanäle sind ein stiller Fehlermodus.
Verfügbarkeitsprüfungen und synthetisches Monitoring
- HTTP(S)- und TCP-Prüfungen von globalen Standorten aus verifizieren die externe Erreichbarkeit. Kombinieren Sie Prüfungen mit Inhaltsabgleichen, um Teilausfälle zu erkennen.
- Nutzen Sie private Verfügbarkeitsprüfungen über hybride Konnektivität oder Private Service Connect für interne Dienste.
- Fehlermodi: Prüfungen können aufgrund von DNS-TTL-Verzögerungen, Problemen bei der Rotation von TLS-Zertifikaten oder regionalen Ausfällen fehlschlagen; bestätigen Sie dies mit Metriken, bevor Sie Paging auslösen.
Projektübergreifendes Monitoring
- Verwenden Sie einen einzigen Monitoring-Workspace und verknüpfen Sie alle Projekte für konsolidierte Dashboards und Benachrichtigungen. Dies vereinfacht flottenweite SLOs und reduziert Duplikate.

Logging, Audit und Anwendungsdiagnose

Cloud Logging ist die Log-Routing-, Speicher- und Abfrageebene für Plattform- und Anwendungslogs. Ergänzende APM-Tools (Error Reporting, Trace, Profiler) beschleunigen die Isolierung der Grundursache.

Log-Routing, Buckets, Sinks und Aufbewahrung
- Leiten Sie Logs mit Sinks an Log-Buckets (Standard oder benutzerdefiniert), BigQuery (Analyse), Pub/Sub (Stream-Verarbeitung) oder Cloud Storage (Archivierung) weiter.
- Verwenden Sie regional begrenzte Log-Buckets für Datenresidenz und Performance. Wenden Sie CMEK an, falls von Compliance-Vorgaben gefordert.
- Legen Sie die Aufbewahrungsdauer pro Bucket fest (z. B. 30–90 Tage für den Betrieb, mehrere Jahre für Audits). Längere Aufbewahrung erhöht die Kosten; filtern Sie aggressiv, um die Ausgaben zu kontrollieren.
- Ausschlüsse reduzieren die Erfassung von ausführlichen Logs (z. B. Health Checks). Validieren Sie Filter, um das unbeabsichtigte Verwerfen kritischer Logs zu vermeiden.
Beispiel: Erstellen eines BigQuery-Sinks für Audit-Logs

undefined

Beispiel: Erstellen eines Ausschlusses

undefined

Abfragen und Log Explorer
- Verwenden Sie erweiterte Filter für resource.type, severity, Labels und JSON-Payloads. Speichern Sie Abfragen für gängige Triage-Pfade (Startfehler, permissionDenied, quotaExceeded).
- Erstellen Sie verteilungs- und zählerbasierte Log-Metriken für Benachrichtigungen und Dashboards.
Cloud Audit Logs
- Admin Activity-Logs: immer aktiv, keine Kosten für die Erfassung; zeichnen administrative Schreibvorgänge auf (z. B. createInstance).
- Data Access-Logs: zeichnen Lese- und Schreibvorgänge auf der Datenebene auf (z. B. storage.objects.get). Standardmäßig für viele Dienste deaktiviert; aktivieren Sie sie selektiv, da Volumen und Kosten hoch sein können.
- System Event-Logs: Google-Systemaktionen (z. B. Autoscaler, Live-Migration bei Wartung).
- Policy Denied-Logs: explizite Aufzeichnungen von Verweigerungen durch IAM- und Organisationsrichtlinien. Kritisch für die Fehlerbehebung bei Zugriffen und für Sicherheitsüberprüfungen.
- Leiten Sie Audit-Logs zur Aufbewahrung und Untersuchung an BigQuery weiter; indizieren Sie Labels wie authenticationInfo.principalEmail für die Zuordnung.
Error Reporting, Trace und Profiler
- Error Reporting gruppiert Stack-Traces automatisch nach Dienst und Version; integrieren Sie es mit Benachrichtigungskanälen für neue Fehlergruppen und plötzliche Anstiege.
- Cloud Trace sammelt Latenzverteilungen und Spans von Anfragen; legen Sie das Sampling fest, um Overhead und Genauigkeit auszugleichen (z. B. 1 von 1000 für Dienste mit hohen QPS, mit Tail-based Sampling bei Verwendung von OpenTelemetry-Kollektoren).
- Profiler bietet kontinuierliches CPU-/Heap-Profiling in der Produktion mit geringem Overhead. Beschränken Sie es auf Hot Paths oder repräsentative Workloads, um Datenvolumen und Overhead zu kontrollieren. Verwenden Sie Source-Mapping für lesbare Aufrufgraphen.
- Kompromisse: Höheres Sampling verbessert die Diagnose, erhöht aber die Kosten und das potenzielle Risiko der Offenlegung von personenbezogenen Daten (PII); bereinigen Sie sensible Felder und verwenden Sie Tokenisierung.

Fehlerbehebung bei Services, Ressourcen und Netzwerken

Eine effiziente Fehlerbehebung bewegt sich von den Symptomen zu den Systemgrenzen und dann zu den Ressourcen und Abhängigkeiten.

Zustand von Managed Services, Servicestatus, Kontingente, regionale Störungen
- Überprüfen Sie, ob eine Störung vorgelagert ist: Prüfen Sie den Servicestatus und aktuelle regionale Meldungen. Achten Sie auf Fehlerspitzen, erhöhte Latenz oder Kontingentfehler.
- Kontingente gelten pro Projekt und oft pro Region; quotaExceeded und rateLimitExceeded in den Logs deuten auf eine Drosselung hin. Beantragen Sie Erhöhungen vor Spitzenlast-Ereignissen.
- Fehlermodus: Teilweise regionale Ausfälle können als intermittierende Fehler erscheinen; konfigurieren Sie nach Möglichkeit ein multiregionales Failover.
Ressourcenzustand und VM-Diagnose
- Nutzen Sie Instanzoperationen, Wartungsereignisse und Zustandsprüfungen. Bei MIGs untersuchen Sie Autohealing-Neustarts und Fehler bei Zustandsprüfungen, um fehlerhafte Images oder Konfigurationen zu isolieren.
- Serielle Konsole der VM für Boot- und Kernel-Meldungen:
  - gcloud compute connect-to-serial-port VM_NAME –zone=ZONE
  - Häufige Ursachen: Kernel Panics, fehlerhafte fstab-Einträge, die den Bootvorgang blockieren, falsche Netzwerkkonfigurationen, Fehlkonfiguration von OS Login, die zu SSH-Fehlern führt.
- Stellen Sie OS Login mit benutzerspezifischen SSH-Schlüsseln und IAM-Rollen (compute.osLogin oder compute.osAdminLogin) für einen zuordenbaren Zugriff sicher.
Logs Explorer zur Fehleranalyse
- Beginnen Sie mit Symptom-Logs (5xx, deadlineExceeded), wechseln Sie die Ansicht anhand von Ressourcen-Labels und korrelieren Sie diese dann mit Änderungen am Deployment und Kontingent-Logs. Verwenden Sie Histogrammansichten, um Änderungspunkte zu lokalisieren.
Netzwerk-Beobachtbarkeit
- VPC Flow Logs: Stichprobenerfassung des 5-Tupel-Traffics pro VNIC; auf Subnetzen aktivieren. Passen Sie das Sampling (z. B. 0.5) und die Metadaten-Optionen an, um Leistung und Detailgrad abzuwägen.
  - gcloud compute networks subnets update SUBNET –region=REGION –enable-flow-logs –flow-sampling=0.5 –aggregation-interval=interval-5-min –metadata=include-all
- Firewall-Logging: Erfassen Sie Allow/Deny-Entscheidungen für kritische Regeln, um unerwartete Blockierungen oder Regelüberschattungen (Shadowing) zu diagnostizieren.
  - gcloud compute firewall-rules update RULE_NAME –enable-logging
- Connectivity Tests: Modellieren und überprüfen Sie die Erreichbarkeit über VPCs, Peering, Cloud VPN, Cloud Interconnect und Firewall-Regeln hinweg. Nützlich für die Validierung vor Änderungen und die Triage von Störungen.
  - gcloud network-management connectivity-tests create test-a –source-instance=projects/PRJ/zones/ZONE/instances/VM1 –destination-ip=10.0.3.21 –protocol=TCP –destination-port=443
- Ergänzende Signale: Logs von Cloud NAT und Load Balancern für Egress- und Edge-Probleme. Zu den Fehlermodi gehören asymmetrisches Routing, fehlende Routen, Firewall-Regeln in falscher Reihenfolge und Richtlinieneinschränkungen.

Zuverlässigkeit, SLOs und Incident-Betrieb

Operative Disziplin verknüpft Telemetrie mit Zielen, die sich auf die Nutzer auswirken, und einer konsistenten Incident-Bearbeitung.

SLOs, Error Budgets und Baselines
- Definieren Sie SLOs auf Basis nutzerzentrierter SLIs (Verfügbarkeit, Latenz, Korrektheit). Beispiel: 99,9 % der Leseanfragen werden über 30 Tage in unter 200 ms abgeschlossen.
- Verfolgen Sie Error Budgets und entwerfen Sie Rollup-Dashboards nach Service und Release-Version. Machen Sie Rollouts vom Budgetverbrauch abhängig.
- Erstellen Sie Performance-Baselines, bevor der Traffic ansteigt; Regressionen werden durch Abweichungen erkannt, nicht durch absolute Werte.
Reduzierung von Alert-Rauschen
- Bevorzugen Sie Alerts auf Service-Ebene gegenüber Alerts auf Instanz-Ebene. Verwenden Sie Bedingungen, die auf Änderungsraten und Perzentilen basieren. Wenden Sie Drosselung von Benachrichtigungen, automatisches Schließen von Incidents und Stummschaltung von Alerts für Wartungsfenster an.
- Deduplizieren Sie Alerts über gemeinsame Labels und Richtlinien; verwenden Sie abhängigkeitsbasiertes Routing, um Paging sowohl für die Datenbank als auch für die Anwendung bei demselben Incident zu vermeiden.
Workflow für die Incident-Bearbeitung
- Führen Sie eine Triage durch und legen Sie den Schweregrad fest; weisen Sie Rollen zu (Incident Commander, Operations, Communications, Scribe).
- Eskalationspfade: Rufbereitschafts-Rotationen, Fachexperten (Subject-Matter Experts) und Anbieter-Support (geben Sie in Support-Tickets Projekt-ID, Request-IDs, Zeitstempel und Regionen an).
- Kommunikation: Pflegen Sie eine zentrale Informationsquelle („Single Source of Truth“) (Chat-Kanal und Incident-Dokument). Stellen Sie regelmäßige Updates für Stakeholder bereit, die Auswirkungen, Gegenmaßnahmen und voraussichtliche Lösungszeiten (ETAs) enthalten.
- Playbooks für Gegenmaßnahmen: Rollback, Failover, Deaktivierung von Feature-Flags oder Hinzufügen von Kapazität. Bevorzugen Sie reversible Änderungen mit einem kleinen „Blast Radius“ (Wirkungsbereich).
Post-Incident-Review und RCA
- Evidenzbasiert: Korrelieren Sie Metriken, Logs, Traces und Änderungsereignisse. Dokumentieren Sie, welche Erkennungssignale ausgelöst wurden (oder warum nicht) und die Zeit bis zur Erkennung/Behebung (Time-to-Detect/Mitigate).
- Identifizieren Sie die beitragenden Faktoren, nicht nur die unmittelbare Ursache. Erfassen Sie konkrete Action Items mit Verantwortlichen und Fristen; aktualisieren Sie Runbooks und Alerts entsprechend.
- Eine „Blameless Culture“ (schuldfreie Kultur) fördert die vollständige Offenlegung und systemische Korrekturen.
Operative Runbooks
- Struktur: Auslöser und Erkennung, schneller Diagnosebaum, sichere Gegenmaßnahmen, Rollback-/Wiederherstellungsschritte, Verifizierung und Abschlusskriterien.
- Halten Sie Befehle und Filter zum Kopieren und Einfügen bereit; überprüfen Sie Least-Privilege-IAM für die zuständigen Mitarbeiter (Responder) (zum Beispiel storage.objectCreator für schreibgeschützte Backups; dedizierte Service Accounts für Workload Identity).
- Versionieren Sie Runbooks mit Change Management; testen Sie sie während sogenannter „Game Days“.

Praktisches Problemszenario

Northwind Outfitters betreibt eine regionale E-Commerce-Plattform auf Google Cloud. Nach einem kürzlichen Anstieg des Traffics melden Benutzer zeitweise Zeitüberschreitungen beim Checkout und langsame Produktsuchen. Das Betriebsteam muss die Zuverlässigkeit schnell wiederherstellen, das Alert-Rauschen reduzieren und die Diagnose über mehrere Projekte hinweg härten.

Vorgehensweise:

Konsolidierung des Monitorings über Projekte hinweg

Aktion: Erstellen Sie einen einzigen Monitoring-Workspace und verknüpfen Sie die Projekte prod, payments und search. Erstellen Sie ein „User Journey“-Dashboard, das Verfügbarkeit, Latenz und Fehlerraten für Checkout und Suche anzeigt.
Begründung: Zentralisierte Sichtbarkeit unterstützt die Triage auf Service-Ebene und korreliert serviceübergreifende Probleme (z. B. wenn Latenz bei der Suche zu Zeitüberschreitungen beim Checkout führt).

Implementierung von SLOs und Burn-Rate-Alerting

Aktion: Definieren Sie SLOs: 99,9 % Checkout unter 400 ms, 99,95 % Suche unter 250 ms. Erstellen Sie Multi-Window-Burn-Alerts (2 % über 1 Stunde und 5 % über 5 Minuten) für Latenz- und Fehlerraten-SLIs. Benachrichtigen Sie die Rufbereitschaft per Paging und die Stakeholder per Chat.
Begründung: Burn-Rate-Alerts erkennen schnelle Regressionen und anhaltende langsame „Burns“ (Budgetverbräuche), ohne bei normalen Schwankungen Paging auszulösen.

Hinzufügen von synthetischen Uptime-Checks mit Inhaltsabgleich

Aktion: Konfigurieren Sie TCP- und HTTPS-Uptime-Checks für die öffentlichen Entrypoints und einen privaten Uptime-Check für die interne Payment-API, der validiert, dass der Response Body „ok“ enthält.
Begründung: Erkennt Erreichbarkeit und Teilausfälle wie falsch geroutete Backends oder beeinträchtigte Upstreams.

Straffung der Logging-Routen und Aufbewahrungsfristen

Aktion: Erstellen Sie dedizierte Log-Buckets: ops (90 Tage), security-audit (2 Jahre, CMEK). Leiten Sie Admin Activity-, Data Access-, System Event- und Policy Denied-Logs über Sinks zur Analyse an BigQuery weiter. Fügen Sie Ausschlüsse für „geschwätzige“ Health Checks hinzu.
Begründung: Angepasste Aufbewahrungsfristen kontrollieren die Kosten; BigQuery ermöglicht schnelle Forensik. Ausschlüsse reduzieren das Rauschen, ohne kritische Beweise zu verlieren.

Aktivierung der Anwendungsdiagnose

Aktion: Instrumentieren Sie Services mit OpenTelemetry für Trace; aktivieren Sie Error Reporting für Backend und Frontend; führen Sie Profiler für den Checkout-Service mit CPU- und Heap-Profilen bei konservativem Sampling ein.
Begründung: Traces identifizieren Latenz-Hot-Paths; Error Reporting hebt neue Fehlergruppen hervor; Profiler deckt CPU-Konflikte und Speicherlecks mit geringem Overhead auf.

Stärkung der Netzwerk-Beobachtbarkeit (Observability)

Aktion: Aktivieren Sie VPC Flow Logs auf Prod-Subnetzen (0,5 Sampling, alle Metadaten einschließen) und Firewall-Logging für Allow/Deny-Regeln für Ingress zu Search und Payments. Erstellen Sie Connectivity Tests vom Web-Tier zu Search und von Payments zu Cloud SQL.
Begründung: Flow- und Firewall-Logs decken Drops, Retransmits und „Shadowed Rules“ (verdeckte Regeln) auf; Connectivity Tests validieren die Erreichbarkeit und identifizieren Fehlkonfigurationen.

Diagnose auf Ressourcenebene und sicherer Zugriff

Aktion: Bei instabilen VMs, untersuchen Sie Boot-Probleme mit der seriellen Konsole:

undefined

Wenn SSH erforderlich ist, erzwingen Sie OS Login und gewähren Sie der Gruppe „ops-admins“ die Berechtigung compute.osAdminLogin. Jeder Admin verwendet seinen eigenen SSH-Schlüssel.
Begründung: Serielle Logs decken Kernel- und Init-Fehler auf. OS Login mit benutzerspezifischen Schlüsseln gewährleistet einen nachvollziehbaren Zugriff nach dem Least-Privilege-Prinzip.

Überprüfung von Kontingenten und regionaler Integrität

Aktion: Überprüfen Sie die jüngsten quotaExceeded-Ereignisse in den Logs; erhöhen Sie das regionale API- und IP-Kontingent für das Search-Autoscaling. Prüfen Sie die Service-Health-Advisories für die betroffene Region; verlagern Sie den Traffic vorübergehend durch die Gewichtung des Load Balancers.
Begründung: Kontingentdrosselung und regionale Incidents sind häufige Ursachen für intermittierende Ausfälle; proaktives Skalieren und Traffic-Steuerung mindern die Auswirkungen.

Rauschreduzierung und Aktualisierung der Runbooks

Aktion: Ersetzen Sie CPU-Alerts pro Instanz durch Sättigungs-Alerts auf Service-Ebene. Fügen Sie Wartungsfenster hinzu, um nicht handlungsrelevante Alerts stummzuschalten. Aktualisieren Sie die Runbooks mit neuen Triage-Abfragen, Trace-Dashboards und Rollback-Verfahren.
Begründung: Reduziert die Paging-Ermüdung und beschleunigt konsistente, sichere Reaktionen.

Post-Incident-Review und Maßnahmen

Aktion: Führen Sie einen „Blameless Review“ (schuldfreie Überprüfung) durch. Korrelieren Sie Burn-Rate-Incidents mit erhöhter Tail-Latenz bei der Suche und einem kürzlichen Index-Rollout. Action Items: Canary-Releases für die Suche hinzufügen, Guardrails für die Indexgröße und Puffer (Headroom) für den Autoscaler einrichten; regelmäßige Tests der Alert-Kanäle zusagen.
Begründung: Eine evidenzbasierte RCA verhindert ein erneutes Auftreten und verbessert die Erkennung, Behebung und Resilienz.

← Bereitstellung · Alle Domänen · Sicherheit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →