{"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\/da\/blog\/administrirovanie\/ishhem-problemu-ne-v-tom-meste","title":{"rendered":"Vi leder ikke efter problemet det forkerte sted.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dette er en lille historie fra virkelig praksis, hvor et lille problem, godt camoufleret af h\u00f8j tilg\u00e6ngelighed, bliver en hovedpine.
\n<\/a><\/noindex><\/p>\n

En lille disposition:<\/h2>\n

\nEn lille filial med sin egen Asterisk-baserede telefoncentral (asterisk + FreePBX) p\u00e5 desktop-hardware og en lokal terminalserver med 1C, en filopbevaring og en virtuel RO dom\u00e6necontroller. Internetforbindelsen leveres af Mikrotik. Filialen er lille, og det er tilstr\u00e6kkeligt for dem.
\nDet hele begyndte med overv\u00e5gning (p\u00e5 grund af mangel p\u00e5 tid og dovenskab overv\u00e5ges ikke alt), som gav besked om overophedning af en server<\/a> (telefoncentralen) i filialen. Mens de lokale fors\u00f8gte at l\u00f8se problemet, fr\u00f8s den gamle enhed, og skadede en smule MySQL-databasen.<\/p>\n

Mange tegn tydede p\u00e5, at der var problemer p\u00e5 vej, men ikke dette\u2026<\/h3>\n

\nIkke noget problem, databasen blev repareret, og alt burde fungere. Men de lokale klager, opkald bliver afbrudt. Okay \u2014 der kan v\u00e6re problemer i FreePBX, jeg tager backup, gendanner, alt er i orden.
\nMen problemerne er stadig til stede, de lokale klager fortsat, opkaldene fungerer ikke normalt. Opkaldene til dem ser ud til at g\u00e5 godt, men n\u00e5r de selv ringer, eller ringer til hinanden, er der en forsinkelse p\u00e5 flere sekunder. Jeg begynder at se p\u00e5 de omfattende og urimelige logs fra Asterisk og FreePBX, jeg kan ikke finde problemet der. Jeg husker, der var et problem med STUN og ICE, der gav en lignende forsinkelse. Jeg deaktiverer det hele, resultatet er nul.<\/p>\n

Fortvivlelse \u2014 vejen til at tr\u00e6ffe d\u00e5rlige beslutninger:<\/h3>\n

\nJeg falder ind i fortvivlelse, mange timers rodende med telefoncentralen f\u00f8rer ikke til noget positivt, det er allerede dybt om natten, og problemet er stadig ikke l\u00f8st.
\nJeg efterlader problemet til morgen, i h\u00e5bet om, at en frisk hjerne vil hj\u00e6lpe. Om morgenen tr\u00e6ffer jeg endnu en d\u00e5rlig beslutning: da systemet er brudt ned (selvom nedbruddet ikke kunne v\u00e6re s\u00e5 katastrofalt), pr\u00f8ver jeg at reparere systemet ved at geninstallere alle pakker. Resultatet er lidt over nul, forsinkelsen er blevet kortere (ikke v\u00e6sentligt, men stadig en sejr).
\nJeg tr\u00e6ffer endnu en d\u00e5rlig beslutning: hvis delvis reparation af operativsystemet (og databasen fra backup) havde haft en lille succes, og \u00e5rsagen til problemet stadig er uklar, og der allerede er brugt meget tid p\u00e5 at finde \u00e5rsagen, s\u00e5 beslutter jeg at handle radikalt: vi sletter operativsystemet og starter forfra (heldigvis g\u00f8r automatiseringen dette p\u00e5 rimelig tid). Jeg geninstallerer FreePBX-konfigurationen fra backupen. Endnu et fiasko. Resultatet er nul!<\/p>\n

Fortvivlelse \u2014 sindet overskygges, beslutninger bliver endnu v\u00e6rre.<\/h3>\n

\nJeg bliver fortvivlet. Begynder at f\u00e5 helt sk\u00f8re tanker, jeg t\u00e6nker: m\u00e5ske er konfigurationen i backuppet sk\u00e6v (det har jeg oplevet f\u00f8r efter flere opdateringer, hvor det ikke fungerede, og jeg aldrig kunne finde \u00e5rsagen), jeg har ikke andet valg: jeg m\u00e5 geninstallere alt fra bunden. Hvilket skam! Resultatet er strengt nul, og der er brugt en masse tid!<\/p>\n

Accept \u2014 vejen til forst\u00e5else<\/h3>\n

\nI min fortvivlede bestr\u00e6belse p\u00e5 at forst\u00e5, hvad der sker, begynder jeg omhyggeligt at studere logfilerne. Jeg bem\u00e6rker et m\u00f8nster. Opkaldet til Extension sker pr\u00e6cist efter 5 sekunder, mens opkaldet til en gruppe med 3 Extension tager 15! Jeg begynder at google om forsinkelse af opkald, men angiver nu den specifikke forsinkelse. Og jeg st\u00f8der p\u00e5 et svar, jeg allerede har fundet tidligere, folk siger, at problemet ligger i DNS, men jeg ved jo med sikkerhed, at der ikke er noget problem, alle adresser opl\u00f8ses!<\/p>\n

Det \u00e5benlyse \u2014 ikke det sandsynlige<\/h3>\n

\nDer er ikke andet at g\u00f8re, jeg tager nslookup i h\u00e5nden og bingo (det skulle jeg have gjort med det samme)! Den prim\u00e6re DNS er nede (virtuel med controlleren), og jeg lagde ikke m\u00e6rke til det! Havde der v\u00e6ret \u00e9n DNS, ville der straks have v\u00e6ret en fejl \ud83d\ude09<\/p>\n

Resultat<\/h3>\n

\nEt element\u00e6rt problem, som overv\u00e5gningen kunne have set (som skal konfigureres for alle noder), maskeret af DNS'ens fejltolerance, f\u00f8rte til tab af n\u00e6sten to arbejdsdage p\u00e5 at l\u00f8se en dum situation. Fa' det er en hovedpine at finde fejlen et sted, hvor den ikke er \u2014 to dage.<\/p>\n

Kun registrerede brugere kan deltage i unders\u00f8gelsen. Log ind<\/a><\/noindex>, please.<\/p>\n

Har du oplevet noget lignende?<\/h2>\n