Instala y configura el servidor de reenvío en Linux

En este documento, se describe cómo instalar y configurar el servidor de reenvío en Linux. Puedes instalar el servidor de reenvío en una variedad de distribuciones de Linux (Debian, Ubuntu, Red Hat, Suse, etcétera). Google Cloud proporciona el software mediante un contenedor de Docker. Puedes ejecutar y administrar el contenedor de Docker en una máquina física o virtual que ejecute Linux.

Cómo personalizar los archivos de configuración

Según la información que enviaste antes de la implementación, Google Cloud te proporciona el software de reenvío y los archivos de configuración. Google Cloud adapta tus archivos de configuración a la instancia de reenvío en tu red. Si necesitas modificar la configuración, comunícate con el equipo de asistencia de Chronicle.

Requisitos del sistema

Las siguientes son recomendaciones generales. Para obtener recomendaciones específicas de tu sistema, comunícate con el equipo de asistencia de Chronicle.

  • RAM: 1.5 GB para cada tipo de datos recopilados. Por ejemplo, la detección y la respuesta de extremos (EDR), el DNS y el DHCP son tipos de datos separados. Necesitará 4.5 GB de RAM para recopilar datos de los tres.

  • CPU: dos CPU son suficientes para manejar menos de 10,000 eventos por segundo (EPS) (total para todos los tipos de datos). Si planeas reenviar más de 10,000 EPS, aprovisiona de 4 a 6 CPU.

  • Disco: 100 MB de espacio en disco es suficiente, independientemente de la cantidad de datos que administre el reenvío de Chronicle. Consulta también Cómo almacenar en búfer el disco si necesitas almacenar en búfer los mensajes pendientes en el disco en lugar de hacerlo en la memoria. El servidor de reenvío de Chronicle almacena en búfer en la memoria de manera predeterminada.

Verifica la configuración del firewall

Si tienes firewalls o proxies autenticados entre el contenedor de reenvío de Chronicle y Internet, estos requieren reglas para abrir el acceso a los siguientes hosts:

Tipo de conexión Destino Puerto
TCP malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443

Instala Docker

Puedes instalar Docker en diversos sistemas operativos de host. La instalación real de Docker depende del entorno de host. Google Cloud proporciona documentación limitada para ayudarte a instalar Docker en varias de las distribuciones de Linux más populares. Sin embargo, Docker es de código abierto y hay documentación sustancial disponible.

Una vez que hayas instalado Docker en tu sistema, el resto del proceso de instalación del servidor de reenvío de Chronicle es idéntico, independientemente de la distribución de Linux que uses.

Verifique que Docker esté instalado en su sistema mediante la ejecución del siguiente comando (privilegios elevados):

# docker ps

La siguiente respuesta indica que Docker se instaló correctamente:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Puedes recopilar información adicional sobre tu instalación de Docker mediante el siguiente comando:

# docker info

Si tienes problemas con Docker, la asistencia de Chronicle podría solicitar el resultado de este comando para ayudar con la depuración.

Instala el servidor de reenvío

En esta sección, se describe cómo instalar Chronicle Forwarder mediante un contenedor de Docker en un sistema Linux.

Paso 1: Descarga, transfiere e instala los archivos de configuración de reenvíos

Google Cloud proporciona archivos de configuración de reenvío específicos del sistema operativo (Linux o Windows). Descarga los archivos del vínculo proporcionado por tu representante de Chronicle a un directorio local en tu laptop (por ejemplo, crónica). Después de completar los siguientes pasos, transfiere los archivos de configuración de tu laptop al directorio forward/config de reenvío dentro del directorio principal del usuario.

  1. Conéctate a tu servidor de reenvío de Linux mediante una terminal.

  2. Crea un usuario nuevo en el servidor de reenvío de Linux.

    # adduser <username>

    # passwd <username>

    # usermod -aG wheel <username>

  3. Cambia el directorio al directorio principal del usuario nuevo que ejecutará Docker Container.

  4. Crea un directorio para almacenar los archivos de configuración de reenvío de Chronicle: # mkdir ~/config

  5. Cambia de directorio

  6. Una vez que se hayan transferido los archivos, confirme que los archivos de configuración se encuentren en el directorio ~/config:

    # ls -l

Paso 2: Instala la clave para Chronicle Container Registry

