Как администрировать Asterisk и не сойти с ума

Введение 

     Во-первых, я прекрасно понимаю, как вы себя чувствуете. Я вообще привык вставать ближе к 10 часам и выхожу из своей зоны комфорта и привычек только когда веду курс у Сергея. Но это нормально, мне это даже нравится, поэтому я этим и занимаюсь.

      У всех обычно утро начинается с чашечки кофе. Наверное, все знают, что визуализация работает, и я думаю, вы сейчас чувствуете этот аромат. Айтишники, админы, сетевики, «астерискеры» в большинстве своём начинают утро именно с кофе. Несмотря на то, что я веду курсы и довольно часто общаюсь с людьми, я привык к интерактиву: есть такая привычка — если я что-то рассказываю, мне нужен фидбэк. На курсах это проще, потому что там всего восемь человек, со всеми уже познакомился, и быстрая обратная связь налажена. Если вам не трудно, тоже дайте мне понять, что вы проснулись, что кофе работает, и что аромат кофе нас всех бодрит. Это хорошо. Да, за окном дождь, пасмурно, осень, всем тяжко — мне тоже было сложно начать это утро. Кто-то вчера пиво пил, а я переделывал свой доклад и нашёл очень интересные фотографии.

Как начиналась конференция AsterConf?

     Это был 2009 год, Финский залив. Собрались ребята и провели первую конференцию по Asterisk. Не знаю, был ли кто-то из вас там — даже меня в 2009 году не было, но тем не менее компания тогда была весёлая: шашлычки, пиво и прочее. Именно столько ребят было в 2009-м. После этого наступил какой-то перерыв, и в 2014 году, уже непосредственно с моим участием, провели следующую конференцию — в городе Дубна. Это был наш первый опыт, очень сложный. Мы даже не представляли себе тогда, как это всё организовывать. Кстати, на фотографиях можно увидеть знакомые лица: и Игоря Кончаровского, и Сергея — всех наших, хорошо известных. Тогда все тоже отдыхали. Конференция 2014 года запомнилась, наверное, больше всего нашим любимым автобусом, который застрял и завалился на бок. Но приехало МЧС, спасло нас, и мы продолжили отдых в 2014-м. Нас тогда было побольше. Так всё и начиналось.

     Честно говоря, я думаю, что на каждой конференции было бы здорово попросить Сергея Грушко добавлять фотографии из всех предыдущих мероприятий. Сергей их уже много лет подряд создаёт, и это очень нелёгкое дело, причём финансового плюса обычно не бывает. Я сам помню, как мы проводили AsterConf: это сложно — понять потребность «астерискеров», айтишников, админов, подстроиться под рынок, ведь иногда что-то случается, и все улетели… В общем, это надо уметь. Поэтому, честно скажу, давайте поблагодарим не только Сергея Грушко, но и всю команду Voxlink за то, что они до сих пор каждый год делают для нас такой классный ивент. Это большая работа, и она очень непростая. Спасибо вам всем!Кстати, Игорь зашёл. Хочешь, покажу? Смотри, какой ты красавчик на фото — наверняка рассказывал тогда про новые фичи Asterisk. А если взглянуть на эти фотографии и на зал сейчас, то можно заметить: и Asterisk, и «астерискеры» немного «заплыли жирком». Серьёзно, посмотрите: у меня пиджак не застёгивается, хотя полгода назад всё было отлично. Не знаю, что случилось. Asterisk тоже «потолстел»: появились новые модули, новые функции — WebRTC и прочие вкусные вещи, новые интеграции. Это классно! От чего-то старого мы избавляемся, и это хорошо. Про это Игорь Гончаровский каждый год рассказывает, когда открывает конференцию: «Вот это ушло, а вот это пришло». Спасибо ему за это!

     «Астерискеры» тоже растут не только вширь, но и в профессиональном плане. Мы набрались опыта: можем строить большие системы, распознавать голос, подключать клиентов из любой точки, как угодно, через VPN или без него. Это круто, и всё шире используется в компаниях, которые берут Asterisk в качестве телефонной станции или виртуальной АТС. Причём это уже не только небольшие фирмы, но и крупные предприятия. В России развитие Asterisk идёт очень бурно, хотя в остальном мире ситуация может отличаться. Но, опять же, всё зависит от экономической ситуации в той или иной стране.

     Ладно, давайте потихоньку перейдём к докладу. Кстати, Сергей Грушко, хочу предложить тебе каждое утро второго дня конференции начинать с просмотра фотографий предыдущих мероприятий. Это были бы полчаса приятных воспоминаний, и сделать это довольно легко. Тем более в конференции участвует вся твоя команда, а на сцене в основном только ты. Ты можешь пригласить кого-то из коллег и дать ему слово, чтобы рассказал, как это было раньше.

