Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Best Practices für die Beobachtbarkeit von GKE-Netzwerken

Autopilot Standard

Die Verwaltung von Netzwerkverbindungen und Sicherheitsrichtlinien in dynamischen Kubernetes-Umgebungen stellt eine erhebliche betriebliche Herausforderung dar. Die Beobachtbarkeit von GKE Dataplane V2 bietet Plattformadministratoren Einblicke in den Netzwerkverkehr des Clusters auf Kernelebene. Dies kann zu einer schnellen Fehlerbehebung, kontinuierlichen Compliance-Prüfung und proaktiven Pfadvalidierung beitragen.

In diesem Dokument werden die konzeptionelle Architektur und Best Practices für die Netzwerkbeobachtbarkeit von Google Kubernetes Engine (GKE) beschrieben, einschließlich des Telemetriestacks, eines mentalen Modells für die Fehlerbehebung, proaktiver Benachrichtigungsregeln, Terraform-Automatisierung und Techniken zur Kostenoptimierung.

Eine detaillierte Anleitung zur Fehlerbehebung und zu Diagnoseverfahren finden Sie unter Fehlerbehebung bei der Netzwerkbeobachtbarkeit.

Vorteile der GKE-Netzwerkbeobachtbarkeit

Die Implementierung einer Beobachtbarkeitsstrategie in GKE bietet die folgenden wichtigen Vorteile:

Schnellere durchschnittliche Zeit bis zur Problemlösung (Mean Time to Resolution, MTTR): Mithilfe von eBPF-basierten Messwerten und Hubble-Flusslogs können Sie Netzwerkanomalien sofort isolieren. So können Sie zwischen Fehlern auf Anwendungsebene, Kubernetes NetworkPolicy-Blockierungen und VPC-Firewall-Drops unterscheiden und die Debugging-Zyklen von Stunden auf Minuten verkürzen.
Instrumentierung auf Kernelebene ohne Sidecars:GKE Dataplane V2 führt die Observability-Logik direkt im Linux-Kernel des Hosts mit eBPF aus. Dadurch sind keine ressourcenintensiven Sidecar-Proxys oder Codeänderungen auf Anwendungsebene erforderlich. Das sorgt für minimalen Overhead und eine gleichbleibende Anwendungsleistung.
Kontinuierliche Prüfung der Sicherheits-Compliance:Durch die NetworkPolicy-Protokollierung werden detaillierte Audit-Logs für jeden Verbindungsversuch (Ergebnisse von ALLOW oder DENY) generiert. Diese Logs bieten einen manipulationssicheren Datensatz des Cluster-Traffics, der für die Einhaltung regulatorischer Anforderungen (z. B. PCI-DSS, SOC 2 und HIPAA) unerlässlich ist.
Proaktive Pfadvalidierung:Durch die Integration mit Konnektivitätstests können Sie Netzwerkpfade simulieren und GKE-NetworkPolicies statisch bewerten, bevor Arbeitslasten bereitgestellt werden. So lassen sich Konfigurationsabweichungen und Konnektivitätsprobleme in der Bereitstellungsphase vermeiden.
Ressourcen- und Kostenoptimierung:Durch die detaillierte Flussverfolgung werden Ineffizienzen wie eine übermäßige Nutzung von Cloud NAT-Ports, Spitzen bei der Datenübertragung zwischen Zonen und nicht im Cache gespeicherte DNS-Auflösungsmuster aufgedeckt. So können Sie fundierte Kapazitätsplanung und Kostenverwaltung vornehmen.

Architektur der GKE-Netzwerkbeobachtbarkeit

GKE Dataplane V2 bietet einen mehrschichtigen Beobachtbarkeitsstack, der für verschiedene Betriebsphasen entwickelt wurde. In der folgenden Tabelle sind die wichtigsten Komponenten und ihre empfohlenen Anwendungsfälle aufgeführt:

Beobachtbarkeitskomponente	Primärer Anwendungsfall	Verfügbarkeit	Datenaufbewahrung	Leistungsaufwand	Wichtige Telemetriesignale
GKE Dataplane V2-Messwerte	Systemweites Gesundheitsmonitoring, Trendanalyse und Benachrichtigungen.	Nur GKE Dataplane V2	Aufbewahrung von Verlaufsdaten (Cloud Monitoring und Google Cloud Managed Service for Prometheus speichern Messwerte und Logs für 30 Tage oder länger)	Gering (Aggregation auf Kernelebene)	Paket- und Byte-Zähler, Anzahl der TCP-Rücksetzungen und Verbindungsabbrüche (`pod_flow_drop_count`).
NetworkPolicy-Logs	Prüfung von Sicherheitsrichtlinien, Analyse von Verbindungen aus der Vergangenheit und Compliance.	Nur GKE Dataplane V2 (für die Konfiguration der benutzerdefinierten `NetworkLogging`-Ressource)	Konfigurierbar (Cloud Logging)	Niedrig (gepufferter Log-Export)	Verbindungsmetadaten (Quell- und Ziellabels, IP-Adressen, Ports) und Richtlinienergebnisse (`ALLOW` oder `DENY`).
Hubble-Befehlszeile und ‑Benutzeroberfläche	Live- und interaktive Verkehrsanalysen und Debugging auf Paketebene in Echtzeit.	Nur GKE Dataplane V2	Sitzungsspezifisch (knotenlokaler Ringpuffer)	Niedrig (dynamisch aktivieren)	Echtzeit-Ablaufverfolgungen, detaillierte Gründe für das Verwerfen (z. B. Richtlinie abgelehnt oder Sättigung der conntrack-Tabelle).
GKE-DNS-Messwerte	Leistung der DNS-Auflösung, Cache-Effizienz und Upstream-Latenz überwachen.	Alle Cluster	Langfristig (Cloud Monitoring)	Vernachlässigbar	Anzahl der DNS-Anfragen, Verhältnis von Cache-Treffern und ‑Fehlern, Upstream-Weiterleitungsverzögerung und Ablehnungen aufgrund des Limits für gleichzeitige Anfragen.
Konnektivitätstests	Pfadvalidierung vor der Bereitstellung und statische Konfigurationsprüfung.	Alle Cluster	Nicht zutreffend (On-Demand-Simulation)	Keine (statisch simuliert)	Simulierter Paketroutingpfad, einschließlich der simulierten NetworkPolicy-Auswertung.
VPC-Flusslogs	Prüfung des Traffics zwischen Knoten und des externen Traffics, Sicherheitsforensik und Kostenanalyse.	Alle Cluster	Konfigurierbar (Cloud Logging oder BigQuery)	Keine (konfigurierbare Stichprobenrate)	5-Tupel-Verbindungsdetails, gesendete Byte und Pakete, GKE-Metadaten (Namespace, Arbeitslast, Dienst) und RTT (für TCP).
Flow Analyzer	VPC-Traffic visuell analysieren, Top-Talker identifizieren und zonenübergreifende Kosten analysieren, ohne SQL-Abfragen schreiben zu müssen.	Alle Cluster	Abhängig von der Aufbewahrungsdauer des Observability Analytics-Buckets	Keine (analytische Benutzeroberfläche)	Aggregiertes Trafficvolumen und Latenz, gruppiert nach GKE-Arbeitslast oder -Dienst.

In der Tabelle oben bedeutet ein Leistungs-Overhead von Geringfügig, dass Komponenten unabhängig von Trafficvolumen oder Systemskalierung einen minimalen Ressourcenbedarf haben (in der Regel <0,1 vCPU und minimaler Arbeitsspeicher). Niedrige Komponenten haben unter Standardbedingungen einen minimalen Ressourcenbedarf, werden aber dynamisch mit der Trafficdichte skaliert. Bei Szenarien mit hohem Durchsatz kann die Ressourcennutzung auf bis zu 2 vCPUs und mehrere Hundert Megabyte Arbeitsspeicher skaliert werden.

GKE-Beobachtbarkeit – mentales Modell und Triage-Schleife

Um Netzwerkabweichungen effektiv zu beheben, müssen Sie das geeignete Telemetriesignal für Ihren Betriebsbereich auswählen und eine konsistente Triage-Methode anwenden.

Die richtige Telemetriequelle auswählen

