VPC-Flusslogs

VPC-Flusslogs zeichnen eine Stichprobe von Netzwerkflüssen auf, die von VM-Instanzen gesendet und empfangen werden, einschließlich Instanzen, die als Google Kubernetes Engine-Knoten verwendet werden. Diese Logs können für Netzwerk-Monitoring, Forensik, Echtzeit-Sicherheitsanalysen und Kostenoptimierung verwendet werden.

Sie können sich die Flusslogs in Cloud Logging ansehen und in jedes Ziel exportieren, das vom Cloud Logging-Export unterstützt wird.

Flusslogs werden durch Verbindung von Compute Engine-VMs aggregiert und in Echtzeit exportiert. Wenn Sie Pub/Sub abonnieren, können Sie Flusslogs mithilfe von APIs für Echtzeitstreaming analysieren.

Haupteigenschaften

• VPC-Flusslogs sind Teil der Andromeda-Software, die VPC-Netzwerken zugrunde liegt. VPC-Flusslogs weisen keine Verzögerung oder Leistungseinbußen auf, wenn sie aktiviert sind.
• VPC-Flusslogs funktionieren in Verbindung mit VPC-Netzwerken, nicht mit Legacy-Netzwerken. Sie aktivieren oder deaktivieren VPC-Flusslogs pro Subnetz. Wenn VPC-Flusslogs für ein Subnetz aktiviert sind, werden Daten von allen VM-Instanzen in diesem Subnetz erfasst.
• VPC-Flusslogs zeichnen Stichproben der TCP-, UDP-, ICMP-, ESP- und GRE-Flüsse jeder VM auf. Sowohl ein- als auch ausgehende Datenströme werden erfasst. Diese Abläufe können innerhalb von Google Cloud oder zwischen Google Cloud und anderen Netzwerken erfolgen. Wenn ein Fluss durch Stichproben erfasst wird, erstellen VPC-Flusslogs ein Log für den Fluss. Jeder Flusseintrag enthält die im Abschnitt Eintragsformat beschriebenen Daten.
• VPC-Flusslogs interagieren so mit Firewallregeln:
  • Ausgehende Pakete werden vor ausgehenden Firewallregeln als Stichprobe erfasst. Selbst wenn eine Firewallregel für ausgehenden Traffic ausgehende Pakete ablehnt, können diese Pakete von VPC-Flusslogs als Stichprobe verwendet werden.
  • Eingehende Pakete werden nach eingehenden Firewallregeln als Stichprobe erfasst. Wenn eine eingehende Firewallregel eingehende Pakete ablehnt, werden diese Pakete nicht von VPC-Flusslogs als Stichprobe verwendet.
• Sie können Filter in VPC-Flusslogs verwenden, um nur bestimmte Logs zu generieren.
• VPC-Flusslogs unterstützen VMs mit mehreren Netzwerkschnittstellen. Sie müssen VPC-Flusslogs für jedes Subnetz in jeder VPC aktivieren, die eine Netzwerkschnittstelle enthält.
• Wenn Sie Datenflüsse zwischen Pods auf demselben GKE-Knoten (Google Kubernetes Engine) protokollieren möchten, müssen Sie für den Cluster die knoteninterne Sichtbarkeit aktivieren.
• VPC-Flusslogs werden nicht von Nicht-VM-Ressourcen wie Cloud Run oder lokalen Endpunkten gemeldet.

Anwendungsfälle

Netzwerküberwachung

VPC-Flusslogs bietet Ihnen Echtzeitinformationen zum Netzwerkdurchsatz und zur Netzwerkleistung. Sie haben folgende Möglichkeiten:

• Überwachung des VPC-Netzwerks
• Durchführung von Netzwerkdiagnosen
• Filterung der Flusslogs nach VMs und nach Anwendungen, um Trafficänderungen zu verstehen
• Informationen zum Trafficwachstum für Kapazitätsprognosen

Netzwerknutzung verstehen und Kosten des Netzwerk-Traffics senken

Sie können die Netzwerknutzung mithilfe von VPC-Flusslogs analysieren. Für folgende Netzwerkflüsse ist eine Analyse möglich:

• Traffic zwischen Regionen und Zonen
• Traffic in bestimmte Länder im Internet
• Top Talkers

Auf der Grundlage der Analyse lassen sich dann die Kosten des Netzwerk-Traffics optimieren.

Netzwerkforensik

Sie können VPC-Flusslogs für die Netzwerkforensik nutzen. Zum Beispiel haben Sie bei einem Vorfall die Möglichkeit, Folgendes zu überprüfen:

• Welche IPs haben mit wem und wann kommuniziert?
• Wurden IPs gefährdet (durch die Analyse aller eingehenden und ausgehenden Netzwerkflüsse)?

Echtzeit-Sicherheitsanalyse

Sie können die APIs für Echtzeitstreaming (über Pub/Sub) nutzen und in SIEM-Systeme (Security Information and Event Management) einbinden. Auf diese Weise werden Echtzeitüberwachung, Ereigniskorrelation, Analysen und Sicherheitswarnungen ermöglicht.

Logerfassung

Flusslogs werden in bestimmten Intervallen für jede VM-Verbindung erfasst. Alle für ein bestimmtes Intervall und für eine bestimmte Verbindung erfassten Pakete werden für den jeweiligen Zeitraum (Aggregationsintervall) in einem einzigen Flusslogeintrag aggregiert. Diese Daten werden anschließend an Logging gesendet.

