Log-Streaming von Google Cloud zu Splunk bereitstellen

Last reviewed 2023-11-16 UTC

In diesem Dokument wird beschrieben, wie Sie einen Exportmechanismus bereitstellen, um Logs von Google Cloud-Ressourcen zu Splunk zu streamen. Es wird davon ausgegangen, dass Sie die entsprechende Referenzarchitektur für diesen Anwendungsfall bereits gelesen haben.

Diese Anleitung richtet sich an Betriebs- und Sicherheitsadministratoren, die Logs von Google Cloud zu Splunk streamen möchten. Sie müssen mit Splunk und dem HTTP Event Collector (HEC) von Splunk vertraut sein, wenn Sie diese Anweisungen für IT-Vorgänge oder Anwendungsfälle im Bereich Sicherheit verwenden. Für diese Bereitstellung ist es zwar hilfreich, mit Dataflow-Pipelines, Pub/Sub, Cloud Logging, Identity and Access Management und Cloud Storage vertraut zu sein.

Informationen zum Automatisieren der Bereitstellungsschritte in dieser Referenzarchitektur mit Infrastruktur als Code (IaC) finden Sie im GitHub-Repository terraform-splunk-log-export.

Architektur

Das folgende Diagramm zeigt die Referenzarchitektur und zeigt, wie die Logdaten von Google Cloud zu Splunk fließen.

Wie im Diagramm dargestellt, erfasst Cloud Logging die Logs in einer Logsenke auf Organisationsebene und sendet sie an Pub/Sub. Der Pub/Sub-Dienst erstellt ein einzelnes Thema und ein Abo für die Logs und leitet die Logs an die Dataflow-Hauptpipeline weiter. Die Haupt-Dataflow-Pipeline ist eine Pub/Sub to Splunk-Streaming-Pipeline, die Logs aus dem Pub/Sub-Abo abruft und an Splunk übermittelt. Parallel zur primären Dataflow-Pipeline ist die sekundäre Dataflow-Pipeline eine Pub/Sub-zu-Pub/Sub-Streaming-Pipeline, um Nachrichten wiederzugeben, wenn eine Übermittlung fehlschlägt. Am Ende des Vorgangs fungiert Splunk Enterprise oder Splunk Cloud Platform als HEC-Endpunkt und empfängt die Logs zur weiteren Analyse. Weitere Informationen finden Sie im Abschnitt Architektur der Referenzarchitektur.

Zum Bereitstellen dieser Referenzarchitektur führen Sie die folgenden Aufgaben aus:

• Führen Sie Einrichtungsaufgaben aus.
• Eine aggregierte Logsenke in einem zugehörigen Projekt erstellen.
• Erstellen Sie ein Thema für unzustellbare Nachrichten.
• Richten Sie einen Splunk-HEC-Endpunkt ein.
• Konfigurieren Sie die Dataflow-Pipelinekapazität.
• Exportieren Sie Logs nach Splunk.
• Transformieren Sie Logs oder Ereignisse während der Übertragung mit benutzerdefinierten Funktionen (User-Defined Functions, UDF) in der Splunk Dataflow-Pipeline.
• Verarbeiten Sie Übermittlungsfehler, um Datenverluste bei potenziellen Fehlkonfigurationen oder vorübergehenden Netzwerkproblemen zu vermeiden.

Hinweise

Führen Sie die folgenden Schritte aus, um eine Umgebung für die Referenzarchitektur von Google Cloud zu Splunk einzurichten:

• Richten Sie ein Projekt ein, aktivieren Sie die Abrechnung und aktivieren Sie die APIs.
• Weisen Sie IAM-Rollen zu.
• Umgebung einrichten
• Richten Sie ein sicheres Netzwerk ein.

Richten Sie ein Projekt ein, aktivieren Sie die Abrechnung und aktivieren Sie die APIs.

1. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

   Zur Projektauswahl

2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

3. Cloud Monitoring API, Secret Manager, Compute Engine, Pub/Sub, and Dataflow APIs aktivieren.

   Aktivieren Sie die APIs

IAM-Rollen zuweisen

Prüfen Sie in der Google Cloud Console, ob Sie die folgenden IAM-Berechtigungen (Identity and Access Management) für Organisations- und Projektressourcen haben. Weitere Informationen finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen.

Berechtigungen	Vordefinierte Rollen	Ressource
logging.sinks.create logging.sinks.get logging.sinks.update	Autor von Log-Konfigurationen (roles/logging.configWriter)	Organisation
compute.networks.* compute.routers.* compute.firewalls.* networkservices.*	Compute-Netzwerkadminstrator (roles/compute.networkAdmin) Compute-Sicherheitsadministrator (roles/compute.securityAdmin)	Projekt
secretmanager.*	Secret Manager-Administrator (roles/secretmanager.admin)	Projekt

Wenn die vordefinierten IAM-Rollen nicht genügend Berechtigungen enthalten, um Ihre Aufgaben auszuführen, erstellen Sie eine benutzerdefinierte Rolle. Eine benutzerdefinierte Rolle bietet Ihnen den erforderlichen Zugriff und hilft Ihnen dabei, das Prinzip der geringsten Berechtigung einzuhalten.

