Release Notes v6.0.2

Перейти к релизу

SmartCPD 6.0.2 — исправляющий релиз линейки 6.0. Его можно установить поверх 6.0.0 или 6.0.1 либо использовать вместо них при переходе с поддерживаемых версий 5.x. Промежуточная установка 6.0.0 или 6.0.1 не требуется.

Исправленные ошибки#

• [#25342] В cdr-collector исправлено отключение сохранения detection-файлов при нулевом сроке хранения. При значении 0 параметров DETECTIONS_B_SIDE_RECORD_RETENTION_DAYS (запись B-side) или DETECTIONS_FULL_RECORD_RETENTION_DAYS (полная запись) файлы соответствующего типа больше не сохраняются; ранее они сохранялись и удалялись примерно через час.
• [#25377] Исправлена зависимость healthcheck воркеров от доступности cdr-collector. Ранее при его недоступности воркеры возвращали балансировщику 503 Service Unavailable. Теперь healthcheck воркера не проверяет доступность cdr-collector: записи накапливаются в очереди для последующего сохранения после восстановления его доступности.

Технические изменения#

• В логах balancer добавлены подробные отчёты о проверках доступности воркеров.
• Переработаны метрики cdr-collector: добавлены показатели времени выполнения дисковых операций и запросов к БД.
• В cdr-collector добавлен параметр DETECTIONS_MULTIPART_MEMORY_LIMIT_BYTES, задающий общий лимит памяти для файлов в одном multipart HTTP-запросе загрузки detection. Значение по умолчанию — 1 МиБ (1048576 байт). Если лимита недостаточно, используются временные файлы на диске. Настройка лимита позволяет сократить обращения к диску при приёме файлов; значение параметра и использование временных файлов отображаются в Grafana.
• В deployment сервиса amd по умолчанию подключена библиотека libtcmalloc_minimal через LD_PRELOAD для стабилизации потребления RAM при длительной высокой нагрузке. Дополнительная настройка compose.override.yml для её подключения не требуется.
• Обновлён дашборд CDR collector в Grafana: добавлены метрики дисковых операций и запросов к БД, показатели использования памяти и временных файлов при загрузке detection, а также healthcheck. Проверка хранилища использует тестовый файл размером 64 КиБ по умолчанию; дашборд показывает время выполнения проверки и отдельных операций с файлом.

Совместимость и обновление#

Совместимость#

• SmartCPD 6.0.1, 6.0.0, 5.2.12, 5.3.2 (см. процесс обновления).
• Docker версии 26+.
• Debian 12, РЕД ОС 8 (проверены для линейки 6.0).
• PostgreSQL версии 14+.

Состав обновления#

Относительно 6.0.1 обновлены следующие образы:

Остальной состав поставки соответствует 6.0.1.

Обновление с версий 6.0.x#

Поддерживаются прямые переходы:

• 6.0.0 → 6.0.2.
• 6.0.1 → 6.0.2.

Выполните deployment из поставки 6.0.2 с автоматической генерацией конфигурации:

./smartcpd-setup.sh deploy

Setup автоматически сформирует необходимую конфигурацию; отдельный запуск generate не требуется. Будут обновлены только затронутые сервисы. Обновление с 6.0.1 до 6.0.2 не добавляет миграций БД; при переходе с 6.0.0 сохраняются миграции, введённые в 6.0.1.

Обновление затрагивает трафик, поскольку меняются образы сервисов обработки вызовов. Рекомендуется проводить его в нерабочее время.

Обновление с версий 5.x#

Прямое обновление до 6.0.2 поддерживается с 5.2.12 и 5.3.2. Для более ранних версий необходимо сначала выполнить обновление до указанной версии своей линейки.

Примеры путей обновления:

• 5.2.2 → 5.2.8 → 5.2.12 → 6.0.2.
• 5.3.0 → 5.3.2 → 6.0.2.

При переходе с 5.2.12 или 5.3.2 применяются требования миграции на линейку 6.0; промежуточная установка 6.0.0 или 6.0.1 не требуется. Порядок обновления и требования к миграции описаны в документе «Обновление SmartCPD».

На каждой промежуточной версии необходимо запустить SmartCPD, дождаться завершения миграций БД и проверить работоспособность компонентов.

Ограничения и особенности#

Длительный первый запуск CDR collector при обновлении с 6.0.0#

При обновлении с 6.0.0 первый запуск cdr-collector может занять существенное время из-за создания индексов: в тестировании на базе примерно 200 млн записей CDR — около 12 минут. Длительность зависит от объёма данных и производительности БД.

Стартовый период healthcheck увеличен до одного часа; контейнер становится healthy после первой успешной проверки. Дождитесь завершения миграций по логам cdr-collector.

Контроль тарифов для облачных назначений#

Для облачных назначений наличие доступного тарифа у тенанта необходимо контролировать вручную, включая создание тенанта, изменение доступности тарифов и окончание срока их действия. При допуске новых вызовов платформа не проверяет наличие тарифа в биллинге и не блокирует вызовы из-за его отсутствия. Если на момент начала вызова не найден применимый тариф ни по назначению вызова, ни по основному назначению default, расчетный факт сохраняется с ошибкой no_effective_tariff, без примененного тарифа и со стоимостью 0. Вызов остается без рассчитанной стоимости; последующее появление тарифа не запускает автоматический пересчет этого факта.

Это ограничение ручного контроля не относится к тарифному покрытию валидной файловой лицензии V3: license-server проверяет, что хотя бы один тариф присутствует, а интервалы тарифов без разрывов покрывают весь срок действия лицензии. При нарушении этого правила лицензия признается невалидной и не предоставляет права на новые вызовы. Если другой действующей лицензии или применимой cloud policy нет, новые вызовы не допускаются. Допуск по cloud policy относится к облачному сценарию и требует ручного контроля тарифов, описанного выше.

Кодировка CSV-файлов разметки#

Загрузка разметки из CSV поддерживает только UTF-8. Файлы в других кодировках, включая Windows-1251, необходимо пересохранить в UTF-8 до отправки; автоматическое перекодирование не поддерживается.

Внешний Audit API#

Внешний Audit API в текущем релизе доступен только на уровне платформы. Tenant-scoped авторизация и получение журнала аудита в контексте клиента пока не поддерживаются.

Timezone приложения и БД#

В SmartCPD 6.0.1 timezone запуска контейнеров (SMARTCPD_TZ) должна совпадать с timezone сервера БД (SMARTCPD_DB_TZ). Setup проверяет это соответствие и отклоняет генерацию или развертывание конфигурации с разными значениями, поэтому установку и изменение конфигурации необходимо выполнять через smartcpd-setup.sh.

Известные проблемы#

• [#25341] Задержка построения биллинговых отчётов. При объёме более 15 млн вызовов за месяц биллинговые отчёты могут формироваться с задержкой 15–30 секунд.
• [#25183] Full Control Group. Механизм Full Control Group в данном релизе не работает.
• [#25373] Метрики дашборда SIP-вызовов. Метрики Unavaialable и SCPD Error в дашборде SIP-вызовы работают некорректно.