Esegui il flusso dei log da Google Cloud a Splunk

Last reviewed 2024-10-24 UTC

Questo documento descrive un'architettura di riferimento che ti aiuta a creare un meccanismo di esportazione dei log scalabile, tollerante ai guasti e pronto per la produzione che trasmette log ed eventi dalle tue risorse in Google Cloud a Splunk. Splunk è un popolare strumento di analisi che offre una piattaforma unificata di sicurezza e osservabilità. Infatti, puoi scegliere di esportare i dati di logging in Splunk Enterprise o nella piattaforma Splunk Cloud. Se sei un amministratore, puoi utilizzare questa architettura anche per le operazioni IT o per casi d'uso di sicurezza. Per eseguire il deployment di questa architettura di riferimento, consulta Eseguire il deployment dello streaming dei log da Google Cloud a Splunk.

Questa architettura di riferimento presuppone una gerarchia delle risorse simile al seguente diagramma. Tutti i log delle risorse Google Cloud a livello di organizzazione, cartella e progetto vengono raccolti in un sink aggregato. Successivamente, lo sink aggregato invia questi log a una pipeline di esportazione dei log, che li elabora ed esporta in Splunk.

Sink di log aggregato a livello di organizzazione per l'esportazione in Splunk.

Architettura

Il seguente diagramma mostra l'architettura di riferimento utilizzata per il deployment di questa soluzione. Questo diagramma mostra come i dati dei log fluiscono da Google Cloud a Splunk.

Flusso di log da Google Cloud a Splunk.

Questa architettura include i seguenti componenti:

  • Cloud Logging: per avviare il processo, Cloud Logging raccoglie i log in un'area di destinazione dei log aggregata a livello di organizzazione e li invia a Pub/Sub.
  • Pub/Sub: il servizio Pub/Sub crea un singolo argomento e una sottoscrizione per i log e li inoltra alla pipeline Dataflow principale.
  • Dataflow: in questa architettura di riferimento sono presenti due pipeline Dataflow:
    • Pipeline Dataflow principale: al centro del processo, la pipeline Dataflow principale è una pipeline di streaming da Pub/Sub a Splunk che estrae i log dall'abbonamento Pub/Sub e li invia a Splunk.
    • Pipeline Dataflow secondaria: parallela alla pipeline Dataflow principale, la pipeline Dataflow secondaria è una pipeline di streaming Pub/Sub to Pub/Sub per riprodurre i messaggi in caso di errore di recapito.
  • Splunk: al termine della procedura, la piattaforma Splunk Enterprise o Splunk Cloud agisce come HEC (Http Event Collector) e riceve i log per ulteriori analisi. Puoi eseguire il deployment di Splunk on-premise, su Google Cloud come SaaS o tramite un approccio ibrido.

Caso d'uso

Questa architettura di riferimento utilizza un approccio cloud basato su push. In questo metodo basato su push, utilizzi il modello Dataflow Pub/Sub-Splunk per eseguire lo streaming dei log in un raccogli eventi HTTP (HEC) di Splunk. L'architettura di riferimento illustra inoltre la pianificazione della capacità della pipeline Dataflow e come gestire i potenziali errori di importazione in caso di problemi temporanei di rete o del server.

Sebbene questa architettura di riferimento si concentri sui log di Google Cloud, la stessa architettura può essere utilizzata per esportare altri dati di Google Cloud, come le modifiche in tempo reale delle risorse e i risultati di sicurezza. Se integri i log di Cloud Logging, puoi continuare a utilizzare i servizi partner esistenti come Splunk come soluzione di analisi dei log unificata.

