Перейти к основному содержимому
Версия: 1.16.2

Конфигурация

Масштабирование​

В случае, когда нагрузка возрастает, для стабилизации работы платформы предусмотрено масштабирование следующих сервисов в ручном режиме:

  • platform-processing-dep
  • image-api-face-detector-liveness-estimator-dep
  • image-api-age-estimator
  • image-api-gender-estimator
  • image-api-mask-estimator
  • image-api-emotion-estimator
  • image-api-face-detector-template-extractor-dep

Для масштабирования сервиса выполните команду:

kubectl scale deployment <SERVICE_NAME> --replicas <COUNT>

где <SERVICE_NAME> - наименование сервиса (например, gateway-dep), а <COUNT> - количество экземпляров сервиса.

примечание

При использовании GPU-ускорения сервис platform-processing-dep поддерживает только один экземпляр, а значит для его масштабирования необходимо иметь N доступных видеоускорителей в кластере. При отсутствии нескольких GPU можно увеличить утилизацию, изменив параметр processing.workers в файле ./cfg/platform.values.yaml.

Для поддержания нагрузки в A запросов/сек., направленной на обработку изображений, на сервере с физическим количеством ядер CPU равным B следует установить значение реплик каждого из указанных сервисов по формуле min(A, B).

Для сохранения параметров масштабирования откройте файлы ./cfg/platform.values.yaml и ./cfg/image-api.values.yaml, найдите поле replicas в блоке сервиса и укажите новые значения реплик.

При следующих установках платформы и image-api сервисы будут автоматически масштабироваться до указанных значений.

подсказка

При увеличении запросов поиска по изображению увеличьте число реплик сервиса image-api-face-detector-template-extractor-dep. Также можно увеличить количество потоков, которые используются для вычисления биометрического шаблона.

При увеличении запросов на детекцию, создание профилей и создание сэмплов увеличьте число реплик сервисов:

  • platform-processing-dep
  • image-api-face-detector-liveness-estimator-dep
  • image-api-age-estimator
  • image-api-gender-estimator
  • image-api-mask-estimator
  • image-api-emotion-estimator

Изменение TTL сэмплов и активностей​

предупреждение

Значения для каждого из параметров указаны по умолчанию. Изменять значения параметров рекомендуется только в случае явной необходимости.

предупреждение

Параметр activity_ttl убран по умолчанию, т.к. добавлен функционал очистки по количеству хранящихся данных. При этом можно включить функционал, описанный здесь. Для этого в файле ./cfg/platform.values.yaml добавьте поле backend.activity_ttl: "2592000".

Файл ./cfg/platform.values.yaml:

  • backend.activity_ttl: время хранения активностей в базе данных. Значение задается в секундах. Например, 2592000 секунд (30 дней).
  • backend.sample_ttl: время хранения сэмплов в базе данных. Значение задается в секундах. Например, 2592000 секунд (30 дней).

Изменение количества хранящихся активностей и событий​

Файл ./cfg/platform.values.yaml:

  • backend.retention_activities_count: количество хранящихся активностей на один воркспейс.
  • backend.activity_handler_period: частота проверки количества активностей в базе. Значение задается в секундах. Например, 604800 секунд (7 дней).
подсказка

Для нахождения оптимального количества активностей можно воспользоваться формулой a = V/(w*0.0025), где a — количество активностей на один воркспейс; V — желаемый объем памяти в ГБ, который будут занимать активности; 0.0025 — средний размер одной активности в ГБ; w — количество воркспейсов пользователей.

Файл ./cfg/platform.values.yaml:

  • event_service.retention_events_count: количество хранящихся событий на один воркспейс.
  • event_service.event_handler_period: частота проверки количества событий в базе. Значение задается в секундах. Например, 604800 секунд (7 дней).
подсказка

Для нахождения оптимального количества событий можно воспользоваться формулой e = V/(w*0.004), где e — количество событий на один воркспейс; V — желаемый объем памяти, который будут занимать события; 0.004 — средний размер одного события в ГБ; w — количество воркспейсов пользователей.

Изменение метода распознавания лиц​

OMNI Platform использует методы распознавания лиц из набора библиотек Face SDK. Под методом имеется в виду версия модели распознавания лиц. По умолчанию в OMNI Platform установлен метод 12v1000. Для более быстрой работы вы можете переключиться на метод 12v100, однако при этом снизится точность распознавания.

Смена метода во время установки платформы​

На этапе заполнения файлов конфигурации откройте файл ./cfg/platform.values.yaml и замените метод в полях generic.recognizer, backend.default_template_version, processing.recognizer_methods. Далее откройте файл ./cfg/image-api.values.yaml и замените метод в полях face-detector-template-extractor.configs.recognizer.name и verify-matcher.configs.recognizer.name.

Смена метода на работающей платформе​

  1. Остановите платформу. 
./cli.sh platform uninstall
  1. Остановите сервисы image-api. 
./cli.sh image-api uninstall
  1. Удалите базу данных платформы.
./cli.sh platform db-reset

  1. Откройте файл ./cfg/platform.values.yaml и замените метод в полях generic.recognizer, backend.default_template_version, processing.recognizer_methods. Далее откройте файл ./cfg/image-api.values.yaml и замените метод в полях face-detector-template-extractor.configs.recognizer.name и verify-matcher.configs.recognizer.name.

  2. Запустите установку сервисов image-api.

./cli.sh image-api install
  1. Запустите платформу.
./cli.sh platform install
примечание

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

Настройка порога схожести лиц (score)​

Параметр score показывает степень схожести лиц от 0 (0%) до 1 (100%). Высокая степень схожести означает, что два биометрических шаблона принадлежат одному и тому же человеку. Пороговое значение по умолчанию — 0.85.

Изменить порог score на OMNI Platform можно через API-запрос updateWorkspaceConfig, где в качестве аргументов указываются два пороговых значения: activityScoreThreshold (требуемый score для привязки активности к профилю) и notificationScoreThreshold (требуемый score для создания оповещений для профиля).

подсказка

Убедитесь, что пороги score, указанные для OMNI-агента и OMNI Platform совпадают. В противном случае, часть активностей, сформированных из переданных процессов OMNI-агента, не будет привязана к соответствующему профилю, а значит и оповещения для таких активностей приходить не будут.

Например:

  • score, указанный на стороне OMNI-агента = 0.7
  • score, указанный на OMNI Platform = 0.85

В этом случае активности, сформированные из процессов OMNI-агента со значением score в диапазоне [0.7, 0.85), не будут прикреплены к соответствующему профилю, оповещения по ним также не появятся.

Для настройки порога score для OMNI-агента см. руководство пользователя OMNI-агента.

Отправка писем на SMTP-сервер​

  1. Остановите развернутую OMNI Platform:

    ./cli.sh platform uninstall

  2. Внесите изменения в файле ./cfg/platform.secrets.json в platform-email-secret.

  3. Пересоздайте секреты:

    ./cli.sh platform install-secrets

  4. Заново разверните OMNI Platform:

    ./cli.sh platform install