Hinweis: Zum Erstellen der aggregierten Logsenke auf Organisationsebene müssen Sie in der Organisationshierarchie die Rolle Autor von Logkonfigurationen haben. Wenn Sie keinen Zugriff haben, um Berechtigungen auf Organisationsebene zu ändern, bitten Sie Ihren Google Cloud-Organisationsadministrator, die organisationsweite Logsenke für Sie zu erstellen. Weitere Informationen zur Cloud Logging-Zugriffssteuerung finden Sie unter Vordefinierte Cloud Logging-Rollen.

Umgebung einrichten

1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

   Cloud Shell aktivieren

2. Legen Sie das Projekt für die aktive Cloud Shell-Sitzung fest:

   gcloud config set project PROJECT_ID
   

   Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Sicheres Netzwerk einrichten

In diesem Schritt richten Sie ein sicheres Netzwerk ein, bevor Sie Logs verarbeiten und in Splunk Enterprise exportieren.

1. Erstellen Sie ein VPC-Netzwerk und ein Subnetz:

   gcloud compute networks create NETWORK_NAME --subnet-mode=custom
   gcloud compute networks subnets create SUBNET_NAME \
   --network=NETWORK_NAME \
   --region=REGION \
   --range=192.168.1.0/24
   

   Ersetzen Sie Folgendes:

   • NETWORK_NAME: der Name des Netzwerks
   • SUBNET_NAME: der Name Ihres Subnetzes
   • REGION: die Region, die Sie für dieses Netzwerk verwenden möchten

2. Erstellen Sie eine Firewallregel für die virtuellen Maschinen (VMs) von Dataflow-Workern, damit sie miteinander kommunizieren können:

   gcloud compute firewall-rules create allow-internal-dataflow \
   --network=NETWORK_NAME \
   --action=allow \
   --direction=ingress \
   --target-tags=dataflow \
   --source-tags=dataflow \
   --priority=0 \
   --rules=tcp:12345-12346
   

   Diese Regel lässt internen Traffic zwischen Dataflow-VMs zu, die die TCP-Ports 12345–12346 verwenden. Außerdem legt der Dataflow-Dienst das Tag dataflow fest.

3. Erstellen Sie ein Cloud-NAT-Gateway:

   gcloud compute routers create nat-router \
   --network=NETWORK_NAME \
   --region=REGION
   
   gcloud compute routers nats create nat-config \
   --router=nat-router \
   --nat-custom-subnet-ip-ranges=SUBNET_NAME \
   --auto-allocate-nat-external-ips \
   --region=REGION
   

4. Aktivieren Sie den privaten Google-Zugriff für das Subnetz:

   gcloud compute networks subnets update SUBNET_NAME \
   --enable-private-ip-google-access \
   --region=REGION
   

Logsenke erstellen

In diesem Abschnitt erstellen Sie die organisationsweite Logsenke und das zugehörige Pub/Sub-Ziel sowie die erforderlichen Berechtigungen.

1. Erstellen Sie in Cloud Shell ein Pub/Sub-Thema und das zugehörige Abo als neues Ziel für die Logsenke:

   gcloud pubsub topics create INPUT_TOPIC_NAME
   gcloud pubsub subscriptions create \
   --topic INPUT_TOPIC_NAME INPUT_SUBSCRIPTION_NAME
   

   Ersetzen Sie Folgendes:

   • INPUT_TOPIC_NAME: der Name des Pub/Sub-Themas, das als Ziel der Logsenke verwendet werden soll
   • INPUT_SUBSCRIPTION_NAME: der Name des Pub/Sub-Abos für das Logsenkenziel

2. Erstellen Sie die Logsenke der Organisation:

   gcloud logging sinks create ORGANIZATION_SINK_NAME \
   pubsub.googleapis.com/projects/PROJECT_ID/topics/INPUT_TOPIC_NAME \
   --organization=ORGANIZATION_ID \
   --include-children \
   --log-filter='NOT logName:projects/PROJECT_ID/logs/dataflow.googleapis.com'
   

   Ersetzen Sie Folgendes:

   • ORGANIZATION_SINK_NAME: der Name Ihrer Organisation.
   • ORGANIZATION_ID: Ihre Organisations-ID.

   Der Befehl besteht aus folgenden Flags:

   • Das --organization Flag gibt an, dass es sich um eine Logsenke auf Organisationsebene handelt.
   • Das Flag --include-children ist erforderlich und sorgt dafür, dass die Logsenke auf Organisationsebene alle Logs in allen Unterordnern und Projekten enthält.
   • Das --log-filter Flag gibt die Logs an, die weitergeleitet werden sollen. In diesem Beispiel schließen Sie Dataflow-Vorgangslogs speziell für das Projekt PROJECT_ID aus, da die Dataflow-Pipeline für den Logexport selbst mehr Logs generiert, während sie Logs verarbeitet. Der Filter verhindert, dass die Pipeline ihre eigenen Logs exportiert, wodurch ein potenziell exponentieller Zyklus vermieden wird. Die Ausgabe enthält ein Dienstkonto im Format o#####-####@gcp-sa-logging.iam.gserviceaccount.com.

