🥇Vi letar efter problemet på fel ställe

Detta är en liten historia från verklig praktik, där ett litet problem, väl dolt av redundans, har blivit en huvudvärk.

Liten disposition:

En liten filial, med sin egen telefonväxel (Asterisk + FreePBX) baserad på desktop-hårdvara och en likadan lokal terminalserver med 1C, en filserver och en virtuell RO domänkontroller. Internet delas via Mikrotik. Filialen är liten, vilket räcker för dem.
Det hela började med övervakning (på grund av tidsbrist och lathet övervakar man inte allt), som rapporterade överhettning av en servern (med telefonväxeln) i filialen. Medan de lokala försökte lösa problemet, frös den gamla servern och skadade lite av MySQL-databasen.

Mycket tycktes luta åt en olycka, men inte den här…

Inga problem, databasen reparerades, allt borde fungera. Men de lokala klagar, samtal bryts. Okej — problem uppstår ibland med FreePBX, jag tar en backup, återställer, allt ser okej ut.
Men olyckan finns fortfarande, de lokala klagar fortfarande, samtal fungerar inte som de ska. När de får ett samtal verkar allt okej, men när de själva ringer, eller ringer till varandra, är det flera sekunders fördröjning. Jag börjar titta på de omfattande och oklara loggarna från Asterisk och FreePBX, men jag kan inte se problemet. Jag kommer ihåg att det fanns ett problem med STUN och ICE, som gav liknande fördröjning. Jag stänger av allt för gott, resultatet är noll.

Förtvivlan — vägen till dåliga beslut:

Jag faller ner i förtvivlan, timtal av grävande i telefonväxeln leder inte till något bra, natten är sen och problemet är olöst.
Jag lät problemet vara till morgonen, i hopp om att vara mer klar i huvudet. På morgonen togs ett ytterligare misslyckat beslut: eftersom systemet har gått sönder (även om frysen inte kan ha varit så förödande) försöker jag reparera systemet genom att installera om alla paket. Resultatet är något mer än noll, fördröjningen har minskat (inte betydligt, men ändå en framgång).
Jag tar ytterligare ett dåligt beslut: om delvis reparation av OS (och databasen från backup) har haft en liten framgång, och roten till problemet fortfarande är oklar, och dessutom har jag redan lagt ner mycket tid på att leta efter orsaken, så beslutar jag att agera radikalt: vi tar bort OS och installerar allt på nytt (lyckligtvis gör automatiseringen av processen detta på rimlig tid). Jag återställer FreePBX-konfigurationen från en kopia. Ännu ett misslyckande. Resultatet är noll!

Förtvivlan — förnuftet förmörkas, besluten blir ännu sämre.

Jag blir förtvivlad. Helt galna tankar börjar dyka upp, jag tänker: kanske är konferensen i backupen trasig (det hände mig efter flera uppdateringar som gjorde att den inte fungerade, och jag kunde aldrig hitta orsaken), det finns inget annat att göra: jag måste börja om från början för hand. Vilken skam! Resultatet är helt noll, och jag har dessutom slösat bort massor av tid!

Acceptans – vägen till insikt

I mina desperata försök att förstå vad som händer börjar jag noggrant studera loggarna. Jag märker ett mönster. Anropet till Extension sker exakt efter 5 sekunder, och för en gruppanrop av 3 Extension efter 15! Jag börjar googla på fördröjning av anrop, men specificerar redan en konkret fördröjning. Och jag snubblar över ett svar jag redan har hittat, folk säger att problemet ligger i DNS, men jag vet att det inte finns något problem, alla adresser löses ju!

Det uppenbara – inte det troliga

Det finns inget annat att göra, jag tar fram nslookup och bingo (varför gjorde jag inte detta direkt)! Primär DNS är nere (virtuell maskin med kontroller), och jag märkte det inte ens! Om det vore en enda DNS skulle det omedelbart ha blivit ett fel 😉

Resultat

Ett elementärt problem som övervakningen (som bör konfigureras för alla noder) kunde ha sett, maskerat av DNS:s redundans, ledde till nästan två arbetsdagar av förlust på grund av en dum situation. Att vara lat är ett huvudverk, att konfigurera övervakningen tar en minut – att leta efter problemet där det inte är – två dagar.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.