Esegui il deployment dei flussi di log da Google Cloud a Splunk

Last reviewed 2023-11-16 UTC

Questo documento descrive come eseguire il deployment di un meccanismo di esportazione per trasmettere i log da le risorse Google Cloud su Splunk. Si presume che tu abbia già letto le riferimento corrispondente per questo caso d'uso.

Queste istruzioni sono rivolte agli amministratori delle operazioni e della sicurezza che vuoi trasmettere i flussi di log da Google Cloud a Splunk. Devi avere familiarità con Splunk e Splunk HTTP Event Collector (HEC) quando si utilizzano queste istruzioni per le operazioni IT o i casi d'uso in materia di sicurezza. Sebbene non sia necessaria, la familiarità con pipeline di Dataflow, Pub/Sub, Cloud Logging, Identity and Access Management e Cloud Storage è utile per questo deployment.

Per automatizzare i passaggi di deployment in questa architettura di riferimento utilizzando Infrastructure as Code (IaC), consulta terraform-splunk-log-export GitHub di ASL.

Architettura

Il seguente diagramma mostra l'architettura di riferimento e illustra il modo in cui log di flussi di dati da Google Cloud a Splunk.

Come mostrato nel diagramma, Cloud Logging raccoglie i log in una un sink di log a livello di organizzazione e invia i log a Pub/Sub. La Il servizio Pub/Sub crea un singolo argomento e una singola sottoscrizione per e inoltra i log alla pipeline Dataflow principale. La la pipeline Dataflow principale è una pipeline da Pub/Sub a Splunk pipeline di flusso che estrae i log dalla sottoscrizione Pub/Sub e li consegna a Splunk. Parallelamente al modello Dataflow principale una pipeline Dataflow secondaria, Pipeline di flusso da Pub/Sub a Pub/Sub da riprodurre se il recapito non va a buon fine. Al termine del processo, Splunk Enterprise o Splunk Cloud Platform funge da endpoint HEC e riceve i log per ulteriori e analisi. Per ulteriori dettagli, consulta Architettura dell'architettura di riferimento.

Per eseguire il deployment di questa architettura di riferimento, devi eseguire le seguenti attività:

• Esegui attività di configurazione.
• Crea un sink di log aggregato in un progetto dedicato.
• Crea un argomento messaggi non recapitabili.
• Configura un endpoint Splunk HEC.
• Configura la capacità della pipeline Dataflow.
• Esporta i log in Splunk.
• Trasforma i log o gli eventi in-flight utilizzando le funzioni definite dall'utente all'interno della pipeline Dataflow di Splunk.
• Gestisci gli errori di consegna per evitare perdite di dati dovute a potenziali errori di configurazione o problemi di rete temporanei.

Prima di iniziare

Completa i seguenti passaggi per configurare un ambiente per il tuo Architettura di riferimento da Google Cloud a Splunk:

• Apri un progetto, abilita la fatturazione e attiva le API.
• Concedi ruoli IAM.
• Configura l'ambiente.
• Configura una rete sicura.

Creare un progetto, abilitare la fatturazione e attivare le API

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

3. Abilita le API Cloud Monitoring API, Secret Manager, Compute Engine, Pub/Sub, and Dataflow.

   Abilita le API

Concedi ruoli IAM

Nella console Google Cloud, assicurati di disporre delle seguenti funzionalità di Identity and Access Management (IAM) per le risorse dell'organizzazione e del progetto. Per ulteriori informazioni, consulta l'articolo Concessione, modifica e revoca dell'accesso a Google Cloud.

Autorizzazioni	Ruoli predefiniti	Risorsa
logging.sinks.create logging.sinks.get logging.sinks.update	Writer configurazione log (roles/logging.configWriter)	Organizzazione
compute.networks.* compute.routers.* compute.firewalls.* networkservices.*	Amministratore rete Compute (roles/compute.networkAdmin) Amministratore sicurezza Compute (roles/compute.securityAdmin)	Progetto
secretmanager.*	Amministratore Secret Manager (roles/secretmanager.admin)	Progetto

