Это небольшая история из реальной практики, когда небольшая проблема, хорошо замаскированная отказоустойчивостью, превращается в головную боль.

Небольшая диспозиция


Маленький филиальчик, в нем есть своя АТС (asterisk + FreePBX) на базе десктопного железа и такой же местный терминальный сервачок с 1С, файлопомойкой и виртуальным RO контроллером домена. Интернет раздает Mikrotik. Филиальчик маленький, им этого достаточно.

Все началось с мониторинга (из-за нехватки времени и лени мониторит не все), который сообщил о перегреве одного сервера (с АТС) в филиале. Пока местные решали проблему, старичок завис и поломал немного базу MySQL.

Многое предвещало беду, но не эту...


Не беда, базу починили, все должно работать. Но местные жалуются, звонки срываются. Ладно — проблемы во FreePBX бывают, беру бэкап, разворачиваю, все Ок.

А беда на месте, местные все ещё жалуются, звонки не ходят нормально. До них звонок проходит кажется нормально, но, когда они сами звонят, или звонят друг другу, получается задержка в несколько секунд. Начинаю смотреть объемные и невразумительные логи Asterisk и FreePBX, в них углядеть проблему не удается. Вспоминаю, была проблема со STUN и ICE, которая давала похожую задержку. Отключаю все к чертям, результат нулевой.

Уныние — путь к принятию плохих решений


Впадаю в уныние, многочасовое ковыряние АТС не приводит ни к чему хорошему, уже глубокая ночь, а проблема не решается.

Оставил проблему до утра, в надежде на свежую голову. Утром было принято очередное неудачное решение: уж раз система сломалась (хотя зависон не мог быть таким уж разрушительным), пытаюсь починить систему через переустановку всех пакетов. Результат чуть больше нуля, сократилась задержка (несущественно, но уже успех).

Принимаю еще одно плохое решение: если частичный ремонт ОС (и базы данных из резервной копии) имели небольшой успех, а корень проблемы все еще не ясен, и при этом уже потрачено очень много времени на поиск причины, то решаю действовать радикально: сносим ОС и накатываем все с чистого листа (благо автоматизация процесса делает это за приемлемое время). Накатываю конфигурацию FreePBX из копии. Очередной провал. Результат нулевой!

Отчаяние — разум затмевается, решения становятся еще хуже


Впадаю в отчаяние. Начинают приходить совсем дурные мысли, думаю: может конфа в бэкапе кривая (было у меня так после ряда обновлений, что после них не работало, и найти причину мне так и не удалось), ничего не остаётся: надо накатить все с чистого листа руками. Какой позор! Результат строго нулевой, да еще потрачена уйма времени!

Принятие — путь к осознанию


В отчаянных попытках понять происходящие начинаю внимательно изучать логи. Замечаю закономерность. Вызов Extension происходит ровно за 5 сек, а для группы вызовов из 3-х Extension за 15! Начинаю гуглить про задержку вызова, но уже указывая конкретную задержку. И натыкаюсь на уже найденный мною ответ, люди говорят, что проблема в DNS, но я-то точно знаю, проблемы нет, все адреса разрешаются!

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


Делать нечего, беру в руки nslookup и бинго (вот бы сразу это сделать)! Первичный DNS лежит (виртуалка с контроллером), а я и не заметил! Был бы один DNS, тут же была бы ошибка ;)

Итог


Элементарная проблема, которую мог бы увидеть мониторинг (его все же стоит настраивать для всех узлов), замаскированная отказоустойчивостю DNS, привела к потере почти двух рабочих дней на решение дурацкой ситуации. Лень всему головняк, настроить мониторинг минута — искать проблему там, где её нет — два дня.

Комментарии (10)


  1. click0
    29.04.2019 23:40

    Проверка работы DNS, связность по Ipv4 и Ipv6 стабильных узлов и обязательно свободное место — это в первую очередь.
    Только потом можно подходить глубже к пробремам.


    1. MagicGTS Автор
      30.04.2019 00:03

      Кто-же спорит. Однако с правильного курса сбили другие обстоятельства проблемы. И в момент попытки понять, что не так, как-то не замечаешь очевидного.


    1. tchspprt
      30.04.2019 01:02

      А в критической ситуации корректный алгоритм траблшутинга сбивается. Нет, если Вы — хладнокровный терминатор — то не сбивается, конечно. Но у простых смертных вроде меня получается как у ТС.
      Прочитал содержимое статьи — такое чувство сложилось… дежавю.


  1. inkvizitor68sl
    29.04.2019 23:50

    $ man resolv.conf | grep -A3 timeout:n
    timeout:n
    Sets the amount of time the resolver will wait for a response from a remote name server before retrying the query via a
    different name server. Measured in seconds, the default is RES_TIMEOUT (currently 5, see <resolv.h>). The value for
    this option is silently capped to 30.

    В общем-то да, случалось =)


  1. Punyaan
    30.04.2019 14:38

    Слышал про такое. Сам не видел. Кто рассказывал — говорил что система телефонии должна быть независима от dns(мол, если dns отвалится — то вы долго будете ломать голову почему все работает через одно место, но работает). Единственное что, все это говорилось при обсуждении Cisco UCM.


    1. MagicGTS Автор
      30.04.2019 14:41

      Тут прикол в том, что все узлы указаны по IP, но кто-то все равно делает lookup на все (даже IP).
      Решением в моем случае может быть такое: настроить локальный DNS кэш (dnsmasq или unbound), тогда отвал любого из DNS не будет заметен в принципе. Особеность установки FreePBX из коробки в том, что его надо прикручивать дополнительно.


  1. Harbour
    30.04.2019 15:59

    enable=yes в /etc/asterisk/dnsmgr.conf


    1. MagicGTS Автор
      30.04.2019 16:01

      По умолчанию он включен.


      1. Harbour
        30.04.2019 16:05

        это в какой версии?

        root@Shiva:~/VoIP/asterisk-16.3.0/configs/samples$ cat dnsmgr.conf.sample
        [general]
        ;enable=yes ; enable creation of managed DNS lookups
        ; default is 'no'
        ;refreshinterval=1200 ; refresh managed DNS lookups every seconds
        ; default is 300 (5 minutes)
        root@Shiva:~/VoIP/asterisk-16.3.0/configs/samples$


        1. MagicGTS Автор
          30.04.2019 16:07

          Я использую FreePBX Distro (SNG7-PBX-64bit-1805-2, FreePBX 14, Centos Linux 7.5, Asterisk 13).