Logs werden standardmäßig 30 Tage lang in Logging gespeichert. Wenn Sie Logs länger aufbewahren möchten, können Sie entweder eine benutzerdefinierte Aufbewahrungsdauer festlegen oder sie in eine unterstützte Aufbewahrungsdauer exportieren.

Log-Sampling und -verarbeitung

Google Cloud nimmt Stichproben von ausgehenden und eingehenden Paketen einer VM, um Flusslogs zu generieren. Nicht jedes Paket wird in einem eigenen Logeintrag erfasst. Etwa eines von 30 Paketen wird erfasst, aber diese Abtastrate kann je nach Auslastung der VM geringer sein. Sie können diese Rate nicht anpassen.

Nachdem die Flusslogs erstellt wurden, werden sie von Google Cloud gemäß dem folgenden Verfahren verarbeitet:

1. Filter: Sie können festlegen, dass nur Logs generiert werden, die bestimmten Kriterien entsprechen. Sie können beispielsweise so filtern, dass nur Logs für eine bestimmte VM oder nur Logs mit einem bestimmten Metadatenwert generiert werden und der Rest verworfen wird. Weitere Informationen finden Sie unter Logfilterung.
2. Aggregation: Die Informationen für die Stichprobenpakete werden über ein konfigurierbares Aggregationsintervall zusammengefasst. Daraus ergibt sich ein Flusslogeintrag.
3. Flusslog-Probenahme: Dies ist ein zweiter Probenahmeprozess. Von den Flusslogeinträgen werden weitere Stichproben gemäß einem konfigurierbaren Parameter für die Abtastrate erstellt.
4. Metadaten: Wenn diese Option deaktiviert ist, werden alle Metadatenannotationen verworfen. Wenn Sie Metadaten behalten möchten, können Sie angeben, dass alle Felder oder eine bestimmte Gruppe von Feldern beibehalten werden. Weitere Informationen finden Sie unter Metadatenannotationen.
5. In Logging schreiben: Die endgültigen Logeinträge werden in Cloud Logging geschrieben.

Hinweis: Die Art, wie Stichproben durch VPC-Flusslogs erfasst werden, kann nicht geändert werden. Sie können jedoch die sekundäre Probenahme der Flusslogs mit dem Parameter für die Logprobenahme steuern. Selbst bei einer Probenahme von Flusslogs von 1.0 oder 100 % werden aufgrund der anfänglichen Abtastrate durchschnittlich etwa 3 % der Pakete auf VM-Ebene verarbeitet. Zur Analyse aller Pakete können Sie die Paketspiegelung und Collector-Instanzen verwenden, auf denen Drittanbieter-Software ausgeführt wird.

Da VPC-Flusslogs nicht jedes Paket erfassen, werden verpasste Pakete durch Interpolation aus den erfassten Paketen kompensiert. Dies geschieht bei Paketen, die aufgrund von anfänglichen und benutzerdefinierten Einstellungen für die Probenahme verpasst wurden.

Obwohl Google Cloud nicht jedes Paket erfasst, können die erfassten Logeinträge recht umfangreich sein. Sie können die Sichtbarkeit des Traffics und die Speicherkosten auf Ihre Bedürfnisse abstimmen, indem Sie die folgenden Aspekte der Logerfassung anpassen:

• Aggregationsintervall: Paketstichproben für ein Zeitintervall werden in einem einzigen Logeintrag zusammengefasst. Dieses Zeitintervall kann 5 Sekunden (Standardeinstellung), 30 Sekunden, 1 Minute, 5 Minuten, 10 Minuten oder 15 Minuten sein.
• Abtastrate: Vor dem Schreiben in Logging können die Logs abgetastet werden, um deren Anzahl zu reduzieren. Standardmäßig wird das Volumen der Logeinträge auf 0,50 (50 %) skaliert, was bedeutet, dass die Hälfte der Einträge beibehalten wird. Sie können einen Wert zwischen 1.0 (100 %, alle Logeinträge werden beibehalten) und 0.0 (0 %, keine Logeinträge werden beibehalten) festlegen.
• Metadatenannotationen: Standardmäßig werden Flusslogeinträge mit Metadaten versehen, beispielsweise mit den Namen der Quell- und Ziel-VMs oder der geografischen Region externer Quellen und Ziele. Metadatenannotationen können deaktiviert werden. Sie können auch nur bestimmte Annotationen angeben, um Speicherplatz zu sparen.
• Filter: Standardmäßig werden Logs für jeden Fluss im Subnetz generiert. Sie können Filter so einrichten, dass nur Logs generiert werden, die bestimmten Kriterien entsprechen.

Metadatenannotationen

Logdatensätze umfassen Basisfelder und Metadatenfelder. Unter Eintragsformat wird angezeigt, welche Felder vom Typ Metadaten sind und welche Typ Basis sind. Die Basisfelder sind immer enthalten. Sie können festlegen, welche Metadatenfelder beibehalten werden.

• Wenn Sie alle Metadaten auswählen, sind alle Metadatenfelder im Eintragsformat für VPC-Flusslogs enthalten. Wenn dem Eintragsformat neue Metadatenfelder hinzugefügt werden, enthalten die Flusslogs automatisch die neuen Felder.

• Wenn Sie keine Metadaten auswählen, werden alle Metadatenfelder weggelassen.