3. Weisen Sie dem Dienstkonto der Logsenke im Pub/Sub-Thema INPUT_TOPIC_NAME die IAM-Rolle „Pub/Sub-Publisher“ zu. Mit dieser Rolle kann das Dienstkonto der Logsenke Nachrichten zum Thema veröffentlichen.

   gcloud pubsub topics add-iam-policy-binding INPUT_TOPIC_NAME \
   --member=serviceAccount:LOG_SINK_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/pubsub.publisher
   

   Ersetzen Sie LOG_SINK_SERVICE_ACCOUNT durch den Namen des Dienstkontos für Ihre Logsenke.

Thema für unzustellbare Nachrichten erstellen

Erstellen Sie ein Pub/Sub-Thema für nicht übermittelbare Nachrichten und ein entsprechendes Abo, um potenzielle Datenverluste zu vermeiden, die auftreten, wenn eine Nachricht nicht übermittelt werden kann. Die fehlgeschlagene Nachricht wird im Thema für unzustellbare Nachrichten gespeichert, bis ein Operator oder ein Site Reliability Engineer den Fehler untersuchen und beheben kann. Weitere Informationen finden Sie im Abschnitt Fehlgeschlagene Nachrichten wiedergeben der Referenzarchitektur.

• Erstellen Sie in Cloud Shell ein Pub/Sub-Thema für unzustellbare Nachrichten und ein Abo, um Datenverlust zu vermeiden, indem Sie nicht zustellbare Nachrichten speichern:

  gcloud pubsub topics create DEAD_LETTER_TOPIC_NAME
  gcloud pubsub subscriptions create --topic DEAD_LETTER_TOPIC_NAME DEAD_LETTER_SUBSCRIPTION_NAME
  

  Ersetzen Sie Folgendes:

  • DEAD_LETTER_TOPIC_NAME: der Name des Pub/Sub-Themas, das das Thema für nicht übermittelbare Nachrichten ist
  • DEAD_LETTER_SUBSCRIPTION_NAME: der Name des Pub/Sub-Abos für das Thema für nicht übermittelbare Nachrichten

Splunk-HEC-Endpunkt einrichten

In den folgenden Verfahren richten Sie einen Splunk-HEC-Endpunkt ein und speichern das neu erstellte HEC-Token als Secret in Secret Manager. Wenn Sie die Splunk-Dataflow-Pipeline bereitstellen, müssen Sie sowohl die Endpunkt-URL als auch das Token angeben.

Splunk-HEC konfigurieren

1. Wenn Sie noch keinen Splunk HEC-Endpunkt haben, finden Sie in der Splunk-Dokumentation Informationen zur Konfiguration von Splunk HEC. Splunk HEC wird auf dem Splunk Cloud Platform-Dienst oder auf Ihrer eigenen Splunk Enterprise-Instanz ausgeführt.
2. Kopieren Sie in Splunk nach dem Erstellen eines Splunk HEC-Tokens den Tokenwert.
3. Speichern Sie in Cloud Shell den Splunk HEC-Tokenwert in einer temporären Datei namens splunk-hec-token-plaintext.txt.

Hinweis: Informationen zur Hochverfügbarkeit und zum Skalieren mit hohem Traffic finden Sie in den Splunk-Dokumenten zum Skalieren von HEC durch Verteilen der Last auf mehrere Knoten mithilfe eines HTTP(S)-Load-Balancer.

Splunk-HEC-Token in Secret Manager speichern

In diesem Schritt erstellen Sie ein Secret und eine einzelne zugrunde liegende Secret-Version, in der der Splunk-HEC-Tokenwert gespeichert wird.

Hinweis: Secret Manager wird ab der Dataflow-Vorlage "Pub/Sub to Splunk"2022-03-14-00_RC00 unterstützt. In dieser Referenzarchitektur wird die neueste Version dieser Vorlage verwendet.

1. Erstellen Sie in Cloud Shell ein Secret zum Speichern Ihres Splunk-HEC-Tokens:

   gcloud secrets create hec-token \
    --replication-policy="automatic"
   

   Weitere Informationen zu den Replikationsrichtlinien für Secrets finden Sie unter Replikationsrichtlinie auswählen.

2. Fügen Sie das Token als Secret-Version hinzu. Verwenden Sie dazu den Inhalt der Datei splunk-hec-token-plaintext.txt:

   gcloud secrets versions add hec-token \
    --data-file="./splunk-hec-token-plaintext.txt"
   

3. Löschen Sie die Datei splunk-hec-token-plaintext.txt, da sie nicht mehr benötigt wird.

Dataflow-Pipelinekapazität konfigurieren

