Crea un flusso di log da Google Cloud a Splunk

Last reviewed 2023-11-16 UTC

Questo documento descrive un'architettura di riferimento che consente di creare un meccanismo di esportazione dei log, scalabile e a tolleranza di errore, pronto per la produzione, che trasmette in streaming log ed eventi dalle risorse di Google Cloud a Splunk. Splunk è un noto strumento di analisi che offre una piattaforma unificata per la sicurezza e l'osservabilità. Puoi scegliere di esportare i dati di logging in Splunk Enterprise o in Splunk Cloud Platform. Se sei un amministratore, puoi utilizzare questa architettura anche per le operazioni IT o per i casi d'uso di sicurezza. Per eseguire il deployment di questa architettura di riferimento, consulta Eseguire il deployment del flusso di log da Google Cloud a Splunk.

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

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

Architettura

Il seguente diagramma mostra l'architettura di riferimento che utilizzi quando esegui il deployment di questa soluzione. Questo diagramma mostra il flusso di dati dei log 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 sink di log aggregato a livello di organizzazione e li invia a Pub/Sub.
  • Pub/Sub: il servizio Pub/Sub crea quindi un argomento e una sottoscrizione singoli per i log e inoltra i log alla pipeline Dataflow principale.
  • Dataflow: questa architettura di riferimento include due pipeline Dataflow:
    • pipeline Dataflow principale: al centro del processo, la pipeline Dataflow principale è una pipeline di inserimento di flussi da Pub/Sub a Splunk, che estrae i log dalla sottoscrizione Pub/Sub e li invia a Splunk.
    • pipeline Dataflow secondaria: parallela alla pipeline Dataflow principale, la pipeline Dataflow secondaria è una pipeline di inserimento di flussi da Pub/Sub a Pub/Sub per riprodurre i messaggi in caso di errore di consegna.
  • Splunk–: alla fine del processo, Splunk Enterprise o Splunk Cloud Platform agiscono da HTTP Event Collector (HEC) e ricevono i log per ulteriori analisi. Puoi eseguire il deployment di Splunk on-premise, in Google Cloud come SaaS o con un approccio ibrido.

Caso d'uso

Questa architettura di riferimento utilizza un approccio cloud basato su push. In questo metodo basato su push, utilizzerai il modello Pub/Sub per Splunk Dataflow per trasmettere i log a un raccoglitore di eventi HTTP Splunk (HEC). L'architettura di riferimento illustra anche la pianificazione della capacità delle pipeline Dataflow e come gestire potenziali errori di distribuzione in caso di problemi temporanei del server o della rete.

Sebbene questa architettura di riferimento sia incentrata sui log di Google Cloud, la stessa architettura può essere utilizzata per esportare altri dati di Google Cloud, come le modifiche agli asset in tempo reale e i risultati sulla sicurezza. Integrando i log di Cloud Logging, puoi continuare a utilizzare i servizi partner esistenti come Splunk come soluzione unificata di analisi dei log.

Il metodo basato su push per trasmettere in streaming i dati di Google Cloud in Splunk presenta i seguenti vantaggi:

  • Servizio gestito. In quanto servizio gestito, Dataflow gestisce le risorse richieste in Google Cloud per le attività di elaborazione dei dati, come l'esportazione dei log.
  • Carico di lavoro distribuito. Questo metodo consente di distribuire i carichi di lavoro tra più worker per l'elaborazione parallela, evitando un solo punto di errore.
  • Sicurezza. Poiché Google Cloud esegue il push dei dati a Splunk HEC, non è previsto alcun carico di manutenzione e sicurezza associato alla creazione e alla gestione delle chiavi degli account di servizio.
  • Scalabilità automatica. Il servizio Dataflow scala automaticamente il numero di worker in risposta alle variazioni nel volume dei log in entrata e nel backlog.
  • Tolleranza di errore. In caso di problemi temporanei al server o alla rete, il metodo basato su push tenta automaticamente di inviare nuovamente i dati a Splunk HEC. Supporta anche gli argomenti non elaborati (noti anche come argomenti non recapitabili) per tutti i messaggi di log non recapitabili al fine di evitare la perdita di dati.
  • Semplicità. Puoi evitare l'overhead della gestione e il costo dell'esecuzione di uno o più forwarder pesanti in Splunk.

