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.
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.
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.
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.
Connettiti al tuo inoltro Linux tramite terminale.
Crea un nuovo utente nello strumento di inoltro Linux.
# adduser <username>
# passwd <username>
# usermod -aG wheel <username>
Modifica la directory nella home directory del nuovo utente che eseguirà Docker Container.
Crea una directory per archiviare i file di configurazione dell'inoltro di Chronicle:
# mkdir ~/config
Cambiare la directory
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.
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
Ottieni l'immagine Docker più recente da Google Cloud:
# docker pull gcr.io/chronicle-container/cf_production_stable
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"
Il valore dei batch_n_byte non deve superare 5 MB.
Puoi creare una directory dei certificati nella directory di configurazione e memorizzarvi i file del certificato.
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:
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.
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.
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:
|
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.