El archivo JSON proporcionado por Google Cloud (el archivo tiene una extensión .json) contiene las credenciales necesarias para acceder al registro de Docker de Chronicle.

  1. Copia el siguiente texto del comando (incluidos los saltos de línea) a un editor de texto y cambia el nombre del archivo .json entre corchetes al nombre de tu archivo de autenticación de Docker de Chronicle.

      docker login \
    
         -u _json_key \
    
         --password-stdin \
    
         https://gcr.io < ./chronicle-container-c2da10b71454-oneline.json
    
  2. Cuando termine de editar, copie el texto del comando completo y ejecútelo desde el directorio ~/config en el servidor de reenvío de Linux.

  3. El resultado del comando de acceso de Docker anterior debería ser "Acceso exitoso".

Si tienes un problema, confirma que la versión de Docker esté en ejecución:

# docker version

Las versiones anteriores de Docker (por ejemplo, 1.13.1) pueden requerir argumentos de línea de comandos diferentes. Las diferencias se indican a continuación.

Paso 2 para versiones anteriores de Docker que no son compatibles con --password-stdin

En el caso de versiones anteriores de Docker (versiones que no aceptan --password-stdin), copia el contenido del archivo JSON y pégalo en el mensaje de contraseña.

  1. Ejecuta el siguiente comando:

    $ cat ./<filename>.json

  2. Copie el resultado del comando cat.

  3. Accede a Docker:

    docker login -u _json_key https://gcr.io

  4. Cuando aparezca el cuadro Password:, pega el contenido del portapapeles.

    Sin importar cómo proporciones la contraseña (--password-stdin o copiar y pegar), el resultado del comando docker login debería ser Login Succeeded.

Paso 3: Ejecuta el servidor de reenvío dentro del contenedor de Docker

Puedes usar los siguientes procedimientos para iniciar el servidor de reenvío de Chronicle por primera vez y actualizar a la versión más reciente del contenedor de Chronicle:

Las opciones de --log-opt están disponibles desde Docker 1.13. Estas opciones limitan el tamaño de los archivos de registro del contenedor y deben usarse siempre y cuando tu versión de Docker las admita.

  1. Si realizas la actualización, realiza una limpieza de cualquier ejecución anterior de Docker. En el siguiente ejemplo, el nombre del contenedor de Docker es cfps y, luego, obtén la última imagen de Docker de Google Cloud con el comando de Docker # a continuación.

    # docker stop cfps
    # docker rm cfps
    
  2. Obtén la imagen de Docker más reciente de Google Cloud:

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

  3. Inicia el reenvío de Chronicle desde el contenedor de 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
    

Estos comandos también se proporcionan como una secuencia de comandos de shell llamada run_docker_production_stable.sh.

El contenedor de Docker (y el servidor de reenvío de Chronicle) persiste después de reiniciar el sistema.

Paso 4: Supervisa y administra el servidor de reenvío

Los siguientes comandos de Docker te ayudan a supervisar y administrar el servidor de reenvío de Chronicle:

  • Verifica si el contenedor de Docker está en ejecución:

    docker ps

  • Muestra los registros del contenedor. Ten en cuenta que esto puede generar un volumen significativo de resultados, pero es útil para la depuración:

    docker logs cfps

  • Para ver qué se ejecuta dentro del contenedor, haga lo siguiente:

    docker top cfps

  • Para detener el contenedor, haz lo siguiente:

    docker stop cfps

Recopila datos de Splunk

