Paketspiegelung für die Anwendungsmonitoring automatisch starten

In dieser Anleitung wird gezeigt, wie Sie mit Cloud Logging, Pub/Sub und Cloud Functions die Paketspiegelung automatisch aktivieren, damit Sie den Traffic in Ihrem VPC-Netzwerk (Virtual Private Cloud) beobachten und Fehler beheben können. Diese Anleitung richtet sich an Netzwerk-, Sicherheits- und DevOps-Teams. Es wird davon ausgegangen, dass Sie mit Cloud Logging, Pub/Sub, Cloud Functions, Paketspiegelung, Compute Engine und Terraform vertraut sind.

Einführung

Die Paketspiegelung ist eine Funktion, mit der Sie VPC-Trafficabläufe in Echtzeit beobachten können. Mit der Paketspiegelung können DevOps-Teams Probleme mit reduzierter Leistung oder Traffic beheben, der zu Fehlermeldungen führt. Sicherheitsbewusste Unternehmen können auch möglicherweise böswillige Trafficmuster beobachten und darauf reagieren. Organisationen verwenden häufig die Paketspiegelung zusammen mit einem Intrusion Detection System (IDS), um Bedrohungen zu erkennen und zu minimieren.

Bei der Paketspiegelung werden der gesamte eingehende und ausgehende Traffic (z. B. Nutzlasten und Header) erfasst und anschließend der Traffic exportiert, wodurch Sie uneingeschränkte Netzwerksichtbarkeit erhalten. Sie können gespiegelten Traffic aus anderen Bereichen an Sicherheits- und Monitoring-Appliances senden, mit denen Sie Bedrohungen erkennen, die Netzwerkleistung beobachten und Fehler bei Anwendungen beheben können.

Sie können die Paketspiegelung auf Subnetzebene, in Netzwerk-Tags oder in bestimmten VPC-Instanzen aktivieren. Sie können die Paketspiegelung kontinuierlich ausführen oder die Paketspiegelung basierend auf vordefinierten Triggern aktivieren oder deaktivieren.

In dieser Anleitung konfigurieren Sie die Architektur im folgenden Diagramm.

Der Internet-Traffic wird über den globalen Load-Balancer an die VPC mit Paketspiegelung weitergeleitet.

Diese Architektur hat den folgenden Workflow:

  1. An den Load-Balancer wird eine ungültige Anfrage gesendet, die von den Webservern den HTTP-Statuscode 500 Internal Server Error auslöst.
  2. Cloud Monitoring generiert ein Ereignis und Cloud Logging protokolliert eine Fehlermeldung.
  3. Pub/Sub, das als Senke für Cloud Monitoring konfiguriert ist, erhält die Fehlermeldung.
  4. Cloud Monitoring überträgt ein Ereignis an Pub/Sub und löst Cloud Functions aus, um die Paketspiegelung zu aktivieren.
  5. Die Paketspiegelung ist aktiviert und der Traffic wird an die Collector-VMs gespiegelt, damit eine entsprechende Person oder ein anderes Team die Fehlermeldungen weiter untersuchen kann. In dieser Anleitung verwenden Sie das Dienstprogramm tcpdump, um erfasste Pakete anzusehen.

Für diese Anleitung verwenden Sie Terraform von HashiCorp, um die VPC, Subnetze, globalen Load-Balancer, Webserver und Collector-VM zu erstellen. Anschließend konfigurieren Sie manuell eine Paketspiegelungsrichtlinie und die zugehörigen Collector-VMs, um gespiegelten Traffic zu erhalten. Konfigurieren Sie abschließend Cloud Logging, Cloud Functions und Pub/Sub, um die Paketspiegelung auszulösen.

In dieser Anleitung wird erläutert, welche Möglichkeiten Sie erhalten, wenn Sie zum Auslösen eines Ereignisses einen Fehlercode (HTTP 500) verwenden. Sie können diese Lösung aber auch für andere Anwendungsfälle und Umgebungen anpassen. Sie können das Logging beispielsweise so auslösen, dass Sie Muster (z. B. ein bestimmtes Regex-Muster) oder Anwendungsmesswerte (z. B. CPU- und Speichernutzung) untersuchen können.