• Wenn Sie benutzerdefinierte Metadaten auswählen, können Sie die Metadatenfelder, die Sie vom übergeordneten Feld einschließen möchten, angeben, z. B. src_vpc, oder ihren vollständigen Namen angeben, z. B. src_vpc.project_id.

  Wenn dem Eintragsformat neue Metadatenfelder hinzugefügt werden, enthalten die Flusslogs diese Felder nur, wenn es sich um ein neues Feld in einem übergeordneten Feld handelt, das Sie angegeben haben.

  • Wenn Sie benutzerdefinierte Metadaten mithilfe von übergeordneten Feldern festlegen, werden den neuen Audit-Logs automatisch die neuen Felder hinzugefügt, wenn dem Eintragsformat in dem übergeordneten Feld neue Metadatenfelder hinzugefügt werden.

  • Wenn Sie benutzerdefinierte Metadaten mit dem vollständigen Namen des Felds angeben, enthalten die Flusslogs keine neuen Felder, wenn dem übergeordneten Feld neue Metadatenfelder hinzugefügt werden.

Informationen zum Anpassen von Metadatenfeldern finden Sie in der gcloud CLI oder der API-Anleitung VPC-Fluss-Logging beim Erstellen eines Subnetzes aktivieren.

GKE-Annotationen

Flüsse, die einen Endpunkt in einem GKE-Cluster haben, können mit GKE-Annotationen annotiert werden. Diese können Details zum Cluster, Pod und Dienst des Endpunkts enthalten.

GKE-Dienstannotationen

Traffic, der an einen ClusterIP, NodePort oder LoadBalancer gesendet wird, kann Dienstannotationen empfangen. Wenn er an einen NodePort oder LoadBalancer gesendet wird, empfängt der Fluss die Dienstannotation in beiden Hops der Verbindung.

Traffic, der direkt an den Dienstport eines Pods gesendet wird, wird mit einer Dienstannotation am Zielendpunkt annotiert.

Traffic, der an den Dienstport eines Pods gesendet wird, der mehr als einen Dienst am selben Dienstport unterstützt, wird mit mehreren Diensten am Zielendpunkt annotiert. Dies ist auf zwei Dienste beschränkt. Wenn mehr Dienste vorhanden sind, wird der Endpunkt mit einer speziellen MANY_SERVICES-Markierung versehen.

Pod-Annotationen zu Internettraffic

Der Traffic zwischen einem Pod und dem Internet erhält standardmäßig keine Pod-Annotationen. Bei Paketen im Internet übersetzt der Masquerade-Agent die Pod-IP-Adresse in die Knoten-IP-Adresse, bevor VPC-Flusslogs das Paket sehen. Daher werden in den VPC-Flusslogs keine Informationen über den Pod erkannt und es können keine Pod-Annotationen hinzugefügt werden.

Aufgrund der Masquerade sind Pod-Annotationen nur sichtbar, wenn sich die Ziele entweder innerhalb der Standardziele ohne Masquerade oder in einer benutzerdefinierten nonMasqueradeCIDRs-Liste befinden. Wenn Sie Internetziele in eine benutzerdefinierte nonMasqueradeCIDRs-Liste aufnehmen, müssen Sie eine Möglichkeit bereitstellen, damit die internen Pod-IP-Adressen übersetzt werden können, bevor sie im Internet bereitgestellt werden. Für private und nicht private Cluster können Sie Cloud NAT verwenden. Weitere Informationen finden Sie unter GKE-Interaktion.

Eintragsformat

Logdatensätze umfassen Basisfelder – die wichtigsten Felder jedes Logdatensatzes – sowie Metadatenfelder, die zusätzliche Informationen enthalten. Metadatenfelder können weggelassen werden, um Speicherkosten zu sparen.

Einige Logfelder haben ein Mehrfeldformat mit mehr als einem Datenelement in einem bestimmten Feld. Das Feld connection hat beispielsweise das Format IpConnection. Dieses Format enthält die Quell- und Ziel-IP-Adresse sowie Protokoll und Port in einem einzigen Feld. Diese Felder mit Mehrfeldformat werden unter der Eintragsformattabelle beschrieben.

Hinweis: Die Werte für Metadatenfelder beruhen nicht auf dem Datenebenenpfad. Es handelt sich um Näherungswerte, die möglicherweise fehlen oder falsch sind. Im Gegensatz dazu werden die Werte für Basisfelder direkt aus Paketheadern übernommen.

