Avvia flussi di 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, a tolleranza di errore e pronto per la produzione che trasmette in streaming log ed eventi dalle tue risorse in Google Cloud a Splunk. Splunk è uno strumento di analisi popolare che offre una piattaforma unificata per la sicurezza e l'osservabilità. Infatti, puoi scegliere di esportare i dati di logging in Splunk Enterprise o Splunk Cloud Platform. Se sei un amministratore, puoi utilizzare questa architettura anche per casi d'uso di operazioni IT o di sicurezza.

Questa architettura di riferimento presuppone una gerarchia delle risorse simile a quella del seguente diagramma. Tutti i log delle risorse Google Cloud a livello di organizzazione, cartella e progetto vengono raccolti in un sink aggregato. Il sink aggregato invia questi log a una pipeline di esportazione dei log, che li elabora e li 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 che utilizzi quando esegui il deployment di questa soluzione. Questo diagramma mostra il flusso dei dati di log da Google Cloud a Splunk.

Flusso dei 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 un singolo argomento e una singola 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 da Pub/Sub a Pub/Sub per riprodurre i messaggi in caso di mancata consegna.
  • Splunk: al termine del processo, Splunk Enterprise o Splunk Cloud Platform funge da HTTP Event Collector (HEC) e riceve i log per un'ulteriore analisi. Puoi eseguire il deployment di Splunk on-premise, in Google Cloud come SaaS o tramite un approccio ibrido.

Caso d'uso

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

Sebbene questa architettura di riferimento si concentri sui Google Cloud log, la stessa architettura può essere utilizzata per esportare altri Google Cloud dati, come modifiche agli asset in tempo reale e risultati di 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 sul push per lo streaming dei dati Google Cloud in Splunk presenta i seguenti vantaggi:

  • Servizio gestito. In qualità di 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 su più worker per l'elaborazione parallela, quindi non esiste un singolo punto di errore.
  • Sicurezza. Poiché Google Cloud trasferisce i tuoi dati a Splunk HEC, non devi occuparti della manutenzione e della sicurezza associate 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 del volume di log in entrata e del backlog.
  • Tolleranza di errore. ​​Se si verificano problemi temporanei con il server o la rete, il metodo basato sul push tenta automaticamente di inviare nuovamente i dati a Splunk HEC. Supporta anche gli argomenti non elaborati (noti anche come argomenti messaggi non recapitabili) per qualsiasi messaggio di log non recapitabile per evitare la perdita di dati.
  • Semplicità. Eviti il sovraccarico di gestione e il costo di esecuzione di uno o più heavy forwarder 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 tuoi dati Google Cloud in Splunk, potresti farlo per i seguenti motivi:

  • Analisi aziendale
  • Operazioni IT
  • Monitoraggio delle prestazioni delle applicazioni
  • Operazioni di sicurezza
  • Conformità

Alternative di progettazione

Un metodo alternativo per l'esportazione dei log in Splunk prevede l'estrazione 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. Potresti scegliere di utilizzare il metodo basato sul pull nelle seguenti situazioni:

  • Il tuo deployment Splunk non offre un endpoint Splunk HEC.
  • 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 Cloud Billing o i log a basso volume.
  • Gestisci già uno o più heavy forwarder in Splunk.
  • Utilizzi Inputs Data Manager per Splunk Cloud ospitato.

Tieni presente anche le considerazioni aggiuntive che sorgono quando utilizzi questo metodo basato sul pull:

  • Un singolo worker gestisce il carico di lavoro di importazione dei dati, che non offre funzionalità di scalabilità automatica.
  • In Splunk, l'utilizzo di un heavy forwarder per estrarre i dati potrebbe causare un singolo punto di errore.
  • Il metodo basato sul pull richiede la creazione e la gestione delle chiavi del service account che utilizzi per configurare il componente aggiuntivo Splunk per Google Cloud.

Prima di utilizzare il componente aggiuntivo Splunk, le voci di log devono essere indirizzate a Pub/Sub utilizzando un sink di log. Per creare un sink di log con l'argomento Pub/Sub come destinazione, consulta Creare un sink. Assicurati di concedere il ruolo Publisher Pub/Sub (roles/pubsub.publisher) all'identità writer del sink nella destinazione dell'argomento Pub/Sub. Per ulteriori informazioni sulla configurazione delle autorizzazioni della destinazione sink, consulta Imposta le autorizzazioni della destinazione.

