Как проверить связку Asterisk и amoCRM до потери звонков

Интеграцию Asterisk и amoCRM пора разбирать, если звонки пропадают из карточек, дублируются, отображаются с опозданием или операторы не видят актуальный статус. Я начинаю аудит с маршрута события от АТС до CRM, затем проверяю доступы и повторную обработку. Ниже — пять проверок, которые помогают найти границу сбоя без гадания по одному графику.

1. Как понять, что AMI подключён правильно

Первый признак — интеграция то видит события, то теряет их. Я начинаю с AMI: это TCP-интерфейс Asterisk для команд и событий, его настройки обычно находятся в /etc/asterisk/manager.conf. В документации Asterisk для AMI указан TCP-порт 5038 по умолчанию, если интерфейс включён. Это порт именно AMI, не HTTPS и не адрес amoCRM. В черновых схемах его часто заменяют на 443, потому что CRM работает через веб. Получается аккуратно нарисованная, но неверная стрелка.

У пользователя AMI задаются имя, пароль и права read для получения событий, write для выполнения действий. Для конкретной интеграции нужны только необходимые классы: read=all и write=all — не безопасный универсальный рецепт. Параметры permit и deny ограничивают адреса, которым разрешено подключаться; доступ к AMI не следует выставлять в интернет. Я сначала выясняю, откуда приходит приложение, затем ограничиваю доступ сетевым ACL и правами самого пользователя. Пароль храню отдельно от кода и логов, а не в открытом репозитории.

Проверяю конфигурацию по факту: включён ли AMI, на каком адресе и порту он слушает, проходит ли вход под отдельной учётной записью и приходят ли нужные события. Если есть доступ к CLI Asterisk, сверяю состояние интерфейса и журнал самой интеграции. Команда nc -zv доказывает только доступность TCP-порта с конкретной машины; она не проверяет пароль, ACL, права пользователя, подписку на событие или обработку ответа. Поэтому зелёный результат nc — не акт приёмки. Это только проверка двери.

На условном проекте студии «Импульс-Логистик» я бы зафиксировал три точки: время звонка в АТС, событие AMI с идентификатором канала и запись в журнале интеграционного сервиса. Если первая точка есть, а второй нет, смотрю настройки AMI и фильтры событий. Если AMI событие есть, а журнал приложения пуст, проверяю сетевой путь и авторизацию. Если приложение событие приняло, но карточка не изменилась, искать причину надо уже на стороне преобразования данных или API CRM. Такая развилка экономит часы на бессмысленном перезапуске всей телефонии.

Для настройки самой связки я привлекаю ИТ-аутсорсинг для офиса, когда важно проверить и АТС, и сетевые правила, и интеграционный сервис как одну цепочку. В нашем условном кейсе не нужно выдумывать аварию или приписывать компании потери: достаточно описать проверяемый симптом, версию установленной системы, окно наблюдения и результат тестового звонка. Я не называю отсутствие события «падением amoCRM», пока не увидел, на каком участке оно исчезло. Диагноз начинается с границы, а не с обвинения.

Наконец, сверяю адрес привязки. Службы могут слушать localhost, внутренний интерфейс или все сетевые интерфейсы — выбор зависит от архитектуры. Если интеграция стоит рядом с Asterisk, наружный доступ к AMI ей не нужен. Если приложение отдельно, открывают доступ только от его адреса, через подходящий внутренний маршрут и правила фильтрации. Не копируйте пример permit из случайной статьи: маска должна соответствовать вашей сети. Ошибка в ACL либо отрежет нужный сервис, либо превратит интерфейс управления в общедоступную точку входа.

• Уточните TCP-порт AMI; по умолчанию это 5038.
• Выдайте отдельного пользователя с минимальными правами.
• Ограничьте доступ через permit/deny и межсетевой экран.
• Проверьте событие, а не только открытый TCP-порт.

2. Почему порт 8088 не равен порту интеграции

Вторая проверка — не перепутаны ли интерфейсы и сетевые направления. У Asterisk есть AMI, ARI и встроенный HTTP-сервер; это разные механизмы. ARI использует HTTP-сервер Asterisk и настраивается через http.conf и ari.conf. В документации типовой HTTP-порт указан как 8088, но сам сервер выключен по умолчанию. Порт 8088 не является обязательным портом всякой связки с amoCRM: его открывают только тогда, когда конкретная архитектура действительно обращается к HTTP-интерфейсу Asterisk.