Il metodo push per l'importazione in streaming dei dati di Google Cloud in Splunk presenta i seguenti vantaggi:

  • Servizio gestito. In qualità di servizio gestito, Dataflow gestisce le risorse richieste in Google Cloud per attività di elaborazione dei dati come l'esportazione dei log.
  • Carico di lavoro distribuito. Questo metodo ti consente di distribuire i carichi di lavoro su più worker per l'elaborazione in parallelo, quindi non esiste un singolo punto di errore.
  • Sicurezza. Poiché Google Cloud invia i dati a Splunk HEC, non è necessario occuparsi della manutenzione e della sicurezza associate alla creazione e alla gestione delle chiavi dell'account di servizio.
  • Scalabilità automatica. Il servizio Dataflow scala automaticamente il numero di worker in risposta alle variazioni del volume e del backlog dei log in arrivo.
  • Tolleranza di errore. ​​Se si verificano problemi temporanei di rete o del server, il metodo basato su push tenta automaticamente di inviare nuovamente i dati all'HEC di Splunk. supporta inoltre gli argomenti non elaborati (noti anche come argomenti messaggi non recapitabili) per tutti i messaggi di log non recapitabili al fine di evitare la perdita di dati.
  • Semplicità. Eviti il sovraccarico di gestione e il costo di esecuzione di uno o più forwarder pesanti in Splunk.

Questa architettura di riferimento si applica ad attività in molti settori verticali diversi, compresi quelli regolamentati come i servizi farmaceutici e finanziari. Quando scegli di esportare i dati di Google Cloud in Splunk, potresti farlo per i seguenti motivi:

  • Dati dell'attività
  • Operations IT
  • Monitoraggio delle prestazioni delle applicazioni
  • Operazioni di sicurezza
  • Conformità

Alternative di design

Un metodo alternativo per l'esportazione dei log in Splunk è quello che consente di estrarre i log da Google Cloud. In questo metodo basato su pull, utilizzi le API Google Cloud per recuperare i dati tramite il plug-in Splunk per Google Cloud. Puoi scegliere di utilizzare il metodo basato su pull nelle seguenti situazioni:

  • Il tuo deployment di Splunk non offre un endpoint HEC di Splunk.
  • Il volume dei log è basso.
  • Vuoi esportare e analizzare le metriche di Cloud Monitoring, gli oggetti Cloud Storage, i metadati dell'API Cloud Resource Manager, i dati di fatturazione Cloud o i log a basso volume.
  • Gestisci già uno o più forwarder pesanti in Splunk.
  • Utilizzi Inputs Data Manager per Splunk Cloud in hosting.

Inoltre, tieni presente le considerazioni aggiuntive che si presentano quando utilizzi questo metodo basato su pull:

  • Un singolo worker gestisce il carico di lavoro di importazione dati, che non offre funzionalità di scalabilità automatica.
  • In Splunk, l'utilizzo di un forwarder pesante per estrarre i dati potrebbe causare un singolo punto di errore.
  • Il metodo basato su pull richiede di creare e gestire le chiavi degli account di servizio utilizzate per configurare il componente aggiuntivo Splunk per Google Cloud.

Prima di utilizzare il componente aggiuntivo Splunk, le voci di log devono prima essere inoltrate a Pub/Sub utilizzando un'area di destinazione dei log. Per creare un'area di destinazione dei sink di log con l'argomento Pub/Sub come destinazione, segui questi passaggi. Assicurati di concedere il ruolo Publisher Pub/Sub (roles/pubsub.publisher) all'identità dello scrittore dell'emissario per la destinazione dell'argomento Pub/Sub. Per ulteriori informazioni sulla configurazione delle autorizzazioni per le destinazioni di destinazione, consulta Impostare le autorizzazioni di destinazione.

Per attivare il componente aggiuntivo Splunk:

  1. In Splunk, segui le istruzioni di Splunk per installare il componente aggiuntivo Splunk per Google Cloud.
  2. Crea una sottoscrizione al pull Pub/Sub per l'argomento Pub/Sub a cui vengono inoltrati i log, se non ne hai già una.
  3. Crea un account di servizio.
  4. Crea una chiave dell'account di servizio per l'account di servizio che hai appena creato.
  5. Concedi i ruoli Visualizzatore Pub/Sub (roles/pubsub.viewer) e Abbonato Pub/Sub (roles/pubsub.subscriber) all'account di servizio per consentire all'account di ricevere messaggi dall'abbonamento Pub/Sub.

  6. In Splunk, segui le istruzioni di Splunk per configurare un nuovo input Pub/Sub nel componente aggiuntivo Splunk per Google Cloud.

    I messaggi Pub/Sub dell'esportazione dei log vengono visualizzati in Splunk.