Se i ruoli IAM predefiniti non includono autorizzazioni sufficienti per di eseguire le tue mansioni, crea una ruolo. Un ruolo personalizzato ti dà l'accesso di cui hai bisogno, aiutandoti al contempo a seguire il principio del privilegio minimo.

Nota: per creare il sink di log aggregato a livello di organizzazione, devi disporre della Ruolo Writer configurazione log assegnato a te nella gerarchia dell'organizzazione livello. Se non disponi dell'accesso per modificare le autorizzazioni a livello di organizzazione, chiedi all'amministratore della tua organizzazione Google Cloud di crea un sink di log a livello di organizzazione per te. Per maggiori informazioni informazioni sul controllo dell'accesso di Cloud Logging, consulta Ruoli predefiniti di Cloud Logging.

Configura l'ambiente

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

2. Imposta il progetto per la sessione di Cloud Shell attiva:

   gcloud config set project PROJECT_ID
   

   Sostituisci PROJECT_ID con l'ID progetto.

Configura una rete sicura

In questo passaggio devi configurare il networking sicuro prima di elaborare ed esportare i log a Splunk Enterprise.

1. Crea una rete VPC e una subnet:

   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
   

   Sostituisci quanto segue:

   • NETWORK_NAME: il nome della tua rete
   • SUBNET_NAME: il nome della subnet
   • REGION: la regione che vuoi utilizzare per rete

2. Crea una regola firewall per le macchine virtuali worker Dataflow per comunicare tra loro:

   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
   

   Questa regola consente il traffico interno tra le VM Dataflow che usano le porte TCP 12345-12346. Inoltre, il servizio Dataflow imposta il tag dataflow.

3. Crea un gateway Cloud NAT:

   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. Abilita l'accesso privato Google nella subnet:

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

Crea un sink di log

In questa sezione creerai il sink di log a livello di organizzazione e i relativi destinazione Pub/Sub, insieme alle autorizzazioni necessarie.

1. In Cloud Shell, crea un argomento Pub/Sub e i relativi abbonamento come nuova destinazione del sink di log:

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

   Sostituisci quanto segue:

   • INPUT_TOPIC_NAME: il nome di Pub/Sub argomento da utilizzare come destinazione del sink di log
   • INPUT_SUBSCRIPTION_NAME: il nome del Sottoscrizione Pub/Sub alla destinazione del sink di log

2. Crea il sink di log dell'organizzazione:

   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'
   

   Sostituisci quanto segue:

   • ORGANIZATION_SINK_NAME: il nome del sink in l'organizzazione
   • ORGANIZATION_ID: l'ID della tua organizzazione

   Il comando è costituito dai seguenti flag:

   • Il flag --organization specifica che si tratta di un'istanza a livello di organizzazione nel sink di log.
   • Il flag --include-children è obbligatorio e garantisce che il flag il sink di log a livello di organizzazione include tutti i log di tutte le sottocartelle in modo programmatico a gestire i progetti.
   • Il flag --log-filter specifica i log da instradare. In questo esempio, escludi i log delle operazioni di Dataflow specifici per progetto PROJECT_ID, perché l'esportazione dei log La pipeline Dataflow genera più log durante l'elaborazione logaritmi. Il filtro impedisce alla pipeline di esportare i propri log, evitando un ciclo potenzialmente esponenziale. L'output include un servizio nel formato o#####-####@gcp-sa-logging.iam.gserviceaccount.com.

3. Concedi il ruolo IAM Publisher Pub/Sub al servizio sink di log sull'argomento Pub/Sub INPUT_TOPIC_NAME. Questo ruolo consente all'account di servizio del sink di log di pubblicare messaggi nell' per ogni argomento.

   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
   

   Sostituisci LOG_SINK_SERVICE_ACCOUNT con il nome dell'account di servizio per il sink di log.

Creare un argomento messaggi non recapitabili

