Esegui il deployment del flusso 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 dalle risorse Google Cloud a Splunk. Presuppone che tu abbia già letto l'architettura di riferimento corrispondente per questo caso d'uso.

Queste istruzioni sono rivolte agli amministratori di operazioni e sicurezza che vogliono trasmettere i log da Google Cloud a Splunk. È necessario conoscere Splunk e Splunk HTTP Event Collector (HEC) quando utilizzi queste istruzioni per le operazioni IT o i casi d'uso di sicurezza. Sebbene non sia obbligatoria, la familiarità con le pipeline 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 il repository GitHub di terraform-splunk-log-export.

Architettura

Il seguente diagramma mostra l'architettura di riferimento e mostra il flusso di dati dei log da Google Cloud a Splunk.

Come mostrato nel diagramma, Cloud Logging raccoglie i log in un sink di log a livello di organizzazione e li invia a Pub/Sub. Il servizio Pub/Sub crea un singolo argomento e sottoscrizione per i log e inoltra i log alla pipeline Dataflow principale. La pipeline Dataflow principale è una pipeline di flusso da Pub/Sub a Splunk che estrae i log dalla sottoscrizione Pub/Sub e li invia a Splunk. Parallelamente alla pipeline Dataflow principale, la pipeline Dataflow secondaria è una pipeline in modalità flusso da Pub/Sub a Pub/Sub per riprodurre i messaggi in caso di errore di distribuzione. Al termine del processo, Splunk Enterprise o Splunk Cloud Platform agisce come endpoint HEC e riceve i log per ulteriori analisi. Per ulteriori dettagli, consulta la sezione Architettura dell'architettura di riferimento.

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

• Eseguire le attività di configurazione.
• Crea un sink di log aggregato in un progetto dedicato.
• Crea un argomento messaggi non recapitabili.
• Configura un endpoint HEC di Splunk.
• Configura la capacità della pipeline Dataflow.
• Esporta i log in Splunk.
• Trasforma i log o gli eventi in corso utilizzando le funzioni definite dall'utente (UDF) 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 la tua 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 reti sicure.

Apri un progetto, abilita la fatturazione e attiva le API

1. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

   Nota: se non prevedi di conservare le risorse create in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

   Vai al selettore progetti

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 autorizzazioni IAM (Identity and Access Management) per le risorse dell'organizzazione e del progetto. Per ulteriori informazioni, consulta Concessione, modifica e revoca dell'accesso alle risorse.

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 eseguire le tue mansioni, crea un ruolo personalizzato. Un ruolo personalizzato ti dà l'accesso di cui hai bisogno e ti aiuta a seguire il principio del privilegio minimo.

Nota: per creare il sink di log aggregato a livello di organizzazione, devi avere assegnato il ruolo Writer configurazione log a livello di gerarchia dell'organizzazione. Se non hai accesso alla modifica delle autorizzazioni a livello di organizzazione, chiedi all'amministratore dell'organizzazione Google Cloud di creare il sink di log a livello di organizzazione per te. Per maggiori informazioni sul controllo dell'accesso di Cloud Logging, consulta Ruoli predefiniti di Cloud Logging.

Configura l'ambiente

1. Nella console Google Cloud, attiva Cloud Shell.

   Attiva 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 reti sicure

In questo passaggio, configurerai il networking sicuro prima di elaborare ed esportare i log in 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 questa rete

2. Crea una regola firewall per consentire alle macchine virtuali (VM) worker di Dataflow di 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 utilizzano 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 sulla 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 la relativa destinazione Pub/Sub, insieme alle autorizzazioni necessarie.

