Перейти к содержанию

v.5.157.0#

Изменения

  • SDK обновлен до версии 5.36.1.

    В данной версии были обновлены:

    • эстиматор DeepFake до версии 11;
    • эстиматор OneShotLiveness до версии 14.

  • Внутренняя библиотека лицензирования обновлена до версии 1.14.0.

  • Обновлена версия InfluxDB — базы данных, используемой по умолчанию для мониторинга работы LP, с 2.0.8 до 2.9.1.

  • Логин учетной записи администратора по умолчанию изменен на нейтральный root@example.com (вместо root@visionlabs.ai).

    Новый логин используется только при установке LP с нуля. При обновлении системы логин администратора остаётся прежним.

    Подробнее см. в разделе "Аккаунты, токены и способы авторизации".

  • Расширены возможности фильтрации для поля meta в событиях (events) и поля event в обобщенных событиях (general events).

    Добавлен новый тип данных json — позволяет передавать JSON-объекты и массивы в качестве значений для фильтрации. Значения должны быть URL-encoded JSON-строками.

    Для работы с типом данных json добавлены новые операторы:

    • contains — проверяет, что все элементы переданного массива содержатся в массиве события;
    • ncontains — отрицание contains;
    • overlaps — проверяет, что хотя бы один элемент из массива присутствует в массиве события;
    • noverlaps — отрицание overlaps.

    Пример: GET /events?meta.tags__contains:json=%5B%22urgent%22%5D, где %5B%22urgent%22%5D — это URL-encoded строка для массива ["urgent"] (поиск событий с тегом "urgent").

    Существующие операторы eq, neq, in, nin теперь также поддерживают тип json, что позволяет точно сопоставлять JSON-объекты и массивы и проверять наличие элементов.

    Примечание. Для ускорения запросов с использованием новых операторов рекомендуется использовать GIN-индексы. Подробнее см. в разделе "User defined data (meta)" документации разработчика.

  • Добавлена поддержка работы с полем source_group для событий (events).

    Ранее это поле было доступно только для обобщенных событий (general events).

    Теперь группа источника событий поддерживается при создании, фильтрации, получении событий, выполнении длительных задач, подписке через WebSocket и в операциях сравнения.

    См. раздел "Работа с группами источников событий".

  • В структуру потока добавлена поддержка поля event_meta для хранения пользовательских данных.

    Теперь при создании или обновлении потока (а также групп потоков) можно указать произвольные JSON-данные в поле event_meta внутри блока analytics. Эти данные будут добавлены в каждое событие, которое генерирует аналитика, или переопределят существующие поля события при совпадении имён.

    Важные ограничения:

    • поля event_id, stream_id, track_id запрещены для переопределения;
    • поля с массивами значений заменяются полностью (без объединения элементов);
    • если в event_meta и в событии есть поле с одинаковым именем, приоритет у значения из event_meta.

    См. описание analytics.event_meta в запросах: create stream, create group, put stream и get streams.

  • В сервисе Python Matcher ускорено сравнение по небольшим спискам лиц.

    В группу параметров DESCRIPTORS_CACHE (секция cached_data > faces_lists) добавлен параметр large_list_batch_threshold. Он определяет порог для группировки запросов на сравнение в один вызов плагина Cached Matcher. Если запрос содержит список, количество лиц в котором превышает этот порог, применяется пакетная обработка.

  • В сервис Lambda добавлена возможность ограничения ресурсов лямбд.

    В конфигурацию сервиса добавлена новая группа параметров LAMBDA_RESOURCE_LIMITS, которая позволяет задать ограничения на ресурсы для каждого пространства имен (namespace) Kubernetes:

    • cpu_limit — максимальное количество CPU на lambda (в единицах, где 1 = 1/1000 ядра процессора);
    • ram_limit — максимальный объём использования RAM на lambda (в ГБ);
    • gpu_availability — доступность GPU;
    • labels — пользовательские метки.

    При создании, обновлении и импорте lambda теперь можно использовать параметр deploy_parameters > check_resources. Если он включён (значение true), перед созданием lambda выполняется проверка запрошенных ресурсов на соответствие ограничениям из LAMBDA_RESOURCE_LIMITS. При превышении лимитов возвращается ошибка с кодом 42022.

    Это позволяет предотвратить неограниченное потребление ресурсов из-за некорректных настроек lambda и не тратить время на сборку lambda, которая всё равно не сможет развернуться из-за конфликта с лимитами Kubernetes.

    Проверить заданные ограничения ресурсов можно с помощью запроса lambda resource limits.

    Важно! Ограничения на уровне Kubernetes могут быть строже, чем заданные в LAMBDA_RESOURCE_LIMITS, что может привести к невозможности запуска lambda.

    См. подробную информацию в разделе Ограничение ресурсов lambda.

  • В сервис Lambda добавлен клиент "Lambdas internal api client", позволяющий лямбдам взаимодействовать друг с другом.

    Теперь из одной lambda можно отправить запрос к другой lambda, указав её идентификатор (lambda_id) или имя (lambda_name).

    В документацию разработчика добавлены "примеры для Standalone-lambda":

    • взаимодействие двух lambda с обращением по ID и по имени;
    • взаимодействие с использованием user_config для передачи идентификатора другой lambda.

    Подробнее см. в разделе "Luna client services".

  • Добавлена возможность работы Agent-lambda в автономном режиме (Autonomous Mode) — управление потоками напрямую, без сервиса Video Manager.

    Ограничения: в автономном режиме недоступны некоторые функции (разделяемые потоки, шаблоны расписаний, распределение потоков между агентами, группировка потоков, автоматический перезапуск). Кроме того, все потоки, логи и данные теряются при перезапуске агента.

    Подробнее см. раздел Автономный режим работы сервиса Video Agent.

  • В руководство разработчика сервиса Lambda добавлен новый раздел Lambda reference table, содержащий справочную информацию по всем функциям, классам и константам для разработки лямбд.

  • В руководство разработчика сервиса Lambda добавлен пример Standalone-lambda обработки запроса с типом содержимого multipart/form-data.

    Пример демонстрирует, как обрабатывать такой запрос, в котором передаются данные в формате JSON и два файла изображений.

    См. подробную информацию в разделе Standalone-lambda.

  • Теперь при регистрации пользовательского сервиса через запрос create service сервиса Admin можно настроить проверку его работоспособности, указав следующие параметры:

    • healthcheck — включить или отключить проверку;
    • route — путь к эндпоинту для проверки (по умолчанию /healthcheck);
    • interval — интервал между проверками в секундах (по умолчанию 10);
    • timeout — таймаут запроса проверки в секундах (по умолчанию 3).

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

    Помимо этого, с помощью запросов get service или get services можно отследить состояние каждого адреса сервиса (поле health со значениями up, down, unavailable, disabled).

    Также в сервисы API и Serving добавлены настройки BALANCER_API_ADDRESS и BALANCER_API_TIMEOUTS, которые определяют параметры подключения к API балансировщика Traefik.

  • В механизм сборки Docker-образов лямбд сервисом Builder добавлена задержка перед удалением подов сборщиком мусора.

    Это предотвращает ситуации, когда сборки со статусом Pending или со статусом, отличным от Running, удалялись до того, как их статус будет считан.

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

  • Исправлена ошибка в сервисе Events при пакетном создании обобщенных событий.

    Ранее при передаче в одном запросе нескольких событий с разными идентификаторами аккаунта все события сохранялись в БД с account_id от первого события в списке. Теперь каждому событию присваивается его собственный account_id.

    См. запрос create new general events.

  • Исправлена ошибка, из-за которой параметры с пустыми значениями не отображались в ответе на запрос "get service configuration".

    Теперь такие параметры отображаются с пустым массивом, что позволяет явно видеть их текущее состояние.

  • Исправлена ​​ошибка агрегации данных для мониторинга Clickhouse.

    Ранее средние значения и показатели по медленным запросам могли быть неточными — расчёт выполнялся по данным из одного случайного интервала вместо усреднения по всем.

  • Исправлена некорректная обработка ошибок переполнения хранилища MinIO при создании лямбды в процессе загрузки архива.

    Ранее при переполнении хранилища пользователь получал неинформативную ошибку с кодом 11009. Теперь возвращается ошибка с кодом 42023, что позволяет диагностировать проблему как связанную с загрузкой архива, в том числе с переполнением хранилища.

  • Исправлена ошибка, из-за которой в контейнере lambda типа Agent не запускался медиасервер MediaMTX, что делало невозможным использование механизма ретрансляции потоков ("Retransmission fallback").

    Примечание. Для корректной работы механизма в Agent-lambda необходимо настроить следующие параметры ядра на уровне узлов Kubernetes:

    • fs.inotify.max_user_instances - 1280
    • fs.inotify.max_user_watches - 655360

    Важно! Меньшие значения недостаточны для стабильной работы механизма.

  • Исправлена ошибка, из-за которой при обновлении базового образа lambda через запрос update lambda имя lambda некорректно заменялось на её идентификатор lambda_id.

    Теперь имя lambda остаётся корректным.