Per impedire la potenziale perdita di dati che si verifica quando un messaggio non riesce consegnati, devi creare un'istanza Pub/Sub argomento messaggi non recapitabili e l'abbonamento corrispondente. Il messaggio di errore viene memorizzato nei messaggi non recapitabili fino a quando un operatore o un tecnico della Site Reliability Engineering non possono esaminare e correggere l'errore. Per ulteriori informazioni, consulta la sezione Riprodurre di nuovo i messaggi non riusciti dell'architettura di riferimento.

• In Cloud Shell, crea un argomento messaggi non recapitabili Pub/Sub e la sottoscrizione per evitare perdite di dati mediante l'archiviazione di messaggi non recapitabili:

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

  Sostituisci quanto segue:

  • DEAD_LETTER_TOPIC_NAME: il nome del Argomento Pub/Sub che sarà l'argomento messaggi non recapitabili
  • DEAD_LETTER_SUBSCRIPTION_NAME: il nome del Sottoscrizione Pub/Sub per l'argomento messaggi non recapitabili

Configura un endpoint Splunk HEC

Nelle procedure seguenti, configuri un endpoint Splunk HEC e memorizzi token HEC appena creato come secret in Secret Manager. Quando eseguire il deployment della pipeline Dataflow Splunk, devi fornire sia l'URL dell'endpoint e il token.

Configurare Splunk HEC

1. Se non hai ancora un endpoint Splunk HEC, consulta la sezione documentazione per scoprire come configurare uno Splunk HEC. Splunk HEC viene eseguito su Splunk Cloud Platform servizio o Splunk Enterprise di Compute Engine.
2. In Splunk, dopo aver creato un token HEC Splunk, copia il valore del token.
3. In Cloud Shell, salva il valore del token HEC Splunk in un file temporaneo denominato splunk-hec-token-plaintext.txt.

Nota: per l'alta disponibilità e per imparare la scalabilità in presenza di traffico con volumi elevati, consulta la documentazione di Splunk su come scalare HEC distribuendo il carico a più nodi tramite un bilanciatore del carico HTTP(S).

Archivia il token HEC Splunk in Secret Manager

In questo passaggio creerai un secret e un'unica versione del secret sottostante in in cui archiviare il valore del token HEC Splunk.

Nota: Secret Manager è supportato a partire da Pub/Sub per Dataflow Splunk versione del modello 2022-03-14-00_RC00. Questa architettura di riferimento utilizza l'ultima versione questo modello.

1. In Cloud Shell, crea un secret che contenga il token HEC Splunk:

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

   Per ulteriori informazioni sui criteri di replica per i secret, consulta Scegliere una criterio di replica.

2. Aggiungi il token come versione del secret utilizzando i contenuti del file splunk-hec-token-plaintext.txt:

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

3. Elimina il file splunk-hec-token-plaintext.txt perché non è più necessario.

Configura la capacità della pipeline Dataflow

Nota: prima di procedere, assicurati di avere una quota di CPU e IP sufficiente nel tuo regione prescelta per eseguire il provisioning il maggior numero possibile di VM Dataflow (impostate con il flag --max-workers). Per maggiori informazioni per controllare e richiedere un aumento delle quote, consulta Quote di allocazione.

La seguente tabella riassume le best practice generali consigliate per configurando le impostazioni relative alla capacità della pipeline Dataflow:

Impostazione	Best practice generale
--worker-machine-type flag	Imposta la dimensione macchina di riferimento n1-standard-4 per il miglior rapporto costo/prestazioni
--max-workers flag	Imposta il numero massimo di worker necessari per gestire le attività previste picco EPS in base ai tuoi calcoli
Parametro parallelism	Imposta su 2 x vCPU/worker x il numero massimo di worker da massimizzare il numero di connessioni HEC Splunk in parallelo
batchCount parametro	Imposta su 10-50 eventi/richiesta per i log, a condizione che il buffering massimo un ritardo di due secondi è accettabile

Ricorda di usare valori e calcoli univoci quando esegui il deployment un'architettura di riferimento nel tuo ambiente.

