Как устроено хранение записей в Asterisk

Универсального каталога для всех записей Asterisk нет: путь зависит от способа записи и настроек сервера. Для MixMonitor относительное имя ведёт в каталог мониторинга из asterisk.conf, а ARI хранит завершённые записи в подкаталоге recording внутри astspooldir. Сначала выясняю фактический путь, затем проверяю доступ и только после этого настраиваю хранение.

Сначала определите способ записи

В Asterisk нет одного каталога, куда обязаны попадать все аудиозаписи. Запись через MixMonitor, запись через ARI и запись модуля очередей могут использовать разные настройки и соглашения о путях. Поэтому я сначала выясняю, какой именно механизм запускает ваш dialplan или приложение. Иначе можно долго проверять пустую папку и уверенно доказывать, что звонки «не записывались». Уверенность тут не заменяет проверку.

Для MixMonitor имя файла передаётся приложению в dialplan. Если имя абсолютное, Asterisk пишет по этому пути; если относительное, использует настроенный каталог мониторинга из asterisk.conf. В типовой установке он находится под /var/spool/asterisk/monitor, но каталог spool можно изменить. Проверяйте живую конфигурацию и сценарий вызова, а не только пример из статьи или старый README. Установка из пакета, сборка из исходников и ручные изменения могут дать разные значения.

У завершённых записей ARI другой стандартный каталог: /recording внутри настроенного astspooldir; при типовом astspooldir это /var/spool/asterisk/recording. Официальная документация прямо описывает это расположение. Сам API управляет сохранёнными объектами, но это не делает каталог MixMonitor и каталог ARI взаимозаменяемыми. Если на сервере используются оба механизма, проверяйте оба и сопоставляйте файлы с журналами приложения.

• Проверить каталог spool в asterisk.conf
• Найти вызовы MixMonitor в dialplan
• Отдельно проверить завершённые записи ARI

Проследите путь от звонка до файла

Я проверяю путь по цепочке: конфигурация Asterisk, место запуска записи, имя файла, затем фактический файл на диске. Для MixMonitor полезно посмотреть, какой аргумент filename формирует dialplan и не подставляет ли он переменную. В документации есть переменная MIXMONITOR_FILENAME: она содержит имя, которое приложение действительно использует. Это позволяет сравнить ожидание с результатом, а не угадывать по названию каталога.

Не ищите несуществующий универсальный параметр recordingdir в mixmonitor.conf. Путь MixMonitor определяется именем файла и каталогом мониторинга Asterisk; верхние каталоги настраиваются в asterisk.conf. Например, изменение astspooldir меняет базовое место для spool и его подкаталогов. После изменения проверьте, что конфигурация действительно загружена и что dialplan не передаёт абсолютный путь в другое место.

У Asterisk также предусмотрено кэширование записываемых звуковых файлов. В примере asterisk.conf параметр cache_record_files включает кэширование, а record_cache_dir задаёт каталог кэша; стандартное значение примера — /tmp. Это промежуточное место во время записи, а не долговременный архив. При диагностике учитывайте его отдельно: свободное место может уходить и там, особенно если запись не завершилась штатно.

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

• Сопоставить MIXMONITOR_FILENAME и файл
• Проверить astspooldir в asterisk.conf
• Отличать каталог записи от кэша

Права: доступ только тем, кому он нужен

Не существует гарантированных прав 640 для каждой записи. Итоговые владелец, группа и режим зависят от пользователя процесса Asterisk, системной маски и настроек окружения. Сначала посмотрите конкретный файл и каталоги по пути: ls -l и namei -l покажут режимы и права прохода. Даже если у сотрудника есть чтение самого WAV, без права пройти по родительским каталогам он до файла не доберётся.

Для ограниченной выдачи доступа можно использовать отдельную группу или ACL. Вариант с группой проще сопровождать: выделяю группу для уполномоченных сотрудников, назначаю её каталогу и проверяю права новых файлов. ACL удобен, когда доступ нужен одному-двум аккаунтам, но он тоже требует проверки наследования и прав на родительские каталоги. Команда setfacl меняет ACL; перед применением изучите текущие значения через getfacl и зафиксируйте, как вернуть прежнее состояние.