Hinweis: Bevor Sie fortfahren, prüfen Sie, ob in Ihrer ausgewählten Region genügend CPU- und IP-Kontingente vorhanden sind, um die maximal mögliche Anzahl von Dataflow-VMs bereitzustellen (festgelegt mit dem Flag --max-workers). Weitere Informationen zum Prüfen und Anfordern einer Erhöhung von Kontingenten finden Sie unter Zuteilungskontingente.

In der folgenden Tabelle sind die empfohlenen allgemeinen Best Practices für die Konfiguration der Dataflow-Pipeline-Kapazitätseinstellungen zusammengefasst:

Einstellung	Allgemeine Best Practice
--worker-machine-type Flag	Auf Basis der Maschinengröße n1-standard-4 festlegen, um das beste Verhältnis von Leistung zu Kosten zu erzielen
--max-workers Flag	Auf die maximale Anzahl von Workern festgelegt, die Sie benötigen, um die erwarteten Spitzen-EPS gemäß Ihren Berechnungen zu verarbeiten
parallelism Parameter	Für 2 x vCPUs/Worker x die maximale Anzahl von Workern festlegen, um die Anzahl der parallelen Splunk HEC-Verbindungen zu maximieren
batchCount Parameter	Für Logs 10 bis 50 Ereignisse/Anfrage einstellen, sofern die maximale Pufferverzögerung von zwei Sekunden akzeptabel ist

Denken Sie daran, Ihre eigenen eindeutigen Werte und Berechnungen zu verwenden, wenn Sie diese Referenzarchitektur in Ihrer Umgebung bereitstellen.

1. Legen Sie Werte für Maschinentyp und Anzahl der Maschinen fest. Informationen zum Berechnen der Werte, die für Ihre Cloud-Umgebung geeignet sind, finden Sie in den Abschnitten Maschinentyp und Maschinenanzahl der Referenzarchitektur.

   DATAFLOW_MACHINE_TYPE
   DATAFLOW_MACHINE_COUNT
   

2. Legen Sie die Werte für die Parallelität und Batch-Anzahl von Dataflow fest. Informationen zum Berechnen der für Ihre Cloud-Umgebung geeigneten Werte finden Sie in den Abschnitten Parallelität und Batchanzahl der Referenzarchitektur.

   JOB_PARALLELISM
   JOB_BATCH_COUNT
   

Weitere Informationen zur Berechnung der Kapazitätsparameter von Dataflow-Pipelines finden Sie im Abschnitt Überlegungen zur Leistungs- und Kostenoptimierung der Referenzarchitektur.

Logs mit der Dataflow-Pipeline exportieren

In diesem Abschnitt stellen Sie die Dataflow-Pipeline mit den folgenden Schritten bereit:

• Erstellen Sie einen Cloud Storage-Bucket und ein Dataflow-Worker-Dienstkonto.
• Weisen Sie dem Dataflow-Worker-Dienstkonto Rollen und Zugriff zu.
• Stellen Sie die Dataflow-Pipeline bereit.
• Sehen Sie sich die Logs in Splunk an.

Die Pipeline sendet Google Cloud-Lognachrichten an den Splunk HEC.

Cloud Storage-Bucket und Dataflow-Worker-Dienstkonto erstellen

1. Erstellen Sie in Cloud Shell einen neuen Cloud Storage-Bucket mit einer einheitlichen Zugriffseinstellung auf Bucket-Ebene:

   gsutil mb -b on gs://PROJECT_ID-dataflow/
   

   Im Cloud Storage-Bucket, den Sie gerade erstellt haben, werden die temporären Dateien vom Dataflow-Job bereitgestellt.

2. Erstellen Sie in Cloud Shell ein Dienstkonto für Ihre Dataflow-Worker:

   gcloud iam service-accounts create WORKER_SERVICE_ACCOUNT \
      --description="Worker service account to run Splunk Dataflow jobs" \
      --display-name="Splunk Dataflow Worker SA"
   

   Ersetzen Sie WORKER_SERVICE_ACCOUNT durch den Namen, den Sie für das Dataflow-Worker-Dienstkonto verwenden möchten.

Rollen und Zugriff auf das Dataflow-Worker-Dienstkonto gewähren

Weisen Sie in diesem Abschnitt dem Dataflow-Worker-Dienstkonto die erforderlichen Rollen zu, wie in der folgenden Tabelle dargestellt.

Rolle	Pfad	Purpose
Dataflow-Administrator	roles/dataflow.worker	Aktivieren Sie das Dienstkonto, das als Dataflow-Administrator fungiert.
Dataflow-Worker	roles/dataflow.worker	Aktivieren Sie das Dienstkonto, das als Dataflow-Worker fungieren soll.
Storage-Objekt-Administrator	roles/storage.objectAdmin	Aktivieren Sie das Dienstkonto, um auf den Cloud Storage-Bucket zuzugreifen, der von Dataflow für Staging-Dateien verwendet wird.
Pub/Sub-Publisher	roles/pubsub.publisher	Aktivieren Sie das Dienstkonto, um fehlgeschlagene Nachrichten im Pub/Sub-Thema für unzustellbare Nachrichten zu veröffentlichen.
Pub/Sub-Abonnent	roles/pubsub.subscriber	Aktivieren Sie das Dienstkonto für den Zugriff auf das Eingabeabo.
Pub/Sub-Betrachter	roles/pubsub.viewer	Aktivieren Sie das Dienstkonto, um das Abo aufzurufen.
Zugriffsperson für Secret Manager-Secret	roles/secretmanager.secretAccessor	Aktivieren Sie das Dienstkonto, um auf das Secret zuzugreifen, das das Splunk HEC-Token enthält.

