Esegui il deployment dello streaming dei log da Google Cloud a Splunk

Last reviewed 2024-10-24 UTC

Questo documento descrive come implementare un meccanismo di esportazione per eseguire lo streaming dei log dalle risorse Google Cloud a Splunk. Si presume che tu abbia già letto la corrispondente architettura di riferimento per questo caso d'uso.

Queste istruzioni sono rivolte agli amministratori di operazioni e sicurezza che vogliono eseguire lo streaming dei log da Google Cloud a Splunk. Devi conoscere Splunk e Splunk HTTP Event Collector (HEC) per utilizzare queste istruzioni per operazioni IT o casi d'uso di sicurezza. Sebbene non sia obbligatorio, è utile conoscere le pipeline di Dataflow, Pub/Sub, Cloud Logging, Identity and Access Management e Cloud Storage per questo deployment.

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

Architettura

Il seguente diagramma mostra l'architettura di riferimento e dimostra come i dati dei log passano 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 una sottoscrizione per i log e li inoltra alla pipeline Dataflow principale. La pipeline Dataflow principale è una pipeline di elaborazione di flussi di dati da Pub/Sub a Splunk che estrae i log dalla sottoscrizione Pub/Sub e li invia a Splunk. Parallela alla pipeline Dataflow principale, la pipeline Dataflow secondaria è una pipeline di streaming Pub/Sub a Pub/Sub per riprodurre i messaggi in caso di mancata consegna. Al termine della procedura, Splunk Enterprise o la piattaforma Splunk Cloud agisce come endpoint HEC e riceve i log per ulteriori analisi. Per maggiori dettagli, consulta la sezione Architettura dell'architettura di riferimento.

Per eseguire il deployment di questa architettura di riferimento, svolgi 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-flight utilizzando le funzioni definite dall'utente (UDF) all'interno della pipeline Splunk Dataflow.
• Gestisci gli errori di importazione per evitare la perdita di dati a causa di 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:

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

Apri un progetto, abilita la fatturazione e attiva 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. Make sure that billing is enabled for your Google Cloud project.

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

   Enable the APIs

Concedi ruoli IAM

Nella console Google Cloud, assicurati di disporre delle seguenti autorizzazioni di Identity and Access Management (IAM) 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	Logs Configuration Writer (roles/logging.configWriter)	Organizzazione
compute.networks.* compute.routers.* compute.firewalls.* networkservices.*	Amministratore rete Compute (roles/compute.networkAdmin) Amministratore della sicurezza di Compute (roles/compute.securityAdmin)	Progetto
secretmanager.*	Amministratore di Secret Manager (roles/secretmanager.admin)	Progetto

Se i ruoli IAM predefiniti non includono autorizzazioni sufficienti per svolgere le tue funzioni, crea un ruolo personalizzato. Un ruolo personalizzato ti offre l'accesso di cui hai bisogno e ti aiuta a seguire il principio del privilegio minimo.

Nota: per creare il sink di log aggregati a livello di organizzazione, devi disporre del ruolo Editor configurazione log assegnato a livello di gerarchia dell'organizzazione. Se non disponi dell'accesso per modificare le autorizzazioni a livello di organizzazione, chiedi all'amministratore dell'organizzazione Google Cloud di creare l'emissario di log a livello di organizzazione per te. Per ulteriori 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 Cloud Shell attiva:

   gcloud config set project PROJECT_ID
   

   Sostituisci PROJECT_ID con l'ID progetto.

Configurare una rete sicura

In questo passaggio, configuri la rete sicura 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 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) dei 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 crei l'emissario di 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 relativa sottoscrizione come nuova destinazione di destinazione dei 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 dell'abbonamento Pub/Sub alla destinazione di destinazione dei sink di log

2. Crea lo 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 della destinazione 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 la sink di log a livello di organizzazione includa tutti i log di tutte le sottocartelle e tutti i progetti.
   • Il flag --log-filter specifica i log da instradare. In questo esempio, escludi i log delle operazioni di Dataflow specificamente per il progetto PROJECT_ID, perché la pipeline Dataflow di esportazione dei log genera più log durante l'elaborazione degli stessi. Il filtro impedisce alla pipeline di esportare i propri log, evitando un ciclo potenzialmente esponenziale. L'output include un account di servizio sotto forma di o#####-####@gcp-sa-logging.iam.gserviceaccount.com.

3. Concedi il ruolo IAM Publisher Pub/Sub all'account del servizio di 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 tuo sink di log.

Creare un argomento messaggi non recapitabili

Per evitare potenziali perdite di dati che si verificano quando la consegna di un messaggio non va a buon fine, devi creare un argomento per la posta in arrivo Pub/Sub e la sottoscrizione corrispondente. Il messaggio con errore viene archiviato nell'argomento per i messaggi inutilizzati finché un operatore o un esperto di affidabilità del sito non può esaminare e correggere l'errore. Per ulteriori informazioni, consulta la sezione Riproduci i messaggi non riusciti dell'architettura di riferimento.

