BindPlane mit Google SecOps verwenden

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.

Bindplane umfasst die folgenden Hauptkomponenten:

  • BindPlane-Collector: Ein Open-Source-Agent, der auf dem OpenTelemetry-Collector (OTel) basiert. Es 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 wird auch als Bindplane Distribution for OpenTelemetry (BDOT) Collector, Bindplane-Agent, Erfassungs-Agent, Collector oder Agent bezeichnet.

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

    Diese Komponente wird möglicherweise 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-Version) wird allen Google SecOps-Kunden zur Verfügung gestellt.

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

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

Bindplane Enterprise (Google-Version) – für Google SecOps Enterprise Plus-Kunden

Bindplane Enterprise (Google-Version) ist für Google SecOps Enterprise Plus-Kunden enthalten.

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

Wenden Sie sich an Ihr Google-Kontoteam, um Ihren Lizenzschlüssel für Bindplane Enterprise (Google Edition) zu erhalten.

BindPlane-Versionen von Google – Unterschiede

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

Thema/Funktion Bindplane (Google Edition) Bindplane Enterprise (Google-Version)
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 Monaten Weiterleitung an ein Nicht-Google-Ziel für SIEM-Migrationen
Filtern Einfacher Filter mit regulärem Ausdruck Prozessoren für erweiterte Filterung (z. B. nach Bedingung, Feld, Schweregrad usw.), Datenreduzierung, Protokoll-Sampling, Deduplizierung
Entfernen – Maskierung personenidentifizierbarer Informationen
Transformation Feld hinzufügen, Feld verschieben, Daten parsen (KV, JSON, CSV, XML, Zeitstempel, Parsing nach regulärem Ausdruck), Feld umbenennen, Event Breaker Enthält alle in BindPlane (Google-Version) unterstützten Funktionen sowie „Feld löschen“, „Leere Werte löschen“ und „Zusammenführen“.
Allgemeine Funktionen auf Plattformebene Gateway (Aggregieren von Daten aus Collectoren), BindPlane-Collectoren, BindPlane-Server (BindPlane-Verwaltungsebene) lokal oder in der Cloud gehostet, alle Quellen, Silent-Host-Überwachung über den Google SecOps-Prozessor, persistente Warteschlange, Telemetrie anreichern, hohe Verfügbarkeit, RBAC, beide Google SecOps-Aufnahme-APIs werden unterstützt, Anmeldedatenverschleierung, erweiterte Flottenverwaltung einschließlich Gruppierung von Collectoren, dynamische Zuweisung von Logtypen Alle in Bindplane (Google-Version) 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 in 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 Protokolle an einen Collector, der als Gateway fungiert

Für umfangreiche Bereitstellungen empfehlen wir die Verwendung von Bindplane Enterprise (Google Edition)-Collectoren, die als Gateways fungieren. Diese Gateways empfangen Telemetriedaten von anderen Collectors über das Netzwerk, führen optional eine zusätzliche Verarbeitung durch und leiten die Daten an Google SecOps weiter.

Ein Collector, der als Gateway fungiert, verwendet dasselbe Binärprogramm wie alle anderen Collectors.

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

Collectors senden Protokolle an einen Collector, der als Gateway fungiert

Collectors senden Logs direkt an die Google SecOps Ingestion API.

Das folgende Diagramm zeigt, wie Collectors Protokolle 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, wie Collectors Logs direkt an Cloud Logging senden:

Collectors senden Logs direkt an Cloud Logging

Collectors senden Logs an mehrere Ziele

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

Collector sendet Protokolle an mehrere Ziele

Bindplane-Server