Per verificare che il componente aggiuntivo funzioni, svolgi i seguenti passaggi:

  1. In Cloud Monitoring, apri Metrics Explorer.
  2. Nel menu Risorse, seleziona pubsub_subscription.
  3. Nelle categorie Metrica, seleziona pubsub/subscription/pull_message_operation_count.
  4. Monitora il numero di operazioni di estrazione dei messaggi per uno o due minuti.

Note sul layout

Le seguenti linee guida possono aiutarti a sviluppare un'architettura che soddisfi i requisiti della tua organizzazione in termini di sicurezza, privacy, conformità, efficienza operativa, affidabilità, tolleranza ai guasti, prestazioni e ottimizzazione dei costi.

Sicurezza, privacy e conformità

Le sezioni seguenti descrivono i fattori di sicurezza per questa architettura di riferimento:

Utilizza indirizzi IP privati per proteggere le VM che supportano la pipeline Dataflow

Devi limitare l'accesso alle VM worker utilizzate nella pipeline Dataflow. Per limitare l'accesso, esegui il deployment di queste VM con indirizzi IP privati. Tuttavia, queste VM devono anche essere in grado di utilizzare HTTPS per eseguire lo streaming dei log esportati in Splunk e accedere a internet. Per fornire questo accesso HTTPS, devi disporre di un gateway Cloud NAT che alloca automaticamente gli indirizzi IP Cloud NAT alle VM che ne hanno bisogno. Assicurati di mappare la subnet contenente le VM al gateway Cloud NAT.

Abilita l'accesso privato Google

Quando crei un gateway Cloud NAT, l'accesso privato Google viene attivato automaticamente. Tuttavia, per consentire ai worker di Dataflow con indirizzi IP privati di accedere agli indirizzi IP esterni utilizzati dalle API e dai servizi Google Cloud, devi anche attivare manualmente l'accesso privato Google per la subnet.

Limita il traffico in entrata di Splunk HEC agli indirizzi IP noti utilizzati da Cloud NAT

Se vuoi limitare il traffico in entrata nell'HEC di Splunk a un sottoinsieme di indirizzi IP noti, puoi prenotare indirizzi IP statici e assegnarli manualmente al gateway Cloud NAT. A seconda del tuo deployment di Splunk, puoi quindi configurare le regole del firewall di ingresso di Splunk HEC utilizzando questi indirizzi IP statici. Per saperne di più su Cloud NAT, vedi Configurare e gestire la Network Address Translation con Cloud NAT.

Memorizza il token HEC di Splunk in Secret Manager

Quando esegui il deployment della pipeline Dataflow, puoi passare il valore del token in uno dei seguenti modi:

  • Testo normale
  • Testo cifrato con una chiave Cloud Key Management Service
  • Versione del secret criptata e gestita da Secret Manager

In questa architettura di riferimento, utilizzi l'opzione Secret Manager perché offre il modo meno complesso ed efficiente per proteggere il token HEC di Splunk. Questa opzione impedisce anche la fuga del token HEC di Splunk dalla console Dataflow o dai dettagli del job.

Un secret in Secret Manager contiene una raccolta di versioni del secret. Ogni versione del secret memorizza i dati effettivi del secret, ad esempio il token HEC di Splunk. Se in un secondo momento scegli di ruotare il token HEC di Splunk come misura di sicurezza aggiuntiva, puoi aggiungere il nuovo token come nuova versione del secret. Per informazioni generali sulla rotazione dei secret, consulta Informazioni sulle pianificazioni della rotazione.

Crea un account di servizio worker Dataflow personalizzato per seguire le best practice privilegio minimo