1. Weisen Sie in Cloud Shell dem Konto des Dataflow-Workers die Rollen „Dataflow-Administrator“ und „Dataflow-Worker“ zu, die dieses Konto zur Ausführung von Dataflow-Jobvorgängen und Verwaltungsaufgaben benötigt:

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
      --role="roles/dataflow.admin"
   

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
      --role="roles/dataflow.worker"
   

2. Gewähren Sie dem Dataflow-Worker-Dienstkonto Zugriff zum Aufrufen und Verarbeiten von Nachrichten aus dem Pub/Sub-Eingabeabo:

   gcloud pubsub subscriptions add-iam-policy-binding INPUT_SUBSCRIPTION_NAME \
    --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/pubsub.subscriber"
   

   gcloud pubsub subscriptions add-iam-policy-binding INPUT_SUBSCRIPTION_NAME \
    --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/pubsub.viewer"
   

3. Gewähren Sie dem Dataflow-Worker-Dienstkonto Zugriff auf die Veröffentlichung fehlgeschlagener Nachrichten im Pub/Sub-Thema für nicht verarbeitete Datensätze:

   gcloud pubsub topics add-iam-policy-binding DEAD_LETTER_TOPIC_NAME \
    --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/pubsub.publisher"
   

4. Gewähren Sie dem Dataflow-Worker-Dienstkonto Zugriff auf das Splunk HEC-Token-Secret in Secret Manager:

   gcloud secrets add-iam-policy-binding hec-token \
   --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com" \
   --role="roles/secretmanager.secretAccessor"
   

5. Gewähren Sie dem Dataflow-Worker-Dienstkonto Lese- und Schreibzugriff auf den Cloud Storage-Bucket, der vom Dataflow-Job für das Staging von Dateien verwendet werden soll:

   gcloud storage buckets add-iam-policy-binding gs://PROJECT_ID-dataflow/ \
   --member="serviceAccount:WORKER_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com"
   --role=”roles/storage.objectAdmin”
   

Dataflow-Pipeline bereitstellen

1. Legen Sie in Cloud Shell die folgende Umgebungsvariable für die Splunk HEC-URL fest:

   export SPLUNK_HEC_URL=SPLUNK_HEC_URL
   

   Ersetzen Sie die Variable SPLUNK_HEC_URL im Format protocol://host[:port]. Dabei gilt:

   • protocol ist entweder http oder https.
   • host ist der voll qualifizierte Domainname (FQDN) oder die IP-Adresse Ihrer Splunk HEC-Instanz oder, wenn Sie mehrere HEC-Instanzen haben, der zugehörige HTTP(S)- (oder DNS-basierte) Load-Balancer.
   • port ist die HEC-Portnummer. Er ist optional und hängt von der Splunk HEC-Endpunktkonfiguration ab.

   Ein Beispiel für eine gültige Splunk HEC-URL-Eingabe ist https://splunk-hec.example.com:8088. Wenn Sie Daten an HEC in Splunk Cloud Platform senden, finden Sie unter Daten an HEC in Splunk Cloud senden Informationen zum Ermitteln der oben genannten Teile host und port Ihrer spezifischen Splunk HEC-URL.

   Achtung: Wenn kein Abgleich des in diesem Schritt beschriebenen Splunk HEC-URL-Formats erfolgt, führt dies zu Fehlern bei der Dataflow-Eingabevalidierung und die Daten werden nicht an den Splunk-HEC-Endpunkt übermittelt. Stattdessen werden Ihre Streaminglogs an das nicht verarbeitete Thema gesendet.

   Die Splunk-HEC-URL darf den HEC-Endpunktpfad nicht enthalten, z. B. /services/collector. Die Dataflow-Vorlage "Pub/Sub to Splunk" unterstützt derzeit nur den Endpunkt /services/collector für JSON-formatierte Ereignisse und hängt diesen Pfad automatisch an die Splunk HEC-URL-Eingabe an. Weitere Informationen zu diesem HEC-Endpunkt finden Sie in der Splunk-Dokumentation für den services/collector-Endpunkt.

