VPC-Flusslogs verwenden

In VPC-Flusslogs wird eine Stichprobe von Netzwerkflüssen erfasst, die von VM-Instanzen gesendet und empfangen werden, darunter Instanzen, die als GKE-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 nach 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

  • Sie können VPC-Fluss-Logs jeweils pro Subnetz eines VPC-Netzwerks aktivieren oder deaktivieren. Wenn VPC-Flusslogs für ein Subnetz aktiviert sind, werden Daten von allen VM-Instanzen in diesem Subnetz erfasst.
  • VMs melden alle TCP- und UDP-Flüsse. Jeder Flussdatensatz enthält die im Abschnitt Datensatzformat beschriebenen Daten.
  • Jede VM erfasst die eingehenden und ausgehenden TCP- und UDP-Flüsse, ob der Datenfluss von oder zu einer anderen VM, einem Host in Ihrem lokalen Rechenzentrum, einem Google-Dienst oder einem Host im Internet erfolgt. Wenn zwei GCP-VMs kommunizieren und sich beide in Subnetzen befinden, für die VPC-Flusslogs aktiviert sind, melden beide VMs die Flüsse.
  • Sie können mithilfe von Filtern auswählen, welche Flusslogs vom Logging ausgeschlossen und welche in externe APIs exportiert werden.
  • VPC-Flowlogs sind nativ in den Netzwerkstack der VPC-Netzwerkinfrastruktur integriert. Beim Routing der protokollierten IP-Pakete an ihr Ziel gibt es keine zusätzliche Verzögerung und keine Leistungseinbußen.

Einsatzbereiche

Netzwerk-Monitoring

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

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

Netzwerknutzung verstehen und Kosten des Netzwerk-Traffics senken

Sie können die Netzwerknutzung mithilfe von VPC-Flusslogs analysieren. Sie können die folgenden Netzwerkflüsse analysieren:

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

Basierend auf der Analyse können Sie 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 prü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-Monitoring, 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 30 Tage lang in Logging gespeichert. Wenn Sie Logs länger aufbewahren möchten, müssen Sie sie in ein unterstütztes Ziel 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 Logdatensatz erfasst. Etwa eines von zehn 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. Aggregation: Die Informationen für die Stichprobenpakete werden über ein konfigurierbares Aggregationsintervall zusammengefasst. Daraus ergibt sich ein Flusslogeintrag.
  2. Flusslog-Sampling: Dies ist ein zweiter Sampling-Prozess. Von den Flusslogeinträgen werden weitere Stichproben gemäß einem konfigurierbaren Parameter für die Abtastrate erstellt.
  3. Metadaten: Falls aktiviert werden Metadatenanmerkungen hinzugefügt.
  4. In Logging schreiben: Die endgültigen Logeinträge werden in Cloud Logging geschrieben.

Obwohl Google Cloud nicht jedes Paket erfasst, können die erfassten Logdatensätze 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: Stichprobenpakete für ein Zeitintervall werden zu einem einzelnen Protokolleintrag zusammengefasst. Dieses Zeitintervall kann 5 Sekunden (Standard), 30 Sekunden, 1 Minute, 5 Minuten, 10 Minuten oder 15 Minuten betragen.
  • Abtastrate: Bevor sie in die Datenbank geschrieben werden, kann eine Stichprobennahme der Logs erfolgen, um ihre Anzahl zu verringern. 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.
  • Metadatenanmerkungen: 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. Diese Metadatenanmerkungen können deaktiviert werden, um Speicherplatz zu sparen.

Datensatzformat

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 im Mehrfeldformat werden unterhalb der Tabelle mit den Datensatzformaten beschrieben.

Feld Feldformat Feldtyp: Basis- oder optionale Metadaten
connection IpConnection
5-Tupel, das diese Verbindung beschreibt.
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
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
rtt_msec int64
Latenz, die (ausschließlich für TCP-Datenflüsse) während des Zeitintervalls gemessen wurde. Dies ist die Zeit, die zwischen dem Senden einer SEQ (Sequenz) und dem Empfang einer entsprechenden ACK (Bestätigung) verstrichen ist und die Netzwerk-RTT (Umlaufzeit) sowie die anwendungsbezogene Verzögerung einschließt.
Basis
reporter String
Die Seite, die den Datenfluss gemeldet hat. Kann entweder "SRC" (Quelle) oder "DEST" (Ziel) sein.
Basis
src_instance InstanceDetails
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 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 VPC-Netzwerkdetails gefüllt. In einer freigegebenen VPC-Konfiguration entspricht project_id dem Projekt, zu dem die Instanz gehört (normalerweise das Dienstprojekt).
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 die project_id der 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 die project_id der des Hostprojekts.
Metadaten
src_location GeographicDetails
Wenn die Quelle der Verbindung außerhalb der Google-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

