SIP-транки — это артерии вашей АТС на Asterisk. Через них проходит каждый входящий и исходящий звонок. Когда транк падает или начинает деградировать, весь колл-центр встаёт — а вы можете даже не узнать об этом, пока не начнут жаловаться клиенты.
Большинство администраторов Asterisk узнают о проблемах с транками постфактум: пользователь сообщает об одностороннем звуке, звонки на конкретное направление перестают проходить или провайдер присылает гневное письмо про шторм регистраций. К этому моменту вы уже потеряли деньги, доверие клиентов и часы на диагностику вслепую.
В этом руководстве разберём, как мониторить SIP-транки проактивно — в реальном времени — чтобы ловить проблемы до того, как они затронут хотя бы один звонок.
Зачем нужен мониторинг SIP-транков
Через SIP-транки проходит 100% внешнего голосового трафика. В отличие от внутренних номеров, где сбой затрагивает одного пользователя, отказ транка бьёт по всем сразу. Вот что стоит на кону:
| Риск | Влияние на бизнес | Обнаружение без мониторинга |
|---|---|---|
| Потеря регистрации транка | Все исходящие звонки не проходят | От минут до часов |
| Деградация качества (jitter/потери) | Рваный звук, обрывы звонков | Жалобы клиентов |
| Исчерпание ёмкости | Короткие гудки, звонки в очереди | Всплеск потерянных вызовов |
| Односторонний звук (проблема NAT) | Клиенты не слышат операторов | Единичные жалобы на звонки |
| Авария у провайдера | Полное отсутствие связи | Уведомление извне |
| Телефонное мошенничество | Огромные неожиданные счета | Шок от счёта в конце месяца |
Простой SIP-транка в колл-центре на 50 рабочих мест обходится в среднем в $5 000–$15 000 в час — это потерянная производительность и упущенная выручка. Мониторинг в реальном времени сокращает среднее время обнаружения (MTTD) с часов до секунд.
Что мониторить: 5 столпов здоровья SIP-транка
Полноценный мониторинг транков закрывает пять критичных направлений.
1. Статус регистрации
Самая базовая проверка: зарегистрирован ли ваш транк у провайдера? В Asterisk статус регистрации показывает, может ли АТС принимать и совершать звонки через конкретный транк.
Ключевые состояния:
- —Registered — транк активен и готов к работе
- —Unregistered — регистрация потеряна (звонки не пройдут)
- —Request Sent — попытка регистрации в процессе
- —Auth Sent — получен запрос аутентификации
- —Rejected — провайдер отклонил регистрацию (неверные учётные данные, блокировка по IP)
- —No Authentication Required — транк по IP, регистрация не нужна
Команды CLI:
Для chan_sip:
asterisk -rx "sip show registry"
# Output:
# Host Username Refresh State Reg.Time
# provider.com mytrunk 105 Registered Thu, 19 Mar 2026 06:00:01Для chan_pjsip (современный Asterisk 16+):
asterisk -rx "pjsip show registrations"
# Output:
# <Registration/ServerURI> <Auth> <Status>
# trunk-provider/sip:provider.com trunk-auth RegisteredНа что настраивать алерт: любой переход из состояния «Registered» должен немедленно поднимать тревогу. Сбои регистрации — это, как правило, первый симптом проблем с учётными данными, сетью или аварии у провайдера.
2. Метрики качества связи (RTP)
Статус «OK» у регистрации ещё не значит, что звонки звучат хорошо. Метрики RTP (Real-time Protocol) показывают реальное качество голоса, которое слышат ваши абоненты.
Критичные метрики:
| Метрика | Норма | Деградация | Критично | Влияние |
|---|---|---|---|---|
| Задержка (в одну сторону) | < 150 мс | 150–300 мс | > 300 мс | Паузы в разговоре, перебивание |
| Jitter | < 20 мс | 20–50 мс | > 50 мс | Рваный звук, «робот» в голосе |
| Потери пакетов | < 0,5% | 0,5–2% | > 2% | Пропадают слова, провалы в звуке |
| MOS (Mean Opinion Score) | > 4,0 | 3,5–4,0 | < 3,5 | Воспринимаемое качество голоса (1–5) |
| R-Factor | > 80 | 70–80 | < 70 | Оценка качества по ITU-T G.107 |
Как измерять в Asterisk:
# Статистика RTP по активному звонку
asterisk -rx "rtp show stats"
# Для каналов PJSIP — качество по каждому каналу
asterisk -rx "pjsip show channels"
# Затем по конкретному каналу:
asterisk -rx "core show channel PJSIP/trunk-provider-00000042"RTCP (Real-Time Control Protocol) отдаёт обратную связь по качеству прямо во время разговора. Включите его в конфигурации PJSIP:
; pjsip.conf
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0:5060
[trunk-provider]
type = endpoint
transport = transport-udp
; Включаем RTCP для метрик качества
rtcp_mux = no3. Загрузка и ёмкость транка
У каждого SIP-транка есть лимит каналов — максимум одновременных разговоров. Упёрлись в лимит — новые звонки получают короткие гудки или молча срываются.
Что отслеживать:
- —Активные каналы — сколько разговоров идёт через транк прямо сейчас
- —Пиковые каналы — максимум одновременных звонков за период
- —Лимит каналов — ваш контрактный или настроенный максимум
- —Процент загрузки — активные / лимит × 100
Мониторинг через AMI (Asterisk Manager Interface):
#!/usr/bin/env python3
"""Мониторинг загрузки SIP-транков в реальном времени через AMI"""
import socket
import re
import time
AMI_HOST = "127.0.0.1"
AMI_PORT = 5038
AMI_USER = "monitor"
AMI_SECRET = "your_ami_password"
def ami_command(sock, action, **params):
"""Отправить действие AMI и прочитать ответ"""
cmd = f"Action: {action}\r\n"
for k, v in params.items():
cmd += f"{k}: {v}\r\n"
cmd += "\r\n"
sock.send(cmd.encode())
time.sleep(0.5)
return sock.recv(65536).decode()
def get_trunk_channels(sock, trunk_name):
"""Посчитать активные каналы конкретного транка"""
response = ami_command(sock, "Command",
Command=f"core show channels concise")
channels = [l for l in response.split('\n')
if trunk_name in l and '!' in l]
return len(channels)
def monitor_trunks():
"""Основной цикл мониторинга"""
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((AMI_HOST, AMI_PORT))
sock.recv(1024) # Приветственное сообщение
# Авторизация
ami_command(sock, "Login",
Username=AMI_USER, Secret=AMI_SECRET)
trunks = {
"provider-a": {"limit": 30, "warn": 0.8},
"provider-b": {"limit": 60, "warn": 0.75},
}
while True:
for name, config in trunks.items():
active = get_trunk_channels(sock, name)
util = active / config["limit"] * 100
status = "OK"
if util >= 95:
status = "CRITICAL"
elif util >= config["warn"] * 100:
status = "WARNING"
print(f"[{time.strftime('%H:%M:%S')}] {name}: "
f"{active}/{config['limit']} ({util:.0f}%) [{status}]")
time.sleep(10) # Опрос каждые 10 секунд
if __name__ == "__main__":
monitor_trunks()Практическое правило по планированию ёмкости: если в часы пик транк регулярно уходит выше 70% загрузки, пора добавлять каналы. Транк, работающий на 90%+, гарантированно даст заметные сбои звонков.
4. Доля успешных вызовов (ASR и NER)
Голый объём звонков ничего не значит, пока вы не понимаете, сколько из них реально соединилось.
Ключевые коэффициенты:
- —
ASR (Answer Seizure Ratio) = отвеченные звонки / все попытки × 100
- —Норма: > 50% (зависит от типа трафика)
- —Исходящие продажи: 20–40% — это нормально
- —Входящая поддержка: ожидается > 95%
- —
NER (Network Effectiveness Ratio) = (отвеченные + занято + без ответа) / всего × 100
- —Норма: > 95%
- —Ниже 90% — признак проблем с сетью или транком
- —
SER (SIP Error Rate) = ответы 4xx/5xx/6xx / всего × 100
- —Норма: < 2%
- —Выше 5% — нужно разбираться
SQL-запросы для анализа по CDR:
-- ASR и NER по транкам (за последние 24 часа)
SELECT
dstchannel AS trunk,
COUNT(*) AS total_calls,
COUNT(*) FILTER (WHERE disposition = 'ANSWERED') AS answered,
ROUND(
COUNT(*) FILTER (WHERE disposition = 'ANSWERED')::numeric
/ NULLIF(COUNT(*), 0) * 100, 1
) AS asr_pct,
ROUND(
COUNT(*) FILTER (WHERE disposition IN ('ANSWERED', 'BUSY', 'NO ANSWER'))::numeric
/ NULLIF(COUNT(*), 0) * 100, 1
) AS ner_pct,
ROUND(
COUNT(*) FILTER (WHERE disposition = 'FAILED')::numeric
/ NULLIF(COUNT(*), 0) * 100, 1
) AS fail_pct
FROM cdr
WHERE calldate >= NOW() - INTERVAL '24 hours'
AND dstchannel LIKE 'PJSIP/trunk%'
GROUP BY dstchannel
ORDER BY total_calls DESC;
-- Почасовая динамика ASR по конкретному транку
SELECT
DATE_TRUNC('hour', calldate) AS hour,
COUNT(*) AS attempts,
COUNT(*) FILTER (WHERE disposition = 'ANSWERED') AS answered,
ROUND(
COUNT(*) FILTER (WHERE disposition = 'ANSWERED')::numeric
/ NULLIF(COUNT(*), 0) * 100, 1
) AS asr_pct
FROM cdr
WHERE calldate >= NOW() - INTERVAL '7 days'
AND dstchannel LIKE 'PJSIP/trunk-provider%'
GROUP BY DATE_TRUNC('hour', calldate)
ORDER BY hour DESC
LIMIT 168; -- 7 дней почасовых данных
-- Разбивка по кодам ответа SIP (нужен расширенный CDR или CEL)
SELECT
hangupcause AS sip_code,
COUNT(*) AS occurrences,
ROUND(COUNT(*)::numeric / SUM(COUNT(*)) OVER () * 100, 1) AS pct
FROM cdr
WHERE calldate >= NOW() - INTERVAL '24 hours'
AND dstchannel LIKE 'PJSIP/trunk%'
AND disposition = 'FAILED'
GROUP BY hangupcause
ORDER BY occurrences DESC;5. Безопасность и выявление аномалий
SIP-транки — излюбленная мишень телефонных мошенников. Взломав ваш транк, злоумышленники за считаные минуты накручивают тысячи долларов международных звонков.
За чем следить:
- —Звонки на премиум-номера (900, международный премиум)
- —Аномальные всплески трафика (в 10 раз выше обычного)
- —Звонки в нерабочее время на неожиданные направления
- —Попытки регистрации с незнакомых IP
- —Шквал INVITE подряд (DoS-атаки)
Запрос для выявления фрода:
-- Подозрительные паттерны международных звонков (за последние 6 часов)
SELECT
src,
dst,
COUNT(*) AS call_count,
SUM(billsec) AS total_seconds,
ROUND(SUM(billsec) / 60.0, 1) AS total_minutes
FROM cdr
WHERE calldate >= NOW() - INTERVAL '6 hours'
AND dstchannel LIKE 'PJSIP/trunk%'
AND LENGTH(dst) > 10 -- Международный формат
AND dst NOT LIKE '1%' -- Исключаем локальные (подстройте под свою страну)
GROUP BY src, dst
HAVING COUNT(*) > 5
ORDER BY total_seconds DESC;Способы мониторинга в реальном времени
Способ 1: Asterisk CLI (вручную)
Годится для быстрых точечных проверок. Для постоянного мониторинга не подходит.
# Все регистрации транков одним взглядом
asterisk -rx "pjsip show registrations"
# Текущие звонки через конкретный транк
asterisk -rx "core show channels" | grep "trunk-provider"
# Состояние эндпоинта транка
asterisk -rx "pjsip show endpoint trunk-provider"
# Количество активных каналов
asterisk -rx "core show channels count"Способ 2: подписка на события AMI (программно)
Asterisk Manager Interface отдаёт события в реальном времени по каждому звонку, изменению регистрации и смене состояния канала. На этом построено большинство систем мониторинга.
Ключевые события для мониторинга транков:
| Событие AMI | Что оно сообщает |
|---|---|
Registry | Изменился статус регистрации транка |
Newchannel | На транке начался новый звонок |
Hangup | Звонок завершён (с кодом причины) |
PeerStatus | Изменилась доступность SIP-пира |
RTCPReceived | Обновились метрики качества связи |
ChanDestroyed | Канал уничтожен (ресурс освобождён) |
ChallengeSent | Отправлен запрос аутентификации (безопасность) |
Конфигурация AMI (manager.conf):
[general]
enabled = yes
port = 5038
bindaddr = 127.0.0.1 ; Только локальный доступ
[monitor]
secret = your_strong_password
deny = 0.0.0.0/0.0.0.0
permit = 127.0.0.1/255.255.255.0
read = system,call,reporting
write = commandСкрипт мониторинга на событиях:
#!/usr/bin/env python3
"""
Событийный мониторинг SIP-транков через AMI.
Подписывается на события в реальном времени и следит за здоровьем транков.
"""
import socket
import re
from collections import defaultdict
from datetime import datetime
class TrunkMonitor:
def __init__(self, host="127.0.0.1", port=5038):
self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
self.sock.connect((host, port))
self.sock.recv(1024)
self.trunk_channels = defaultdict(int)
self.trunk_calls_total = defaultdict(int)
self.trunk_calls_failed = defaultdict(int)
self.registration_status = {}
def login(self, user, secret):
self._send(f"Action: Login\r\nUsername: {user}\r\n"
f"Secret: {secret}\r\nEvents: on\r\n\r\n")
return self._read()
def _send(self, msg):
self.sock.send(msg.encode())
def _read(self):
data = b""
while True:
chunk = self.sock.recv(4096)
data += chunk
if b"\r\n\r\n" in data:
break
return data.decode()
def process_events(self):
"""Главный цикл — обработка событий AMI в реальном времени"""
buffer = ""
while True:
data = self.sock.recv(4096).decode()
buffer += data
while "\r\n\r\n" in buffer:
event_text, buffer = buffer.split("\r\n\r\n", 1)
event = self._parse_event(event_text)
if event.get("Event") == "Registry":
self._handle_registry(event)
elif event.get("Event") == "Newchannel":
self._handle_new_channel(event)
elif event.get("Event") == "Hangup":
self._handle_hangup(event)
elif event.get("Event") == "PeerStatus":
self._handle_peer_status(event)
def _parse_event(self, text):
event = {}
for line in text.strip().split("\r\n"):
if ": " in line:
key, val = line.split(": ", 1)
event[key] = val
return event
def _handle_registry(self, event):
trunk = event.get("Username", "unknown")
status = event.get("Status", "unknown")
old_status = self.registration_status.get(trunk)
self.registration_status[trunk] = status
if old_status and old_status != status:
ts = datetime.now().strftime("%H:%M:%S")
print(f"[{ts}] REGISTRATION CHANGE: {trunk} "
f"{old_status} -> {status}")
if status != "Registered":
print(f" *** ALERT: Trunk {trunk} lost registration!")
def _handle_new_channel(self, event):
channel = event.get("Channel", "")
for trunk in self.trunk_channels:
if trunk in channel:
self.trunk_channels[trunk] += 1
self.trunk_calls_total[trunk] += 1
def _handle_hangup(self, event):
channel = event.get("Channel", "")
cause = event.get("Cause", "0")
for trunk in self.trunk_channels:
if trunk in channel:
self.trunk_channels[trunk] = max(0,
self.trunk_channels[trunk] - 1)
if cause not in ("16", "17", "18", "19"):
self.trunk_calls_failed[trunk] += 1
def _handle_peer_status(self, event):
peer = event.get("Peer", "")
status = event.get("PeerStatus", "")
ts = datetime.now().strftime("%H:%M:%S")
print(f"[{ts}] PEER STATUS: {peer} -> {status}")
if __name__ == "__main__":
monitor = TrunkMonitor()
monitor.login("monitor", "your_strong_password")
monitor.trunk_channels["trunk-provider-a"] = 0
monitor.trunk_channels["trunk-provider-b"] = 0
print("Monitoring SIP trunks... Press Ctrl+C to stop.")
monitor.process_events()Способ 3: SNMP + внешний мониторинг (Nagios/Zabbix)
Вариант для компаний, у которых уже развёрнута система мониторинга. Модуль Asterisk res_snmp отдаёт метрики транков по SNMP.
Включаем SNMP в Asterisk:
; res_snmp.conf
[general]
subagent = yes
enabled = yes# Загружаем модуль SNMP
asterisk -rx "module load res_snmp"
# Проверяем SNMP-запрос
snmpwalk -v2c -c public localhost .1.3.6.1.4.1.22736Скрипт проверки для Nagios:
#!/bin/bash
# check_asterisk_trunk.sh - плагин Nagios для мониторинга транков
# Использование: check_asterisk_trunk.sh <trunk_name> <warn_channels> <crit_channels>
TRUNK=$1
WARN=${2:-20}
CRIT=${3:-28}
# Получаем количество активных каналов транка
CHANNELS=$(asterisk -rx "core show channels concise" 2>/dev/null | grep -c "$TRUNK")
REGISTERED=$(asterisk -rx "pjsip show registrations" 2>/dev/null | grep "$TRUNK" | grep -c "Registered")
if [ "$REGISTERED" -eq 0 ]; then
echo "CRITICAL - Trunk $TRUNK not registered | channels=$CHANNELS"
exit 2
fi
if [ "$CHANNELS" -ge "$CRIT" ]; then
echo "CRITICAL - Trunk $TRUNK: $CHANNELS active channels (>=$CRIT) | channels=$CHANNELS"
exit 2
elif [ "$CHANNELS" -ge "$WARN" ]; then
echo "WARNING - Trunk $TRUNK: $CHANNELS active channels (>=$WARN) | channels=$CHANNELS"
exit 1
else
echo "OK - Trunk $TRUNK: Registered, $CHANNELS active channels | channels=$CHANNELS"
exit 0
fiСпособ 4: Prometheus + Grafana (современный стек)
Выгружаем метрики Asterisk в Prometheus и визуализируем в Grafana. Готовое решение даёт проект asterisk_exporter.
# docker-compose.yml для стека мониторинга транков Asterisk
version: '3.8'
services:
asterisk-exporter:
image: ghcr.io/cswiger/asterisk_exporter:latest
environment:
AMI_HOST: host.docker.internal
AMI_PORT: 5038
AMI_USER: monitor
AMI_SECRET: your_password
ports:
- "9200:9200"
prometheus:
image: prom/prometheus:latest
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
ports:
- "9090:9090"
grafana:
image: grafana/grafana:latest
environment:
GF_SECURITY_ADMIN_PASSWORD: admin
ports:
- "3000:3000"# prometheus.yml
scrape_configs:
- job_name: 'asterisk'
scrape_interval: 15s
static_configs:
- targets: ['asterisk-exporter:9200']Такой подход требует серьёзной настройки и постоянного сопровождения: поднять экспортеры, написать запросы PromQL, собрать дашборды, настроить правила алертинга. Небольшой команде специализированное решение вроде Astervis снимает эту сложность целиком.
Устали угадывать, что происходит в очередях?
Astervis даёт 30+ реалтайм-графиков, KPI операторов и CRM-интеграцию для вашего Asterisk PBX. On-premise. Установка за 5 минут. От $119/мес flat — без ограничения на операторов.
Способ 5: Astervis — аналитика, созданная под Asterisk
Astervis даёт мониторинг SIP-транков в реальном времени из коробки, без настройки:
Что вы получаете сразу после установки:
- —Живой дашборд состояния транков — статус регистрации, активные каналы и загрузка по каждому транку, обновление в реальном времени
- —Тепловые карты качества связи — видно, в какие часы и дни качество проседает
- —Отслеживание ASR/NER — автоматический расчёт с графиками динамики и оповещениями
- —Алерты по ёмкости транков — предупреждение до того, как вы упрётесь в лимит каналов
- —Аналитика CDR по каждому транку — детализация по паттернам звонков, часам пик и доле сбоев
- —30+ готовых графиков — без PromQL, без сборки дашбордов, без написания запросов
- —Эффективность операторов в связке с маршрутизацией по транкам — видно, какими транками пользуются ваши лучшие операторы
- —Интеграция с CRM — сопоставляйте работу транков с удовлетворённостью клиентов (Bitrix24, AmoCRM)
Установка:
curl -fsSL https://api.astervis.io/api/releases/install.sh | bashОдна команда. Пять минут. Полноценный мониторинг транков. Начать бесплатный 14-дневный период →
Как собрать дашборд мониторинга транков
Каким бы инструментом вы ни пользовались, дашборд мониторинга транков должен с одного взгляда отвечать на следующие вопросы.
Wallboard (реальное время)
| Виджет | Частота обновления | Назначение |
|---|---|---|
| Статус регистрации (все транки) | 10 секунд | Мгновенное обнаружение аварии |
| Активные каналы по транкам | 5 секунд | Контроль ёмкости |
| Шкала загрузки (%) | 5 секунд | Предупреждение о нехватке каналов |
| Качество связи вживую (MOS/jitter) | По каждому звонку | Деградация качества |
| Неуспешные звонки (за 15 минут) | 30 секунд | Отслеживание тренда |
Операционный дашборд (почасовой)
| Виджет | Содержание |
|---|---|
| Динамика ASR (24 ч) | Линейный график по транкам |
| Тепловая карта загрузки каналов | Матрица «транк × час» |
| Топ направлений со сбоями | Столбчатая диаграмма проблемных номеров |
| Распределение оценок качества | Гистограмма значений MOS |
| Сравнение провайдеров | Метрики транков бок о бок |
Стратегический дашборд (неделя/месяц)
| Виджет | Содержание |
|---|---|
| Стоимость по транкам | Затраты против объёма звонков |
| Рейтинг надёжности | У какого провайдера лучший uptime |
| Прогноз по ёмкости | Когда понадобятся дополнительные каналы |
| Динамика качества | Тренд MOS по месяцам |
| Расчёт ROI | Экономия за счёт мониторинга |
Типичные проблемы SIP-транков и как их обнаружить
Проблема 1: тихие сбои регистрации
Симптомы: исходящие звонки не проходят, но в консоли Asterisk никаких ошибок.
Как обнаружить:
# Проверяем, действительно ли регистрация актуальна
asterisk -rx "pjsip show registrations" | grep -v "Registered"
# Ищем ошибки регистрации в логах
grep "Registration .* failed" /var/log/asterisk/messages | tail -20Первопричины:
- —Провайдер сменил учётные данные без предупреждения
- —Изменился IP-адрес (динамический IP без DynDNS)
- —Файрвол провайдера блокирует ваш новый IP
- —Истёк срок действия TLS-сертификата
Проблема 2: постепенная деградация качества
Симптомы: пользователи говорят, что «звонки стали хуже звучать», но когда это началось — сказать не могут.
Как обнаружить:
-- Динамика MOS по неделям
SELECT
DATE_TRUNC('week', calldate) AS week,
ROUND(AVG(
CASE
WHEN billsec > 0 THEN
4.5 - (0.01 * EXTRACT(EPOCH FROM (end_time - answer_time) - billsec))
ELSE NULL
END
), 2) AS avg_estimated_mos,
COUNT(*) AS calls
FROM cdr
WHERE calldate >= NOW() - INTERVAL '90 days'
AND dstchannel LIKE 'PJSIP/trunk%'
AND disposition = 'ANSWERED'
GROUP BY DATE_TRUNC('week', calldate)
ORDER BY week;Первопричины:
- —Интернет-провайдер изменил маршруты
- —Провайдер связи перепродал ёмкость
- —Деградация сетевого оборудования
- —Согласование кодеков откатывается на менее качественный
Проблема 3: исчерпание ёмкости транка
Симптомы: в часы пик часть звонков срывается, но далеко не все.
Как обнаружить:
-- Находим пик одновременных звонков по часам
SELECT
DATE_TRUNC('hour', calldate) AS hour,
MAX(concurrent) AS peak_concurrent
FROM (
SELECT
calldate,
COUNT(*) OVER (
ORDER BY calldate
RANGE BETWEEN INTERVAL '0 seconds' PRECEDING
AND INTERVAL '0 seconds' FOLLOWING
) AS concurrent
FROM cdr
WHERE calldate >= NOW() - INTERVAL '7 days'
AND dstchannel LIKE 'PJSIP/trunk%'
) sub
GROUP BY DATE_TRUNC('hour', calldate)
ORDER BY peak_concurrent DESC
LIMIT 24;Решение: настройте алерты по загрузке на порогах 70% и 90%. Если 70% в часы пик срабатывает регулярно — пора заниматься планированием ёмкости.
Проблема 4: телефонное мошенничество прямо сейчас
Симптомы: неожиданные международные звонки, особенно в нерабочее время.
Как обнаружить:
# В реальном времени: ловим международные звонки вне рабочих часов
asterisk -rx "core show channels concise" | \
awk -F'!' '{print $1, $7}' | \
grep -E '\+?(9[0-9]{2}|00[0-9]{3})' Немедленная реакция:
# Мгновенно блокируем транк
asterisk -rx "pjsip set endpoint trunk-name max_channels 0"
# Или разрываем все каналы транка
asterisk -rx "channel request hangup all"Чек-лист: настраиваем мониторинг с нуля
Пройдите по шагам, чтобы внедрить мониторинг транков.
Шаг 1. Проведите инвентаризацию транков
# Выводим все настроенные транки
asterisk -rx "pjsip show endpoints" | grep -E "Endpoint:|Contact:"
# Или для chan_sip:
asterisk -rx "sip show peers" | grep -v "^Name\|--\|^$"Шаг 2. Включите сбор метрик качества
; pjsip.conf - добавьте к каждому эндпоинту транка
[trunk-provider]
type = endpoint
; ... существующая конфигурация ...
allow = !all,opus,g722,ulaw,alaw ; Приоритет качественным кодекам
trust_id_inbound = yes
send_rpid = yesШаг 3. Настройте доступ AMI для мониторинга
; manager.conf
[monitor]
secret = strong_random_password_here
deny = 0.0.0.0/0.0.0.0
permit = 127.0.0.1/255.255.255.0
read = system,call,reporting
write = commandШаг 4. Настройте запись CDR в базу
; cdr.conf
[general]
enable = yes
unanswered = yes ; Пишем и неотвеченные звонки
congestion = yes
; cdr_adaptive_odbc.conf или cdr_pgsql.conf
[global]
connection = asterisk
table = cdrШаг 5. Внедрите мониторинг (выберите путь)
- —Быстро и просто: Astervis —
curl -fsSL https://api.astervis.io/api/releases/install.sh | bash(5 минут) - —Своими руками + Grafana: экспортер Prometheus + собственные дашборды (2–3 дня)
- —Enterprise: интеграция SNMP + Nagios/Zabbix (1–2 дня при наличии опыта)
Шаг 6. Настройте оповещения
Задайте пороги для следующих событий:
- —Изменение статуса регистрации → немедленный алерт
- —Загрузка > 70% → предупреждение
- —Загрузка > 90% → критично
- —Падение ASR более чем на 10% от базового уровня → предупреждение
- —MOS < 3,5 → алерт по качеству
- —Международные звонки вне рабочих часов → алерт о фроде
Шаг 7. Проверьте, что мониторинг работает
# Имитируем сбой регистрации (осторожно — транк отключится!)
# Делайте это только в технологическое окно
asterisk -rx "pjsip send unregister trunk-provider"
# Убеждаемся, что алерт сработал, и регистрируемся заново
asterisk -rx "pjsip send register trunk-provider"Сравнение подходов к мониторингу SIP-транков
| Возможность | CLI/скрипты | Grafana+Prometheus | Nagios/Zabbix | Astervis |
|---|---|---|---|---|
| Время внедрения | Минуты | 2–3 дня | 1–2 дня | 5 минут |
| Обновление в реальном времени | Ручное обновление | Интервал 15 с | Опрос раз в 1–5 мин | Живое (WebSocket) |
| Алерты по регистрации | Свой скрипт | Свои правила | Нужен плагин | Из коробки |
| Метрики качества связи | Ограниченно | С экспортером RTP | Только SNMP | Полный анализ RTP |
| Контроль ёмкости | grep + подсчёт | Свой PromQL | Своя проверка | Автоматически |
| Расчёт ASR/NER | SQL-запросы | Свои дашборды | Нет из коробки | Готовые графики |
| Выявление фрода | Вручную | Свои правила | Свои правила | Детекция аномалий |
| Связка с операторами | Невозможно | Сложные JOIN | Нет из коробки | Нативная интеграция |
| Интеграция с CRM | Невозможно | Невозможно | Нет из коробки | Bitrix24, AmoCRM |
| Сопровождение | Высокое | Среднее | Среднее | Нулевое (как SaaS) |
| Стоимость | Бесплатно (+ время) | Бесплатно (+ время) | Зависит от лицензии | От $119/мес |
Главное
- —
Закрывайте все пять столпов: регистрацию, качество, ёмкость, долю успешных вызовов и безопасность. Пропустили один — получили слепую зону.
- —
Реальное время лучше опроса по расписанию: подписка на события AMI ловит проблемы за секунды, а периодические проверки легко пропускают плавающие сбои.
- —
Сначала снимите базовые показатели: соберите неделю данных в нормальном режиме, прежде чем выставлять пороги алертов. Каждая инсталляция уникальна.
- —
Автоматизируйте реакцию: не ограничивайтесь оповещением — держите runbook на каждый сценарий. А лучше автоматизируйте переключение на резервные транки.
- —
Связывайте с бизнес-метриками: «авария транка» — это просто цифра. «47 клиентов не смогли дозвониться в поддержку из-за сбоя транка» — это бизнес-эффект, под который выделяют бюджет.
- —
Начинайте с простого и наращивайте: стартуйте с проверок регистрации и базовой загрузки. Метрики качества и детекцию фрода добавите по мере зрелости.
Соберёте ли вы свой стек мониторинга или возьмёте специализированный инструмент вроде Astervis — главное начать мониторить уже сегодня. Каждый день без видимости по транкам — это день, когда вы играете в рулетку с надёжностью своего колл-центра.
Хотите видеть свои SIP-транки в реальном времени? Попробуйте Astervis бесплатно 14 дней →
Хватит гадать. Начни видеть.
Реальная картина вашего Asterisk колл-центра: время ожидания, активность операторов, нагрузка на транки и 30+ графиков. On-premise на вашем сервере. Установка за 5 минут. Без карты.
От $119/мес flat. Без ограничения на операторов. Триал 14 дней.