🥇Leder efter problemet det forkerte sted

Dette er en lille historie fra virkelig praksis, hvor et lille problem, godt camoufleret af høj tilgængelighed, bliver en hovedpine.

En lille disposition:

En lille filial med sin egen Asterisk-baserede telefoncentral (asterisk + FreePBX) på desktop-hardware og en lokal terminalserver med 1C, en filopbevaring og en virtuel RO domænecontroller. Internetforbindelsen leveres af Mikrotik. Filialen er lille, og det er tilstrækkeligt for dem.
Det hele begyndte med overvågning (på grund af mangel på tid og dovenskab overvåges ikke alt), som gav besked om overophedning af en server (telefoncentralen) i filialen. Mens de lokale forsøgte at løse problemet, frøs den gamle enhed, og skadede en smule MySQL-databasen.

Meget tegnede til problemer, men ikke dette…

Ikke noget problem, databasen blev repareret, og alt burde fungere. Men de lokale klager, opkald bliver afbrudt. Okay — der kan være problemer i FreePBX, jeg tager backup, gendanner, alt er i orden.
Men problemerne er stadig til stede, de lokale klager fortsat, opkaldene fungerer ikke normalt. Opkaldene til dem ser ud til at gå godt, men når de selv ringer, eller ringer til hinanden, er der en forsinkelse på flere sekunder. Jeg begynder at se på 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.

Fortvivlelse — vejen til at træffe dårlige beslutninger:

Jeg falder ind i fortvivlelse, mange timers rodende med telefoncentralen fører ikke til noget positivt, det er allerede dybt om natten, og problemet er stadig ikke løst.
Jeg efterlader problemet til morgen, i håbet om, at en frisk hjerne vil hjælpe. Om morgenen træffer jeg endnu en dårlig beslutning: da systemet er brudt ned (selvom nedbruddet ikke kunne være så katastrofalt), prøver jeg at reparere systemet ved at geninstallere alle pakker. Resultatet er lidt over nul, forsinkelsen er blevet kortere (ikke væsentligt, men stadig en sejr).
Jeg træffer endnu en dårlig beslutning: hvis delvis reparation af operativsystemet (og databasen fra backup) havde haft en lille succes, og årsagen til problemet stadig er uklar, og der allerede er brugt meget tid på at finde årsagen, så beslutter jeg at handle radikalt: vi sletter operativsystemet og starter forfra (heldigvis gør automatiseringen dette på rimelig tid). Jeg geninstallerer FreePBX-konfigurationen fra backupen. Endnu et fiasko. Resultatet er nul!

Fortvivlelse — sindet overskygges, beslutninger bliver endnu værre.

Jeg bliver fortvivlet. Begynder at få helt skøre tanker, jeg tænker: måske er konfigurationen i backuppet skæv (det har jeg oplevet før efter flere opdateringer, hvor det ikke fungerede, og jeg aldrig kunne finde årsagen), jeg har ikke andet valg: jeg må geninstallere alt fra bunden. Hvilket skam! Resultatet er strengt nul, og der er brugt en masse tid!

Accept — vejen til forståelse

I min fortvivlede bestræbelse på at forstå, hvad der sker, begynder jeg omhyggeligt at studere logfilerne. Jeg bemærker et mønster. Opkaldet til Extension sker præcist 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øder på 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øses!

Det åbenlyse — ikke det sandsynlige

Der er ikke andet at gøre, jeg tager nslookup i hånden og bingo (det skulle jeg have gjort med det samme)! Den primære DNS er nede (virtuel med controlleren), og jeg lagde ikke mærke til det! Havde der været én DNS, ville der straks have været en fejl 😉

Resultat

Et elementært problem, som overvågningen kunne have set (som skal konfigureres for alle noder), maskeret af DNS'ens fejltolerance, førte til tab af næsten to arbejdsdage på at løse en dum situation. Fa' det er en hovedpine at finde fejlen et sted, hvor den ikke er — to dage.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.