1. In Cloud Shell, crea un argomento Pub/Sub e la sottoscrizione associata 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 dell'argomento Pub/Sub da utilizzare come destinazione del sink di log
   • INPUT_SUBSCRIPTION_NAME: il nome della sottoscrizione Pub/Sub nella 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 nell'organizzazione
   • ORGANIZATION_ID: l'ID della tua organizzazione

   Il comando è costituito dai seguenti flag:

   • Il flag --organization specifica che si tratta di un sink di log a livello di organizzazione.
   • Il flag --include-children è obbligatorio e garantisce che il sink di log a livello di organizzazione includa tutti i log in tutte le sottocartelle e i progetti.
   • Il flag --log-filter specifica i log di cui eseguire il routing. In questo esempio, escludi i log delle operazioni di Dataflow appositamente per il progetto PROJECT_ID, poiché la pipeline di esportazione dei log genera più log mentre elabora i log. Il filtro impedisce alla pipeline di esportare i propri log, evitando un ciclo potenzialmente esponenziale. L'output include un account di servizio nel formato o#####-####@gcp-sa-logging.iam.gserviceaccount.com.

3. Concedi il ruolo IAM Publisher Pub/Sub all'account di servizio del sink di log nell'argomento Pub/Sub INPUT_TOPIC_NAME. Questo ruolo consente all'account di servizio del sink di log di pubblicare messaggi nell'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 evitare potenziali perdite di dati che si verificano quando un messaggio non viene recapitato, devi creare un argomento messaggi non recapitabili Pub/Sub e la sottoscrizione corrispondente. Il messaggio non riuscito viene archiviato nell'argomento messaggi non recapitabili finché un operatore o un Site Reliability Engineer non riesce a esaminare e correggere l'errore. Per ulteriori informazioni, consulta la sezione Ripetere i messaggi non riusciti dell'architettura di riferimento.

• In Cloud Shell, crea un argomento e una sottoscrizione non recapitabili Pub/Sub per prevenire la perdita di dati archiviando i 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: nome dell'argomento Pub/Sub che sarà l'argomento messaggi non recapitabili
  • DEAD_LETTER_SUBSCRIPTION_NAME: nome della sottoscrizione Pub/Sub per l'argomento messaggi non recapitabili

Configurare un endpoint HEC Splunk

Nelle procedure seguenti, configurerai un endpoint HEC di Splunk e archivi il token HEC appena creato come secret in Secret Manager. Quando esegui il deployment della pipeline Dataflow di Splunk, devi fornire sia l'URL endpoint sia il token.

Configurare l'HEC di Splunk

1. Se non disponi già di un endpoint HEC Splunk, consulta la documentazione di Splunk per scoprire come configurare un endpoint HEC di Splunk. HEC di Splunk viene eseguito sul servizio Splunk Cloud Platform o sulla tua istanza Splunk Enterprise.
2. In Splunk, dopo aver creato un token HEC di Splunk, copia il valore del token.
3. In Cloud Shell, salva il valore del token HEC di Splunk in un file temporaneo denominato splunk-hec-token-plaintext.txt.

Nota: per l'alta disponibilità e per scoprire come scalare con traffico ad alto volume, consulta la documentazione di Splunk su come scalare HEC distribuendo il carico a più nodi utilizzando un bilanciatore del carico HTTP(S).

Archivia il token HEC di Splunk in Secret Manager

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

Nota: Secret Manager è supportato a partire dalla versione Da Pub/Sub a Splunk Dataflow 2022-03-14-00_RC00. Questa architettura di riferimento utilizza la versione più recente di questo modello.

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

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

   Per ulteriori informazioni sui criteri di replica per i secret, consulta Scegliere un 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 disporre di una quota di CPU e IP sufficiente nella regione scelta per eseguire il provisioning del numero massimo possibile di VM Dataflow (impostata con il flag --max-workers). Per ulteriori informazioni su come verificare e richiedere un aumento delle quote, consulta Quote di allocazione.

La seguente tabella riassume le best practice generali consigliate per la configurazione delle impostazioni della capacità della pipeline Dataflow:

Impostazione	Best practice generale
Flag --worker-machine-type	Imposta le dimensioni della macchina di riferimento n1-standard-4 per ottenere il miglior rapporto costo/prestazioni
Flag --max-workers	Imposta il numero massimo di worker necessari per gestire il picco di EPS previsto per i tuoi calcoli
Parametro parallelism	Impostato su 2 x vCPU/worker x sul numero massimo di worker per massimizzare il numero di connessioni Splunk HEC parallele
batchCount parametro	Impostato su 10-50 eventi/richiesta per i log, a condizione che sia accettabile un ritardo massimo di buffering di due secondi

Ricorda di utilizzare valori e calcoli univoci quando esegui il deployment di questa architettura di riferimento nel tuo ambiente.

1. Imposta i valori per tipo di macchina e conteggio macchine. Per calcolare i valori appropriati per il tuo ambiente cloud, consulta le sezioni Tipo di macchina e Conteggio macchine dell'architettura di riferimento.

   DATAFLOW_MACHINE_TYPE
   DATAFLOW_MACHINE_COUNT
   

2. Imposta i valori per il parallelismo e il conteggio batch di Dataflow. Per calcolare i valori appropriati per il tuo ambiente cloud, consulta le sezioni Parallelismo e Conteggio batch dell'architettura di riferimento.

   JOB_PARALLELISM
   JOB_BATCH_COUNT
   

Per ulteriori informazioni su come calcolare i parametri di capacità della pipeline Dataflow, consulta la sezione Considerazioni sulla progettazione dell'ottimizzazione delle prestazioni e dei costi dell'architettura di riferimento.

Esporta i log utilizzando la pipeline Dataflow

In questa sezione, eseguirai il deployment della pipeline Dataflow seguendo questi passaggi:

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

La pipeline consegna i messaggi di log di Google Cloud all'HEC di Splunk.

Crea 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:

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

   Nel bucket Cloud Storage appena creato si trova il job Dataflow in cui vengono inseriti i file temporanei.

2. In Cloud Shell, crea un account di servizio per i 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 vuoi utilizzare per l'account di servizio worker Dataflow.

Concedi ruoli e accesso all'account di servizio worker Dataflow

In questa sezione, concedi i ruoli richiesti all'account di servizio worker Dataflow come mostrato nella tabella seguente.

Ruolo	Percorso	Finalità
Amministratore Dataflow	roles/dataflow.worker	Abilitare l'account di servizio in modo che agisca come amministratore Dataflow.
Worker Dataflow	roles/dataflow.worker	Abilitare l'account di servizio in modo che agisca come worker Dataflow.
Amministratore oggetti Storage	roles/storage.objectAdmin	Abilitare l'account di servizio per accedere al bucket Cloud Storage utilizzato da Dataflow per i file di gestione temporanea.
Publisher Pub/Sub	roles/pubsub.publisher	Abilita l'account di servizio per pubblicare i messaggi non riusciti nell'argomento messaggi non recapitabili Pub/Sub.
Sottoscrittore Pub/Sub	roles/pubsub.subscriber	Abilita l'account di servizio per accedere alla sottoscrizione 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	Abilitare l'account di servizio per accedere al secret che contiene il token HEC di Splunk.