I worker nella pipeline Dataflow utilizzano l'account di servizio worker Dataflow per accedere alle risorse ed eseguire operazioni. Per impostazione predefinita, i worker utilizzano l'account di servizio predefinito di Compute Engine del progetto come account di servizio dei worker, che concede loro autorizzazioni ampie per tutte le risorse del progetto. Tuttavia, per eseguire i job Dataflow in produzione, ti consigliamo di creare un account di servizio personalizzato con un insieme minimo di ruoli e autorizzazioni. Puoi quindi assegnare questo account di servizio personalizzato ai worker della pipeline Dataflow.

Il seguente diagramma elenca i ruoli richiesti che devi assegnare a un account di servizio per consentire ai worker Dataflow di eseguire correttamente un job Dataflow.

Ruoli richiesti per l'assegnazione a un account di servizio worker Dataflow.

Come mostrato nel diagramma, devi assegnare i seguenti ruoli all'account di servizio per il tuo worker Dataflow:

  • Dataflow Admin
  • Dataflow Worker
  • Storage Object Admin
  • Pub/Sub Subscriber
  • Pub/Sub Viewer
  • Publisher Pub/Sub
  • Accesso ai secret

Per ulteriori dettagli sui ruoli da assegnare all'account di servizio worker Dataflow, consulta la sezione Assegnare i ruoli e l'accesso all'account di servizio worker Dataflow della guida all'implementazione.

Configura la convalida SSL con un certificato CA radice interno se utilizzi una CA privata

Per impostazione predefinita, la pipeline Dataflow utilizza l'archivio di attendibilità predefinito del worker Dataflow per convalidare il certificato SSL per l'endpoint HEC di Splunk. Se utilizzi un'autorità di certificazione (CA) privata per firmare un certificato SSL utilizzato dall'endpoint HEC di Splunk, puoi importare il certificato CA radice interno nell'archivio attendibile. I worker Dataflow possono quindi utilizzare il certificato importato per la convalida del certificato SSL.

Puoi utilizzare e importare il tuo certificato CA radice interno per i deployment di Splunk con certificati autofirmati o firmati privatamente. Puoi anche disattivare completamente la convalida SSL solo per scopi di sviluppo e test interni. Questo metodo CA radice interno è ideale per i deployment di Splunk interni non rivolti a internet.

Per ulteriori informazioni, consulta i parametri del modello Dataflow da Pub/Sub a Splunk rootCaCertificatePath e disableCertificateValidation.

Efficienza operativa

Le sezioni seguenti descrivono le considerazioni sull'efficienza operativa per questa architettura di riferimento:

Utilizzare le funzioni definite dall'utente per trasformare i log o gli eventi in tempo reale

Il modello Dataflow da Pub/Sub a Splunk supporta le funzioni definite dall'utente (UDF) per la trasformazione degli eventi personalizzati. Alcuni casi d'uso includono l'arricchimento dei record con campi aggiuntivi, l'oscuramento di alcuni campi sensibili o l'esclusione dei record indesiderati. Le funzioni definite dall'utente ti consentono di modificare il formato dell'output della pipeline di Dataflow senza dover ricompilare o gestire il codice del modello stesso. Questa architettura di riferimento utilizza una UDF per gestire i messaggi che la pipeline non è in grado di inviare a Splunk.

Riproduci i messaggi non elaborati

A volte, la pipeline riceve errori di recapito e non tenta di inviare nuovamente il messaggio. In questo caso, Dataflow invia questi messaggi non elaborati a un argomento non elaborato, come mostrato nel seguente diagramma. Dopo aver corretto la causa principale del mancato recapito, puoi riprodurre i messaggi non elaborati.

Gestione degli errori durante l'esportazione dei log in Splunk.