Der BindPlane-Server bietet die folgenden wichtigen Funktionen:

  • Zentrale Verwaltung: Auf dem Server können Sie alle Ihre OTel-Collector-Bereitstellungen in Google Cloudverwalten. Sie können den Status jeder Bereitstellung aufrufen und gängige Verwaltungsaufgaben wie das Starten, Beenden und Neustarten von Collectors ausführen.
  • Echtzeitüberwachung: Der Server bietet Echtzeitüberwachung Ihrer OTel-Collector-Bereitstellungen. Sie können Messwerte wie CPU-Auslastung, Speicherauslastung und Durchsatz im Blick behalten. Sie können 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 Messwertschwellenwert überschritten wird.
  • Konfigurationsverwaltung: Mit dem Server können Sie die Konfiguration Ihrer OTel-Collectoren zentral verwalten. Sie können Konfigurationsdateien bearbeiten, Umgebungsvariablen festlegen und Sicherheitsrichtlinien auf alle Ihre Bereitstellungen anwenden.
  • Einbindung in Google Cloud: Sie können OTel-Collector-Bereitstellungen in Google Cloud erstellen und verwalten und über den Server auf Ihre Google Cloud -Ressourcen zugreifen.

Bindplane bietet Cloud- und lokale Bereitstellungsoptionen. 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 unterhält Netzwerkverbindungen für Folgendes:

  • Collector-Verwaltung
  • Collector-Durchsatzmessungen
  • Befehlszeilen und Weboberflächen

Verbindungsanforderungen

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

Der Bindplane-Port wird für Folgendes verwendet:

  • Collector-Befehle und ‑Steuerung über OpAMP (WebSocket)
  • Anfragen zur Messung des Collector-Durchsatzes (HTTP POST-Anfrage)
  • Browser- und CLI-Nutzer (HTTP und WebSocket)

Collectors müssen Verbindungen zu Bindplane für OpAMP (WebSocket) und Durchsatzmessungen (HTTP) initiieren können.

BindPlane initiiert niemals Verbindungen zu den Collectors. Sie können eine Firewall konfigurieren, um zu verhindern, dass Bindplane auf die Collector-Netzwerke zugreift. Die Collector-Netzwerke müssen jedoch über den konfigurierten Port auf Bindplane zugreifen können.

Allgemeine technische Anforderungen an Bindplane-Collector

Informationen zu den allgemeinen technischen Anforderungen für den BindPlane-Collector finden Sie unter:

Ressourcenanforderungen für Collector

Die Ressourcenanforderungen von Bindplane unterscheiden sich je nach Anzahl der verwalteten Collectoren. Mit zunehmender Anzahl verwalteter Collectors steigen auch die CPU-, Arbeitsspeicher-, Festplattendurchsatz-/IOPS- und Netzwerknutzung.

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 der Bindplane-Bereitstellung berücksichtigen sollten.

Skalierung und Fehlertoleranz berücksichtigen

Horizontales Skalieren ist vorzuziehen, da es Fehlertoleranz bietet und Engpässe bei Exportern beseitigen kann.

Wenn Sie Bindplane-Collectoren 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 Collectoren berechnen

Berücksichtigen Sie bei der Berechnung der Anzahl der für Ihre Arbeitslast erforderlichen Collectors den erwarteten Durchsatz oder die erwartete Protokollrate 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, steigen die Rechenanforderungen.

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

Collector-Flotte für Fehlertoleranz überdimensionieren

Stellen Sie mehr Collector-Instanzen bereit als benötigt, um Fehlertoleranz zu gewährleisten. Falls ein oder mehrere Collectors ausfallen oder zur Wartung offline genommen werden, müssen die verbleibenden Collectors über genügend Kapazität verfügen, um den Telemetrie-Durchsatz zu bewältigen.

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 verrichten. Wenn Sie hohe Anforderungen an die Verarbeitung haben, kann es sinnvoll sein, diese Verarbeitung auf eine Flotte von Gateway-Collectoren auszulagern. Anstatt Telemetriedaten beispielsweise mit einem aufwendigen regulären Ausdruck zu filtern, können Sie diese Aufgabe von den Gateway-Collectoren ausführen lassen. In der Regel werden Gateway-Collectors auf einem dedizierten System ausgeführt. Dies rechtfertigt den Verarbeitungsaufwand, da er nicht die Rechenleistung anderer Dienste beansprucht, die auf demselben System ausgeführt werden. Das ist bei einem Nicht-Gateway-Collector, der möglicherweise auf einem Datenbankserver ausgeführt wird, anders.

Best Practices für den Gateway-Modus

