{"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\/no\/blog\/administrirovanie\/ishhem-problemu-ne-v-tom-meste","title":{"rendered":"Vi ser etter problemet ikke i det opplagte stedet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dette er en liten historie fra ekte praksis, hvor et lite problem, godt maskert av feilfrihet, blir til en hodepine.
\n<\/a><\/noindex><\/p>\n

Liten disposisjon:<\/h2>\n

\nEt lite filialkontor, med sin egen PBX (asterisk + FreePBX) basert p\u00e5 stasjon\u00e6r maskinvare, samt en lokal terminalserver med 1C, filavfall og en virtuell RO-domene kontroller. Internett distribueres gjennom Mikrotik. Filialen er liten, og dette er tilstrekkelig for dem.
\nAlt startet med overv\u00e5kning (p\u00e5 grunn av mangel p\u00e5 tid og latskap overv\u00e5kes ikke alt), som rapporterte om overoppheting av en serveren<\/a> (PBX) i filialen. Mens lokale akt\u00f8rer fors\u00f8kte \u00e5 l\u00f8se problemet, fr\u00f8s maskinen og \u00f8dela litt av MySQL-databasen.<\/p>\n

Mange varsla om ulykke, men ikke denne\u2026<\/h3>\n

\nDet er ikke noe problem, databasen ble fikset, alt skal fungere. Men lokalbefolkningen klager, samtaler blir avbrutt. Vel \u2014 det oppst\u00e5r problemer i FreePBX, jeg tar en sikkerhetskopi, og gjenoppretter, alt ser ok ut.
\nMen problemet vedvarer, lokalbefolkningen klager fortsatt, samtaler g\u00e5r ikke normalt. N\u00e5r de mottar samtaler, ser alt greit ut, men n\u00e5r de ringer hverandre, kommer det med flere sekunders forsinkelse. Jeg begynner \u00e5 se p\u00e5 de omfattende og uforst\u00e5elige loggene fra Asterisk og FreePBX, men finner ikke problemet. Jeg husker, det var et problem med STUN og ICE, som ga lignende forsinkelse. Jeg deaktiverer alt helt, resultatet er null.<\/p>\n

Fortvilelse \u2014 veien til d\u00e5rlige beslutninger:<\/h3>\n

\nJeg blir frustrert, timevis med stusslende PBX f\u00f8rer ikke til noe godt, det er allerede sent om natten, og problemet er fortsatt ikke l\u00f8st.
\nJeg lar problemet ligge til morgenen, i h\u00e5p om klarere tanker. Om morgenen ble en ny mislykket beslutning tatt: siden systemet br\u00f8t sammen (selv om fryseren ikke kunne v\u00e6re s\u00e5 \u00f8deleggende), pr\u00f8ver jeg \u00e5 fikse systemet ved \u00e5 reinstallere alle pakkene. Resultatet er litt bedre enn null, forsinkelsen reduseres (ikke betydelig, men allikevel en suksess).
\nJeg tar enda en d\u00e5rlig beslutning: hvis delvis reparasjon av OS (og databasen fra backup) hadde liten suksess, og roten til problemet fortsatt ikke er klar, og p\u00e5 toppen av dette er mye tid allerede brukt p\u00e5 \u00e5 finne \u00e5rsaken, s\u00e5 bestemmer jeg meg for \u00e5 handle radikalt: vi fjerner OS og installerer alt p\u00e5 nytt (heldigvis gj\u00f8r automatiseringen dette p\u00e5 en akseptabel tid). Jeg laster opp FreePBX-konfigurasjonen fra kopien. Nok et nederlag. Resultatet er null!<\/p>\n

Fortvilelse \u2014 sinnet blir overskyet, beslutningene blir enda d\u00e5rligere.<\/h3>\n

\nJeg blir fortvila. D\u00e5rlige tanker begynner \u00e5 komme, jeg tenker: kanskje backupen er feil (jeg opplevde slik etter flere oppdateringer, at ingenting fungerte, og jeg klarte aldri \u00e5 finne \u00e5rsaken), det er ingenting \u00e5 gj\u00f8re: jeg m\u00e5 installere alt fra bunnen av med h\u00e5nda. For en skam! Resultatet er strengt null, og en hel del tid er bortkastet!<\/p>\n

Aksept \u2014 veien til forst\u00e5else<\/h3>\n

\nI desperate fors\u00f8k p\u00e5 \u00e5 forst\u00e5 hva som skjer, begynner jeg \u00e5 studere loggene n\u00f8ye. Jeg merker et m\u00f8nster. Kall av Extension skjer n\u00f8yaktig etter 5 sekunder, mens for en gruppe av 3 Extension-kall skjer det etter 15! Jeg begynner \u00e5 google om forsinkelse p\u00e5 kall, men spesifiserer allerede den konkrete forsinkelsen. Og jeg st\u00f8ter p\u00e5 et svar jeg har funnet tidligere, folk sier at problemet ligger i DNS, men jeg vet jo sikkert at det ikke er noe problem, alle adresser oppl\u00f8ses!<\/p>\n

Det \u00e5penbare er ikke det sannsynlige<\/h3>\n

\nDet er ikke noe \u00e5 gj\u00f8re, jeg tar fram nslookup og bingo (hadde bare gjort dette med en gang)! Prim\u00e6r DNS er nede (virtuell maskin med kontroller), og jeg la ikke merke til det! Hadde det v\u00e6rt bare \u00e9n DNS, ville det v\u00e6rt en feil med en gang \ud83d\ude09<\/p>\n

Resultat<\/h3>\n

\nEt element\u00e6rt problem som overv\u00e5kingen kunne ha sett (som b\u00f8r konfigureres for alle noder), maskert av DNS-sikkerhet, f\u00f8rte til at jeg mistet nesten to arbeidsdager p\u00e5 \u00e5 l\u00f8se en dum situasjon. Latskap er en hodepine, \u00e5 sette opp overv\u00e5kingen tar ett minutt \u2014 \u00e5 lete etter problemet der det ikke finnes \u2014 to dager.<\/p>\n

Kun registrerte brukere kan delta i unders\u00f8kelsen. Logg inn<\/a><\/noindex>, v\u00e6r s\u00e5 snill.<\/p>\n

Har noe lignende skjedd med deg?<\/h2>\n