Есть и обратное направление: интеграционный сервис может отправлять HTTPS-запрос в API amoCRM, а CRM может вызывать настроенный вебхук на внешнем endpoint. Тогда для исходящего запроса нужен доступ к сервису назначения, а для входящего вебхука — опубликованный HTTPS endpoint интеграции. Это не означает, что надо перенаправлять порты 443 и 8088 на телефонию. Вебхук — HTTP-уведомление приложения о событии, а не команда открыть конкретный порт в роутере. Сначала рисую стрелки с инициатором соединения, адресатом и протоколом, потом меняю firewall.

Условная схема аудита выглядит просто: Asterisk передаёт событие на интеграционный сервис через выбранный интерфейс; сервис проверяет и преобразует данные; затем использует API CRM или принимает вебхук — в зависимости от того, как собрана система. Для каждого участка отдельно записываю имя сервиса, локальный порт, направление соединения и сетевое правило. Если перед Asterisk стоит reverse proxy или VPN-сегмент, это тоже отражаю на схеме, но не делаю вид, что компонент существует, пока не проверил его конфигурацию. Лишние стрелки в схеме обычно превращаются в лишние разрешения в firewall.

Я сверяю фактические параметры на установленном сервере: http show status показывает состояние встроенного HTTP-сервера, адрес и порт привязки. В http.conf проверяю enabled, bindaddr и bindport; для ARI отдельно смотрю пользователя и настройки в ari.conf. Если сервис включён на всех интерфейсах, это надо осознанно ограничить сетевыми правилами. Нельзя лечить отсутствие события советом «откройте 8088», пока не ясно, какой процесс должен подключаться к нему и откуда. Иначе диагностическая гипотеза станет постоянной дырой в периметре.

Для внешнего API CRM проверяю не порт Asterisk, а результат запроса из интеграционного сервиса: код ответа, время, текст ошибки и корреляционный идентификатор. HTTP 401/403 обычно требуют разбирать авторизацию и права; сетевой таймаут — маршрут, DNS и фильтрацию; ответ API с ошибкой валидации — содержимое запроса. Это разные классы отказов и разные владельцы проблемы. Я не обещаю, что любая ошибка решится сменой сертификата: сертификаты важны для TLS, но не исправляют неверное поле или отозванный токен.

Если amoCRM отправляет вебхук, проверьте точный URL назначения, доступность HTTPS и журнал приёма на стороне приложения. Официальная документация описывает вебхуки как уведомления сторонних приложений и отдельно описывает API управления ими. Значит, смотреть надо на настройки аккаунта и логи endpoint, а не на строки Newstate или Hangup в журнале Asterisk как на подтверждение доставки вебхука. Один компонент может быть здоров, пока следующий спокойно теряет данные. Так и появляется классическое «у нас всё зелёное», хотя карточка пустая.

• Отделите AMI на TCP 5038 от HTTP-сервера Asterisk.
• Для ARI проверьте `http.conf` и `ari.conf`.
• Зафиксируйте, кто инициирует каждый запрос.
• Смотрите коды и журналы интеграционного сервиса.

3. Какие журналы доказывают, где пропал звонок

Третий признак — запись о звонке появляется с опозданием или только после ручного обновления. Для разбора нужны журналы всех звеньев: Asterisk, интеграционного сервиса и API-обмена с CRM. В Asterisk уровни и каналы логирования задаются в logger.conf; команда core set verbose меняет уровень подробности вывода в консоль. Это не создаёт автоматически файл ami.log и не включает магическую запись всех AMI-событий. Имя файла, категории и ротация зависят от реальной конфигурации.

Временная шкала важнее объёмного лога. Для одного тестового вызова фиксирую время начала, номер тестового абонента, идентификатор канала, действие пользователя и время появления результата в CRM. В каждом компоненте записываю статус обработки и длительность. Часы серверов должны быть синхронизированы, иначе сравнение меток времени превратится в детектив с ненадёжным свидетелем. Не пишите в журнал пароли, токены OAuth, полные персональные данные и содержимое разговоров: для диагностики обычно хватает обезличенного номера теста и идентификатора события.

Я делю проверку на четыре результата: звонок виден в Asterisk; нужное событие сформировано и получено интеграцией; запрос отправлен в CRM; CRM вернула успешный ответ или понятную ошибку. Вебхуки amoCRM и API-запросы — не одно и то же действие, поэтому фиксируйте, какой поток используется. При сетевом таймауте смотрите соединение и повторную отправку. При отказе авторизации — актуальность токена и права. При ответе о неверных данных — сопоставление полей. Если в логах осталась только строка «ошибка», добавьте контекст обработки, но не секреты.