Da mehrere Telemetriequellen verfügbar sind, sollten Sie das Tool auswählen, das zu Ihrer aktuellen betrieblichen Aufgabe passt:

Telemetriequelle	Antworten	Ideal für	Google Cloud Ziel
GKE Dataplane V2-Messwerte	Was passiert und in welchem Umfang?	Dashboards, Benachrichtigungen und Kapazitätsplanung.	Cloud Monitoring (`prometheus.googleapis.com`)
NetworkPolicy-Logs	Warum wurde eine Verbindung in GKE blockiert?	Sicherheitsaudits und Ursachenanalyse von Sicherheitsrichtlinien.	Cloud Logging (`policy-action`-Log)
VPC-Flusslogs	Was ist mit diesem Traffic passiert, nachdem er den Pod verlassen hat?	Analyse des bisherigen Traffics zwischen Arbeitslasten, Kosten für die Datenübertragung zwischen Zonen und Zuordnung von Rückgängen auf VPC-Ebene.	Cloud Logging und Observability Analytics (`vpc_flows`-Log)
Hubble-Befehlszeile und ‑Benutzeroberfläche	Was passiert gerade auf dem Knoten?	Live-Debugging, tcpdump-Alternative und aktive Vorfälle.	Flüchtiger Ringpuffer (Hubble-Befehlszeile)
Konnektivitätstests	Kann der Traffic erfolgreich übertragen werden?	Aktive Datenebene-Tests und Pfadanalyse: Erreichbarkeit prüfen und genaue Drop-Punkte über VPC-Firewalls, Routen und GKE-Knoten hinweg ermitteln.	Network Intelligence Center (Simulation)

Standardisierte Schleife zur Fehlerbehebung

Verwenden Sie diesen wiederholbaren Workflow, um GKE-Netzwerkvorfälle zu priorisieren:

Anomalie erkennen:Identifizieren Sie das Problem anhand von Cloud Monitoring-Benachrichtigungen (z. B. Spitzen bei TCP-Resets, Ablehnungen aufgrund des DNS-Limits für gleichzeitige Anfragen oder Paketverluste).
Tier isolieren:Führen Sie den GCE-VM-Basistest aus (siehe Fehlerbehebung bei Latenz auf Knotenebene und CNI-Engpässen), um festzustellen, ob sich der Block innerhalb des GKE-Cluster (CNI, NetworkPolicy, IP-Masquerade) oder außerhalb im VPC (Firewallregeln, Routing, Cloud NAT) befindet.
Ursache untersuchen:Führen Sie eine detaillierte Analyse des Ablaufs durch:
- Bei Live-Vorfällen: Verwenden Sie die Hubble-Befehlszeile (hubble observe), um Flows in Echtzeit zu streamen und Gründe für das Beenden von Verbindungen zu ermitteln.
- Bei früheren oder zeitweiligen Problemen: Fragen Sie NetworkPolicy-Logs oder VPC-Flusslogs in Cloud Logging ab.
Abhilfemaßnahmen validieren:Führen Sie einen simulierten Konnektivitätstest aus, um zu prüfen, ob der Pfad statisch zulässig ist. Sehen Sie dann im Messwert-Dashboard nach, ob die Drop-Rate wieder null beträgt.

Proaktives Netzwerkmonitoring und Benachrichtigungen

Um eine Hochverfügbarkeit zu gewährleisten, sollten Plattformadministratoren Benachrichtigungsrichtlinien in Cloud Monitoring einrichten, um eine Beeinträchtigung des Netzwerks zu erkennen, bevor sie sich auf Arbeitslasten auswirkt.

Benachrichtigung bei Spitzenwerten bei Paketverlusten

Ein anomaler Anstieg der verworfenen Netzwerkflüsse deutet in der Regel auf eine falsch konfigurierte Sicherheitsrichtlinie oder eine Erschöpfung des Connection-Tracking (conntrack) auf Knotenebene hin.

Prometheus-Abfrage (PromQL):

sum(rate(pod_flow_egress_flows_count{verdict="DROPPED"}[5m])) by (source) > 10

Empfohlene Maßnahme:Weitere Informationen finden Sie unter Paketverluste und NetworkPolicy-Blockierungen diagnostizieren, um die spezifische GKE-NetworkPolicy oder den eBPF-Löschgrund zu ermitteln, der den Paketverlust verursacht.

