Миграция событий алертов в ClickHouse после обновления KUMA с версии 3.4.х

После обновления KUMA с версии 3.4.x до версии 4.0 необходимо выполнить миграцию событий алертов из MongoDB в ClickHouse и указать хранилище в параметрах наполнения алертов.

После обновления KUMA установщик останавливает сервис kuma-mongodb и его нужно вручную запустить перед миграцией событий алертов. В случае установки с Ядром KUMA в кластере Kubernetes после обновления контейнер с MongoDB также не будет запущен, поэтому его будет необходимо запустить перед миграцией.

Если по каким-либо причинам вам необходимо прервать выполнение команды, нажмите Ctrl+C в консоли командной строки. Отобразится уведомление о том, что команда будет остановлена. Текущая пачка событий будет безопасно перенесена в хранилище, прогресс миграции сохранится, и процесс можно будет продолжить при следующем запуске команды.

Доступна миграция для следующих типов установки:

Подробное описание миграции для каждого из типов см. ниже в этой статье.

Миграция событий алертов в случае обновления установки KUMA в неотказоустойчивой конфигурации

Чтобы выполнить перенос событий алертов в неотказоустойчивой конфигурации:

  1. В веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы выберите хранилище, в котором будут храниться события алертов, и нажмите Копировать идентификатор кластера. Идентификатор кластера хранения понадобится при выполнении команды по переносу событий алертов.
  2. На сервере с Ядром KUMA запустите сервис kuma-mongodb.service с помощью следующей команды:

    sudo systemctl start kuma-mongodb.service

  3. Перейдите в каталог /opt/kaspersky/kuma и выполните следующую команду, подставив нужные значения в параметры и подставив в команду полученный ранее идентифкатор кластера хранения в параметр --cluster-id:

    ./kuma tools migrate --mongo="mongodb://<имя хоста, на котором установлена MongoDB>:<порт>" --core-url="https://<FQDN сервера, на котором установлено Ядро KUMA>:<порт>" --core-dir="<директория хранения данных Ядра KUMA: в зависимости от типа установки /opt/kaspersky/kuma/core/00000000-0000-0000-0000-000000000000 или /opt/kaspersky/kuma/core>" --cluster-id="<идентификатор кластера хранения, куда вы хотите перенести события алертов KUMA 3.4>" --batch=<количество событий алертов в пачке> 2>&1 | tee /tmp/migrate.log | grep -v "debug"

    Пример:

    ./kuma tools migrate --mongo="mongodb://localhost:27017" --core-url="https://kuma.example.com:7210" --core-dir="/opt/kaspersky/kuma/core/00000000-0000-0000-0000-000000000000" --cluster-id="0a123456-789a-0123-ab12-a3fab45ab6a7" --batch=10000 2>&1 | tee /tmp/migrate.log | grep -v "debug"

    Доступные параметры миграции событий алертов из MongoDB в ClickHouse

    Полный вывод команды будет сохранен в файл /tmp/migrate.log.

    Миграция может занять продолжительное время, если алертов много. Чтобы ускорить процесс миграции, вы можете применить параметр --batch, предварительно выделив дополнительное дисковое пространство и ОЗУ. Например, 150000 алертов можно мигрировать за одну итерацию длительностью порядка 3 минут при ОЗУ 12 ГБ для мигратора и MongoDB и дисковом пространстве 30 ГБ при значении параметра --batch равном 150000. В этом примере значения и продолжительность миграции приведены в качестве ориентира. Продолжительность может отличаться в зависимости от количества алертов и событий в алертах, от доступного дискового пространства и ОЗУ, а также от количества событий алертов в пачке, указанном в параметре --batch. Вы можете адаптировать значения под свои нужды.

    Также вы можете ускорить миграцию, если хотите перенести только часть событий алертов, например, за последний год. В таком случае вы можете указать значение параметра --time-limit, который будет соответствовать значению параметра Срок хранения алертов, дни.
    Например, у вас есть события алертов за полтора года, а вы хотите мигрировать только часть из них - события алертов за последний год. Вы выполняете миграцию 18 августа 2025 года, при этом для параметра Срок хранения алертов, дни указано значение 365, тогда в значении параметра --time-limit следует указать 19 августа 2024 года следующим образом: --time-limit="Sun, 19 Aug 2024 00:01:00 UTC".
    В результате в ходе миграции будут перенесены только события алертов за последние 365 дней. Это позволит ускорить миграцию и избежать переноса лишних событий.
    Если вы не укажете значение параметра --time-limit, миграция всех событий алертов в ClickHouse будет выполнена, но это может занять больше времени, а события алертов старше заданного срока хранения алертов будут позднее удалены из ClickHouse.

  4. После выполнения команды остановите сервис mongodb и отключите его запуск следующими командами:

    sudo systemctl stop kuma-mongodb.service

    sudo systemctl disable kuma-mongodb.service

