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

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

Architettura

Il seguente diagramma mostra l'architettura di riferimento e il modo in cui i dati di log fluiscono 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 singola 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 consegna a Splunk. Parallelamente alla pipeline Dataflow principale, la pipeline Dataflow secondaria è una pipeline di flusso da Pub/Sub a Pub/Sub per riprodurre i messaggi in caso di errore di consegna. 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à:

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

• 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 autorizzazioni 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 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 anche 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 per modificare le 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 ulteriori 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 una rete sicura

In questo passaggio devi configurare 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 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 la relativa destinazione Pub/Sub, insieme alle autorizzazioni necessarie.

1. In Cloud Shell, crea un argomento Pub/Sub e una 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 usare come destinazione del sink di log
   • INPUT_SUBSCRIPTION_NAME: il nome della 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 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 di tutte le sottocartelle e i progetti.
   • Il flag --log-filter specifica i log da instradare. In questo esempio, escludi i log delle operazioni di Dataflow specifici per il progetto PROJECT_ID, perché la pipeline di esportazione dei log di Dataflow genera più log durante l'elaborazione. 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 la potenziale perdita di dati che si verifica quando un messaggio non può essere consegnato, devi creare un argomento messaggi non recapitabili Pub/Sub e la corrispondente sottoscrizione. Il messaggio di errore viene archiviato nell'argomento messaggi non recapitabili fino a quando un operatore o un Site Reliability Engineer non possono analizzare 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 e una sottoscrizione Pub/Sub 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 della sottoscrizione Pub/Sub per l'argomento messaggi non recapitabili

Configura un endpoint Splunk HEC

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

Configurare Splunk HEC

1. Se non hai ancora un endpoint Splunk HEC, consulta la documentazione di Splunk per scoprire come configurare un endpoint Splunk. Splunk HEC viene eseguito sul servizio Splunk Cloud Platform o sulla tua istanza Splunk Enterprise.
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 a scalare con traffico elevato, 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 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 al modello Dataflow di Splunk 2022-03-14-00_RC00. Questa architettura di riferimento utilizza la versione più recente del 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 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 avere 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 maggiori informazioni su come controllare e richiedere un aumento delle quote, consulta Quote di allocazione.

La tabella seguente riassume le best practice generali consigliate per configurare 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 il picco di 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 HEC Splunk parallele
batchCount parametro	Imposta su 10-50 eventi/richiesta per i log, a condizione che il ritardo di buffering massimo di due secondi sia accettabile

Ricorda di utilizzare 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 conteggio delle macchine. Per calcolare i valori appropriati per il tuo ambiente cloud, consulta le sezioni Tipo di macchina e Conteggio macchina dell'architettura di riferimento.

   DATAFLOW_MACHINE_TYPE
   DATAFLOW_MACHINE_COUNT
   

2. Imposta i valori per il parallelismo e il conteggio dei batch di Dataflow. Per calcolare i valori appropriati per il tuo ambiente cloud, consulta le sezioni Parallelismo e Conteggio dei 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 per prestazioni e ottimizzazione 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 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:

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

   Il bucket Cloud Storage che hai appena creato è il luogo in cui il job Dataflow inserisce 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 temporanei.
Publisher Pub/Sub	roles/pubsub.publisher	Abilitare l'account di servizio per pubblicare messaggi non riusciti nell'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	Abilitare l'account di servizio per accedere al secret che contiene il token HEC 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 e le attività di amministrazione del 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 worker Dataflow l'accesso per visualizzare e utilizzare i 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 elaborati 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 l'accesso in lettura e scrittura al bucket Cloud Storage affinché venga utilizzato dal 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 l'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 l'indirizzo IP della tua istanza Splunk HEC oppure, se hai 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 Splunk di HeC.

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

   Attenzione: la mancata corrispondenza del formato di URL Splunk HEC descritto in questo passaggio causa errori di convalida dell'input di Dataflow e i dati non verranno inviati all'endpoint Splunk HEC. I log dei flussi di dati verranno invece inviati all'argomento non elaborato.

   L'URL HEC 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 il percorso all'input dell'URL Splunk HEC. Per saperne di più sull'endpoint HEC, consulta la documentazione di Splunk per services/collector endpoint.