Feldformat von IpConnection

Feld Typ Beschreibung
src_ip String IP-Adresse der Quelle
src_port int32 Quellport
dest_ip String IP-Adresse des Ziels
dest_port int32 Zielport
protocol int32 Die IANA-Protokollnummer

Feldformat von InstanceDetails

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

Feldformat von VpcDetails

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

Feldformat von GeographicDetails

Feld Typ Beschreibung
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
city String Stadt für externe Endpunkte
asn int32 Die Nummer des autonomen Systems (Autonomous System Number, ASN) des externen Netzwerks, zu dem der Endpunkt gehört.

Zugriffsmuster – Beispiele

In diesem Abschnitt wird das Funktionsprinzip von VPC-Flusslogs für die folgenden Anwendungsfälle erläutert:

VM-zu-VM-Datenflüsse in derselben VPC

Grafik: VM-Datenflüsse innerhalb einer VPC (zum Vergrößern anklicken)
VM-Datenflüsse innerhalb einer VPC (zum Vergrößern anklicken)

Bei VM-zu-VM-Datenflüssen in derselben VPC werden Flusslogs sowohl von der anfragenden als auch von der antwortenden VM gemeldet, wenn sich beide VMs in Subnetzen befinden, für die VPC-Flusslogs 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 VPC-Anmerkungen
Anfrage 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
Antwort 10.50.0.2 10.10.0.2 5342 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 VPC-Anmerkungen
Anfrage 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
Antwort 10.50.0.2 10.10.0.2 5342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*

VM-zu-Extern-Datenflüsse

Grafik: VM-zu-Extern-Datenflüsse (zum Vergrößern anklicken)
VM-zu-Extern-Datenflüsse (zum Vergrößern anklicken)

Für Datenflüsse zwischen einer VM und einer externen Entität werden Flusslogs nur von der VM gemeldet:

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

Das gilt für:

  • Traffic zwischen einem VPC-Netzwerk und einem lokalen Netzwerk über VPN oder Cloud Interconnect
  • Traffic zwischen VMs und Standorten im Internet

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 VPC-Anmerkungen
Anfrage 10.10.0.2 10.30.0.2 1224 src_instance.*
src_vpc.*
dest_location.*
Antwort 10.30.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*
src_location.*

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

Grafik: Freigegebene VPC-Datenflüsse (zum Vergrößern anklicken)
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 Subnetz 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", "recommendation" (Empfehlung), "database" (Datenbank).

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

Die folgende Tabelle zeigt einen Datenfluss, der entweder von 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 stehen für die Dienstprojekte, 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-Peering

Grafik: VPC-Peering-Datenflüsse (zum Vergrößern anklicken)
VPC-Peering-Datenflüsse (zum Vergrößern anklicken)

Wenn sich die beiden VMs nicht im selben GCP-Projekt befinden, werden VM-zu-VM-Datenflüsse für Peering-VPCs auf die gleiche Weise wie für externe Endpunkte gemeldet. Projekt- und sonstige Anmerkungsdaten für die andere VM werden nicht bereitgestellt. Wenn sich beide VMs in demselben Projekt befinden, selbst im Falle von verschiedenen Netzwerken, werden Projekt- und andere Anmerkungsdaten auch für die andere VM bereitgestellt.

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-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 keine Logs von der VM 10.50.0.2 aufgezeichnet.

reporter connection.src_ip connection.dest_ip bytes_sent VPC-Anmerkungen
Quelle 10.10.0.2 10.50.0.2 1224 src_instance.*
src_vpc.*
Ziel 10.50.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*

VM-zu-VM-Datenflüsse für das interne Load-Balancing