1. Imposta i valori per il tipo di macchina e il conteggio delle macchine. Per calcolare i valori appropriati per il tuo ambiente cloud, consulta Machine tipo e a macchina contare sezioni dell'architettura di riferimento.

   DATAFLOW_MACHINE_TYPE
   DATAFLOW_MACHINE_COUNT
   

2. Imposta i valori per il parallelismo e il conteggio dei batch di Dataflow. A di calcolare i valori appropriati per il tuo ambiente cloud, consulta Parallelismo e Batch contare sezioni dell'architettura di riferimento.

   JOB_PARALLELISM
   JOB_BATCH_COUNT
   

Per ulteriori informazioni su come calcolare la pipeline Dataflow di capacità, consulta la sezione Progettazione dell'ottimizzazione dei costi e delle prestazioni considerazioni dell'architettura di riferimento.

Esporta i log utilizzando la pipeline Dataflow

In questa sezione eseguirai il deployment della pipeline Dataflow con seguenti passaggi:

• Crea un bucket Cloud Storage e un account di servizio worker Dataflow.
• Concedi i ruoli e l'accesso all'account di servizio worker Dataflow.
• Esegui il deployment della pipeline Dataflow.
• Visualizza i log in Splunk.

La pipeline invia i messaggi di log di Google Cloud a Splunk HEC.

Creare un bucket Cloud Storage e un account di servizio worker Dataflow

1. In Cloud Shell, crea un nuovo bucket Cloud Storage con un impostazione di accesso uniforme a livello di bucket:

   gcloud storage buckets create gs://PROJECT_ID-dataflow/ --uniform-bucket-level-access
   

   Il bucket Cloud Storage che hai appena creato è il punto in cui Il job Dataflow organizza i file temporanei.

2. In Cloud Shell, crea un account di servizio Worker Dataflow:

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

   Sostituisci WORKER_SERVICE_ACCOUNT con il nome che che si vuole usare per l'account di servizio worker Dataflow.

Concedi ruoli e accesso all'account di servizio worker Dataflow

In questa sezione, concedi i ruoli richiesti al worker Dataflow come mostrato nella tabella seguente.

Ruolo	Percorso	Finalità
Amministratore Dataflow	roles/dataflow.worker	Abilita l'account di servizio in modo che agisca come Dataflow amministratore.
Worker Dataflow	roles/dataflow.worker	Abilita l'account di servizio in modo che agisca come Dataflow worker.
Amministratore oggetti Storage	roles/storage.objectAdmin	Abilita l'account di servizio per accedere a Cloud Storage utilizzato da Dataflow per i file temporanei.
Editore Pub/Sub	roles/pubsub.publisher	Abilita l'account di servizio per pubblicare i messaggi non riusciti in Argomento messaggi non recapitabili Pub/Sub.
Sottoscrittore Pub/Sub	roles/pubsub.subscriber	Abilita l'account di servizio per accedere all'abbonamento di input.
Visualizzatore Pub/Sub	roles/pubsub.viewer	Abilita l'account di servizio per visualizzare l'abbonamento.
Funzione di accesso ai secret di Secret Manager	roles/secretmanager.secretAccessor	Abilita l'account di servizio per accedere al secret che contiene Token HEC Splunk.

1. In Cloud Shell, concedi il servizio worker Dataflow l'amministratore Dataflow e il worker Dataflow ruoli necessari a questo account per eseguire il job Dataflow le attività operative e di amministrazione:

   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. Concedi all'account di servizio worker Dataflow l'accesso in visualizzazione e consumare messaggi dalla sottoscrizione di input Pub/Sub:

   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. Concedi all'account di servizio worker Dataflow l'accesso per pubblicare eventuali messaggi non riusciti nell'argomento Pub/Sub non elaborato:

   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. Concedi all'account di servizio worker Dataflow l'accesso al Secret del token HEC Splunk 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. Concedi all'account di servizio worker Dataflow di leggere e scrivere al bucket Cloud Storage che deve essere utilizzato Job Dataflow per i file temporanei:

   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”
   

esegui il deployment della pipeline Dataflow

