Каждый звонок, проходящий через ваш Asterisk PBX, порождает запись о вызове — Call Detail Record (CDR). В этих записях лежит масса информации: кто звонил, когда, сколько длился разговор, ответили ли на вызов. Но у большинства администраторов Asterisk данные CDR так и остаются лежать в таблице MySQL или в плоском файле — невидимыми и бесполезными.
Это руководство превращает ваши CDR из сырых строк базы данных в осмысленные отчёты, на основе которых принимают реальные бизнес-решения. Вы разберётесь, как устроен CDR, как эффективно его запрашивать и как построить (или выбрать) систему отчётности, которая действительно помогает управлять колл-центром.
Что содержится в CDR Asterisk?
Запись CDR создаётся для каждого вызова, обработанного Asterisk. Каждая запись состоит из стандартных полей:
| Поле | Описание | Пример |
|---|---|---|
accountcode | Учётный код, присвоенный вызову | sales-team |
src | Номер источника (звонящего) | +15551234567 |
dst | Номер назначения (набранный) | 200 |
dcontext | Контекст назначения | from-internal |
clid | Полная строка Caller ID | "John Smith" <+15551234567> |
channel | Исходный канал | PJSIP/trunk-0000001a |
dstchannel | Канал назначения | PJSIP/1001-0000001b |
lastapp | Последнее выполненное приложение | Dial, Queue, Voicemail |
lastdata | Данные, переданные в последнее приложение | PJSIP/1001,30 |
start | Метка времени начала вызова | 2026-03-18 09:15:22 |
answer | Метка времени ответа | 2026-03-18 09:15:28 |
end | Метка времени завершения вызова | 2026-03-18 09:18:45 |
duration | Общая длительность вызова (в секундах) | 203 |
billsec | Тарифицируемые секунды (время разговора) | 197 |
disposition | Итог вызова | ANSWERED, NO ANSWER, BUSY, FAILED |
amaflags | Флаги AMA | DOCUMENTATION |
uniqueid | Уникальный идентификатор вызова | 1710752122.456 |
userfield | Пользовательское поле | (зависит от настроек) |
CDR против CEL: в чём разница
CDR даёт одну запись на вызов — сводку. Считайте это чеком.
CEL (Channel Event Logging) фиксирует каждое событие внутри вызова: создание канала, вызывной сигнал, ответ, соединение, перевод, отбой. Это уже полный журнал транзакции.
Для базовой отчётности (объём вызовов, длительность, итог) достаточно CDR. Для сложной аналитики (цепочки переводов, участники конференций, взаимодействие с очередями) нужен CEL.
| Задача | Хватит CDR | Нужен CEL |
|---|---|---|
| Всего вызовов за день | ✅ | ✅ |
| Средняя длительность вызова | ✅ | ✅ |
| Разбивка по итогам вызовов | ✅ | ✅ |
| Отслеживание маршрута перевода | ❌ | ✅ |
| Время ожидания в очереди по каждому звонящему | Ограниченно | ✅ |
| Учёт участников конференции | ❌ | ✅ |
| Время дозвона до оператора | ❌ | ✅ |
| Точные биллинговые расчёты | ❌ | ✅ |
Настройка хранения CDR
Вариант 1: CSV (по умолчанию)
По умолчанию Asterisk пишет CDR в /var/log/asterisk/cdr-csv/Master.csv. Для небольших инсталляций это нормально, но очень быстро становится неудобным.
# Check if CSV CDR is active
asterisk -rx "cdr show status"Вариант 2: MySQL/MariaDB
Самый распространённый бэкенд для отчётности по CDR. Настраивается в /etc/asterisk/cdr_mysql.conf:
[global]
hostname = localhost
dbname = asteriskcdrdb
table = cdr
password = your_db_password
user = asterisk_cdr
port = 3306Создайте таблицу CDR:
CREATE TABLE cdr (
id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
calldate DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
clid VARCHAR(80) NOT NULL DEFAULT '',
src VARCHAR(80) NOT NULL DEFAULT '',
dst VARCHAR(80) NOT NULL DEFAULT '',
dcontext VARCHAR(80) NOT NULL DEFAULT '',
channel VARCHAR(80) NOT NULL DEFAULT '',
dstchannel VARCHAR(80) NOT NULL DEFAULT '',
lastapp VARCHAR(80) NOT NULL DEFAULT '',
lastdata VARCHAR(80) NOT NULL DEFAULT '',
duration INT(11) NOT NULL DEFAULT 0,
billsec INT(11) NOT NULL DEFAULT 0,
disposition VARCHAR(45) NOT NULL DEFAULT '',
amaflags INT(11) NOT NULL DEFAULT 0,
accountcode VARCHAR(20) NOT NULL DEFAULT '',
uniqueid VARCHAR(150) NOT NULL DEFAULT '',
userfield VARCHAR(255) NOT NULL DEFAULT '',
INDEX idx_calldate (calldate),
INDEX idx_src (src),
INDEX idx_dst (dst),
INDEX idx_disposition (disposition),
INDEX idx_accountcode (accountcode)
);Вариант 3: PostgreSQL
Для более крупных инсталляций. Настраивается в /etc/asterisk/cdr_pgsql.conf:
[global]
hostname = localhost
dbname = asteriskcdrdb
table = cdr
password = your_db_password
user = asterisk_cdr
port = 5432Вариант 4: ODBC (универсальный)
ODBC работает с любой поддерживаемой базой данных. Настраивается через /etc/asterisk/cdr_adaptive_odbc.conf:
[asterisk_cdr]
connection = asterisk
table = cdr
alias start => calldate
alias clid => srcПосле настройки перезагрузите CDR:
asterisk -rx "module reload cdr"
asterisk -rx "cdr show status"Обязательные запросы к CDR
Как только CDR оказался в базе данных, вот запросы, которые нужны каждому администратору:
Объём вызовов по дням
SELECT
DATE(calldate) AS call_date,
COUNT(*) AS total_calls,
SUM(CASE WHEN disposition = 'ANSWERED' THEN 1 ELSE 0 END) AS answered,
SUM(CASE WHEN disposition = 'NO ANSWER' THEN 1 ELSE 0 END) AS no_answer,
SUM(CASE WHEN disposition = 'BUSY' THEN 1 ELSE 0 END) AS busy,
SUM(CASE WHEN disposition = 'FAILED' THEN 1 ELSE 0 END) AS failed
FROM cdr
WHERE calldate >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
GROUP BY DATE(calldate)
ORDER BY call_date DESC;Почасовое распределение вызовов (данные для тепловой карты)
SELECT
DAYOFWEEK(calldate) AS day_of_week,
HOUR(calldate) AS hour_of_day,
COUNT(*) AS call_count
FROM cdr
WHERE calldate >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY DAYOFWEEK(calldate), HOUR(calldate)
ORDER BY day_of_week, hour_of_day;Этот запрос даёт данные для тепловой карты — одной из самых полезных визуализаций при планировании смен.
Средняя длительность вызова по направлениям
SELECT
dst AS extension,
COUNT(*) AS total_calls,
ROUND(AVG(billsec), 1) AS avg_talk_seconds,
ROUND(AVG(duration), 1) AS avg_total_seconds,
ROUND(AVG(duration - billsec), 1) AS avg_ring_seconds,
SUM(CASE WHEN disposition = 'ANSWERED' THEN 1 ELSE 0 END) / COUNT(*) * 100 AS answer_rate_pct
FROM cdr
WHERE calldate >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
AND disposition IN ('ANSWERED', 'NO ANSWER')
GROUP BY dst
HAVING total_calls >= 5
ORDER BY total_calls DESC
LIMIT 20;Самые активные звонящие (входящие)
SELECT
src AS caller_number,
COUNT(*) AS call_count,
SUM(billsec) AS total_talk_seconds,
ROUND(AVG(billsec), 1) AS avg_talk_seconds,
MIN(calldate) AS first_call,
MAX(calldate) AS last_call
FROM cdr
WHERE calldate >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
AND src != ''
AND LENGTH(src) > 5 -- Filter internal extensions
GROUP BY src
ORDER BY call_count DESC
LIMIT 25;Анализ неотвеченных вызовов
SELECT
src AS caller_number,
dst AS called_extension,
calldate,
duration AS ring_seconds,
disposition
FROM cdr
WHERE calldate >= DATE_SUB(CURDATE(), INTERVAL 1 DAY)
AND disposition != 'ANSWERED'
AND LENGTH(src) > 5
ORDER BY calldate DESC;Загрузка транков
SELECT
SUBSTRING_INDEX(channel, '-', 1) AS trunk,
COUNT(*) AS total_calls,
SUM(billsec) AS total_seconds,
ROUND(AVG(billsec), 1) AS avg_seconds,
SUM(CASE WHEN disposition = 'ANSWERED' THEN 1 ELSE 0 END) AS answered,
SUM(CASE WHEN disposition = 'FAILED' THEN 1 ELSE 0 END) AS failed
FROM cdr
WHERE calldate >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY SUBSTRING_INDEX(channel, '-', 1)
ORDER BY total_calls DESC;Пик одновременных вызовов (продвинутый уровень)
SELECT
DATE(calldate) AS call_date,
HOUR(calldate) AS call_hour,
MAX(concurrent) AS peak_concurrent
FROM (
SELECT
calldate,
(SELECT COUNT(*) FROM cdr c2
WHERE c2.calldate <= c1.calldate
AND ADDTIME(c2.calldate, SEC_TO_TIME(c2.duration)) >= c1.calldate) AS concurrent
FROM cdr c1
WHERE calldate >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
) AS concurrent_data
GROUP BY DATE(calldate), HOUR(calldate)
ORDER BY call_date DESC, call_hour;Сравнение инструментов отчётности по CDR
Ручные SQL-запросы
Плюсы: полный контроль, никакого дополнительного софта Минусы: нужно знать SQL, нет визуализации, нет автоматизации, отнимает много времени
Asternic CDR Reports
Просмотрщик CDR для Asterisk, написанный на PHP.
Плюсы: прямая работа с таблицей CDR, базовые графики Минусы: легаси-код на PHP, ограниченная кастомизация, нет режима реального времени, устаревший интерфейс
CDR-Stats (заброшен)
Платформа аналитики CDR на Django.
Плюсы: когда-то была весьма полной, с детектированием мошенничества Минусы: проект заброшен. Последние реальные обновления были годы назад. Эпоха Python 2. Не начинайте новые внедрения с ним.
Устали угадывать, что происходит в очередях?
Astervis даёт 30+ реалтайм-графиков, KPI операторов и CRM-интеграцию для вашего Asterisk PBX. On-premise. Установка за 5 минут. От $119/мес flat — без ограничения на операторов.
Grafana + SQL Datasource
Подключите Grafana напрямую к базе данных CDR.
Плюсы: мощная визуализация, бесплатно, гибко настраивается Минусы: все запросы вы пишете сами. Никакой логики, заточенной под очереди. 20-40 часов на сборку приличного набора дашбордов. Плюс постоянное сопровождение.
Astervis
Специализированная аналитическая платформа, которая выходит далеко за рамки отчётности по сырым CDR.
Плюсы:
- —Автоматический сбор CDR: настраивать базу данных вручную не нужно. Astervis читает данные CDR через AMI и собственный конвейер сбора.
- —30+ готовых графиков: тепловые карты, линии трендов, сравнительные срезы — всё работает из коробки
- —Очереди и CDR вместе: в отличие от чистых CDR-инструментов, Astervis связывает данные CDR с событиями очередей, показывая жизненный цикл вызова целиком
- —Эффективность операторов: индивидуальные KPI по каждому оператору на основе CDR и данных очередей
- —Установка одной командой: без PHP, без Java, без самописного SQL
Минусы: платно после 14-дневного пробного периода (от $119/месяц)
Дальше базового CDR: продвинутая аналитика
Сырые данные CDR отвечают на вопрос «что произошло». Продвинутая аналитика отвечает «почему это произошло» и «что с этим делать».
Классификация итогов вызова
Поле disposition в CDR говорит вам ANSWERED или NO ANSWER, но не показывает бизнес-результат. Привёл ли отвеченный вызов к продаже? К решению проблемы? К заявке на обратный звонок?
Продвинутые платформы дополняют CDR:
- —Данными очередей: время ожидания, название очереди, оператор, обработавший вызов
- —Данными CRM: карточка клиента, статус тикета, стадия сделки
- —Записями разговоров: о чём на самом деле шла речь
Именно на этой связке CDR перестаёт быть журналом и становится источником знаний.
Выявление трендов
Отчёты по CDR за один день — это шум. Полезные выводы дают тренды:
- —Растёт ли среднее время обработки от недели к неделе? (проблема с обучением)
- —Концентрируются ли неуспешные вызовы на конкретных транках? (проблема на стороне провайдера)
- —Смещается ли объём вызовов на другие часы? (изменения на рынке)
- —Есть ли всплески отказов на конкретных внутренних номерах? (проблема с укомплектованностью смен)
Прогнозное планирование смен
Исторические данные CDR вместе с аналитикой очередей позволяют строить прогнозные модели загрузки персонала:
- —Проанализируйте закономерности объёма вызовов по часам, дням, неделям и месяцам
- —Учтите сезонность и заранее известные события
- —Рассчитайте необходимое число операторов на каждый интервал исходя из целей по SLA
- —Автоматически формируйте графики смен
Это и есть святой Грааль аналитики CDR — превращение исторических данных в решения, работающие на опережение.
Настройка отчётности по CDR с Astervis
Если вы хотите пропустить самописные SQL-запросы и получить готовую к продакшену отчётность по CDR за считаные минуты:
Шаг 1: Установите Astervis
curl -fsSL https://api.astervis.io/api/releases/install.sh | bashAstervis автоматически подключается к вашему серверу Asterisk через AMI и начинает собирать данные о вызовах — CDR, события очередей и события каналов — в свой бэкенд на TimescaleDB.
Шаг 2: Изучите готовые отчёты
Откройте дашборд по адресу http://your-server:3000. Отчёты на базе CDR доступны сразу же:
- —Тренды объёма вызовов: по дням, неделям, месяцам — с наложением периодов для сравнения
- —Тепловая карта: распределение вызовов по часам и дням недели
- —Разбивка по итогам: отвеченные, пропущенные, занято, неуспешные — с трендами
- —Эффективность операторов: обработанные вызовы, средняя длительность, доступность
- —Аналитика транков: загрузка по каждому транку, доля отказов, одновременные вызовы
- —Топ звонящих и направлений: номера с наибольшим объёмом и детализацией по клику
Шаг 3: Подключите свою CRM
Подключите Bitrix24 или AmoCRM, чтобы видеть контекст клиента рядом с данными CDR. Открывая запись о вызове, вы сразу видите историю клиента, открытые сделки и обращения в поддержку — всё в одном окне.
Лучшие практики хранения данных CDR
Как долго хранить данные CDR
| Сценарий | Срок хранения | Обоснование |
|---|---|---|
| Операционная отчётность | 90 дней | Свежие закономерности для планирования смен |
| Соответствие требованиям (GDPR) | По требованию | Зависит от юрисдикции |
| Споры по биллингу | 12 месяцев | Стандартный срок оспаривания |
| Анализ трендов | 24 месяца | Выявление сезонных закономерностей |
| Регуляторные требования (телеком) | 1-7 лет | Зависит от юрисдикции |
Оптимизация производительности
Для таблиц CDR в MySQL/MariaDB:
-- Partition by month for faster queries
ALTER TABLE cdr PARTITION BY RANGE (TO_DAYS(calldate)) (
PARTITION p202601 VALUES LESS THAN (TO_DAYS('2026-02-01')),
PARTITION p202602 VALUES LESS THAN (TO_DAYS('2026-03-01')),
PARTITION p202603 VALUES LESS THAN (TO_DAYS('2026-04-01')),
PARTITION p_future VALUES LESS THAN MAXVALUE
);
-- Archive old data
CREATE TABLE cdr_archive LIKE cdr;
INSERT INTO cdr_archive SELECT * FROM cdr WHERE calldate < DATE_SUB(CURDATE(), INTERVAL 1 YEAR);
DELETE FROM cdr WHERE calldate < DATE_SUB(CURDATE(), INTERVAL 1 YEAR);Для нагруженных инсталляций (от 10 000 вызовов в день) присмотритесь к TimescaleDB — расширению PostgreSQL, созданному специально для временных рядов. Именно его Astervis использует внутри, и на больших объёмах он обрабатывает запросы к CDR на порядки быстрее обычного MySQL.
Типичные ошибки при работе с CDR
1. Пропущенные записи
Записи CDR генерирует Asterisk, а не сеть. Если Asterisk упадёт посреди разговора, соответствующий CDR может оказаться неполным или вовсе отсутствовать. Всегда сверяйте количество записей CDR с ожидаемым объёмом вызовов.
2. Путаница между duration и billsec
- —
duration= общее время от начала вызова до отбоя (включая дозвон) - —
billsec= время от ответа до отбоя (только разговор)
Если использовать duration для метрик эффективности операторов, цифры окажутся завышенными. Для расчёта времени разговора всегда берите billsec.
3. Двойной учёт переведённых вызовов
Слепые переводы создают несколько записей CDR на один клиентский контакт. Вызов, переведённый дважды, порождает 3 записи CDR. Ваша отчётность должна это учитывать, группируя по linkedid (Asterisk 12+) или по исходному uniqueid.
4. Несовпадение часовых поясов
Если ваш сервер Asterisk работает в UTC, а команда — в EST, метки времени CDR будут отличаться от «рабочего времени» на 5 часов. Либо настройте часовой пояс в Asterisk, либо выполняйте преобразование на уровне отчётности.
5. У вызовов из очереди нет контекста
CDR по вызову из очереди показывает последнего оператора, который его обработал, но не показывает:
- —сколько клиент ждал в очереди
- —скольким операторам звонок предлагался до этого (события RINGNOANSWER)
- —отказался ли клиент от ожидания и перезвонил ли потом
Именно поэтому одного CDR для аналитики колл-центра недостаточно. Вместе с CDR нужны queue_log или данные событий AMI.
Заключение
Данные CDR — фундамент отчётности в Asterisk, но сырые записи CDR это лишь отправная точка. Разрыв между «данными в базе» и «рабочими выводами» — то самое место, где застревает большинство команд: недели уходят на написание SQL-запросов и сборку дашбордов вместо улучшения работы колл-центра.
Если вам нужны просто логи вызовов, хватит и ручных SQL-запросов. Если нужна готовая к продакшену аналитика с тепловыми картами, KPI операторов, мониторингом транков и интеграцией с CRM — Astervis даёт всё это за 5 минут установки, с 30+ графиками, доступными с первого дня.
Начните бесплатный 14-дневный пробный период и узнайте, что всё это время пытались сказать вам ваши данные CDR.
Нужен ещё и мониторинг в реальном времени? Читайте: Как мониторить очереди Asterisk в реальном времени
Сравниваете решения? Смотрите: Лучшие инструменты мониторинга Asterisk в 2026 году
Хватит гадать. Начни видеть.
Реальная картина вашего Asterisk колл-центра: время ожидания, активность операторов, нагрузка на транки и 30+ графиков. On-premise на вашем сервере. Установка за 5 минут. Без карты.
От $119/мес flat. Без ограничения на операторов. Триал 14 дней.