Release Notes

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

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

Исправлена первичная инициализация billing-server после крупных миграций с объёмом более 40 млн записей CDR: устранены ошибка 500 Internal Server Error от cdr-collector и избыточный проход по всей истории CDR до заданной даты начала расчёта. При отсутствии сохранённого курсора биллинг определяет стартовую последовательность по этой дате и продолжает чтение по курсору.
Исправлена инициализация назначения default для облачных тенантов: биллинг учитывает всех тенантов из лицензий и cloud policy и создаёт отсутствующие назначения с даты начала расчёта при наличии применимого тарифа.
Исправлено преждевременное создание default текущей датой при открытии списка тарифных назначений в UI до завершения первичной инициализации биллинга.

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

В cdr-collector добавлены индексы по ingest_seq в таблицах CDR и разметки для ускорения чтения по курсору.
В cdr-collector добавлены GET /v1/cdr/ingest/start-seq и GET /v1/markup/ingest/start-seq для получения стартового ingest_seq по дате since перед чтением по курсору.
В license-server добавлен GET /v3/cloud: список cloud policy без фильтрации по состоянию, с сохранением проверки прав доступа.

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

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

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

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

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

Сервис	Образ:версия
`cdr-collector`	`cdr-collector:6.0.1`
`billing-server`	`billing-server:6.0.1`
`license-server`	`license-server:6.0.1`

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

Обновление с версии 6.0.0#

Поддерживается прямой переход 6.0.0 → 6.0.1. Перед обновлением исходная версия должна быть запущена, миграции БД завершены, работоспособность компонентов проверена.

Выполните deployment из поставки 6.0.1:

./smartcpd-setup.sh deploy

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

Для обновления необходимо технологическое окно, которое может быть коротким, чтобы избежать деградации сервиса.

Индексы ingest_seq создаются автоматически при применении миграций cdr-collector. Дождитесь завершения миграций и проверьте синхронизацию billing-server. Повторная миграция legacy-данных не требуется.

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

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

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

5.2.2 → 5.2.8 → 5.2.12 → 6.0.1.
5.3.0 → 5.3.2 → 6.0.1.

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

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

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

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

При обновлении с 6.0.0 до 6.0.1 первый запуск cdr-collector на большой базе может занимать существенное время из-за создания индексов. В ходе внутреннего тестирования на базе примерно 200 млн записей CDR этот этап занял около 12 минут. Фактическая длительность зависит от объёма данных, производительности хранилища и нагрузки на БД. При последующих запусках повторное создание этих индексов не требуется.

Чтобы дать миграциям время завершиться, стартовый период healthcheck (start-period) увеличен до одного часа. Это запас времени для инициализации, а не обязательная задержка или гарантированный предел длительности миграции: если запуск завершится раньше, первая успешная проверка переведёт контейнер в состояние healthy. При обновлении с 6.0.0 следует контролировать логи первого запуска 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.

Потребление памяти сервисом amd#

При длительной работе amd на предельных нагрузках возможно повышенное или неравномерное потребление RAM. В контейнер amd уже включена библиотека libtcmalloc_minimal из Google Performance Tools. Если на большой нагрузке требуется стабилизировать профиль потребления памяти, библиотеку можно подключить через LD_PRELOAD в compose.override.yml:

services:
  amd:
    environment:
      LD_PRELOAD: "/usr/lib/x86_64-linux-gnu/libtcmalloc_minimal.so.4"

После изменения compose.override.yml необходимо перегенерировать и применить стек:

./smartcpd-setup.sh generate
./smartcpd-setup.sh deploy

tcmalloc использует отдельные кэши памяти для потоков, сокращая блокировки при выделении памяти. При длительной высокой нагрузке это может повысить производительность amd и сделать потребление RAM более плавным и стабильным.

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

[#25341] Задержка построения биллинговых отчётов. При объёме более 15 млн вызовов за месяц биллинговые отчёты могут формироваться с задержкой 15–30 секунд.
[#25183] Full Control Group. Механизм Full Control Group в данном релизе не работает.
[#25373] Метрики дашборда SIP-вызовов. Метрики Unavaialable и SCPD Error в дашборде SIP-вызовы работают некорректно.
[#25342] Нулевой срок хранения detection-файлов в CDR collector. При значении 0 параметров DETECTIONS_B_SIDE_RECORD_RETENTION_DAYS или DETECTIONS_FULL_RECORD_RETENTION_DAYS файлы соответствующего типа всё равно сохраняются и удаляются примерно через час. Исправлено в 6.0.2: нулевой срок хранения отключает сохранение файлов.
[#25377] Недоступность воркеров при недоступности CDR collector. Healthcheck воркеров зависит от доступности cdr-collector; при его недоступности воркеры возвращают балансировщику 503 Service Unavailable. Исправлено в 6.0.2: healthcheck не проверяет доступность коллектора, записи накапливаются в очереди для последующего сохранения.