1. In Cloud Shell, imposta la seguente variabile di ambiente per URL Splunk HEC:

   export SPLUNK_HEC_URL=SPLUNK_HEC_URL
   

   Sostituisci la variabile SPLUNK_HEC_URL utilizzando il modulo protocol://host[:port], dove:

   • protocol è http o https.
   • host è il nome di dominio completo (FQDN) o IP della tua istanza Splunk HEC o, se disponi diverse istanze HEC, il carico HTTP(S) (o basato su DNS) associato con il bilanciatore del carico di rete passthrough esterno regionale.
   • port è il numero di porta HEC. È facoltativo e dipende dal tuo Splunk Configurazione endpoint HEC.

   Un esempio di input di URL Splunk HEC valido è https://splunk-hec.example.com:8088. Se invii dati a HEC su Piattaforma cloud Splunk, consulta Inviare dati a HEC su Splunk Cloud per determinare le porzioni sopra indicate (host e port) del tuo Splunk specifico URL HEC.

   Attenzione: mancata corrispondenza con il formato dell'URL Splunk HEC descritto in questo passaggio causerà errori di convalida dell'input di Dataflow i dati non verranno inviati all'endpoint Splunk HEC. Invece, i flussi di log verranno inviati all'argomento non elaborato.

   L'URL HEC Splunk non deve includere il percorso dell'endpoint HEC, ad esempio /services/collector. Da Pub/Sub a Splunk Il modello Dataflow al momento supporta solo Endpoint /services/collector per eventi in formato JSON aggiunge automaticamente quel percorso all'input dell'URL Splunk HEC. A per saperne di più sull'endpoint HEC, consulta la documentazione di Splunk per services/collector endpoint.

2. Eseguire il deployment della pipeline Dataflow utilizzando Pub/Sub al modello Dataflow di Splunk:

   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
   

   Sostituisci JOB_NAME con il formato del nome pubsub-to-splunk-date+"%Y%m%d-%H%M%S"

   I parametri facoltativi javascriptTextTransformGcsPath e javascriptTextTransformFunctionName specificano un valore funzione definita dall'utente di esempio: gs://splk-public/js/dataflow_udf_messages_replay.js. L'esempio La funzione definita dall'utente include esempi di codice per la trasformazione e la decodifica degli eventi utilizzata per riprodurre i caricamenti non riusciti. Per ulteriori informazioni Funzionalità definita dall'utente, consulta Trasformare gli eventi in corso con la funzione definita dall'utente.

3. Al termine del job della pipeline, trova il nuovo ID job nell'output, copia ID job e salvarlo. Inserisci questo ID job in un passaggio successivo.

Visualizza i log in Splunk

Sono necessari alcuni minuti perché i worker della pipeline Dataflow di cui è stato eseguito il provisioning e pronto a consegnare i log a Splunk HEC. Puoi verificare che i log vengono ricevuti e indicizzati correttamente in Splunk Enterprise o Splunk Cloud Interfaccia di ricerca della piattaforma. Per vedere il numero di log per tipo di monitoraggio risorsa:

1. In Splunk, apri Ricerca Splunk e Report.

2. Esegui la ricerca index=[MY_INDEX] | stats count by resource.type dove l'indice MY_INDEX è configurato per il tuo token HEC Splunk:

   

3. Se non vedi alcun evento, vedi Gestire gli errori di recapito.

Trasforma gli eventi in-flight con la funzione definita dall'utente

Il modello Dataflow da Pub/Sub a Splunk supporta una funzione JavaScript definita dall'utente per la trasformazione di eventi personalizzati, come l'aggiunta di nuovi campi impostando i metadati Splunk HEC in base agli eventi. La pipeline di cui hai eseguito il deployment utilizza questa UDF di esempio.

In questa sezione, devi prima modificare la funzione UDF di esempio per aggiungere un nuovo evento . Questo nuovo campo specifica il valore del campo sottoscrizione Pub/Sub come informazioni contestuali aggiuntive. Tu quindi aggiorna la pipeline Dataflow con la funzione definita dall'utente modificata.