Мой доклад

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

     Первый вопрос: «Как выбрать сервер? Какой сервак нужен? Взять ли старый десктоп из кладовки? Купить ли серьёзное железо, которое стоит полмиллиона? А может быть VPS, или вообще взять роутер, Raspberry, и поставить туда Asterisk?»

     Всё зависит от того, зачем он вам нужен, какую задачу решает и насколько надёжно всё это должно работать. Я искал информацию о том, сколько ресурсов — процессора и памяти — реально нужно, и в интернете её мало, да и то устаревшая. Поэтому решил разделить подход на три типа:

1. Простой Asterisk без особых сложных диалпланов. Если только вызовы, без записи, локальных очередей и без сложной логики, он прекрасно живёт на маленьких «железках».
2. Asterisk посерьёзнее — уже с записью, локальными очередями, более сложными диалпланами. Тут нужно хотя бы 4 ГБ оперативки, побольше места, процессор посолиднее.
3. Asterisk «плюс-плюс-плюс» — это большие высоконагруженные системы, где используется AMI, ARI, распознавание голоса, полная запись всех звонков и прочее. Нужно понимать, что это требует совсем других ресурсов.

     Нельзя просто прийти и сказать: «Какой сервер мне купить под Asterisk?» Я не знаю, какие вы будете включать функции, какие приложения. Вы должны сами это посчитать, посмотреть на нагрузку и сделать тесты. Есть готовые инструменты для нагрузочного тестирования, их надо использовать перед вводом системы в эксплуатацию.

     В качестве мини-отметок (лайфхаков) для себя при выборе железа:

• Систему ставим на SSD (они уже не такие дорогие).
• Запись и логи выносим на отдельный диск, в идеале даже на HDD, если надо.
• Параметр cache_record_files в Asterisk, который умеет кэшировать записи в памяти и только после завершения вызова сбрасывать их на диск, — классная вещь.
• AGI очень удобна, но не рекомендую использовать локально на том же сервере, где крутится Asterisk. Лучше FastAGI — выносим скрипты на отдельный сервер, общаемся по TCP.
• CDR, CEL обычно пишут в MySQL или другую базу, и это тоже нагрузка. Нужно заниматься тюнингом MySQL.
• AMI, ARI тоже никто не учитывает, пока не начинаются проблемы. А ведь вы просто включили какую-нибудь интеграцию с Битрикс24 или CRM, и вдруг всё начинает тормозить, потому что не оптимизировали работу AMI или ARI.

Сборка Asterisk

     Сборка Asterisk — тема тоже вечная. Самая правильная документация — на wiki.asterisk.org. Там сейчас навели порядок, всё структурировано. Да, на английском, но для айтишников это не проблема. Раньше для сборки Asterisk нужно было вручную ставить кучу зависимостей. Теперь есть команда ./install_prereq, которая сама всё установит. Дальше стандартные шаги: make menuselect, make, make install, make config, make install-logrotate.

     menuselect — это не просто «зашёл, вышел и забыл». Там есть множество опций, и, изучив их, вы сможете оптимизировать сборку под себя, в том числе по производительности.

     modules.conf — про него почему-то все забывают, а ведь это один из важнейших конфигов Asterisk. Именно там указывается, какие модули загружать, а какие нет. Мы обычно делаем autoload=yes, и всё, что было собрано, грузится без разбора. Потом удивляемся, что Asterisk работает медленнее, открывает кучу ненужных портов, а безопасник ругается. Лучше чётко прописать нужные модули. Например, параметр load или preload — только для тех, что вам действительно требуются (SIP, PJSIP, записи и т.п.). Есть модули, которые нужно загружать до инициализации Asterisk (например, доступ к внешним ресурсам), для них надо использовать preload. Так вы получите более быструю загрузку и меньше потенциальных проблем.

     Кстати, один из самых правильных modules.conf лежит в официальных конфигурациях Asterisk — configs/basic-pbx/modules.conf. Берите его за основу и добавляйте только то, что вам нужно. Тогда вы будете понимать, что именно умеет ваш Asterisk.

     Преимущество правильной настройки modules.conf: в консоли при старте не будет портянки из 200–300 предупреждений и ошибок. Если вы видите, что при загрузке нет ни одного ворнинга, значит всё настроили чётко. И если вдруг появится одна ошибка, вы сразу обратите на неё внимание, а не потеряетесь в море «варнингов».

