Installazione e configurazione dell'inoltro su Linux

Questo documento descrive come installare e configurare lo strumento di inoltro su Linux. Puoi installare l'inoltro su una varietà di distribuzioni Linux (Debian, Ubuntu, Red Hat, Suse e così via). Google Cloud fornisce il software utilizzando un container Docker. Puoi eseguire e gestire il container Docker su una macchina fisica o virtuale che esegue Linux.

Personalizzare i file di configurazione

In base alle informazioni che hai inviato prima del deployment, Google Cloud fornisce il software di inoltro e i file di configurazione. Google Cloud sposta i tuoi file di configurazione nell'istanza di inoltro sulla tua rete. Se devi modificare la configurazione, contatta l'assistenza di Chronicle.

Nota: non condividere i file di configurazione all'esterno dell'organizzazione.

Requisiti di sistema

Di seguito sono riportati consigli generali. Per consigli specifici per il tuo sistema, contatta l'assistenza di Chronicle.

• RAM: 1,5 GB per ciascun tipo di dati raccolti. Ad esempio, il rilevamento e la risposta degli endpoint (EDR), DNS e DHCP sono tutti tipi di dati separati. Avrai bisogno di 4,5 GB di RAM per raccogliere i dati per tutti e tre.

• CPU: 2 CPU sono sufficienti per gestire meno di 10.000 eventi al secondo (EPS) (totale per tutti i tipi di dati). Se prevedi di inoltrare più di 10.000 EPS, esegui il provisioning da 4 a 6 CPU.

• Disco: sono sufficienti 100 MB di spazio su disco, indipendentemente dalla quantità di dati gestita dall'inoltro di Chronicle. Vedi anche Buffer del disco se è necessario eseguire il buffer dei messaggi con backlog sul disco anziché sulla memoria. Per impostazione predefinita, il buffer di Chronicle passa in memoria.

Verifica la configurazione del firewall

Se sono presenti firewall o proxy autenticati tra il container di inoltro Chronicle e Internet, le regole richiedono l'accesso per l'accesso ai seguenti host:

Tipo di connessione	Destinazione	Port (Porta)
TCP	malachiteingestion-pa.googleapis.com	443
TCP	accounts.google.com	443
TCP	gcr.io	443
TCP	oauth2.googleapis.com	443
TCP	storage.googleapis.com	443

Raccogli dati Splunk

Puoi configurare lo strumento di inoltro di Chronicle in modo che inoltri i tuoi dati Splunk a Chronicle. Google Cloud configura l'inoltro automatico di Chronicle con le seguenti informazioni per l'inoltro dei dati da Splunk:

• URL per l'API REST di Splunk (ad esempio, https://10.0.113.15:8889).

• Suddividi le query per generare dati per ciascuno dei tipi di dati richiesti (ad esempio, indice=dns).

Devi rendere disponibili a Chronicle le credenziali del tuo account Splunk.

Nota: non inoltrare le credenziali Splunk a Google Cloud.

Crea un file locale per le tue credenziali Splunk e denominalo creds.txt. Inserisci il tuo nome utente nella prima riga e la password nella seconda riga:

  cat creds-file

  myusername
  mypassword

Per i clienti che utilizzano lo strumento di inoltro Chronicle per accedere a un'istanza di Splunk, copia il file creds.txt nella directory di configurazione (la stessa directory dei file di configurazione). Ad esempio:

cp creds-file ~/config/creds.txt

Verifica che il file creds.txtem> sia nella posizione corretta:

ls ~/config

- splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10
      maximum_window_size: 30
      user: admin
      password: letmeinaA1!
      query_string: search index=* sourcetype=dns
      query_mode: realtime

minimum_window_size: l'intervallo di tempo minimo passato alla query Splunk. Il valore predefinito è 10 secondi. Questo parametro viene utilizzato per l'ottimizzazione se il requisito richiede di modificare la frequenza di esecuzione della query del server Splunk quando lo strumento di inoltro è in stato stabile. Inoltre, in caso di ritardo, la chiamata API Splunk può essere effettuata più volte.

max_window_size: l'intervallo di tempo massimo passato alla query Splunk. Il valore predefinito è 30 secondi. Questo parametro viene utilizzato per l'ottimizzazione nei casi di ritardo e se sono necessari più dati per query.

