Forwarder unter Linux installieren und konfigurieren

In diesem Dokument wird beschrieben, wie Sie den Forwarder unter Linux installieren und konfigurieren. Sie können den Forwarder auf einer Vielzahl von Linux-Distributionen (Debian, Ubuntu, Red Hat, Suse usw.) installieren. Google Cloud stellt die Software mit einem Docker-Container bereit. Sie können den Docker-Container auf einer physischen oder virtuellen Maschine ausführen und verwalten, auf der Linux ausgeführt wird.

Konfigurationsdateien anpassen

Basierend auf den Informationen, die Sie vor der Bereitstellung gesendet haben, stellt Ihnen Google Cloud die Forwarder-Software und die Konfigurationsdateien zur Verfügung. Google Cloud sendet Ihre Konfigurationsdateien an die Forwarder-Instanz in Ihrem Netzwerk. Wenn Sie die Konfiguration ändern müssen, wenden Sie sich an den Chronicle-Support.

Systemanforderungen

Im Folgenden finden Sie allgemeine Empfehlungen. Empfehlungen für Ihr System erhalten Sie vom Chronicle-Support.

  • RAM: 1,5 GB für jeden erfassten Datentyp. Zum Beispiel sind die Endpunkterkennung und -antwort (Endpoint Detection and Response, EDR), DNS und DHCP jeweils unterschiedliche Datentypen. Sie benötigen 4,5 GB RAM, um Daten für alle drei Geräte zu erfassen.

  • CPU: Zwei CPUs reichen aus,um weniger als 10.000 Ereignisse pro Sekunde (EPS) (insgesamt für alle Datentypen) zu verarbeiten. Wenn Sie voraussichtlich mehr als 10.000 EPS weiterleiten, stellen Sie 4 bis 6 CPUs bereit.

  • Laufwerk: 100 MB Speicher ist ausreichend, unabhängig davon, wie viele Daten der Chronicle-Forwarder verarbeitet. Weitere Informationen finden Sie auch im Abschnitt Disk Buffering, wenn Sie für Nachrichten auf dem Laufwerk (nicht für den Arbeitsspeicher) Daten zwischenspeichern müssen. Der Chronicle-Forwarder puffert standardmäßig den Speicher.

Firewallkonfiguration prüfen

Wenn sich zwischen dem Chronicle-Forwarder-Container und dem Internet Firewalls oder authentifizierte Proxys befinden, sind Regeln erforderlich, um den Zugriff auf die folgenden Hosts zu öffnen:

Verbindungstyp Ziel Port
TCP malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443

Docker installieren

Sie können Docker auf verschiedenen Hostbetriebssystemen installieren. Die eigentliche Installation von Docker hängt von der Hostumgebung ab. Google Cloud bietet nur eingeschränkte Dokumentationen zur Installation von Docker auf einigen der beliebtesten Linux-Distributionen. Docker ist jedoch Open Source und eine umfassende Dokumentation ist bereits verfügbar.

Sobald Sie Docker auf Ihrem System installiert haben, ist der Rest der Installation des Chronicle-Forwarders identisch, unabhängig davon, welche Linux-Distribution Sie verwenden.

Prüfen Sie mit dem folgenden Befehl, ob Docker auf Ihrem System installiert ist (erhöhte Berechtigungen):

# docker ps

Die folgende Antwort zeigt an, dass Docker korrekt installiert wurde:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Mit dem folgenden Befehl können Sie zusätzliche Informationen zu Ihrer Docker-Installation abrufen:

# docker info

Wenn Probleme mit Docker auftreten, fordert der Chronicle-Support möglicherweise die Ausgabe dieses Befehls zur Unterstützung bei der Fehlerbehebung an.

Forwarder installieren

In diesem Abschnitt wird beschrieben, wie Sie Chronicle Forwarder mit einem Docker-Container auf einem Linux-System installieren.