• In Cloud Shell, crea un argomento e una sottoscrizione Pub/Sub per la posta in arrivo per evitare 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: il nome dell'argomento Pub/Sub che sarà l'argomento messaggi non recapitabili
  • DEAD_LETTER_SUBSCRIPTION_NAME: il nome dell'abbonamento Pub/Sub per l&#argomento messaggi non recapitabili

Configurare un endpoint HEC di Splunk

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

Configurare l'HEC di Splunk

1. Se non hai ancora un endpoint HEC di Splunk, consulta la documentazione di Splunk per scoprire come configurare un HEC di Splunk. Splunk HEC viene eseguito sul servizio Splunk Cloud Platform o sulla tua istanza Splunk Enterprise. Mantieni disattivata l'opzione di conferma dell'indice HEC di Splunk, poiché non è supportata da Splunk Dataflow.
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 chiamato splunk-hec-token-plaintext.txt.

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

Memorizza il token HEC di Splunk in Secret Manager

In questo passaggio, crei un secret e una singola versione del secret sottostante in cui memorizzare il valore del token HEC di Splunk.

Nota: Secret Manager è supportato a partire dalla versione del modello 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 segreto contenente 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, poiché 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 (impostate con il flag --max-workers). Per ulteriori informazioni su come controllare e richiedere un aumento delle quote, consulta Quote di allocazione.

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

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

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

1. Imposta i valori per il tipo di macchina e il numero di macchine. Per calcolare i valori appropriati per il tuo ambiente cloud, consulta le sezioni Tipo di macchina e Numero di 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 Parallelis 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 di progettazione per l'ottimizzazione di prestazioni e costi dell'architettura di riferimento.

Esportare i log utilizzando la pipeline Dataflow

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

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

La pipeline invia 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:

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

   Il bucket Cloud Storage che hai appena creato è il luogo in cui il job Dataflow gestisce 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 i ruoli e l'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à
Dataflow Admin	roles/dataflow.worker	Consenti all'account di servizio di agire come amministratore di Dataflow.
Dataflow Worker	roles/dataflow.worker	Consenti all'account di servizio di agire come worker Dataflow.
Storage Object Admin	roles/storage.objectAdmin	Abilitare l'account di servizio per accedere al bucket Cloud Storage utilizzato da Dataflow per i file temporanei.
Pub/Sub Publisher	roles/pubsub.publisher	Consenti all'account di servizio di pubblicare i messaggi non riusciti nell'argomento messaggi non recapitabili Pub/Sub.
Pub/Sub Subscriber	roles/pubsub.subscriber	Consenti all'account di servizio di accedere all'abbonamento inserito.
Pub/Sub Viewer	roles/pubsub.viewer	Consenti all'account di servizio di visualizzare l'abbonamento.
Secret Manager Secret Accessor	roles/secretmanager.secretAccessor	Consenti all'account di servizio di accedere al secret contenente il token HEC di Splunk.

1. In Cloud Shell, concedi all'account di servizio worker Dataflow i ruoli Dataflow Admin e Dataflow Worker di cui questo account ha bisogno per eseguire operazioni e attività di amministrazione dei job 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 del worker Dataflow l'accesso per visualizzare e utilizzare i messaggi dall'abbonamento 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 del worker Dataflow l'accesso per pubblicare eventuali messaggi non riusciti nell'argomento non elaborato Pub/Sub:

   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 da utilizzare dal job Dataflow per l'organizzazione dei 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 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 dell'istanza HEC di Splunk o, se hai più istanze HEC, il 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 dell'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 sopra indicate dell'URL HEC di Splunk specifico.

   Attenzione: se non corrispondi al formato dell'URL HEC di Splunk descritto in questo passaggio, si verificheranno errori di convalida dell'input di Dataflow e i dati non verranno inviati all'endpoint HEC di Splunk. I log streaming verranno inviati all'argomento non elaborato.

   L'URL HEC di Splunk non deve includere il percorso dell'endpoint HEC, ad esempio/services/collector. Al momento, il modello Dataflow Pub/Sub-Splunk 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 approfondire l'endpoint HEC, consulta la documentazione di Splunk relativa all'endpoint 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 UDF di esempio disponibile pubblicamente: gs://splk-public/js/dataflow_udf_messages_replay.js. La UDF di esempio include esempi di codice per la logica di decodifica e trasformazione degli eventi che utilizzi per riprodurre i caricamenti non riusciti. Per ulteriori informazioni sulle funzioni UDF, consulta Trasformare gli eventi in transito con le funzioni UDF.

3. Al termine del job della pipeline, individua il nuovo ID job nell'output, copialo e salvalo. Inserisci questo ID job in un passaggio successivo.

Visualizzare i log in Splunk

Sono necessari alcuni minuti per eseguire il provisioning dei worker della pipeline Dataflow e per prepararli a inviare i log a Splunk HEC. Puoi verificare che i log vengano ricevuti e indicizzati correttamente nell'interfaccia di ricerca della piattaforma Splunk Enterprise o Splunk Cloud. Per visualizzare il numero di log per tipo di risorsa monitorata:

1. In Splunk, apri Ricerca e reporting di Splunk.

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

   

3. Se non vedi eventi, consulta Gestire gli errori di importazione.

