🥇Wir suchen das Problem nicht dort, wo es liegt

Das ist eine kleine Geschichte aus der realen Praxis, als ein kleines Problem, gut maskiert durch Redundanz, zu einem großen Kopfschmerz wurde.

Eine kleine Anordnung:

Eine kleine Filiale mit einer eigenen Telefonanlage (Asterisk + FreePBX) auf Desktop-Hardware und einem lokalen Terminalserver mit 1C, einer Dateischleuder und einem virtuellen RO-Domaincontroller. Das Internet wird über Mikrotik bereitgestellt. Die Filiale ist klein, das ist ausreichend.
Alles begann mit einer Überwachung (aufgrund von Zeitmangel und Faulheit wird nicht alles überwacht), die über eine Überhitzung eines Server (mit der Telefonanlage) in der Filiale berichtete. Während die lokalen Mitarbeiter das Problem lösten, hing die alte Hardware und beschädigte ein wenig die MySQL-Datenbank.

Vieles deutete auf ein Unglück hin, aber nicht auf dieses…

Keine Sorge, die Datenbank wurde repariert, alles sollte funktionieren. Aber die lokalen Mitarbeiter beschweren sich, die Anrufe brechen ab. Gut — es gibt Probleme mit FreePBX, ich mache ein Backup, stelle es wieder her, alles in Ordnung.
Doch das Unglück bleibt, die lokalen Mitarbeiter beschweren sich weiterhin, die Anrufe laufen nicht richtig. Bei ihnen scheint der Anruf normal durchzukommen, aber wenn sie anrufen oder sich gegenseitig anrufen, gibt es eine Verzögerung von mehreren Sekunden. Ich beginne, die umfangreichen und unzureichenden Protokolle von Asterisk und FreePBX anzusehen, kann das Problem dort aber nicht erkennen. Ich erinnere mich, dass es ein Problem mit STUN und ICE gab, das eine ähnliche Verzögerung verursachte. Ich schalte alles ab, aber das Ergebnis ist null.

Der Pessimismus — der Weg zu schlechten Entscheidungen:

Ich verfalle in Pessimismus, stundenlanges Herumdoktern an der Telefonanlage führt zu nichts Gutem, es ist schon tief in der Nacht und das Problem ist nicht gelöst.
Ich lasse das Problem bis zum Morgen ruhen, in der Hoffnung auf einen klaren Kopf. Am Morgen wurde eine weitere missratene Entscheidung getroffen: Da das System kaputt gegangen ist (obwohl der Ausfall nicht so katastrophal gewesen sein kann), versuche ich, das System durch die Neuinstallation aller Pakete zu reparieren. Das Ergebnis ist etwas besser als null, die Verzögerung hat sich verkürzt (nicht erheblich, aber ein Erfolg).
Ich treffe eine weitere schlechte Entscheidung: Wenn die teilweise Reparatur des Betriebssystems (und der Datenbank aus dem Backup) einen kleinen Erfolg hatte, die Ursache des Problems aber immer noch unklar ist und bereits sehr viel Zeit mit der Fehlersuche verstrichen ist, beschließe ich, radikal zu handeln: Wir löschen das Betriebssystem und installieren alles von Grund auf neu (zum Glück macht die Automatisierung des Prozesses das in angemessener Zeit). Ich spiele die Konfiguration von FreePBX aus einer Kopie zurück. Ein weiterer Misserfolg. Das Ergebnis ist null!

Verzweiflung — der Verstand wird trüb, die Entscheidungen werden noch schlechter.

Ich verfalle in Verzweiflung. Es kommen mir ganz verrückte Gedanken, ich denke: Vielleicht ist die Konferenz im Backup fehlerhaft (so ging es mir nach einigen Updates, dass danach nichts funktionierte und ich die Ursache nie fand), bleibt nichts anderes übrig: Ich muss alles von Hand neu aufsetzen. Was für eine Schande! Das Ergebnis ist genau null und ich habe auch noch eine Menge Zeit verloren!

Akzeptanz ist der Weg zum Verständnis

In verzweifelten Versuchen, das Geschehen zu verstehen, beginne ich, die Logs genau zu studieren. Ich erkenne ein Muster. Der Aufruf der Extension erfolgt genau nach 5 Sekunden, während der Aufruf einer Gruppe von 3 Extensions 15 Sekunden dauert! Ich beginne mit der Googlesuche zur Verzögerung des Aufrufs, aber bereits mit der Angabe einer konkreten Verzögerung. Und ich stoße auf die bereits von mir gefundene Antwort, die Leute sagen, das Problem liege beim DNS, aber ich weiß ganz genau, dass es kein Problem gibt, alle Adressen werden aufgelöst!

Das Offensichtliche ist nicht das Wahrscheinliche

Es bleibt mir nichts anderes übrig, als nslookup in die Hand zu nehmen, und Bingo (hätte ich das nur sofort gemacht)! Der primäre DNS ist down (virtuelle Maschine mit dem Controller), und ich habe es nicht einmal bemerkt! Hätte ich nur einen DNS, wäre sofort ein Fehler aufgetreten 😉

Fazit

Ein elementares Problem, das durch das Monitoring (das für alle Knoten eingerichtet werden sollte) hätte erkannt werden können, wurde durch die Ausfallsicherheit des DNS maskiert und führte zu fast zwei Arbeitstagen, die für die Lösung einer dummen Situation verloren gingen. Faulheit ist eine große Herausforderung, das Monitoring in einer Minute einzurichten – das Problem dort zu suchen, wo es nicht ist – zwei Tage.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.