System Monitoring

OTRS implementiert eine grundlegende Schnittstelle zu System-Monitoring-Suiten.

Bemerkung

Um diese Funktion zu nutzen, ist ein Netzwerküberwachungssystem wie Nagios, Icinga2, HP OpenView oder ein ähnliches System erforderlich, das Ereignisse per E-Mail versenden kann.

Kontrollfluss für Nagios

Bei Nagios funktioniert es durch den Empfang von E-Mail-Nachrichten, die von einer Netzwerküberwachungs-Suite gesendet werden. Bei Ausfällen von Komponenten werden neue Tickets erstellt. Sobald ein Ticket geöffnet wurde, werden Nachrichten bezüglich der betroffenen Komponente an dieses Ticket angehängt. Wenn sich die Komponente wieder erholt, kann der Ticket-Status geändert oder das Ticket geschlossen werden. Wenn ein offenes Ticket für eine bestimmte Host- und Service-Kombination existiert, werden alle Nachrichten, die diese bestimmte Kombination betreffen, an dieses Ticket angehängt, bis es geschlossen wird.

Der folgende Kontrollfluss veranschaulicht, wie Mails von diesem Modul behandelt werden und in welchen Fällen sie welche Aktion auslösen. So ziemlich alle Prüfungen sind mit den regulären Ausdrücken konfigurierbar, die durch die unten aufgeführten Parameter gegeben sind.

  • E-Mail stimmt mit FromAddress überein?

    • NEIN → Mit der regulären E-Mail-Verarbeitung fortfahren

    • JA → Gibt es in OTRS bereits ein Ticket mit passender Kombination von Host und Service?

      • NEIN → Stimmt State: mit NewTicketRegExp überein?

        • NEIN → Bearbeitung dieser E-Mail beenden (stiller Abwurf)

        • JA → Neues Ticket erstellen, Host und Service erfassen, Mail anhängen

      • JA → E-Mail an Ticket anhängen. Passt State: zu CloseTicketRegExp?

        • NEIN → Mit der regulären E-Mail-Verarbeitung fortfahren

        • JA → Ticket-Typ ändern, wie in CloseActionState konfiguriert

Abgesehen von ein paar zusätzlichen Prüfungen behandelt das Systemüberwachungsmodul eingehende E-Mails auf diese Weise. Durch Änderung der regulären Ausdrücke sollte es möglich sein, es an verschiedene Überwachungssysteme anzupassen.

Icinga2-Bestätigung

Für Icinga2 funktioniert es, indem ein Host und ein Service in den dynamischen Feldern des Tickets angegeben werden. Diese Kombination aus Host und Service wird verwendet, nachdem eine Ticketsperre gesetzt wurde, um eine HTTP-Anfrage zu erzeugen, die an den konfigurierten Icinga2-Host gesendet wird. In Icinga2 wird diese Anfrage verwendet, um neue Vorfälle zu erstellen oder zu bestätigen.

Ein neues Ticket wird mit Werten in den angegebenen dynamischen Feldern erstellt, die als Kombination von Host und Service für die Kommunikation zum Icinga2-Host benötigt werden. Nachdem dieses neu erstellte Ticket für einen Agenten gesperrt ist, wird eine HTTP-Anforderung an den konfigurierten Icinga2-Host gesendet. Im Icinga2-Host wird eine neue Bestätigung erstellt oder eine bestehende bestätigt.

Systemkonfiguration für das System-Monitoring

Es gibt zwei nützliche Funktionen, die zur Automatisierung des Arbeitsablaufs auf der Grundlage der Meldungen aus den System-Monitoring-Suiten verwendet werden können. Beide Funktionen sind jedoch standardmäßig deaktiviert, können aber in der Systemkonfiguration aktiviert werden.

Bemerkung

Die Funktion OTRS-Konfigurationsmanagement ist erforderlich, um diese Funktionen zu nutzen.

Vorfallstatus festlegen

Es ist möglich, den Ereignisstatus eines Configuration Items automatisch zu setzen, wenn eine Systemüberwachungs-E-Mail eintrifft.

Die Einstellung SystemMonitoring::SetIncidentState muss aktiviert sein, um diese Funktion zu nutzen.

Siehe auch

Externe Programme, die von OTRS ausgeführt werden sollen, sind aus Sicherheitsgründen standardmäßig blockiert. Sie müssen das Programm zur Liste der erlaubten Programme hinzufügen, wie im Kapitel Sichere Ausführung des Programms zulassen beschrieben.

Nach oben scrollen