Trasforma gli eventi in-flight con le UDF

Il modello Dataflow Pub/Sub to Splunk supporta una UDF JavaScript per la trasformazione di eventi personalizzati, ad esempio l'aggiunta di nuovi campi o l'impostazione dei metadati HEC di Splunk in base agli eventi. La pipeline di cui hai eseguito il deployment utilizza questa UDF di esempio.

In questa sezione, modifichi prima la funzione UDF di esempio per aggiungere un nuovo campo evento. Questo nuovo campo specifica il valore dell'abbonamento Pub/Sub di origine come informazioni contestuali aggiuntive. Poi, aggiorna la pipeline Dataflow con la UDF modificata.

Modifica la UDF di esempio

1. In Cloud Shell, scarica il file JavaScript contenente 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:

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

Aggiorna la pipeline Dataflow con la nuova UDF

1. In Cloud Shell, interrompi la pipeline utilizzando l'opzione Svuota per assicurarti che i log già estratti da Pub/Sub non vadano persi:

   gcloud dataflow jobs drain JOB_ID --region=REGION
   

2. Esegui il job della pipeline Dataflow con la UDF 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 importazione possono verificarsi a causa di errori nell'elaborazione degli eventi o nella connessione all'HEC di Splunk. In questa sezione viene introdotto un errore di importazione per dimostrare il flusso di lavoro di gestione degli errori. Inoltre, scoprirai come visualizzare e attivare il nuovo invio dei messaggi non riusciti a Splunk.

Attivare i fallimenti di pubblicazione

Per introdurre manualmente un errore di importazione 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 riusciti

Per esaminare un messaggio non riuscito, puoi utilizzare la console Google Cloud:

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

   Vai ad Abbonamenti Pub/Sub

2. Fai clic sull'abbonamento non elaborato che hai creato. Se hai utilizzato l'esempio precedente, il nome dell'abbonamento è: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, assicurandoti di lasciare deselezionata l'opzione Abilita messaggi di conferma.

5. Controlla i messaggi non riusciti. Presta attenzione a quanto segue:

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

Lo screenshot seguente mostra un esempio di messaggio di errore che ricevi se l'endpoint HEC di Splunk è temporaneamente non disponibile o non raggiungibile. Tieni presente che il testo dell'attributo errorMessage è The target server failed to respond. Il messaggio mostra anche il timestamp associato a ciascun errore. Puoi utilizzare questo timestamp per risolvere il problema alla radice dell'errore.

Riproduci di nuovo i messaggi non riusciti

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

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

   • Se hai interrotto il server Splunk, riavvialo.
   • Se hai disattivato l'endpoint HEC di Splunk nella sezione Attivare gli errori di invio, verifica che l'endpoint HEC di Splunk sia ora operativo.

2. In Cloud Shell, acquisisci uno snapshot dell'abbonamento non elaborato prima di rielaborare i messaggi in questo abbonamento. Lo snapshot impedisce la perdita di 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 Pub/Sub to Splunk per creare una pipeline Pub/Sub to 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=n2-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 utilizzarlo in un secondo momento. Inserisci questo ID job come REPLAY_JOB_ID quando svuoti il job Dataflow.

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

   Vai ad Abbonamenti Pub/Sub

6. Seleziona l'abbonamento non elaborato. Verifica che il grafico Conteggio messaggi non confermati sia pari 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 di Dataflow principale recupera automaticamente i messaggi non riusciti e li recapita a Splunk.

Confermare i messaggi in Splunk

1. Per verificare che i messaggi siano stati inviati di nuovo, in Splunk apri Splunk Search & Reporting.

2. Esegui una ricerca per delivery_attempts > 1. Si tratta di un campo speciale che la UDF di esempio aggiunge a ogni evento per monitorare il numero di tentativi di invio. Assicurati di espandere l'intervallo di tempo di ricerca in modo da includere gli eventi che potrebbero essere stati registrati in passato, perché il timestamp dell'evento corrisponde all'ora originale di creazione, non all'ora di indicizzazione.

Nello screenshot seguente, i due messaggi che inizialmente non sono riusciti ora sono stati recapitati e indicizzati correttamente in Splunk con il timestamp corretto.

Tieni presente che il valore del campo insertId corrisponde a quello visualizzato nei messaggi di errore quando visualizzi l'abbonamento non elaborato. Il campo insertId è un identificatore univoco assegnato da Cloud Logging 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 contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina l'emissario a livello di organizzazione

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

  gcloud logging sinks delete ORGANIZATION_SINK_NAME --organization=ORGANIZATION_ID
  

Elimina il progetto

Dopo aver 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à descritte in questo documento, quando lo elimini elimini anche tutto il 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 appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi

• Per un elenco completo dei parametri del modello Pub/Sub to Splunk Dataflow, consulta la documentazione di Pub/Sub to Splunk Dataflow.
• 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 di Cloud Monitoring predefinita per monitorare la pipeline Splunk Dataflow.
• 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 streaming di Splunk Dataflow.
• Per altre architetture di riferimento, diagrammi e best practice, visita il Cloud Architecture Center.