Wenn Sie Bindplane-Collectoren im Gateway-Modus ausführen, empfehlen wir, die Bereitstellung gemäß 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 persistente Warteschlange haben.

Bei Bedarf Load-Balancer verwenden

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

Wenn Sie Bindplane-Collectoren 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 Möglichkeit, Ausfälle zu verkraften, ohne dass es zu Unterbrechungen kommt.

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

Weitere Informationen finden Sie unter Load Balancer.

Load-Balancing-Port und ‑Protokolle

Bindplane überwacht standardmäßig Port 3001.

Um die große Bandbreite an netzwerkbasierten Empfängern in OpenTelemetry zu unterstützen, muss der Load-Balancer Folgendes unterstützen:

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

Dimensionierung des Load-Balancing

Bindplane-Knoten sollten aus Gründen der maximalen Fehlertoleranz nicht mehr als 30.000 Collectors verwalten. Jeder Collector öffnet zwei Verbindungen zu Bindplane (eine für die OpAMP-Remote-Verwaltung und eine zum Veröffentlichen von Durchsatzmesswerten). Dieses Limit trägt dazu bei, dass Sie das Verbindungslimit von etwa 65.535 pro Backend-Instanz, das von den meisten Load Balancern auferlegt 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 zur Wartung heruntergefahren wird, da jede verbleibende Bindplane-Instanz dann 50.000 Collectors oder 100.000 TCP-Verbindungen verwalten würde.

Best Practices für die Dimensionierung von Load Balancern

  • Systemdiagnosen implementieren Konfigurieren Sie den Load Balancer so, dass der Collector bereit ist, Traffic zu empfangen.
  • Verbindungen gleichmäßig verteilen: Verbindungen sollten gleichmäßig auf die Collectors verteilt werden.

  • Erforderliche Protokolle unterstützen: Um die große Bandbreite an netzwerkbasierten Empfängern in OpenTelemetry zu unterstützen, muss der Load-Balancer Folgendes unterstützen:

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

Weitere Informationen finden Sie unter Collector-Resilience.

Load-Balancing nach Quelltyp

Jeder Quelltyp, der Telemetriedaten von Remote-Systemen über das Netzwerk empfängt, eignet sich für das Load-Balancing, 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 Einzelinstanzkonfiguration oder in einer Konfiguration mit mehreren Instanzen bereitstellen. Für Produktionsbereitstellungen, die Hochverfügbarkeit (High Availability, HA) und Ausfallsicherheit erfordern, empfehlen wir die Verwendung eines Bereitstellungsmodells mit mehreren Instanzen (HA).

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

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

Anzahl der Collector- und Bindplane-Server für HA berechnen

Wenn Sie BindPlane im HA-Modus betreiben, müssen Sie berücksichtigen, wie viele Collectors jeder BindPlane-Server verarbeiten soll.

Nehmen Sie die Gesamtzahl der Bindplane-Instanzen und ziehen Sie die maximale Anzahl von Knoten ab, 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 HA

Postgres ist eine Voraussetzung, wenn Sie Bindplane im HA-Modus betreiben.

Prometheus für HA

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

Weitere Informationen finden Sie unter Prometheus.

Ereignisbus für HA

BindPlane verwendet einen Ereignisbus 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.

Single-Instance-Bereitstellung für eine Testumgebung oder einen Proof-of-Concept verwenden

Für eine Testumgebung oder einen Proof-of-Concept empfehlen wir eine Einzelinstanzbereitstellung.

Weitere Informationen finden Sie unter Einzelne Instanz.

Back-End-Anmeldedaten isolieren

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

Gateway-Collector 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 dürfen, Gateway-Collectors aber nicht auf Ihr Anwendungsnetzwerk zugreifen können. 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 auf dem konfigurierten Port an Bindplane zulassen.

Firewallkonfiguration prüfen

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

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

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 in der Regel die Leistung von PostgreSQL-Speicher-Back-Ends. Wir empfehlen, den PostgreSQL-Speicher mit Speicher mit niedriger Latenz und hohem Durchsatz zu sichern, z. B. mit Solid-State-Laufwerken (SSDs).

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:

Geeignete Authentifizierung implementieren

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

