Ищем проблему не в том месте
Это небольшая история из реальной практики, когда небольшая проблема, хорошо замаскированная отказоустойчивостью, превращается в головную боль.
Небольшая диспозиция
Маленький филиальчик, в нем есть своя АТС (asterisk + FreePBX) на базе десктопного железа и такой же местный терминальный сервачок с 1С, файлопомойкой и виртуальным RO контроллером домена. Интернет раздает Mikrotik. Филиальчик маленький, им этого достаточно.
Все началось с мониторинга (из-за нехватки времени и лени мониторит не все), который сообщил о перегреве одного сервера (с АТС) в филиале. Пока местные решали проблему, старичок завис и поломал немного базу MySQL.
Многое предвещало беду, но не эту…
Не беда, базу починили, все должно работать. Но местные жалуются, звонки срываются. Ладно — проблемы во FreePBX бывают, беру бэкап, разворачиваю, все Ок.
А беда на месте, местные все ещё жалуются, звонки не ходят нормально. До них звонок проходит кажется нормально, но, когда они сами звонят, или звонят друг другу, получается задержка в несколько секунд. Начинаю смотреть объемные и невразумительные логи Asterisk и FreePBX, в них углядеть проблему не удается. Вспоминаю, была проблема со STUN и ICE, которая давала похожую задержку. Отключаю все к чертям, результат нулевой.
Уныние — путь к принятию плохих решений
Впадаю в уныние, многочасовое ковыряние АТС не приводит ни к чему хорошему, уже глубокая ночь, а проблема не решается.
Оставил проблему до утра, в надежде на свежую голову. Утром было принято очередное неудачное решение: уж раз система сломалась (хотя зависон не мог быть таким уж разрушительным), пытаюсь починить систему через переустановку всех пакетов. Результат чуть больше нуля, сократилась задержка (несущественно, но уже успех).
Принимаю еще одно плохое решение: если частичный ремонт ОС (и базы данных из резервной копии) имели небольшой успех, а корень проблемы все еще не ясен, и при этом уже потрачено очень много времени на поиск причины, то решаю действовать радикально: сносим ОС и накатываем все с чистого листа (благо автоматизация процесса делает это за приемлемое время). Накатываю конфигурацию FreePBX из копии. Очередной провал. Результат нулевой!
Отчаяние — разум затмевается, решения становятся еще хуже
Впадаю в отчаяние. Начинают приходить совсем дурные мысли, думаю: может конфа в бэкапе кривая (было у меня так после ряда обновлений, что после них не работало, и найти причину мне так и не удалось), ничего не остаётся: надо накатить все с чистого листа руками. Какой позор! Результат строго нулевой, да еще потрачена уйма времени!
Принятие — путь к осознанию
В отчаянных попытках понять происходящие начинаю внимательно изучать логи. Замечаю закономерность. Вызов Extension происходит ровно за 5 сек, а для группы вызовов из 3-х Extension за 15! Начинаю гуглить про задержку вызова, но уже указывая конкретную задержку. И натыкаюсь на уже найденный мною ответ, люди говорят, что проблема в DNS, но я-то точно знаю, проблемы нет, все адреса разрешаются!
Очевидное — невероятное
Делать нечего, беру в руки nslookup и бинго (вот бы сразу это сделать)! Первичный DNS лежит (виртуалка с контроллером), а я и не заметил! Был бы один DNS, тут же была бы ошибка ;)
Итог
Элементарная проблема, которую мог бы увидеть мониторинг (его все же стоит настраивать для всех узлов), замаскированная отказоустойчивостю DNS, привела к потере почти двух рабочих дней на решение дурацкой ситуации. Лень всему головняк, настроить мониторинг минута — искать проблему там, где её нет — два дня.
