Как хранить записи Asterisk и не забить диск

Чтобы записи Asterisk не забили диск и не потерялись, заранее задайте формат, срок хранения, правила доступа и способ поиска файла по CDR. Я покажу, как оценить объём по длительности разговоров, настроить MixMonitor, проверить права и автоматизировать архивирование с удалением.

Почему включённая запись звонков через полгода превращается в проблему

Типовая картина: телефонию подняли, в диалплан добавили MixMonitor, все довольны. Через полгода сервер предупреждает о нехватке места, а руководитель просит найти разговор за прошлый вторник. Администратор листает десятки тысяч файлов с именами вроде 1729154432.1187.wav. Когда мы берём такую АТС на ИТ-аутсорсинг под ключ, часто обнаруживаем записи в одном каталоге, на разделе с системой и без понятной связи с CDR.

Проблемы растут одновременно. Первая — объём: записи копятся, и свободное место кончается не по расписанию. Если заполнен раздел, где лежат система и журналы, последствия могут выйти за пределы каталога записей. Вторая — поиск: без структуры и идентификатора из CDR файл трудно связать с конкретным разговором. Третья — доступ: запись разговора может содержать персональные данные, поэтому право читать каталог не должно выдаваться всем подряд.

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

Как MixMonitor пишет разговор и зачем нужна опция b

MixMonitor — приложение Asterisk, которое записывает аудио текущего канала и по умолчанию смешивает направления в один файл. Общий вид вызова: MixMonitor(имя_файла,опции,команда). Для абсолютного пути используется указанный путь; относительный путь строится внутри настроенного каталога мониторинга. Часто это /var/spool/asterisk/monitor, но каталог задаётся конфигурацией Asterisk. Расширение файла должно соответствовать поддерживаемому формату. Третий параметр — команда после завершения записи; перед обработкой файла в диалплане вызовите StopMixMonitor, чтобы гарантировать, что файл закрыт.

Опция b сохраняет аудио, пока канал находится в мосту с другим каналом. Она помогает не включать в файл часть ожидания до соединения, но не превращает CDR billsec в точную длительность записанного аудио при любых переводах и сценариях удержания. В примере с «Окном слова» это сокращает часть тишины и музыки до соединения; фактическую экономию нужно измерять по своим звонкам. Не обещайте, что b не создаст пустых файлов: это зависит от сценария и сборки.

Я запускаю MixMonitor в той ветке диалплана, где понятен жизненный цикл звонка, до перехода в Queue() или Dial(), если запись должна начаться для этого сценария. После запуска переменная MIXMONITOR_FILENAME содержит фактическое имя файла, использованное Asterisk. Его можно сохранить в CDR, пока соответствующая запись CDR ещё доступна для изменения. В CDR одного разговора может быть несколько записей для отдельных каналов или этапов; при сложных переводах проверьте связь по linkedid, а не рассчитывайте на одну строку. Синтаксис приложения и доступные опции смотрите в справке именно установленной версии.

• b — сохранять аудио только в мосте каналов
• a — добавлять запись в конец существующего файла
• r(файл) и t(файл) — раздельные направления, если нужны отдельные дорожки
• MIXMONITOR_FILENAME — фактическое имя файла записи

Сколько места займут записи: считаем по фактическому потоку

Считать нужно по длительности разговоров и реальному формату файла. Для несжатого PCM WAV, 8 кГц, 16 бит, моно поток составляет 128 кбит/с: примерно 16 КБ/с, 0,96 МБ/мин или 57,6 МБ/час в десятичных единицах. Это оценка без небольших накладных расходов контейнера. CDR billsec показывает длительность от ответа до окончания конкретной CDR-записи, а не гарантированное число секунд в аудиофайле для всех сценариев. Поэтому сумму billsec используйте для первичной оценки, затем сравните её с фактическим размером записей за типичный период.

В условном примере «Окна слова» — около 600 отвеченных звонков в рабочий день со средней длительностью три минуты: это 1800 минут. При 22 рабочих днях получается 39 600 минут в месяц. Для WAV из предыдущего расчёта это примерно 38 ГБ, а для MP3 с постоянным потоком 32 кбит/с — около 9,5 ГБ до учёта накладных расходов и конкретных настроек кодировщика. Это расчётный пример, а не гарантия размера файлов: проверьте результат на своей АТС и на реальном материале.

Для своей АТС сначала проверьте, где и в каком виде сохраняются CDR: это может быть база или CSV, но Master.csv есть не в каждой установке. Сложите подходящие billsec за репрезентативный период, учитывая несколько записей на один разговор, затем сопоставьте сумму с каталогом файлов. Умножьте измеренный месячный объём на срок хранения и добавьте запас под пики. Если сезонность заметна, планируйте по пиковому периоду. Не прибавляйте универсальный процент вслепую: сравните пиковые месяцы и темп роста.

Структура каталогов и имён, по которой запись находится за минуту

Имя файла должно помогать связать запись с CDR, но не раскрывать лишнее тем, кто видит только список каталога. Я использую дату в пути и уникальный идентификатор канала в имени. Так проще искать записи и удалять старые файлы по сроку. Создание вложенных каталогов зависит от версии и настроек, поэтому проверьте на тестовом звонке, что нужная структура создаётся и запись действительно открывается.