I passaggi che seguono descrivono la procedura mostrata nel diagramma precedente:

  1. La pipeline di invio principale da Pub/Sub a Splunk inoltra automaticamente i messaggi non recapitabili all'argomento non elaborato per le indagini degli utenti.

  2. L'operatore o l'SRE (Site Reliability Engineer) esamina i messaggi con errori nell'abbonamento non elaborato. L'operatore risolve il problema e corregge la causa principale del mancato recapito. Ad esempio, la correzione di un'errata configurazione del token HEC potrebbe consentire l'invio dei messaggi.

  3. L'operatore attiva la pipeline dei messaggi di riproduzione non riuscita. Questa pipeline da Pub/Sub a Pub/Sub (evidenziata nella sezione tratteggiata del diagramma precedente) è una pipeline temporanea che sposta i messaggi con errori dall'abbonamento non elaborato all'argomento sink di log originale.

  4. La pipeline di recapito principale elabora nuovamente i messaggi che non sono stati recapitati in precedenza. Questo passaggio richiede che la pipeline utilizzi la funzione UDF di esempio per il rilevamento e la decodifica corretti dei payload dei messaggi non riusciti. Il codice seguente mostra la parte della funzione che implementa questa logica di decodifica condizionale, incluso un conteggio dei tentativi di invio per finalità di monitoraggio:

    // If the message has already been converted to a Splunk HEC object
// with a stringified obj.event JSON payload, then it's a replay of
// a previously failed delivery.
// Unnest and parse the obj.event. Drop the previously injected
// obj.attributes such as errorMessage and timestamp
if (obj.event) {
 try {
   event = JSON.parse(obj.event);
   redelivery = true;
 } catch(e) {
   event = obj;
 }
} else {
 event = obj;
}

// Keep a tally of delivery attempts
event.delivery_attempt = event.delivery_attempt || 1;
if (redelivery) {
 event.delivery_attempt += 1;
}

Affidabilità e tolleranza agli errori

In merito all'affidabilità e alla tolleranza ai guasti, la seguente tabella (Tabella 1) elenca alcuni possibili errori di importazione di Splunk. La tabella elenca anche gli attributi errorMessage corrispondenti che la pipeline registra con ogni messaggio prima di inoltrarlo all'argomento non elaborato.

Tabella 1: tipi di errori di importazione di Splunk

Tipo di errore di recapito Il tentativo è stato ripetuto automaticamente dalla pipeline? Attributo errorMessage di esempio

Errore di rete temporaneo

Sì

Read timed out

o

Connection reset

Errore 5xx del server Splunk

Sì

Splunk write status code: 503

Errore 4xx del server Splunk

No

Splunk write status code: 403

Server Splunk non attivo

No

The target server failed to respond

Certificato SSL di Splunk non valido

No

Host name X does not match the certificate

Errore di sintassi di JavaScript nella funzione definita dall'utente (UDF)

No

ReferenceError: X is not defined

In alcuni casi, la pipeline applica il backoff esponenziale e prova automaticamente a recapitare il messaggio di nuovo. Ad esempio, quando il server Splunk genera un codice di errore 5xx, la pipeline deve recapitare il messaggio. Questi codici di errore si verificano quando l'endpoint HEC di Splunk è sovraccaricato.

In alternativa, potrebbe esserci un problema persistente che impedisce l'invio di un messaggio all'endpoint HEC. Per questi problemi persistenti, la pipeline non tenta di consegnare di nuovo il messaggio. Di seguito sono riportati alcuni esempi di problemi persistenti:

  • Un errore di sintassi nella funzione UDF.
  • Un token HEC non valido che causa la generazione da parte del server Splunk di una risposta del server 4xx "Forbidden".

Ottimizzazione delle prestazioni e dei costi

In merito all'ottimizzazione delle prestazioni e dei costi, devi determinare le dimensioni e la velocità massime per la pipeline Dataflow. Devi calcolare i valori corretti di dimensioni e throughput in modo che la pipeline possa gestire il volume giornaliero massimo dei log (GB/giorno) e la frequenza dei messaggi di log (eventi al secondo o EPS) dall'abbonamento Pub/Sub a monte.

Devi selezionare i valori di dimensione e throughput in modo che il sistema non abbia uno dei seguenti problemi:

  • Ritardi causati da una coda di messaggi o dal throttling dei messaggi.
  • Costi aggiuntivi dovuti al provisioning eccessivo di una pipeline.