2. Stellen Sie die Dataflow-Pipeline mit der Dataflow-Vorlage „Pub/Sub to Splunk“ bereit:

   gcloud beta dataflow jobs run JOB_NAME \
   --gcs-location=gs://dataflow-templates/latest/Cloud_PubSub_to_Splunk \
   --staging-location=gs://PROJECT_ID-dataflow/temp/ \
   --worker-machine-type=DATAFLOW_MACHINE_TYPE \
   --max-workers=DATAFLOW_MACHINE_COUNT \
   --region=REGION \
   --network=NETWORK_NAME \
   --subnetwork=regions/REGION/subnetworks/SUBNET_NAME \
   --disable-public-ips \
   --parameters \
   inputSubscription=projects/PROJECT_ID/subscriptions/INPUT_SUBSCRIPTION_NAME,\
   outputDeadletterTopic=projects/PROJECT_ID/topics/DEAD_LETTER_TOPIC_NAME,\
   url=SPLUNK_HEC_URL,\
   tokenSource=SECRET_MANAGER, \
   tokenSecretId=projects/PROJECT_ID/secrets/hec-token/versions/1, \
   batchCount=JOB_BATCH_COUNT,\
   parallelism=JOB_PARALLELISM,\
   javascriptTextTransformGcsPath=gs://splk-public/js/dataflow_udf_messages_replay.js,\
   javascriptTextTransformFunctionName=process
   

   JOB_NAME durch das Namensformat pubsub-to-splunk-date+"%Y%m%d-%H%M%S" ersetzen

   Die optionalen Parameter javascriptTextTransformGcsPath und javascriptTextTransformFunctionName geben eine öffentlich verfügbare Beispiel-UDF an: gs://splk-public/js/dataflow_udf_messages_replay.js. Die Beispiel-UDF enthält Codebeispiele für die Ereignistransformations- und Decodierungslogik, mit der Sie fehlgeschlagene Zustellungen wiederholen. Weitere Informationen zu UDF finden Sie unter Ereignisse während der Laufzeit mit UDF transformieren.

3. Wenn der Pipelinejob abgeschlossen ist, suchen Sie die neue Job-ID in der Ausgabe, kopieren Sie die Job-ID und speichern sie. Sie geben diese Job-ID in einem späteren Schritt ein.

Logs in Splunk ansehen

Es dauert einige Minuten, bis die Dataflow-Pipeline-Worker bereitgestellt und bereit sind, Logs an Splunk HEC zu senden. Sie können in der Splunk Enterprise- oder Splunk Cloud Platform-Suchoberfläche prüfen, ob die Logs ordnungsgemäß empfangen und indexiert werden. So zeigen Sie die Anzahl der Logs pro Typ der überwachten Ressource an:

1. Öffnen Sie in Splunk Splunk Search & Reporting.

2. Führen Sie den Suchbefehl index=[MY_INDEX] | stats count by resource.type aus, um den Index MY_INDEX für Ihr Splunk HEC-Token zu konfigurieren:

   

3. Wenn Sie keine Ereignisse sehen, lesen Sie den Abschnitt Übermittlungsfehler verarbeiten.

Ereignisse während der Laufzeit mit UDF umwandeln

Die Dataflow-Vorlage Pub/Sub zu Splunk unterstützt eine JavaScript-UDF für benutzerdefinierte Ereignistransformationen, z. B. das Hinzufügen neuer Felder oder das Festlegen von Splunk HEC-Metadaten auf Ereignisbasis. Die von Ihnen bereitgestellte Pipeline verwendet diese Beispiel-UDF.

In diesem Abschnitt bearbeiten Sie zuerst die Beispiel-UDF-Funktion, um ein neues Ereignisfeld hinzuzufügen. In diesem neuen Feld wird der Wert des ursprünglichen Pub/Sub-Abos als zusätzliche Kontextinformationen angegeben. Anschließend aktualisieren Sie die Dataflow-Pipeline mit der geänderten UDF.

Beispiel-UDF ändern

1. Laden Sie in Cloud Shell die JavaScript-Datei herunter, die die Beispiel-UDF-Funktion enthält:

     wget https://storage.googleapis.com/splk-public/js/dataflow_udf_messages_replay.js
     

2. Öffnen Sie in einem Texteditor Ihrer Wahl die JavaScript-Datei, suchen Sie das Feld event.inputSubscription, entfernen Sie das Kommentarzeichen in dieser Zeile und ersetzen Sie splunk-dataflow-pipeline durch INPUT_SUBSCRIPTION_NAME:

   event.inputSubscription = "INPUT_SUBSCRIPTION_NAME";
   

3. Speichern Sie die Datei.

4. Laden Sie die Datei in den Cloud Storage-Bucket hoch.

   gsutil cp ./dataflow_udf_messages_replay.js gs://PROJECT_ID-dataflow/js/
   

Dataflow-Pipeline mit der neuen UDF aktualisieren

1. Beenden Sie die Pipeline in Cloud Shell mit der Drain-Option, damit die Logs, die bereits aus Pub/Sub abgerufen wurden, nicht verloren gehen:

   gcloud dataflow jobs drain JOB_ID --region=REGION
   

