Если у вас колл-центр на Asterisk, очереди — это пульс всей операции. Каждый неотвеченный звонок, каждое долгое ожидание, каждый простаивающий оператор стоят вам денег. При этом большинство администраторов Asterisk работают вслепую: у них нет представления о том, что происходит в очередях прямо сейчас.
В этом руководстве разобраны все доступные способы мониторинга очередей Asterisk в реальном времени — от встроенных CLI-команд и событий AMI до специализированных аналитических платформ. К концу статьи вы будете точно знать, какой подход подходит вашей команде и как внедрить его уже сегодня.
Зачем нужен мониторинг очередей в реальном времени
Прежде чем переходить к «как», оцифруем «зачем».
Колл-центр без мониторинга в реальном времени по определению работает реактивно. Вы узнаёте о проблемах уже после того, как они обошлись вам в деньги:
- —Потерянные звонки: средний показатель по отрасли — 5–8 %. Без оповещений в реальном времени всплески потерь остаются незамеченными до вечернего отчёта.
- —Нарушения SLA: если ваша цель — 80 % звонков, отвеченных за 20 секунд, вы должны узнать об отставании в ту же минуту, а не завтра утром.
- —Перекос в загрузке операторов: один оператор захлёбывается, трое сидят без дела. Без живого дашборда супервизор не может перераспределить нагрузку на лету.
- —Перегрузка транков: когда все SIP-транки заняты, входящие абоненты слышат короткие гудки. Мониторинг транков в реальном времени это предотвращает.
Математика простая: колл-центр, обрабатывающий 500 звонков в день, снизив потери на 2 %, сохраняет 10 звонков ежедневно. Даже при средней ценности звонка в $50 это $500 в день или $130 000 в год — только за счёт мониторинга в реальном времени.
Способ 1: CLI-команды Asterisk
Самая простая отправная точка. В Asterisk есть встроенные CLI-команды для просмотра состояния очередей.
queue show
Самая часто используемая команда:
asterisk -rx "queue show"Вывод:
support has 3 calls (max unlimited) in 'rrmemory' strategy (18s holdtime, 145s talktime), W:0, C:47, A:12, SL:78.3%, SL2:65.2% within 60s
Members:
SIP/1001 (ringinuse disabled) (dynamic) (Not in use) has taken 15 calls (last was 342 secs ago)
SIP/1002 (ringinuse disabled) (dynamic) (In use) has taken 18 calls (last was 12 secs ago)
SIP/1003 (ringinuse disabled) (dynamic) (Paused) has taken 14 calls (last was 890 secs ago)
Callers:
1. SIP/trunk-00000a1b (wait: 0:18, prio: 0)
2. SIP/trunk-00000a1c (wait: 0:09, prio: 0)
3. SIP/trunk-00000a1d (wait: 0:03, prio: 0)
Ключевые поля:
- —W (Weight — вес), C (Completed — завершённые звонки), A (Abandoned — потерянные звонки)
- —SL (Service Level в процентах — звонки, отвеченные в пределах целевого времени)
- —Состояния участников очереди: Not in use, In use, Paused, Unavailable, Ringing, Busy
- —Время ожидания абонентов в реальном времени
queue show [queue_name]
Для конкретной очереди:
asterisk -rx "queue show sales"Ограничения CLI-команд
- —Ничего не сохраняется: статистика обнуляется при перезапуске Asterisk
- —Нет сравнения с историей: вы видите «сейчас», но не можете сравнить со вчерашним днём
- —Нет оповещений: проверять нужно вручную, push-уведомлений нет
- —Только снимок: вы видите состояние в один момент времени, а не динамику
- —Плохо масштабируется: запуск CLI-команд в цикле ненадёжен и прожорлив по ресурсам
CLI полезен для быстрой диагностики, но для промышленного мониторинга его недостаточно.
Способ 2: Asterisk Manager Interface (AMI)
AMI — событийный интерфейс Asterisk, на котором построено большинство инструментов мониторинга. Он отдаёт события обо всём, что происходит в очередях, в реальном времени.
Настройка AMI
Отредактируйте /etc/asterisk/manager.conf:
[general]
enabled = yes
port = 5038
bindaddr = 127.0.0.1
[monitor]
secret = your_secure_password
deny = 0.0.0.0/0.0.0.0
permit = 127.0.0.1/255.255.255.0
read = agent,call,reporting
write = agent,call,originateПерезагрузите конфигурацию после изменений:
asterisk -rx "manager reload"Ключевые события очередей
AMI генерирует событие на каждое изменение состояния очереди. Самые важные из них:
| Событие | Когда срабатывает | Ключевые поля |
|---|---|---|
QueueCallerJoin | Абонент попал в очередь | Queue, Position, Count, CallerIDNum |
QueueCallerLeave | Абонент покинул очередь | Queue, Position, Count, HoldTime |
QueueCallerAbandon | Абонент положил трубку, не дождавшись ответа | Queue, Position, OriginalPosition, HoldTime |
QueueMemberStatus | Изменилось состояние оператора | Queue, Interface, Status, Paused |
QueueMemberAdded | Оператор вошёл в очередь | Queue, MemberName, Interface |
QueueMemberRemoved | Оператор вышел из очереди | Queue, MemberName, Interface |
QueueMemberPause | Оператор встал на паузу или снялся с неё | Queue, Interface, Paused, Reason |
AgentConnect | Звонок соединён с оператором | Queue, Interface, HoldTime, RingTime |
AgentComplete | Оператор завершил разговор | Queue, Interface, HoldTime, TalkTime |
Приём событий AMI (пример на Python)
Минимальный скрипт на Python, который слушает события очередей в реальном времени:
import socket
import re
def connect_ami(host='127.0.0.1', port=5038, user='monitor', secret='your_secure_password'):
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((host, port))
# Read banner
sock.recv(1024)
# Login
sock.send(f'Action: Login\r\nUsername: {user}\r\nSecret: {secret}\r\n\r\n'.encode())
sock.recv(4096)
# Subscribe to queue events
sock.send('Action: QueueStatus\r\n\r\n'.encode())
print("Connected to AMI. Listening for queue events...")
buffer = ''
while True:
data = sock.recv(4096).decode('utf-8', errors='ignore')
buffer += data
while '\r\n\r\n' in buffer:
event, buffer = buffer.split('\r\n\r\n', 1)
if 'Event: Queue' in event or 'Event: Agent' in event:
print(f"\n{'='*50}")
print(event)
connect_ami()AMI-команды для управления очередями
Помимо приёма событий, через AMI можно активно управлять очередями:
Action: QueueStatus # Get current state of all queues
Action: QueueSummary # Get summary statistics
Action: QueueAdd # Add agent to queue dynamically
Action: QueueRemove # Remove agent from queue
Action: QueuePause # Pause/unpause an agent
Action: QueueReset # Reset queue statistics
Ограничения «сырого» AMI
- —Всё придётся писать самому: парсинг, хранение, визуализация, оповещения — целиком ваш код
- —Нет истории: события идут потоком в реальном времени, но нигде не сохраняются, пока вы это не реализуете
- —Сложное управление состоянием: отслеживание статусов операторов сразу в нескольких очередях требует аккуратного кода
- —Нет дашбордов: для визуализации нужен отдельный фронтенд
- —Стоимость поддержки: самописные скрипты мониторинга AMI быстро превращаются в технический долг
AMI мощный, но чтобы превратить его в работающее решение для мониторинга, нужны серьёзные затраты на разработку.
Способ 3: файл queue_log
Asterisk пишет все события очередей в /var/log/asterisk/queue_log. На этом файле построено большинство инструментов исторической отчётности.
Формат queue_log
Каждая строка выглядит так:
UNIX_TIMESTAMP|CALLID|QUEUE|AGENT|EVENT|PARAM1|PARAM2|PARAM3
Примеры записей:
1710720000|1710719980.123|support|SIP/1001|CONNECT|18|1710719982.124|5
1710720180|1710719980.123|support|SIP/1001|COMPLETECALLER|18|180||
1710720200|1710720190.125|support|NONE|ABANDON|1|1|15
Ключевые события в queue_log
| Событие | Описание | Параметры |
|---|---|---|
ENTERQUEUE | Абонент попал в очередь | URL, CallerID |
CONNECT | Звонок соединён с оператором | HoldTime, BridgedChannel, RingTime |
COMPLETECALLER | Абонент положил трубку после разговора | HoldTime, TalkTime, Position |
COMPLETEAGENT | Оператор положил трубку после разговора | HoldTime, TalkTime, Position |
ABANDON | Абонент ушёл, не дождавшись ответа | Position, OrigPosition, WaitTime |
RINGNOANSWER | Оператор не ответил вовремя | RingTime |
TRANSFER | Звонок был переведён | Extension, Context |
PAUSE | Оператор встал на паузу | Reason |
UNPAUSE | Оператор снялся с паузы | — |
Разбор queue_log (Bash)
Быстрый однострочник, чтобы посмотреть долю потерянных звонков за сегодня:
# Count today's events
TODAY=$(date +%s -d "today 00:00")
awk -F'|' -v start="$TODAY" '$1 >= start' /var/log/asterisk/queue_log | \
awk -F'|' '{events[$5]++} END {for(e in events) print e, events[e]}' | sort -k2 -rnОграничения
- —Работа с файлом: разбор текстовых файлов плохо масштабируется дальше нескольких тысяч звонков в день
- —Нет дашборда в реальном времени: вы разбираете данные постфактум
- —Проблемы с ротацией: при неаккуратной настройке ротации логов часть данных теряется
- —Ручная агрегация: расчёт KPI вроде service level требует нетривиальных скриптов
Способ 4: запись CDR и CEL в базу данных
Для постоянного хранения настройте запись CDR (Call Detail Records) или CEL (Channel Event Logging) в базу данных.
CDR в MySQL/PostgreSQL
В /etc/asterisk/cdr_adaptive_odbc.conf:
[asterisk_cdr]
connection = asterisk
table = cdr
alias start => calldate
alias clid => srcТак вы получите записи о звонках, доступные через SQL. Но в CDR нет специфики очередей: есть записи о звонках, но нет метрик очередей — времени ожидания по каждой очереди, эффективности операторов внутри очереди или причин потери звонка.
CEL для детальных событий
CEL (Channel Event Logging) даёт куда более гранулярные данные, чем CDR. Для хранения в базе настройте /etc/asterisk/cel_odbc.conf. CEL фиксирует по каждому каналу события CHAN_START, ANSWER, BRIDGE_ENTER, BRIDGE_EXIT и HANGUP.
Однако чтобы превратить сырые события CEL в осмысленные дашборды очередей, потребуется:
- —Сложные SQL-запросы с объединением нескольких событий
- —Логика конечного автомата для восстановления хода звонка
- —Собственная агрегация KPI
- —Слой визуализации (Grafana, своё приложение и т. д.)
Именно здесь большинство самодельных решений либо застревают, либо съедают месяцы инженерного времени.
Способ 5: open-source инструменты
Есть несколько open-source проектов, которые пытаются решить задачу мониторинга очередей Asterisk:
QPanel
QPanel — панель реального времени для очередей Asterisk и FreeSWITCH. Подключается по AMI и показывает текущее состояние очередей.
Плюсы: бесплатно, open-source, отображение в реальном времени Минусы: минималистичный интерфейс, нет исторической аналитики, вялая разработка, нет оповещений, нет отслеживания KPI
Устали угадывать, что происходит в очередях?
Astervis даёт 30+ реалтайм-графиков, KPI операторов и CRM-интеграцию для вашего Asterisk PBX. On-premise. Установка за 5 минут. От $119/мес flat — без ограничения на операторов.
MoniAst
Веб-панель мониторинга Asterisk: показывает текущие звонки и внутренние номера.
Плюсы: отображение в реальном времени, мониторинг внутренних номеров Минусы: базовая поддержка очередей, нет аналитики, устаревшая кодовая база
CDR-Stats
Когда-то многообещающий инструмент аналитики CDR на Django.
Плюсы: был функционально полным Минусы: фактически заброшен — последнее значимое обновление было много лет назад. Код эпохи Python 2. Для новых внедрений не рекомендуется.
Grafana + собственные дашборды
Мощный DIY-вариант: складывать данные queue_log или CEL в InfluxDB/TimescaleDB и строить дашборды в Grafana.
Плюсы: гибко, бесплатно, мощная визуализация Минусы: на нормальную настройку уйдёт 40–80 часов инженерного времени. Свои пайплайны данных. Постоянная поддержка. Никакой готовой логики по очередям «из коробки». Вы строите продукт, а не пользуетесь им.
Способ 6: коммерческие решения
QueueMetrics
Ветеран рынка. Написан на Java, существует с 2005 года.
Цена: от CHF 8 за оператора в месяц (облако) или разовая лицензия Плюсы: развёрнутая отчётность, зрелый продукт, поддержка wallboard Минусы: зависимость от Java (нужен Tomcat), устаревший интерфейс, сложная установка, дорого на масштабе (50 операторов = CHF 400 в месяц), медленное развитие
Asternic Call Center Stats
Сфокусирован на отчётности по очередям.
Цена: для полного функционала нужна коммерческая лицензия Плюсы: прямая интеграция с queue_log, генерация отчётов Минусы: в основном историческая отчётность (не реальное время), устаревший интерфейс, ограниченная настройка дашбордов, легаси-код на PHP
Astervis
Современный SaaS, созданный специально для мониторинга и аналитики очередей Asterisk.
Цена: от $119 в месяц (число операторов не ограничено) до индивидуальных Enterprise-планов Установка: одна команда — подключение по AMI, без Java, без PHP, без сложных зависимостей
Ключевые отличия:
- —30+ графиков в реальном времени: тепловые карты, эффективность очередей, дашборды операторов, аналитика транков — всё обновляется вживую
- —Отслеживание работы операторов: индивидуальные KPI, рейтинги, динамика времени обработки, решение с первого звонка в разрезе оператора
- —Установка одной командой:
curl -fsSL https://api.astervis.io/api/releases/install.sh | bash— запуск меньше чем за 5 минут - —Self-hosted: данные остаются в вашей инфраструктуре. Изначально дружелюбно к GDPR.
- —Интеграция с CRM: нативные коннекторы Bitrix24 и AmoCRM — история клиента прямо во время разговора
- —Прослушивание записей: слушайте записи разговоров прямо в аналитическом дашборде
- —Современный стек: TimescaleDB для аналитики временных рядов, а не легаси-базы
- —14 дней бесплатно: без привязки карты
Как выбрать подход
Матрица решения:
| Подход | Время внедрения | Реальное время | История | Оповещения | Стоимость | Кому подходит |
|---|---|---|---|---|---|---|
| CLI-команды | 0 мин | Снимок | Нет | Нет | Бесплатно | Быстрая диагностика |
| Скрипт на AMI | 20+ ч | Да | Своими силами | Своими силами | Бесплатно | Разработчикам, пишущим свои инструменты |
| Разбор queue_log | 5+ ч | Нет | Базовая | Нет | Бесплатно | Простых проверок по истории |
| CDR/CEL + Grafana | 40–80 ч | Частично | Да | Своими силами | Бесплатно | Командам с инженерным ресурсом |
| QPanel | 1–2 ч | Да | Нет | Нет | Бесплатно | Только базового отображения в реальном времени |
| QueueMetrics | 2–4 ч | Да | Да | Да | $$$ | Легаси-окружений с большим бюджетом |
| Astervis | 5 мин | Да | Да | Да | от $119/мес | Промышленных колл-центров |
Настройка мониторинга в реальном времени на Astervis
Если хотите пройти путь от нуля до полноценного мониторинга очередей меньше чем за 10 минут — вот маршрут:
Шаг 1: установите Astervis
На сервере Asterisk (или на отдельном сервере мониторинга с доступом к AMI):
curl -fsSL https://api.astervis.io/api/releases/install.sh | bashИнсталлятор сам определит конфигурацию Asterisk, развернёт базу данных и запустит службу мониторинга.
Шаг 2: настройте подключение к AMI
Убедитесь, что AMI включён в /etc/asterisk/manager.conf (см. Способ 2 выше). Astervis нужен доступ на чтение событий agent, call и reporting.
Шаг 3: откройте дашборд
Откройте в браузере http://your-server:3000. Вы сразу увидите:
- —Состояние очередей вживую: звонки в ожидании, свободные операторы, текущее время ожидания
- —Тепловую карту: распределение нагрузки по часам и дням недели
- —Дашборд операторов: кто на линии, кто свободен, кто на паузе
- —Контроль SLA: service level в реальном времени относительно ваших целей
- —Загрузку транков: активные каналы по каждому транку
Шаг 4: настройте оповещения (опционально)
Настройте уведомления на случай, когда:
- —Время ожидания в очереди превысило порог (например, 60 секунд)
- —Доля потерянных звонков резко выросла
- —Все операторы недоступны
- —Загрузка транка выше 80 %
Ключевые метрики
Когда мониторинг в реальном времени заработал, сосредоточьтесь на этих KPI очередей:
Service Level (SL)
Формула: (Звонки, отвеченные в пределах целевого времени / Всего звонков) × 100
Отраслевой стандарт — 80/20 (80 % звонков отвечены за 20 секунд). Следите за этим в реальном времени, чтобы ловить нарушения SLA до того, как они накопятся.
Average Speed of Answer (ASA)
Формула: Суммарное время ожидания по отвеченным звонкам / Количество отвеченных звонков
Ориентир: до 30 секунд для большинства колл-центров. Если ASA растёт в течение дня, значит в очереди не хватает операторов.
Доля потерянных звонков (Abandonment Rate)
Формула: (Потерянные звонки / Всего звонков, попавших в очередь) × 100
Ориентир: до 5 %. Показатель выше 8 % обычно говорит о нехватке персонала или проблемах с маршрутизацией.
Загруженность оператора (Occupancy)
Формула: (Суммарное время обработки / Суммарное время в системе) × 100
Ориентир: 75–85 %. Ниже 70 % — персонала слишком много. Выше 90 % — выгорание и падение качества.
First Call Resolution (FCR)
Отслеживайте, сколько обращений решается без повторных звонков и переводов. Для этого нужен учёт результата звонка — такая функция есть в продвинутых платформах вроде Astervis, которые совмещают данные CDR с метриками очередей.
Лучшие практики мониторинга очередей Asterisk
- —
Мониторьте круглосуточно, а не только в рабочие часы: звонки в нерабочее время часто вскрывают проблемы с транками, неверно настроенные failover-сценарии или неожиданные всплески обращений.
- —
Сначала соберите базовые показатели: перед настройкой порогов оповещений понаблюдайте 2 недели. У каждого колл-центра своя «норма».
- —
Используйте тепловые карты для планирования смен: мониторинг в реальном времени — про настоящее, а тепловые карты показывают закономерности для будущего планирования персонала.
- —
Смотрите на динамику, а не только на снимок: очередь с тремя ожидающими — это нормально, если она рассасывается, и тревожно, если растёт. Хороший мониторинг показывает и то и другое.
- —
Сопоставляйте метрики очередей с качеством связи: время ожидания ничего не значит, если в разговоре проблемы со звуком. Следите за обоими сразу.
- —
Разбор — еженедельно, оптимизация — ежемесячно: используйте историю для еженедельных разборов с командой и ежемесячной оптимизации процессов.
Заключение
Мониторинг очередей Asterisk в реальном времени — не опция для серьёзного колл-центра, а разница между управлением на опережение и постоянным тушением пожаров.
Если начинаете с нуля, обходите DIY-подходы стороной, пока у вас нет выделенных инженеров. Современные инструменты вроде Astervis дают 30+ графиков в реальном времени, отслеживание работы операторов и интеграцию с CRM — всё на вашей инфраструктуре — меньше чем за 10 минут.
Начните бесплатный 14-дневный триал — карта не нужна. Посмотрите, что на самом деле происходит в ваших очередях Asterisk.
Работаете на FreePBX? Читайте наше руководство: FreePBX Call Center Reporting: как получить аналитику в реальном времени
Сравниваете инструменты? Читайте: Лучшие инструменты мониторинга Asterisk в 2026 году
Хватит гадать. Начни видеть.
Реальная картина вашего Asterisk колл-центра: время ожидания, активность операторов, нагрузка на транки и 30+ графиков. On-premise на вашем сервере. Установка за 5 минут. Без карты.
От $119/мес flat. Без ограничения на операторов. Триал 14 дней.