Dopo aver eseguito i calcoli delle dimensioni e del throughput, puoi utilizzare i risultati per configurare una pipeline ottimale che bilanci prestazioni e costi. Per configurare la capacità della pipeline, utilizza le seguenti impostazioni:

Le sezioni seguenti forniscono una spiegazione di queste impostazioni. Ove applicabile, queste sezioni forniscono anche formule e calcoli di esempio che utilizzano ciascuna formula. Questi calcoli di esempio e i valori risultanti presuppongono un'organizzazione con le seguenti caratteristiche:

  • Genera 1 TB di log al giorno.
  • Ha una dimensione media del messaggio di 1 KB.
  • Ha una frequenza di picco dei messaggi sostenuta pari al doppio della frequenza media.

Poiché il tuo ambiente Dataflow è univoco, sostituisci i valori di esempio con quelli della tua organizzazione man mano che svolgi i passaggi.

Tipo di macchina

Best practice: imposta il flag --worker-machine-type su n2-standard-4 per selezionare una dimensione della macchina che offra il miglior rapporto prestazioni/costo.

Poiché il tipo di macchina n2-standard-4 può gestire 12.000 EPS, ti consigliamo di utilizzare questo tipo di macchina come linea di base per tutti i tuoi worker Dataflow.

Per questa architettura di riferimento, imposta il flag --worker-machine-type su un valore n2-standard-4.

Conteggio macchine

Best practice: imposta il flag --max-workers per controllare il numero massimo di worker necessari per gestire il picco di EPS previsto.

La scalabilità automatica di Dataflow consente al servizio di modificare in modo adattativo il numero di worker utilizzati per eseguire la pipeline di streaming quando si verificano variazioni nell'utilizzo e nel carico delle risorse. Per evitare il provisioning eccessivo durante la scalabilità automatica, ti consigliamo di definire sempre il numero massimo di macchine virtuali utilizzate come worker Dataflow. Quando esegui il deployment della pipeline Dataflow, definisci il numero massimo di macchine virtuali con il flag --max-workers.

Dataflow esegue il provisioning statico del componente di archiviazione come segue:

  • Una pipeline con scalabilità automatica esegue il deployment di un disco permanente dei dati per ogni potenziale worker di streaming. La dimensione predefinita del disco permanente è 400 GB e puoi impostare il numero massimo di worker con il flag --max-workers. I dischi vengono montati sui worker in esecuzione in qualsiasi momento, inclusa l'avvio.

  • Poiché ogni istanza worker è limitata a 15 dischi permanenti, il numero minimo di worker iniziali è ⌈--max-workers/15⌉. Pertanto, se il valore predefinito è --max-workers=20, l'utilizzo (e il costo) della pipeline è il seguente:

    • Spazio di archiviazione:statico con 20 dischi permanenti.
    • Computing: dinamico con un minimo di 2 istanze worker (⌈20/15⌉ = 2) e un massimo di 20.

    Questo valore equivale a 8 TB di un Persistent Disk. Questa dimensione del Persistent Disk potrebbe comportare costi non necessari se i dischi non vengono utilizzati completamente, in particolare se la maggior parte del tempo sono in esecuzione solo uno o due worker.

