Bindplane-Agent für die Erfassung bereitstellen

Unterstützt in:

In diesem Dokument wird Bindplane für Google Security Operations beschrieben.

Bindplane ist eine Telemetrie-Pipeline, mit der Logs aus beliebigen Quellen erfasst, optimiert und in Google SecOps exportiert werden können.

Bindplane bietet zwei Versionen speziell für Google an.

Bindplane umfasst die folgenden Hauptkomponenten:

  • BindPlane-Collector. Ein Open-Source-Agent, der auf dem OpenTelemetry-Collector (OTel) basiert. Er erfasst Logs aus verschiedenen Quellen, einschließlich Microsoft Windows-Ereignisprotokollen, und sendet sie an Google SecOps. Sie können die Collectors lokal oder in der Cloud installieren.

    Diese Komponente kann auch als Bindplane Distribution for OpenTelemetry (BDOT) Collector, Bindplane-Agent, Erfassungs-Agent, Collector oder Agent bezeichnet werden.

  • Bindplane-Server Eine umfassende und einheitliche Plattform für die Verwaltung Ihrer OTel-Collector-Bereitstellungen. Diese Bereitstellungen können sich in Google SecOps und Google Cloudbefinden. Viele Google SecOps-Kunden verwenden Bindplane Server, die Verwendung ist jedoch optional. Der Bindplane-Server kann lokal oder in der Bindplane-Cloud ausgeführt werden. Weitere Informationen zum Server finden Sie unter Bindplane-Server.

    Diese Komponente wird auch als Bindplane Observability Pipeline (OP) Management Console oder Bindplane Management Console bezeichnet.

Google-Versionen von Bindplane

Bindplane bietet zwei Versionen speziell für Google: Bindplane (Google Edition) und Bindplane Enterprise (Google Edition).

Bindplane (Google Edition)

Bindplane (Google Edition) wird allen Google SecOps-Kunden zur Verfügung gestellt.

Sie können Bindplane (Google Edition) in der Bindplane-Cloud selbst verwalten.

Informationen zum Installieren und selbst hosten von Bindplane (Google Edition) oder zum Generieren Ihres Schlüssels für einen lokalen Bindplane-Server finden Sie unter Bindplane (Google Edition).

Bindplane Enterprise (Google Edition) – für Kunden von Google SecOps Enterprise Plus und Google Unified Security (GUS)

Bindplane Enterprise (Google Edition) ist für Google SecOps Enterprise Plus- und GUS-Kunden enthalten.

Bindplane Enterprise (Google Edition) wird für umfangreiche Bereitstellungen empfohlen.

Bindplane Enterprise-Lizenzschlüssel herunterladen

Google SecOps Enterprise Plus- und GUS-Kunden können ihren Bindplane Enterprise-Lizenzschlüssel (Google Edition) direkt über die Plattformkonsole herunterladen:

  1. Rufen Sie in der Google SecOps-Konsole Einstellungen > Datenverwaltung > Erfassungs-Agents auf.
  2. Klicken Sie auf der Karte Bindplane-Lizenz auf Lizenz herunterladen, um die Lizenzschlüsseldatei zu speichern.
  3. Wenden Sie den heruntergeladenen Lizenzschlüssel auf Ihre Bindplane Server-Installation an. Weitere Informationen finden Sie unter Bindplane-Lizenz anwenden.

Bindplane Google-Versionen – Unterschiede

In der folgenden Tabelle sind die Unterschiede zwischen den Bindplane Google-Versionen aufgeführt:

Thema/Funktion Bindplane (Google Edition) Bindplane Enterprise (Google Edition)
Kosten Für alle Google SecOps-Kunden ohne Aufpreis enthalten Für Google SecOps Enterprise Plus-Kunden kostenlos enthalten
Routing/Ziele Nur Google, einschließlich Google SecOps, Cloud Logging, BigQuery und Cloud Storage über Google SecOps Google, einschließlich 12 Monate Routing zu einem Ziel außerhalb von Google für SIEM-Migrationen
Filterfunktion Einfacher Filter mit regulärem Ausdruck Erweiterte Filterprozessoren (z. B. Filter nach Bedingung, Feld, Schweregrad usw.), Datenreduzierung, Log-Stichprobenerhebung, Deduplizierung
Entfernen – Maskierung personenidentifizierbarer Informationen
Transformation Feld hinzufügen, Feld verschieben, Daten parsen (KV, JSON, CSV, XML, Zeitstempel, Parsen nach regulärem Ausdruck), Feld umbenennen, Event Breaker Umfasst alle in Bindplane (Google Edition) unterstützten Funktionen plus Feld löschen, leere Werte löschen, zusammenführen
Allgemeine Funktionen auf Plattformebene Gateway (aggregierte Daten von Collectors), Bindplane-Collectors, Bindplane-Server (Bindplane-Verwaltungsebene) lokal oder in der Cloud gehostet, alle Quellen, Silent-Host-Monitoring über Google SecOps-Prozessor, persistente Warteschlange, Telemetrieanreicherung, Hochverfügbarkeit, RBAC, beide Google SecOps-Aufnahme-APIs unterstützt, Verschleierung von Anmeldedaten, erweiterte Flottenverwaltung einschließlich Gruppierung von Collectors, dynamische Zuweisung von Logtypen Alle in Bindplane (Google Edition) unterstützten Funktionen

Bindplane-Collector-Architektur

Bindplane verwendet den BDOT Collector, der allgemein als Collector bezeichnet wird, um die Telemetrieverwaltung mit dem Open Agent Management Protocol (OpAMP) zu standardisieren. Mit Bindplane können Sie auch benutzerdefinierte OpenTelemetry Collector-Distributionen erstellen und verwalten.

Der Collector kann unter Linux oder Docker als einfacher Webserver ohne externe Abhängigkeiten ausgeführt werden.

Weitere Informationen zur Bereitstellungsarchitektur von Bindplane OpenTelemetry-Collectors finden Sie unter Bereitstellung.

In den folgenden Abschnitten werden die verfügbaren Architekturoptionen beschrieben.