Не выдавайте 777 и не делайте весь каталог общедоступным «на минуту». Записи содержат разговоры, а права на каталог определяют не только чтение: запись и удаление могут быть не менее чувствительны. Я проверяю доступ от имени реального пользователя, которому его выдают, и отдельно проверяю, что посторонняя учётная запись не читает файлы. Один успешный тест администратора ничего не говорит о доступе для целевой группы.

• Сверить владельца и режим файла
• Проверить проход по каталогам
• Проверить ACL и доступ целевой учётной записи

Срок хранения и безопасная очистка

Сначала зафиксируйте, какие записи нужны и сколько времени. Универсальный срок хранения без контекста назначить нельзя: владелец процесса определяет его с учётом цели записи и применимых к организации требований. Я не ставлю срок из чужого кейса в cron. Если записи нужны для претензий, контроля качества или иной задачи, порядок и срок хранения должны быть согласованы до автоматизации удаления.

Автоматическая команда удаления не должна появляться до инвентаризации форматов, каталогов, резервного копирования и исключений. Начните с просмотра кандидатов: find /var/spool/asterisk/monitor -type f -mtime +30 -print. Это только пример проверки старше условных 30 суток, а не рекомендация хранить именно столько. Проверьте список, путь, часовой пояс и смысл критерия возраста. Имя каталога нельзя подставлять в скрипт вслепую, особенно если путь менялся.

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

Особенно внимательно проверьте возрастную выборку на границе суток: параметры find считают возраст по времени изменения и правилам самой утилиты, а не по юридическому статусу записи. Если архив разбит по каталогам года и месяца, тестируйте обход на всём дереве. После просмотра списка сделайте резерв перечня выбранных файлов, чтобы можно было объяснить, что именно удалил планировщик. GNU Findutils рекомендует сначала проверять команду с -print перед добавлением -delete; это хорошая привычка даже для опытного администратора.

• Согласовать срок с владельцем процесса
• Сначала выполнить find с -print
• Проверить архив и журнал очистки

Следите за местом и проверяйте результат

Смотрите не только на общий размер папки, но и на файловую систему, где она расположена. df -h показывает доступное место по разделам, du -sh помогает оценить объём каталога. Если каталог находится на отдельном томе, свободное место корневого раздела не отвечает на вопрос, сколько осталось архиву. Проверяйте рост во времени: пиковые дни и крупные очереди звонков быстро делают вчерашнюю оценку бесполезной.

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

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

• Сверить df -h и du -sh
• Оповещать о заполнении нужного раздела
• Сопоставлять CDR.recordingfile с файлом

Если удалили файл, а место не вернулось

Linux освобождает место после удаления имени файла, когда закрыты все открытые ссылки на него. Если процесс продолжает держать файл открытым, блоки могут оставаться занятыми, хотя путь уже исчез. Сначала повторите df -h и проверьте открытые удалённые файлы через lsof +L1; при необходимости сузьте вывод до процесса Asterisk. Команда требует подходящих прав и наличия lsof. Не путайте этот случай с inode: отсутствие свободных inode проверяется отдельно через df -i.

Если Asterisk держит удалённый файл, выясните, какая запись и какой процесс его удерживает, и оцените влияние на активные звонки. Перезапуск systemctl restart asterisk может закрыть файловый дескриптор, но он способен прервать обслуживание; это не универсальная первая помощь и не гарантия решения всех проблем с диском. Сначала выберите безопасное окно, согласуйте возможный перерыв и проверьте, какой именно unit запущен в вашей системе.

После устранения причины повторно проверьте df -h, список каталогов, свежую тестовую запись и её чтение нужной учётной записью. Если место не вернулось, проверьте другие процессы, точки монтирования, inode и файлы кэша. Зафиксируйте результат в журнале инцидента, иначе следующий дежурный повторит те же команды без контекста. Восстановление считается законченным, когда понятны причина, освобождённый объём и состояние записи новых звонков.

Если применяете кэширование записей, осмотрите и каталог, заданный параметром record_cache_dir: стандартный пример asterisk.conf указывает /tmp. Не очищайте его общей уборкой временных файлов во время активной записи. Сопоставьте время звонка, активность процесса и состояние файла; затем убедитесь, что кэшируемая запись завершилась и итоговый файл появился в ожидаемом каталоге. Учитывайте отдельный раздел для /tmp: иначе временные данные могут забить систему, хотя архив записей расположен на другом томе.

• Проверить lsof +L1 и df -i
• Оценить влияние перезапуска на звонки
• Проверить тестовую запись после работ

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