Modifica questo parametro (uguale a o maggiore di) quando cambi il parametro minimo. Si possono verificare casi di ritardo se una chiamata di query Splunk richiede più tempo del valore max_window_size.

Nota: gli intervalli di tempo non si sovrappongono mai quando viene eseguita una query sul server Splunk. L'intervallo di date della query è sempre compreso tra i parametri minimi e massimi della finestra.

Installa Docker

Puoi installare Docker su diversi sistemi operativi host. L'installazione effettiva di Docker dipende dall'ambiente host. Google Cloud fornisce documentazione limitata per aiutarti a installare Docker in alcune delle distribuzioni Linux più popolari. Tuttavia, Docker è open source e la documentazione sostanziale è già disponibile.

Dopo aver installato Docker sul tuo sistema, il resto del processo di installazione dello strumento di forwarding Chronicle è identico, indipendentemente dalla distribuzione di Linux che stai utilizzando.

Verifica che Docker sia installato sul sistema eseguendo il seguente comando (privilegi più elevati):

# docker ps

La seguente risposta indica che Docker è stato installato correttamente:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Puoi raccogliere ulteriori informazioni sull'installazione di Docker utilizzando il seguente comando:

# docker info

In caso di problemi con Docker, l'assistenza di Chronicle potrebbe richiedere l'output da questo comando per aiutarti con il debug.

Installa l'inoltro

Questa sezione descrive come installare Chronicle Forwarder utilizzando un container Docker in un sistema Linux.

Passaggio 1: Scarica, trasferisci e installa i file di configurazione dello strumento di inoltro

Google Cloud fornisce i file di configurazione di inoltro specifici per il tuo sistema operativo (Linux o Windows). Scarica i file dal link fornito dal tuo rappresentante Chronicle in una directory locale sul tuo laptop (ad esempio, denominata chronicle). Dopo aver completato i seguenti passaggi, trasferisci i file di configurazione dal laptop alla directory di inoltro ~/config all'interno della home directory dell'utente.

1. Connettiti al tuo inoltro Linux tramite terminale.

2. Crea un nuovo utente nello strumento di inoltro Linux.

   # adduser <username>

   # passwd <username>

   # usermod -aG wheel <username>

3. Modifica la directory nella home directory del nuovo utente che eseguirà Docker Container.

4. Crea una directory per archiviare i file di configurazione dell'inoltro di Chronicle: # mkdir ~/config

5. Cambiare la directory

6. Una volta trasferiti i file, verifica che si trovino nella directory ~/config:

   # ls -l

Passaggio 2: Esegui lo strumento di forwarding all'interno del container Docker

Puoi utilizzare le seguenti procedure per avviare l'inoltro a Chronicle la prima volta e per eseguire l'upgrade all'ultima versione del container Chronicle:

Le opzioni --log-opt sono disponibili dalla versione Docker 1.13. Queste opzioni limitano la dimensione dei file di log del container e devono essere utilizzate purché la tua versione di Docker le supporti.

1. Se esegui l'upgrade, pulisci innanzitutto le esecuzioni precedenti di Docker. Nell'esempio seguente, il nome del container Docker è cfps, quindi recupera l'immagine Docker più recente da Google Cloud con il comando # docker pull riportato di seguito.

   # docker stop cfps
   # docker rm cfps
   

2. Ottieni l'immagine Docker più recente da Google Cloud:

   # docker pull gcr.io/chronicle-container/cf_production_stable

3. Avvia lo strumento di inoltro di Chronicle dal container Docker:

   docker run \
   
     --detach \
   
     --name cfps \
   
     --restart=always \
   
     --log-opt max-size=100m \
   
     --log-opt max-file=10 \
   
     --net=host \
   
     -v ~/config:/opt/chronicle/external \
   
     gcr.io/chronicle-container/cf_production_stable
   

Questi comandi vengono anche forniti come script shell, chiamato run_docker_production_stable.sh.

