In diesem Artikel werden mehrere Optionen zur Überwachung Ihrer TIE-Serverbereitstellung beschrieben.
HINWEIS: Ab TIE Server Version 2.1.0 werden Master- und Slave-Operationen als primäre und sekundäre Operationen bezeichnet. Beispiel:
Master heißt nun Primär
Slave heißt nun Sekundär
In früheren Versionen von TIE Server werden nach wie vor die bisherigen Bezeichnungen Master und Slave verwendet.
ePolicy Orchestrator – Automatische Reaktionen hinsichtlich des TIE-Serverzustands Ab TIE Server 1.3.0 können Sie mithilfe von ePolicy Orchestrator-Serverereignissen (ePO) automatische ePO-Reaktionen wie E-Mail-Benachrichtigungen und andere Aktionen erstellen.
Der ePO-Server-Task für die
TIE-Server-Überwachung wird stündlich ausgeführt. Wenn TIE-Server-Instanzen nicht erreichbar sind oder ihre Zustands-API nicht reagiert, werden Ereignisse erstellt. Erstellen Sie entsprechende automatische ePO-Reaktionen, die beim Empfang der Ereignisse ausgeführt werden. Für die Ereignisse wird der ID-Bereich 37175–37179 verwendet. Jede ID entspricht zur leichteren Fehlerbehebung einem gegebenen Betriebsmodus des TIE-Servers. Erstellen Sie die automatischen Antworten unter
Menü,
Automatische Antworten,
Neue Antwort. Geben Sie für den
Ereignistyp die Option
Server an. Filtern Sie nach der
Ereignis-ID. Diese muss
gleich dem TIE-Serverbereich
37175–37179 sein.
HINWEIS: Damit E-Mails für automatische Antworten empfangen werden, muss unter "Menü", "Server-Einstellungen", "E-Mail-Server" ein E-Mail-Konto konfiguriert sein.
ePO – Produktinformationen in der Gerätestruktur: ePO bietet für TIE anpassbare Produkteigenschaften, die relevante Messgrößen zu Integrationen von Advanced Threat Defense (ATD) und Global Threat Intelligence (GTI) beinhalten. Sie finden diese unter:
Systemstruktur,
Systemname der TIE-Server-Appliance,
Produkte,
McAfee Threat Intelligence Exchange Server. Der folgende Screenshot zeigt ein Ausgabebeispiel:
ePO – Topologieseite für Data Exchange Layer-Fabric:
Diese Seite ist ab Data Exchange Layer (DXL) 1.1 unter Menü, Konfiguration, Server-Einstellungen, DXL-Topologie verfügbar. Auf der Seite mit der DXL-Fabric-Topologie werden Informationen zu DXL-Eigenschaften, Bridges und Diensten angezeigt. Jeder DXL-Broker gibt zudem die Anzahl der von den DXL-Diensten pro Sekunde verarbeiteten Meldungen an. Der folgende Screenshot zeigt ein Ausgabebeispiel von Registrierungsinformationen für den TIE-Dienst:
ePO-Web-APIs:
Der DXL-Broker bietet ePO-Web-APIs, um die Anzahl der verbundenen Clients zu melden. ePO-Web-APIs können von beliebigen Überwachungslösungen zur kontinuierlichen Überwachung von Diensten und deren Zustand verwendet werden, um Probleme zu identifizieren. Ab DXL 2.0 sind die folgenden Remote-Überwachungsbefehle verfügbar:
- dxl.broker.queryRegisteredServices: Gibt eine Liste der registrierten DXL-Dienste zurück
- dxl.client.fabricHeath.fabricHealthCommand: Ruft Informationen zum Zustand des DXL-Brokers ab
Statusfunktion Ab TIE Server 2.0.0 wird auf der
Topologieseite für TIE-Server zu jedem Server ein allgemeiner Serverstatus angezeigt. Wählen Sie
Menü,
Konfiguration,
Server-Einstellungen, und gehen Sie zum Abschnitt für die Topologieverwaltung des TIE-Servers
. Dort können Sie den DXL-, ATD- und GTI-Verbindungsstatus jeder TIE-Server-Instanz prüfen. Außerdem sehen Sie, ob die Datenbankversionen innerhalb jedes TIE-Servers kompatibel sind. Angezeigt wird auch, ob die installierte Erweiterungsversion mit der Erweiterungsversion des Servers übereinstimmt. Für Slaves können Sie auch den Status der Datenbankreplikation prüfen.
Beispiel:
SAR-Funktion Ab TIE Server 2.0.0 wird auf der Appliance das Paket
sysstat installiert. Dies stellt den Befehl
sar zur Verfügung.
Mit dem MER-Tool werden alle sar-Protokolle in
logs/sys/sar kopiert. Mit einer lokalen Kopie des sar-Befehls oder
sadf können unter Verwendung dieser Dateien mehrere Abfragen ausgeführt werden. Zur weiteren Vereinfachung wird mit dem ksar-Tool die Datei
logs/sys/sar/ksar.txt generiert.
