Как восстановить Asterisk после сбоя и не усугубить аварию

Когда Asterisk перестал проводить звонки, сначала выясните, остановился ли процесс, сломался ли маршрут вызова или пропал только звук. Я проверяю статус службы и последние ошибки, затем ресурсы, конфигурацию и сеть. Так можно выбрать точное действие и не превращать сбой телефонии в перезагрузку всего сервера.

С чего начать, если Asterisk не отвечает

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

Если Asterisk установлен как служба systemd и unit называется asterisk, выполните systemctl status asterisk. Команда покажет состояние службы и последние сообщения, но не объяснит автоматически, почему звонок не дошёл. Имя unit зависит от способа установки; если система отвечает, что такой службы нет, это повод выяснить, как именно запускается процесс, а не создавать unit наугад. В командную строку Asterisk подключаются через asterisk -rvvv: это консоль для наблюдения за событиями с подробным выводом, а не проверка синтаксиса конфигурации.

Журналы тоже не обязаны лежать там, где их ожидает администратор. В типовой установке используется каталог /var/log/asterisk, но путь задаётся через astlogdir в asterisk.conf, а направления и состав записей настраиваются в logger.conf. Проверьте фактический файл или syslog, сопоставьте время ошибки со временем неудачного вызова и сохраните несколько соседних записей. Одной строки без контекста мало: в ней может быть следствие, а причина окажется на несколько событий выше.

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

Я также спрашиваю, что менялось незадолго до сбоя: обновляли пакеты, правили маршрут, меняли сетевое правило или подключали новое оборудование. Это не поиск виноватого, а способ сузить проверку до событий, которые могли повлиять на вызовы. Когда изменений было несколько, я сравниваю их с журналом и откатываю только подтверждённую правку. «Кто последний трогал?» полезно для хронологии, но не заменяет диагностику.

• Уточните симптом: регистрация, входящие, исходящие или звук.
• Если служба управляется systemd, проверьте systemctl status asterisk.
• Сверьте время отказа с журналом Asterisk и системными сообщениями.
• Проведите один контролируемый тестовый звонок и запишите его результат.

Нехватка памяти и OOM-killer

При дефиците памяти Linux может запустить OOM-killer и завершить процесс, который ядро выбрало по своим критериям. Это не доказывает, что Asterisk сам по себе «съел всю память»: причиной могут оказаться другой процесс, ограничение контейнера или общая нехватка ресурсов. Я ищу в системных сообщениях запись о завершённом процессе и сверяю её с нагрузкой и временем пропажи службы. Если имя процесса в записи не совпадает с Asterisk, обвинять телефонию только потому, что звонки остановились, рано.

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

В условном сценарии с сетью «Факел-Строй» я бы разделил две задачи: вернуть службу и выяснить, почему ядро остановило процесс. Для первой проверил бы состояние unit и последние записи; для второй — системный журнал, ограничения памяти и процессы, работавшие одновременно. Подтверждения именно OOM без записи ядра нет. Если такой записи не нашли, версия о нехватке памяти остаётся догадкой, даже если после перезапуска всё временно ожило.

Порог оповещения нельзя выбрать одной магической цифрой для всех машин. На узле с небольшой свободной памятью сигнал может появиться слишком поздно, а на загруженном сервере краткий пик не обязательно предвещает отказ. Я настраиваю наблюдение по истории конкретного сервера, учитываю пики звонков и запас для соседних служб. Для этого подойдёт мониторинг Asterisk, если он показывает не только состояние службы, но и изменение ресурсов во времени.

Важно отличать единичный пик от устойчивого роста. Я смотрю, возвращается ли память к привычному уровню после завершения нагрузки, и растёт ли потребление именно у Asterisk или у соседнего процесса. Затем проверяю ограничения контейнера и работу записи звонков. Слепое увеличение лимита лишь отодвигает повтор сбоя, если утечка осталась. Резерв памяти тоже не чинит код: у него другая должность.

• Ищите запись OOM в системных сообщениях.
• Сверяйте имя остановленного процесса с причиной сбоя.
• Сопоставляйте память, каналы и внешние процессы по времени.

