Большинство колл-центров на Asterisk берутся за мониторинг слишком поздно. Ставят Asterisk, настраивают очереди, нанимают операторов, а через полгода кто-нибудь спрашивает: «Почему 15% звонящих бросают трубку?»
К этому моменту проблема уже несколько месяцев съедает деньги.
Я работал с инсталляциями Asterisk от 5 операторов до 200+. Картина везде одна: команды, которые настроили мониторинг с первого дня, точнее планируют смены, ловят проблемы до того, как о них расскажет клиент, и платят меньше за каждый решённый звонок.
В этом руководстве — что мониторить, как это включить на стороне Asterisk и какие инструменты реально живут в продакшене. Без теории: конкретные конфиги, SQL-запросы и живые цифры.
Что Asterisk отдаёт наружу (а что прячет)
Asterisk генерирует много данных. Сложность не в сборе, а в том, чтобы понять, какие данные важны и как связать их между собой.
Три источника данных, без которых не обойтись
1. AMI (Asterisk Manager Interface) — события в реальном времени
AMI отдаёт события по мере их возникновения: звонок попал в очередь, оператор ответил, абонент бросил трубку, оператор ушёл на паузу. Это несущая конструкция мониторинга в реальном времени.
; /etc/asterisk/manager.conf
[monitoring]
secret = generate_a_strong_password_here
deny = 0.0.0.0/0.0.0.0
permit = 10.0.0.0/255.255.255.0
read = system,call,log,agent,reporting
write = system,call,agent,reporting
writetimeout = 5000AMI даёт видимость состояния очередей с задержкой меньше секунды. Любой внешний инструмент мониторинга подключается через AMI за данными реального времени.
2. queue_log — история событий очереди
Этот файл фиксирует каждое взаимодействие с очередью: кто позвонил, какой оператор ответил, сколько человек ждал, почему разговор завершился.
# Проверяем, что queue_log действительно пишется
tail -5 /var/log/asterisk/queue_log
# Ожидаемый формат:
# 1774000000|1774000001|sales|ENTERQUEUE||2125551234|1
# 1774000005|1774000001|sales|CONNECT|5|SIP/200|1774000005.42
# 1774000120|1774000001|sales|COMPLETECALLER|5|115||1Поля: метка времени, уникальный ID, имя очереди, событие и данные, специфичные для события. Смысл полей data1/data2/data3 меняется в зависимости от типа события — именно на этом спотыкается большинство самописных систем отчётности.
Важно: включите полное логирование в каждой очереди:
; /etc/asterisk/queues.conf (для каждой очереди)
[sales]
eventwhencalled = yes
eventmemberstatus = yes
queue-callswaiting = yesБез eventwhencalled = yes вы теряете детализацию по операторам. Без eventmemberstatus не сможете отслеживать смену состояний оператора.
3. CDR (Call Detail Records) — данные на уровне звонка
CDR фиксирует время начала, время ответа, время завершения, длительность и disposition. Это уровень звонка, а не уровень очереди.
Типичная ошибка: duration в CDR включает время дозвона. billsec ближе к времени разговора, но включает навигацию по IVR. Ни то, ни другое не отражает реальное время разговора оператора с клиентом. Для точного времени разговора берите события CONNECT/COMPLETE из queue_log.
Метрики, которые действительно важны
Я видел дашборды с 40 метриками, из которых никто не смотрит на 35. Начните с этих семи. Добавляйте новые только тогда, когда у вас появится конкретный вопрос, на который они отвечают.
Уровень 1: смотреть каждый час
1. Звонки в ожидании (реальное время)
Сколько абонентов сейчас в очереди. Если это число превышает количество свободных операторов втрое, у вас проблема с укомплектованностью смены — не завтра, а прямо сейчас.
# Быстрая проверка из CLI
asterisk -rx "queue show sales" | grep -E "^ [0-9]+ has"2. Уровень сервиса (SLA)
Доля звонков, отвеченных в пределах вашего целевого времени. Отраслевой дефолт — «80/20» (80% ответов за 20 секунд), но цель должна соответствовать типу очереди:
| Тип очереди | Цель по SLA | Почему |
|---|---|---|
| Продажи / входящие | 80% за 15 с | Звонящий с намерением купить уходит быстро |
| Техподдержка | 80% за 30 с | У человека проблема — он готов ждать дольше |
| VIP / корпоративные клиенты | 90% за 10 с | Премиальные клиенты, премиальный SLA |
| Общие вопросы | 70% за 45 с | Ниже срочность, выше терпение |
-- Скользящий SLA по очередям (за последние 24 часа)
SELECT
queuename,
COUNT(CASE WHEN event = 'CONNECT' AND CAST(data1 AS UNSIGNED) <= 20 THEN 1 END) AS within_sla,
COUNT(CASE WHEN event = 'CONNECT' THEN 1 END) AS total_answered,
ROUND(100.0 * COUNT(CASE WHEN event = 'CONNECT' AND CAST(data1 AS UNSIGNED) <= 20 THEN 1 END) /
NULLIF(COUNT(CASE WHEN event = 'CONNECT' THEN 1 END), 0), 1) AS sla_pct
FROM queue_log
WHERE time > UNIX_TIMESTAMP(NOW() - INTERVAL 24 HOUR)
GROUP BY queuename
ORDER BY sla_pct ASC;3. Процент потерянных звонков (abandon rate)
Доля абонентов, которые бросили трубку, не дождавшись оператора. Ниже 5% — норма. Выше 10% — это уже потеря выручки.
-- Процент потерянных звонков по часам (ищем проблемные часы)
SELECT
HOUR(FROM_UNIXTIME(time)) AS hour_of_day,
COUNT(CASE WHEN event = 'ABANDON' THEN 1 END) AS abandoned,
COUNT(CASE WHEN event IN ('CONNECT','ABANDON') THEN 1 END) AS total_attempts,
ROUND(100.0 * COUNT(CASE WHEN event = 'ABANDON' THEN 1 END) /
NULLIF(COUNT(CASE WHEN event IN ('CONNECT','ABANDON') THEN 1 END), 0), 1) AS abandon_pct
FROM queue_log
WHERE time > UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)
GROUP BY HOUR(FROM_UNIXTIME(time))
ORDER BY abandon_pct DESC;Достаточно выполнить этот запрос один раз. Вы найдёте 2-3 часа, в которые процент потерь резко подскакивает. Это и есть ваши недоукомплектованные окна.
Уровень 2: смотреть ежедневно
4. Среднее время обработки (AHT) по операторам
AHT сильно различается от оператора к оператору. Вопрос в том, говорит ли этот разброс о проблеме или просто о разной сложности звонков.
-- AHT по операторам с количеством звонков (за 7 дней)
SELECT
agent,
COUNT(*) AS calls,
ROUND(AVG(CAST(data2 AS UNSIGNED))) AS avg_talk_sec,
ROUND(AVG(CAST(data1 AS UNSIGNED))) AS avg_hold_sec,
ROUND(AVG(CAST(data2 AS UNSIGNED) + CAST(data1 AS UNSIGNED))) AS avg_total_sec
FROM queue_log
WHERE event IN ('COMPLETECALLER', 'COMPLETEAGENT')
AND time > UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)
AND agent != 'NONE'
GROUP BY agent
HAVING calls >= 10
ORDER BY avg_total_sec DESC;Оператор с AHT 180 с и 50 звонками в день не обязательно хуже того, у кого 120 с и 40 звонков. Проверьте процент решения с первого звонка, прежде чем считать, что быстрее значит лучше.
5. Загрузка операторов (occupancy)
Время на обработке звонков как доля от времени в системе. Здоровый диапазон — 70-85%.
Ниже 70%: перебор с людьми в смене или операторы уклоняются от очереди. Выше 85%: вы движетесь к выгоранию операторов. Качество постобработки падает, количество ошибок растёт, следом идёт текучка.
6. Распределение времени ожидания (а не среднее)
Среднее время ожидания вводит в заблуждение. В очереди со средним ожиданием 15 секунд 80% звонков могут отвечаться за 5 секунд, а 20% — ждать больше 3 минут. Для этих 20% опыт отвратительный.
-- Распределение времени ожидания (перцентили)
SELECT
queuename,
COUNT(*) AS total_calls,
ROUND(AVG(CAST(data1 AS UNSIGNED))) AS avg_wait,
-- Приблизительные перцентили через условную агрегацию
MAX(CASE WHEN rn <= total * 0.50 THEN wait_sec END) AS p50_wait,
MAX(CASE WHEN rn <= total * 0.90 THEN wait_sec END) AS p90_wait,
MAX(CASE WHEN rn <= total * 0.95 THEN wait_sec END) AS p95_wait
FROM (
SELECT
queuename,
CAST(data1 AS UNSIGNED) AS wait_sec,
ROW_NUMBER() OVER (PARTITION BY queuename ORDER BY CAST(data1 AS UNSIGNED)) AS rn,
COUNT(*) OVER (PARTITION BY queuename) AS total
FROM queue_log
WHERE event = 'CONNECT'
AND time > UNIX_TIMESTAMP(NOW() - INTERVAL 7 DAY)
) sub
GROUP BY queuename;Если P50 равен 8 секундам, а P95 — 180, у вас бимодальное распределение. Лечится это обычно усилением смены в пиковые часы, а не добавлением операторов во все смены подряд.
Уровень 3: смотреть еженедельно
7. Утилизация транков
Насколько ваши SIP-транки близки к пределу ёмкости? Держитесь ниже 80% в пике. Выше — и во время всплесков абоненты начнут получать сигнал «занято».
-- Пик одновременных звонков по транкам (за 7 дней)
SELECT
DATE(calldate) AS day,
HOUR(calldate) AS peak_hour,
SUBSTRING_INDEX(channel, '/', 2) AS trunk,
COUNT(*) AS concurrent_calls
FROM cdr
WHERE calldate > DATE_SUB(NOW(), INTERVAL 7 DAY)
AND disposition = 'ANSWERED'
GROUP BY DATE(calldate), HOUR(calldate), SUBSTRING_INDEX(channel, '/', 2)
ORDER BY concurrent_calls DESC
LIMIT 10;Как поднять мониторинг: три подхода
Подход 1: CLI-скрипты (бесплатно, ограниченно)
Годится для разовых проверок. Полноценным решением для мониторинга это не является.
#!/bin/bash
# quick-queue-status.sh - запускать через cron каждые 5 минут
QUEUES=$(asterisk -rx "queue show" | grep "^[a-zA-Z]" | awk '{print $1}')
for Q in $QUEUES; do
WAITING=$(asterisk -rx "queue show $Q" | grep "has [0-9]* calls" | awk '{print $3}')
AGENTS=$(asterisk -rx "queue show $Q" | grep -c "SIP/")
if [ "$WAITING" -gt 5 ] && [ "$AGENTS" -gt 0 ]; then
RATIO=$((WAITING / AGENTS))
if [ "$RATIO" -gt 3 ]; then
echo "ALERT: Queue $Q has $WAITING calls waiting with $AGENTS agents (ratio: $RATIO:1)"
# Отправить оповещение на почту, в Slack и т.д.
fi
fi
doneБазовые оповещения вы получите. Но проверка идёт раз в 5 минут, а за 5 минут может произойти многое. И ничего о трендах, паттернах и работе конкретных операторов такой скрипт вам не расскажет.
Подход 2: Grafana + собственный пайплайн (бесплатно, 40-80 часов)
Для команд, у которых есть DevOps-компетенция и время:
- —Установить Grafana + PostgreSQL (или TimescaleDB для оптимизации временных рядов)
- —Написать парсер queue_log, который заливает события в базу
- —Сделать слушатель AMI для событий реального времени
- —Собрать дашборды под каждую метрику выше
- —Настроить правила оповещений
Трезвая оценка: первоначальная сборка занимает 40-80 часов в зависимости от вашего опыта с SQL и Grafana. Дашборд получается красивым. А дальше:
- —Приход, уход и паузы операторов требуют правок дашбордов
- —Изменения в конфигурации очередей ломают запросы
- —Кто-то должен поддерживать слушатель AMI (он отваливается, Asterisk перезапускается, сеть моргает)
- —Хранением исторических данных надо управлять
Большинство проектов «Grafana поверх Asterisk», которые я видел, забрасывают в течение 6-12 месяцев — когда уходит инженер, который их собрал. Ломается не дашборд: ломается сопровождение пайплайна данных.
Подробный разбор — в нашем полном сравнении Grafana и Astervis.
Подход 3: Astervis (специализированное решение, 10 минут)
Astervis сделан именно под мониторинг колл-центров на Asterisk. Подключение к AMI, разбор queue_log, дашборды реального времени, управление операторами и оповещения работают из коробки.
# Установка на сервер с Asterisk или на отдельную машину
curl -fsSL https://api.astervis.io/api/releases/install.sh | bashДальше в дашборде:
- —Добавляете свой сервер Asterisk (учётные данные AMI)
- —Очереди подхватываются автоматически
- —Начинаете мониторить
Что вы получаете:
- —30+ графиков, включая тепловые карты, сравнение трендов и аналитику по очередям
- —Дашборды реального времени (обработка событий AMI быстрее секунды)
- —Отслеживание работы операторов с KPI и рейтингами
- —Мониторинг SLA с настраиваемыми порогами для каждой очереди
- —Планирование смен и управление операторами
- —Прослушивание записей разговоров прямо из дашборда
- —Интеграция с CRM (Bitrix24, AmoCRM)
- —Self-hosted — данные остаются в вашей сети
Стоимость: от $119 в месяц, число операторов не ограничено. 14-дневный бесплатный триал, без привязки карты.
Работает с FreePBX, Sangoma, Issabel, VitalPBX — со всем, у чего под капотом Asterisk.
Настройка Asterisk под мониторинг
Устали угадывать, что происходит в очередях?
Astervis даёт 30+ реалтайм-графиков, KPI операторов и CRM-интеграцию для вашего Asterisk PBX. On-premise. Установка за 5 минут. От $119/мес flat — без ограничения на операторов.
Включаем полное логирование событий
В большинстве инсталляций Asterisk логирование неполное. Начните с этого:
; /etc/asterisk/queues.conf - добавить в КАЖДУЮ секцию очереди
[sales]
; ... ваш текущий конфиг ...
eventwhencalled = yes ; Логировать, какому оператору предложен звонок
eventmemberstatus = yes ; Логировать смену состояний оператора (пауза, снятие паузы, вход)
monitor-type = MixMonitor ; Включить запись разговоров
queue-callswaiting = yes ; Объявлять абоненту его позицию
queue-thankyou = beep ; Звук подтверждения при соединении
; Тонкая настройка производительности
wrapuptime = 30 ; 30 с между звонками (защищает от выгорания, улучшает учёт постобработки)
timeout = 15 ; Звонить оператору 15 с, потом пробовать следующего
retry = 5 ; Пауза 5 с между попыткамиМоё мнение про wrapuptime: по умолчанию это 0, то есть следующий звонок прилетает оператору сразу после того, как он положил трубку. Плохо это по трём причинам: (1) оператор не успевает завершить постобработку и делает её уже во время следующего звонка, раздувая AHT; (2) это приводит к выгоранию — см. наше руководство по профилактике выгорания; (3) ваши цифры AHT теряют смысл, потому что время постобработки прячется внутри времени разговора.
Ставьте wrapuptime минимум на 15-30 секунд. Сначала AHT визуально вырастет, но реальная производительность станет выше.
Настраиваем AMI для внешних инструментов
; /etc/asterisk/manager.conf
[general]
enabled = yes
port = 5038
bindaddr = 0.0.0.0
[monitoring]
secret = use_a_strong_32_char_password
deny = 0.0.0.0/0.0.0.0
permit = 10.0.0.100/255.255.255.255 ; Только IP вашего сервера мониторинга
read = system,call,log,agent,reporting
write = system,call,agent,reporting
writetimeout = 5000Безопасность: никогда не используйте permit = 0.0.0.0/0.0.0.0 в продакшене. AMI даёт полный контроль над вашей АТС. Ограничивайте доступ конкретными IP.
После изменений:
asterisk -rx "manager reload"
# Проверка: telnet your-asterisk-server 5038Выбор стратегии очереди
Данные мониторинга хороши ровно настолько, насколько продумана стратегия очереди. Разные стратегии дают разные картины:
| Стратегия | Поведение | Кому подходит | Что видно в мониторинге |
|---|---|---|---|
| ringall | Звонит всем операторам сразу | Небольшие команды (<5) | Равномерное распределение, высокий процент ответов |
| leastrecent | Звонит тому, кто дольше всех простаивал | Сбалансированная нагрузка | Однородные метрики по операторам |
| fewestcalls | Звонит тому, у кого меньше всего звонков | Честное распределение | Схожее количество звонков |
| rrmemory | Round-robin с запоминанием | Предсказуемость | Последовательные паттерны по операторам |
| random | Случайный оператор | Большие команды | Статистическое распределение |
| linear | Фиксированный порядок приоритета | Распределение по навыкам | Лучшие операторы перегружены |
linear даёт самое предсказуемое качество, но выжигает ваших лучших операторов. leastrecent — лучшая универсальная стратегия: она естественным образом выравнивает нагрузку, а значит, ваши данные мониторинга становятся осмысленнее.
Типичные ошибки в мониторинге
Ошибка 1: смотреть на средние вместо распределений
Среднее время ожидания 25 секунд звучит приемлемо. Но распределение может быть таким:
- —60% звонков: ответ быстрее 10 секунд
- —25% звонков: ответ за 30-60 секунд
- —15% звонков: ожидание 2-5 минут
Эти 15% — ваш риск оттока. Используйте перцентили P90 и P95 вместо средних. SQL-запросы выше считают и то, и другое.
Ошибка 2: не разделять типы очередей
Смешивая метрики очереди продаж с метриками поддержки, вы обесцениваете и те, и другие. 30 секунд ожидания в очереди продаж стоят выручки. 30 секунд ожидания в очереди обратного звонка — это норма. Настройте отдельные цели по SLA для каждой очереди.
Ошибка 3: считать CDR аналитикой очередей
CDR фиксирует звонки. queue_log фиксирует взаимодействия с очередью. Это разные источники данных, отвечающие на разные вопросы.
CDR говорит: «Этот звонок длился 3 минуты». queue_log говорит: «Абонент ждал 45 секунд, ответил оператор SIP/200, разговор длился 2 минуты 15 секунд, абонент положил трубку первым».
Если вы строите отчёты только на данных CDR, вы теряете контекст очереди. О том, как эффективно совместить оба источника, читайте в нашем руководстве по отчётности CDR.
Ошибка 4: усталость от оповещений
Оповещения на каждый мелкий порог создают шум. Люди привыкают игнорировать все алерты, включая критические.
Начните всего с трёх:
- —Переполнение очереди: больше 10 абонентов ждут дольше 2 минут
- —Нарушение SLA: уровень сервиса ниже 60% на протяжении 15+ минут
- —Ёмкость транков: одновременные звонки превышают 80% ёмкости транка
Добавляйте новые оповещения только после того, как докажете, что стабильно реагируете на эти три.
Ошибка 5: нет исторической базы для сравнения
Дашборды реального времени бесполезны без контекста. «47 звонков в очереди» ничего не значит, если вы не знаете, что во вторник в 14:00 их обычно 50. Прежде чем дашборд реального времени начнёт приносить пользу, нужно накопить минимум 30 дней истории.
Чек-лист мониторинга
Пройдитесь по списку, чтобы убедиться, что мониторинг Asterisk настроен полностью:
Сбор данных:
- — AMI включён, заведён пользователь для мониторинга
- — queue_log пишет все события (eventwhencalled, eventmemberstatus)
- — CDR пишется в базу данных (а не только в плоский файл)
- — wrapuptime задан для каждой очереди (не 0)
- — Запись разговоров включена (MixMonitor)
Дашборды:
- — Состояние очередей в реальном времени (звонки в ожидании, свободные операторы)
- — Индикатор SLA по каждой очереди (с корректным порогом)
- — Процент потерянных звонков по часам (тепловая карта)
- — Таблица показателей операторов (AHT, звонки, FCR)
- — График утилизации транков
Оповещения:
- — Настроено оповещение о переполнении очереди
- — Настроено оповещение о нарушении SLA
- — Настроено оповещение о ёмкости транков
- — Доставка оповещений протестирована (почта, Slack, webhook)
Отчётность:
- — Ежедневная сводка автоматизирована
- — Настроен еженедельный отчёт по трендам
- — Запланирован ежемесячный отчёт по ёмкости
Что меняется с мониторингом в реальном времени
Команды, которые выстроили мониторинг правильно, стабильно получают улучшения:
- —Процент потерянных звонков падает на 30-50% уже в первый месяц (потому что вы видите проблемы в момент их возникновения, а не через неделю)
- —Простой операторов сокращается на 15-20% (более точные решения по смене в реальном времени)
- —Соблюдение SLA улучшается на 10-25% (пороговые оповещения не дают нарушениям затягиваться)
- —Затраты на персонал снижаются на 5-10% за 3 месяца (тепловые карты показывают окна с избытком людей)
Это не гипотезы. Это картина, которую я вижу раз за разом, когда команды переходят от «иногда заглянуть в CLI» к непрерывному мониторингу.
Разрыв между колл-центром на Asterisk с хорошим мониторингом и колл-центром без него — это не разница в технической изощрённости. Это разница в видимости. Нельзя починить то, чего не видишь.
Держите колл-центр на Asterisk без мониторинга в реальном времени? Запустите бесплатный 14-дневный триал Astervis и получите 30+ дашбордов за 10 минут.
Уже мониторите через Grafana или скрипты? Посмотрите, как Astervis выглядит на их фоне, в нашем сравнении инструментов мониторинга.
Хватит гадать. Начни видеть.
Реальная картина вашего Asterisk колл-центра: время ожидания, активность операторов, нагрузка на транки и 30+ графиков. On-premise на вашем сервере. Установка за 5 минут. Без карты.
От $119/мес flat. Без ограничения на операторов. Триал 14 дней.