Пример фрагмента диалплана для входящих звонков в очередь:

same => n,Set(REC=${STRFTIME(${EPOCH},,%Y/%m/%d)}/${STRFTIME(${EPOCH},,%H%M%S)}-${UNIQUEID}.wav)
same => n,MixMonitor(/var/spool/asterisk/monitor/${REC},b)
same => n,Set(CDR(userfield)=${REC})
same => n,Queue(sales)

В примере дата и UNIQUEID входят в имя, а относительный путь записывается в userfield. Перед внедрением проверьте, что каталог существует, доступен пользователю Asterisk, а выбранный CDR-backend сохраняет userfield. Документация отдельно предупреждает: не подставляйте непроверенные строки вроде CALLERID(num) или CALLERID(name) в параметры MixMonitor — возможна инъекция команды. Если номер нужен для поиска, берите его из CDR с контролем доступа.

UNIQUEID — уникальный идентификатор канала Asterisk, поэтому он надёжнее номера телефона как часть имени. Не считайте, что одного uniqueid всегда достаточно для объединения всех этапов сложного вызова: для связанных CDR предусмотрен linkedid. В примере намеренно нет номера абонента в имени файла. Ситуацию, когда CRM получает пустую запись, мы разбирали отдельно: почему пропадают записи звонков.

Кто может слушать записи: права на файлы и доступ людей

Asterisk обычно работает от системного пользователя asterisk, но конкретные пользователь, группа и umask зависят от установки. Я задаю отдельную группу, например recordings, и выдаю доступ только тому сервисному аккаунту, которому действительно нужно читать файлы. Типовая цель — каталоги 2750 и файлы 640: владелец может читать и менять, группа — читать, остальные не имеют доступа. Setgid на каталогах помогает новым файлам наследовать группу; корректную маску записи проверьте отдельно на тестовом файле.

Сначала проверьте текущие права, ничего не меняя:

ls -ld /var/spool/asterisk/monitor
find /var/spool/asterisk/monitor -type f -perm -o=r -print
find /var/spool/asterisk/monitor -type f -perm -g=r -print | head

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

chgrp -R recordings /var/spool/asterisk/monitor
find /var/spool/asterisk/monitor -type d -exec chmod 2750 {} +
find /var/spool/asterisk/monitor -type f -exec chmod 640 {} +

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

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

Сжатие, архив и удаление по сроку без ручной работы

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

Постобработку можно запустить командой MixMonitor после записи, но она выполняется для каждого звонка. Если обработка тяжёлая, вынесите её в очередь или ночное задание. Перед чтением или конвертацией из диалплана используйте StopMixMonitor, чтобы файл был закрыт. Для ночного задания я сначала создаю сжатую копию, проверяю код завершения, наличие файла и возможность его прочитать, затем обновляю ссылку в CDR и только после этого удаляю исходник. lame — внешний кодировщик MP3; проверьте его наличие и формат входного WAV. Архив копируйте на отдельное хранилище, а независимые снимки или резервные копии защитят его от случайного удаления вместе с источником.

Пример команды GNU find для удаления файлов старше 90 суток по времени изменения:

find /var/spool/asterisk/monitor -type f -mtime +90 -print
# После проверки списка:
find /var/spool/asterisk/monitor -type f -mtime +90 -delete
find /var/spool/asterisk/monitor -mindepth 1 -type d -empty -delete

-mtime считает полные 24-часовые периоды, поэтому +90 — не календарная дата «ровно три месяца назад». Сначала проверьте список без -delete, затем согласуйте границу срока. Для архива задайте отдельный путь и срок. Пишите в журнал число удалённых файлов и объём, следите за свободным местом и настройте предупреждение до исчерпания раздела. Отдельный том снижает риск, что заполнение записей затронет систему, но само по себе не заменяет мониторинг.

• Отдельный том или каталог с контролем свободного места
• Ночная перекодировка с проверкой результата
• Архив на отдельном хранилище и независимая копия
• Предварительный список файлов перед find -delete
• Журнал удаления и раннее предупреждение о заполнении

Чем закончилось у «Окна слова» и что дальше

В условном примере настройка заняла два рабочих дня: в первый посчитали поток по CDR, выделили место под записи и скорректировали диалплан; во второй проверили права, отключили общую папку и настроили ночную обработку, архив, удаление и мониторинг. Расчётная оценка для выбранного формата MP3 — около 9,5 ГБ за месяц при заданных вводных вместо примерно 38 ГБ несжатого WAV. Фактические 90 дней проверяют по измеренному потоку за сопоставимый сезон, а не по одной красивой цифре в статье.

Практический результат — понятные роли, предсказуемый срок и поиск файла через CDR. Ошибки, которые я встречаю чаще всего, повторяются: запись складывают рядом с системой, права оставляют слишком широкими, а старые файлы не удаляют. Исправления начинаются с инвентаризации: где лежат записи, кто их читает, какой процесс их связывает с CDR и кто утвердил срок. Потом настраиваем автоматизацию и проверяем её на тестовом наборе.

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

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