Modifica la funzione definita dall'utente di esempio

1. In Cloud Shell, scarica il file JavaScript che contiene funzione UDF di esempio:

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

2. Nell'editor di testo di tua scelta, apri il file JavaScript, individua la campo event.inputSubscription, rimuovi il commento dalla riga e sostituisci splunk-dataflow-pipeline con INPUT_SUBSCRIPTION_NAME:

   event.inputSubscription = "INPUT_SUBSCRIPTION_NAME";
   

3. Salva il file.

4. Carica il file nel bucket Cloud Storage:

   gcloud storage cp ./dataflow_udf_messages_replay.js gs://PROJECT_ID-dataflow/js/
   

Aggiorna la pipeline Dataflow con la nuova funzione definita dall'utente

1. In Cloud Shell, arresta la pipeline utilizzando il comando opzione per assicurarti che i log già estratti da Pub/Sub non vengono persi:

   gcloud dataflow jobs drain JOB_ID --region=REGION
   

2. Eseguire il job della pipeline Dataflow con la funzione definita dall'utente aggiornata.

   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
   

   Sostituisci JOB_NAME con il formato del nome pubsub-to-splunk-date+"%Y%m%d-%H%M%S"

Gestire gli errori di recapito

Gli errori di consegna possono verificarsi a causa di errori di elaborazione degli eventi o di connessione a i modelli HEC di Splunk. In questa sezione, introdurremo l'errore di consegna per dimostrare il flusso di lavoro per gestione degli errorii. Imparerai inoltre a visualizzare e attivare la riconsegna dei messaggi non riusciti a Splunk.

Attiva errori di recapito

Per introdurre manualmente un errore di consegna in Splunk, procedi in uno dei seguenti modi:

• Se esegui una singola istanza, arresta il server Splunk per causare la connessione errori.
• Disattiva il token HEC pertinente dalla configurazione di input Splunk.

Risolvere i problemi relativi ai messaggi non riusciti

Per esaminare un messaggio di errore, puoi utilizzare la console Google Cloud:

1. Nella console Google Cloud, vai alla Abbonamenti Pub/Sub.

   Vai alle sottoscrizioni Pub/Sub

2. Fai clic sulla sottoscrizione non elaborata che hai creato. Se hai utilizzato la versione precedente Ad esempio, il nome della sottoscrizione è projects/PROJECT_ID/subscriptions/DEAD_LETTER_SUBSCRIPTION_NAME.

3. Per aprire il visualizzatore dei messaggi, fai clic su Visualizza messaggi.

4. Per visualizzare i messaggi, fai clic su Pull e assicurati di lasciare Abilita conferma messaggi cancellati.

5. Controlla i messaggi con errori. Presta attenzione a quanto segue:

   • Payload dell'evento Splunk nella colonna Message body.
   • Il messaggio di errore nella colonna attribute.errorMessage.
   • Il timestamp dell'errore nella colonna attribute.timestamp.

Il seguente screenshot mostra un esempio di messaggio di errore che ricevi se l'endpoint HEC di Splunk è temporaneamente inattivo o non è raggiungibile. Nota che il testo dell'attributo errorMessage è The target server failed to respond. Il messaggio mostra anche il timestamp associato a ciascun errore. Tu puoi utilizzare questo timestamp per risolvere la causa principale dell'errore.

Riproduci di nuovo i messaggi non riusciti

In questa sezione, devi riavviare il server Splunk o abilitare Splunk HEC per correggere l'errore di recapito. Puoi quindi riprodurre i video non elaborati messaggi.

1. In Splunk, utilizza uno dei seguenti metodi per ripristinare la connessione a Google Cloud:

   • Se hai arrestato il server Splunk, riavvia il server.
   • Se hai disabilitato l'endpoint HEC Splunk nella Attivare gli errori di recapito verifica che l'endpoint Splunk HEC sia ora operativo.