Questa architettura di riferimento si applica ad attività di molti verticali diversi, inclusi quelli regolamentati come quelli del settore farmaceutico e finanziario. Quando scegli di esportare i tuoi dati di Google Cloud in Splunk, potresti scegliere di farlo per i seguenti motivi:

  • Analisi dell'attività
  • operazioni IT
  • Monitoraggio delle prestazioni delle applicazioni
  • Operazioni di sicurezza
  • Conformità

Progettare alternative

Un metodo alternativo per esportare i log in Splunk è quello in cui esegui il pull dei log da Google Cloud. In questo metodo basato sul pull, utilizzi le API Google Cloud per recuperare i dati tramite il componente aggiuntivo Splunk per Google Cloud. Puoi scegliere di utilizzare il metodo basato su pull nelle seguenti situazioni:

  • Il deployment Splunk non offre un endpoint HEC Splunk.
  • Il volume dei log è basso.
  • Vuoi analizzare le metriche di Cloud Monitoring, gli oggetti Cloud Storage, i metadati dell'API Cloud Resource Manager o i log a basso volume.
  • Gestisci già uno o più inoltro intensi in Splunk.
  • Utilizzerai il gestore Inputs Data Manager per Splunk Cloud ospitato.

Inoltre, tieni presente le considerazioni aggiuntive che emergono 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 forwarding pesante per estrarre i dati potrebbe causare un single point of failure,
  • Il metodo basato sul pull richiede la creazione e la gestione delle chiavi degli account di servizio da utilizzare per configurare il componente aggiuntivo di Splunk per Google Cloud.

Per attivare il componente aggiuntivo Splunk, svolgi i seguenti passaggi:

  1. In Splunk, segui le istruzioni di Splunk per installare il componente aggiuntivo Splunk per Google Cloud.
  2. In Google Cloud, crea un argomento Pub/Sub per esportare i dati di logging.
  3. Crea una sottoscrizione pull Pub/Sub per questo argomento.
  4. Crea un account di servizio.
  5. Crea una chiave dell'account di servizio per l'account di servizio appena creato.
  6. Concedi i ruoli Visualizzatore Pub/Sub (roles/pubsub.viewer) e Sottoscrittore Pub/Sub (roles/pubsub.subscriber) all'account di servizio per consentire all'account di ricevere messaggi dalla sottoscrizione Pub/Sub.

  7. 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 provenienti dall'esportazione dei log vengono visualizzati in Splunk.

Per verificare che il componente aggiuntivo funzioni:

  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 pull 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 agli errori, prestazioni e ottimizzazione dei costi.

Sicurezza, privacy e conformità

Le seguenti sezioni descrivono le considerazioni sulla 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 di Dataflow. Per limitare l'accesso, esegui il deployment di queste VM con indirizzi IP privati. Tuttavia, queste VM devono anche utilizzare HTTPS per trasmettere in streaming i log esportati a Splunk e accedere a internet. Per fornire questo accesso HTTPS, è necessario un gateway Cloud NAT che alloca automaticamente gli indirizzi IP Cloud NAT alle VM che ne hanno bisogno. Assicurati di mappare la subnet che contiene le VM al gateway Cloud NAT.

Abilita l'accesso privato Google

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

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

Se vuoi limitare il traffico in Splunk HEC a un sottoinsieme di indirizzi IP noti, puoi prenotare indirizzi IP statici e assegnarli manualmente al gateway Cloud NAT. A seconda del deployment di Splunk, puoi configurare le regole firewall in entrata HEC di Splunk utilizzando questi indirizzi IP statici. Per ulteriori informazioni su Cloud NAT, consulta Configurare e gestire Network Address Translation con Cloud NAT.

Archivia 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 crittografato con una chiave Cloud Key Management Service
  • Versione del secret criptata e gestita da Secret Manager

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

Un secret in Secret Manager contiene una raccolta di versioni di secret. Ogni versione del secret archivia i dati secret effettivi, 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 a questo secret. Per informazioni generali sulla rotazione dei secret, consulta Informazioni sulle pianificazioni di 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 le operazioni. Per impostazione predefinita, i worker utilizzano l'account di servizio predefinito di Compute Engine del progetto come account di servizio worker, il 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 tuoi worker della pipeline Dataflow.

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

Ruoli necessari da assegnare a un account di servizio worker Dataflow.

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

  • Amministratore Dataflow
  • Worker Dataflow
  • Amministratore oggetti Storage
  • Sottoscrittore Pub/Sub
  • Visualizzatore Pub/Sub
  • Publisher Pub/Sub
  • Funzione di accesso secret

Per ulteriori dettagli sui ruoli da assegnare all'account di servizio worker Dataflow, consulta la sezione Concedi ruoli e accesso all'account di servizio worker Dataflow della guida al deployment.

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 Splunk. Se usi un'autorità di certificazione (CA) privata per firmare un certificato SSL utilizzato dall'endpoint HEC Splunk, puoi importare il certificato CA radice interno nell'archivio di attendibilità. I worker Dataflow possono quindi utilizzare il certificato importato per la convalida dei certificati SSL.

Puoi utilizzare e importare il tuo certificato CA radice interno per i deployment Splunk con certificati autofirmati o firmati privatamente. Puoi anche disabilitare la convalida SSL completamente solo a scopo di test e sviluppo interno. Questo metodo della CA radice interna funziona meglio per i deployment di Splunk interni non rivolti a internet.

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

Efficienza operativa

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

Utilizza la funzione definita dall'utente per trasformare log o eventi in corso

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

Riprodurre di nuovo i messaggi non elaborati

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

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

I seguenti passaggi descrivono la procedura descritta nel diagramma precedente:

  1. La pipeline di distribuzione principale da Pub/Sub a Splunk inoltra automaticamente i messaggi non recapitabili all'argomento non elaborato per l'indagine sugli utenti.

  2. L'operatore o il Site Reliability Engineer (SRE) esamina i messaggi con errori nella sottoscrizione non elaborata. L'operatore risolve e corregge la causa principale dell'errore di consegna. Ad esempio, la correzione di un errore di configurazione del token HEC potrebbe attivare la consegna dei messaggi.

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

  4. La pipeline di distribuzione principale rielabora i messaggi precedentemente non riusciti. Questo passaggio richiede che la pipeline utilizzi la funzione definita dall'utente di esempio per il rilevamento e la decodifica corretti dei payload dei messaggi non riusciti. Il seguente codice mostra la parte della funzione che implementa questa logica di decodifica condizionale, incluso un conteggio dei tentativi di consegna ai fini del 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

Per quanto riguarda l'affidabilità e la tolleranza di errore, la seguente tabella, Tabella 1, elenca alcuni possibili errori di consegna Splunk. La tabella elenca anche gli attributi errorMessage corrispondenti che la pipeline registra con ogni messaggio prima di inoltrare questi messaggi all'argomento non elaborato.

Tabella 1: tipi di errori di pubblicazione Splunk

Tipo di errore di recapito Nuovo tentativo automatico dalla pipeline? Esempio di attributo errorMessage

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 Splunk non valido

No

Host name X does not match the certificate

Errore di sintassi JavaScript nella funzione definita dall'utente dall'utente

No

ReferenceError: X is not defined

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

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

  • Un errore di sintassi nella funzione UDF.
  • Un token HEC non valido che fa sì che il server Splunk generi una risposta del server 4xx "Forbidden".

Ottimizzazione delle prestazioni e dei costi

Per quanto riguarda l'ottimizzazione delle prestazioni e dei costi, devi determinare le dimensioni e la velocità effettiva massime per la pipeline Dataflow. Devi calcolare i valori corretti di dimensione e velocità effettiva in modo che la tua pipeline sia in grado di gestire i picchi di volume dei log giornalieri (GB/giorno) e la frequenza di messaggi di log (eventi al secondo o EPS) dalla sottoscrizione Pub/Sub a monte.

Devi selezionare i valori relativi a dimensioni e velocità effettiva in modo che il sistema non presenti nessuno dei seguenti problemi:

  • Ritardi causati dal backlogging o dalla limitazione dei messaggi.
  • Costi aggiuntivi derivanti dall'overprovisioning di una pipeline.

Dopo aver eseguito i calcoli relativi a dimensioni e velocità effettiva, puoi utilizzare i risultati per configurare una pipeline ottimale che bilancia prestazioni e costi. Per configurare la capacità della pipeline, utilizza le seguenti impostazioni:

Le sezioni seguenti forniscono una spiegazione di queste impostazioni. Se applicabile, queste sezioni forniscono anche formule e calcoli di esempio che utilizzano ogni 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 costante dei messaggi pari al doppio della frequenza media.

Poiché il tuo ambiente Dataflow è univoco, sostituisci i valori di esempio con valori della tua organizzazione durante l'esecuzione dei passaggi.

Tipo di macchina

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

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

Per questa architettura di riferimento, imposta il flag --worker-machine-type sul valore n1-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 adattabile il numero di worker utilizzati per eseguire la pipeline in modalità flusso in caso di modifiche all'utilizzo e al carico delle risorse. Per evitare l'overprovisioning durante la scalabilità automatica, ti consigliamo di definire sempre il numero massimo di macchine virtuali utilizzate come worker Dataflow. Devi definire il numero massimo di macchine virtuali con il flag --max-workers quando esegui il deployment della pipeline Dataflow.

Dataflow esegue il provisioning statico del componente di archiviazione nel seguente modo:

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

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

    • Archiviazione: elemento statico con 20 dischi permanenti.
    • Computing: dinamico con minimo 2 istanze worker (⌈20/15⌉ = 2) e massimo 20.

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

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

  1. Per determinare la media degli eventi al secondo (EPS), utilizza la seguente formula:

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

    Esempio di calcolo: dati i valori di esempio di 1 TB di log al giorno con una dimensione media dei messaggi di 1 kB, questa formula genera un valore EPS medio di 11,5 mila EPS.

  2. Per determinare l'EPS di picco sostenuto utilizzando la seguente formula, in cui il moltiplicatore N rappresenta la natura "bursty" del logging:

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

    Esempio di calcolo: dato un valore di esempio pari a N=2 e un valore EPS medio di 11,5.000 calcolato nel passaggio precedente, questa formula genera un valore EPS di picco sostenuto di 23.000 EPS.

  3. Per determinare il numero massimo richiesto di vCPU, utilizza 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. Per determinare il numero massimo di worker Dataflow, utilizza la formula seguente:

    \( maxNumWorkers = ⌈maxCPUs / 4 ⌉ \)

    Esempio di calcolo: utilizzando l'esempio di 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 n1-standard-4.

Per questo esempio, imposteresti 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 per il numero massimo di worker Dataflow.

Il parametro parallelism consente di massimizzare il numero di connessioni HEC di Splunk parallele, che a sua volta massimizza la tariffa EPS per la tua pipeline.

Il valore predefinito parallelism di 1 disabilita il parallelismo e limita la frequenza di output. Devi sostituire questa impostazione predefinita per considerare da 2 a 4 connessioni parallele per vCPU, con il numero massimo di worker di cui è stato eseguito il deployment. Come regola, calcoli il valore di override per questa impostazione moltiplicando il numero massimo di worker Dataflow per il numero di vCPU per worker e raddoppiando questo valore.

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

\( {Parallelismo = maxCPUs * 2} \)

Esempio di calcolo: utilizzando l'esempio di numero massimo di vCPU di 8 calcolato in precedenza per il conteggio delle macchine, questa formula genera il numero di connessioni parallele pari a 8 x 2 = 16.

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

Conteggio batch

Best practice: per consentire all'HEC di Splunk 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 consente di aumentare gli EPS e ridurre il carico sull'endpoint HEC di Splunk. L'impostazione combina più eventi in un unico batch per garantire un'elaborazione più efficiente. Ti consigliamo di impostare il parametro batchCount su un valore compreso tra 10 e 50 eventi per richiesta di log, a condizione che sia accettabile un ritardo massimo di buffering di due secondi.

\( {batchCount >= 10} \)

Poiché in questo esempio le dimensioni medie dei messaggi di log sono pari a 1 kB, consigliamo di raggruppare almeno 10 eventi per richiesta. Per questo esempio, dovresti impostare il parametro batchCount sul valore 10. Tuttavia, ricordati di utilizzare i tuoi valori e calcoli univoci quando esegui il deployment di questa architettura di riferimento nel tuo ambiente.

Per ulteriori informazioni su questi suggerimenti 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 del flusso di log da Google Cloud a Splunk.

Passaggi successivi