Benachrichtigung bei DNS-Sättigung

Wenn CoreDNS oder NodeLocal DNSCache das Limit für gleichzeitige Abfragen erreicht, werden nachfolgende DNS-Lookups abgelehnt, was zu zeitweiligen Zeitüberschreitungen bei Anwendungen führt.

Prometheus-Abfrage (PromQL):

sum by (cluster_name) (rate(kubernetes_io_networking_dns_kubedns_max_concurrent_rejected_request_count[5m])) > 0

Empfohlene Maßnahme:Skalieren Sie die Anzahl der kube-dns-Repliken oder implementieren Sie NodeLocal DNSCache, um die Auflastung zu verteilen. Eine ausführliche Anleitung finden Sie unter Fehler bei der DNS-Auflösung diagnostizieren.

Benachrichtigung bei Spitzen von TCP-Resets

Ein Anstieg der TCP-Reset-Pakete deutet oft darauf hin, dass ein Backend-Dienst Verbindungen ablehnt, möglicherweise aufgrund von Anwendungsabstürzen oder einer Überlastung der Socket-Warteschlange.

Monitoring Query Language (MQL):

fetch prometheus_target
| metric 'prometheus.googleapis.com/hubble_tcp_flags_total/counter'
| filter (metric.flag == 'RST')
| align rate(1m)
| every 1m
| group_by [metric.source, metric.destination], sum(val())
| condition val() > 50

Empfohlene Maßnahme:Informationen zum Untersuchen von Verbindungsstabilität oder Anwendungswarteschlangensättigung finden Sie unter Ungleichgewicht beim Traffic und TCP-Resets diagnostizieren.

Automatisierte Pfadvalidierung in CI/CD

Integrieren Sie Konnektivitätstests in Bereitstellungspipelines, um Netzwerkpfade statisch zu validieren, bevor Sie Produktionstraffic weiterleiten. Verwenden Sie die gcloud CLI, um zu prüfen, ob neu bereitgestellte Arbeitslasten ohne Richtlinienblockierungen auf externe Abhängigkeiten (z. B. Datenbanken und APIs) zugreifen können.

Beispielbefehl:

gcloud network-management connectivity-tests create test-prod-db-egress \
    --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/my-app-pod \
    --destination-ip-address=10.240.0.100 \
    --protocol=TCP \
    --destination-port=5432

Observability Analytics für die visuelle Flussanalyse aktivieren

Wenn Sie VPC-Traffic-Flüsse visuell und ohne SQL analysieren möchten, upgraden Sie den GKE-Log-Bucket (in der Regel den _Default-Bucket), um Observability Analytics zu verwenden. So können Plattformadministratoren mit Flow Analyzer die Traffic-Verteilung und die Kosten für die Datenübertragung untersuchen. Weitere Informationen finden Sie unter Kosten und Leistung von Clustertraffic mit Flow Analyzer analysieren.

Terraform-Automatisierung: Observability-as-Code

Um diese Architektur für die Beobachtbarkeit konsistent zu implementieren und manuelle Einrichtungsfehler zu vermeiden, stellen Sie die Telemetriepipeline mit der folgenden Terraform-Konfiguration bereit (erfordert den google-beta-Anbieter):

