{"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 richtigen Stelle.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dies ist eine kleine Geschichte aus der Praxis, in der ein kleines Problem, gut getarnt durch Redundanz, zu einer echten Herausforderung wird.
\n<\/a><\/noindex><\/p>\n

Ein kurzer \u00dcberblick:<\/h2>\n

\nEine kleine Filiale, die ein eigenes PBX-System (Asterisk + FreePBX) auf Desktop-Hardware sowie einen lokalen Terminalserver mit 1C, einem Fileserver und einem virtuellen Domain-Controller betreibt. Das Internet wird \u00fcber Mikrotik bereitgestellt. Die Filiale ist klein, das reicht aus.
\nAlles begann mit einer \u00dcberwachung (wegen Zeitmangels und Faulheit wird nicht alles \u00fcberwacht), die \u00fcber eine \u00dcberhitzung eines Server<\/a> (PBX) in der Filiale informierte. W\u00e4hrend die Mitarbeiter vor Ort das Problem l\u00f6sten, st\u00fcrzte der alte Server ab und besch\u00e4digte die MySQL-Datenbank ein wenig.<\/p>\n

Vieles deutete auf Probleme hin, aber nicht auf dieses\u2026<\/h3>\n

\nKeine Sorge, die Datenbank wurde repariert, alles sollte funktionieren. Aber die Mitarbeiter beklagten sich, Anrufe brechen ab. Na gut \u2013 Probleme in FreePBX gibt es manchmal, ich mache ein Backup, stelle es wieder her, alles in Ordnung.
\nEs gibt Probleme vor Ort, die Anrufer klagen immer noch, dass die Anrufe nicht richtig durchkommen. Der Anruf bei ihnen scheint in Ordnung zu sein, aber wenn sie selbst anrufen oder sich gegenseitig anrufen, gibt es eine Verz\u00f6gerung von mehreren Sekunden. Ich beginne, die umfangreichen und unklaren Protokolle von Asterisk und FreePBX zu durchsuchen, aber ich kann das Problem nicht finden. Ich erinnere mich, dass es ein Problem mit STUN und ICE gab, das eine \u00e4hnliche Verz\u00f6gerung verursachte. Ich schalte alles ab und das Ergebnis bleibt gleich null.<\/p>\n

Tr\u00fcbsal ist der Weg zu schlechten Entscheidungen:<\/h3>\n

\nIch verfalle in Tr\u00fcbsal; stundenlanges Herumprobieren mit der Telefonanlage f\u00fchrt zu nichts Gutem. Es ist bereits sp\u00e4t in der Nacht, und das Problem bleibt ungel\u00f6st.
\nIch lasse das Problem bis zum Morgen ruhen in der Hoffnung auf einen klaren Kopf. Am Morgen wurde eine weitere missratene Entscheidung getroffen: Nachdem das System abgest\u00fcrzt ist (obwohl der Absturz nicht katastrophal sein konnte), versuche ich, das System durch Neuinstallation aller Pakete zu reparieren. Das Ergebnis ist etwas besser als null, die Verz\u00f6gerung hat sich verringert (nicht wesentlich, aber dennoch ein Erfolg).
\nIch treffe eine weitere schlechte Entscheidung: Wenn die Teilreparatur des Betriebssystems (und der Datenbank aus dem Backup) nur begrenzt erfolgreich war und die Hauptursache weiterhin unklar bleibt, sowie bereits viel Zeit auf die Fehlersuche verwendet wurde, entscheide ich mich radikal zu handeln: Wir l\u00f6schen das Betriebssystem und installieren alles von Grund auf neu (zum Gl\u00fcck erledigt die Automatisierung diesen Prozess in einer akzeptablen Zeit). Ich spiele die Konfiguration von FreePBX aus dem Backup ein. Ein weiterer Misserfolg. Das Ergebnis ist null!<\/p>\n

Verzweiflung \u2013 der Verstand wird getr\u00fcbt, die L\u00f6sungen werden noch schlechter.<\/h3>\n

\nIch verfalle in Verzweiflung. Es kommen mir v\u00f6llig wirre Gedanken: Vielleicht ist die Konfiguration im Backup fehlerhaft (ich hatte das nach einer Reihe von Updates, nach denen es nicht funktionierte, und ich konnte die Ursache nie finden). Mir bleibt nichts anderes \u00fcbrig, als alles manuell von Grund auf neu zu machen. Welche Schande! Das Ergebnis ist absolut null, und ich habe viel Zeit verloren!<\/p>\n

Akzeptanz \u2013 der Weg zum Bewusstsein.<\/h3>\n

\nIn einem verzweifelten Versuch, das Geschehen zu ergr\u00fcnden, beginne ich, die Protokolle genau zu analysieren. Mir f\u00e4llt eine Regelm\u00e4\u00dfigkeit auf. Der Aufruf der Extension erfolgt genau nach 5 Sekunden, w\u00e4hrend der Gruppenaufruf von 3 Extensions nach 15 Sekunden erfolgt! Ich fange an, nach der Verz\u00f6gerung des Aufrufs zu googeln, wobei ich bereits die spezifische Verz\u00f6gerung angebe. Und ich sto\u00dfe auf die Antwort, die ich bereits gefunden hatte: Menschen sagen, das Problem liege an DNS, aber ich bin mir sicher, dass es kein Problem gibt, alle Adressen werden aufgel\u00f6st!<\/p>\n

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

\nEs bleibt nichts anderes \u00fcbrig, als nslookup zu nutzen, und bingo (h\u00e4tte ich das gleich machen sollen)! Der prim\u00e4re DNS ist down (VM mit dem Controller), und ich habe es nicht einmal bemerkt! H\u00e4tte es nur einen DNS gegeben, g\u00e4be es sofort einen Fehler \ud83d\ude09<\/p>\n

Zusammenfassung<\/h3>\n

\nEin elementares Problem, das das Monitoring h\u00e4tte erkennen k\u00f6nnen (das f\u00fcr alle Knoten konfiguriert werden muss), maskiert durch die Ausfallsicherheit von DNS, hat dazu gef\u00fchrt, dass ich fast zwei Arbeitstage mit der L\u00f6sung einer dummen Situation verloren habe. Faulheit verursacht Kopfschmerzen; ein Monitoring einzustellen dauert eine Minute, das Problem dort zu suchen, wo es keines gibt \u2013 zwei Tage.<\/p>\n

Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte melden Sie sich an.<\/a><\/noindex>Sind Sie an Contour interessiert?<\/p>\n

Hatte jemand von Ihnen eine \u00e4hnliche Erfahrung?<\/h2>\n