Collectors senden Logs an einen Collector, der als Gateway fungiert.

Für umfangreiche Bereitstellungen empfehlen wir die Verwendung von Collectors, die als Gateways fungieren. Diese Gateways empfangen Telemetriedaten von anderen Collectors über das Netzwerk, führen optional zusätzliche Verarbeitungsschritte aus und leiten die Daten an Google SecOps weiter.

Ein Collector, der als Gateway fungiert, verwendet dieselbe Binärdatei wie alle anderen Collectoren.

Das folgende Diagramm zeigt Collectors, die Logs an einen Collector senden, der als Gateway fungiert:

Collectors senden Logs an einen Collector, der als Gateway fungiert.

Collectors senden Logs direkt an die Google SecOps Ingestion API.

Das folgende Diagramm zeigt Collectors, die Logs direkt an die Google SecOps Ingestion API senden:

Collectors senden Logs direkt an die Google SecOps Ingestion API.

Collectors senden Logs direkt an Cloud Logging.

Das folgende Diagramm zeigt Collectors, die Logs direkt an Cloud Logging senden:

Collectors senden Logs direkt an Cloud Logging.

Collectors senden Logs an mehrere Ziele

Das folgende Diagramm zeigt Collectors, die Logs an mehrere Ziele senden:

Collector sendet Logs an mehrere Ziele

Bindplane-Server

Der Bindplane-Server bietet die folgenden wichtigen Funktionen:

  • Zentrale Verwaltung: Mit dem Server können Sie alle Ihre OTel-Collector-Bereitstellungen in Google Cloudverwalten. Sie können den Status jeder Bereitstellung einsehen und gängige Verwaltungsaufgaben ausführen, z. B. das Starten, Beenden und Neustarten von Collectors.
  • Echtzeit-Monitoring Der Server bietet Echtzeit-Monitoring Ihrer OTel-Collector-Bereitstellungen. Sie können Messwerte wie CPU-Auslastung, Arbeitsspeichernutzung und Durchsatz verfolgen. Sie können sich auch Logs und Traces ansehen, um Probleme zu beheben.
  • Benachrichtigungen Auf dem Server können Sie Benachrichtigungen für wichtige Ereignisse einrichten, z. B. wenn ein Collector ausfällt oder ein Messwertgrenzwert überschritten wird.
  • Konfigurationsverwaltung: Mit dem Server können Sie die Konfiguration Ihrer OTel-Collectors zentral verwalten. Sie können Konfigurationsdateien bearbeiten, Umgebungsvariablen festlegen und Sicherheitsrichtlinien auf alle Ihre Bereitstellungen anwenden.
  • Integration in Google Cloud. Sie können OTel-Collector-Bereitstellungen in Google Cloud erstellen und verwalten und den Server für den Zugriff auf Ihre Google Cloud -Ressourcen verwenden.

Bindplane bietet Bereitstellungsoptionen für die Cloud und lokal. Weitere Informationen finden Sie unter Bindplane-Server verwenden.

Technische Anforderungen und Empfehlungen

In diesem Abschnitt werden die technischen Anforderungen und Empfehlungen für die Installation und Ausführung von Bindplane mit Google SecOps beschrieben.

Bandbreitenanforderungen

Bindplane verwaltet Netzwerkverbindungen für Folgendes:

  • Collector-Verwaltung
  • Durchsatzmessungen des Collectors
  • Befehlszeilen und Web-Benutzeroberflächen

Verbindungsanforderungen

Bindplane überwacht standardmäßig Port 3001. Dieser Port ist konfigurierbar.

Der Bindplane-Port wird für Folgendes verwendet:

  • Collector-Befehl und -Steuerung mit OpAMP (WebSocket)
  • Anfragen zur Messung des Collector-Durchsatzes (HTTP-POST-Anfrage)
  • Browser- und CLI-Nutzer (HTTP und WebSocket)

Collectors müssen in der Lage sein, Verbindungen zu Bindplane für OpAMP (WebSocket) und Durchsatzmessungen (HTTP) zu initiieren.

Bindplane initiiert niemals Verbindungen zu den Collectors. Sie können eine Firewall konfigurieren, um zu verhindern, dass Bindplane die Collector-Netzwerke erreicht. Collector-Netzwerke müssen jedoch in der Lage sein, Bindplane über den konfigurierten Port zu erreichen.

Allgemeine technische Anforderungen für Bindplane-Collector

Informationen zu den allgemeinen technischen Anforderungen für den Bindplane-Collector finden Sie hier:

Ressourcenanforderungen für Collector

Die Ressourcenanforderungen von Bindplane hängen von der Anzahl der verwalteten Collectors ab. Mit zunehmender Anzahl verwalteter Collectors steigen auch die CPU-, Arbeitsspeicher-, Laufwerkdurchsatz-/IOPS- und Netzwerkauslastung.

Verwenden Sie die folgende Tabelle für die Dimensionierung von CPU, Arbeitsspeicher und Speicherkapazität:

Anzahl der Collectors Bindplane-Knoten Fehlertoleranz CPU-Kerne Speicher Datenbank
1–100 1 – 2 4 GB bbolt
100–25.000 1 – 4 16 GB postgres
1–60.000 3 1 2 8 GB postgres
60.001–125.000 5 1 2 8 GB postgres
125.001–250.000 10 2 2 8 GB postgres

Installation und Bereitstellung planen

Die folgenden Abschnitte enthalten Empfehlungen und Best Practices, die Sie bei der Planung Ihrer Bindplane-Bereitstellung berücksichtigen sollten.

Skalierung und Fehlertoleranz berücksichtigen

Die horizontale Skalierung ist vorzuziehen, da sie Fehlertoleranz bietet und Engpässe beim Exporter beseitigen kann.

Wenn Sie Bindplane-Collectors im Gateway-Modus ausführen, empfehlen wir, sie mit einem Load Balancer zu koppeln, um Fehlertoleranz und horizontale Skalierung zu ermöglichen.

Anzahl der benötigten Collectors berechnen