Schritt 1: Forwarder-Konfigurationsdateien herunterladen, übertragen und installieren

Google Cloud bietet Forwarder-Konfigurationsdateien für Ihr Betriebssystem (Linux oder Windows). Laden Sie die Dateien über den Link, den Sie von Ihrem Chronicle-Ansprechpartner erhalten haben, in ein lokales Verzeichnis auf Ihrem Laptop herunter (z. B. "chronicle"). Nachdem Sie die folgenden Schritte ausgeführt haben, übertragen Sie die Konfigurationsdateien von Ihrem Laptop in das Forwarder-Verzeichnis ~/config im Basisverzeichnis des Nutzers.

  1. Stellen Sie über das Terminal eine Verbindung zu Ihrem Linux-Forwarder her.

  2. Erstellen Sie auf dem Linux-Forwarder einen neuen Nutzer.

    # adduser <username>

    # passwd <username>

    # usermod -aG wheel <username>

  3. Wechseln Sie in das Basisverzeichnis des neuen Nutzers, der Docker-Container ausführt.

  4. Erstellen Sie ein Verzeichnis zum Speichern der Chronicle-Forwarder-Konfigurationsdateien: # mkdir ~/config

  5. Verzeichnis wechseln

  6. Prüfen Sie nach der Übertragung der Dateien, ob sich die Konfigurationsdateien im Verzeichnis "~/config" befinden:

    # ls -l

Schritt 2: Schlüssel für die Chronicle Container Registry installieren

Die von Google Cloud bereitgestellte JSON-Datei (die Datei hat die Erweiterung json .json“) enthält die Anmeldedaten, die für den Zugriff auf die Chronicle-Docker-Registry erforderlich sind.

  1. Kopieren Sie den folgenden Befehlstext (einschließlich der Zeilenumbrüche) in einen Texteditor und benennen Sie den JSON-Dateinamen innerhalb der Klammern in den Namen der Chronicle-Docker-Authentifizierung um.

      docker login \
    
         -u _json_key \
    
         --password-stdin \
    
         https://gcr.io < ./chronicle-container-c2da10b71454-oneline.json
    
  2. Kopieren Sie nach Abschluss der Bearbeitung den vollständigen Befehlstext und führen Sie den Befehl im Verzeichnis "~/config" auf dem Linux-Forwarder aus.

  3. Die Ausgabe des obigen Docker-Anmeldebefehls sollte Log-in erfolgreich sein.

Wenn ein Problem auftritt, prüfen Sie, ob die Docker-Version ausgeführt wird:

# docker version

Ältere Versionen von Docker (z. B. 1.13.1) erfordern möglicherweise andere Befehlszeilenargumente. Die Unterschiede sind nachfolgend aufgeführt.

Schritt 2 für ältere Versionen von Docker, die "--password-stdin" nicht unterstützen

Kopieren Sie für ältere Versionen von Docker (Versionen, die --password-stdin nicht akzeptieren) den Inhalt Ihrer JSON-Datei und fügen Sie sie in die Passwortaufforderung ein.

  1. Führen Sie dazu folgenden Befehl aus:

    $ cat ./<filename>.json

  2. Kopieren Sie die Ausgabe des Befehls cat.

  3. Melden Sie sich bei Docker an:

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

  4. Fügen Sie den Inhalt der Zwischenablage in die Eingabeaufforderung Password: ein.

    Unabhängig davon, wie Sie das Passwort angeben (--password-stdin oder kopieren und einfügen), sollte die Ausgabe des docker login-Befehls Login Succeeded sein.

Schritt 3: Forwarder im Docker-Container ausführen

Mit den folgenden Verfahren können Sie Chronicle-Forwarder zum ersten Mal starten und auf die neueste Version des Chronicle-Containers aktualisieren:

Die Optionen --log-opt sind seit Docker 1.13 verfügbar. Diese Optionen begrenzen die Größe der Container-Logdateien und sollten verwendet werden, solange Ihre Docker-Version sie unterstützt.

  1. Wenn Sie ein Upgrade ausführen möchten, müssen Sie alle vorherigen Docker-Ausführungen bereinigen. Im folgenden Beispiel lautet der Name des Docker-Containers cfps. Rufen Sie dann mit dem folgenden Docker-Befehl # das neueste Docker-Image von Google Cloud ab.

    # docker stop cfps
    # docker rm cfps
    
  2. Rufen Sie das neueste Docker-Image von Google Cloud ab:

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

  3. Starten Sie Chronicle-Forwarder im Docker-Container:

    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
    

Diese Befehle werden auch als Shell-Skript mit dem Namen run_docker_production_stable.sh bereitgestellt.

Der Docker-Container (und der Chronicle-Forwarder) bleiben nach dem Neustart des Systems bestehen.

Schritt 4: Forwarder überwachen und verwalten

Die folgenden Docker-Befehle helfen Ihnen, den Chronicle-Forwarder zu überwachen und zu verwalten:

  • Prüfen Sie, ob der Docker-Container ausgeführt wird:

    docker ps

  • Rufen Sie die Logs des Containers auf. Beachten Sie, dass dadurch ein beträchtliches Ausgabevolumen generiert werden kann, es ist jedoch für die Fehlerbehebung hilfreich:

    docker logs cfps

  • So sehen Sie, was innerhalb des Containers ausgeführt wird:

    docker top cfps

  • So beenden Sie den Container:

    docker stop cfps

Splunk-Daten erfassen

