🥇Zoeken naar het probleem niet op de juiste plek

Dit is een klein verhaal uit de praktijk, waarbij een klein probleem, goed verstopt achter redundantie, uitgroeit tot een hoofdpijn.

Korte inleiding:

Een kleine vestiging met een eigen PBX (Asterisk + FreePBX) op basis van desktophardware, en dezelfde lokale terminalserver met 1C, een bestandsopslag en een virtuele RO-domeincontroller. Internet wordt gedeeld via Mikrotik. De vestiging is klein, dat is genoeg voor hen.
Alles begon met monitoring (vanwege tijdgebrek en luiheid wordt niet alles gemonitord), die melding maakte van oververhitting van een de server (met PBX) in de vestiging. Terwijl de lokale medewerkers het probleem probeerden op te lossen, bevroor de oudere server en beschadigde een beetje de MySQL-database.

Veel wees op problemen, maar niet deze...

Geen probleem, de database werd gerepareerd, alles zou moeten werken. Maar de lokale medewerkers klagen over verbroken gesprekken. In orde — problemen met FreePBX komen voor, ik neem een back-up, zet het terug, alles lijkt goed.
Maar het probleem blijft, de lokale medewerkers klagen nog steeds, gesprekken verlopen niet goed. Een inkomend gesprek klinkt normaal, maar wanneer zij zelf bellen of elkaar bellen, is er een vertraging van enkele seconden. Ik begin de omvangrijke en onduidelijke logs van Asterisk en FreePBX te bekijken, maar ik kan het probleem daar niet vinden. Ik herinner me een probleem met STUN en ICE, dat een soortgelijke vertraging gaf. Ik schakel alles uit, maar het resultaat is nul.

Somberheid — de weg naar het nemen van slechte beslissingen:

Ik raak ontmoedigd, urenlang prutsen aan de PBX leidt tot niets goeds, het is al diep in de nacht en het probleem is nog niet opgelost.
Ik laat het probleem tot de ochtend liggen, in de hoop dat een frisse geest helpt. In de ochtend neem ik opnieuw een verkeerde beslissing: aangezien het systeem is beschadigd (hoewel de vastloper niet zo destructief kan zijn geweest), probeer ik het systeem te herstellen door alle pakketten opnieuw te installeren. Het resultaat is iets meer dan nul, de vertraging is verkort (niet significant, maar toch een succes).
Ik neem nog een slechte beslissing: als gedeeltelijke reparatie van het besturingssysteem (en de database uit de back-up) een klein succes had, en de wortel van het probleem nog steeds onduidelijk is, en bovendien al veel tijd is besteed aan het zoeken naar de oorzaak, besluit ik radicaal te handelen: we verwijderen het besturingssysteem en installeren alles opnieuw vanaf nul (gelukkig maakt automatisering dit in een redelijke tijd mogelijk). Ik herstel de configuratie van FreePBX uit een back-up. Weer een mislukking. Het resultaat is nul!

Wanhoop — het verstand wordt vertroebeld, de beslissingen worden nog slechter.

Ik raak in wanhoop. Er beginnen heel rare gedachten op te komen, ik denk: misschien is de backup in de war (ik heb dit meegemaakt na verschillende updates, waardoor het niet werkte, en ik kon de oorzaak niet vinden), er blijft niets anders over: ik moet alles met de hand opnieuw installeren. Wat een schande! Het resultaat is absoluut nul, en ik heb ook nog eens een hoop tijd verspild!

Acceptatie - de weg naar bewustwording

In wanhopige pogingen om te begrijpen wat er aan de hand is, begin ik de logs zorgvuldig te bestuderen. Ik merk een patroon op. De aanroep van de Extension gebeurt precies na 5 seconden, terwijl voor een groep aanroepen van 3 Extensions het 15 seconden kost! Ik begin te googelen over oproepvertraging, maar geef al een specifieke vertraging op. En ik stuit op een antwoord dat ik eerder had gevonden, mensen zeggen dat het probleem in DNS zit, maar ik weet zeker dat dat niet het geval is, alle adressen worden correct opgelost!

Wat voor de hand ligt, is niet waarschijnlijk

Ik heb niets anders te doen, ik pak nslookup en bingo (had dit meteen moeten doen)! De primaire DNS is down (een virtuele machine met de controller), en ik heb het niet opgemerkt! Als er maar één DNS was, zou er meteen een fout zijn geweest 😉

Conclusie

Een elementair probleem, dat ontdekt had kunnen worden door monitoring (die voor alle knooppunten ingesteld moet worden), verborgen door de failover van DNS, heeft geleid tot het verlies van bijna twee werkdagen om een belachelijke situatie op te lossen. Luiheid is altijd een hoofdpijn, monitoring instellen duurt een minuut - het probleem zoeken waar het niet is kost twee dagen.

Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. Log in, alstublieft.