Berücksichtigen Sie bei der Berechnung der Anzahl der für Ihre Arbeitslast erforderlichen Collectors den erwarteten Durchsatz oder die erwartete Lograte und verwenden Sie die folgende Tabelle. In dieser Tabelle wird davon ausgegangen, dass jeder Collector vier CPU-Kerne und 16 GB Arbeitsspeicher hat. Die Tabelle enthält keine Berechnungen mit Prozessoren. Wenn Prozessoren hinzugefügt werden, erhöhen sich die Rechenanforderungen.

Telemetriedurchsatz Logs/Sekunde Collectors
5 GB/m 250.000 2
10 GB/m 500.000 3
20 GB/m 1.000.000 5
100 GB/m 5.000.000 25

Collector-Flotte für Fehlertoleranz überdimensionieren

Überdimensionieren Sie die Collector-Flotte, um Fehlertoleranz zu gewährleisten. Wenn ein oder mehrere Collector-Systeme ausfallen oder für Wartungsarbeiten offline genommen werden, müssen die verbleibenden Collectoren über genügend Kapazität verfügen, um den Telemetriedurchsatz zu verarbeiten.

Wenn Sie mit einer festen Anzahl von Collectors arbeiten, können Sie die CPU und den Arbeitsspeicher vertikal skalieren, um den Durchsatz zu erhöhen.

Verarbeitungsaufwand auslagern

Im Allgemeinen sollten Ihre Collectors so wenig Arbeit wie möglich erledigen. Wenn Sie hohe Verarbeitungsanforderungen haben, kann es sinnvoll sein, diese Verarbeitung auf eine Flotte von Gateway-Kollektoren auszulagern. Anstatt Telemetriedaten beispielsweise mit einem aufwendigen regulären Ausdruck zu filtern, können Sie diese Aufgabe von den Gateway-Collectors ausführen lassen. In der Regel werden Gateway-Collectors auf einem dedizierten System ausgeführt. Dies rechtfertigt den Verarbeitungsaufwand, da die Rechenleistung anderer Dienste, die auf demselben System ausgeführt werden, nicht beansprucht wird, im Gegensatz zu einem Nicht-Gateway-Collector, der möglicherweise auf einem Datenbankserver ausgeführt wird.

Best Practices für den Gateway-Modus

Wenn Sie Bindplane-Collectors im Gateway-Modus ausführen, empfehlen wir, Ihre Bereitstellung mit den folgenden Best Practices zu planen:

  • Platzieren Sie mindestens zwei Collectors hinter einem Load Balancer.
  • Jeder Collector sollte mindestens zwei Kerne haben.
  • Jeder Collector sollte mindestens 8 GB Arbeitsspeicher haben.
  • Jeder Collector sollte 60 GB nutzbaren Speicherplatz für eine nichtflüchtige Warteschlange haben.

Load Balancer bei Bedarf verwenden

Ein Load Balancer ist erforderlich, wenn Sie Bindplane im Hochverfügbarkeitsmodus betreiben.

Wenn Sie Bindplane-Collectors im Gateway-Modus ausführen, verwenden Sie einen Load Balancer, um die Leistung und Redundanz zu erhöhen. Load Balancing ermöglicht auch die horizontale Skalierung Ihrer Gateway-Flotte und die Fähigkeit, Ausfälle ohne Ausfallzeiten zu überstehen.

Der Bindplane-Collector kann mit einer Vielzahl von Load Balancern verwendet werden.

Weitere Informationen finden Sie unter Load-Balancer-Konfiguration.

Load-Balancing-Port und -Protokolle

Bindplane überwacht standardmäßig Port 3001.

Damit die vielen verschiedenen netzwerkbasierten Empfänger in OpenTelemetry unterstützt werden können, muss der Load Balancer Folgendes unterstützen:

  • TCP/UDP-Transportprotokolle
  • HTTP- und gRPC-Anwendungsprotokolle

Load-Balancing-Größe

Bindplane-Knoten sollten nicht mehr als 30.000 Collectors verwalten,um eine maximale Fehlertoleranz zu erreichen. Jeder Collector öffnet zwei Verbindungen zu Bindplane (eine für die OpAMP-Remoteverwaltung und eine für die Veröffentlichung von Durchsatzmesswerten). Mit diesem Limit wird sichergestellt, dass Sie das Verbindungslimit von etwa 65.535 pro Backend-Instanz, das von den meisten Load Balancern vorgegeben wird, nicht überschreiten.

Wenn eine Organisation 100.000 Collectors hat, wäre eine Clustergröße von drei nicht ausreichend. Jeder Knoten wäre für etwa 33.000 Collectors verantwortlich, was 66.000 TCP-Verbindungen pro Bindplane-Instanz entspricht. Diese Situation verschlimmert sich, wenn ein Knoten für Wartungsarbeiten heruntergefahren wird, da jede verbleibende Bindplane-Instanz dann 50.000 Collectors oder 100.000 TCP-Verbindungen verwalten müsste.

Best Practices für die Dimensionierung des Load Balancing

  • Systemdiagnosen implementieren Konfigurieren Sie den Load Balancer, damit der Collector Traffic empfangen kann.
  • Verbindungen gleichmäßig verteilen: Verbindungen sollten gleichmäßig auf die Collectors verteilt sein.

  • Unterstützung der erforderlichen Protokolle Damit die vielen verschiedenen netzwerkbasierten Empfänger in OpenTelemetry unterstützt werden können, muss der Load Balancer Folgendes unterstützen:

    • TCP/UDP-Transportprotokolle
    • HTTP- und gRPC-Anwendungsprotokolle

Weitere Informationen finden Sie unter Collector-Ausfallsicherheit.

Load Balancing nach Quelltyp

Jeder Quelltyp, der Telemetriedaten von Remote-Systemen über das Netzwerk empfängt, ist für das Load Balancing geeignet, einschließlich der folgenden:

  • OTLP
  • Syslog
  • TCP/UDP
  • Splunk-HEC
  • Fluent Forward

Hochverfügbarkeitsmodus in Produktionsumgebungen verwenden