2. Acquisisci uno snapshot dell'abbonamento non elaborato in Cloud Shell. prima di rielaborare i messaggi in questa sottoscrizione. L'istantanea previene la perdita dei messaggi se una configurazione .

   gcloud pubsub snapshots create SNAPSHOT_NAME \
   --subscription=DEAD_LETTER_SUBSCRIPTION_NAME
   

   Sostituisci SNAPSHOT_NAME con un nome utile per identificare lo snapshot, ad esempio dead-letter-snapshot-date+"%Y%m%d-%H%M%S.

3. Usa il modello Pub/Sub per Splunk Dataflow per e creare una pipeline da Pub/Sub a Pub/Sub. La utilizza un altro job Dataflow per trasferire i messaggi dalla sottoscrizione non elaborata all'argomento di input.

   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. Copia l'ID job Dataflow dall'output comando e salvalo per un secondo momento. Dovrai inserire questo ID job come REPLAY_JOB_ID quando svuota il tuo job Dataflow.

5. Nella console Google Cloud, vai alla Abbonamenti Pub/Sub.

   Vai alle sottoscrizioni Pub/Sub

6. Seleziona la sottoscrizione non elaborata. Verifica che l'opzione Messaggio non agganciato conteggio è sceso a 0, come mostrato nello screenshot seguente.

   

7. In Cloud Shell, svuota il job Dataflow creato:

   gcloud dataflow jobs drain REPLAY_JOB_ID --region=REGION
   

   Sostituisci REPLAY_JOB_ID con ID job Dataflow salvato in precedenza.

Quando i messaggi vengono trasferiti all'argomento di input originale, La pipeline Dataflow preleva automaticamente i messaggi non riusciti e li invia nuovamente a Splunk.

Conferma i messaggi in Splunk

1. Per verificare che i messaggi siano stati recapitati di nuovo, apri in Splunk Ricerca Splunk e Report.

2. Esegui una ricerca per delivery_attempts > 1. Si tratta di un campo speciale una funzione definita dall'utente di esempio viene aggiunta a ogni evento per tenere traccia del numero di tentativi di recapito. Marca assicurati di ampliare l'intervallo di tempo della ricerca in modo da includere gli eventi avvenuta in passato, perché il timestamp dell'evento corrisponde all'ora originale quando vengono create, non in fase di indicizzazione.

Nello screenshot seguente, i due messaggi per cui l'errore inizialmente non è riuscito sono ora pubblicati e indicizzati correttamente in Splunk con il timestamp corretto.

Tieni presente che il valore del campo insertId è uguale a quello visualizzato nella i messaggi non riusciti quando visualizzi la sottoscrizione non elaborata. Il campo insertId è un identificatore univoco che Cloud Logging assegna al voce di log originale... insertId compare anche in Pub/Sub corpo del messaggio.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse usata in questa architettura di riferimento, elimina il progetto che contiene di risorse o di mantenere il progetto ed eliminare le singole risorse.

Elimina il sink a livello di organizzazione

• Utilizza il comando seguente per eliminare il sink di log a livello di organizzazione:

  gcloud logging sinks delete ORGANIZATION_SINK_NAME --organization=ORGANIZATION_ID
  

Elimina il progetto

Una volta eliminato il sink di log, puoi procedere con l'eliminazione delle risorse create per ricevere ed esportare i log. Il modo più semplice è eliminare il progetto che hai creato per l'architettura di riferimento.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:
• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.
1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

• Per un elenco completo di Dataflow e Splunk da Pub/Sub i parametri del modello, consulta Da Pub/Sub a Dataflow Splunk documentazione.
• Per i modelli Terraform corrispondenti che ti aiuteranno a eseguire il deployment di questo riferimento architettura, consulta terraform-splunk-log-export GitHub di ASL. Include una dashboard di Cloud Monitoring predefinita il monitoraggio della pipeline Splunk Dataflow.
• Per maggiori dettagli sulle metriche personalizzate di Splunk Dataflow e per aiutarti a monitorare e risolvere i problemi di Splunk Pipeline Dataflow, consulta questo blog New observability (Nuova osservabilità) per i flussi di dati Splunk Dataflow pipeline di dati.
• Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.