BindPlane-Server verwenden

Die meisten Google SecOps-Kunden verwenden den Bindplane-Server, aber seine Verwendung ist 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 zur Konfiguration des Bindplane-Servers zum Standardisieren von Logs und zum Exportieren in Google SecOps finden Sie [auf dieser Seite](https://bindplane.com/use-case-demo). Wählen Sie dann Google SecOps Configuration aus.

Bindplane Cloud-Server verwenden

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

Melden Sie sich in der Google-Version an.

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

BindPlane-Server auf Ihrem Google Cloudverwenden

Informationen zum Ausführen des BindPlane-Servers auf Ihrem 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 Skript:

  1. Führen Sie dieses Skript aus:

    curl -fsSlL https://storage.googleapis.com/bindplane-op-releases/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh

  2. Folgen Sie der Anleitung, um den Server zu initialisieren.

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 Releaseversion getaggt, z. B. Release v1.35.0 mit dem 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 benötigen in der Regel nur minimale Ressourcen. Wenn Sie jedoch große Mengen an Logs verarbeiten, sollten Sie auf den Ressourcenverbrauch achten, um Auswirkungen auf andere Dienste zu vermeiden. Weitere Informationen finden Sie unter Technische Anforderungen und Empfehlungen, Installation und Bereitstellung planen und Agent-Größe und ‑Skalierung.

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

Sie können auch die GitHub-Dokumentation bindplane-otel-collector aufrufen.

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

  • Google SecOps-Datei für die Authentifizierung der Aufnahme

    So laden Sie die Authentifizierungsdatei herunter:

    1. Öffnen Sie die Google SecOps-Konsole.
    2. Rufen Sie die SIEM-Einstellungen > Collection Agent auf.
    3. Laden Sie die Authentifizierungsdatei für die Google SecOps-Aufnahme herunter.

  • Google SecOps-Kundennummer

    So finden Sie die Kunden-ID:

    1. Öffnen Sie die Google SecOps-Konsole.
    2. Rufen Sie die SIEM-Einstellungen > Profile auf.
    3. Kopieren Sie die Kunden-ID aus dem Bereich 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 mit einem GitOps-Modell bereit, das Folgendes umfasst:

  • Bindplane-Authentifizierung
  • Bindplane-CLI
  • Netzwerkzugriff
  • Einbindung in ein GitHub-Repository und GitHub Actions
  • Vorhandene Ressourcen exportieren
  • Sensible Werte verwalten
  • GitHub Actions-Workflow einrichten
  • Schritt-für-Schritt-Anleitung zum Übertragen und Testen der Konfiguration, zum Aktivieren automatischer Roll-outs 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-CLI

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 unter:

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 das aktuelle Installationsprogramm für Windows herunterladen, um die Installation mit einem Installationsassistenten durchzuführen. Ö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 ermittelt, welches Paket installiert werden soll. Sie können dasselbe Skript auch verwenden, um eine vorhandene Installation zu aktualisieren.

Führen Sie das folgende Skript aus, um die Installation mit dem Installationsskript 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 mit den Releases herunter und installieren Sie das Paket 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 „Releases“ herunter und installieren Sie das Paket mit dpkg. Sehen Sie sich das folgende Beispiel für die Installation des amd64-Pakets an:

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 observiq-otel-collector-Dienst 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 Exportparameter aktualisieren, damit der Collector sich bei Google SecOps authentifiziert.

OTel Collector-Konfigurationsdatei

Unter Linux befindet sich 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 Standardfehlerlog für den Collector-Prozess finden Sie unter C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

Wenn Sie unter Linux Logs vom Collector aufrufen möchten, führen Sie sudo tail -F /opt/observiq-otel-collector/log/collector.log aus.

Häufige Linux-Befehle für den OTel-Collector-Dienst:

  • Führen Sie sudo systemctl stop observiq-otel-collector aus, um den OTel-Collectors-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.

Collector-Dienst für die Konfigurationsänderungen neu starten

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

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 SIEM-Einstellungen > Collection Agent auf.

Passen Sie die folgenden beiden Abschnitte in der Konfigurationsdatei an:

  • Empfänger: 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 Protokolle an den Google SecOps Forwarder.
    • Cloud Logging-Exporter: Sendet Logs an Cloud Logging.

Passen Sie im Exporter Folgendes an:

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

  • creds: Ihr Authentifizierungstoken.

    Alternativ können Sie mit creds_file_path direkt auf die Datei mit den Anmeldedaten verweisen. Bei der Windows-Konfiguration müssen Sie den Pfad mit Backslashes 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 Exporteur konfigurieren.

Beispiele für die Konfiguration der Logerfassung

Die folgenden Abschnitte enthalten Konfigurationsbeispiele für die Protokollerfassung.

Windows-Ereignisse und Sysmon-Ereignisse 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.iam.gserviceaccount.com",
  "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.iam.gserviceaccount.com",
  "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.iam.gserviceaccount.com",
  "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.iam.gserviceaccount.com",
  "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 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 remote 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 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.iam.gserviceaccount.com",
  "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.iam.gserviceaccount.com",
  "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 löschen, die mit einem regulären Ausdruck übereinstimmen

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

Wenn Sie Logs verwerfen möchten, die einem regulären Ausdruck entsprechen, fügen Sie Ihrer Konfiguration einen Prozessor vom Typ filter/drop-matching-logs-to-Chronicle hinzu. Dieser Prozessor verwendet die Funktion IsMatch, um den Log-Body anhand des regulären Ausdrucks auszuwerten. Wenn die Funktion true zurückgibt, wird der Log verworfen.

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

Sie können den regulären Ausdruck an jedes beliebige 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 der Pipeline in derselben Konfiguration 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 Routinevorgänge und Wartungsmaßnahmen beschrieben.

OTel-Konfiguration prüfen

Informationen zum Überprüfen der BindPlane-OTel-Konfiguration finden Sie unter OTelBin.

Versionsupdates für Collectors

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.

Sicherung und Notfallwiederherstellung von PostgreSQL

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

BBolt-Sicherung und ‑Notfallwiederherstellung

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

Robustheit und Wiederholungsversuche

Die Funktion „Wiederholen“ ist standardmäßig für alle Ziele aktiviert, die sie unterstützen. Standardmäßig werden fehlgeschlagene Anfragen nach fünf Sekunden wiederholt und das Backoff-Intervall wird progressiv auf bis zu 30 Sekunden erhöht. Nach fünf Minuten werden Anfragen endgültig gelöscht.

Weitere Informationen finden Sie unter Collector-Resilience.

Logvolumen mit dem Schweregradfilter reduzieren

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

Bindplane-Integrationen mit Drittanbieter-Collectoren

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

BindPlane-Integration in Splunk

Weitere Informationen zu Splunk mit BindPlane finden Sie unter:

Bindplane-Integrationen mit anderen Drittanbieter-Collectors

Informationen zu Bindplane-Integrationen mit Drittanbieter-Collectoren finden Sie unter Andere OpenTelemetry-Collectoren über die OpAMP-Erweiterung verbinden.

Silent Host Monitoring

Mit Google Security Operations Silent Host Monitoring 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 Erfassungsrate unter den von Ihnen definierten Grenzwert fällt. Dies kann auf einen möglichen Collector-Stopp hinweisen.

Informationen zur Verwendung von BindPlane für das Silent-Host-Monitoring finden Sie unter:

Bindplane unter Linux aktualisieren

Wenn Sie den Installationsbefehl ohne das Flag --init am Ende ausführen, wird Bindplane aktualisiert. Führen Sie dieses Skript auf Ihrem BindPlane-Server aus, um BindPlane zu aktualisieren. Weitere Informationen finden Sie unter Bindplane Server upgraden, downgraden oder deinstallieren.

Bindplane überwachen

Informationen zum Überwachen von BindPlane finden Sie unter BindPlane überwachen.

Kubernetes in BindPlane überwachen

Informationen zum Überwachen von Kubernetes in Bindplane finden Sie unter Kubernetes Monitoring.

Zusätzliche Dokumentation

Weitere Informationen zu BindPlane (früher observIQ) finden Sie unter:

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