Sie können eine Bindplane-Instanz entweder in einer Einzelinstanz- oder in einer Multi-Instanz-Konfiguration bereitstellen. Für Produktionsbereitstellungen, die Hochverfügbarkeit und Ausfallsicherheit erfordern, empfehlen wir ein Bereitstellungsmodell mit mehreren Instanzen (Hochverfügbarkeit).

Wenn Bindplane mehr als 25.000 Collectors verwaltet,empfehlen wir, Bindplane im Hochverfügbarkeitsmodus (HA) zu betreiben.

Informationen zur Hochverfügbarkeit in Bindplane finden Sie unter Hochverfügbarkeit.

Anzahl der Collectors und Bindplane-Server für Hochverfügbarkeit berechnen

Wenn Sie BindPlane im Hochverfügbarkeitsmodus betreiben, müssen Sie berücksichtigen, wie viele Collectors jeder BindPlane-Server voraussichtlich verarbeiten wird.

Nehmen Sie die Gesamtzahl der Bindplane-Instanzen und subtrahieren Sie die maximale Anzahl von Knoten, die aufgrund von Wartungsarbeiten voraussichtlich nicht verfügbar sein werden. Achten Sie darauf,dass jeder Knoten während eines Knotenausfalls nicht mehr als 30.000 Collectors verwaltet.

Postgres für Hochverfügbarkeit

Postgres ist eine Voraussetzung, wenn Sie Bindplane im Hochverfügbarkeitsmodus betreiben.

Prometheus für Hochverfügbarkeit

Prometheus ist erforderlich, wenn Sie Bindplane im Hochverfügbarkeitsmodus betreiben.

Weitere Informationen finden Sie unter Prometheus.

Ereignisbus für Hochverfügbarkeit

Bindplane verwendet einen Event Bus für die Kommunikation zwischen Komponenten innerhalb von Bindplane. Wenn Sie Bindplane im HA-Modus betreiben, können Sie den Ereignisbus verwenden, um Ereignisse zwischen Bindplane-Servern zu senden.

Weitere Informationen finden Sie unter Event Bus.

Verwenden Sie eine Bereitstellung mit einer einzelnen Instanz für eine Testumgebung oder einen Proof of Concept.

Für eine Testumgebung oder einen Proof of Concept empfehlen wir die Verwendung einer Bereitstellung mit einer einzelnen Instanz.

Weitere Informationen finden Sie unter Einzelne Instanz.

Backend-Anmeldedaten isolieren

Anstatt Anmeldedaten auf allen Collector-Systemen bereitzustellen, können Sie sie ausschließlich auf den Gateway-Collectoren speichern. Dies vereinfacht die Rotation von Anmeldedaten und reduziert die Angriffsfläche, da die Bereitstellung von Anmeldedaten auf eine Teilmenge Ihrer Systeme beschränkt wird.

Gateway-Collectors mit einer Firewall schützen

Sie können Gateway-Collectors in einem Perimeternetzwerk platzieren, das durch eine Firewall vom internen Netzwerk getrennt ist. Sie können Ihr Netzwerk so konfigurieren, dass Ihre anderen Collectors Daten an die Gateway-Collectors weiterleiten können, während Gateway-Collectors der Zugriff auf Ihr Anwendungsnetzwerk verwehrt wird. So können Sie Telemetriedaten an ein cloudbasiertes Backend senden, ohne Ihren Endpunkten direkten Zugriff auf das Internet zu gewähren.

Die Firewall muss HTTP-Traffic zulassen, damit Bindplane über den konfigurierten Port erreicht werden kann.

Firewallkonfiguration prüfen (Ingestion API)

Für alle Firewalls oder authentifizierten Proxys zwischen dem Collector und dem Internet sind Regeln erforderlich, um den Zugriff auf die folgenden Hosts zu ermöglichen:

Verbindungstyp Ziel Port
TCP malachiteingestion-pa.googleapis.com 443
TCP asia-northeast1-malachiteingestion-pa.googleapis.com 443
TCP asia-south1-malachiteingestion-pa.googleapis.com 443
TCP asia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP australia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP europe-malachiteingestion-pa.googleapis.com 443
TCP europe-west2-malachiteingestion-pa.googleapis.com 443
TCP europe-west3-malachiteingestion-pa.googleapis.com 443
TCP europe-west6-malachiteingestion-pa.googleapis.com 443
TCP europe-west12-malachiteingestion-pa.googleapis.com 443
TCP me-central1-malachiteingestion-pa.googleapis.com 443
TCP me-central2-malachiteingestion-pa.googleapis.com 443
TCP me-west1-malachiteingestion-pa.googleapis.com 443
TCP northamerica-northeast2-malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP oauth2.googleapis.com 443

Voraussetzungen für die Google SecOps-Aufnahme mit Bindplane

In diesem Abschnitt werden die Voraussetzungen für die erfolgreiche Aufnahme von Daten in Google SecOps mit Bindplane beschrieben, insbesondere bei Verwendung der Chronicle Ingestion API.

Netzwerkanforderungen für die Chronicle API (HTTPS)

Wenn Sie Bindplane mit der Chronicle Ingestion API verwenden, die HTTPS nutzt, müssen Ihre Netzwerk- und Firewallkonfigurationen ausgehende Verbindungen zu den Chronicle API-Endpunkten zulassen.

Wenn Ihre Organisation IP-basierte Firewall-Einschränkungen verwendet, müssen Sie die dynamische Natur der IP-Adressen von Google Cloud berücksichtigen. Da Google SecOps die Aufnahme statischer IP-Adressen in die Zulassungsliste für die Ingestion APIs nicht unterstützt, wird davon abgeraten, sich ausschließlich auf statische IP-Adressen zu verlassen. Dies kann zu Fehlern bei der Aufnahme führen.