Feld	Feldformat	Feldtyp: Basis- oder optionale Metadaten
Verbindung	IpConnection 5-Tupel, das diese Verbindung beschreibt.	Basis
reporter	string Die Seite, die den Datenfluss gemeldet hat. Kann entweder SRC oder DEST sein.	Basis
rtt_msec	int64 Latenz, gemessen während des Zeitintervalls, nur für TCP-Flüsse. Die gemessene Latenz ist die Zeit, die zwischen dem Senden einer SEQ und dem Empfang einer entsprechenden ACK vergangen ist. Das Latenzergebnis ist die Summe der Netzwerk-RTT und der durch die Anwendung verbrauchten Zeit.	Basis
bytes_sent	int64 Anzahl der Byte, die von der Quelle an das Ziel gesendet werden.	Basis
packets_sent	int64 Anzahl der Pakete, die von der Quelle an das Ziel gesendet werden.	Basis
start_time	string Zeitstempel (RFC 3339-Datumsstring-Format) des ersten beobachteten Pakets während des aggregierten Zeitintervalls.	Basis
end_time	string Zeitstempel (RFC 3339-Datumsstring-Format) des letzten beobachteten Pakets während des aggregierten Zeitintervalls.	Basis
src_gke_details	GkeDetails GKE-Metadaten für Quellendpunkte. Nur verfügbar, wenn der Endpunkt GKE ist.	Metadaten
dest_gke_details	GkeDetails GKE-Metadaten für Zielendpunkte. Nur verfügbar, wenn der Endpunkt GKE ist.	Metadaten
src_instance	InstanceDetails Wenn die Quelle der Verbindung eine VM in der gleichen VPC war, wird dieses Feld mit VPC-Instanzdetails gefüllt. In einer freigegebenen VPC-Konfiguration entspricht project_id dem Projekt, zu dem die Instanz gehört (normalerweise das Dienstprojekt).	Metadaten
dest_instance	InstanceDetails Wenn das Ziel der Verbindung eine VM in der gleichen VPC war, wird dieses Feld mit VM-Instanzdetails gefüllt. In einer freigegebenen VPC-Konfiguration entspricht project_id dem Projekt, zu dem die Instanz gehört (normalerweise das Dienstprojekt).	Metadaten
src_location	GeographicDetails Wenn die Quelle der Verbindung außerhalb der VPC lag, wird dieses Feld mit verfügbaren Standortmetadaten gefüllt.	Metadaten
dest_location	GeographicDetails Wenn das Ziel der Verbindung außerhalb der Google-VPC lag, wird dieses Feld mit verfügbaren Standortmetadaten gefüllt.	Metadaten
src_vpc	VpcDetails Wenn die Quelle der Verbindung eine VM in der gleichen VPC war, wird dieses Feld mit VPC-Netzwerkdetails gefüllt. In einer freigegebenen VPC-Konfiguration entspricht project_id der ID des Hostprojekts.	Metadaten
dest_vpc	VpcDetails Wenn das Ziel der Verbindung eine VM in der gleichen VPC war, wird dieses Feld mit VPC-Netzwerkdetails gefüllt. In einer freigegebenen VPC-Konfiguration entspricht project_id der ID des Hostprojekts.	Metadaten

Feldformat von IpConnection

Feld	Typ	Beschreibung
Protokoll	int32	Die IANA-Protokollnummer
src_ip	String	Quell-IP-Adresse
dest_ip	String	Ziel-IP-Adresse
src_port	int32	Quellport
dest_port	int32	Zielport

Feldformat von GkeDetails

Feld	Typ	Beschreibung
Cluster	Clusterdetails	GKE-Clustermetadaten.
Pod	PodDetails	GKE-Pod-Metadaten, die ausgefüllt werden, wenn die Quelle oder das Ziel des Traffics ein Pod ist.
Dienst	ServiceDetails	GKE-Dienstmetadaten, die nur in Dienstendpunkten ausgefüllt werden. Der Eintrag enthält bis zu zwei Dienste. Wenn mehr als zwei relevante Dienste vorhanden sind, enthält dieses Feld einen einzelnen Dienst mit einer speziellen MANY_SERVICES-Markierung.

Feldformat von ClusterDetails

Feld	Typ	Beschreibung
cluster_location	String	Speicherort des Clusters. Dies kann eine Zone oder Region sein, je nachdem, ob der Cluster zonal oder regional ist.
cluster_name	String	Name des GKE-Clusters.

Feldformat von PodDetails

Feld	Typ	Beschreibung
pod_name	String	Name des Pods.
pod_namespace	String	Namespace des Pods.

Feldformat von ServiceDetails

Feld	Typ	Beschreibung
service_name	String	Name des Dienstes, Wenn mehr als zwei relevante Dienste vorhanden sind, wird das Feld auf eine spezielle MANY_SERVICES-Markierung gesetzt.
service_namespace	String	Namespace des Dienstes.

Beispiel:

Wenn zwei Dienste vorhanden sind, sieht das Dienstfeld so aus:

service: [
 0: {
  service_name: "my-lb-service"
  service_namespace: "default"
 }
 1: {
  service_name: "my-lb-service2"
  service_namespace: "default"
 }
]

Wenn mehr als zwei Dienste vorhanden sind, sieht das Dienstfeld so aus:

service: [
 0: {
  service_name: "MANY_SERVICES"
 }
]

Feldformat von InstanceDetails

Feld	Typ	Beschreibung
project_id	string	ID des Projekts, das die VM enthält
Region	String	Region der VM
vm_name	string	Instanzname der VM
Zone	String	Zone der VM

Feldformat von GeographicDetails

Feld	Typ	Beschreibung
asn	int32	Die Nummer des autonomen Systems (Autonomous System Number, ASN) des externen Netzwerks, zu dem der Endpunkt gehört.
Ort	string	Stadt für externe Endpunkte
continent	string	Kontinent für externe Endpunkte
country	String	Land für externe Endpunkte, dargestellt als Ländercodes gemäß ISO 3166-1 Alpha-3.
Region	string	Region für externe Endpunkte

Feldformat von VpcDetails

Feld	Typ	Beschreibung
project_id	String	ID des Projekts, das die VPC enthält
subnetwork_name	String	Subnetzwerk, auf dem die VM ausgeführt wird
vpc_name	String	VPC, in der die VM ausgeführt wird

Logfilterung

Wenn Sie VPC-Flusslogs aktivieren, können Sie einen Filter anhand von Basis- und Metadatenfeldern festlegen, die nur Logs beibehalten, die dem Filter entsprechen. Alle anderen Logs werden verworfen, bevor sie in Logging geschrieben werden. Dadurch sparen Sie Geld und können die benötigte Zeit für die Suche nach den gewünschten Informationen reduzieren.

Sie können nach einer beliebigen Teilmenge von Feldern filtern, die im Eintragsformat aufgeführt sind, mit Ausnahme der folgenden Felder:

• rtt_msec
• bytes_sent
• packets_sent
• start_time
• end_time