Weitere Informationen zum Konfigurieren von Cloud Monitoring und Cloud Logging finden Sie in der Dokumentation zu Cloud Logging und Cloud Monitoring.

Ziele

  • Mit Terraform eine Basisumgebung bereitstellen.
  • Die Paketspiegelungsinfrastruktur konfigurieren.
  • Eine Anwendungsfehlermeldung auslösen.
  • Prüfen, ob die Paketspiegelung aktiviert ist.
  • Eine Paketerfassung auf den Collector-Compute Engine-Instanzen anzeigen.

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss dieser Anleitung können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Vorbereitung

  1. Aktivieren Sie Cloud Shell in der Cloud Console.

    Cloud Shell aktivieren

    Die meisten Schritte in dieser Anleitung erfolgen über das Cloud Shell-Terminal mit Terraform und dem Cloud SDK.

  2. Wechseln Sie in Cloud Shell in das lokale Arbeitsverzeichnis und klonen Sie das GitHub-Repository:

    cd $HOME
    git clone https://github.com/GoogleCloudPlatform/terraform-gce-packetmirror.git packetMirror
    

    Das Repository enthält alle Dateien, die Sie für diese Anleitung benötigen. Eine vollständige Beschreibung der einzelnen Dateien finden Sie in der Datei README.md im Repository.

  3. Wandeln Sie alle Shell-Skripts in ausführbare Dateien um:

    cd $HOME/packetMirror
    sudo chmod 755 *.sh
    
  4. Das Nutzerkonto, das Sie für diese Anleitung verwenden, muss die Berechtigungen zur Identitäts- und Zugriffsverwaltung (IAM) haben, die zum Ausführen der Anleitung erforderlich sind.

Umgebung vorbereiten

In diesem Abschnitt richten Sie die Umgebungsvariablen ein und stellen die unterstützende Infrastruktur bereit.

Terraform einrichten

  1. Folgen Sie den Schritten in der HashiCorp-Dokumentation, um Terraform zu installieren.
  2. Initialisieren Sie in Cloud Shell Terraform:

    terraform init
    

    Die Ausgabe sieht etwa so aus:

    ...
    Initializing provider plugins...
    The following providers do not have any version constraints in configuration, so the latest version was installed.
    ...
    Terraform has been successfully initialized!
    ...
    