Ошибки конфигурации и диалплана

После изменения файла конфигурации я сначала выясняю, какой компонент должен был его перечитать. Для вызовов важны не только sip.conf или pjsip.conf: маршрут может зависеть от контекста в extensions.conf, настроек регистрации и отдельных модулей. Команда asterisk -rvvv подключает к работающей консоли и помогает увидеть события, но не запускает самостоятельную проверку всех файлов перед перезапуском. Если в консоли нет ожидаемого маршрута, проверяйте контекст endpoint и совпадение номера с правилом диалплана.

Ошибка «extension not found in context» означает, что Asterisk не нашёл подходящее расширение в контексте, куда направлен вызов. Это не равнозначно падению службы: процесс может быть исправен, а конкретный звонок — настроен неверно. Сопоставьте имя контекста на endpoint с контекстом в диалплане, проверьте шаблон номера и направление входящего вызова. Разбор основ есть в статье про диалплан Asterisk; менять правила вслепую в рабочее время я бы не стал.

И совет «после любой правки обязательно перезапустить всё» слишком грубый. Некоторые модули умеют перечитывать свои настройки, для других требуется отдельное действие, а изменения транспорта PJSIP по умолчанию не применяются обычной перезагрузкой модуля, если не разрешён allow_reload. Сверяйте именно изменённый раздел с документацией своей версии и планируйте полную остановку, если она нужна. Перезапуск ради любой запятой — простой способ оборвать текущие звонки и не понять, помогло ли исправление.

В кейсе из черновика утверждалось, что администратор забыл формат номера и получил «No such context». Это разные виды ошибки, и связь между ними нельзя устанавливать без конкретной записи журнала. Поэтому я оставляю практический вывод, а выдуманную последовательность событий убираю: когда звонок не попал в нужный маршрут, исследуйте context и dialplan. Причину подтверждает журнал или воспроизводимый тест, а не удачно звучащий рассказ.

Перед изменением диалплана сохраните текущий файл и зафиксируйте, какое правило меняете. Сверьте контекст на endpoint с именем контекста в extensions.conf, затем проверьте маршрут на тестовом звонке. Если правка затрагивает несколько направлений, проходите их по одному и записывайте результат. Так проще вернуть прежнее поведение, чем восстанавливать конфигурацию по памяти после неудачного эксперимента.

Сеть, NAT и пропавший звук

Если телефон зарегистрирован, но вызов не устанавливается, проверьте путь сигнализации: телефон, маршрутизатор, правила межсетевого экрана, затем транспорт Asterisk. Прослушиваемый порт сам по себе не доказывает, что пакеты доходят с обеих сторон. Проверьте правила на сервере и сетевом шлюзе, адрес источника, протокол и фактический транспорт из конфигурации. Число 5060 часто встречается в примерах SIP, но слушать сервер может на другом порту; фиксированный порт из статьи не заменит проверку вашей настройки.

Когда разговор устанавливается, но пропал звук или слышит только одна сторона, отдельно проследите медиапоток RTP. Диапазон RTP задаётся в конфигурации и может отличаться от распространённых шаблонов, поэтому правило «откройте 10000–20000» нельзя копировать вслепую. Сверьте активные значения rtpstart и rtpend в конфигурации с правилами фаервола и трансляцией адресов. Если голос не приходит в одну сторону, найдите, на каком участке пакеты перестали проходить; наличие SIP-соединения этого не подтверждает.

Для удалённых endpoint за NAT в PJSIP используются настройки, влияющие на адреса сигнализации и медиа, в том числе rtp_symmetric, force_rport и rewrite_contact. Это не универсальный переключатель «включить NAT»: значения зависят от того, где находится Asterisk и за каким шлюзом сидит телефон. Сначала зафиксируйте схему соединения и адреса, после этого меняйте настройки endpoint. Пример и смысл параметров разобраны в руководстве по настройке PJSIP.