Per determinare il numero massimo di worker di cui hai bisogno per la pipeline, utilizza in sequenza le seguenti formule:

  1. Determina gli eventi al secondo (EPS) medi utilizzando la seguente formula:

    \( {AverageEventsPerSecond}\simeq\frac{TotalDailyLogsInTB}{AverageMessageSizeInKB}\times\frac{10^9}{24\times3600} \)

    Calcolo di esempio: dati i valori di esempio di 1 TB di log al giorno con una dimensione media del messaggio di 1 KB, questa formula genera un valore medio di EPS di 11.500 EPS.

  2. Determina il picco massimo di EPS utilizzando la seguente formula, dove il moltiplicatore N rappresenta la natura intermittente della registrazione:

    \( {PeakEventsPerSecond = N \times\ AverageEventsPerSecond} \)

    Calcolo di esempio: dato un valore di esempio di N=2 e il valore medio dell'utile per azione di 11.500 calcolato nel passaggio precedente, questa formula genera un valore di picco dell'utile per azione sostenuto di 23.000.

  3. Determina il numero massimo di vCPU richieste utilizzando la seguente formula:

    \( {maxCPUs = ⌈PeakEventsPerSecond / 3k ⌉} \)

    Esempio di calcolo: utilizzando il valore EPS di picco sostenuto di 23.000 calcolato nel passaggio precedente, questa formula genera un massimo di ⌈23 / 3⌉ = 8 core vCPU.

  4. Determina il numero massimo di worker Dataflow utilizzando la seguente formula:

    \( maxNumWorkers = ⌈maxCPUs / 4 ⌉ \)

    Calcolo di esempio: utilizzando il valore massimo di vCPU pari a 8 calcolato nel passaggio precedente, questa formula [8/4] genera un numero massimo di 2 per un tipo di macchina n2-standard-4.

Per questo esempio, imposta il flag --max-workers su un valore 2 in base al precedente insieme di calcoli di esempio. Tuttavia, ricordati di utilizzare i tuoi valori e calcoli univoci quando esegui il deployment di questa architettura di riferimento nel tuo ambiente.

Parallelismo

Best practice: imposta il parametro parallelism nel modello Dataflow da Pub/Sub a Splunk su due volte il numero di vCPU utilizzate dal numero massimo di worker Dataflow.

Il parametro parallelism consente di massimizzare il numero di connessioni HEC di Splunk in parallelo, il che a sua volta massimizza la frequenza EPS per la pipeline.

Il valore predefinito di parallelism, 1, disattiva il parallelismo e limita la frequenza di output. Devi sostituire questa impostazione predefinita per tenere conto di 2-4 connessioni parallele per vCPU, con il numero massimo di worker di cui è stato eseguito il deployment. Come regola, calcola il valore di override per questa impostazione moltiplicando il numero massimo di worker Dataflow per il numero di vCPU per worker e poi raddoppiando questo valore.

Per determinare il numero totale di connessioni parallele all'HEC di Splunk su tutti i worker Dataflow, utilizza la seguente formula:

\( {parallelism = maxCPUs * 2} \)

Calcolo di esempio: utilizzando le vCPU massime di esempio pari a 8 calcolate in precedenza per il numero di macchine, questa formula genera un numero di connessioni parallele pari a 8 x 2 = 16.

Per questo esempio, imposta il parametro parallelism su un valore 16 in base al calcolo dell'esempio precedente. Tuttavia, ricordati di utilizzare i tuoi valori e calcoli unici quando esegui il deployment di questa architettura di riferimento nel tuo ambiente.

Conteggio batch

Best practice: per consentire a Splunk HEC di elaborare gli eventi in batch anziché uno alla volta, imposta il parametro batchCount su un valore compreso tra 10 e 50 eventi/richiesta per i log.

La configurazione del conteggio batch contribuisce ad aumentare l'EPS e a ridurre il carico sull'endpoint HEC di Splunk. L'impostazione combina più eventi in un unico batch per un'elaborazione più efficiente. Ti consigliamo di impostare il parametro batchCount su un valore compreso tra 10 e 50 eventi/richiesta per i log, a condizione che il ritardo di buffering massimo di due secondi sia accettabile.

\( {batchCount >= 10} \)

Poiché in questo esempio la dimensione media del messaggio di log è 1 KB, ti consigliamo di aggregare almeno 10 eventi per richiesta. Per questo esempio, imposta il parametro batchCount su un valore 10. Tuttavia, ricordati di utilizzare i tuoi valori e calcoli unici quando esegui il deployment di questa architettura di riferimento nel tuo ambiente.

Per ulteriori informazioni su questi consigli per l'ottimizzazione delle prestazioni e dei costi, consulta Pianificare la pipeline Dataflow.

Deployment

Per eseguire il deployment di questa architettura di riferimento, consulta Eseguire il deployment dello streaming dei log da Google Cloud a Splunk.

Passaggi successivi