Umgebungsvariablen festlegen

  1. Wenn Ihr Google Cloud-Nutzerkonto zu einer Google Cloud-Organisation gehört, führen Sie in Cloud Shell die folgenden Befehle aus:

    1. Legen Sie als Variable TF_VAR_org_id den Namen Ihrer Google Cloud-Organisation fest:

      export TF_VAR_org_id=$(gcloud organizations list \
          --format="value(ID)" \
          --filter="DISPLAY_NAME:YOUR_ORGANIZATION_NAME")
      

      Ersetzen Sie YOUR_ORGANIZATION_NAME durch den Google Cloud-Organisationsnamen, den Sie in dieser Anleitung verwenden möchten.

    2. Fügen Sie der Projektressource die Terraform-Variable org_id hinzu:

      sed -i "s/#org_id          = var.org_id/org_id          = var.org_id/" main.tf
      
    3. Prüfen Sie, ob die Umgebungsvariable richtig festgelegt ist:

      echo $TF_VAR_org_id
      

      Die Ausgabe enthält Ihre numerische Organisations-ID und sieht in etwa so aus:

      ...
      123123123123
      ...
      
  2. Legen Sie den Namen des Rechnungskontos fest:

    1. Listen Sie Ihre aktiven Rechnungskonten auf:

      gcloud beta billing accounts list
      

      Kopieren Sie den Namen des Rechnungskontos, den Sie für die Anleitung verwenden möchten. Sie benötigen diesen Namen im nächsten Schritt.

    2. Legen Sie die Umgebungsvariable für das Rechnungskonto fest:

      TF_VAR_billing_name="YOUR_BILLING_ACCOUNT_NAME"
      export TF_VAR_billing_name
      

      Ersetzen Sie YOUR_BILLING_ACCOUNT_NAME durch den Namen des Rechnungskontos, den Sie im vorherigen Schritt kopiert haben.

  3. Legen Sie die restlichen Umgebungsvariablen fest:

    source $HOME/packetMirror/set_variables.sh
    
  4. Prüfen Sie, ob die Umgebungsvariablen richtig festgelegt sind:

    env | grep TF_
    

    Die Ausgabe sieht etwa so aus:

    ...
    TF_VAR_billing_account=YOUR_BILLING_ACCOUNT_NAME
    TF_VAR_org_id=YOUR_ORGANIZATION_NAME
    TF_VAR_region=YOUR_REGION
    TF_VAR_user_account=YOUR_USER_ACCOUNT
    TF_VAR_pid=YOUR_PROJECT_ID
    TF_VAR_zone=YOUR_ZONE
    ...
    

    In dieser Ausgabe gilt:

    • YOUR_REGION: Die Region Ihres Google Cloud-Projekts, z. B. us-west1
    • YOUR_USER_ACCOUNT: Ihre Konto-ID, z. B. user@example
    • YOUR_PROJECT_ID: Ihre Cloud-Projekt-ID
    • YOUR_ZONE: Die Zone Ihres Cloud-Projekts, z. B. us-west1-b
  5. Wenn die Variable TF_VAR_billing_account nicht richtig festgelegt ist, wechseln Sie in der Cloud Console auf der Seite Abrechnungskonten verwalten zur Seite Übersicht – Rechnungskonto, kopieren Sie die ID-Nummer des Abrechnungskontos und legen Sie die folgende Umgebungsvariable fest:

    export TF_VAR_billing_account=BILLING_ACCOUNT_ID
    

    Ersetzen Sie BILLING_ACCOUNT_ID durch die Kontonummer, die Sie zuvor in diesem Schritt kopiert haben.

  6. Erstellen Sie eine Datei mit Umgebungsvariablen:

    $HOME/packetMirror/saveVars.sh
    

    Mit diesem Befehl werden die von Ihnen erstellten Umgebungsvariablen in die Datei TF_ENV_VARS weitergeleitet. Jeder Variable wird der Befehl export vorangestellt. Wenn Ihre Cloud Shell-Sitzung beendet wurde, können Sie mit dieser Datei die Variablen zurücksetzen. Diese Variablen werden von Terraform-Skripts, Cloud Shell-Skripts und dem gcloud-Befehlszeilentool verwendet.

    Wenn Sie die Variablen später neu initialisieren müssen, können Sie den folgenden Befehl ausführen:

    source $HOME/packetMirror/TF_ENV_VARS
    

Basisinfrastruktur bereitstellen

  1. Stellen Sie in Cloud Shell die unterstützende Infrastruktur von Terraform bereit:

    cd $HOME/packetMirror
    terraform apply
    
  2. Geben Sie yes ein, wenn Sie dazu aufgefordert werden, um eine der beiden Konfigurationen anzuwenden.

    Der Befehl terraform apply weist Terraform an, das Projekt, Netzwerke, Subnetzwerke, den globalen Load-Balancer und Webserver bereitzustellen. Wenn Sie wissen möchten, wie die Infrastruktur deklarativ definiert ist, können Sie die Terraform-Manifeste (Dateien mit der Erweiterung .tf) lesen.

    Die Bereitstellung der Komponenten durch Terraform kann einige Minuten dauern. Die folgenden Objekte werden erstellt:

    • VPC
    • Firewallregeln
    • Subnetze
    • Instanzvorlage für Webserver
    • Verwaltete Instanzgruppe für Webserver
    • Nicht verwaltete Instanzgruppe für Collector-VMs
    • Cloud NAT
    • Globaler Load-Balancer und zugehörige Systemdiagnosen

    Sie können Ihr Projekt durchsuchen, um diese Elemente entweder über die Cloud Console oder mithilfe von gcloud-Befehlen anzuzeigen.