2. Esegui il deployment della pipeline Dataflow usando il modello Dataflow di Pub/Sub:

   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 disponibile pubblicamente: gs://splk-public/js/dataflow_udf_messages_replay.js. La funzione definita dall'utente di esempio include esempi di codice per la logica di trasformazione e decodifica degli eventi che utilizzi per riprodurre le consegne non riuscite. Per ulteriori informazioni sulle funzioni definite 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. Inserisci questo ID job in un passaggio successivo.

Visualizza i log in Splunk

Il provisioning dei worker della pipeline Dataflow richiede alcuni minuti e sono pronti a consegnare i log a Splunk HEC. Puoi verificare che i log vengano ricevuti e indicizzati correttamente nell'interfaccia di ricerca di Splunk Enterprise o Splunk Cloud Platform. Per vedere il numero di log per tipo di risorsa monitorata:

1. In Splunk, apri Ricerca e report Splunk.

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

   

3. Se non viene visualizzato alcun evento, consulta Gestire gli errori di recapito.

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

Il modello Dataflow di Pub/Sub per Splunk supporta una funzione JavaScript definita dall'utente per la trasformazione di eventi personalizzati, come l'aggiunta di nuovi campi o l'impostazione di metadati HEC Splunk in base a 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 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 di tua scelta, 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 Svuota per assicurarti che i log già estratti da Pub/Sub non vadano 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 nell'elaborazione degli eventi o nella connessione a Splunk HEC. In questa sezione, presenterai l'errore di consegna per dimostrare il flusso di lavoro di gestione degli errori. Imparerai inoltre a visualizzare e attivare il recapito 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 errori di connessione.
• 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 pagina Abbonamenti Pub/Sub.

   Vai agli abbonamenti 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, assicurandoti di lasciare deselezionata Abilita messaggi di conferma.

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 viene visualizzato se l'endpoint HEC 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. 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 l'endpoint Splunk HEC per correggere l'errore di consegna. Puoi quindi riprodurre 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, riavvia il server.
   • Se hai disabilitato l'endpoint Splunk HEC nella sezione Trigger delivery errors, verifica che l'endpoint Splunk HEC sia ora operativo.

2. In Cloud Shell, acquisisci uno snapshot della sottoscrizione non elaborata prima di rielaborare i messaggi in questa sottoscrizione. Lo snapshot previene la perdita dei messaggi se si verifica un 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. Utilizzare il modello Dataflow 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. Inserirai questo ID job come REPLAY_JOB_ID quando svuota il tuo job Dataflow.

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

   Vai agli abbonamenti Pub/Sub

6. Seleziona la sottoscrizione non elaborata. Verifica che il grafico Numero di messaggi non bloccati sia ridotto 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 Dataflow principale seleziona 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, in Splunk apri Splunk Search & Reporting.

2. Esegui una ricerca per 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 consegna. Assicurati di espandere l'intervallo di tempo di ricerca in modo da includere gli eventi che potrebbero essersi verificati in passato, poiché il timestamp dell'evento indica l'ora originale della creazione, non quella dell'indicizzazione.

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

Tieni presente che il valore del campo insertId è uguale a quello visualizzato nei messaggi con errori quando visualizzi la sottoscrizione non elaborata. 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 il sink 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

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 dei parametri dei modelli Dataflow da Pub/Sub a Splunk, consulta la documentazione da Pub/Sub a Dataflow di Splunk.
• Per i modelli Terraform corrispondenti che ti aiuteranno 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 Dataflow Splunk.
• Per ulteriori dettagli sulle metriche personalizzate e sul logging di Splunk Dataflow per aiutarti a monitorare e risolvere i problemi delle tue pipeline 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.