1. In Cloud Shell, concedi all'account di servizio worker Dataflow i ruoli Amministratore Dataflow e Worker Dataflow necessari a questo account per eseguire le operazioni del job e le attività di amministrazione di Dataflow:

   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 per visualizzare e utilizzare 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 tutti i 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 di 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 l'accesso in lettura e scrittura al bucket Cloud Storage che verrà utilizzato dal job Dataflow per i file di gestione temporanea:

   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 l'URL HEC di Splunk:

   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 l'indirizzo IP della tua istanza Splunk HEC o, se disponi di più istanze HEC, del bilanciatore del carico HTTP(S) (o basato su DNS) associato.
   • port è il numero di porta HEC. È facoltativo e dipende dalla configurazione dell'endpoint HEC di Splunk.

   Un esempio di input di URL HEC di Splunk valido è https://splunk-hec.example.com:8088. Se invii dati a HEC sulla piattaforma Splunk Cloud, consulta Inviare dati a HEC su Splunk Cloud per determinare le parti host e port riportate sopra del tuo URL Splunk HEC specifico.

   Attenzione: la mancata corrispondenza al formato dell'URL HEC di Splunk descritto in questo passaggio causerà errori di convalida dell'input di Dataflow e i dati non verranno consegnati all'endpoint HEC di Splunk. Invece, i log di flusso dei dati verranno inviati all'argomento non elaborato.

   L'URL HEC di Splunk non deve includere il percorso dell'endpoint HEC, ad esempio /services/collector. Il modello Dataflow da Pub/Sub a Splunk al momento supporta solo l'endpoint /services/collector per gli eventi in formato JSON e aggiunge automaticamente questo percorso all'input dell'URL HEC di Splunk. Per scoprire di più sull'endpoint HEC, consulta la documentazione di Splunk per endpoint di services/collector.

2. Esegui il deployment della pipeline Dataflow utilizzando il modello Dataflow da Pub/Sub a 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 una funzione definita dall'utente di esempio di esempio disponibile pubblicamente: gs://splk-public/js/dataflow_udf_messages_replay.js. La funzione definita dall'utente di esempio include esempi di codice per la trasformazione e la decodifica degli eventi che utilizzi per riprodurre le distribuzioni non riuscite. Per ulteriori informazioni sulla funzione 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 l'ID job e salvalo. Potrai inserire questo ID job in un passaggio successivo.

Visualizza i log in Splunk

Sono necessari alcuni minuti per eseguire il provisioning dei worker di pipeline Dataflow e renderli pronti per consegnare i log a Splunk HEC. Puoi confermare che i log vengono ricevuti e indicizzati correttamente nell'interfaccia di ricerca di Splunk Enterprise o Splunk Cloud Platform. Per visualizzare il numero di log per tipo di risorsa monitorata:

1. In Splunk, apri Splunk Search & Reporting.

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

   

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

Trasformare gli eventi in corso con le funzioni definite 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 o l'impostazione dei metadati HEC Splunk per evento. La pipeline di cui hai eseguito il deployment utilizza questa funzione definita dall'utente di esempio.

In questa sezione, dovrai prima modificare la funzione funzione definita dall'utente di esempio per aggiungere un nuovo campo evento. Questo nuovo campo specifica il valore della sottoscrizione Pub/Sub di origine come informazioni contestuali aggiuntive. 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 la funzione UDF di esempio:

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

2. Nell'editor di testo che preferisci, apri il file JavaScript, individua il 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:

   gsutil 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 l'opzione di svuotamento per assicurarti che i log di cui è già stato eseguito il pull da Pub/Sub non vengano persi:

   gcloud dataflow jobs drain JOB_ID --region=REGION
   

2. Esegui 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 consegna

Gli errori di consegna possono verificarsi a causa di errori durante l'elaborazione degli eventi o la connessione a HEC di Splunk. In questa sezione introduci la mancata consegna per dimostrare il flusso di lavoro di gestione degli errori. Scoprirai anche come visualizzare e attivare il nuovo recapito dei messaggi non riusciti a Splunk.

Attiva errori di pubblicazione

Per introdurre manualmente un errore di recapito in Splunk, esegui una delle seguenti operazioni:

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

Risolvere i problemi relativi ai messaggi non inviati

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

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

   Vai alle sottoscrizioni Pub/Sub

2. Fai clic sulla sottoscrizione non elaborata che hai creato. Se hai utilizzato l'esempio precedente, 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 deselezionata l'opzione Abilita messaggi ACK.

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 visualizzato se l'endpoint HEC di Splunk è temporaneamente non disponibile o non raggiungibile. Nota che il testo dell'attributo errorMessage è The target server failed to respond. Il messaggio mostra anche il timestamp associato a ogni errore. Puoi utilizzare questo timestamp per risolvere la causa principale dell'errore.

