🥇Търсим проблема не на правилното място

Това е кратка история от реалната практика, когато малък проблем, добре скрит зад отказоустойчивостта, се превръща в истинска болка.

Кратка диспоция:

Малък офис, в който има собствена АТС (Asterisk + FreePBX) на десктоп хардуер и подобен местен терминален сървър с 1С, файлово хранилище и виртуален контролер на домейна. Интернет се раздава чрез Mikrotik. Офисът е малък, това им е достатъчно.
Всичко започна с мониторинг (поради липса на време и мързел, не се следи всичко), който съобщи за прегряването на един сървър (с АТС) в офиса. Докато местните решаваха проблема, старият започна да засяда и малко развали базата MySQL.

Много неща предвещаваха беда, но не и това…

Не е проблем, базата беше поправена, всичко трябва да работи. Но местните се оплакват, обажданията се прекъсват. Добре — понякога имат проблеми с FreePBX, взех резервно копие, възстанових, всичко е ОК.
Но бедата остава, местните отново се оплакват, обажданията не минават нормално. При тях обаждането минава нормално, но когато те сами се обаждат, или се обаждат помежду си, се получава забавяне от няколко секунди. Започвам да преглеждам обемни и неразбираеми логове на Asterisk и FreePBX, но не мога да открия проблема. Спомням си, че имаше проблем със STUN и ICE, който даваше подобно забавяне. Изключвам всичко, но резултатът е нулев.

Отчаянието е пътят към вземането на лоши решения:

Потъвам в отчаяние, многочасовото ровене в АТС не води до нищо добро, вече е късно през нощта, а проблемът не се решава.
Оставям проблема до утрото, в надежда за свежа глава. Сутринта беше взето поредното неуспешно решение: тъй като системата се е развалила (въпреки че засядането не би могло да е толкова разрушително), опитвам се да поправя системата чрез повторна инсталация на всички пакети. Резултатът е малко по-добър от нула, забавянето намаля (не значително, но все пак успех).
Приемам още едно лошо решение: ако частичният ремонт на операционната система (и базата данни от резервно копие) имаше малък успех, а коренът на проблема все още не е ясен, и при това вече е загубено много време в търсене на причината, решавам да взема радикални мерки: изтриваме операционната система и инсталираме всичко от нулата (добре, че автоматизацията прави този процес за приемливо време). Възстановявам конфигурацията на FreePBX от копие. Поредният провал. Резултатът е нулев!

Отчаянието — разумът е помрачен, решенията стават все по-лоши.

Падам в отчаяние. Започват да ми идват наум съвсем луди мисли, мисля: може би конфигурацията в бекъп файла е неправилна (имал съм такава ситуация след редица актуализации, в следствие на което нищо не работеше, и не успях да намеря причината), нищо не остава: трябва да инсталирам всичко наново ръчно. Какъв срам! Резултатът е абсолютно нулев, а и времето е похарчено без никаква полза!

Приемането — пътят към осъзнаването

В отчаяни опити да разбера какво се случва, започвам внимателно да изучавам логовете. Забелязвам закономерност. Възходът на Extension става точно след 5 сек, а за група от 3 Extension — след 15! Започвам да търся в Google за забавяне на повикването, но вече указвайки конкретното забавяне. И попадам на вече намерения от мен отговор, хората казват, че проблемът е в DNS, но аз точно знам, че проблем няма, всички адреси се разрешават!

Очевидното — не вероятното

Няма какво да правя, взимам nslookup и бинго (да бях го направил веднага)! Първичният DNS е паднал (виртуалка с контролер), а аз не забелязах! Ако имаше само един DNS, щеше да има грешка веднага 😉

Резюме

Елементарен проблем, който мониторингът е можел да види (който трябва да бъде настроен за всички възли), прикрит от отказоустойчивостта на DNS, доведе до загуба на почти два работни дни в решаване на глупава ситуация. Ленивостта е всеобща болка, настройката на мониторинг отнема минута — търсенето на проблем там, където го няма — два дни.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.