Мониторинг должен отвечать на практические вопросы: доступен ли процесс, растёт ли очередь необработанных событий, появляются ли ошибки интеграции и не заканчивается ли место под журналы. Не используйте придуманные имена метрик вроде asterisk.ami.connected как будто они встроены в Asterisk или Zabbix. Сначала выясните, какие метрики экспортирует ваш агент или шаблон, а потом создайте триггеры на реальные значения. Для небольшого офиса достаточно понятной проверки доступности и уведомления при росте ошибок; декоративная панель из десятков нулей полезна примерно как термометр в выключенном шкафу.

Логи надо ограничивать по сроку хранения и доступу. Подробная диагностика на короткое окно помогает найти причину, а постоянно включённый максимальный уровень может увеличить объём записей и раскрыть лишние данные. Я заранее определяю, кто имеет доступ к журналам и как долго они хранятся. Ротацию проверяю отдельно: наличие файла не гарантирует, что он не заполнит диск. После теста возвращаю обычный уровень логирования и оставляю только те события, которые нужны для поддержки.

На условном разборе в «Импульс-Логистик» итогом аудита должен быть не вывод «CRM тупит», а короткая цепочка доказательств: тестовый вызов создан в АТС в конкретное время; AMI-событие содержит идентификатор; сервис записал результат отправки и ответ CRM; карточка содержит ожидаемую запись. Если задержка действительно измерена, указываю интервал между точками и повторяю тест. Одного рассказа о «примерно полуминуте» недостаточно, чтобы объявить задержку постоянной или обвинить конкретную версию ПО.

• Сопоставьте время и идентификатор на каждом участке.
• Настройте логирование через фактический `logger.conf`.
• Не записывайте пароли, токены и лишние данные клиентов.
• Стройте оповещения на существующих метриках.

4. Что проверить при дублях и сбоях очереди

Четвёртый признак — одна беседа создаёт несколько записей или очередь ведёт себя не так, как ожидают операторы. Здесь часто смешивают две независимые задачи. У очереди Asterisk свои настройки в queues.conf и стратегия распределения вызовов; интеграция с CRM отдельно обрабатывает события и решает, к какой карточке их привязать. Изменение maxlen или стратегии не исправит дубли в amoCRM, как и новый идентификатор звонка не устранит перегрузку очереди.

Для диагностики очереди я сначала смотрю её фактическое состояние командой queue show: сколько вызовов ожидает, есть ли свободные участники, какова выбранная стратегия и появляются ли ошибки в журнале. Затем проверяю маршрут вызова, таймауты и поведение при занятых или недоступных агентах. rrmemory — существующая стратегия Asterisk, но она не является универсальным ускорителем и не обязана быть справедливой для конкретного расписания. Настраивать стратегию следует под правила обслуживания, а не потому, что название звучит как готовое решение.

Фраза «app_queue блокируется при любом росте нагрузки» неверна. Утверждать deadlock можно только по подтверждённым сообщениям и состоянию конкретной версии; сам факт, что стало больше звонков, этого не доказывает. Если обнаружена блокировка, сохраняю журналы, версию, конфигурацию очереди, нагрузку и точное время, после чего сверяю известные проблемы и рекомендации для этой ветки Asterisk. Не советую без разбора размножать узлы или поднимать буферы: это увеличивает число переменных и иногда делает задержку заметнее, но не устраняет причину.

В интеграционном сервисе проверяю повторную доставку. Сеть могла оборваться после того, как CRM приняла запрос, но до получения ответа. Если сервис повторит операцию без защиты от повторов, пользователь может увидеть дубль. Идемпотентность — это не обязательный заголовок amoCRM и не поле custom_fields, которое автоматически решит вопрос; это правило обработки на стороне интеграции с выбранным устойчивым ключом и проверкой результата. Конкретный способ зависит от используемого API и модели данных. Сначала фиксируем, что считается одним звонком, затем проверяем, как это правило выдерживает повтор.

Параметр persistent=yes в исходном тексте не подтверждён как универсальная настройка очереди. В документации Asterisk встречается persistentmembers=yes для сохранения динамических участников между перезапусками, это другое поведение. Оно не реплицирует вызовы между серверами и не устраняет блокировки. Здесь особенно опасна правдоподобная опечатка: строка выглядит знакомо, а администратор ожидает от неё гарантию сохранности звонков. Я удаляю обещание про «persistent и репликацию», пока не определены версия, модуль и схема отказоустойчивости. Для подробной настройки пригодится отдельная инструкция по очередям Asterisk, а в аудите я проверяю только тот параметр, который влияет на найденный симптом.