Beachten Sie Folgendes, um eine kontinuierliche Datenaufnahme zu gewährleisten:

  • Domainbasierte Zulassungsliste: Es wird empfohlen, die Firewall so zu konfigurieren, dass ausgehender HTTPS-Traffic (Port 443) an die gesamte *.chronicle.googleapis.com-Domain zugelassen wird.
  • Regionale Endpunkte: Bindplane sollte so konfiguriert werden, dass der entsprechende regionale Endpunkt für Ihre Google SecOps-Instanz verwendet wird, z. B. us-chronicle.googleapis.com, europe-chronicle.googleapis.com usw. Eine vollständige Liste der regionalen Endpunkte finden Sie in der Dokumentation Von Legacy-SIEM API zur Chronicle API migrieren.
  • Automatisierte IP-Updates: Wenn eine domainbasierte Zulassungsliste nicht möglich ist, müssen Sie ein automatisiertes System implementieren, um die mit *.chronicle.googleapis.com verknüpften IP-Bereiche regelmäßig abzurufen und zu aktualisieren. Die aktuellen IP-Bereiche für Google APIs können aus den Dateien goog.json und cloud.json abgerufen werden, wie in der Dokumentation zu Google-IP-Adressen beschrieben. Implementieren Sie ein System, um Ihre Firewallregeln basierend auf diesen Quellen dynamisch zu aktualisieren.

PostgreSQL für Produktionsbereitstellungen verwenden

Postgres ist für Produktionsbereitstellungen von Bindplane erforderlich.

Postgres ist eine Voraussetzung für den Betrieb von Bindplane im Hochverfügbarkeitsmodus.

Die Anzahl der CPU-Kerne und der verfügbare Arbeitsspeicher begrenzen im Allgemeinen die Leistung von PostgreSQL-Speicher-Back-Ends. Wir empfehlen, PostgreSQL-Speicher mit Speicher mit niedriger Latenz und hohem Durchsatz wie Solid-State-Laufwerken (SSDs) zu sichern.

Anzahl der Collectors CPU-Kerne Speicher
1–60.000 4 16 GB
60.001–125.000 8 32 GB
125.001–250.000 16 64 GB

Weitere Informationen nachstehend:

Richtige Authentifizierung implementieren

Bindplane unterstützt die Authentifizierung mit den folgenden Protokollen und Diensten. Achten Sie darauf, dass sie ordnungsgemäß implementiert sind:

Bindplane-Server verwenden

Die meisten Google SecOps-Kunden verwenden den Bindplane-Server, die Verwendung ist jedoch optional. Wenn Sie den Bindplane-Server installieren, benötigen Sie Zugriff auf storage.googleapis.com. Wenn Sie nur einen Collector installieren, ist dieser Zugriff nicht erforderlich.

Eine Demo, in der gezeigt wird, wie Sie den Bindplane-Server konfigurieren, um Logs zu standardisieren und nach Google SecOps zu exportieren, finden Sie unter Bindplane-Anwendungsfalldemos. Wählen Sie dann Google SecOps-Konfiguration aus.

Bindplane Cloud-Server verwenden

Bindplane Cloud ist für Google-Kunden verfügbar.

Melden Sie sich in der Google-Version an.

Wenden Sie sich bei Problemen mit Bindplane Cloud Server an den Bindplane-Support. Wenden Sie sich bei Problemen mit dem lokalen Bindplane-Server an den Google SecOps-Support.

BindPlane-Server auf Ihrem Google Cloudverwenden

Informationen zum Ausführen des Bindplane-Servers auf Google Cloudfinden Sie unter Bindplane Enterprise Edition.

Lokalen Bindplane-Server verwenden

Die Verwendung des lokalen Bindplane-Servers unterliegt den bestehenden Google Cloud -Nutzungsbedingungen.

Lokalen Server unter Linux installieren

Sie können den lokalen Bindplane-Server unter Linux installieren, indem Sie entweder ein Skript ausführen (empfohlen) oder eine Binärdatei herunterladen und manuell installieren. Weitere Informationen finden Sie unter Bindplane Server installieren.

So installieren Sie den lokalen Bindplane-Server unter Linux mit einem Script:

  1. Führen Sie dieses Skript aus:

    curl -fsSlL https://downloads.bindplane.com/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh

  2. Folgen Sie der Anleitung, die Sie durch die Serverinitialisierung führt.

So installieren Sie den lokalen Bindplane-Server unter Linux mit einer Binärdatei:

  1. Laden Sie eine der folgenden Dateien herunter:

  2. Aktualisieren Sie die Konfigurationsdatei gemäß der Anleitung unter Bindplane-Server konfigurieren.

Unterstützte Linux-Distributionen:
  • Red Hat, Centos, Oracle Linux 7, 8, 9
  • Debian 11 und 12
  • Ubuntu LTS 20.04 und 22.04
  • SUSE Linux 12 und 15
  • Alma und Rocky Linux

Weitere Informationen nachstehend:

Lokale Docker-Bereitstellungen

Weitere Informationen finden Sie unter Bindplane Server installieren.

Bindplane-Docker-Container-Images finden Sie an den folgenden Speicherorten:

  • GitHub-Pakete: ghcr.io/observiq/Bindplane-ee
  • Google-Artefakt-Repository: us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
  • Docker Hub: observiq/bindplane-ee

Container-Images werden mit der Release-Version getaggt: Release v1.35.0 hat beispielsweise das Tag observiq/bindplane-ee:1.35.0.

Bindplane-Collector installieren

In diesem Abschnitt wird beschrieben, wie Sie den Bindplane-Collector für Google SecOps auf verschiedenen Systemen installieren.

Collectors verwenden in der Regel nur minimale Ressourcen. Achten Sie bei der Verarbeitung großer Mengen von Logs jedoch auf den Ressourcenverbrauch, um Auswirkungen auf andere Dienste zu vermeiden. Weitere Informationen finden Sie unter Technische Anforderungen und Empfehlungen, Installation und Bereitstellung planen und Größenanpassung und Skalierung von Agents.

Informationen zum Installieren des Collectors (also des OTel-Agents) finden Sie unter Bindplane OTel Collector.

Weitere Informationen finden Sie in der GitHub-Dokumentation bindplane-otel-collector.