Bei der VPC-Flusslog-Filterung wird CEL verwendet, eine eingebettete Ausdruckssprache für attributbasierte logische Ausdrücke. Filterausdrücke für VPC-Flusslogs sind auf 2.048 Zeichen begrenzt. Weitere Informationen finden Sie unter Unterstützte CEL-Operatoren.

Weitere Informationen zu CEL finden Sie in der CEL-Einführung und in der Sprachdefinition. Das Generierungsfilter-Feature unterstützt eine begrenzte Teilmenge der CEL-Syntax.

Informationen zum Erstellen eines Subnetzes mit Logfilterung finden Sie in der gcloud CLI oder der API-Anleitung VPC-Flusslogs beim Erstellen eines Subnetzes aktivieren.

Informationen zum Konfigurieren der Logfilterung finden Sie in der gcloud CLI oder der API-Anleitung Parameter für VPC-Flusslogs aktualisieren.

Beispiel 1: Beschränken Sie die Logerfassung auf eine bestimmte VM mit dem Namen my-vm. In diesem Fall werden nur Logs aufgezeichnet, bei denen das Feld src_instance, das von der Quelle des Traffics gemeldet wird, my-vm ist, oder das Feld dst_instance, das vom Ziel des Traffics gemeldet wird, my-vm ist.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"

Beispiel 2: Beschränken Sie die Logerfassung auf Pakete, deren Quell-IP-Adressen im Subnetz 10.0.0.0/8 enthalten sind.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr="inIpRange(connection.src_ip, '10.0.0.0/8')"

Beispiel 3: Beschränken Sie die Logerfassung auf Traffic außerhalb einer VPC.

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr '!(has(src_vpc.vpc_name) && has(dest_vpc.vpc_name))'

Unterstützte logische CEL-Operatoren

Ausdruck	unterstützte Typen	Beschreibung
true, false	Boolesch	Boolesche Konstanten
x == y x != y	Boolean, Int, String	Vergleichsoperator Beispiel: connection.protocol == 6
x && y x || y	Boolesch	Boolesche logische Operatoren Beispiel: connection.protocol == 6 && src_instance.vm_name == "vm_1"
!x	Boolesch	Negation
1, 2.0, 0, ...	Int	Konstante numerische Literale
x + y	String	String-Verkettung
"foo", 'foo', ...	String	Konstantes Stringliteral
x.lower()	String	Gibt den Kleinbuchstabenwert des Strings zurück
x.upper()	String	Gibt den Großbuchstabenwert des Strings zurück
x.contains(y)	String	Gibt "true" zurück, wenn der String den angegebenen Teilstring enthält
x.startsWith(y)	String	Gibt "true" zurück, wenn der String mit dem angegebenen Teilstring beginnt.
x.endsWith(y)	String	Gibt "true" zurück, wenn der String mit dem angegebenen Teilstring endet.
inIpRange(X, Y)	String	Gibt "true" zurück, wenn X eine IP-Adresse und Y ein IP-Bereich ist, der X enthält. Example: inIpRange("1.2.3.1", "1.2.3.0/24")
x.containsFieldValue(y)	x: list y: map(string, string)	Gibt "true" zurück, wenn die Liste ein Objekt mit Feldern enthält, die mit den angegebenen Schlüssel/Wert-Paaren übereinstimmen. Beispiel: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})
has(x)	String	Gibt „true“ zurück, wenn das Feld vorhanden ist.

Zugriffsmuster – Beispiele

In diesem Abschnitt wird das Funktionsprinzip von VPC-Flusslogs für verschiedene Anwendungsfälle erläutert.

VM-zu-VM-Datenflüsse im derselben VPC-Netzwerk

VM-Datenflüsse innerhalb eines VPC-Netzwerks. Zum Vergrößern klicken.

Bei VM-zu-VM-Datenflüssen im selben VPC-Netzwerk werden Fluss-Logs sowohl von der anfragenden als auch von der antwortenden VM gemeldet, wenn sich beide VMs in Subnetzen befinden, für die VPC-Fluss-Logs aktiviert sind. In diesem Beispiel sendet die VM 10.10.0.2 eine Anfrage mit 1.224 Byte an die VM 10.50.0.2, die sich ebenfalls in einem Subnetz befindet, für das Logging aktiviert ist. 10.50.0.2 antwortet auf die Anfrage mit einer Antwort, die 5.342 Byte enthält. Sowohl die Anfrage als auch die Antwort werden von den anfragenden und den antwortenden VMs aufgezeichnet.