Per attivare il componente aggiuntivo Splunk, segui questi passaggi:

  1. In Splunk, segui le istruzioni per installare il componente aggiuntivo Splunk per Google Cloud.
  2. Crea una sottoscrizione pull Pub/Sub per l'argomento Pub/Sub a cui vengono indirizzati 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 Sottoscrittore Pub/Sub (roles/pubsub.subscriber) al service account per consentirgli 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 dall'esportazione dei log vengono visualizzati in Splunk.

Per verificare che il componente aggiuntivo funzioni, segui questi passaggi:

  1. In Cloud Monitoring, apri Esplora metriche.
  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 1-2 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 sezioni seguenti 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 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 trasmettere in streaming i log esportati in Splunk e accedere a internet. Per fornire questo accesso HTTPS, hai bisogno di un gateway Cloud NAT che allochi 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.

Limitare il traffico in entrata Splunk HEC 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 della tua implementazione di Splunk, puoi quindi configurare le regole firewall di ingresso HEC di Splunk utilizzando questi indirizzi IP statici. Per saperne di più su Cloud NAT, consulta Configurare e gestire Network Address Translation con Cloud NAT.

Archivia il token Splunk HEC in Secret Manager

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

  • Testo normale
  • Testo cifrato criptato 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 perdita del token Splunk HEC 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 Splunk HEC 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 la sezione Informazioni sulle pianificazioni di rotazione.

Crea un service account worker Dataflow personalizzato per seguire le best practice relative ai privilegi minimi

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 Compute Engine predefinito del tuo progetto come service account worker, il che concede loro ampie autorizzazioni per tutte le risorse del tuo progetto. Tuttavia, per eseguire i job Dataflow in produzione, ti consigliamo di creare un service account personalizzato con un insieme minimo di ruoli e autorizzazioni. Puoi quindi assegnare questo service account personalizzato ai worker della pipeline Dataflow.

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

Ruoli richiesti da assegnare a un service account worker Dataflow.

Come mostrato nel diagramma, devi assegnare i seguenti ruoli al service account per il worker Dataflow:

  • Dataflow Admin
  • Dataflow Worker
  • Storage Object Admin
  • Pub/Sub Subscriber
  • Pub/Sub Viewer
  • Publisher Pub/Sub
  • Secret Accessor

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 Splunk HEC. Se utilizzi un'autorità di certificazione (CA) privata per firmare un certificato SSL utilizzato dall'endpoint Splunk HEC, puoi importare il certificato CA radice interno nell'archivio di attendibilità. 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 le implementazioni 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 di CA radice interna è più adatto alle implementazioni Splunk interne non connesse 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 UDF per trasformare i log o gli eventi in volo

Il modello Dataflow da Pub/Sub a Splunk supporta le funzioni definite dall'utente (UDF) per la trasformazione personalizzata degli eventi. Esempi di casi d'uso 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 ti consente di modificare il formato di output della pipeline 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 recapitare a Splunk.

Riproduci i messaggi non elaborati

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

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

I seguenti passaggi descrivono la procedura mostrata nel diagramma precedente:

  1. La pipeline di consegna principale da Pub/Sub a Splunk inoltra automaticamente i messaggi non recapitabili all'argomento non elaborato per l'analisi da parte dell'utente.

  2. L'operatore o l'ingegnere dell'affidabilità del sito (SRE) esamina i messaggi non riusciti nell'abbonamento non elaborato. L'operatore risolve i problemi e la causa principale del mancato recapito. Ad esempio, la correzione di un'errata configurazione del token HEC potrebbe consentire la consegna dei messaggi.

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

  4. La pipeline di recapito principale rielabora i messaggi non riusciti in precedenza. Questo passaggio richiede che la pipeline utilizzi una UDF per il rilevamento e la decodifica corretti dei payload dei messaggi non riusciti. Il seguente codice è una funzione di esempio che implementa questa logica di decodifica condizionale, incluso un conteggio dei tentativi di pubblicazione a scopo 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

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