При поиске причины не меняйте одновременно фаервол, NAT и диалплан. Зафиксируйте исходное правило, внесите одно согласованное изменение и повторите одинаковый тестовый вызов. Если изменилось сразу несколько условий, случайно заработавший звонок не покажет, какая правка была нужна; следующая проверка начнётся с нуля. Сеть любит точные наблюдения: какой пакет вышел, какой дошёл, куда Asterisk отправил ответ и что вернул телефон.

Проверка сети должна повторять реальную схему звонка: тот же телефон, тот же маршрут, тот же удалённый сегмент. Успешный ping до сервера не доказывает, что SIP-сигнализация и двусторонний RTP проходят через те же правила. Я отдельно проверяю входящий и исходящий сценарии, а также слышимость в обе стороны. «Сервер пингуется» — хорошая новость для ICMP, но телефонии от этого ни жарко ни холодно.

Старая версия Asterisk и обновление

Совет «ставьте версию 13 или выше» устарел. По официальной таблице проекта Asterisk ветка 11 завершила жизненный цикл 25 октября 2017 года, а ветка 13 — 24 октября 2021 года. Эти версии не становятся безопасными оттого, что на них продолжают идти звонки. До обновления проверьте статус своей ветки, источник пакетов и совместимость модулей; дату следующего выпуска нельзя подменять универсальным обещанием «последняя стабильная».

Обновление не всегда является быстрым способом поднять связь прямо во время аварии. Сначала верните контроль над текущим процессом и сохраните конфигурацию, затем соберите список используемых модулей, каналов, транков и интеграций. После этого подготовьте перенос на поддерживаемую ветку, проверьте конфигурацию и проведите тесты входящих, исходящих и медиапотока. План перехода и фактический статус релизов я сверяю по таблице версий Asterisk и официальным заметкам проекта.

Перед работами сохраните конфигурацию и убедитесь, что копия читается. Одной папки с файлами недостаточно, если неизвестно, какие модули установлены, откуда взяты пакеты и как запускается служба. Запишите версии и параметры транспорта, отметьте локальные правки, затем обновляйте тестовую систему или согласованное окно. Для распределения рисков пригодится отдельная инструкция по резервной копии конфигурации Asterisk.

Не называю конкретную актуальную версию в тексте на годы вперёд: поддержка меняется, а понятие «последняя» устаревает быстрее статьи. Рабочее правило другое — использовать ветку, которую проект сейчас поддерживает, проверить сроки её сопровождения и читать примечания именно к целевому выпуску. База пакетов вашего дистрибутива может предлагать другой релизный цикл; сравните его с расписанием проекта, а не обновляйте систему наугад.

Для обновления заранее проверьте, откуда установлены пакеты и какие дополнительные модули подключены к Asterisk. После перехода может измениться совместимость стороннего модуля или способ сборки; номер ветки сам по себе этого не предсказывает. Подготовьте возврат к прежнему пакету и копии конфигурации, а тестовый запуск проведите до планового окна. Обновление в разгар отказа — плохой момент знакомиться с зависимостями.

Диск, оборудование и восстановление после сбоя

Заполненный диск мешает создавать новые журналы, временные файлы и записи разговоров, но сам по себе не доказывает, что именно он остановил Asterisk. Команда df -h показывает занятое место в смонтированных файловых системах; проверьте раздел, где находятся журналы и данные Asterisk, а также свободное место на корневом разделе. При необходимости отдельно смотрите занятые inode: свободные гигабайты не помогут, если закончились записи каталогов.

Если место закончилось, не удаляйте наугад всё из /var/log/asterisk и каталогов записей. Сначала выясните, какой файл вырос и почему, сохраните полезный журнал, затем используйте настроенную ротацию или безопасную очистку по сроку хранения. Удалённый файл может продолжать занимать место, пока его держит открытым процесс. Исправление должно вернуть свободное пространство и не стереть следы причины; иначе утром станет легче только потому, что расследовать уже нечего.

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

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

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

• Проверьте свободное место через df -h.
• Сверьте разделы с фактическими путями данных и журналов.
• Ищите подтверждение аппаратного сбоя в системных сообщениях.
• После исправления проверьте регистрацию, вызов и звук.

Частые вопросы