Перенос событий алертов выполнен.

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

Миграция событий алертов в случае обновления установки с Ядром KUMA в кластере Kubernetes

Чтобы выполнить перенос событий алертов в установке с Ядром KUMA в кластере Kubernetes:

  1. В веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы выберите хранилище, в котором будут храниться события алертов, и нажмите Копировать идентификатор. Идентификатор кластера хранения понадобится при выполнении команды по переносу событий алертов.
  2. Запустите контейнер с MongoDB в поде Ядра KUMA, выполнив следующую команду на мастер-контроллере:

    sudo k0s kubectl apply -f /root/k0s/core-manifest.yaml

    Будет выполнен перезапуск Ядра KUMA.

  3. Подключитесь к мастер-контроллеру кластера k0s и запустите перенос событий алертов, подставив в команду полученный ранее идентифкатор кластера хранения в параметр --cluster-id:

    k0s kubectl exec -it deployment/core-deployment -c core -n kuma -- kuma tools migrate --mongo="mongodb://127.0.0.1:27017" --core-url="https://core:7210" --core-dir="/opt/kaspersky/kuma/core" --cluster-id="ec9e34bc-8c05-4f95-bb37-cfd5fe4b354a" --wd="/opt/kaspersky/kuma/core" --batch=10000 2>&1 | tee /tmp/migrate.log | grep -v "debug"

    Доступные параметры миграции событий алертов из MongoDB в ClickHouse

    Полный вывод команды будет сохранен в файл /tmp/migrate.log на хосте, где запускают k0s kubectl, а не в томе пода.

    Миграция может занять продолжительное время, если алертов много. Если прервется ssh-сессия, команда продолжит выполняться на поде. В таком случае запускать команду повторно не нужно. Можно отследить выполнение команды в процессах на рабочем узле где запущено Ядро KUMA:

    sudo watch 'ps -faux | grep "kuma tools migrate"'

    Чтобы ускорить процесс миграции, вы можете применить параметр --batch, предварительно выделив дополнительное дисковое пространство и ОЗУ. Например, 150000 алертов можно мигрировать за одну итерацию длительностью порядка 3 минут при ОЗУ 12 ГБ для мигратора и MongoDB и дисковом пространстве 30 ГБ при значении параметра --batch равном 150000. В этом примере значения и продолжительность миграции приведены в качестве ориентира. Продолжительность может отличаться в зависимости от количества алертов и событий в алертах, от доступного дискового пространства и ОЗУ и от количества событий алертов в пачке, указанном в параметре --batch. Вы можете адаптировать значения под свои нужды.

    Также вы можете ускорить миграцию, если хотите перенести только часть событий алертов, например, за последний год. В таком случае вы можете указать значение параметра --time-limit, который будет соответствовать значению параметра Срок хранения алертов, дни.
    Например, у вас есть события алертов за полтора года, а вы хотите мигрировать только часть из них - события алертов за последний год. Вы выполняете миграцию 18 августа 2025 года, при этом для параметра Срок хранения алертов, дни указано значение 365, тогда в значении параметра --time-limit следует указать 19 августа 2024 года следующим образом: --time-limit="Sun, 19 Aug 2024 00:01:00 UTC".
    В результате в ходе миграции будут перенесены только события алертов за последние 365 дней. Это позволит ускорить миграцию и избежать переноса лишних событий.
    Если вы не укажете значение параметра --time-limit, миграция всех событий алертов в ClickHouse будет выполнена, но это может занять больше времени, а события алертов старше заданного срока хранения алертов будут позднее удалены из ClickHouse.

  4. После успешного переноса событий алертов мы рекомендуем запустить Ядро KUMA без контейнера MongoDB. Для этого на мастер-контроллере выполните запуск Ядра KUMA в версии без контейнера MongoDB с помощью следующей команды:

    sudo k0s kubectl apply -f /root/k0s/core-manifest-no-mongodb.yaml

    Будет выполнен перезапуск Ядра KUMA.

Перенос событий алертов выполнен.

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

В начало