Paketspiegelungsressourcen erstellen

Mit den folgenden Schritten erstellen und prüfen Sie die Infrastruktur für die Paketspiegelung.

Collector-interne Load-Balancing-Ressourcen erstellen

  • Erstellen Sie in Cloud Shell den Back-End-Dienst und die Weiterleitungsregel:

    gcloud compute backend-services create collector-ilb \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region" \
        --load-balancing-scheme=internal \
        --protocol=tcp \
        --health-checks=http-basic-check
    
    gcloud compute backend-services add-backend collector-ilb \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region" \
        --instance-group=collector-ig \
        --instance-group-zone="$TF_VAR_zone"
    
    gcloud compute forwarding-rules create fr-ilb-packet-mirroring \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region" \
        --load-balancing-scheme=internal \
        --network=packet-mirror-vpc \
        --subnet=collectors \
        --ip-protocol=TCP \
        --ports=all \
        --backend-service=collector-ilb \
        --backend-service-region="$TF_VAR_region" \
        --is-mirroring-collector
    

    Die Ausgabe sieht etwa so aus:

    ...
    Created [https://www.googleapis.com/compute/v1/projects/pm-pid-1357261223/regions/us-west1/backendServices/collector-ilb].
    NAME           BACKENDS  PROTOCOL
    collector-ilb            TCP
    ...
    Updated [https://www.googleapis.com/compute/v1/projects/pm-pid-1357261223/regions/us-west1/backendServices/collector-ilb].
    ...
    Created [https://www.googleapis.com/compute/projects/pm-pid-1357261223/regions/us-west1/forwardingRules/fr-ilb-packet-mirroring].
    ...
    

Paketspiegelungsrichtlinie erstellen und deaktivieren

  1. Erstellen und deaktivieren Sie in Cloud Shell eine Paketspiegelungsrichtlinie:

    gcloud compute packet-mirrorings create pm-mirror-subnet1 \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region" \
        --network=packet-mirror-vpc \
        --collector-ilb=fr-ilb-packet-mirroring \
        --mirrored-subnets=webservers \
        --no-enable
    
    gcloud compute packet-mirrorings describe pm-mirror-subnet1 \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region"
    

    Die Ausgabe sieht etwa so aus:

    ...
    Created [https://www.googleapis.com/compute/projects/pm-pid-1357261223/regions/us-west1/packetMirrorings/pm-mirror-subnet1].
    ...
    collectorIlb:
    ...
    enable: 'FALSE'
    ...
    

    Die Paketspiegelungsrichtlinie ist standardmäßig aktiviert. In diesem Schritt deaktivieren Sie die Richtlinie, da die Paketspiegelung nicht aktiv sein soll, bis Cloud Logging ein Problem erkennt.

Automatisierung erstellen, um eine Paketspiegelung auszulösen

  1. Erstellen Sie in Cloud Shell das Pub/Sub-Thema, das Sie für die Cloud Logging-Senke verwenden:

    gcloud pubsub topics create stackdriver_logging \
        --project="$TF_VAR_pid"
    

    Die Ausgabe sieht etwa so aus:

    ...
    Created topic [projects/pm-pid-1357261223/topics/stackdriver_logging].
    ...
    
  2. Erstellen Sie eine Cloud Logging-Senke:

    gcloud logging sinks create stackdriver_logging pubsub.googleapis.com/projects/"$TF_VAR_pid"/topics/stackdriver_logging \
        --log-filter='resource.type="http_load_balancer" \
            AND http_request.status>=500' \
        --project=$TF_VAR_pid
    

    Die Cloud Logging-Senke filtert die globalen HTTP-Statuscodes im Bereich 500 (z. B. 500, 501 oder 502) und sendet die Ereignisse an das Pub/Sub-Thema.

    Die Ausgabe sieht etwa so aus:

    Created [https://logging.googleapis.com/v2/projects/pm-pid-1357261223/sinks/stackdriver_logging].
    Please remember to grant `serviceAccount:p422429379846-984011@gcp-sa-logging.iam.gserviceaccount.com` the Pub/Sub Publisher role on the topic.
    More information about sinks can be found at https://cloud.oogle.com/logging/docs/export/configure_export
    

    Kopieren Sie den Wert serviceAccount aus der Ausgabe. Sie benötigen diesen Wert im nächsten Schritt.

  3. Gewähren Sie dem Dienstkonto die IAM-Rolle "Pub/Sub-Publisher" (roles/pubsub.publisher):

    gcloud pubsub topics add-iam-policy-binding stackdriver_logging \
        --project="$TF_VAR_pid" \
        --member serviceAccount:UPDATE_ACCOUNT \
        --role roles/pubsub.publisher
    

    Ersetzen Sie UPDATE_ACCOUNT durch den Wert für serviceAccount aus dem vorherigen Schritt.

    Die Ausgabe sieht etwa so aus:

    ...
    Updated IAM policy for topic [stackdriver_logging].
    bindings:
    - members:
      - serviceAccount:UPDATE_ACCOUNT
      role: roles/pubsub.publisher
    etag: notuCRmpoyI=
    version: 1
    ...
    
  4. Aktualisieren Sie die Datei main.py:

    net_id="$(gcloud compute networks describe packet-mirror-vpc --project="$TF_VAR_pid" --format='value(id)')"
    sed -i "s/PROJECT-ID/"$TF_VAR_pid"/g" main.py
    sed -i "s/REGION/"$TF_VAR_region"/g" main.py
    sed -i "s/NETWORK-ID/"$net_id"/g" main.py
    

    Die Datei main.py im Repository enthält die Funktion packet_mirror_pubsub, mit der Sie die Cloud Functions-Funktion erstellen. Bevor Sie die Cloud Functions-Funktion erstellen, aktualisiert der vorherige Befehl in der Python-Datei die Google Cloud-Projekt-ID, -Region und -Netzwerkinformationen.

  5. Erstellen Sie die Cloud Functions-Funktion:

    gcloud functions deploy packet_mirror_pubsub \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region" \
        --runtime python37 \
        --trigger-topic stackdriver_logging
    

    Wenn die folgende Warnung angezeigt wird, geben Sie N ein:

    Allow unauthenticated invocations of new function
    [packet_mirror_pubsub]? (y/N)?
    

    Die Ausgabe sieht etwa so aus:

    ...
    availableMemoryMb: 256
    entryPoint: packet_mirror_pubsub
    eventTrigger:
      eventType: google.pubsub.topic.publish
      failurePolicy: {}
      resource: projects/pm-pid--1517226903/topics/stackdriver_logging
      service: pubsub.googleapis.com
    ingressSettings: ALLOW_ALL
    labels:
      deployment-tool: cli-gcloud
    name: projects/pm-pid--1517226903/locations/europe-west1/functions/packet_mirror_pubsub
    runtime: python37
    serviceAccountEmail: pm-pid--1517226903@appspot.gserviceaccount.com
    ...
    status: ACTIVE
    ...
    

    Die Bereitstellung der Cloud Functions-Funktion kann einige Minuten dauern.

  6. Wenn Sie eine Fehlermeldung erhalten, gehen Sie so vor:

    • Wenn Sie eine Fehlermeldung zum Aktivieren der Cloud Build API erhalten, aktivieren Sie die API:

      gcloud services enable cloudbuild.googleapis.com
      

      Wiederholen Sie Schritt 5.

    • Wenn Sie eine Fehlermeldung für den Zugriff auf Cloud Storage erhalten, wiederholen Sie Schritt 5. Dieser Fehler kann auftreten, wenn Sie die Befehle schnell hintereinander ausführen.

Lösung prüfen

In den folgenden Schritten wird die Lösung ausgelöst und geprüft.

  1. Prüfen Sie in Cloud Shell das neue Pub/Sub-Abo:

    gcloud pubsub subscriptions list --project="$TF_VAR_pid"
    

    Die Ausgabe sieht etwa so aus:

    ...
    ---
    ackDeadlineSeconds: 600
    expirationPolicy: {}
    messageRetentionDuration: 604800s
    name: projects/pm-pid--1517226903/subscriptions/gcf-packet_mirror_pubsub-europe-west1-stackdriver_logging
    pushConfig:
      attributes:
        x-goog-version: v1
      pushEndpoint: https://e147a3acbd9a5314f553d1710671be9c-dot-efdbf9529ce1147d5p-tp.appspot.com/_ah/push-handlers/pubsub/projects/pm-pid--1517226903/topics/stackdriver_logging?pubsub_trigger=true
    topic: projects/pm-pid--1517226903/topics/stackdriver_logging
    ...
    
  2. Melden Sie sich bei der Collector-VM an:

    gcloud compute ssh collector \
        --tunnel-through-iap \
        --project="$TF_VAR_pid" \
        --zone="$TF_VAR_zone"
    
  3. Nachdem Sie sich bei der Collector-VM angemeldet haben, installieren und aktivieren Sie das Dienstprogramm tcpdump:

    sudo apt-get install tcpdump -y
    sudo tcpdump -n not net 172.16.21.0/24
    

    Die Ausgabe sieht etwa so aus:

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    

    Lassen Sie diese Cloud Shell-Sitzung geöffnet.

  4. Öffnen Sie ein neues Cloud Shell-Terminalfenster und lösen Sie dann die Cloud Functions-Funktion aus. Generieren Sie dazu einen HTTP 500-Fehler:

    cd $HOME/packetMirror
    source TF_ENV_VARS
    lb_ip=$(gcloud compute forwarding-rules describe packet-mirror-gfr --project=$TF_VAR_pid --global --format="value(IPAddress)")
    curl http://"$lb_ip"/error500
    

    Die Ausgabe sieht etwa so aus:

    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
    <html><head>
    <title>500 Internal Server Error</title>
    </head><body>
    <h1>Internal Server Error</h1>
    <p>The server encountered an internal error or
    misconfiguration and was unable to complete
    your request.</p>
    <p>Please contact the server administrator at
     webmaster@localhost to inform them of the time this error occurred,
     and the actions you performed just before this error.</p>
    <p>More information about this error may be available
    in the server error log.</p>
    <hr>
    <address>Apache/2.4.25 (Debian) Server at 35.241.40.217 Port 80</address>
    
  5. Kehren Sie zur Cloud Shell-Sitzung für die Collector-VM zurück und überwachen Sie die Ausgabe mit dem Befehl tcpdump. Die Collector-VM empfängt Traffic, d. h. die Prüfung zur Systemdiagnose für die Webserverinstanzen.

    Die Ausgabe sieht etwa so aus:

    ...
    07:33:41.131992 IP 130.211.2.146.53702 > 172.16.20.2.80: Flags [S], seq 4226031116, win 65535, options [mss 1420,sackOK,TS val 2961711820 ecr 0,nop,wscale 8], length 0
    07:33:41.132149 IP 130.211.2.146.53702 > 172.16.20.2.80: Flags [.], ack 3978158577, win 256, options [nop,nop,TS val 2961711821 ecr 4348156], length 0
    ...
    
  6. Zum Beenden der Ausgabe des Befehls tcpdump drücken Sie Control+C.

  7. Geben Sie exit ein, um die Collector-VM zu beenden.

  8. Prüfen Sie in Cloud Shell die Logs, um festzustellen, ob die Cloud Functions-Funktion ausgeführt wurde:

    gcloud functions logs read \
        --limit 50 \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region"
    

    Die Ausgabe sieht etwa so aus:

    LEVEL  NAME                  EXECUTION_ID     TIME_UTC                 LOG
    D      packet_mirror_pubsub  999875368753102  2020-02-21 07:33:39.206  Function execution started
    I      packet_mirror_pubsub  999875368753102  2020-02-21 07:33:39.222  HTTP 500 Error Detected in: {"httpRequest":{"remoteIp":"136.27.39.107","requestMethod":"GET","requestSize":"85","requestUrl":"http://35.241.40.217/error500","responseSize":"801","serverIp":"172.16.20.2","status":500,"userAgent":"curl/7.52.1"},"insertId":"nb4g1sfdrpm04","jsonPayload":{"@type":"type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry","enforcedSecurityPolicy":{"configuredAction":"ACCEPT","name":"policy","outcome":"ACCEPT","priority":2147483647},"statusDetails":"response_sent_by_backend"},".............
    I      packet_mirror_pubsub  999875368753102  2020-02-21 07:33:39.222  Activating Packet Mirroring For Analysis
    I      packet_mirror_pubsub  999875368753102  2020-02-21 07:33:39.329  ya29.c.KqUBvwfoZ5z88EmHKPXkgd1Gwqwwca88wWsyqjxrEFdhK8HjJDwmBWBIX_DAnC4wOO5W2B6EOQArgHQ03AIVwFnQMawXrB2tLGIkBYFuP3Go5Fylo6zZAvgtXF3LvrXiarwaASkfAM73lXfQiT20PYn4ML4E2Kli9WmhZDu6AdAe1aH-FK2MEoca84zgG65tirRGe04EJGY_hYHejlG_xrRWeaojVlc3
    I      packet_mirror_pubsub  999875368753102  2020-02-21 07:33:40.100  {
    I      packet_mirror_pubsub  999875368753102  2020-02-21 07:33:40.100    "id": "1924200601229605180",
    I      packet_mirror_pubsub  999875368753102  2020-02-21 07:33:40.100    "name": "operation-1582270419413-59f110a49a878-b68f2d26-c8f66a7b",
    I      packet_mirror_pubsub  999875368753102  2020-02-21 07:33:40.100    "operationType": "patch",
    I      packet_mirror_pubsub  999875368753102  2020-02-21 07:33:40.100    …..
     Function execution took 900 ms, finished with status: 'ok'
    

    Die Logs zeigen, dass die Paketspiegelung auf Basis des HTTP 500-Fehlercodes ausgelöst wurde, der von den Webserverinstanzen generiert wurde.

  9. Prüfen Sie den Funktionsstatus der Paketspiegelung:

    gcloud compute packet-mirrorings describe pm-mirror-subnet1 \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region"
    

    Die Ausgabe sieht etwa so aus:

    ...
    collectorIlb:
    ...
    enable: 'TRUE'
    ...
    

Bereinigen

Führen Sie eine Bereinigung durch, um zu vermeiden, dass Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden.

Infrastruktur löschen

  1. Entfernen Sie in Cloud Shell die Automatisierungsressourcen:

    gcloud functions delete packet_mirror_pubsub \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region" \
        --quiet
    gcloud logging sinks delete stackdriver_logging \
        --project="$TF_VAR_pid" \
        --quiet
    gcloud pubsub topics delete stackdriver_logging \
        --project="$TF_VAR_pid" \
        --quiet
    gcloud compute packet-mirrorings delete  pm-mirror-subnet1  \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region" \
        --quiet
    gcloud compute forwarding-rules delete fr-ilb-packet-mirroring \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region" \
        --quiet
    gcloud compute backend-services delete collector-ilb \
        --project="$TF_VAR_pid" \
        --region="$TF_VAR_region" \
        --quiet
    
  2. Löschen Sie alle Komponenten der Anleitung:

    pushd $HOME/packetMirror
    terraform destroy
    popd
    

    Geben Sie zum Löschen der Konfiguration yes ein, wenn Sie dazu aufgefordert werden.

  3. Entfernen Sie das Git-Repository:

    rm -rf $HOME/packetMirror
    

Weitere Informationen