Für die Installation des Collectors benötigen Sie Folgendes:

  • Authentifizierungsdatei für die Datenaufnahme in Google SecOps

    So laden Sie die Authentifizierungsdatei herunter:

    1. Öffnen Sie die Google SecOps-Konsole.
    2. Rufen Sie Einstellungen > Datenverwaltung > Erfassungs-Agents auf.
    3. Laden Sie die Authentifizierungsdatei für die Google SecOps-Datenaufnahme herunter. Der nächste Schritt hängt von der Übertragungsmethode ab:
      • gRPC: Verwenden Sie die heruntergeladene Authentifizierungsdatei.
      • HTTPS: Erstellen Sie im Projekt Google Cloud , das mit Google SecOps verknüpft ist, ein Dienstkonto und weisen Sie ihm die Rolle Chronicle Editor zu.

  • Google SecOps-Kundennummer

    So finden Sie die Kundennummer:

    1. Öffnen Sie die Google SecOps-Konsole.
    2. Gehen Sie zu Einstellungen > Verwaltung > Profil.
    3. Kopieren Sie die Kundennummer aus dem Bereich Organization Details (Organisationsdetails).

  • Windows 2012 SP2 oder höher oder Linux-Host mit systemd

  • Internetverbindung

  • GitHub-Zugriff

Tools zur Bereitstellung

In diesem Abschnitt werden die Bereitstellungstools für Bindplane beschrieben.

GitOps

Stellen Sie Bindplane-Ressourcen mithilfe eines GitOps-Modells bereit, das Folgendes umfasst:

  • Bindplane-Authentifizierung
  • Bindplane-Befehlszeile
  • Netzwerkzugriff
  • Integration in ein GitHub-Repository und GitHub Actions
  • Vorhandene Ressourcen exportieren
  • Sensible Werte verwalten
  • GitHub Actions-Workflow einrichten
  • Detaillierte Anleitung zum Übernehmen und Testen der Konfiguration, zum Aktivieren automatischer Rollouts und zum Aktualisieren von Ressourcen mithilfe von direkten Änderungen oder der UI-Exportmethode
  • Sensible Werte aktualisieren und RBAC verwenden

Weitere Informationen finden Sie unter GitOps.

Ansible

Informationen zum Bereitstellen von Bindplane mit Ansible finden Sie unter bindplane-agent-ansible.

Bindplane-Befehlszeile

Informationen zur Bindplane-Befehlszeile finden Sie unter GitOps.

Terraform

Informationen zur Verwendung von Terraform zum Konfigurieren Ihrer Bindplane-Ressourcen finden Sie unter Bindplane-Anbieter.

Kubernetes

Weitere Informationen zu Kubernetes mit Bindplane finden Sie hier:

Bindplane-Collector unter Windows installieren

Führen Sie den folgenden PowerShell-Befehl aus, um den Bindplane-Collector unter Windows zu installieren:

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

Alternativ können Sie die Installation mit einem Installationsassistenten durchführen. Laden Sie dazu das aktuelle Installationsprogramm für Windows herunter. Öffnen Sie nach dem Herunterladen des Installationsprogramms den Installationsassistenten und folgen Sie der Anleitung, um den Bindplane-Collector zu konfigurieren und zu installieren.

Weitere Informationen zur Installation des Bindplane-Collectors unter Windows finden Sie unter Windows-Installation.

Bindplane-Collector unter Linux installieren

Sie können den Collector unter Linux mit einem Skript installieren, das automatisch bestimmt, welches Paket installiert werden soll. Sie können dasselbe Skript auch verwenden, um eine vorhandene Installation zu aktualisieren.

Führen Sie das folgende Script aus, um die Installation mit dem Installationsscript durchzuführen:

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

Installation aus einem lokalen Paket

Wenn Sie den Collector aus einem lokalen Paket installieren möchten, verwenden Sie -f mit dem Pfad zum Paket.

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh -f path_to_package

RPM-Installation

Laden Sie das RPM-Paket für Ihre Architektur von der Seite „Releases“ herunter und installieren Sie es mit rpm. Im folgenden Beispiel wird das Paket amd64 installiert:

sudo rpm -U ./observiq-otel-collector_v${VERSION}_linux_amd64.rpm
sudo systemctl enable --now observiq-otel-collector

Ersetzen Sie VERSION durch die Version des heruntergeladenen Pakets.

DEB-Installation

Laden Sie das DEB-Paket für Ihre Architektur von der Seite mit den Releases herunter und installieren Sie es mit dpkg. Im folgenden Beispiel wird das Paket amd64 installiert:

sudo dpkg -i --force-overwrite ./observiq-otel-collector_v${VERSION}_linux_amd64.deb
sudo systemctl enable --now observiq-otel-collector

Ersetzen Sie VERSION durch die Version des heruntergeladenen Pakets.

BindPlane-Collector konfigurieren

Nach der Installation des Collectors wird der Dienst observiq-otel-collector ausgeführt und kann konfiguriert werden.

Sie können den Collector entweder manuell oder über den Bindplane-Server konfigurieren.

Wenn Sie den Collector manuell konfigurieren, müssen Sie die Exporter-Parameter aktualisieren, damit sich der Collector bei Google SecOps authentifiziert.

OTel-Collector-Konfigurationsdatei

Unter Linux finden Sie die Konfigurationsdatei des Collectors unter /opt/observiq-otel-collector/config.yaml.

OTel-Collector-Dienst und -Logs

Der Collector protokolliert standardmäßig in C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

Das Standardfehlerprotokoll für den Collector-Prozess finden Sie unter C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

Führen Sie unter Linux sudo tail -F /opt/observiq-otel-collector/log/collector.log aus, um Logs vom Collector aufzurufen.

Gängige Linux-OTel-Collector-Dienstbefehle:

  • Führen Sie sudo systemctl stop observiq-otel-collector aus, um den OTel-Collector-Dienst zu beenden.

  • Führen Sie sudo systemctl start observiq-otel-collector aus, um den OTel-Collector-Dienst zu starten.

  • Führen Sie sudo systemctl restart observiq-otel-collector aus, um den OTel-Collector-Dienst neu zu starten.

  • Führen Sie sudo systemctl enable observiq-otel-collector aus, um den OTel-Collector-Dienst beim Start zu aktivieren.