2. Führen Sie den Dataflow-Pipelinejob mit der aktualisierten UDF aus.

   gcloud beta dataflow jobs run JOB_NAME \
   --gcs-location=gs://dataflow-templates/latest/Cloud_PubSub_to_Splunk \
   --worker-machine-type=DATAFLOW_MACHINE_TYPE \
   --max-workers=DATAFLOW_MACHINE_COUNT \
   --region=REGION \
   --network=NETWORK_NAME \
   --subnetwork=regions/REGION/subnetworks/SUBNET_NAME \
   --disable-public-ips \
   --parameters \
   inputSubscription=projects/PROJECT_ID/subscriptions/INPUT_SUBSCRIPTION_NAME,\
   outputDeadletterTopic=projects/PROJECT_ID/topics/DEAD_LETTER_TOPIC_NAME,\
   url=SPLUNK_HEC_URL,\
   tokenSource=SECRET_MANAGER, \
   tokenSecretId=projects/PROJECT_ID/secrets/hec-token/versions/1, \
   batchCount=JOB_BATCH_COUNT,\
   parallelism=JOB_PARALLELISM,\
   javascriptTextTransformGcsPath=gs://PROJECT_ID-dataflow/js/dataflow_udf_messages_replay.js,\
   javascriptTextTransformFunctionName=process
   

   JOB_NAME durch das Namensformat pubsub-to-splunk-date+"%Y%m%d-%H%M%S" ersetzen

Übermittlungsfehler verarbeiten

Fehler bei der Zustellung können aufgrund von Fehlern bei der Verarbeitung der Ereignisse oder der Verbindung mit Splunk HEC auftreten. In diesem Abschnitt führen Sie einen Übermittlungsfehler durch, um den Workflow zur Fehlerbehandlung zu demonstrieren. Sie erfahren auch, wie Sie die erneute Übermittlung der fehlgeschlagenen Nachrichten an Splunk anzeigen und auslösen.

Zustellungsfehler auslösen

Führen Sie einen der folgenden Schritte aus, um einen Übermittlungsfehler in Splunk manuell einzuführen:

• Wenn Sie eine einzelne Instanz ausführen, beenden Sie den Splunk-Server, um Verbindungsfehler zu verursachen.
• Deaktivieren Sie das relevante HEC-Token aus der Splunk-Eingabekonfiguration.

Fehlerbehebung bei fehlgeschlagenen Nachrichten

Um eine fehlgeschlagene Nachricht zu untersuchen, können Sie die Google Cloud Console verwenden:

1. Rufen Sie in der Google Cloud Console die Seite Pub/Sub-Abos auf.

   Pub/Sub-Abos aufrufen

2. Klicken Sie auf das unverarbeitete Abo, das Sie erstellt haben. Wenn Sie das vorherige Beispiel verwendet haben, lautet der Abo-Name projects/PROJECT_ID/subscriptions/DEAD_LETTER_SUBSCRIPTION_NAME.

3. Klicken Sie zum öffnen der Nachrichtenanzeige auf Nachrichten anzeigen.

4. Klicken Sie zum Abrufen von Nachrichten auf Pull. Außerdem muss die Option Bestätigungsnachrichten aktivieren deaktiviert sein.

5. Prüfen Sie die fehlgeschlagenen Nachrichten. Achten Sie auf Folgendes:

   • Die Splunk-Ereignisnutzlast in der Spalte Message body.
   • Die Fehlermeldung in der Spalte attribute.errorMessage.
   • Der Fehlerzeitstempel in der Spalte attribute.timestamp.

Der folgende Screenshot zeigt ein Beispiel für eine Fehlermeldung, die Sie erhalten, wenn der Splunk HEC-Endpunkt vorübergehend nicht verfügbar oder nicht erreichbar ist. Der Text des Attributs errorMessage lautet The target server failed to respond. Die Nachricht enthält auch den Zeitstempel, der mit jedem Fehler verknüpft ist. Sie können diesen Zeitstempel verwenden, um die Ursache des Fehlers zu beheben.

Fehlgeschlagene Nachrichten wiedergeben

In diesem Abschnitt müssen Sie den Splunk-Server neu starten oder den Splunk HEC-Endpunkt aktivieren, um den Bereitstellungsfehler zu beheben. Sie können dann die nicht verarbeiteten Nachrichten wiedergeben.

1. Verwenden Sie in Splunk eine der folgenden Methoden, um die Verbindung in Google Cloud wiederherzustellen:

   • Wenn Sie den Splunk-Server gestoppt haben, starten Sie den Server neu.
   • Wenn Sie den Splunk HEC-Endpunkt im Abschnitt Trigger für fehlgeschlagene Übermittlung deaktiviert haben, prüfen Sie, ob der Splunk HEC-Endpunkt jetzt funktioniert.

2. Erstellen Sie in Cloud Shell einen Snapshot des nicht verarbeiteten Abos, bevor Sie die Nachrichten in diesem Abo noch einmal verarbeiten. Der Snapshot verhindert den Verlust von Nachrichten, wenn ein unerwarteter Konfigurationsfehler auftritt.

   gcloud pubsub snapshots create SNAPSHOT_NAME \
   --subscription=DEAD_LETTER_SUBSCRIPTION_NAME
   

   Ersetzen Sie SNAPSHOT_NAME durch einen Namen, mit dem Sie den Snapshot identifizieren können, z. B. dead-letter-snapshot-date+"%Y%m%d-%H%M%S.