Grafik: Datenflüsse für das interne Load-Balancing (zum Vergrößern anklicken)
Datenflüsse für das interne Load-Balancing (zum Vergrößern anklicken)

Wenn Sie dem Back-End-Dienst für einen internen Load-Balancer eine VM hinzufügen, fügt die Linux- oder Windows-Gastumgebung die IP-Adresse des Load-Balancers 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 der VM, die dem Load-Balancing unterliegt.

VM-zu-VM-Datenflüsse, die über einen internen Load-Balancer gesendet werden, 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 Load-Balancer bei 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.3 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.

VPC-Flusslogs aktivieren

Wenn Sie VPC-Flusslogs aktivieren, aktivieren Sie diese für alle VMs in einem Subnetz. Sie können auch Parameter für das Log-Sampling angeben, wenn Sie das Logging aktivieren. Ausführliche Informationen zu den Parametern, die Sie festlegen können, finden Sie unter Log-Sampling und Logaggregation.

VPC-Flusslogs beim Erstellen eines Subnetzes aktivieren

Console

  1. Rufen Sie in der Google Cloud Console die Seite "VPC-Netzwerke" auf.
    Zur Seite "VPC-Netzwerke"
  2. Klicken Sie auf das Netzwerk, dem Sie ein Subnetz hinzufügen möchten.
  3. Klicken Sie auf Subnetz hinzufügen.
  4. Wählen Sie unter Flusslogs die Option An aus.
  5. Wenn Sie Log-Sampling und Logaggregation anpassen möchten, klicken Sie auf Logs konfigurieren und ändern Sie die folgenden Einstellungen wie gewünscht:
    • Aggregationsintervall
    • Ob Sie in den endgültigen Logeinträgen Metadaten einschließen möchten
    • Abtastrate (100% bedeutet, dass alle Einträge erhalten bleiben)
  6. Füllen Sie die anderen Felder je nach Bedarf aus.
  7. Klicken Sie auf Hinzufügen.

