ISDN-Überwachung

[Berndp]

Hallo zusammen,

wir haben eine verteilte Ferrari-Umgebung welche auch an mehrerere TK-Anlagen angeschlossen ist.
Wir überwachen auch die Log-Dateien des Ferrari-Servers mit Nagios. Trotzdem gibt es Situationen, wo eine Störung besteht und der Ferrari-Server keinen Fehler protokolliert.
Gibt es so eine Art ISDN-Überwachungssoftware, mit der ich die Verfügbarkeit der ISDN-Leitung hin zum Fax-Server überwachen kann?

[Waldemar Sennert]

Hallo,

es sind zwar snmp-Funktionalitäten in Vorbereitung, dennoch dürfte es ausgesprochen schwierig bis unmöglich werden, alle denkbaren Störungen programmatisch zu erkennen. Denn selbst wenn es vorgesehen wäre, z.B. die ISDN-Schicht 1 und 2 zu überwachen, so kann dennoch eine Störung in der Schicht 3 auftreten, welche erst bei laufenden Verbindungen zum Tragen kommt. Und selbst ein regelmäßiger erfolgreicher TK-interner Selbstanruf schliesst nicht aus, dass Probleme bei externen Verbindungen auftreten.

Fazit: Der einzige Test um sicherzustellen, dass eine bestimmte Verbindung funktioniert ist, genau diese Verbindung testweise aufzubauen - und selbst dies bedeutet nicht, dass es 1 Minute später bei einem erneuten Versuch nicht dennoch zu Problemen kommen kann.

Alle denkbaren Störungen vorab programmatisch zu erkennen, dürfte daher ein nahezu unlösbares Problem sein.

[smileyman]

Hallo Waldemar,
hallo Berndp,

ja, da muss ich Waldemar insofern recht geben, dass sicherlich nicht alle Störungen automatisch erkannt oder gar behoben werden können.
Dennoch wäre eine derartige Überwachung sicherlich ganz interessant. Dies betrifft sicherlich auch nicht nur die ISDN-Protokoll-Ebene sondern eine vollständige (und daher von Ferrarie fast nicht realisierbare) End-to-End-Betrachtung: stehen die ISDN-Schichten noch? läuft der Zentralkonverter noch? können eMails eingeliefert werden? hat sich irgend eine Komponente aufgehängt?
All solche Fragen würden im Optimalfall beantwortet werden.

Dennoch wäre es schon mal ein Anfang in bestimmten Fällen den Systemadmin, beispielsweise via Mail zu benachrichtigen. - Das wäre meines Erachtens eine tolle Sache, die proaktiv Probleme vermeiden könnte.
So haben wir beispielsweise zwei vollständig getrennte Systeme mit beiderseitigem Loadbalancing (TK-Anlage sowie Mailserver) am Laufen. Fällt nun beispielsweise auf einer dieser Maschinen der Zentralkonverter aus, nimmt diese dennoch immer weiter Aufträge entgegen, kann diese jedoch nicht abarbeiten. Obwohl wir somit für eine vollständig redundante Lösung einiges an Money in die Handy genommen haben, hat man keine verlässliche Ausfallsicherung, die sich selber managt. So wäre es schon eine geniale Sache, hierüber vom System informiert zu werden, anstatt die Userbeschwerden über nur vereinzelt ankommende Faxe abarbeiten zu müssen.
Noch optimaler hingegen wäre eine dann auszulösende Aktion, z. B. Neustart des Systems, stoppen von anderen Komponenten (z. B. smtp-Komponente), etc.

Grüße
smileyman

[Waldemar Sennert]

Hallo smileyman,

du hast mich vollkommen richtig verstanden. Da diese Frage aber immer wieder mal auftaucht, aber vielleicht trotzdem noch ein paar Anmerkungen dazu.

Der eine (wie Berndp) wünscht sich eine ISDN-Überwachung, der nächste (ebenfalls durchaus verständlicherweise) des Konverters, der dritte der am Filegw angebundenen ERP-Software, der vierte des SMTP-Verkehrs zu einem externen Mailserver usw. und genau das ist das eigentliche Problem, denn viele Komponenten sind optional und können laufen (dann sollten sie möglichst überwacht werden), müssen aber niemals laufen (welches dann aber auch keinen Fehler darstellt). Darüber hinaus ist das System sehr granular verteilbar, d.h. der Messaging Server ist zwar software-seitig ein Server, kann aber hardware-seitig (zumindest in der unlimited user Variante) auf x PCs in X Standorten verteilt werden. Ausserdem muß es für Wartungszwecke möglich sein, einzelne Komponenten zu stoppen, ohne dass hierdurch andere Komponenten beeinträchtigt werden, also müssen sich die Aufträge ggf. auch stauen können, um später nachbearbeitet zu werden.

Doch was ist dann eigentlich noch ein Fehler, der einen Alarm rechtfertigt?

Was im einen System einen Fehlerzustand darstellt (z.B. mehr als 10 Aufträge stauen sich an einer Stelle), kann im nächsten System normal sein, da irgendeine Komponente zu Wartungszwecken gestoppt wurde, oder weil das für 20 User dimensionierte System einmalig im Jahr mit 8000 Werbeserienfaxen ausgelastet wird. Ist ein Gassenbesetzt in der TK nun ein Fehler, über den der Admin sofort informiert werden sollte, oder waren einfach, völlig unbedenklich, mal zufällig alle Mitarbeiter gleichzeitig am Telefon, haben alle Amtsleitungen belegt und 2 Minuten später ist wieder alles OK. Eine vollständige Überwachung (ggf. mit Fehlerbehandlungsmechanismen), so wünschenswert sie sicherlich ist, dürfte daher annähernd ein eigenes Serversystem mit nicht zu unterschätzender künstlicher Intelligenz erfordern.

Fazit: Einen Zustand zu protokollieren oder zu melden, ist die eine Sache (hierfür ist SNMP, wie beschrieben, bereits in Vorbereitung), aus diesen Informationen korrekt Fehler zu diagnostizieren und auch einen Normalzustand inkl. dessen "normalen Auffälligkeiten" als solchen zu erkennen, die wesentlich komplexere. Diesen Optimalfall zu erreichen, stelle ich mir daher als schwierig bis unmöglich vor. Aber vielleicht hat ja jemand eine gute Idee...

Gruß
W. Sennert

P.S. In überschaubaren Teilbereichen sind dergleichen Watchdogs übrigens durchaus bereits integriert und starten beispielsweise das OfficeMaster Gate neu, wenn bestimmte ISDN-Fehler-Szenarien eintreten, die Verbindung zum Server unterbrochen wird usw.