Como instalar e configurar o encaminhador no Linux
Este documento descreve como instalar e configurar o encaminhador no Linux. É possível instalar o encaminhador em várias distribuições Linux (Debian, Ubuntu, Red Hat, Suse etc.). O Google Cloud fornece o software usando um contêiner do Docker. É possível executar e gerenciar o contêiner do Docker em uma máquina física ou virtual que executa o Linux.
Personalizar os arquivos de configuração
Com base nas informações enviadas antes da implantação, o Google Cloud fornece o software de encaminhamento e os arquivos de configuração. O Google Cloud orienta os arquivos de configuração para a instância de encaminhamento na sua rede. Se precisar alterar a configuração, entre em contato com o Suporte do Chronicle.
Requisitos do sistema
Veja a seguir recomendações gerais. Para ver recomendações específicas ao seu sistema, entre em contato com o suporte do Chronicle.
RAM: 1,5 GB para cada tipo de dado coletado. Por exemplo, detecção e resposta de endpoint (EDR), DNS e DHCP são tipos de dados distintos. Você precisa de 4,5 GB de RAM para coletar todos os três.
CPU: duas CPUs são suficientes para processar menos de 10.000 eventos por segundo (EPS,na sigla em inglês) (total para todos os tipos de dados). Se você quer encaminhar mais de 10.000 EPS, provisione de 4 a 6 CPUs.
Disco: 100 MB de espaço em disco são suficientes, independentemente da quantidade de dados que o encaminhador do Chronicle processa. Consulte também Buffers de disco se precisar armazenar em buffer mensagens enviadas para o disco, em vez de na memória. O encaminhador do Chronicle armazena em buffer por padrão a memória.
Verifique a configuração do firewall
Se você tiver firewalls ou proxies autenticados entre o contêiner de encaminhamento do Chronicle e a Internet, eles precisarão de regras para abrir o acesso aos seguintes hosts:
Tipo de conexão | Destino | 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 |
Coletar dados do Splunk
É possível configurar o encaminhador do Chronicle para encaminhar seus dados do Splunk para o Chronicle. O Google Cloud configura o encaminhador do Chronicle com as seguintes informações para encaminhar os dados do Splunk:
URL da API REST do Splunk (por exemplo, https://10.0.113.15:8889).
Consultas do Splunk para gerar dados para cada um dos tipos de dados necessários (por exemplo, index=dns).
É necessário disponibilizar as credenciais da sua conta do Splunk para o encaminhamento do Chronicle.
Crie um arquivo local para as credenciais do Splunk e nomeie-o como creds.txt. Coloque seu nome de usuário na primeira linha e a senha na segunda linha:
cat creds-file
myusername
mypassword
Para clientes que usam o encaminhador do Chronicle para acessar uma instância do Splunk, copie o arquivo creds.txt para o diretório de configuração (o mesmo diretório dos arquivos de configuração). Exemplo:
cp creds-file ~/config/creds.txt
Verifique se o arquivo creds.txtem> está no local adequado:
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: o período mínimo passado para a consulta do Splunk. O valor padrão é de 10 segundos. Esse parâmetro é usado para ajustar se o requisito é mudar a frequência com que o servidor do Splunk é consultado quando o encaminhador está em estado estável. Além disso, quando há atraso, a chamada de API do Splunk pode ser feita várias vezes.
maximum_window_size: o período máximo passado para a consulta do Splunk. O valor padrão é de 30 segundos. Esse parâmetro é usado para ajustar os casos em que há atraso e se mais dados por consulta são necessários.
Altere esse parâmetro (igual ou maior que) quando você alterar o parâmetro mínimo. Os casos de atraso podem ocorrer quando uma chamada de consulta do Splunk está demorando mais do que o valor de max_window_size.
Instalar o Docker
Você pode instalar o Docker em vários sistemas operacionais host. A instalação real do Docker depende do ambiente do host. O Google Cloud tem uma documentação limitada que ajuda a instalar o Docker em várias das distribuições Linux mais conhecidas. No entanto, o Docker é de código aberto e a documentação substancial já está disponível.
Depois de instalar o Docker no sistema, o restante do processo de instalação do encaminhador do Chronicle é idêntico, independentemente da distribuição do Linux usada.
Verifique se o Docker está instalado no sistema executando o seguinte comando (privilégios elevados):
# docker ps
A resposta a seguir indica que o Docker foi instalado corretamente:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Use o comando a seguir para coletar outras informações sobre a instalação do Docker:
# docker info
Se você tiver problemas com o Docker, o Chronicle Support poderá solicitar a saída desse comando para ajudar na depuração.
Instalar o encaminhador
Nesta seção, descrevemos como instalar o Chronicle Forwarder usando um contêiner do Docker em um sistema Linux.
Etapa 1. Fazer o download, transferir e instalar os arquivos de configuração do encaminhador
O Google Cloud fornece arquivos de configuração de encaminhamento específicos para seu sistema operacional (Linux ou Windows). Faça download dos arquivos do link fornecido pelo seu representante do Chronicle para um diretório local no seu laptop (por exemplo, crronicle). Depois de concluir as etapas a seguir, transfira os arquivos de configuração do laptop para o diretório ~/config do encaminhamento no diretório inicial do usuário.
Conecte-se ao encaminhador do Linux por meio do terminal.
Crie um novo usuário no encaminhador do Linux.
# adduser <username>
# passwd <username>
# usermod -aG wheel <username>
Altere o diretório para o diretório principal do novo usuário que executará o contêiner do Docker.
Crie um diretório para armazenar os arquivos de configuração do encaminhador do Chronicle:
# mkdir ~/config
Alterar o diretório
Depois de transferir os arquivos, confirme se os arquivos de configuração estão no diretório ~/config:
# ls -l
Etapa 2. Executar o encaminhador no contêiner do Docker
Você pode usar os procedimentos a seguir para iniciar o encaminhador do Chronicle pela primeira vez e também para fazer upgrade para a versão mais recente do contêiner do Chronicle:
As opções --log-opt
estão disponíveis desde o Docker
1.13. Essas opções limitam o tamanho dos arquivos de registros de contêiner e
precisam ser usadas desde que sua versão do Docker seja compatível com elas.
Se você estiver fazendo upgrade, comece limpando todas as execuções anteriores do Docker. No exemplo a seguir, o nome do contêiner do Docker é
cfps
. Em seguida, acesse a imagem do Docker mais recente do Google Cloud com o comando # docker pull abaixo.# docker stop cfps # docker rm cfps
Consiga a imagem mais recente do Docker do Google Cloud:
# docker pull gcr.io/chronicle-container/cf_production_stable
Inicie o encaminhador do Chronicle no contêiner do 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
Esses comandos também são fornecidos como um script de shell chamado run_docker_production_stable.sh
.
O contêiner do Docker (e o encaminhador do Chronicle) persiste após a reinicialização do sistema.
Etapa 3. Monitorar e gerenciar o encaminhador
Os comandos do Docker a seguir ajudam a monitorar e gerenciar o encaminhador do Chronicle:
Verifique se o contêiner do Docker está em execução:
docker ps
Exiba os registros do contêiner. Isso pode gerar um volume substancial de saída, mas é útil para depuração:
docker logs cfps
Para ver o que está sendo executado no contêiner, faça o seguinte:
docker top cfps
Para interromper o contêiner:
docker stop cfps
Coletar dados de syslog
O encaminhamento do Chronicle pode operar como um servidor Syslog, o que significa que você pode configurar qualquer dispositivo ou servidor compatível com o envio de dados de syslog por uma conexão TCP ou UDP para encaminhar os dados para o encaminhamento do Chronicle. Você pode controlar quais dados o dispositivo ou servidor envia ao encaminhador do Chronicle. O encaminhador do Chronicle pode então encaminhar os dados para o Chronicle.
O arquivo de configuração (fornecido pelo Google Cloud) especifica quais portas você quer monitorar para cada tipo de dado encaminhado (por exemplo, porta 10514). Por padrão, o encaminhador do Chronicle aceita conexões TCP e UDP.
Configurar rsyslog
Para configurar o rsyslog, é necessário especificar um destino para cada porta (por exemplo, cada tipo de dados). Consulte a sintaxe do seu sistema na documentação. Os exemplos a seguir ilustram uma configuração de destino rsyslog:
Tráfego de registro TCP:
dns.* @192.168.0.12:10514
Tráfego de registro UDP:
dns.* @192.168.0.12:10514
Ativar o TLS para configurações do syslog
Você pode ativar o TLS para a conexão do Syslog com o encaminhador do Chronicle. No arquivo de configuração do encaminhador do Chronicle, especifique o local do próprio certificado gerado e da chave de certificado, conforme mostrado no exemplo a seguir:
certificado | "/opt/chronicle/external/certs/client_generated_cert.pem" |
Chave_de_certificado | "/opt/chronicle/external/certs/client_generated_cert.key" |
Com base no exemplo mostrado, a configuração do encaminhador do Chronicle seria
modificada da seguinte maneira:
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"
O valor de batch_n_bytes não deve exceder 5 MB.
É possível criar um diretório de certificados no diretório de configuração e armazenar os arquivos de certificado nele.
Coletar dados de arquivos
Inicie o encaminhador do Chronicle no contêiner do 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
Esse comando docker run é essencial para mapear o volume de carregamento para o contêiner.
Com base neste exemplo, você modificaria a configuração do encaminhador do Chronicle da seguinte maneira:
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:
Coletar dados de pacote
O encaminhador do Chronicle pode capturar pacotes diretamente de uma interface de rede usando o libpcap no Linux. Os pacotes são capturados e enviados ao Chronicle em vez de entradas de registro. A captura de pacotes é processada apenas a partir de uma interface local. Para ativar a captura de pacotes no seu sistema, entre em contato com o suporte do Chronicle.
O Google Cloud configura o encaminhador do Chronicle com a expressão Berkeley Packet Filter (BPF) usada ao capturar pacotes (por exemplo, porta 53 e não localhost).
Alternar a compactação de dados
A compactação de registros reduz o consumo de largura de banda da rede ao transferir registros para o Chronicle. No entanto, a compactação pode causar um aumento no uso da CPU. A compensação entre o uso de CPU e a largura de banda depende de muitos fatores, incluindo o tipo de dados de registro, a compactação desses dados, a disponibilidade de ciclos de CPU no host que executa o encaminhador e a necessidade de reduzir o consumo de largura de banda da rede.
Por exemplo, os registros baseados em texto são compactados com eficiência e podem economizar muito largura de banda com baixo uso da CPU. No entanto, os payloads criptografados de pacotes brutos não compactam bem e geram maior uso da CPU.
A compactação de registros fica desativada por padrão. Ativar a compactação de registros pode reduzir o consumo da largura de banda. No entanto, ativar a compactação de registros também pode aumentar o uso da CPU. Esteja ciente das vantagens e desvantagens.
Para ativar a compactação de registros, defina o campo compactação como true no arquivo de configuração do encaminhador do Chronicle, conforme mostrado no exemplo a seguir:
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", ...
Armazenando em buffer do disco
O armazenamento em buffer do disco permite que você armazene em buffer mensagens de backlog no disco, em vez de memória. As mensagens de backlog podem ser armazenadas caso o encaminhador ou o host subjacente falhem. Esteja ciente de que a ativação do armazenamento em buffer do disco pode afetar o desempenho.
Se você estiver executando o encaminhador usando o Docker, o Google recomenda montar um volume separado do volume de configuração para fins de isolamento. Além disso, cada entrada deve ser isolada com seu próprio diretório ou volume para evitar conflitos.
Exemplo de configuração: armazenamento em buffer do disco
A configuração a seguir inclui sintaxe para ativar o armazenamento em buffer do 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
Filtros de expressão regular
Os filtros de expressão regular permitem filtrar registros com base em correspondências de expressões regulares com base em registros brutos.
Os filtros empregam a sintaxe RE2 descrita aqui: https://github.com/google/re2/wiki/Sintaxe
Os filtros precisam incluir uma expressão regular e, como opção, definir um comportamento quando houver uma correspondência. O comportamento padrão em uma correspondência é bloquear. Também é possível configurá-lo explicitamente como bloqueio.
Como alternativa, os filtros podem ser especificados com o comportamento allow
. Se você especificar
qualquer filtro de permissão, o encaminhamento bloqueará todos os registros que não corresponderem a pelo menos um
filtro de permissão.
É possível definir um número arbitrário de filtros. Os filtros de bloco têm prioridade sobre os filtros de permissão.
Quando os filtros são definidos, é necessário atribuir um nome a eles. Os nomes dos filtros ativos serão informados ao Chronicle por meio das métricas de integridade do encaminhador. Os filtros definidos na raiz da configuração são mesclados com os filtros definidos no nível do coletor. Os filtros no nível do coletor têm precedência em casos de nomes conflitantes. Se nenhum filtro for definido no nível raiz ou do coletor, o comportamento será permitir todos.
Exemplo de configuração: filtros de expressão regular
Na configuração do encaminhador, os registros WINEVTLOG que não correspondem ao
filtro raiz (allow_filter
) são bloqueados. Dada a expressão regular, o filtro permite apenas registros com prioridades entre 0 e 99. No entanto, todos os registros NIX_SYSTEM que contêm
'foo' ou 'bar' são bloqueados, apesar de allow_filter
. Isso ocorre porque os filtros usam um operador lógico "OR". Todos os registros são processados até que um filtro seja acionado.
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
Etiquetas arbitrárias
Os rótulos são usados para anexar metadados arbitrários aos registros usando pares de chave e valor. Os rótulos podem ser configurados para um encaminhador inteiro ou dentro de um coletor específico de um encaminhador. Se ambos forem fornecidos, os rótulos serão mesclados com as chaves do coletor, que terão precedência sobre as chaves do encaminhador, se as chaves se sobrepuserem.
Exemplo de configuração: rótulos arbitrários
Na configuração do encaminhador a seguir, os pares de chave-valor e 'foo=bar' e #39;meow=mix' são anexados aos registros WINEVTLOG, e os pares de chave e valor 'foo=baz' e ##99;meow=mix' são anexados aos registros NIX_SYSTEM.
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
Namespaces
Use rótulos de namespace para identificar registros de diferentes segmentos de rede e conflitar os endereços IP sobrepostos. É possível configurar um rótulo de namespace para todo um encaminhador ou dentro de um coletor específico do encaminhador. Se ambos forem incluídos, o namespace do coletor específico terá precedência.
Qualquer namespace configurado para o encaminhador aparece com os recursos associados na interface do usuário do Chronicle. Também é possível pesquisar namespaces usando o recurso Chronicle Search.
Para mais informações sobre como visualizar namespaces na interface do usuário do Chronicle, consulte este link.
Exemplo de configuração: namespaces
Na configuração do encaminhador, os registros WINEVTLOG são anexados ao namespace FORWARDER e os registros NIX_SYSTEM são anexados ao namespace 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
Entrada do Kafka
É possível ingerir dados de tópicos do Kafka da mesma forma que para o syslog. Os grupos de consumidores são utilizados para permitir a implantação de até três encaminhadores e a extração de dados do mesmo tópico do Kafka.
Para mais informações sobre grupos de consumidores de Kafka, consulte: https://docs.confluent.io/platform/current/clients/consumer.html.
Exemplo de configuração: entrada do Kafka
A configuração do encaminhador a seguir mostra como configurá-lo para ingerir dados de tópicos do 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
Balanceamento de carga e alta disponibilidade
O encaminhador do Chronicle Linux pode ser implantado em um ambiente em que um balanceador de carga da camada 4 está instalado entre a origem de dados e as instâncias do encaminhador. Isso permite que um cliente distribua a coleta de registros em vários encaminhadores ou envie registros para outro encaminhamento se houver falha. Esse recurso é compatível apenas com o tipo de coleção syslog.
O encaminhador do Linux inclui um servidor HTTP integrado que responde a verificações de integridade HTTP do balanceador de carga. O servidor HTTP também ajuda a garantir que os registros não sejam perdidos durante a inicialização ou o encerramento de um encaminhador.
Configure o servidor HTTP, o balanceamento de carga e as opções de alta disponibilidade na seção servidor do arquivo de configuração do encaminhador. Essas opções oferecem suporte à definição de durações de tempo limite e códigos de status retornados em resposta a verificações de integridade recebidas em implantações baseadas em orquestração e programador de contêineres, bem como em balanceadores de carga tradicionais.
Use os seguintes caminhos de URL para verificações de integridade, prontidão e atividade. Os valores <host:port>
são definidos na configuração do encaminhador.
- http://
<host:port>
/meta/available: verificações de atividade para programadores/orquestradores de contêineres, como o Kubernetes. - http://
<host:port>
/meta/ready: verificações de prontidão e verificações de integridade do balanceador de carga tradicional.
A configuração de encaminhamento a seguir é um exemplo de balanceamento de carga e alta disponibilidade:
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
Caminho da configuração | Descrição |
---|---|
servidor : Graceful_timeout | Tempo que o encaminhamento retorna uma verificação de prontidão/saúde ruim e ainda aceita novas conexões. Esse também é o tempo de espera entre o recebimento de um sinal e o início do encerramento do próprio servidor. Isso permite que o tempo do balanceador de carga remova o encaminhador do pool. |
servidor : dred_timeout | Quantidade de tempo que o encaminhamento aguarda até que as conexões ativas sejam fechadas por conta própria antes de serem fechadas pelo servidor. |
servidor : http : porta | Número da porta que o servidor HTTP detecta para verificações de integridade do balanceador de carga. Precisa estar entre 1024-65535. |
servidor : http : host | Endereços IP ou nome do host que podem ser resolvidos para endereços IP que o servidor precisa detectar. Se estiver vazio, o valor padrão será o sistema local (0.0.0.0). |
servidor : http : read_timeout | Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. Tempo máximo permitido para ler toda a solicitação, o cabeçalho e o corpo. É possível definir read_timeout e read_header_timeout. |
servidor : http : read_header_timeout | Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. Tempo máximo permitido para ler cabeçalhos de solicitação. O prazo de leitura da conexão é redefinido depois da leitura do cabeçalho. |
servidor : http : write_timeout | Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. Tempo máximo permitido para enviar uma resposta. Ele é redefinido quando um novo cabeçalho de solicitação é lido. |
servidor : http : inatividade_tempo limite | Usado para ajustar o servidor HTTP. Normalmente, não precisa ser alterado da configuração padrão. Tempo máximo de espera para a próxima solicitação quando as conexões inativas estiverem ativadas. Se o inatividade de nenhum valor for zero, o valor de read_timout será usado. Se ambos forem zero, read_header_timeout será usado. |
routes : meta : pronto_status | O código de status que o encaminhador retorna quando está pronto para aceitar tráfego em uma destas situações:
|
routes : meta : não lida com status | Código de status que o encaminhador retorna quando não está pronto para aceitar o tráfego. |
routes : meta : available_status | Código de status que o encaminhador retorna quando uma verificação de atividade é recebida e o encaminhador está disponível. As verificações de atividade geralmente são enviadas por programadores/orquestradores de contêineres, como o Kubernetes. |
Perguntas frequentes
O que é um contêiner do Docker?
Os contêineres do Docker, como as máquinas virtuais, fornecem mais segurança, isolamento e gerenciamento de recursos.
Máquinas virtuais: têm um espaço privilegiado (kernel do Linux) e um espaço de usuário (tudo com que você interage: libc, python, ls, tcpdump etc.).
Os contêineres têm apenas um espaço de usuário (tudo o que você interage com: libc, python, ls, tcpdump etc.) e dependem do espaço de privilégios do host.
Por que distribuir um encaminhamento do Chronicle usando um contêiner?
- Mais segurança com o isolamento:
- O ambiente e os requisitos do cliente não afetam o encaminhamento do Chronicle.
- O ambiente e os requisitos do encaminhador do Chronicle não afetam o cliente.
- O mecanismo de distribuição de contêiner já existe e pode ser privado e separado para o Google Cloud e os clientes. https://cloud.google.com/container-registry/
Por que apenas o Linux para contêineres? E o Windows?
Os contêineres foram desenvolvidos primeiro para Linux e estão prontos para produção.
A compatibilidade do Windows com contêineres está melhorando. Os contêineres estão disponíveis para o Windows Server 2016 e o Windows 10.
Você precisa aprender comandos avançados do Docker?
- O encaminhamento do Chronicle usa um único contêiner, então você não precisa saber sobre o Swarm, orquestração, Kubernetes ou outros conceitos ou comandos avançados do Docker.