Wie von anfragender VM gemeldet (10.10.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Request	10.10.0.2	10.50.0.2	1.224	src_instance.* dest_instance.* src_vpc.* dest_vpc.*
antworten	10.50.0.2	10.10.0.2	5.342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

Wie von antwortender VM gemeldet (10.50.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	Byte	Annotationen
Request	10.10.0.2	10.50.0.2	1.224	src_instance.* dest_instance.* src_vpc.* dest_vpc.*
antworten	10.50.0.2	10.10.0.2	5.342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

VM-zu-Extern-IP-Adressflüsse

VM-zu-Extern-IP-Adressflüsse (zum Vergrößern klicken)

Für Datenflüsse, die das Internet zwischen einer VM in einem VPC-Netzwerk und einem Endpunkt mit einer externen IP-Adresse durchlaufen, werden nur Flusslogs von der VM gemeldet, die sich im VPC-Netzwerk befindet:

• Bei ausgehenden Datenflüssen werden die Logs von der VPC-Netzwerk-VM gemeldet, die die Quelle des Traffics ist.
• Bei eingehenden Datenflüssen werden die Logs von der VPC-Netzwerk-VM gemeldet, die das Ziel des Traffics ist.

In diesem Beispiel tauscht die VM 10.10.0.2 Pakete über das Internet mit einem Endpunkt aus, der die externe IP-Adresse 203.0.113.5 hat. Der ausgehende Traffic von 1.224 Byte, der von 10.10.0.2 an 203.0.113.5 gesendet wurde, wird von der Quell-VM 10.10.0.2 gemeldet. Der eingehende Traffic von 5.342 Byte, der von 203.0.113.5 an 10.10.0.2 gesendet wurde, wird vom Ziel des Traffics, der VM 10.10.0.2, gemeldet.

Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Request	10.10.0.2	203.0.113.5	1.224	src_instance.* src_vpc.* dest_location.*
antworten	203.0.113.5	10.10.0.2	5.342	dest_instance.* dest_vpc.* src_location.*

VM-zu-Lokal-Datenflüsse

VM-zu-Lokal-Datenflüsse (zum Vergrößern klicken)

Für Datenflüsse zwischen einer VM in einem VPC-Netzwerk und einem lokalen Endpunkt mit einer internen IP-Adresse werden Flusslogs nur von der VM gemeldet, die sich im VPC-Netzwerk befindet:

• Bei ausgehenden Datenflüssen werden die Logs von der VPC-Netzwerk-VM gemeldet, die die Quelle des Traffics ist.
• Bei eingehenden Datenflüssen werden die Logs von der VPC-Netzwerk-VM gemeldet, die das Ziel des Traffics ist.

In diesem Beispiel sind die VM 10.10.0.2 und der lokale Endpunkt 10.30.0.2 über ein VPN-Gateway oder Cloud Interconnect verbunden. Der ausgehende Traffic von 1.224 Byte, der von 10.10.0.2 an 10.30.0.2 gesendet wurde, wird von der Quell-VM 10.10.0.2 gemeldet. Der eingehende Traffic von 5.342 Byte, der von 10.30.0.2 an 10.10.0.2 gesendet wurde, wird vom Ziel des Traffics, der VM 10.10.0.2, gemeldet.

Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Request	10.10.0.2	10.30.0.2	1.224	src_instance.* src_vpc.*
antworten	10.30.0.2	10.10.0.2	5.342	dest_instance.* dest_vpc.*

VM-zu-VM-Datenflüsse für freigegebene VPC

Freigegebene VPC-Datenflüsse (zum Vergrößern anklicken).

Bei VM-zu-VM-Datenflüssen für freigegebene VPC können Sie VPC-Flusslogs für das Subnet im Hostprojekt aktivieren. Beispiel: Das Subnetz 10.10.0.0/20 gehört zu einem freigegebenen VPC-Netzwerk, das in einem Hostprojekt definiert ist. Sie können Flusslogs von VMs sehen, die zu diesem Subnetz gehören, einschließlich solcher, die von Dienstprojekten erstellt wurden. In diesem Beispiel heißen die Dienstprojekte "Webserver", "Empfehlung", "Datenbank".

Bei VM-zu-VM-Datenflüssen werden, wenn sich beide VMs im selben Projekt oder – im Fall eines freigegebenen Netzwerks – im selben Hostprojekt befinden, Anmerkungen für die Projekt-ID und dergleichen für den anderen Endpunkt in der Verbindung bereitgestellt. Wenn sich die andere VM in einem anderen Projekt befindet, werden keine Annotationen für die andere VM bereitgestellt.

Die folgende Tabelle zeigt einen Datenfluss, der entweder in 10.10.0.10 oder 10.10.0.20 gemeldet wird.

• src_vpc.project_id und dest_vpc.project_id stehen für das Hostprojekt, da das VPC-Subnetz zum Hostprojekt gehört.
• src_instance.project_id und dest_instance.project_id sind für die Dienstprojekte bestimmt, da die Instanzen zu den Dienstprojekten gehören.

connection .src_ip	src_instance .project_id	src_vpc .project_id	connection .dest_ip	dest_instance .project_id	dest_vpc .project_id
10.10.0.10	webserver	host_project	10.10.0.20	Empfehlung	host_project

Dienstprojekte sind keine Inhaber des freigegebenen VPC-Netzwerks und haben keinen Zugriff auf die Flusslogs des freigegebenen VPC-Netzwerks.

VM-zu-VM-Datenflüsse für VPC-Netzwerk-Peering

VPC-Netzwerk-Peering-Datenflüsse (zum Vergrößern klicken).

Wenn sich die beiden VMs nicht im selben Google Cloud-Projekt befinden, werden VM-zu-VM-Datenflüsse für Peering-VPC-Netzwerke auf die gleiche Weise wie für externe Endpunkte gemeldet. Projekt- und andere Annotationsinformationen für die andere VM werden nicht bereitgestellt. Wenn sich beide VMs in demselben Projekt befinden, auch wenn sie sich in verschiedenen Netzwerken befinden, werden Projekt- und andere Annotationsinformationen auch für die andere VM angegeben.

In diesem Beispiel sind die Subnetze der VM 10.10.0.2 im Projekt "analytics-prod" und der VM 10.50.0.2 im Projekt "webserver-test" über VPC-Netzwerk-Peering verbunden. Wenn im Projekt "analytics-prod" VPC-Flusslogs aktiviert sind, wird der von 10.10.0.2 an 10.50.0.2 gesendete Traffic (1.224 Byte) von der VM 10.10.0.2 gemeldet, die die Quelle des Datenflusses ist. Der von 10.50.0.2 an 10.10.0.2 gesendete Traffic (5.342 Byte) wird auch von der VM 10.10.0.2 gemeldet, die das Ziel des Datenflusses ist.

In diesem Beispiel sind VPC-Flusslogs im Projekt "webserver-test" nicht aktiviert, also werden von der VM 10.50.0.2 keine Logs aufgezeichnet.

reporter	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
source	10.10.0.2	10.50.0.2	1.224	src_instance.* src_vpc.*
Ziel	10.50.0.2	10.10.0.2	5.342	dest_instance.* dest_vpc.*

VM-zu-VM-Datenflüsse für interne Passthrough Network Load Balancer

Datenflüsse für den internen Passthrough Network Load Balancer (zum Vergrößern klicken)

Wenn Sie dem Backend-Dienst für einen internen Passthrough Network Load Balancer eine VM hinzufügen, fügt die Linux- oder Windows-Gastumgebung die IP-Adresse des Load-Balancings zur lokalen Routingtabelle der VM hinzu. Dadurch kann die VM Anfragepakete mit Zielen akzeptieren, die auf die IP-Adresse des Load-Balancers festgelegt sind. Wenn die VM antwortet, sendet sie ihre Antwort direkt. Als Quell-IP-Adresse für die Antwortpakete wird jedoch die IP-Adresse des Load Balancers festgelegt und nicht die VM, deren Last ausgeglichen wird.

Über einen internen Passthrough Network Load Balancer gesendete VM-zu-VM-Datenflüsse werden sowohl von der Quelle als auch vom Ziel gemeldet. Als Beispiel für ein HTTP-Anfrage/Antwort-Paar werden in der folgenden Tabelle die Felder der beobachteten Einträge im Flusslog beschrieben. Sehen Sie sich dazu auch die folgende Netzwerkkonfiguration an:

• Browserinstanz bei 192.168.1.2
• Interner Passthrough Network Load Balancer unter 10.240.0.200
• Webserverinstanz bei 10.240.0.3

Traffic-Richtung	reporter	connection.src_ip	connection.dest_ip	connection.src_instanz	connection.dest_instance
Anfrage	SRC	192.168.1.2	10.240.0.200	Browserinstanz
Anfrage	DEST	192.168.1.2	10.240.0.200	Browserinstanz	Webserverinstanz
Antwort	SRC	10.240.0.3	192.168.1.2	Webserverinstanz	Browserinstanz
Antwort	DEST	10.240.0.200	192.168.1.2		Browserinstanz

Die anfragende VM weiß nicht, welche VM auf die Anfrage antworten wird. Da die andere VM eine Antwort mit der IP des internen Load-Balancers als Quelladresse sendet, weiß die anfragende VM nicht, welche VM reagiert hat. Deshalb kann die anfragende VM dest_instance-Daten nicht in ihren Bericht aufnehmen, sondern nur src_instance-Daten. Da die antwortende VM die IP-Adresse der anderen VM kennt, kann sie die Daten von src_instance und dest_instance bereitstellen.

Pod-zu-ClusterIP-Datenfluss

IP-Datenfluss von Pod zu Cluster (zum Vergrößern klicken)

In diesem Beispiel wird der Traffic vom Client-Pod (10.4.0.2) an cluster-service (10.0.32.2:80) gesendet. Das Ziel wird in die ausgewählte Server-Pod-IP-Adresse (10.4.0.3) des Zielports (8080) aufgelöst.

An Knotenrändern wird der Fluss zweimal mit der übersetzten IP-Adresse und dem Port erfasst. Für beide Stichprobenpunkte bestimmen wir, dass der Ziel-Pod den Dienst cluster-service auf Port 8080 sichert, und annotieren den Eintrag mit den Dienst- und Pod-Details. Wenn der Traffic an einen Pod auf demselben Knoten weitergeleitet wird, verlässt der Traffic den Knoten nicht und wird nicht erfasst.

In diesem Beispiel werden die folgenden Einträge gefunden.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotationen
SRC	10.4.0.2	10.4.0.3	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* src_gke_details.pod.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*
DEST	10.4.0.2	10.4.0.3	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* src_gke_details.pod.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Externe GKE-LoadBalancer-Datenflüsse

Externe Load-Balancer-Datenflüsse (zum Vergrößern klicken).

Traffic von einer externen IP-Adresse an einen GKE-Dienst (35.35.35.35) wird zur Weiterleitung an einen Knoten im Cluster weitergeleitet, in diesem Beispiel 10.0.12.2. Standardmäßig verteilen Passthrough Network Load Balancer den Traffic auf alle Knoten im Cluster, auch auf diejenigen, die keinen relevanten Pod ausführen. Der Traffic benötigt möglicherweise zusätzliche Hops, um zum entsprechenden Pod zu gelangen. Weitere Informationen finden Sie unter Netzwerke außerhalb des Clusters.

Der Traffic wird dann vom Knoten (10.0.12.2) an den ausgewählten Server-Pod (10.4.0.2) weitergeleitet. Beide Hops werden protokolliert, da alle Knotenkanten erfasst werden. Wenn der Traffic an einen Pod auf demselben Knoten wie 10.4.0.3 weitergeleitet wird, wird der zweite Hop nicht protokolliert, da er den Knoten nicht verlässt. Der zweite Hop wird von den Stichprobenpunkten der beiden Knoten protokolliert. Der zweite Hop wird von den Stichprobenpunkten beider Knoten protokolliert. Für den ersten Hop haben wir den Dienst anhand der IP-Adresse und des Dienstports des Load-Balancers (80) ermittelt. Beim zweiten Hop haben wir festgestellt, dass der Ziel-Pod den Dienst am Zielport (8080) gesichert.

In diesem Beispiel werden die folgenden Einträge gefunden.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotationen
DEST	203.0.113.1	35.35.35.35	1.224	src_location.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*
DEST	10.0.12.2	10.4.0.2	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Eingehende GKE-Datenflüsse

Eingehende Datenflüsse (zum Vergrößern klicken).

Eine Verbindung von einer öffentlichen IP-Adresse zu einem Ziel für eingehenden Traffic wird beim Load-Balancer-Dienst beendet. Die Verbindung wird einem NodePort-Dienst gemäß der URL zugeordnet. Zur Verarbeitung der Anfrage stellt der Load-Balancer (130.211.0.1) eine Verbindung zu einem der Clusterknoten (10.0.12.2) her, um das Routing über den NodePort des Dienstes durchzuführen. Standardmäßig erstellt der GKE-Ingress-Controller beim Erstellen eines Ingress-Objekts einen HTTP(S)-Load-Balancer, der den Traffic auf alle Knoten im Cluster verteilt, auch auf diejenigen, die keinen relevanten Pod ausführen. Der Traffic benötigt möglicherweise zusätzliche Hops, um zum entsprechenden Pod zu gelangen. Weitere Informationen finden Sie unter Netzwerke außerhalb des Clusters. Der Traffic wird dann vom Knoten (10.0.12.2) an den ausgewählten Server-Pod (10.4.0.2) weitergeleitet.

Beide Hops werden protokolliert, da alle Knotenkanten erfasst werden. Für den ersten Hop haben wir den Dienst mit dem NodePort des Dienstes (60000) bestimmt. Für den zweiten Hop bestimmen wir, dass der Ziel-Pod den Dienst am Zielport (8080) sichert. Der zweite Hop wird durch die Stichprobenpunkte beider Knoten protokolliert. In einem Fall, in dem der Traffic jedoch an einen Pod auf demselben Knoten weitergeleitet wird (10.4.0.3), wird der zweite Hop nicht protokolliert, da der Traffic den Knoten nicht verlassen hat.

In diesem Beispiel werden die folgenden Einträge gefunden.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotationen
DEST	130.211.0.1	10.0.12.2	1.224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*
DEST	10.0.12.2	10.4.0.2	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Eingehende GKE-Datenflüsse mit containernativem Load-Balancing

Eingehende Datenflüsse mit containernativem Load-Balancing (zum Vergrößern klicken).

Anfragen von einer öffentlichen IP-Adresse an ein Ingress, das containernatives Load-Balancing verwendet, werden am Load-Balancer beendet. Bei diesem Ingress-Typ sind Pods Kernobjekte für das Load-Balancing. Eine Anfrage wird dann direkt vom Load-Balancer (130.211.0.1) an einen ausgewählten Pod (10.4.0.2) gesendet. Wir stellen fest, dass der Ziel-Pod den Dienst am Zielport (8080) sichert.

In diesem Beispiel wird der folgende Eintrag gefunden.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotationen
DEST	130.211.0.1	10.4.0.2	1.224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Pod zu externen Datenflüssen

Pod zu externem Datenfluss (zum Vergrößern klicken).

Der Traffic von einem Pod (10.4.0.3) zu einer externen IP-Adresse (203.0.113.1) wird durch IP-Masquerade geändert, sodass die Pakete von der Knoten-IP (10.0.12.2) statt von der Pod-IP gesendet werden. Standardmäßig ist der GKE-Cluster so konfiguriert, dass der Traffic zu externen Zielen maskiert wird. Weitere Informationen finden Sie unter Agent für IP-Masquerade.

Wenn Sie Pod-Annotationen für diesen Traffic ansehen möchten, können Sie den Masquerade-Agent so konfigurieren, dass er Pod-IP-Adressen nicht maskiert. In diesem Fall können Sie Cloud NAT konfigurieren, der die Pod-IP-Adressen verarbeitet, um Traffic zum Internet zuzulassen. Weitere Informationen zu Cloud NAT mit GKE finden Sie unter GKE-Interaktion.

In diesem Beispiel wird der folgende Eintrag gefunden.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotationen
SRC	10.0.12.2	203.0.113.1	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.*

Preise

Es gelten die Standardpreise für Logging, BigQuery oder Pub/Sub. Die Preisgestaltung für VPC-Flusslogs wird unter Netzwerktelemetrie-Preise beschrieben.

FAQ

• Unterstützen VPC-Flusslogs sowohl zulässigen als auch abgelehnten Traffic, der auf Firewallregeln basiert?

  • VPC-Flusslogs umfassen Traffic aus der Sicht einer VM. Der gesamte ausgehende Traffic von einer VM wird in Logs erfasst, auch wenn er durch eine ablehnende Firewallregel blockiert wird. Eingehender Traffic wird in Logs erfasst, wenn dies durch eine Firewall-Zulassungsregel für eingehenden Traffic erlaubt ist. Der durch eine Firewall-Ablehnungsregel für eingehenden Traffic blockierte eingehende Traffic wird nicht in Logs erfasst.

• Funktionieren VPC-Flusslogs bei VM-Instanzen mit mehreren Schnittstellen?

  • Ja. Sie können VPC-Flusslogs für alle Schnittstellen auf einer VM mit mehreren Schnittstellen aktivieren.

• Funktionieren VPC-Flusslogs bei Legacy-Netzwerken?

  • Nein. VPC-Flusslogs werden in Legacy-Netzwerken nicht unterstützt.

Nächste Schritte

• VPC-Flusslogs verwenden