Der EventSentry Collector, eingeführt in Version 3.2, ermöglicht eine 3-Schichten-Architektur zwischen einer Aktion (z.B. Datenbank, E-Mail-Server) und den EventSentry-Agenten. Wenn er aktiviert ist, bietet der Collector eine Funktionalität ähnlich wie ein Proxy-Server (wenn auch mit wesentlich mehr Funktionalität) und kommuniziert mit einer unterstützenden EventSentry-Aktion im Namen eines Remote-Agenten. Der Collector unterstützt sowohl Komprimierung als auch sichere TLS-Verschlüsselung.
Der Collector kann während der Installation aktiviert werden (Standardverhalten) oder nach einer Installation oder einem Upgrade konfiguriert werden. Eine Aktion wird unter den folgenden Umständen über einen Collector geleitet:
• Ein Collector wird in den "Collector"-Einstellungen konfiguriert (und ausgeführt)
• Die Aktion kann durch einen Collector geleitet (siehe "Unterstützte Aktionen") und für die Verwendung eines Collectors konfiguriert werden
|
Es ist möglich und wird unterstützt, nur einige Aktionen über einen Collector zu leiten, andere Aktionen jedoch für eine direkte Kommunikation (zwischen Agent und Aktion) zu konfigurieren. |
Unterstützte Plattformen
Der Collector ist als 64-Bit (x64) und 32-Bit (x86) Binärdatei verfügbar. Die 64-Bit-Binärdatei wird empfohlen und standardmäßig auf 64-Bit-Betriebssystemen installiert.
Unterstützte Aktionen
Die folgenden Aktionen können über einen Collector geleitet werden:
• Datenbank
• E-Mail (SMTP)
• Syslog
• Datei
Alle anderen Aktionen kommunizieren entweder direkt mit der entfernten Aktion (z.B. HTTP-Aktion) oder werden lokal ausgeführt (z.B. Prozess-Aktion).
Unterstützte Komponenten
Die folgenden Komponenten können derzeit den Collector nutzen, alle anderen Komponenten kommunizieren weiterhin direkt mit ihren jeweiligen Aktionen:
•Agents
•Heartbeat Service
•Network Services
Vorteile
Die Verwendung des Collectors bietet folgenden Vorteile:
1. Die Kommunikation zwischen den Agenten und dem Collector kann für mehr Privatsphäre verschlüsselt werden, was für Hosts, die Daten über ein unsicheres Netzwerk übertragen (z.B. Laptops), nützlich ist.
2. Die Kommunikation zwischen den Agenten und dem Collector kann komprimiert werden, um den Bandbreitenverbrauch zu reduzieren
3. Die Sicherheit kann erhöht werden, indem Aktionen, wie z.B. ein Datenbank- oder E-Mail-Server, so eingeschränkt werden, dass nur der Collector und nicht alle Agenten darauf zugreifen können.
4. Datenbank: Alle Daten werden vom Agenten zwischengespeichert, wenn der Collector vorübergehend nicht verfügbar ist. Nur Ereignisprotokolldaten werden im Cache gespeichert, wenn kein Collector verwendet wird, während die Datenbank nicht verfügbar ist.
5. Datenbank: Obwohl automatisch von den EventSentry-Agenten verwaltet, müssen ODBC-Treiber nicht auf den Agenten installiert werden.
6. Datenbank: Die Anmeldedaten für die Datenbank müssen nicht an die Agenten übermittelt werden, da sie nicht direkt mit der Datenbank verbunden sind.
7. Agentenverwaltung: Der Collector kann automatisch Konfigurations- und Agent-Updates an entfernte Agenten übertragen.
Nachteile
In einigen Fällen kann die traditionelle Methode, bei der die Agenten direkt mit einer Aktion kommunizieren, vorzuziehen sein. Der Collector bietet in den folgenden Szenarien wenig Nutzen:
1. Die gesamte Installation erstreckt sich nur über einen einzigen Host
2. Die Agenten haben eine direkte Verbindung mit der Datenbank oder dem E-Mail-Server
3. Daten, die vom Agenten an die Aktion gesendet werden, werden bereits über ein sicheres Netzwerk übertragen
4. Daten, die vom Agenten an die Aktion gesendet werden, werden bereits über ein schnelles Netzwerk übertragen, wo die Komprimierung wenig oder keinen Nutzen bringt
5. Die Aktion (z.B. Datenbank) ist zuverlässig und hat keine oder nur geringe Ausfallzeiten
6. Die Installation und/oder Wartung eines oder mehrerer Collectors ist nicht wünschenswert
Da der Collector ein potenzieller Single Point of Failure (SPOF) ist, bietet EventSentry die folgenden Funktionen, um eine maximale Verfügbarkeit zu gewährleisten:
•Agenten speichern alle Daten in einem persistenten lokalen Cache, wenn sie den Collector nicht erreichen können. Die Daten werden erneut übermittelt, sobald der Collector erreichbar ist.
•Der Collector speichert alle Daten im Cache, wenn er eine Aktion (z.B. Datenbank, E-Mail-Server) nicht im Speicher erreichen kann, und wird auf die Festplatte gespült, wenn der Collectordienst beendet wird. Zwischengespeicherte Daten werden in temporäre Dateien ausgelagert, wenn der In-Memory-Cache (auch als Warteschlange bezeichnet) entweder eine harte Grenze überschreitet oder aufgrund früherer Nutzung ungewöhnlich hoch ist.
•Der Collector protokolliert Ereignis ID 210, wenn das Auslagern beginnt, gefolgt von Ereignis 214, wenn das Auslagern deaktiviert wird. Der Collector benötigt mindestens 500 MB freien Speicherplatz auf dem Laufwerk %SYSTEMROOT%, um das Paging auf der Festplatte zu unterstützen.
•Mehrere Collectors können für zusätzliche Redundanz konfiguriert werden.
Leistung
Der Collectordienst ist so konzipiert, dass er sowohl eine große Anzahl von Kunden als auch große Datenmengen in Echtzeit unterstützt. Für Datenbankaktionen verwendet der Collector mehrere (~20) gleichzeitige DB-Verbindungen, um einen hohen Durchsatz zu gewährleisten. Der aktuelle Status des Collectors kann in den Web Reports unter dem Menüabschnitt Werkzeuge/Wartung ("Collector Status") eingesehen werden, wenn "Collect Statistics" aktiviert ist.