Riprodurre di nuovo i messaggi con errori

In questa sezione, devi riavviare il server Splunk o attivare l'endpoint HEC Splunk per correggere l'errore di consegna. Puoi quindi riprodurre di nuovo i messaggi non elaborati.

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

   • Se hai arrestato il server Splunk, riavvialo.
   • Se hai disabilitato l'endpoint HEC di Splunk nella sezione Errori di pubblicazione dei trigger, verifica che l'endpoint HEC di Splunk sia in funzione.

2. In Cloud Shell, acquisisci uno snapshot della sottoscrizione non elaborata prima di rielaborare i messaggi in questa sottoscrizione. Lo snapshot impedisce la perdita dei messaggi in caso di errore di configurazione imprevisto.

   gcloud pubsub snapshots create SNAPSHOT_NAME \
   --subscription=DEAD_LETTER_SUBSCRIPTION_NAME
   

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

3. Utilizza il modello Dataflow da Pub/Sub a Splunk per creare una pipeline da Pub/Sub a Pub/Sub. La pipeline 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. Per lo svuotamento del job Dataflow, inserirai questo ID job come REPLAY_JOB_ID.

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

   Vai alle sottoscrizioni Pub/Sub

6. Seleziona la sottoscrizione non elaborata. Verifica che il grafico Numero di messaggi non ACK sia inferiore a 0, come mostrato nello screenshot seguente.

   

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

   gcloud dataflow jobs drain REPLAY_JOB_ID --region=REGION
   

   Sostituisci REPLAY_JOB_ID con l'ID job Dataflow che hai salvato in precedenza.

Quando i messaggi vengono trasferiti nuovamente all'argomento di input originale, la pipeline principale di Dataflow raccoglie automaticamente i messaggi in errore e li reinvia a Splunk.

Conferma i messaggi in Splunk

1. Per confermare che i messaggi siano stati recapitati nuovamente, in Splunk apri Splunk Search & Reporting.

2. Esegui una ricerca di delivery_attempts > 1. Questo è un campo speciale che la funzione definita dall'utente di esempio aggiunge a ogni evento per monitorare il numero di tentativi di pubblicazione. Assicurati di espandere l'intervallo di tempo della ricerca in modo da includere gli eventi che possono essersi verificati in passato, poiché il timestamp dell'evento indica la data e l'ora di creazione originale, non quella dell'indicizzazione.

Nello screenshot seguente, i due messaggi inizialmente non riusciti vengono recapitati e indicizzati in Splunk con il timestamp corretto.

Tieni presente che il valore del campo insertId corrisponde a quello visualizzato nei messaggi con errori quando visualizzi la sottoscrizione non elaborata. Il campo insertId è un identificatore univoco che Cloud Logging assegna alla voce di log originale. insertId viene visualizzato anche nel corpo del messaggio Pub/Sub.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questa architettura di riferimento, elimina il progetto che le contiene oppure mantieni il progetto ed elimina 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 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 dei parametri dei modelli Dataflow da Pub/Sub a Splunk, consulta la documentazione di Dataflow da Pub/Sub a Splunk.
• Per i modelli Terraform corrispondenti che ti aiutano a eseguire il deployment di questa architettura di riferimento, consulta il repository GitHub di terraform-splunk-log-export. Include una dashboard predefinita di Cloud Monitoring per il monitoraggio della pipeline Dataflow di Splunk.
• Per ulteriori dettagli sulle metriche personalizzate e sul logging di Splunk Dataflow per aiutarti a monitorare e risolvere i problemi delle pipeline di Splunk Dataflow, consulta questo blog Nuove funzionalità di osservabilità per le pipeline di flusso di Splunk Dataflow.
• Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.