Мониторинг

     Про мониторинг (Zabbix, Netdata, Grafana, Prometheus и т. д.) на этой сцене говорили много раз. Мы, как правило, берём готовые модули, всё настраиваем и получаем лавину уведомлений — в почту, в Telegram, причём тысячами. В итоге мы их все игнорируем. Нужно правильно определить, кто будет получать уведомления, какие и когда.

• Если директор или менеджеры хотят быть в курсе, дайте им эту возможность.
• Если это админ или IT-отдел, надо настроить нужные фильтры, чтобы не заваливать их мусором.
• Уровень проблемы тоже важен: где-то достаточно письма на email, где-то уместен Telegram-бот, а где-то даже звонок.

     Иногда достаточно так настроить систему, чтобы уведомления вообще никому не уходили, потому что оно работает стабильно и без участия человека. Но это очень индивидуально.

     Автоматизация — моя любимая тема. Часто основная проблема — не в самом Asterisk, а в провайдерах: упала связь, закончился баланс, бухгалтерия не оплатила счёт, и т. д. Я сделал скрипты на bash или Python, которые раз в n минут проверяют, работает ли транк с провайдером. Если нет — сразу автоматически формируется письмо провайдеру с договором и моим IP. То есть тикет открывается без моего участия. То же самое с балансом: если вызовов за полчаса не прошли, пишется письмо — или провайдеру, или бухгалтеру. Таким образом, я разгрузил себя от рутинных задач.

      В итоге клиенты видят, что «всё работает», хотя я их фактически поддерживаю за 0 рублей. Они и не ищут других специалистов, приходят ко мне за доработками и обновлениями. Со временем у меня освободилось больше личного времени, а отношения с клиентами, наоборот, укрепились.

Логи

     Логи — самая простая вещь, но многие их неправильно настраивают. В Asterisk классная система логирования:

1. Пишите full.log (в отдельный диск/раздел), ротуйте его раз в сутки. Если клиент говорит: «Пару дней назад что-то плохо работало», вы быстро смотрите размер лога за два дня — если он аномально маленький или большой, значит там что-то есть.
2. grep по call-id (уникальный идентификатор в квадратных скобках) — можно очень быстро вытащить всю цепочку вызова.
3. CDR по умолчанию довольно информативен, но туда можно дописать кастомные поля (номер SIP-агента, тот же call-id) — и потом быстро смотреть, какой именно вызов надо искать в логах.
4. CEL — тоже крутая штука, но осторожно: если вам это не нужно, лучше отключать, иначе база начнёт расти слишком быстро.

Интеграции

     Куча готовых виджетов и решений для Asterisk, чтобы интегрироваться с CRM, ERP, 1С, Bitrix24 и т.д. Обычно админы берут готовый модуль, ставят, он «как-то» работает, а о безопасности никто не думает. Между тем AMI, ARI, HTTP-запросы — это всё полноценные входы в систему, и надо их защищать.

• Curl() и прочие HTTP-запросы из диалплана — можно вызывать внешние API.
• System() / SHELL() — можно запускать скрипты на сервере.
• Asterisk DB — и вовсе позволяет напрямую писать и читать в базу RealTime или внешние хранилища.
• AMI, ARI — модули, через которые работают многие готовые интеграции. Нужно помнить, что AMI даёт практически полный доступ к системе, вплоть до чтения конфигов. Ни в коем случае не оставляйте их «проброшенными» наружу без защиты.

     Если что-то не получается, есть debugs AMI в Asterisk, есть команда grep по нужным событиям, можно посмотреть, что реально шлёт ваша CRM.

     RealTime используется вместо FreePBX в некоторых проектах. FreePBX тоже допилили за последние годы, стало лучше, есть даже встроенный firewall, но всё равно он часто ставит модули «пачкой», и много чего включено «на всякий случай». Если у вас простая система, RealTime может оказаться более элегантным решением: Asterisk сразу читает и пишет нужные данные в базу (MySQL, Postgres), и вы получаете гибкую настройку, которая по сути похожа на собственный «самописный FreePBX».

Команда Originate

     Это прям моя любимая штука. Обычно, когда мы что-то настроили в dialplan, мы поднимаем VPN, подключаемся софтфоном и проверяем, работает ли, есть ли звук. Я предлагаю проверять всё прямо из консоли Asterisk командой originate. Например, originate через нужный транк на мобильный номер, потом запустить приложение Echo(), проверить двусторонний звук. Или originate на application Playback() — и послушать, играет ли файл. Так экономится куча времени, не надо поднимать VPN и возиться с софтфоном.

     Через originate можно даже нагрузку проверить, запуская параллельно несколько вызовов. Или быстро проверить новый диалплан. Это очень удобно, но почему-то многие этим не пользуются.