Sie können Chronicle-Forwarder konfigurieren, um Ihre Splunk-Daten an Chronicle weiterzuleiten. Google Cloud konfiguriert Chronicle-Forwarder mit den folgenden Informationen, um Ihre Daten von Splunk weiterzuleiten:

  • URL für die Splunk REST API (z. B. https://10.0.113.15:8889).

  • Splunk-Abfragen zum Generieren von Daten für jeden der erforderlichen Datentypen (z. B. index=dns).

Sie müssen die Anmeldedaten Ihres Splunk-Kontos für den Chronicle-Forwarder verfügbar machen.

Erstellen Sie eine lokale Datei für Ihre Splunk-Anmeldedaten und nennen Sie sie creds.txt. Fügen Sie Ihren Nutzernamen in die erste Zeile und das Passwort in die zweite Zeile ein:

  cat creds-file

  myusername
  mypassword

Kunden, die den Chronicle-Forwarder verwenden, um auf eine Splunk-Instanz zuzugreifen, kopieren die Datei creds.txt in das Konfigurationsverzeichnis (dasselbe Verzeichnis wie die Konfigurationsdateien). Beispiel:

cp creds-file ~/config/creds.txt

Prüfen Sie, ob sich die Datei creds.txtem> am richtigen Speicherort befindet:

ls ~/config

Syslog-Daten erfassen

Chronicle-Forwarder kann als Syslog-Server fungieren. Das bedeutet, dass Sie jede Appliance oder jeden Server konfigurieren können, der Syslog-Daten über eine TCP- oder UDP-Verbindung sendet, um die Daten an den Chronicle-Forwarder weiterzuleiten. Sie können genau steuern, welche Daten die Appliance oder der Server an den Chronicle-Forwarder sendet. Der Chronicle-Forwarder kann die Daten dann an Chronicle weiterleiten.

Die von Google Cloud bereitgestellte Konfigurationsdatei gibt an, welche Ports für jeden Typ weitergeleiteter Daten überwacht werden sollen (z. B. Port 10514). Standardmäßig akzeptiert der Chronicle-Forwarder sowohl TCP- als auch UDP-Verbindungen.

rsyslog konfigurieren

Zum Konfigurieren von rsyslog müssen Sie für jeden Port ein Ziel angeben (z. B. jeden Datentyp). Die korrekte Syntax finden Sie in der Systemdokumentation. Die folgenden Beispiele veranschaulichen eine rsyslog-Zielkonfiguration:

  • TCP-Log-Traffic: dns.* @192.168.0.12:10514

  • UDP-Log-Traffic: dns.* @192.168.0.12:10514

TLS für Syslog-Konfigurationen aktivieren

Sie können TLS für die Syslog-Verbindung zum Chronicle-Forwarder aktivieren. Geben Sie in der Konfigurationsdatei von Chronicle den Speicherort Ihres Zertifikats und Zertifikatschlüssels an, wie im folgenden Beispiel gezeigt:

Zertifikat "/opt/chronicle/external/certs/edb3ae966a7bbe1f.pem"
certificate_key "/opt/chronicle/external/certs/forwarder.key"

Entsprechend dem gezeigten Beispiel würde die Chronicle-Forwarder-Konfiguration so geändert:

  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"

Sie können im Konfigurationsverzeichnis ein Zertifikatverzeichnis erstellen und die Zertifikatsdateien dort speichern.

Paketdaten erfassen

Der Chronicle-Forwarder kann Pakete mit libpcap unter Linux direkt von einer Netzwerkschnittstelle erfassen. Pakete werden erfasst und an Chronicle gesendet, anstatt Logeinträge zu senden. Die Paketerfassung erfolgt nur über eine lokale Schnittstelle. Wenden Sie sich an den Chronicle-Support, um die Paketerfassung für Ihr System zu aktivieren.

Google Cloud konfiguriert den Chronicle-Forwarder mit dem Berkeley-Paketfilterfilter (BPF), der zum Erfassen von Paketen verwendet wird (z. B. Port 53 und nicht localhost).

Datenkomprimierung umschalten

Die Logkomprimierung reduziert den Netzwerkbandbreitenverbrauch beim Übertragen von Logs an Chronle. Die Komprimierung kann jedoch zu einem Anstieg der CPU-Auslastung führen. Der Kompromiss zwischen CPU-Auslastung und Bandbreite hängt von vielen Faktoren ab, einschließlich des Typs der Log-Daten, der Kompressibilität dieser Daten, der Verfügbarkeit von CPU-Zyklen auf dem Host, auf dem die Forwarder ausgeführt werden, und der Notwendigkeit, das Netzwerk zu reduzieren{101 }Bandbreitenverbrauch.

Beispielsweise werden textbasierte Logs gut komprimiert und können eine erhebliche Bandbreiteneinsparung bei geringer CPU-Auslastung bieten. Verschlüsselte Nutzlasten von Rohpaketen werden jedoch nicht gut komprimiert und verursachen eine höhere CPU-Auslastung.

Da die meisten vom Forwarder aufgenommenen Logtypen effizient komprimiert werden können, ist die Logkomprimierung standardmäßig aktiviert, um den Bandbreitenverbrauch zu reduzieren. Wenn die höhere CPU-Auslastung jedoch den Vorteil der Einsparungen bei der Bandbreite überwiegt, können Sie die Komprimierung deaktivieren. Legen Sie dazu den ParameterKomprimierung Feld bisfalsch in der Chronicle-Forwarder-Konfigurationsdatei wie im folgenden Beispiel gezeigt:

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",
...

Laufwerkzwischenspeicher

Durch die Zwischenspeicherung von Laufwerken können Sie Rückstände von Nachrichten auf der Festplatte statt im Arbeitsspeicher zwischenspeichern. Die im Rückstand befindlichen Nachrichten können für den Fall gespeichert werden, dass der Forwarder abstürzt oder der zugrunde liegende Host abstürzt. Die Aktivierung der Zwischenspeicherung von Laufwerken kann sich auf die Leistung auswirken.

Wenn Sie den Forwarder mit Docker ausführen, empfiehlt Google, zu Isolationszwecken ein von Ihrem Konfigurations-Volume unabhängiges Volume bereitzustellen. Außerdem sollte jede Eingabe mit einem eigenen Verzeichnis oder Volume isoliert werden, um Konflikte zu vermeiden.

Beispielkonfiguration: Laufwerkzwischenspeicher

Die folgende Konfiguration enthält eine Syntax zum Aktivieren der Zwischenspeicherung von Laufwerken:

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

Filter für reguläre Ausdrücke

Mit Filtern für reguläre Ausdrücke können Sie Logs basierend auf Übereinstimmungen mit regulären Ausdrücken mit Rohlogs filtern.

Die Filter verwenden die unter https://github.com/google/re2/wiki/Syntax beschriebene RE2-Syntax.

Die Filter müssen einen regulären Ausdruck enthalten und bei Bedarf eine Funktionsweise definieren. Das Standardverhalten bei einer Übereinstimmung ist Block (Sie können sie auch explizit als Block konfigurieren).

Alternativ können Sie Filter mit dem Verhalten allow angeben. Wenn Sie allow-Filter angeben, blockiert der Forwarder alle Logs, die nicht mit mindestens einem "allow"-Filter übereinstimmen.

Es ist möglich, eine beliebige Anzahl von Filtern zu definieren. Blockfilter haben Vorrang vor Zulassungsfiltern.

Wenn Filter definiert sind, muss ihnen ein Name zugewiesen werden. Die Namen der aktiven Filter werden Chronicle über Forwarder-Systemdiagnosen gemeldet. Filter, die im Stammverzeichnis der Konfiguration definiert sind, werden mit Filtern zusammengeführt, die auf Collector-Ebene definiert sind. Bei Konfliktnamen haben Filter auf Collector-Ebene Vorrang. Wenn auf der Stamm- oder Collector-Ebene keine Filter definiert sind, werden alle Filter zugelassen.

Beispielkonfiguration: Filter für reguläre Ausdrücke

In der folgenden Forwarder-Konfiguration werden WINEVTLOG-Logs blockiert, die nicht mit dem Root-Filter (allow_filter) übereinstimmen. Aufgrund des regulären Ausdrucks lässt der Filter nur Logs mit Prioritäten zwischen 0 und 99 zu. Allerdings werden alle NIX_SYSTEM-Logs mit "foo" oder "bar" trotz allow_filter blockiert. Das liegt daran, dass die Filter ein logisches OR verwenden. Alle Logs werden verarbeitet, bis ein Filter ausgelöst wird.

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

Beliebige Labels

Labels werden verwendet, um mithilfe von Schlüssel/Wert-Paaren beliebige Metadaten an Logs anzuhängen. Labels können für einen gesamten Forwarder oder innerhalb eines bestimmten Collectors eines Forwarders konfiguriert werden. Wenn beide bereitgestellt werden, werden die Labels mit den Collector-Schlüsseln zusammengeführt, die Vorrang vor den Forwarder-Schlüsseln haben, wenn sich die Schlüssel überschneiden.

Beispielkonfiguration: Beliebige Labels

In der folgenden Forwarder-Konfiguration sind die Schlüssel/Wert-Paare "foo=bar" und "meow=mix" an WINEVTLOG-Logs sowie der Schlüssel "foo=baz" und "meow=mix" und Wertpaare sind an die NIX_SYSTEM-Logs angehängt.

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

Verwenden Sie Namespace-Labels, um Logs aus verschiedenen Netzwerksegmenten zu identifizieren und sich überschneidende IP-Adressen in Konflikt zu setzen. Sie können ein Namespace-Label für einen gesamten Forwarder oder in einem bestimmten Collector des Forwarders konfigurieren. Wenn beide enthalten sind, hat der Namespace des spezifischen Collectors Vorrang.

Jeder für den Forwarder konfigurierte Namespace wird mit den zugehörigen Assets in der Chronicle-Benutzeroberfläche angezeigt. Sie können auch mit der Funktion hrChronicle-Suche“ nach Namespaces suchen.

Informationen zum Aufrufen von Namespaces in der Chronicle-Benutzeroberfläche finden Sie hier.

Beispielkonfiguration: Namespaces

In der folgenden Forwarder-Konfiguration werden WINEVTLOG-Logs mit dem FORWARDER-Namespace und NIX_SYSTEM-Logs mit dem CORPORATE-Namespace verknüpft.

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

Kafka-Eingabe

Daten zu Kafka-Themen können Sie genau wie für syslog aufnehmen. Mit Nutzergruppen können Sie bis zu drei Forwarder bereitstellen und Daten aus demselben Kafka-Thema abrufen.

Weitere Informationen zu Kafka-Nutzergruppen finden Sie unter: https://docs.confluent.io/platform/current/clients/consumer.html

Beispielkonfiguration: Kafka-Eingabe

Die folgende Forwarder-Konfiguration zeigt, wie der Forwarder eingerichtet wird, um Daten aus Kafka-Themen aufzunehmen:

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

Load-Balancing und Hochverfügbarkeit

Der Chronicle Linux-Forwarder kann in einer Umgebung bereitgestellt werden, in der ein Layer-4-Load-Balancer zwischen der Datenquellen- und der Forwarder-Instanz installiert ist. Dadurch kann ein Kunde die Logerfassung auf mehrere Forwarder verteilen oder Logs an einen anderen Forwarder senden, wenn einer die Weiterleitung nicht zulässt. Dieses Feature wird nur mit dem Sammlungstyp syslog unterstützt.

Der Linux-Forwarder enthält einen integrierten HTTP-Server, der auf HTTP-Systemdiagnosen des Load-Balancers reagiert. Der HTTP-Server trägt außerdem dazu bei, dass Logs nicht beim Starten oder Herunterfahren eines Forwarders verloren gehen.

Konfigurieren Sie den HTTP-Server, das Load-Balancing und die Hochverfügbarkeitsoptionen im Abschnitt Server der Forwarder-Konfigurationsdatei. Diese Optionen unterstützen das Festlegen von Zeitlimits und Statuscodes als Antwort auf Systemdiagnosen, die in Containerplaner- und Orchestrierungs-basierten Bereitstellungen sowie bei herkömmlichen Load-Balancern empfangen werden.

Verwenden Sie die folgenden URL-Pfade für Integritäts-, Bereitschafts- und Aktivitätsprüfungen. Die <host:port>-Werte sind in der Forwarder-Konfiguration definiert.

  • http://<host:port>/meta/available: Aktivitätsprüfungen für Containerplaner/-orchestratoren wie Kubernetes.
  • http://<host:port>/meta/ready: Bereitschaftsprüfungen und herkömmliche Systemdiagnosen für Load-Balancer.

Die folgende Forwarder-Konfiguration ist ein Beispiel für Load-Balancing und Hochverfügbarkeit:

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
Konfigurationspfad Beschreibung
Server : ordnungsgemäßer Zeitraum Die Zeit, die der Forwarder eine fehlerhafte Bereitschaft/Systemdiagnose zurückgibt und akzeptiert weiterhin neue Verbindungen. Dies ist auch die Zeit, die zwischen dem Empfang eines Signals und dem Beginn des Herunterfahrens des Servers selbst wartet. Dadurch kann der Load-Balancer den Forwarder aus dem Pool entfernen.
Server : expiration_timeout Die Zeit, die der Forwarder wartet, bis aktive Verbindungen von selbst beendet wurden, bevor er vom Server geschlossen wird.
Server : http : Port Portnummer, die der HTTP-Server auf Systemdiagnosen des Load-Balancers überwacht. Muss zwischen 1024 und 65535 liegen.
Server : http : Host IP-Adresse oder Hostname, die in IP-Adressen aufgelöst werden kann und vom Server überwacht werden soll. Wenn das Feld leer ist, ist der Standardwert das lokale System (0.0.0.0).
Server : http : read_timeout Dient zum Optimieren des HTTP-Servers. Dieser muss in der Regel nicht von der Standardeinstellung geändert werden. Die maximale Lesezeit für die gesamte Anfrage, sowohl im Header als auch im Text. Sie können sowohl read_timeout als auch read_header_timeout festlegen.
Server : http : read_header_timeout Dient zum Optimieren des HTTP-Servers. Dieser muss in der Regel nicht von der Standardeinstellung geändert werden. Maximale Zeit zum Lesen von Anfrageheadern. Die Lesefrist für die Verbindung wird nach dem Lesen des Headers zurückgesetzt.
Server : http : write_timeout Dient zum Optimieren des HTTP-Servers. Dieser muss in der Regel nicht von der Standardeinstellung geändert werden. Maximale Zeit zum Senden einer Antwort Sie wird zurückgesetzt, wenn ein neuer Anfrageheader gelesen wird.
Server : http : inaktiv_timeout Dient zum Optimieren des HTTP-Servers. Dieser muss in der Regel nicht von der Standardeinstellung geändert werden. Maximale Wartezeit bis zur nächsten Anfrage, wenn inaktive Verbindungen aktiviert sind. Wenn Inaktivität_timout null ist, wird der Wert von read_timout verwendet. Wenn beide Nullen sind, wird _read_header_timeout“ verwendet.
routes : meta : ready_status Der Statuscode, den der Forwarder zurückgibt, wenn er bereit ist, Traffic in einer der folgenden Situationen zu akzeptieren:
  • Eine Bereitschaftsprüfung wird von einem Containerplaner oder -orchestrator wie Kubernetes empfangen.
  • Die Systemdiagnose wird von einem herkömmlichen Load-Balancer empfangen.
route : meta : ungeleseny_status Der Statuscode, den der Forwarder zurückgibt, wenn er nicht bereit ist, Traffic anzunehmen.
routes : meta : available_status Der Statuscode wird zurückgegeben, wenn eine Aktivitätsprüfung empfangen wird und der Forwarder verfügbar ist. Aktivitätsprüfungen werden häufig von Containerplanern/-orchestratoren wie Kubernetes gesendet.

FAQ

Was ist ein Docker-Container?

  • Docker-Container, wie virtuelle Maschinen, bieten zusätzliche Sicherheit, Isolation und Ressourcenverwaltung.

  • Virtuelle Maschinen haben sowohl einen privilegierten Bereich (Linux-Kernel) als auch einen Nutzerbereich (alles, mit dem Sie interagieren): libc, python, ls, tcpdump usw.

  • Container haben nur einen Nutzerbereich (alle Aktionen, mit denen Sie interagieren, z. B. libc, python, ls, tcpdump usw.) und nutzt den Berechtigungsbereich des Hosts.

Warum Verteiler von Chronicle mit einem Container verteilen?

  • Höhere Sicherheit durch Isolation:
    • Die Kundenumgebung und die Anforderungen wirken sich nicht auf den Chronicle-Forwarder aus.
    • Chronicle-Forwarder-Umgebung und -Anforderungen haben keine Auswirkungen auf den Kunden.
    • Der Containerverteilungsmechanismus ist bereits vorhanden und kann für Google Cloud und Kunden privat und getrennt sein. https://cloud.google.com/container-registry/

Warum nur Linux für Container? Was ist mit Windows?

  • Container wurden zuerst für Linux entwickelt und sind produktionsbereit.

  • Die Windows-Unterstützung für Container wird verbessert. Container sind für Windows Server 2016 und Windows 10 verfügbar.

Sie benötigen erweiterte Docker-Befehle?

  • Chronicle-Forwarder verwendet einen einzelnen Container, sodass Sie sich nicht mit Swarm, Orchestrierung, Kubernetes oder anderen erweiterten Docker-Konzepten oder -Befehlen vertraut machen müssen.