gcloud

    gcloud compute networks subnets create NAME \
        --enable-flow-logs \
        [--logging-aggregation-interval=INTERVAL \
        [--logging-flow-sampling=0.0...1.0] \
        [--logging-metadata=(include-all | exclude-all)] \
        [other flags as needed]
    

Dabei gilt:

  • --logging-aggregation-interval=<var>INTERVAL</var> legt das Aggregationsintervall für Flusslogs in diesem Subnetz fest. Das Intervall kann 5 Sekunden (Standard), 30 Sekunden, 1 Minute, 5 Minuten, 10 Minuten oder 15 Minuten betragen.
  • --logging-flow-sampling ist die Flussabtastrate. Das Fluss-Sampling kann auf einen Wert zwischen 0.0 (kein Sampling) und 1.0 (alle Logs) festgelegt werden. Der Standardwert ist 0.5.
  • --logging-metadata=(include-all | exclude-all) aktiviert bzw. deaktiviert die Aufzeichnung von Metadatenanmerkungen. Der Standardwert ist "An", also aktiviert.

API

Aktivieren Sie VPC-Fluss-Logs, wenn Sie ein neues Subnetz erstellen.

    POST https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/subnetworks
    {
      "logConfig": {
        "aggregationInterval": "AGGREGATION_INTERVAL",
        "flowSampling": SAMPLING_RATE,
        "enable": true
      },
      "ipCidrRange": "IP_RANGE",
      "network": "NETWORK_URL",
      "name": "SUBNET_NAME"
    }
    

Ersetzen Sie die Platzhalter durch gültige Werte:

  • PROJECT_ID ist die ID des Projekts, in dem das Subnetz erstellt wird.
  • REGION ist die Region, in der das Subnetz erstellt wird.
  • AGGREGATION_INTERVAL legt das Aggregationsintervall für Flusslogs im Subnetz fest. Das Intervall kann auf einen der folgenden Werte festgelegt werden: INTERVAL_5_SEC, INTERVAL_30_SEC, INTERVAL_1_MIN, INTERVAL_5_MIN, INTERVAL_10_MIN oder INTERVAL_15_MIN.
  • SAMPLING_RATE ist die Flussabtastrate. Das Fluss-Sampling kann auf einen Wert zwischen 0.0 (kein Sampling) und 1.0 (alle Logs) festgelegt werden. Der Standardwert ist .0.5.
  • IP_RANGE ist der primäre interne IP-Adressbereich des Subnetzes.
  • NETWORK_URL ist die VPC-Netzwerk-URL, unter der das Subnetz erstellt wird.
  • SUBNET_NAME ist ein Name für das Subnetz.

Weitere Informationen finden Sie in der Methode subnetworks.insert.

VPC-Flusslogs für ein vorhandenes Subnetz aktivieren

Console

  1. Rufen Sie in der Google Cloud Console die Seite "VPC-Netzwerke" auf.
    Zur Seite "VPC-Netzwerke"
  2. Klicken Sie auf das Subnetz, das Sie aktualisieren möchten.
  3. Klicken Sie auf Bearbeiten.
  4. Wählen Sie unter Flusslogs die Option An aus.
  5. Wenn Sie Log-Sampling und Logaggregation anpassen möchten, klicken Sie auf Logs konfigurieren und ändern Sie die folgenden Einstellungen wie gewünscht:
    • Aggregationsintervall
    • Ob Sie in den endgültigen Logeinträgen Metadaten einschließen möchten
    • Abtastrate (100% bedeutet, dass alle Einträge erhalten bleiben)
  6. Klicken Sie auf Speichern.

gcloud

    gcloud compute networks subnets update NAME \
        --enable-flow-logs \
        [--logging-aggregation-interval=INTERVAL] \
        [--logging-flow-sampling=0.0...1.0 \
        [--logging-metadata=(include-all | exclude-all)]
    

Dabei gilt:

  • --logging-aggregation-interval=<var>INTERVAL</var> legt das Aggregationsintervall für Flusslogs in diesem Subnetz fest. Das Intervall kann 5 Sekunden (Standard), 30 Sekunden, 1 Minute, 5 Minuten, 10 Minuten oder 15 Minuten betragen.
  • --logging-flow-sampling ist die Flussabtastrate. Das Fluss-Sampling kann auf einen Wert zwischen 0.0 (kein Sampling) und 1.0 (alle Logs) festgelegt werden. Der Standardwert ist .0.5.
  • --logging-metadata=(include-all | exclude-all) aktiviert bzw. deaktiviert die Aufzeichnung von Metadatenanmerkungen. Der Standardwert ist "An", also aktiviert.

API

Aktivieren Sie VPC-Flusslogs für ein vorhandenes Subnetz.

    PATCH https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME
    {
      "logConfig": {
        "enable": true
        ...other logging fields
      },
      "fingerprint": "SUBNETWORK_FINGERPRINT"
    }
    

Ersetzen Sie die Platzhalter durch gültige Werte:

  • PROJECT_ID ist die ID des Projekts, in dem sich das Subnetz befindet.
  • REGION ist die Region, in der sich das Subnetz befindet.
  • SUBNET_NAME ist der Name des vorhandenen Subnetzes.
  • SUBNET_FINGERPRINT ist die Fingerabdruck-ID für das bestehende Subnetz, die Sie beim Beschreiben des Subnetzes erhalten.
  • Informationen zu den anderen Logging-Feldern finden Sie unter VPC-Flusslogs beim Erstellen eines Subnetzes aktivieren.

Weitere Informationen finden Sie in der Methode subnetworks.patch.

Geschätztes Logvolumen für vorhandene Subnetze ansehen

Die Google Cloud Console bietet eine Schätzung des Logvolumens für vorhandene Subnetze, die Sie dann verwenden können, um die ungefähren Kosten für das Aktivieren der Flusslogs zu ermitteln. Die Schätzung basiert auf Flüssen, die über die letzten 7 Tage in 5-Sekunden-Intervallen für das Subnetz erfasst wurden. Die Größe jedes Logs hängt auch davon ab, ob Sie Metadatenanmerkungen aktivieren.

  1. Rufen Sie in der Google Cloud Console die Seite "VPC-Netzwerke" auf.
    Zur Seite "VPC-Netzwerke"
  2. Klicken Sie auf das Subnetz, für das Sie die Kosten schätzen möchten.
  3. Klicken Sie auf Bearbeiten.
  4. Wählen Sie unter Flusslogs die Option An aus.
  5. Klicken Sie auf Logs konfigurieren.
  6. Unter Geschätzte Logs pro Tag sehen Sie die Schätzung.
  7. Klicken Sie auf Abbrechen, damit keine Änderungen gespeichert werden.

VPC-Fluss-Logging-Parameter aktualisieren

Sie können die Log-Sampling-Parameter anpassen. Ausführliche Informationen zu den Parametern, die Sie festlegen können, finden Sie unter Log-Sampling und Logaggregation.

Console

  1. Rufen Sie in der Google Cloud Console die Seite "VPC-Netzwerke" auf.
    Zur Seite "VPC-Netzwerke"
  2. Klicken Sie auf das Subnetz, das Sie aktualisieren möchten.
  3. Klicken Sie auf Bearbeiten.
  4. Klicken Sie auf Logs konfigurieren, um Log-Sampling und Logaggregation anzupassen:
    • Aggregationsintervall
    • Ob Sie in den endgültigen Logeinträgen Metadaten einschließen möchten
    • Abtastrate (100% bedeutet, dass alle Einträge erhalten bleiben)
  5. Klicken Sie auf Speichern.

gcloud

    gcloud compute networks subnets update NAME \
        [--logging-aggregation-interval=INTERVAL] \
        [--logging-flow-sampling=0.0...1.0 \
        [--logging-metadata=(include-all | exclude-all)]
    

Dabei gilt:

  • --logging-aggregation-interval=<var>INTERVAL</var> legt das Aggregationsintervall für Flusslogs in diesem Subnetz fest. Das Intervall kann 5 Sekunden (Standard), 30 Sekunden, 1 Minute, 5 Minuten, 10 Minuten oder 15 Minuten betragen.
  • --logging-flow-sampling ist die Flussabtastrate. Das Fluss-Sampling kann auf einen Wert zwischen 0.0 (kein Sampling) und 1.0 (alle Logs) festgelegt werden. Der Standardwert ist .0.5.
  • --logging-metadata=(include-all | exclude-all) aktiviert bzw. deaktiviert die Aufzeichnung von Metadatenanmerkungen. Der Standardwert ist "An", also aktiviert.

API

Ändern Sie die Log-Sampling-Felder, um das Verhalten der VPC-Flusslogs zu aktualisieren.

    PATCH https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME
    {
      "logConfig": {
        ...fields to modify
      },
      "fingerprint": "SUBNETWORK_FINGERPRINT"
    }
    

Ersetzen Sie die Platzhalter durch gültige Werte:

  • PROJECT_ID ist die ID des Projekts, in dem sich das Subnetz befindet.
  • REGION ist die Region, in der sich das Subnetz befindet.
  • SUBNET_NAME ist der Name des vorhandenen Subnetzes.
  • SUBNET_FINGERPRINT ist die Fingerabdruck-ID für das bestehende Subnetz, die Sie beim Beschreiben des Subnetzes erhalten.
  • Informationen zu den Feldern, die Sie ändern können, finden Sie unter VPC-Flusslogs beim Erstellen eines Subnetzes aktivieren.

Weitere Informationen finden Sie in der Methode subnetworks.patch.

VPC-Flusslogs für ein Subnetz deaktivieren

Console

  1. Rufen Sie in der Google Cloud Console die Seite "VPC-Netzwerke" auf.
    Zur Seite "VPC-Netzwerke"
  2. Klicken Sie auf das Subnetz, das Sie aktualisieren möchten.
  3. Klicken Sie auf Bearbeiten.
  4. Wählen Sie unter Flusslogs die Option Aus.
  5. Klicken Sie auf Speichern.

gcloud

    gcloud compute networks subnets update NAME \
        --no-enable-flow-logs
    

API

Deaktivieren Sie VPC-Flusslogs für ein Subnetz, um die Erfassung von Logdatensätzen zu beenden.

    PATCH https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME
    {
      "logConfig": {
        "enable": false
      },
      "fingerprint": "SUBNETWORK_FINGERPRINT"
    }
    

Ersetzen Sie die Platzhalter durch gültige Werte:

  • PROJECT_ID ist die ID des Projekts, in dem sich das Subnetz befindet.
  • REGION ist die Region, in der sich das Subnetz befindet.
  • SUBNET_NAME ist der Name des vorhandenen Subnetzes.
  • SUBNET_FINGERPRINT ist die Fingerabdruck-ID für das bestehende Subnetz, die Sie beim Beschreiben des Subnetzes erhalten.

Weitere Informationen finden Sie in der Methode subnetworks.patch.

Logs über Logging aufrufen

IAM konfigurieren

Gehen Sie nach dem Anleitung zur Zugriffssteuerung für Logging vor.

Sehen Sie sich Logs mithilfe der Loganzeige an.

Sie benötigen die Projekt-ID Ihres Projekts für diese Befehle.

Auf alle Flusslogs zugreifen

  1. Rufen Sie in der Google Cloud Console die Seite "Logs" auf.
    Zur Seite "Logs"
  2. Wählen Sie im ersten Drop-down-Menü die Option GCE-Subnetzwerk aus.
  3. Wählen Sie im zweiten Drop-down-Menü die Option vpc_flows aus.
  4. Klicken Sie auf OK.

Alternativ:

  1. Rufen Sie in der Google Cloud Console die Seite "Logs" auf.
    Zur Seite "Logs"
  2. Klicken Sie auf den Drop-down-Pfeil rechts neben dem Feld Nach Label oder Textsuche filtern und wählen Sie In erweiterten Filter umwandeln aus.
  3. Fügen Sie Folgendes in das Feld ein. Ersetzen Sie [PROJECT-ID] durch Ihre Projekt-ID.
        resource.type="gce_subnetwork"
        logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows"
        
  4. Klicken Sie auf Filter senden.

Auf Logs für ein bestimmtes Subnetz zugreifen

  1. Rufen Sie in der Google Cloud Console die Seite "Logs" auf.
    Zur Seite "Logs"
  2. Bewegen Sie den Cursor im ersten Drop-down-Menü auf GCE-Subnetzwerk und bewegen Sie ihn dann nach rechts, um das Auswahlmenü für die einzelnen Subnetze zu öffnen.
  3. Wählen Sie im zweiten Drop-down-Menü vpc_flows aus.
  4. Klicken Sie auf OK.

Alternativ:

  1. Rufen Sie in der Google Cloud Console die Seite "Logs" auf.
    Zur Seite "Logs"
  2. Klicken Sie auf den Drop-down-Pfeil rechts neben dem Feld Nach Label oder Textsuche filtern und wählen Sie In erweiterten Filter umwandeln aus.
  3. Fügen Sie Folgendes in das Feld ein. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID und SUBNETWORK_NAME durch Ihr Subnetzwerk.
        resource.type="gce_subnetwork"
        logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows"
        resource.labels.subnetwork_name="SUBNETWORK_NAME"
        
  4. Klicken Sie auf Filter senden.

Auf Logs für bestimmte VMs zugreifen

  1. Rufen Sie in der Google Cloud Console die Seite "Logs" auf.
    Zur Seite "Logs"
  2. Klicken Sie auf den Drop-down-Pfeil rechts neben dem Feld Nach Label oder Textsuche filtern und wählen Sie In erweiterten Filter umwandeln aus.
  3. Fügen Sie Folgendes in das Feld ein. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID und VM_NAME durch Ihre VM.
        resource.type="gce_subnetwork"
        logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows"
        jsonPayload.src_instance.vm_name="VM_NAME"
        
  4. Klicken Sie auf Filter senden.

Auf Logs für Traffic zu einem bestimmten Präfix zugreifen

  1. Rufen Sie in der Google Cloud Console die Seite "Logs" auf.
    Zur Seite "Logs"
  2. Klicken Sie auf den Drop-down-Pfeil rechts neben dem Feld Nach Label oder Textsuche filtern und wählen Sie In erweiterten Filter umwandeln aus.
  3. Fügen Sie Folgendes in das Feld ein. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID und SUBNETWORK_NAME durch Ihr Subnetzwerk.
        resource.type="gce_subnetwork"
        logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows"
        ip_in_net(jsonPayload.connection.dest_ip, SUBNETWORK_NAME)
        
  4. Klicken Sie auf Filter senden.

Auf Logs für bestimmte Ports und Protokolle zugreifen

Für einen einzelnen Port

  1. Rufen Sie in der Google Cloud Console die Seite "Logs" auf.
    Zur Seite "Logs"
  2. Klicken Sie auf den Drop-down-Pfeil rechts neben dem Feld Nach Label oder Textsuche filtern und wählen Sie In erweiterten Filter umwandeln aus.
  3. Fügen Sie Folgendes in das Feld ein. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID, PORT durch den Port und PROTOCOL durch das Protokoll.
        resource.type="gce_subnetwork"
        logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows"
        jsonPayload.connection.src_port=PORT
        jsonPayload.connection.protocol=PROTOCOL
        
  4. Klicken Sie auf Filter senden.

Für mehrere Ports

  1. Rufen Sie in der Google Cloud Console die Seite "Logs" auf.
    Zur Seite "Logs"
  2. Klicken Sie auf den Drop-down-Pfeil rechts neben dem Feld Nach Label oder Textsuche filtern und wählen Sie In erweiterten Filter umwandeln aus.
  3. Fügen Sie Folgendes in das Feld ein. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID, PORT1 und PORT2 durch die Ports und PROTOCOL durch das Protokoll.
        resource.type="gce_subnetwork"
        logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows"
        jsonPayload.connection.src_port=(PORT1 OR PORT2)
        jsonPayload.connection.protocol=PROTOCOL
        
  4. Klicken Sie auf Filter senden.

Logs nach BigQuery, Pub/Sub und zu benutzerdefinierten Zielen exportieren

Sie können Flusslogs von Logging an ein Ziel Ihrer Wahl exportieren, wie in der Dokumentation zu Logging beschrieben. Beispiele für Filter finden Sie im vorherigen Abschnitt.

Fehlerbehebung

In Logging werden unter der Ressource gce_subnetwork keine vpc_flows angezeigt

  • VPC-Datenflüsse werden nur für das VPC-Netzwerk unterstützt. Wenn Sie ein Legacy-Netzwerk haben, werden keine Logs angezeigt.
  • In freigegebenen VPC-Netzwerken erscheinen Logs ausschließlich im Hostprojekt, aber nicht in den Dienstprojekten. Achten Sie darauf, dass Sie im Hostprojekt nach den Logs suchen.
  • Ausschlussfilter in Logging sperren bestimmte Logs. Achten Sie darauf, dass keine Ausschlussregeln vorhanden sind, die VPC-Flusslogs verwerfen.
    1. Öffnen Sie die Ressourcennutzung.
    2. Klicken Sie auf die Registerkarte Ausnahmen.
    3. Achten Sie darauf, dass keine Ausschlussregeln vorhanden sind, die VPC-Flusslogs verwerfen könnten.

Keine RTT- oder Bytewerte für manche Logs

  • RTT-Messungen können fehlen, wenn nicht genügend Pakete zur Erfassung von RTT abgetastet wurden. Dies tritt eher bei Verbindungen mit geringem Volumen auf.
  • Für UDP-Flüsse sind keine RTT-Werte verfügbar.
  • Einige Pakete werden ohne Nutzlast gesendet. Wenn Nur-Header-Pakete abgetastet wurden, ist der Bytewert 0.

Einige Datenflüsse fehlen

  • Nur UDP- und TCP-Protokolle werden unterstützt. VPC-Flusslogs unterstützen keine anderen Protokolle.
  • Es werden Logstichproben erstellt. Einige Pakete in Datenflüssen mit sehr geringem Volumen werden unter Umständen nicht erfasst.

Preise

Es gelten die Standardpreise für Logging, BigQuery oder Pub/Sub. Eine Beschreibung zu den Preisen für VPC-Flusslogs finden Sie unter Preise für Netzwerktelemetrie.

FAQ

  • Enthalten VPC-Flusslogs sowohl zugelassenen als auch abgelehnten Traffic, der auf Firewallregeln basiert?

    • VPC-Fluss-Logs decken Traffic aus der Perspektive einer VM ab. 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 dieser durch eine zulassende Firewallregel für eingehenden Traffic erlaubt ist. Der durch eine ablehnende Firewallregel für eingehenden Traffic blockierte eingehende Traffic wird nicht in Logs erfasst.
  • Funktionieren VPC-Flusslogs auch bei VM-Instanzen mit mehreren Schnittstellen?

  • Funktionieren VPC-Flusslogs bei Legacy-Netzwerken?

Weitere Informationen