Puedes configurar el reenvío de Chronicle para reenviar los datos de Splunk a Chronicle. Google Cloud configura el servidor de reenvío de Chronicle con la siguiente información para reenviar los datos de Splunk:

  • La URL de la API de REST de Splunk (por ejemplo, https://10.0.113.15:8889)

  • Consultas de Splunk a fin de generar datos para cada uno de los tipos de datos requeridos (por ejemplo, index=dns).

Debes hacer que las credenciales de tu cuenta de Splunk estén disponibles para el servidor de reenvío de Chronicle.

Crea un archivo local para tus credenciales de Splunk y asígnale el nombre creds.txt. Coloque su nombre de usuario en la primera línea y la contraseña en la segunda línea:

  cat creds-file

  myusername
  mypassword

Para los clientes que usan el servidor de reenvío de Chronicle para acceder a una instancia de Splunk, copia el archivo creds.txt en el directorio de configuración (el mismo directorio que los archivos de configuración). Por ejemplo:

cp creds-file ~/config/creds.txt

Verifique que el archivo creds.txtem> esté en su ubicación correcta:

ls ~/config

Recopila datos de syslog

El servidor de reenvío de Chronicle puede funcionar como un servidor Syslog, lo que significa que puedes configurar cualquier dispositivo o servidor que admita el envío de datos syslog a través de una conexión TCP o UDP para reenviar sus datos al servidor de reenvío de Chronicle. Puedes controlar exactamente qué datos envía el dispositivo o el servidor al servidor de reenvío de Chronicle. El servidor de reenvío de Chronicle puede reenviar los datos a Chronicle.

El archivo de configuración (proporcionado por Google Cloud) especifica qué puertos se deben supervisar para cada tipo de datos reenviados (por ejemplo, el puerto 10514). De forma predeterminada, el servidor de reenvío de Chronicle acepta conexiones TCP y UDP.

Configura rsyslog

A fin de configurar rsyslog, debes especificar un destino para cada puerto (por ejemplo, cada tipo de datos). Consulta la documentación del sistema para conocer la sintaxis correcta. En los siguientes ejemplos, se ilustra una configuración de destino rsyslog:

  • Tráfico del registro de TCP: dns.* @192.168.0.12:10514

  • Tráfico del registro UDP: dns.* @192.168.0.12:10514

Cómo habilitar TLS para configuraciones de syslog

Puedes habilitar TLS para la conexión de Syslog a la herramienta de reenvío de Chronicle. En el archivo de configuración de reenvío de Chronicle, especifica la ubicación de tu certificado y la clave del certificado, como se muestra en el siguiente ejemplo:

certificado “/opt/chronicle/external/certs/edb3ae966a7bbe1f.pem”
certificado_clave “/opt/chronicle/external/certs/forwarder.key”

Según el ejemplo que se muestra, la configuración de reenvío de Chronicle se modificaría de la siguiente manera:

  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
  connection_timeout_sec: 60
  certificate: "/opt/chronicle/external/certs/edb3ae966a7bbe1f.pem"
  certificate_key: "/opt/chronicle/external/certs/forwarder.key"

Puedes crear un directorio de certificados en el directorio de configuración y almacenar los archivos de certificado allí.

Cómo recopilar datos de paquetes

El servidor de reenvío de Chronicle puede capturar paquetes directamente desde una interfaz de red mediante libpcap en Linux. Los paquetes se capturan y se envían a Chronicle en lugar de entradas de registro. La captura de paquetes solo se maneja desde una interfaz local. Para habilitar la captura de paquetes en tu sistema, comunícate con el equipo de asistencia de Chronicle.

Google Cloud configura el servidor de reenvío de Chronicle con la expresión del filtro de paquetes de Berkeley (BPF) que se usa cuando se capturan paquetes (por ejemplo, el puerto 53 y no localhost).

Activar o desactivar compresión de datos

La compresión de registros reduce el consumo de ancho de banda de red cuando se transfieren registros a Chronicle. Sin embargo, la compresión puede causar un aumento en el uso de la CPU. La compensación entre el uso de CPU y el ancho de banda depende de muchos factores, incluidos el tipo de datos de registro, la compresibilidad de esos datos, la disponibilidad de ciclos de CPU en el host que ejecuta el servidor de reenvío y la necesidad de reducir la red.{101 }el consumo de ancho de banda.

Por ejemplo, los registros basados en texto se comprimen de forma correcta y pueden proporcionar un ahorro sustancial en el ancho de banda con bajo uso de la CPU. Sin embargo, las cargas útiles encriptadas de los paquetes sin procesar no se comprimen bien y generan un mayor uso de la CPU.

Debido a que la mayoría de los tipos de registro que transfiere el servidor de reenvío se pueden comprimir de manera eficiente, la compresión de registros está habilitada de forma predeterminada para reducir el consumo de ancho de banda. Sin embargo, si el aumento en el uso de la CPU supera el beneficio de los ahorros de ancho de banda, puedes inhabilitar la compresión si configuras lacompresión campo parafalso En el archivo de configuración de reenvío de Chronicle, como se muestra en el siguiente ejemplo:

output:
  compression: false
    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",
...

Almacenamiento en búfer del disco

El almacenamiento en búfer de disco te permite almacenar en búfer los mensajes pendientes en el disco, en lugar de hacerlo en la memoria. Los mensajes de tareas pendientes se pueden almacenar en caso de que el servidor de reenvío falle o el host subyacente falle. Ten en cuenta que habilitar el almacenamiento en búfer de discos puede afectar el rendimiento.

Si ejecutas el servidor de reenvío con Docker, Google recomienda activar un volumen distinto del volumen de configuración con fines de aislamiento. Además, cada entrada debe aislarse con su propio directorio o volumen para evitar conflictos.

Configuración de ejemplo: almacenamiento en búfer del disco

En la siguiente configuración, se incluye una sintaxis para habilitar el almacenamiento en búfer de discos:

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 expresión regular

Los filtros de expresiones regulares te permiten filtrar registros según coincidencias de expresiones regulares con registros sin procesar.

Los filtros emplean la sintaxis RE2 que se describe aquí: https://github.com/google/re2/wiki/Sintaxis

Los filtros deben incluir una expresión regular y, de forma opcional, un comportamiento cuando hay una coincidencia. El comportamiento predeterminado de una coincidencia es el bloqueo (también puedes configurarlo de forma explícita como bloqueo).

Como alternativa, puedes especificar filtros con el comportamiento allow. Si especificas filtros de permiso, el servidor de reenvío bloquea los registros que no coinciden con al menos un filtro de permiso.

Es posible definir una cantidad arbitraria de filtros. Los filtros de bloque tienen prioridad sobre los filtros de permiso.

Cuando se definan filtros, se les deben asignar un nombre. Los nombres de los filtros activos se informarán a Chronicle a través de las métricas de estado de Forwarder. Los filtros definidos en la raíz de la configuración se combinan con los filtros definidos a nivel del colector. Los filtros de nivel de colector tienen prioridad en los casos de nombres en conflicto. Si no se definen filtros a nivel de raíz o de colector, el comportamiento es permitir todos.

Configuración de ejemplo: Filtros de expresiones regulares

En la siguiente configuración de reenvío, se bloquean los registros WINEVTLOG que no coinciden con el filtro raíz (allow_filter). Dada la expresión regular, el filtro solo permite registros con prioridades entre 0 y 99. Sin embargo, los registros NIX_SYSTEM que contienen "foo" o "bar" se bloquean, a pesar de allow_filter. Esto se debe a que los filtros usan un operador lógico OR. Todos los registros se procesan hasta que se activa 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

Etiquetas arbitrarias

Las etiquetas se usan para adjuntar metadatos arbitrarios a los registros con pares clave-valor. Las etiquetas se pueden configurar para un servidor de reenvío completo o dentro de un colector específico de un servidor de reenvío. Si se proporcionan ambas, las etiquetas se combinan con las claves del colector que tienen prioridad sobre las claves del reenvío si estas se superponen.

Configuración de ejemplo: etiquetas arbitrarias

En la siguiente configuración de reenvío, los pares de clave y valor “foo=bar” y “meow=mix” están adjuntos a los registros WINEVTLOG, y las claves “foo=baz” y “meow=mix” y se adjuntan los pares de valores a los 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

Espacios de nombres

Usa etiquetas de espacio de nombres para identificar registros de segmentos de red distintos y desconflictar las direcciones IP superpuestas. Puedes configurar una etiqueta de espacio de nombres para un servidor de reenvío completo o dentro de un colector específico del servidor de reenvío. Si se incluyen ambos, el espacio de nombres del colector específico tiene prioridad.

Cualquier espacio de nombres configurado para el servidor de reenvío aparece con los elementos asociados en la interfaz de usuario de Chronicle. También puedes buscar espacios de nombres con la función de búsqueda de Chronicle.

Para obtener información sobre cómo ver los espacios de nombres en la interfaz de usuario de Chronicle, consulta aquí.

Configuración de ejemplo: espacios de nombres

En la siguiente configuración de Forwarder, los registros WINEVTLOG se adjuntan al espacio de nombres FORWARDER y los registros NIX_SYSTEM se adjuntan al espacio de nombres 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 de Kafka

Puedes transferir datos de temas de Kafka del mismo modo que lo haces con syslog. Los grupos de consumidores se aprovechan para permitirte implementar hasta 3 agentes de reenvío y extraer datos del mismo tema de Kafka.

Para obtener más información sobre los grupos de consumidores de Kafka, consulta lo siguiente: https://docs.confluent.io/platform/current/clients/consumer.html

Configuración de ejemplo: entrada de Kafka

En la siguiente configuración de reenvío, se muestra cómo configurar el reenvío para transferir datos de temas de 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: 60
      brokers:
      - broker-1:9093
      - 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

Balanceo de cargas y alta disponibilidad

El servidor de reenvío de Chronicle Linux se puede implementar en un entorno en el que se instala un balanceador de cargas de capa 4 entre las instancias de reenvío y de fuente de datos. Esto permite que un cliente distribuya la recopilación de registros entre varios servidores de reenvío o envíe registros a un servidor de reenvío diferente si uno falla. Esta característica solo es compatible con el tipo de colección syslog.

El servidor de reenvío de Linux incluye un servidor HTTP integrado que responde a las verificaciones de estado de HTTP desde el balanceador de cargas. El servidor HTTP también ayuda a garantizar que los registros no se pierdan durante el inicio o el cierre de un servidor de reenvío.

Configura las opciones de servidor HTTP, balanceo de cargas y alta disponibilidad en la sección server del archivo de configuración de reenvío. Estas opciones admiten la configuración de las duraciones del tiempo de espera y los códigos de estado que se muestran en respuesta a las verificaciones de estado recibidas en las implementaciones basadas en la organización y en el programador de contenedores, así como en los balanceadores de cargas tradicionales.

La siguiente configuración de reenvío es un ejemplo de balanceo de cargas y alta disponibilidad:

- 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
Ruta de configuración Descripción
server : Graceful_timeout La cantidad de tiempo que el servidor de reenvío muestra una verificación de estado o preparación incorrecta y, aún, acepta conexiones nuevas. Este también es el tiempo de espera entre la recepción de una señal para detenerse y el inicio del cierre del servidor. Esto permite que el balanceador de cargas quite el reenvío del grupo.
server : desvío_tiempo de espera Tiempo que el servidor de reenvío espera a que las conexiones activas se cierren por sí solas antes de que el servidor las cierre.
servidor : http : puerto Número de puerto que el servidor HTTP escucha en las verificaciones de estado del balanceador de cargas. Debe ser un valor entre 1,024 y 65,535.
servidor : http : host Dirección IP, o nombre de host que se puede resolver en direcciones IP, que el servidor debe escuchar. Si está vacío, el valor predeterminado es el sistema local (0.0.0.0).
servidor : http : read_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar desde la configuración predeterminada. Tiempo máximo de lectura de la solicitud completa, tanto en el encabezado como en el cuerpo. Puedes configurar leer_timeout y read_header_timeout.
servidor : http : read_header_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar desde la configuración predeterminada. Tiempo máximo de lectura de encabezados de solicitud. El plazo de lectura de la conexión se restablece después de leer el encabezado.
servidor : http : write_timeout Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar desde la configuración predeterminada. Tiempo máximo permitido para enviar una respuesta. Se restablece cuando se lee un encabezado de solicitud nuevo.
servidor : http : tiempo de espera inactivo Se usa para ajustar el servidor HTTP. Por lo general, no es necesario cambiar desde la configuración predeterminada. Tiempo máximo de espera para la siguiente solicitud cuando las conexiones inactivas están habilitadas. Si inactivo_timout es cero, se usa el valor de read_timout. Si ambos son cero, se usa read_header_timeout.
routes : meta : Ready_Status Código de estado que el servidor de reenvío muestra cuando está listo para aceptar tráfico en cualquiera de las siguientes situaciones:
  • La verificación de disponibilidad se recibe desde un programador o organizador de contenedores, como Kubernetes.
  • La verificación de estado se recibe de un balanceador de cargas tradicional.
routes : meta : unready_status El código de estado que el servidor de reenvío muestra cuando no está listo para aceptar tráfico.
routes : meta : available_status Código de estado que el servidor de reenvío muestra cuando se recibe una verificación de actividad y el servidor de reenvío está disponible. Las verificaciones de actividad suelen enviarse a través de programadores o organizadores de contenedores, como Kubernetes.

Preguntas frecuentes

¿Qué es un contenedor de Docker?

  • Los contenedores de Docker, como las máquinas virtuales, proporcionan seguridad, aislamiento y administración de recursos adicionales.

  • Máquinas virtuales: Deben tener un espacio privilegiado (kernel de Linux) y un espacio de usuario (todo lo que interactúas con: libc, python, ls, tcpdump, etcétera).

  • Contenedores: Solo tienen un espacio de usuario (todo lo que interactúa con libc, Python, ls, tcpdump, etc.) y se basa en el espacio de privilegios del host.

¿Por qué distribuir el servidor de reenvío de Chronicle mediante un contenedor?

  • Mejor seguridad mediante el aislamiento:
    • El entorno y los requisitos del cliente no afectan el reenvío de Chronicle.
    • El entorno y los requisitos del servidor de reenvío de Chronicle no afectan al cliente.
    • El mecanismo de distribución de contenedores ya existe y puede ser privado y estar separado para Google Cloud y los clientes. https://cloud.google.com/container-registry/

¿Por qué solo Linux para contenedores? ¿Qué sucede con Windows?

  • Los contenedores se desarrollaron primero para Linux y están listos para la producción.

  • La compatibilidad de Windows con los contenedores está mejorando. Los contenedores están disponibles para Windows Server 2016 y Windows 10.

¿Necesitas aprender comandos avanzados de Docker?

  • El servidor de reenvío de Chronicle usa un solo contenedor, por lo que no es necesario aprender sobre Swarm, organización, Kubernetes ni otros comandos o conceptos avanzados de Docker.