Il container Docker (e l'inoltro del Chronicle) persistono dopo il riavvio del sistema.

Passaggio 3: Monitoraggio e gestione dell'inoltro

I seguenti comandi Docker ti consentono di monitorare e gestire l'inoltro di Chronicle:

• Verifica se il container Docker è in esecuzione:

  docker ps

• Visualizza i log dal container. Tieni presente che può generare un volume di output considerevole, ma è utile per eseguire il debug:

  docker logs cfps

• Per verificare cosa è in esecuzione all'interno del container:

  docker top cfps

• Per arrestare il contenitore:

  docker stop cfps

Raccogli dati di syslog

L'inoltro Chronicle può funzionare come server Syslog, il che significa che puoi configurare qualsiasi appliance o server che supporta l'invio di dati syslog tramite una connessione TCP o UDP per inoltrare i suoi dati all'inoltratore di Chronicle. Puoi controllare esattamente quali dati invia l'appliance o il server all'inoltratore di Chronicle. L'inoltro di Chronicle può quindi inoltrare i dati a Chronicle.

Il file di configurazione (fornito da Google Cloud) specifica le porte da monitorare per ogni tipo di dati inoltrati (ad esempio, la porta 10514). Per impostazione predefinita, lo strumento di inoltro Chronicle accetta entrambe le connessioni TCP e UDP.

Configura rsyslog

Per configurare rsyslog, devi specificare una destinazione per ogni porta (ad esempio, ogni tipo di dati). Per la sintassi corretta, consulta la documentazione del sistema. I seguenti esempi illustrano una configurazione di destinazione rsyslog:

• Traffico di log TCP: dns.* @192.168.0.12:10514

• Traffico log UDP: dns.* @192.168.0.12:10514

Abilita TLS per le configurazioni di syslog

Puoi abilitare TLS per la connessione Syslog all'inoltro di Chronicle. Nel file di configurazione dell'inoltro di Chronicle, specifica la posizione del certificato e della chiave del certificato generati come mostrato nell'esempio seguente:

certificato	"/opt/chronicle/external/certs/client_generate_cert.pem"
certificato_chiave	"/opt/chronicle/external/certs/client_generate_cert.key"

In base all'esempio mostrato, la configurazione del forwarding di Chronicle verrebbe modificata come segue:

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
  tcp_address: 0.0.0.0:10515
  tcp_buffer_size: 65536
  connection_timeout_sec: 60
  certificate: "/opt/chronicle/external/certs/client_generated_cert.pem"
  certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
  minimum_tls_version: "TLSv1_3"

Nota: puoi configurare la dimensione del buffer TCP. La dimensione predefinita del buffer TCP è 64 kB.

Nota: non configurare un valore per batch_n_byte superiore a 5 MB.

Il valore dei batch_n_byte non deve superare 5 MB.

Nota: la versione minima di TLS viene confrontata con la versione TLS della richiesta di input. La versione TLS della richiesta di input deve essere superiore alla versione minima di TLS. La versione minima di TLS deve essere uno dei seguenti valori: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

Nota: il valore predefinito e consigliato per connection_timeout è 60 secondi. La connessione TCP si interrompe dopo che è stata disattivata per un periodo di tempo specificato.

Puoi creare una directory dei certificati nella directory di configurazione e memorizzarvi i file del certificato.

Nota: rimuovi il campo udp_address dal file di configurazione dello strumento di inoltro Chronicle. TLS deve utilizzare TCP per il trasporto, quindi UDP non può essere configurato.

Raccogli i dati del file

Avvia lo strumento di inoltro Chronicle dal container Docker:

  docker run \

    --name cfps \

    --log-opt max-size=100m \

    --log-opt max-file=10 \

    --net=host \

    -v ~/config:/opt/chronicle/external \

    -v /var/log/crowdstrike/falconhoseclient:/opt/chronicle/edr \

     gcr.io/chronicle-container/cf_production_stable

Questo comando docker run è fondamentale per mappare il volume di carico al container.

In base a questo esempio, cambierai la configurazione dell'inoltro di Chronicle nel seguente modo:

 collectors:
  - file:
       common:
         enabled: true
         data_type: CS_EDR
         data_hint:
         batch_n_seconds: 10
         batch_n_bytes: 1048576
       file_path: /opt/chronicle/edr/output/sample.txt
       filter:

Nota: crea la configurazione per impostare l'input del file come mostrato sopra.

Raccogli i dati del pacchetto

L'inoltro di Chronicle può acquisire i pacchetti direttamente da un'interfaccia di rete utilizzando libpcap su Linux. I pacchetti vengono acquisiti e inviati a Chronicle anziché alle voci di log. L'acquisizione dei pacchetti viene gestita solo da un'interfaccia locale. Per attivare l'acquisizione del pacchetto per il tuo sistema, contatta l'assistenza Chronicle.

Google Cloud configura l'inoltratore Chronicle con l'espressione Berkeley Packet Filter (BPF) utilizzata durante l'acquisizione dei pacchetti, ad esempio la porta 53 e non l'host locale.

Attiva/disattiva la compressione dati

La compressione dei log riduce il consumo della larghezza di banda della rete durante il trasferimento dei log a Chronicle. Tuttavia, la compressione potrebbe causare un aumento dell'utilizzo della CPU. Il compromesso tra l'utilizzo e la larghezza di banda della CPU dipende da molti fattori, tra cui il tipo di dati di log, la compressione dei dati, la disponibilità delle cicli di CPU sull'host che esegue il forwarding e la necessità di ridurre il consumo della larghezza di banda della rete.

Ad esempio, i log basati su testo si comprimeno bene e possono offrire notevoli risparmi di larghezza di banda con un utilizzo ridotto della CPU. Tuttavia, i payload criptati dei pacchetti non elaborati non si comprimeno bene e richiedono un maggiore utilizzo della CPU.

La compressione dei log è disattivata per impostazione predefinita. L'attivazione della compressione dei log potrebbe ridurre il consumo della larghezza di banda. Tuttavia, l'attivazione della compressione dei log potrebbe anche aumentare l'utilizzo della CPU. Sii consapevole del compromesso.

Per attivare la compressione dei log, imposta il campo compression su true nel file di configurazione dell'inoltro di Chronicle, come illustrato nell'esempio seguente:

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
      secret_key: |
        {
          "type": "service_account",
...

Buffer del disco

Il buffering del disco ti consente di eseguire il buffering di messaggi con backlog su disco anziché la memoria. I messaggi in backlog possono essere archiviati in caso di arresto anomalo dell'inoltro o di arresto anomalo dell'host sottostante. Tieni presente che l'abilitazione del buffering del disco può influire sulle prestazioni.

Nota: se ricevi il messaggio di errore "Limite batch (xxx) raggiunto, liberando un batch dal backlog" e aumentando max_file_buffer_byte a 1 GB o più.

Nota: se il buffering del disco è disattivato, lo strumento di inoltro utilizza 1 GB di memoria (RAM) per ciascun tipo di log (ad esempio per connettore). Specifica il parametro di configurazione max_memory_buffer_bytes. Il limite massimo consentito è 4 GB.

Se esegui l'inoltro utilizzando Docker, Google consiglia di montare un volume separato dal volume di configurazione per scopi di isolamento. Inoltre, ogni input deve essere isolato con la propria directory o con il proprio volume per evitare conflitti.

Configurazione di esempio: buffering del disco

La seguente configurazione include la sintassi per abilitare il buffering del disco:

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the forwarder
      write_to_disk_dir_path: /buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Filtri per espressioni regolari

I filtri delle espressioni regolari consentono di filtrare i log in base a corrispondenze di espressioni regolari rispetto ai log non elaborati.

I filtri utilizzano la sintassi RE2 descritta qui: https://github.com/google/re2/wiki/Sintassi

I filtri devono includere un'espressione regolare e, facoltativamente, definire un comportamento in caso di corrispondenza. Il comportamento predefinito in una corrispondenza è un blocco (puoi anche configurarlo esplicitamente come blocco).

In alternativa, puoi specificare i filtri con il comportamento allow. Se specifichi dei filtri di autorizzazione, l'inoltro blocca tutti i log che non corrispondono ad almeno un filtro di autorizzazione.

È possibile definire un numero arbitrario di filtri. I filtri di blocco hanno la precedenza sui filtri di autorizzazione.

Quando vengono definiti i filtri, devono essere assegnati un nome. I nomi dei filtri attivi verranno segnalati a Chronicle tramite le metriche relative allo stato di inoltro. I filtri definiti nella directory principale della configurazione vengono uniti con i filtri definiti a livello di raccoglitore. In caso di nomi in conflitto, i filtri a livello di raccoglitore hanno la precedenza. Se non vengono definiti filtri a livello di directory principale o di collettore, il comportamento consiste nel consentire tutti.

Esempio di configurazione: filtri con espressioni regolari

Nella seguente configurazione dello strumento di inoltro, i log WINEVTLOG che non corrispondono al filtro root (allow_filter) vengono bloccati. Data l'espressione regolare, il filtro consente solo i log con priorità comprese tra 0 e 99. Tuttavia, tutti i log NIX_SYSTEM contenenti 'foo' o 'bar' sono bloccati, nonostante allow_filter. Questo perché i filtri utilizzano un operatore logico OR. Tutti i log vengono elaborati fino all'attivazione di un filtro.

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Etichette arbitrarie

Le etichette vengono utilizzate per collegare metadati arbitrari ai log tramite coppie chiave-valore. Le etichette possono essere configurate per un intero inoltro o all'interno di uno specifico raccoglitore di uno strumento di inoltro. Se vengono forniti entrambi, le etichette vengono unite alle chiavi raccoglitore che hanno la precedenza sulle chiavi Inoltra.

Configurazione di esempio: etichette arbitrarie

Nella seguente configurazione di Inoltra, le 'foo=bar' e 'meow=mix' coppie di chiavi e valore sono entrambe collegate ai log WINEVTLOG e le coppie 'foo=baz' e 'meow=mix' sono collegate le coppie chiave e valore.

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Spazi dei nomi

Utilizza le etichette dello spazio dei nomi per identificare i log di segmenti di rete distinti e creare conflitti tra gli indirizzi IP sovrapposti. Puoi configurare un'etichetta dello spazio dei nomi per un inoltro completo o all'interno di uno specifico raccoglitore dello strumento di inoltro. Se sono inclusi entrambi, lo spazio dei nomi di Collector specifico ha la precedenza.

Qualsiasi spazio dei nomi configurato per lo strumento di inoltro viene visualizzato con le risorse associate nell'interfaccia utente di Chronicle. Puoi anche cercare spazi dei nomi utilizzando la funzionalità Search Chronicle.

Per informazioni su come visualizzare gli spazi dei nomi nell'interfaccia utente di Chronicle, visita questa pagina.

Esempio di configurazione: spazi dei nomi

Nella seguente configurazione dello strumento di inoltro, i log WINEVTLOG sono collegati allo spazio dei nomi FORWARDER, mentre i log di NIX_SYSTEM sono associati allo spazio dei nomi CORPORATE.

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Ingresso Kafka

Puoi importare dati da argomenti Kafka esattamente come puoi fare per syslog. I gruppi consumer vengono utilizzati per permetterti di eseguire il deployment di un massimo di tre server di inoltro e di estrarre i dati dallo stesso argomento con Kafka.

Nota: per importare dati da argomenti Kafka, devi configurare le connessioni TLS come mostrato nell'esempio di seguito.

Per ulteriori informazioni sui gruppi di utenti di Kafka, consulta: https://docs.confluent.io/platform/current/clients/consumer.html

Esempio di configurazione: input Kafka

La seguente configurazione dello strumento di inoltro mostra come configurare lo strumento di inoltro per importare dati da argomenti di Kafka:

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      username: user
      password: password
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "/path/to/cert.pem"
        certificate_key: "/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Bilanciamento del carico e alta disponibilità

È possibile eseguire il deployment dell'inoltro Linux Chronicle in un ambiente in cui è installato un bilanciatore del carico di livello 4 tra l'origine dati e le istanze di inoltro. Questo consente a un cliente di distribuire la raccolta di log tra più inoltri o di inviare i log a uno strumento di inoltro diverso se uno non riesce. Questa funzionalità è supportata solo per il tipo di raccolta syslog.

L'inoltro Linux include un server HTTP integrato che risponde ai controlli di integrità HTTP dal bilanciatore del carico. Il server HTTP inoltre consente di assicurare che i log non vadano persi durante l'avvio o l'arresto di uno strumento di inoltro.

Configura il server HTTP, il bilanciamento del carico e le opzioni di disponibilità elevata nella sezione server del file di configurazione dello strumento di inoltro. Queste opzioni supportano l'impostazione di durate di timeout e dei codici di stato restituiti in risposta ai controlli di integrità ricevuti nei deployment basati su scheduler dei container e orchestrazione, oltre che ai bilanciatori del carico tradizionali.

Utilizza i seguenti percorsi URL per i controlli di integrità, recupero e attività. I valori <host:port> sono definiti nella configurazione dell'inoltro.

• http://<host:port>/meta/available: controlli di attività per scheduler/orchestratori di container, come Kubernetes
• http://<host:port>/meta/ready: controlli di idoneità e controlli di integrità del bilanciatore del carico tradizionale.

La seguente configurazione dello strumento di inoltro è un esempio per il bilanciamento del carico e l'alta disponibilità:

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503

Percorso di configurazione	Descrizione
server : Graful_timeout	Periodo di tempo durante il quale lo strumento di inoltro restituisce un controllo di idoneità/integrità non valido e continua a accettare nuove connessioni. Questo è anche il tempo di attesa tra la ricezione di un segnale per l'arresto e l'avvio effettivo della chiusura del server stesso. In questo modo, il bilanciatore del carico avrà il tempo di rimuovere il forwarding dal pool.
server : scarichi_timeout	Periodo di tempo in cui l'inoltro lascia in attesa che le connessioni attive si concludano autonomamente prima di essere chiuse dal server.
server : http : porta	Numero di porta su cui il server HTTP rimane in ascolto per i controlli di integrità del bilanciatore del carico. Deve essere compreso tra 1024 e 65535.
server : http : host	Indirizzo IP o nome host che può essere risolto in indirizzi IP su cui il server deve rimanere in ascolto. Se vuoto, il valore predefinito è il sistema locale (0.0.0.0).
server : http : read_timeout	Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Tempo massimo consentito per leggere l'intera richiesta, sia l'intestazione sia il corpo. Puoi impostare sia read_timeout che read_header_timeout.
server : http : read_header_timeout	Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Tempo massimo di lettura delle intestazioni delle richieste consentito. La scadenza della lettura della connessione viene reimpostata dopo aver letto l'intestazione.
server : http : write_timeout	Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Tempo massimo di invio di una risposta. ma viene reimpostato quando viene letta una nuova intestazione della richiesta.
server : http : inattività_timeout	Utilizzato per ottimizzare il server HTTP. In genere, non è necessario modificare l'impostazione predefinita. Tempo massimo di attesa della richiesta successiva quando sono abilitate le connessioni inattive. Se idle_timout è zero, viene utilizzato il valore di read_timout. Se entrambi sono zero, viene utilizzato il valore read_header_timeout.
route : meta : ready_status	Codice di stato restituito dall'inoltro quando è pronto per accettare il traffico in una delle seguenti situazioni: Il controllo di idoneità viene ricevuto da uno scheduler di container o da un orchestratore, come Kubernetes. Il controllo di integrità viene ricevuto da un bilanciatore del carico tradizionale.
route : meta : stato_pronto	Il codice di stato restituito dall'inoltro quando non è pronto ad accettare traffico.
route : meta : disponibile_stato	Il codice di stato restituito dall'inoltro alla ricezione di un controllo di attività e che è disponibile. I controlli di attività vengono spesso inviati da programmatori/orchestratori di container come Kubernetes.

Domande frequenti

Che cos'è un container Docker?

• I container Docker, come le macchine virtuali, offrono ulteriore sicurezza, isolamento e gestione delle risorse.

• Le macchine virtuali hanno sia uno spazio con privilegi (kernel Linux) sia uno spazio utente (tutti gli utenti con cui interagisci: libc, python, ls, tcpdump e così via).

• I container hanno uno spazio utente (tutti gli elementi con cui interagisci: libc, python, ls, tcpdump e così via) e si basano sullo spazio di privilegi dell'host.

Perché distribuire lo strumento di inoltro di Chronicle utilizzando un container?

• Maggiore sicurezza grazie all'isolamento:
  • L'ambiente e i requisiti dei clienti non influiscono sull'inoltro di Chronicle.
  • L'ambiente di inoltro di Chronicle e i requisiti non influiscono sul cliente.
  • Il meccanismo di distribuzione dei container esiste già e può essere privato e separato per Google Cloud e per i clienti. https://cloud.google.com/container-registry/

Perché solo Linux per i container? Come funziona con Windows?

• I container sono stati sviluppati prima per Linux e sono pronti per la produzione.

• Il supporto di Windows per i container è migliorato. I container sono disponibili per Windows Server 2016 e Windows 10.

Ti serve imparare a utilizzare i comandi Docker avanzati?

• L'inoltro di Chronicle utilizza un singolo container, quindi non è necessario conoscere Swarm, orchestrazione, Kubernetes o altri comandi o comandi avanzati di Docker.