{"id":32682,"date":"2019-10-31T21:48:22","date_gmt":"2019-10-31T18:48:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ishhem-problemu-ne-v-tom-meste\/"},"modified":"2019-10-31T21:48:22","modified_gmt":"2019-10-31T18:48:22","slug":"ishhem-problemu-ne-v-tom-meste","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ishhem-problemu-ne-v-tom-meste","title":{"rendered":"Wir suchen das Problem nicht an der falschen Stelle.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Das ist eine kleine Geschichte aus der realen Praxis, als ein kleines Problem, gut maskiert durch Redundanz, zu einem gro\u00dfen Kopfschmerz wurde.
\n<\/a><\/noindex><\/p>\n

Eine kleine Anordnung:<\/h2>\n

\nEine 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 \u00fcber Mikrotik bereitgestellt. Die Filiale ist klein, das ist ausreichend.
\nAlles begann mit einer \u00dcberwachung (aufgrund von Zeitmangel und Faulheit wird nicht alles \u00fcberwacht), die \u00fcber eine \u00dcberhitzung eines Server<\/a> (mit der Telefonanlage) in der Filiale berichtete. W\u00e4hrend die lokalen Mitarbeiter das Problem l\u00f6sten, hing die alte Hardware und besch\u00e4digte ein wenig die MySQL-Datenbank.<\/p>\n

Vieles deutete auf Unheil hin, aber nicht das...<\/h3>\n

\nKeine Sorge, die Datenbank wurde repariert, alles sollte funktionieren. Aber die lokalen Mitarbeiter beschweren sich, die Anrufe brechen ab. Gut \u2014 es gibt Probleme mit FreePBX, ich mache ein Backup, stelle es wieder her, alles in Ordnung.
\nDoch das Ungl\u00fcck 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\u00f6gerung 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 \u00e4hnliche Verz\u00f6gerung verursachte. Ich schalte alles ab, aber das Ergebnis ist null.<\/p>\n

Der Pessimismus \u2014 der Weg zu schlechten Entscheidungen:<\/h3>\n

\nIch verfalle in Pessimismus, stundenlanges Herumdoktern an der Telefonanlage f\u00fchrt zu nichts Gutem, es ist schon tief in der Nacht und das Problem ist nicht gel\u00f6st.
\nIch 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\u00f6gerung hat sich verk\u00fcrzt (nicht erheblich, aber ein Erfolg).
\nIch 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\u00dfe ich, radikal zu handeln: Wir l\u00f6schen das Betriebssystem und installieren alles von Grund auf neu (zum Gl\u00fcck macht die Automatisierung des Prozesses das in angemessener Zeit). Ich spiele die Konfiguration von FreePBX aus einer Kopie zur\u00fcck. Ein weiterer Misserfolg. Das Ergebnis ist null!<\/p>\n

Verzweiflung \u2014 der Verstand wird tr\u00fcb, die Entscheidungen werden noch schlechter.<\/h3>\n

\nIch verfalle in Verzweiflung. Es kommen mir ganz verr\u00fcckte 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 \u00fcbrig: Ich muss alles von Hand neu aufsetzen. Was f\u00fcr eine Schande! Das Ergebnis ist genau null und ich habe auch noch eine Menge Zeit verloren!<\/p>\n

Akzeptanz ist der Weg zum Verst\u00e4ndnis<\/h3>\n

\nIn 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\u00e4hrend der Aufruf einer Gruppe von 3 Extensions 15 Sekunden dauert! Ich beginne mit der Googlesuche zur Verz\u00f6gerung des Aufrufs, aber bereits mit der Angabe einer konkreten Verz\u00f6gerung. Und ich sto\u00dfe auf die bereits von mir gefundene Antwort, die Leute sagen, das Problem liege beim DNS, aber ich wei\u00df ganz genau, dass es kein Problem gibt, alle Adressen werden aufgel\u00f6st!<\/p>\n

Das Offensichtliche ist nicht das Wahrscheinliche<\/h3>\n

\nEs bleibt mir nichts anderes \u00fcbrig, als nslookup in die Hand zu nehmen, und Bingo (h\u00e4tte ich das nur sofort gemacht)! Der prim\u00e4re DNS ist down (virtuelle Maschine mit dem Controller), und ich habe es nicht einmal bemerkt! H\u00e4tte ich nur einen DNS, w\u00e4re sofort ein Fehler aufgetreten \ud83d\ude09<\/p>\n

Fazit<\/h3>\n

\nEin elementares Problem, das durch das Monitoring (das f\u00fcr alle Knoten eingerichtet werden sollte) h\u00e4tte erkannt werden k\u00f6nnen, wurde durch die Ausfallsicherheit des DNS maskiert und f\u00fchrte zu fast zwei Arbeitstagen, die f\u00fcr die L\u00f6sung einer dummen Situation verloren gingen. Faulheit ist eine gro\u00dfe Herausforderung, das Monitoring in einer Minute einzurichten \u2013 das Problem dort zu suchen, wo es nicht ist \u2013 zwei Tage.<\/p>\n

Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte einloggen<\/a><\/noindex>.<\/p>\n

Hattest du so etwas schon einmal?<\/h2>\n