Для «Импульс-Логистик» разумный итог проверки — зафиксировать число агентов и очередей, наблюдавшийся симптом, состояние queue show, выбранную стратегию и результат повторного теста, не выдумывая тест на 200 одновременных вызовов. Если узкое место подтверждено, сначала проверяю конфигурацию маршрута и ресурсы узла в обычной нагрузке. К масштабу колл-центра из двух офисных очередей не прыгают одним советом «кластеризуйте всё». Иногда нужно поправить таймаут и расписание; иногда — разбирать программную ошибку. Выбор следует из замера.

• Посмотрите состояние через `queue show`.
• Проверьте стратегию и поведение при занятых агентах.
• Сопоставьте дубли с повторной отправкой запроса.
• Не смешивайте persistent members с репликацией очередей.

5. Как связать событие Asterisk с карточкой amoCRM

Пятый признак — звонок есть в телефонии, но CRM не понимает, к какой записи его прикрепить. В Asterisk у канала есть уникальный UniqueID; связанный вызов может включать несколько каналов, поэтому полезно учитывать и LinkedID, если он доступен в выбранном потоке событий. Это штатные идентификаторы телефонной стороны, подтверждённые документацией Asterisk. Они не превращаются автоматически в пользовательский UUID в amoCRM и не создают поле custom_fields сами по себе. Сопоставление реализует интеграционный сервис.

Проверьте, какой идентификатор приложение сохраняет при начале вызова и повторно использует при обновлении статуса или записи результата. Для каждой записи полезно иметь понятный ключ связи и журнал переходов: событие получено, обработано, отправлено, CRM ответила. Если сервис получает новый идентификатор на каждом этапе или ищет карточку только по номеру телефона, повторный звонок того же контакта может ошибочно склеиться с предыдущим, а повтор доставки — создать второй объект. Правило связи должно быть описано и проверено на сценариях: входящий, исходящий, перевод, повторный запрос и звонок без найденного контакта.

Нормализация номера помогает искать контакт, но не доказывает, что два звонка — один звонок. В одной системе номер может прийти с плюсом, в другой — с кодом страны, а внутренний номер вообще не похож на внешний. Я храню исходное значение для диагностики и отдельно применяю согласованное правило нормализации. Формат +7XXXXXXXXXX подходит не всем странам, внутренним номерам и служебным вызовам, поэтому не объявляю его обязательным для каждой интеграции. Так же осторожно обращаюсь со временем: храню временную зону явно и сравниваю события в едином формате, а не надеюсь на одинаковые настройки двух серверов.

Сторону CRM проверяю отдельно: был ли запрос авторизован, какие сущности и поля он менял, каков ответ API, не изменились ли пользовательские настройки или доступ интеграции. Документация amoCRM описывает методы API и вебхуки; формат и набор полей зависят от выбранного метода. Поэтому утверждение «amoCRM молча отбрасывает дату» без конкретного ответа сервера — догадка. Если API вернул ошибку, сохраните код и безопасно очищенное тело ответа. Если ответ успешный, а записи нет там, где её ждут, проверяйте идентификатор сущности и логику привязки. За общим фоном можно обратиться к пошаговой настройке интеграции Asterisk и CRM, а здесь я сосредоточен на признаках и границе сбоя.

Я делаю приёмочный прогон не по одному счастливому звонку, а по небольшой таблице сценариев: входящий номер известного контакта, новый номер, исходящий вызов, занято, перевод и повторное уведомление. Для каждого сценария заранее записываю ожидаемый результат: одна карточка звонка, правильное направление и время, верный контакт или отсутствие привязки, если данных недостаточно. Так проверяется поведение интеграции, а не только доступность API. Если система должна прикладывать запись разговора, отдельно проверяю ссылку, права доступа и срок её хранения — успешный вызов не гарантирует корректную запись.

Условный кейс студии «Импульс-Логистик» заканчивается только после повторяемого теста: в журналах есть исходный ID канала, сервис использует согласованный ключ, а карточка CRM показывает ровно ожидаемый результат. Числа, версии и сроки в таком разборе берутся из замеров и конфигурации, а не добавляются для убедительности. Я не стану писать, что «UUID устранил проблему» или что «18.9.2 не поддерживала endpoint amoCRM», если нет подтверждения для конкретной версии коннектора и API. Технический текст обязан различать факт, гипотезу и рекламную легенду.

• Сохраните `UniqueID` и при необходимости `LinkedID`.
• Опишите ключ сопоставления в интеграционном сервисе.
• Проверьте повторы, переводы и неизвестные номера.
• Сверьте ответ API и фактическую карточку CRM.

Частые вопросы