3. Verwenden Sie die Dataflow-Vorlage „Pub/Sub to Splunk“ zum Erstellen einer Pub/Sub-zu-Pub/Sub-Pipeline. Die Pipeline verwendet einen anderen Dataflow-Job, um die Nachrichten aus dem nicht verarbeiteten Abo wieder an das Eingabethema zu übertragen.

   DATAFLOW_INPUT_TOPIC="INPUT_TOPIC_NAME"
   DATAFLOW_DEADLETTER_SUB="DEAD_LETTER_SUBSCRIPTION_NAME"
   JOB_NAME=splunk-dataflow-replay-date +"%Y%m%d-%H%M%S"
   gcloud dataflow jobs run JOB_NAME \
   --gcs-location= gs://dataflow-templates/latest/Cloud_PubSub_to_Cloud_PubSub \
   --worker-machine-type=n1-standard-2 \
   --max-workers=1 \
   --region=REGION \
   --parameters \
   inputSubscription=projects/PROJECT_ID/subscriptions/DEAD_LETTER_SUBSCRIPTION_NAME,\
   outputTopic=projects/PROJECT_ID/topics/INPUT_TOPIC_NAME
   

4. Kopieren Sie die Dataflow-Job-ID aus der Befehlsausgabe und speichern Sie sie für später. Sie geben diese Job-ID als REPLAY_JOB_ID ein, wenn Sie den Dataflow-Job per Drain beenden.

5. Rufen Sie in der Google Cloud Console die Seite Pub/Sub-Abos auf.

   Pub/Sub-Abos aufrufen

6. Wählen Sie das nicht verarbeitete Abo aus. Prüfen Sie, ob die Grafik Unbestätigte Nachrichtenanzahl auf 0 reduziert ist, wie im folgenden Screenshot dargestellt.

   

7. Entfernen Sie in Cloud Shell den von Ihnen erstellten Dataflow-Job:

   gcloud dataflow jobs drain REPLAY_JOB_ID --region=REGION
   

   Ersetzen Sie REPLAY_JOB_ID durch die zuvor gespeicherte Dataflow-Job-ID.

Wenn Nachrichten wieder in das ursprüngliche Eingabethema übertragen werden, übernimmt die Dataflow-Hauptpipeline die fehlgeschlagenen Nachrichten automatisch und übermittelt sie an Splunk.

Nachrichten in Splunk bestätigen

1. Öffnen Sie in Splunk Splunk Search & Reporting, um zu bestätigen, dass die Nachrichten noch einmal übermittelt wurden.

2. Führen Sie eine Suche nach delivery_attempts > 1 durch. Dies ist ein spezielles Feld, das die Beispiel-UDF jedem Ereignis hinzufügt, um die Anzahl der Übermittlungsversuche zu verfolgen. Erweitern Sie den Suchzeitbereich um Ereignisse, die möglicherweise in der Vergangenheit aufgetreten sind, da der Ereigniszeitstempel der ursprüngliche Zeitpunkt der Erstellung und nicht der Zeitpunkt der Indizierung ist.

Im folgenden Screenshot werden die beiden ursprünglich fehlgeschlagenen Nachrichten jetzt erfolgreich zugestellt und in Splunk mit dem richtigen Zeitstempel indexiert.

Beachten Sie, dass der Feldwert insertId mit dem Wert übereinstimmt, der in den fehlgeschlagenen Nachrichten angezeigt wird, wenn Sie das nicht verarbeitete Abo aufrufen. Das Feld insertId ist eine eindeutige Kennung, die Cloud Logging dem ursprünglichen Logeintrag zuweist. insertId wird auch im Pub/Sub-Nachrichtentext angezeigt.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Referenzarchitektur verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Senke auf Organisationsebene löschen

• Verwenden Sie den folgenden Befehl, um die Logsenke auf Organisationsebene zu löschen:

  gcloud logging sinks delete ORGANIZATION_SINK_NAME --organization=ORGANIZATION_ID
  

Projekt löschen

Nachdem die Logsenke gelöscht wurde, können Sie mit dem Löschen von Ressourcen fortfahren, die zum Empfangen und Exportieren von Logs erstellt wurden. Am einfachsten ist es, das für die Referenzarchitektur erstellte Projekt zu löschen.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:
• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.
1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

   Zur Seite „Ressourcen verwalten“

2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Nächste Schritte

• Eine vollständige Liste der Parameter der Dataflow-Vorlage "Pub/Sub to Splunk" finden Sie in der Dokumentation „Pub/Sub to Splunk Dataflow“.
• Die entsprechenden Terraform-Vorlagen zur Bereitstellung dieser Referenzarchitektur finden Sie im GitHub-Repository terraform-splunk-log-export. Es enthält ein vordefiniertes Cloud Monitoring-Dashboard für das Monitoring Ihrer Splunk Dataflow-Pipeline.
• Weitere Informationen zu benutzerdefinierten Messwerten und Logging von Splunk Dataflow finden Sie in diesem Blog: Neue Beobachtbarkeitsfeatures für Ihre Splunk Dataflow-Streamingpipelines.
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.