# Configure the VPC Subnet with VPC Flow Logs enabled and all metadata included
resource "google_compute_subnetwork" "gke_subnet" {
  name          = "gke-subnet"
  ip_cidr_range = "10.0.0.0/20"
  region        = "us-central1"
  network       = google_compute_network.custom.id

  # Enable VPC Flow Logs. flow_sampling is the secondary sampling rate, which
  # applies to flow log entries after they are generated. The primary packet
  # sampling rate is dynamic and isn't configurable.
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.5 # Default rate; satisfies the LIGHT org policy tier
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

# Configure GKE Cluster with Dataplane V2, Intranode Visibility, and Hubble
resource "google_container_cluster" "primary" {
  provider   = google-beta
  name       = "gke-observability-cluster"
  location   = "us-central1"
  network    = google_compute_network.custom.id
  subnetwork = google_compute_subnetwork.gke_subnet.id

  # Enable Dataplane V2 (Required for all advanced telemetry)
  datapath_provider = "ADVANCED_DATAPATH"

  # Enable Intranode Visibility (ensures local node pod-to-pod traffic hits the VPC)
  enable_intranode_visibility = true

  # Enable Managed Service for Prometheus (GMP)
  monitoring_config {
    enable_components = ["SYSTEM_COMPONENTS"]
    managed_prometheus {
      enabled = true
    }

    # Enable Dataplane V2 Flow Observability (Hubble Relay and metric exposure)
    advanced_datapath_observability_config {
      enable_metrics = true
      enable_relay   = true
    }
  }
}

# Upgrade the Default log bucket to use Log Analytics (required for Flow Analyzer)
resource "google_logging_project_bucket_config" "default_analytics" {
  project          = var.project_id
  location         = "global"
  bucket_id        = "_Default"
  enable_analytics = true
}

# Define a baseline static path validation test (Pod to external internet gateway)
resource "google_network_management_connectivity_test" "pod_to_internet" {
  name = "pod-to-internet-egress"
  source {
    gke_pod = "projects/${var.project_id}/locations/us-central1/clusters/${google_container_cluster.primary.name}/k8s/namespaces/prod/pods/my-app-pod"
  }
  destination {
    ip_address = "8.8.8.8"
    port       = 443
  }
  protocol = "TCP"
}

Kostenoptimierung und Rauschunterdrückung

Netzwerktelemetrie (Messwerte und Logs) kann erhebliche Datenmengen generieren, was zu hohen Aufnahme- und Speicherkosten führt. Mit den folgenden Strategien können Sie die Erfassung von Telemetriedaten optimieren, ohne die Sichtbarkeit kritischen Traffics zu verlieren:

Logs für zulässige Verbindungen deaktivieren

Standardmäßig werden beim NetworkPolicy-Logging sowohl zugelassene als auch abgelehnte Verbindungen erfasst. Zulässige Verbindungen machen den Großteil des Logvolumens aus (oft 99% oder mehr des Traffics). Sie können die NetworkLogging-Konfiguration des Clusters so aktualisieren, dass nur abgelehnte Verbindungen (Drops) erfasst werden. Dadurch werden die Loggingkosten erheblich gesenkt:

Speichern Sie das folgende Manifest als network-logging-config.yaml:

apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: false # Disable logging for allowed traffic
      delegate: false
    deny:
      log: true  # Keep logging for blocked traffic (critical for security/triage)
      delegate: false

Wenden Sie die Konfiguration an:

kubectl apply -f network-logging-config.yaml

Logging über Annotationen delegieren

Wenn Sie die Kosten detailliert kontrollieren möchten, können Sie die Protokollierung an Anmerkungen delegieren, indem Sie delegate: true in der benutzerdefinierten Ressource NetworkLogging festlegen. Diese Konfiguration sorgt für Folgendes:

Zulässiger Traffic wird nur protokolliert, wenn die entsprechende NetworkPolicy die Annotation policy.network.gke.io/enable-logging: "true" hat.
Abgelehnter Traffic wird nur für Pod-Objekte in Namespaces protokolliert, die mit policy.network.gke.io/enable-deny-logging: "true" annotiert sind.

Mit dieser Konfiguration können Sie die Protokollierung nur für hochkritische Arbeitslasten (z. B. Zahlungs-Gateways) aktivieren und Dienste mit geringem Risiko ignorieren.

Samplingrate für VPC-Flusslogs anpassen

Reduzieren Sie in Ihrer Terraform-Konfiguration (oder Google Cloud -Console) die sekundäre Samplingrate nur für Subnetze, in denen Sie Trafficvolumen und Kostenaggregate anstelle einzelner Flow-Datensätze benötigen. Da bei VPC-Flusslogs der Gesamttraffic anhand von Stichprobenpaketen geschätzt wird, können Byte- und Paketanzahlen auch bei niedrigeren Raten für die Kostenanalyse verwendet werden. Legen Sie die Rate flow_sampling nicht niedriger als 0.1 fest. Das ist die Mindestrate, die die Stufe ESSENTIAL der Organisationsrichtlinie constraints/compute.requireVpcFlowLogs erfüllt:

resource "google_compute_subnetwork" "gke_subnet" {
  # ... other subnet configs ...
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.1 # ESSENTIAL tier: volume and cost analysis, not per-flow troubleshooting
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

In der folgenden Tabelle sind die sekundären Sampling-Raten und die entsprechenden Stufen der constraints/compute.requireVpcFlowLogs-Organisationsrichtlinie zusammengefasst:

Sekundäre Stichprobenrate	Ebene der Organisationsrichtlinie	Verwendung
`1.0`	`COMPREHENSIVE`	Cluster mit einer ständigen Anforderung für die Forensik pro Flow oder Sicherheitsüberprüfung. Wählen Sie diese Rate aus, wenn Sie das Subnetz konfigurieren. Wenn Sie die Rate nach einem Vorfall erhöhen, können Sie keine Flows wiederherstellen, die nie erfasst wurden.
`0.5` (Standard)	`LIGHT`	Subnetze, die Cluster unterstützen, bei denen Sie Probleme beheben. Dies ist die Standardrate und die empfohlene Baseline.
`0.1`	`ESSENTIAL`	Subnetze, für die Sie Traffic-Volumen und Kostenaggregate anstelle einzelner Flows benötigen.

Cloud Logging-Ausschlüsse anwenden

Schließen Sie irrelevante Logs (z. B. kube-system-internen Traffic) direkt auf der Ebene der Cloud Logging-Senke aus. Fügen Sie Ihrer _Default-Senke einen Ausschlussfilter hinzu, um interne Metadaten oder System-Pod-Logs zu verwerfen:

resource.type="gce_subnetwork" AND
log_name:"projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND
jsonPayload.src_gke_details.pod.pod_namespace="kube-system"

Best Practices und operative Tipps

Beachten Sie beim Bereitstellen und Warten Ihrer Cluster-Telemetriepipeline die folgenden Betriebsrichtlinien:

GKE Dataplane V2-Flow-Beobachtbarkeit bei Bedarf aktivieren:Die Flow-Beobachtbarkeit (hubble-relay) kann zu einem geringen Mehraufwand führen. In Produktionsclustern können Sie die Funktion während der Debugging-Sitzungen aktivieren und danach deaktivieren, um den Ressourcenverbrauch auf Knoten zu minimieren:
```
gcloud container clusters update CLUSTER_NAME \
    --enable-dataplane-v2-flow-observability \
    --location=LOCATION
```
Knoteninterne Sichtbarkeit aktivieren:Standardmäßig verlässt der Traffic zwischen zwei Pod-Objekten auf demselben Knoten den Knoten nicht, sodass er für VPC-Flusslogs nicht sichtbar ist. Die knoteninterne Sichtbarkeit ist in Autopilot-Clustern standardmäßig aktiviert und in Standardclustern standardmäßig deaktiviert, einschließlich Standardclustern, die GKE Dataplane V2 verwenden. Durch Aktivieren der Sichtbarkeit innerhalb von Knoten wird dieser Traffic über die VPC geleitet. So wird dafür gesorgt, dass VPC-Firewallregeln und Flusslogs konsistent angewendet werden.
Verhalten bei der Auflösung der VIP des Dienstes verstehen:Nachdem eine virtuelle IP-Adresse (VIP) eines Kubernetes-Dienstes in eine IP-Adresse eines Backend-Pods aufgelöst wurde, werden Transportebenenmesswerte (OSI-Schicht 4) als Pod-zu-Pod-Traffic gezählt. Um nachzuvollziehen, welche Service-VIP ursprünglich als Ziel festgelegt wurde, können Sie sich während des Verbindungs-Handshakes auf die Live-Flows der Hubble-Befehlszeile verlassen.
Zeitstempel für Messwerte und Logs abstimmen:Wenn Sie einen Vorfall untersuchen, sollten Sie den Anstieg der Cloud Monitoring-Messwerte mit dem genauen Zeitfenster korrelieren, in dem Sie Logs in Cloud Logging oder der Hubble-Befehlszeile abfragen, um sicherzustellen, dass Sie dasselbe Ereignis analysieren.