Starten Sie den Collector-Dienst neu, damit die Konfigurationsänderungen wirksam werden:

Wenn Sie die Konfiguration ändern, müssen Sie den Collector-Dienst neu starten, damit die Konfigurationsänderungen wirksam werden (sudo systemctl restart observiq-otel-collector).

Standard-Beispielkonfigurationsdatei verwenden

Standardmäßig befindet sich eine Collector-Konfigurationsdatei unter C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

So laden Sie eine Beispielkonfigurationsdatei und ein Authentifizierungstoken herunter, die vom Collector verwendet werden:

  • Öffnen Sie die Google SecOps-Konsole und rufen Sie Einstellungen > Datenverwaltung > Erfassungs-Agents auf.

Passen Sie die folgenden beiden Abschnitte in der Konfigurationsdatei an:

  • Receiver: Gibt an, welche Logs der Collector erfassen und an Google SecOps senden soll.
  • Exporter: Gibt das Ziel an, an das der Collector die Logs sendet. Die folgenden Exporter werden unterstützt:
    • Google SecOps-Exporter: Sendet Logs direkt an die Google SecOps Ingestion API.
    • Google SecOps-Forwarder-Exporter: Sendet Logs an den Google SecOps-Forwarder.
    • Cloud Logging-Exporter: Sendet Logs an Cloud Logging.

Passen Sie im Exporter Folgendes an:

  • customer_id: Ihre Google SecOps-Kundennummer.
  • endpoint: Ihr regionaler Google SecOps-Endpunkt.

  • creds: Ihr Authentifizierungstoken.

    Alternativ können Sie creds_file_path verwenden, um direkt auf die Datei mit den Anmeldedaten zu verweisen. Verwenden Sie für die Windows-Konfiguration Backslashes, um den Pfad zu maskieren.

  • log_type: Logtyp. Wir empfehlen, WINDOWS_DNS als Logtyp auszuwählen.

  • ingestion_labels: Labels für die Datenaufnahme. Diese Labels identifizieren die Logs in Google SecOps.

  • namespace: Optionaler Namespace.

    Für jeden Logtyp müssen Sie einen Exporter konfigurieren.

Beispiele für die Konfiguration der Logerfassung

Die folgenden Abschnitte enthalten Konfigurationsbeispiele für die Logerfassung.

Windows-Ereignisse und Sysmon direkt an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

Beispielkonfiguration:

receivers:
  windowseventlog/sysmon:
    channel: Microsoft-Windows-Sysmon/Operational
    raw: true
  windowseventlog/security:
    channel: security
    raw: true
  windowseventlog/application:
    channel: application
    raw: true
  windowseventlog/system:
    channel: system
    raw: true

processors:
  batch:

exporters:
  chronicle/sysmon:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.",
  "universe_domain": "googleapis.com"
}' 
    log_type: 'WINDOWS_SYSMON'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'
  chronicle/winevtlog:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.",
  "universe_domain": "googleapis.com"
}'
    log_type: 'WINEVTLOG'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'

service:
  pipelines:
    logs/sysmon:
      receivers: [windowseventlog/sysmon]
      processors: [batch]
      exporters: [chronicle/sysmon]
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: [batch]
      exporters: [chronicle/winevtlog]

Windows-Ereignisse und Syslog direkt an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

Beispielkonfiguration:

receivers:
    tcplog:
      listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicle/chronicle_w_labels
        logs/source1__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Windows-Ereignisse und Syslog an den Google SecOps-Forwarder senden

Konfigurieren Sie diese Parameter im Beispiel:

Beispielkonfiguration:

receivers:
tcplog:
    listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicleforwarder/forwarder:
        export_type: syslog
        raw_log_field: body
        syslog:
            endpoint: 127.0.0.1:10514
            transport: udp
service:
    pipelines:
        logs/source0__forwarder-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicleforwarder/forwarder
        logs/source1__forwarder-0:
            receivers:
                - tcplog
            exporters:
                - chronicleforwarder/forwarder

Syslog direkt an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

Beispielkonfiguration:

receivers:
  tcplog:
    listen_address: "0.0.0.0:54525"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Windows-Ereignisse per Fernzugriff erfassen und direkt an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

  • windowseventlogreceiver
    • username
    • password
    • server
  • chronicleexporter
    • namespace
    • ingestion_labels
    • log_type
    • customer_id
    • creds

Beispielkonfiguration:

receivers:
    windowseventlog/system:
        channel: system
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "remote-server"
    windowseventlog/application:
        channel: application
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
    windowseventlog/security:
        channel: security
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: WINEVTLOG
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/system
                - windowseventlog/application
                - windowseventlog/security
            exporters:
                - chronicle/chronicle_w_labels

Daten an Cloud Logging senden

Konfigurieren Sie den Parameter credentials_file im Beispiel.

Beispielkonfiguration:

exporters:
  googlecloud:
    credentials_file: /opt/observiq-otel-collector/credentials.json

SQL-Datenbank abfragen und die Ergebnisse an Google SecOps senden

Konfigurieren Sie diese Parameter im Beispiel:

Beispielkonfiguration:

receivers:
  sqlquery/source0:
    datasource: host=localhost port=5432 user=postgres password=s3cr3t sslmode=disable
    driver: postgres
    queries:
      - logs:
          - body_column: log_body
        sql: select * from my_logs where log_id > $$1
        tracking_column: log_id
        tracking_start_value: "10000"
processors:
  transform/source0_processor0__logs:
    error_mode: ignore
    log_statements:
      - context: log
        statements:
          - set(attributes["chronicle_log_type"], "POSTGRESQL") where true
exporters:
  chronicle/chronicle_sql:
    compression: gzip
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.",
  "universe_domain": "googleapis.com"
}' 
    customer_id: customer_id
    endpoint: malachiteingestion-pa.googleapis.com
    log_type: POSTGRESQL
    namespace: null
    raw_log_field: body
    retry_on_failure:
      enabled: false
    sending_queue:
      enabled: false
