Мониторинг и выявление узких мест

В предыдущей теме мы настроили ядро и модули для работы под нагрузкой. Но даже идеальный конфиг может «поплыть» в реальных условиях. Чтобы связь не обрывалась, нужно вовремя находить узкие места (Bottlenecks) — ресурсы, которые тормозят всю АТС.

Мы будем использовать системные метрики ОС и счетчики Asterisk. Это основа для проактивной оптимизации: вы устраняете проблему до того, как пользователи начнут жаловаться на «квакающий» голос.

Слой 1: Ресурсы операционной системы

Для VoIP-сервера в 2026 году простого top мало. Asterisk чувствителен к задержкам (latency). Если процессор занят посторонними задачами, голос пострадает первым.

Процессор и Load Average

Высокий Load Average — это не всегда занятый CPU. Часто это очередь процессов, ожидающих ответа от диска или сети.

• CPU Steal Time: Критично для виртуальных машин (VPS). Показывает, сколько ресурсов забирает гипервизор. Если значение > 1–2%, качественного голоса не будет 📉
• Context Switches: Если переключений слишком много, ядро тратит время на «перекладывание бумажек» (управление потоками), а не на обработку звонков.

Дисковая подсистема и I/O Wait

Запись разговоров — тяжелая операция. Если диск медленный, процесс Asterisk «замирает», ожидая завершения записи.

Совет: Следите за %iowait. Если он растет вместе с количеством звонков — пора переходить на NVMe или выносить запись на отдельный быстрый массив.

Метрика	Норма	Признак беды
CPU User	< 60%	Скачки до 100%
I/O Wait	< 1%	> 5% при записи MixMonitor
RAM Free	> 10%	Использование Swap — смерть для Real-time

Слой 2: Внутренние очереди Asterisk (Taskprocessors)

Внутри Asterisk задачи (обработка SIP, логирование, диалплан) передаются через очереди — Taskprocessors. Если один модуль тормозит, очередь к нему растет, вызывая лаги во всей системе.

Схема 1 показывает, как задача проходит путь от сети до модуля. Рост очередей — главный сигнал, что Asterisk перегружен «изнутри», даже если CPU свободен.

Для проверки используйте команду в консоли Asterisk: core show taskprocessors

Смотрите на колонки In Queue и Max Depth. Если там тысячи задач — вы нашли узкое место.

Пример анализа

Норма:

Processor                                  Processed   In Queue  Max Depth
pjsip/distributor-00000034                     15020          0         12

Проблема (затор):

Processor                                  Processed   In Queue  Max Depth
pjsip/distributor-00000034                     18400        542        900

В данном случае PJSIP не успевает разгребать пакеты. Причины: тяжелый диалплан, долгие запросы к базе или тормоза DNS.

Слой 3: Сетевой стек и интенсивность

Для диагностики качества важны три показателя:

1. CPS (Calls Per Second) — скорость поступления новых звонков.
2. CAPS (Call Attempt Per Second) — общая нагрузка на сигнальный трафик (включая попытки регистрации).
3. Active Channels — количество текущих разговоров.

График 1 наглядно показывает: при достижении определенного порога CPS задержки растут экспоненциально.

Алгоритм поиска проблем

Если связь «лагает», действуйте по шагам:

1. Проверьте ОС: Утилиты top, iostat, vmstat. Ищем iowait и steal time.
2. Проверьте лимиты: Команда ulimit -n. Для нагруженных систем нужно минимум 65535 открытых файлов.
3. Загляните в Asterisk: core show taskprocessors. Ищем забитые очереди.
4. Проверьте сеть: Если таблица conntrack в Linux переполнена, ядро будет отбрасывать SIP-пакеты еще до того, как их увидит Asterisk 🛡️

Этот метод — основа проактивной оптимизации. Видите рост задержек на диске? Заранее планируйте перенос базы CDR на другой сервер.

Понимать пределы текущей системы — это база. Чтобы бизнес не встал из-за нехватки ресурсов, нужно уметь прогнозировать. В следующей теме мы научимся анализировать потребности и планировать масштабирование заранее.