Tabella 1: tipi di errori di recapito di Splunk

Tipo di errore di recapito Riprova automatica della 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 Splunk non valido

No

Host name X does not match the certificate

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

No

ReferenceError: X is not defined

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

In alternativa, potrebbe esserci un problema persistente che impedisce l'invio di un messaggio all'endpoint HEC. Per problemi così persistenti, la pipeline non tenta di recapitare 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 fa sì che il server Splunk generi una risposta del server "Forbidden" 4xx.

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 tua pipeline Dataflow. Devi calcolare le dimensioni e i valori di velocità effettiva corretti in modo che la pipeline possa gestire il volume di log giornaliero di picco (GB/giorno) e la frequenza dei messaggi di log (eventi al secondo, o EPS) dall'abbonamento Pub/Sub upstream.

Devi selezionare i valori di dimensione e velocità effettiva in modo che il sistema non incorra in uno dei seguenti problemi:

  • Ritardi causati dal backlog dei messaggi o dalla limitazione 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. Se applicabile, queste sezioni forniscono anche formule ed esempi di calcoli 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 velocità di messaggi di picco sostenuta che è il doppio della velocità media.

Poiché l'ambiente Dataflow è unico, sostituisci i valori di esempio con i valori della tua organizzazione man mano che procedi con 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/costi.

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

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

Conteggio macchine

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

La scalabilità automatica di Dataflow consente al servizio di modificare in modo adattivo il numero di worker utilizzati per eseguire la pipeline di streaming quando si verificano modifiche all'utilizzo delle risorse e al carico. Per evitare un provisioning eccessivo durante la scalabilità automatica, ti consigliamo di definire sempre il numero massimo di macchine virtuali utilizzate come worker Dataflow. Definisci 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 per i dati per ogni potenziale worker di streaming. 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⌉. Pertanto, se il valore predefinito è --max-workers=20, l'utilizzo (e il costo) della pipeline è il seguente:

    • Archiviazione:statica con 20 dischi permanenti.
    • Compute: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 disco permanente potrebbe comportare costi inutili se i dischi non vengono utilizzati completamente, 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 seguenti formule in sequenza:

  1. Determina il numero medio di eventi al secondo (EPS) utilizzando 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 k EPS.

  2. Determina l'EPS di picco sostenuto utilizzando la seguente formula, in cui il moltiplicatore N rappresenta la natura bursty della registrazione:

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

    Esempio di calcolo:dato un valore di esempio di N=2 e il valore EPS medio di 11,5 mila che hai calcolato nel passaggio precedente, questa formula genera un valore EPS di picco sostenuto di 23 mila EPS.

  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 che hai 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 ⌉ \)

    Esempio di calcolo:utilizzando il valore massimo di vCPU di 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, imposteresti il flag --max-workers sul valore 2 in base al precedente insieme di calcoli di esempio. Tuttavia, ricordati di utilizzare i tuoi valori e calcoli unici quando implementi questa architettura di riferimento nel tuo ambiente.

Parallelismo

Best practice: imposta il parametro parallelism nel modello Dataflow Da Pub/Sub a Splunk sul doppio del numero di vCPU utilizzate dal numero massimo di worker Dataflow.

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

Il valore predefinito parallelism di 1 disabilita il parallelismo e limita il tasso 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 generale, calcoli 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 a Splunk HEC in tutti i worker Dataflow, utilizza la seguente formula:

\( {parallelism = maxCPUs * 2} \)

Esempio di calcolo: utilizzando il 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, imposteresti il parametro parallelism sul valore 16 in base al calcolo dell'esempio precedente. Tuttavia, ricordati di utilizzare valori e calcoli unici quando implementi 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 consente di aumentare l'EPS e ridurre il carico sull'endpoint Splunk HEC. 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 massimo di buffering di due secondi sia accettabile.

\( {batchCount >= 10} \)

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

Per ulteriori informazioni su questi suggerimenti per l'ottimizzazione del rendimento e dei costi, consulta Pianificare la pipeline Dataflow.

Passaggi successivi