service:
  pipelines:
    logs/source0_chronicle_sql-0:
      receivers:
        - sqlquery/source0
      processors:
        - transform/source0_processor0__logs
      exporters:
        - chronicle/chronicle_sql

Logs verwerfen, die mit einem regulären Ausdruck übereinstimmen

Sie können den Collector so konfigurieren, dass Logs, die einem regulären Ausdruck entsprechen, verworfen werden. Das ist nützlich, um unerwünschte Logs wie bekannte Fehler oder Debugging-Nachrichten herauszufiltern.

Wenn Sie Logs verwerfen möchten, die mit einem regulären Ausdruck übereinstimmen, fügen Sie Ihrer Konfiguration einen Prozessor vom Typ filter/drop-matching-logs-to-Chronicle hinzu. Dieser Prozessor verwendet die Funktion IsMatch, um den Logtext mit dem regulären Ausdruck abzugleichen. Wenn die Funktion true zurückgibt, wird das Log verworfen.

In der folgenden Beispielkonfiguration werden Logs verworfen, die die Strings <EventID>10</EventID> oder <EventID>4799</EventID> im Logtext enthalten.

Sie können den regulären Ausdruck an jedes gewünschte Muster anpassen. Die Funktion IsMatch verwendet die RE2-Syntax für reguläre Ausdrücke.

Beispielkonfiguration:

processors:
    filter/drop-matching-logs-to-Chronicle:
        error_mode: ignore
        logs:
            log_record:
                - (IsMatch(body, "<EventID>10</EventID>")) or (IsMatch(body, "<EventID>4799</EventID>"))

Im folgenden Beispiel wird der Prozessor in derselben Konfiguration zur Pipeline hinzugefügt:

service:
  pipelines:
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: 
      - filter/drop-matching-logs-to-Chronicle # Add this line
      - batch
      exporters: [chronicle/winevtlog]

Bindplane-Betrieb und -Wartung

In diesem Abschnitt werden routinemäßige Betriebs- und Wartungsmaßnahmen beschrieben.

OTel-Konfiguration prüfen

Informationen zum Prüfen der Bindplane-OTel-Konfiguration finden Sie unter OTelBin.

Updates zu Collector-Releases

BindPlane kann bindplane-otel-collector/releases abfragen, um neue Collector-Releases zu erkennen. Diese Funktion ist optional.

Sie können das GitHub-Polling deaktivieren, indem Sie in Ihrer Bindplane-Konfiguration agentVersions.syncInterval auf 0 setzen:

agentVersions:
syncInterval: 0

Sicherung und Notfallwiederherstellung

Informationen zur Sicherung und Notfallwiederherstellung mit Bindplane finden Sie unter Bindplane-Ressourcen.

PostgreSQL-Sicherung und Notfallwiederherstellung

Informationen zur Sicherung und Notfallwiederherstellung von PostgreSQL mit Bindplane finden Sie in der PostgreSQL-Dokumentation.

BBolt-Sicherung und Notfallwiederherstellung

Informationen zur Sicherung und Notfallwiederherstellung mit BBolt (eingestellt) und Bindplane finden Sie in der BBolt Store-Dokumentation.

Resilienz und Wiederholung

Wiederholungsversuche sind standardmäßig für alle Ziele aktiviert, die diese Funktion unterstützen. Standardmäßig werden fehlgeschlagene Anfragen nach fünf Sekunden wiederholt und nach bis zu 30 Sekunden schrittweise zurückgestellt. Nach fünf Minuten werden Anfragen endgültig verworfen.

Weitere Informationen finden Sie unter Collector-Ausfallsicherheit.

Logvolumen mit dem Schweregradfilter reduzieren

Informationen zum Reduzieren des Logvolumens finden Sie unter Logvolumen mit dem Schweregradfilter reduzieren.

Bindplane-Integrationen mit Drittanbieter-Collectors

Bindplane ist zwar leistungsfähiger, wenn Sie den Bindplane-Collector für die Erfassung am Edge verwenden, aber in den meisten Fällen kann Bindplane in Ihrer vorhandenen Infrastruktur verbleiben. Wenn Sie beispielsweise bereits Fluent Bit oder Splunk Universal Forwarder verwenden, können Sie dies weiterhin tun.

Bindplane-Integration in Splunk

Informationen zu Splunk mit Bindplane finden Sie hier:

Bindplane-Integrationen mit anderen Drittanbieter-Collectors

Informationen zu Bindplane-Integrationen mit Drittanbieter-Collectors finden Sie unter Andere OpenTelemetry-Collectors mit der OpAMP-Erweiterung verbinden.

Silent Host Monitoring

Mit dem Silent Host Monitoring von Google Security Operations können Sie mit Google Cloud Monitoring Benachrichtigungen für Änderungen der Aufnahmerate erstellen. Es werden Benachrichtigungen pro Collector generiert und Sie werden benachrichtigt, wenn die Aufnahmerate unter den von Ihnen definierten Grenzwert fällt. Dies weist auf potenzielle Collector-Stopps hin.

Informationen zur Verwendung von Bindplane für das Monitoring von Silent Hosts finden Sie hier:

Bindplane unter Linux aktualisieren

Wenn Sie den Installationsbefehl ohne das Flag --init am Ende ausführen, reicht das aus, um Bindplane zu aktualisieren. Führen Sie dieses Script auf Ihrem Bindplane-Server aus, um ein Upgrade von Bindplane durchzuführen. Weitere Informationen finden Sie unter Bindplane Server aktualisieren, herabstufen oder deinstallieren.

Bindplane überwachen

Informationen zum Monitoring von Bindplane finden Sie unter Bindplane überwachen.

Kubernetes in Bindplane überwachen

Informationen zum Monitoring von Kubernetes in Bindplane finden Sie unter Kubernetes-Monitoring.

Zusätzliche Dokumentation

Weitere Informationen zu Bindplane (früher observIQ) finden Sie hier:

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten