Обновление системы

В данном разделе описаны действия по обновлению основного экземпляра системы или сателлита (далее — "экземпляр системы").

Обновление состоит из следующих этапов:

Подготовка к обновлению
Обновление системы
Действия после обновления
Авторизация в системе

Если к основному экземпляру системы подключены сателлиты, нужно обновить их после обновления основного экземпляра системы. Инструкция по обновлению сателлитов приведена в разделе Обновление сателлитов.

Подготовка к обновлению

Подготовительные действия перед обновлением

В процессе обновления системы базы данных и сервисы могут быть временно недоступны. Работоспособность системы будет автоматически восстановлена по завершении обновления.

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

Минимизируйте операции в системе, связанные с изменениями в базах данных и NATS, такие как активный сбор событий или изменения конфигурации системы.
Проверьте соответствие программных и аппаратных требований для работы установщика новой версии экземпляра системы.
Убедитесь, что у вас установлена версия ClickHouse, поддерживаемая новой версией системы. Если ваша версия ClickHouse отличается от поддерживаемой, обновите ClickHouse до требуемой версии.
Скачайте архив с файлами для установки новой версии экземпляра системы и проверьте его целостность.

Смена доменного имени системы

При необходимости перед началом обновления вы можете изменить доменное имя, по которому доступен веб-интерфейс системы. Для этого:

Подключитесь к терминалу master-узла кластера Kubernetes, в котором установлен основной экземпляр системы.
Обновите доменное имя в секрете evo.infra.global, выполнив следующую команду:
kubectl patch secret evo.infra.global -n <namespace> -p='{"stringData":{"FRONTEND_HOST": "<new_domain_name>","GRAFANA_EXTERNAL_URL": "https://<new_domain_name>/grafana"}}'
Здесь:
- <namespace> — название пространства имен, в котором установлена система.
- <new_domain_name> — новое доменное имя, например, evo-new.company.local.
В результате успешного обновления секрета должно отобразиться следующее сообщение:
secret/evo.infra.global patched
Запустите обновление. После обновления система будет доступна по новому доменному имени.

Настройка шифрования трафика между узлами кластера

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

Чтобы настроить шифрование трафика между узлами кластера, вы можете включить использование протокола WireGuard для сетевого плагина Calico. После этого плагин начнет создавать защищенные туннели между узлами кластера.

Для работы WireGuard требуется ядро Linux версии 5.6 и выше, поскольку этот протокол встроен в ядро начиная с версии 5.6.
Трафик между узлами кластера шифруется, но на каждом узле трафик между самим подом и его хостом остается открытым. Считается, что для его перехвата злоумышленнику требуется прямой доступ к самому хосту.
Трафик между подами на одном узле не шифруется.

Инструкции по устранению типичных проблем при работе WireGuard приведены в разделе Устранение проблем при эксплуатации системы.

Включение шифрования трафика

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

Убедитесь что на всех узлах кластера открыт порт 51820.
Подключитесь к терминалу master-узла кластера.
Чтобы отслеживать статус WireGuard, установите утилиту wg с помощью менеджера пакетов вашей операционной системы, например:
```
sudo dnf install -y yq wireguard-tools
```
Включите параметр wireguardEnabled в ресурсе FelixConfiguration, выполнив следующую команду:
```
kubectl patch felixconfiguration default --type='merge' -p '{"spec":{"wireguardEnabled":true}}'
```
Убедитесь, что шифрование трафика между узлами кластера включено:
1. Проверьте, что в информации об узлах Calico появилось поле wireguardPublicKey:
  for node in $(kubectl get nodes -o yaml| yq '.items[].metadata.name'); do echo ">>> $node"; calicoctl get node $node -o yaml | grep wireguardPublicKey; done
2. Проверьте, что утилита wg возвращает информацию о конфигурации, с помощью следующих команд:
  sudo wg show
  sudo wg showconf wireguard.cali

Обновление ключей WireGuard

В Calico процесс обновления ключей WireGuard полностью автоматизирован и не требует ручных действий. Он встроен в работу компонента Felix на каждом узле кластера.

Обновление ключей выполняется следующим образом:

Генерация новой пары ключей: компонент Felix периодически генерирует новую локальную пару ключей WireGuard (приватный и публичный ключи) на каждом узле кластера. Частота этой ротации не документирована как настраиваемый параметр и определяется внутренней логикой Calico.
Размещение публичного ключа: после генерации нового ключа Felix автоматически обновляет статус своего узла (node resource) в Kubernetes API, сохраняя в аннотации или поле .status свой новый публичный ключ WireGuard.
Обнаружение и применение: Felix постоянно отслеживает изменения в статусах всех узлов. Когда он обнаруживает, что у соседнего узла появился новый публичный ключ, он немедленно обновляет конфигурацию своего локального WireGuard-интерфейса (wireguard.cali), добавляя или заменяя ключ для соответствующего пира (peer).

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

Особенности обновления системы с определенных версий

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

Особенности обновления системы с версии ниже 2.0.0

В системе версии ниже 2.0.0 может возникать ошибка при просмотре логов коллектора в интерфейсе:

Не удалось получить логи коллектора.
connect ECONNREFUSED <...>

В логах пода loki-gateway отображается ошибка:

host not found in resolver "coredns.kube-system.svc.cluster.local." in /etc/nginx/nginx.conf:33

Причина: чарт Loki по умолчанию использует имя coredns для конфигурации разрешения имен пода loki-gateway, однако в кластере может использоваться другое имя для сервиса DNS — например, kube-dns.

В системе версии 2.0.0 и выше данный параметр определяется автоматически, но при обновлении с более старой версии проблема может воспроизводиться, поэтому перед обновлением следует ее устранить.

Решение: нужно исправить конфигурацию сервиса loki-gateway. Для этого:

Получите фактическое имя DNS-сервиса:

K8S_DNS_SERVICE="$(kubectl get service -n kube-system -l k8s-app=kube-dns -o 'jsonpath={.items..metadata.name}')"

Получите конфигурацию loki-gateway:

LOKI_CONFIG="$(get cm loki-gateway -n kube-prometheus-stack -o 'jsonpath={.data.nginx\.conf}')"

Сравните имена DNS-сервисов:
```
echo "K8s DNS: $K8S_DNS_SERVICE"
echo "Loki DNS: $(echo "$LOKI_CONFIG" | grep resolver)"
```
Пример вывода имен DNS-сервисов
```
K8s DNS: kube-dns
Loki DNS: resolver coredns.kube-system.svc.cluster.local.;
```
Если в выводе имена сервисов разные, перейдите к шагу 4.
Откройте ConfigMap loki-gateway:
```
KUBE_EDITOR=nano kubectl edit configmap/loki-gateway -n kube-prometheus-stack
```
Замените имя DNS-сервиса coredns после resolver на значение переменной K8S_DNS_SERVICE. После исправления строка ConfigMap должна принять вид:
```
resolver <dns_name>.kube-system.svc.cluster.local.;
```
Здесь:
- <dns_name> — имя DNS-сервиса Kubernetes, полученное на шаге 3, например, kube-dns.

Сохраните файл и перезапустите loki-gateway:

kubectl rollout restart deployment/loki-gateway -n kube-prometheus-stack

Особенности обновления системы с версии ниже 2.3.0

Начиная с версии 2.3.0 система поставляется на базе платформы R-Vision EVO.

Обновление системы с версий ниже 2.3.0 требует ручных действий.

Выключение коллекторов

Перед обновлением системы с версии ниже 2.3.0 необходимо выключить все работающие коллекторы.

После обновления все необходимые коллекторы и конвейеры нужно будет включить вручную.

Создание общей БД PostgreSQL

Сервисы платформы могут использовать как общую БД, так и собственные. В установщиках системы версий ниже 2.3.0 общая БД отсутствует. Необходимо создать ее вручную с помощью команды:

kubectl exec -n <namespace> sts/postgresql -- psql -U <username> -d postgres -c 'CREATE DATABASE evo;'

Здесь:

<namespace> — название пространства имен, в котором установлена система.
<username> — имя пользователя PostgreSQL, которое было указано при установке системы.

Имя пользователя PostgreSQL можно получить из секрета evo.siem.global, выполнив следующую команду:

kubectl -n <namespace> get secrets evo.siem.global -o jsonpath='{.data.POSTGRES_USER}' | base64 -d

Здесь:

<namespace> — название пространства имен, в котором установлена система.

Обновление NATS

Начиная с версии 2.2.0 в поставку системы входит NATS. При обновлении с 2.2.x необходимо предварительно удалить предыдущие helm-релизы NATS, чтобы избежать ошибок. Для этого:

Удостоверьтесь, что NATS развернут в необходимом пространстве имен:
```
helm list -n <namespace> | grep nats-
```

Удалите nats-main и nats-bridge при их наличии:

helm uninstall -n <namespace> nats-bridge
helm uninstall -n <namespace> nats-main

Здесь:

<namespace> — название пространства имен, в котором установлена система.

Устранение проблем при обновлении

При обновлении системы установщик выполняет ряд специфичных действий по переносу конфигурационных параметров в платформу.

Если во время обновления системы произошел сбой, выполните следующие действия:

Удалите метаданные модулей, которые успели развернуться до сбоя:
```
kubectl get cm -n <namespace> -o name | grep release-info | xargs -n1 -t kubectl delete -n <namespace>
```
Запустите обновление повторно без распаковки дистрибутива:
```
export PATH=$PATH:/opt/r-vision/common/bin
evoctl instance update -v
```

Добавление разрешений

При обновлении системы с версии ниже 2.3.0 в пользовательских ролях сбрасываются все разрешения. После обновления необходимо заново настроить разрешения ролей.

Особенности обновления системы с версии ниже 2.3.3

Начиная с версии 2.3.3 названия схем активных списков и таблиц обогащения не могут содержать точки.

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

Особенности обновления системы с версии ниже 2.4.0

После обновления системы с версии ниже 2.4.0 тип существующих точек входа HTTP Client изменится на HTTP Client_deprecated в связи с их функциональными обновлениями.

Для обновления точек входа HTTP Client:

Измените тип существующих точек входа HTTP Client_deprecated в конвейерах на обновленный тип без суффикса _deprecated.
Удалите устаревший тип точки входа из таблицы entry_point_type в базе данных коллекторов PostgreSQL. Для этого:
1. Подключитесь к терминалу master-узла кластера.
2. Подключитесь к PostgreSQL, выполнив следующую команду:
  kubectl exec -it -n <namespace> postgresql-0 sh
  Здесь:
  - <namespace> — название пространства имен, в котором установлена система.
3. Подключитесь к базе данных коллекторов:
  psql -U postgres -d collector
4. Удалите из таблицы entry_point_type устаревший тип точки входа:
  delete from "entry_point_type" where "name" like '%_deprecated';

Особенности обновления системы с версии ниже 2.5.0

При обновлении системы с версии ниже 2.5.0 необходимо обновить ClickHouse до поддерживаемой версии.

Особенности обновления системы с версии ниже 2.6.0

Обновление системы с версий ниже 2.6.0 требует ручных действий.

Сохранение настроек стримов в менеджере пространств

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

Чтобы не потерять изменения, внесенные в настройки стримов, перед обновлением системы сохраните их в секрет evo.space.global. Для этого выполните следующую команду для каждой измененной переменной окружения:

kubectl patch secret evo.space.global -n evo-namespace -p='{"stringData":{"<env_var>": "<value>"}}'

Здесь:

<env_var> — переменная окружения, новое значение которой необходимо сохранить. Например: NATS_CONFIGURATOR_GLOBAL_OBJECTS_OS_MAX_SIZE.
<value> — новое значение переменной окружения. Например: 512MB.

Список переменных окружения с настройками стримов и их значения по умолчанию приведены в разделе Настройка стримов в менеджере пространств.

Переход на новые точки входа R-Vision Endpoint

Начиная с версии 2.6.0 тип точек входа R-Vision Endpoint заменен на R-Vision Endpoint_deprecated в силу функционального устаревания, а R-Vision EVO Endpoint — на R-Vision Endpoint.

После обновления системы с версии ниже 2.6.0 рекомендуется перейти со старых точек входа R-Vision Endpoint_deprecated на новые — R-Vision Endpoint. Для этого:

Удалите агенты R-Vision Endpoint и установите системные агенты согласно инструкции в разделе Переход с агентов R-Vision Endpoint на системные агенты.
Измените тип существующих точек входа R-Vision Endpoint_deprecated в конвейерах на обновленный тип без суффикса _deprecated и укажите домен для подключения к шлюзу. Подробности приведены в описании точки входа R-Vision Endpoint.
Удалите устаревший тип точки входа из таблицы entry_point_type в базе данных коллекторов PostgreSQL. Для этого:
1. Подключитесь к терминалу master-узла кластера.
2. Подключитесь к PostgreSQL, выполнив следующую команду:
  kubectl exec -it -n <namespace> postgresql-0 sh
  Здесь:
  - <namespace> — название пространства имен, в котором установлена система.
3. Подключитесь к базе данных коллекторов:
  psql -U postgres -d collector
4. Удалите из таблицы entry_point_type устаревший тип точки входа:
  delete from "entry_point_type" where id = 'f7183617-e756-4fa9-9f59-bd2c2529625c';

Включение поиска по нескольким хранилищам событий

Одновременный поиск по нескольким хранилищам, созданным до версии 2.4.0 и в версии 2.4.0 или выше, недоступен. Это связано с переходом на тип данных DateTime64 в служебных полях моделей событий в версии 2.4.0. В таком случае необходимо ограничиться поиском только по тем хранилищам, которые были созданы либо в версии ниже 2.4.0, либо в версии 2.4.0 или выше.

Для работы поиска по нескольким хранилищам событий выполните процедуру создания недостающих удаленных (remote) и локальных таблиц хранилищ:

Создайте необходимые распределенные таблицы с помощью скрипта, приведенного после заголовка Создать необходимые распределенные таблицы в разделе Настройка существующего кластера ClickHouse. Вы можете выполнить скрипт на любом экземпляре кластера ClickHouse.
Подключитесь к терминалу master-узла кластера.
Откройте ConfigMap сервиса evo.streams.event-storage-manager. Для этого выполните следующую команду:
```
kubectl -n <namespace> edit configmap evo.streams-event-storage-manager-env
```
Здесь:
- <namespace> — название пространства имен, в котором установлена система.

Измените значение переменной EVO_STREAMS_EVENT_STORAGE_MANAGER_RECREATE_EVENT_STORAGES на "true".

Пересоздание таблиц хранилищ событий занимает некоторое время. В процессе пересоздания liveness-пробы сервиса evo.streams.event-storage-manager могут завершиться с ошибкой, что приведет к циклическому перезапуску этого сервиса. Во избежание такого поведения рекомендуется увеличить интервал между liveness-пробами, выполнив следующие действия:

Откройте конфигурацию контроллера Deployment evo.streams.event-storage-manager, выполнив следующую команду:
kubectl -n <namespace> edit deployment evo.streams.event-storage-manager
Здесь:
- <namespace> — название пространства имен, в котором установлена система.
Скопируйте и сохраните текущие значения параметров в секции livenessProbe.
Пример содержимого секции livenessProbe
```
livenessProbe:
  grpc:
    port: 3000
    service: ''
  initialDelaySeconds: 10
  timeoutSeconds: 3
  periodSeconds: 10
  successThreshold: 1
  failureThreshold: 3
```
Увеличьте значения параметров timeoutSeconds, periodSeconds и failureThreshold.
Сохраните изменения.

После перезапуска сервиса evo.streams.event-storage-manager рекомендуется восстановить настройки liveness-проб по умолчанию.

Удалите под сервиса evo.streams.event-storage-manager, выполнив следующую команду:
```
kubectl -n <namespace> delete pods -l app.kubernetes.io/name=evo.streams.event-storage-manager
```
Под будет пересоздан автоматически.
Дождитесь, когда под evo.streams.event-storage-manager перейдет в статус Running. Инструкция по проверке статуса пода приведена в разделе Просмотр состояния подов кластера.
Когда под перейдет в статус Running, перейдите в веб-интерфейс системы и убедитесь, что поиск по хранилищам событий выполняется успешно и события поступают в хранилища.
Откройте ConfigMap сервиса evo.streams.event-storage-manager. Для этого выполните следующую команду:
```
kubectl -n <namespace> edit configmap evo.streams-event-storage-manager-env
```
Здесь:
- <namespace> — название пространства имен, в котором установлена система.
Измените значение переменной EVO_STREAMS_EVENT_STORAGE_MANAGER_RECREATE_EVENT_STORAGES обратно на "false".
Если вы меняли интервал liveness-проб, восстановите интервал по умолчанию в конфигурации evo.streams.event-storage-manager. Ее можно открыть, выполнив следующую команду:
kubectl -n <namespace> edit deployment evo.streams.event-storage-manager
Здесь:
- <namespace> — название пространства имен, в котором установлена система.

Восстановление работы сервисов оповещений

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

Особенности обновления системы с версии ниже 2.7.0

При обновлении системы с версии ниже 2.7.0 необходимо обновить ClickHouse до поддерживаемой версии.

Особенности обновления системы с версии ниже 2.7.1

Пересоздание системных активных списков

Начиная с версии 2.7.1 в активных списках изменена логика срока жизни записей, а также добавлен специальный тип данных для хранения VRL в записях. Теперь срок жизни записи можно задавать в секундах через поле ttl типа integer вместо поля dueDate. Из-за этого при обновлении системы с версии 2.7.0 системные активные списки могут начать работать некорректно.

Чтобы восстановить корректную работу системных активных списков, перед обновлением системы с версии 2.7.0 их необходимо удалить. Для этого:

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

Сбросьте тип системных активных списков на Пользовательский, запустив в СУБД PostgreSQL следующий скрипт:

-- Сброс типа для белого и черного списков.
UPDATE active_list.active_list
SET is_system = false
WHERE active_list_name IN ('system-whitelist', 'system-blacklist');

-- Сброс типа для схем белого и черного списков.
UPDATE expertise.expertise
SET object_type = 'custom'
WHERE name IN ('system-whitelist', 'system-blacklist');

-- Удаление скрипта добавления исключений.
DELETE FROM evo_streams_script.executed_script WHERE name = 'ScriptAddExceptionActiveList';

Удалите системные активные списки:
1. Перейдите в раздел Ресурсы → Активные списки.
2. Найдите активные списки system-whitelist и system-blacklist.
3. Удостоверьтесь, что найденные активные списки имеют тип Пользовательский. В противном случае повторите шаг 2 текущей инструкции.
4. Удалите активные списки system-whitelist и system-blacklist.
Удалите схемы системных активных списков:
1. Перейдите в раздел Экспертиза.
2. Найдите схемы активных списков system-whitelist и system-blacklist.
3. Удостоверьтесь, что найденные схемы активных списков имеют тип создания Пользовательский. В противном случае повторите шаг 2 текущей инструкции.
4. Удалите схемы активных списков system-whitelist и system-blacklist.

Если вы хотите импортировать в систему CSV-файлы с записями системных активных списков, которые были экспортированы в версии 2.7.0, их необходимо предварительно отредактировать и привести к актуальному формату. Для этого выполните следующие действия:

Замените поле dueDate на ttl и укажите актуальные сроки жизни для каждой записи в секундах. Поле ttl может принимать только целочисленные значения.

Если требуется сделать записи бессрочными, задайте значение 0.
Удалите поле createdAt.

Обновление настроек NATS Object Store

Начиная с версии 2.7.1 в системе исправлена проблема, из-за которой при сбросе метрик в глобальной шине могла очиститься очередь событий.

Теперь в новых коллекторах сброс метрик не будет приводить к очистке очереди в глобальной шине. Однако в существующих коллекторах данная проблема по-прежнему может наблюдаться. Чтобы исправить ее, необходимо изменить настройки объектного хранилища NATS Object Store. Для этого после обновления на версию 2.7.1 или выше выполните следующие действия для центрального кластера и каждого кластера сателлита:

Подключитесь к терминалу master-узла кластера.
Откройте терминал контейнера пода nats-space-box:
```
kubectl exec -n <namespace> -it deployment/nats-space-box -- sh
```
Здесь:
- <namespace> — название пространства имен, в котором установлена система.

Создайте скрипт script.sh, например, с помощью команды:

vi script.sh

Содержимое скрипта script.sh

filter="<object_id>"

data="$(nats obj ls -n r-space-siem-collector-objects | grep "$filter")"
set -- $data

list="$@"

changed=1
while [ $changed -eq 1 ]; do
  changed=0
  new_list=""
  prev=""
  for item in $list; do
    if [ -z "$prev" ]; then
      prev="$item"
      continue
    fi
    prev_prefix="${prev:0:105}"
    curr_prefix="${item:0:105}"

    if [ "$curr_prefix" \< "$prev_prefix" ]; then
      new_list="$new_list $item"
      prev="$prev"
      changed=1
    elif [ "$curr_prefix" == "$prev_prefix" ]; then
      prev_suffix="${prev:105}"
      curr_suffix="${item:105}"
      prev_p2=$(echo "$prev_suffix" | cut -d '_' -f2)
      curr_p2=$(echo "$curr_suffix" | cut -d '_' -f2)
      if [[ "$prev_p2" =~ ^[0-9]+$ && "$curr_p2" =~ ^[0-9]+$ && "$curr_p2" \< "$prev_p2" ]]; then
        new_list="$new_list $item"
        prev="$prev"
        changed=1
      else
        new_list="$new_list $prev"
        prev="$item"
      fi
    else
      new_list="$new_list $prev"
      prev="$item"
    fi
  done

  new_list="$new_list $prev"
  list="$new_list"
done


for oldKey in $list; do
  suffix="${oldKey:105}"

  p1=$(echo "$suffix" | cut -d'_' -f1)
  p2=$(echo "$suffix" | cut -d'_' -f2)
  p3=$(echo "$suffix" | cut -d'_' -f3)

  if [[ -z "$p1" && "$p2" =~ ^[0-9]+$ ]]; then
    suffix=""
    if [[ "$p3" == "mongodb/mongodb.checkpoints.json" ]]; then suffix="/mongodb.checkpoints.json"; fi
    if [[ "$p3" == "sftp/checkpoints.json" ]];            then suffix="/checkpoints.json"        ; fi
    if [[ "$p3" == "smb/checkpoints.json" ]];             then suffix="/checkpoints.json"        ; fi
    if [[ "$p3" == "database/checkpoints.json" ]];        then suffix="/checkpoints.json"        ; fi
    if [[ "$p3" == "http" ]];                             then suffix="/http_checkpoints.json"   ; fi

    if [[ -n "$suffix" ]]; then
      prefix="${oldKey:0:105}"
      newKey=$(echo "$prefix""$suffix")
      oldConnectionId=$(echo "$oldKey" | cut -d'/' -f2)
      newConnectionId=$(echo "$newKey" | cut -d'/' -f2)

      echo ">>>>> rename object key in bucket r-space-siem-collector-objects"
      echo "  old key: $oldKey"
      echo "  new key: $newKey"
      echo "  get obj: $(nats object get r-space-siem-collector-objects "$oldKey" -f -O ./tmp.json)"

      content=$(cat tmp.json)
      contentIndex=$((${#oldConnectionId}+18))
      contentSuffix="${content:$contentIndex}"
      newContent="{\"connection_id\":\"""$newConnectionId""$contentSuffix"
      echo "$newContent" > ./tmp_new.json

      echo "  put obj: $(nats object put r-space-siem-collector-objects --name "$newKey" -f ./tmp_new.json)"
      echo "  del obj: $(nats object del r-space-siem-collector-objects "$oldKey" -f)"
    fi
  fi
done

Здесь:

<object_id> — идентификатор коллектора или конвейера, для которого необходимо изменить настройки NATS Object Store.

При необходимости вы можете указать несколько идентификаторов, разделяя их вертикальной чертой. Например: 7f901c19-451f-698e-a5f4-6ea53f074bb6|e7bebc60-41cf-8bf3-68b1-382332a74f57.

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

Обновите настройки NATS Object Store. Для этого выполните следующие действия для каждого коллектора в кластере:

Отключите конфигурации всех конвейеров в коллекторе.
Выключите коллектор.
Отредактируйте скрипт script.sh, добавленный ранее, указав идентификатор коллектора вместо <object_id>.
Запустите скрипт, например, с помощью команды:
```
sh script.sh
```
Для коллектора будут обновлены настройки NATS Object Store.
Включите коллектор и установите конфигурации его конвейеров.

Вы также можете обновить настройки сразу всех коллекторов в кластере. Для этого:

Отключите конфигурации всех конвейеров во всех коллекторах кластера.
Выключите все коллекторы в кластере.
Укажите пустое значение вместо <object_id> в скрипте script.sh.
Запустите скрипт, например, с помощью команды:
```
sh script.sh
```
Включите нужные коллекторы и установите конфигурации их конвейеров.

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

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

Особенности обновления системы с версии ниже 2.8.0

Прекращение поддержки прямого обновления с версий ниже 2.3.0

Начиная с версии 2.8.0 прямое обновление системы с версий ниже 2.3.0 не поддерживается. При попытке запуска такого обновления отобразится сообщение о необходимости сначала обновить систему до версии 2.3.0 или выше.

В таком случае следует выполнять обновление в два этапа:

С версии ниже 2.3.0 — до 2.7.0 или любой ее патч-версии (2.7.x): например, 2.7.1 или 2.7.2.
С версии 2.7.x — до 2.8.0 или выше.

Изменение функций поиска подстрок в элементах экспертизы

Начиная с версии 2.8.0 в следующих VRL-функциях исправлен тип первого аргумента с любого (any) на строку (string):

В связи с этим перед обновлением необходимо обновить элементы экспертизы в соответствии с актуальным синтаксисом данных функций.

Обновление системы

Чтобы обновить экземпляр системы до новой версии:

Запустите установщик и выберите режим установки Updating previous version.

install updating

При выборе обновления выполняется распаковка пакетов в каталог продукта и управление передается скрипту установщика.

Если версии ClickHouse, PostgreSQL и/или NATS, установленные в кластере, не соответствуют техническим требованиям, при запуске обновления системы установщик попытается обновить их автоматически.

Если версии компонентов значительно устарели, автоматическое обновление будет недоступно и отобразится сообщение с ключевыми словами Please perform a manual update. Пример для PostgreSQL:

Please perform a manual update postgresql to required version >= 15.0.0.

В таком случае выполните ручное обновление необходимых компонентов согласно инструкциям из раздела Ручное обновление компонентов системы и перезапустите обновление системы.

Автоматическое обновление доступно для ClickHouse и PostgreSQL, только если они установлены в кластере Kubernetes. Обновление вынесенных инсталляций ClickHouse и PostgreSQL администратор кластера должен выполнять самостоятельно.

Выберите пространство имен, в котором установлен экземпляр системы.

Вы можете получить название пространства имен, в котором установлена система, с помощью утилиты evoctl.
Задайте параметры Ansible:
1. Имя пользователя.
2. Метод аутентификации: через ключ или по паролю.
3. Пароль: задайте и подтвердите пароль пользователя.

В целевом пространстве имен будут обновлены все чарты модуля Streams.

После обновления на экран будет выведен URL-адрес для подключения к системе.

Обновление сателлитов

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

Скопируйте архив TLS-сертификатов $SETUP_ROOT_DIR/r-vision/nats-tls.tar.gz из основного экземпляра системы в каталог $SETUP_ROOT_DIR/r-vision сателлита.

Каталоги установки (значения переменной $SETUP_ROOT_DIR) основного экземпляра системы и сателлита могут отличаться.

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

Действия после обновления

После обновления выполните следующие действия:

Создание недостающих пользователей и таблиц ClickHouse
Перезапуск коллекторов и конвейеров

Создание недостающих пользователей и таблиц ClickHouse

После обновления системы необходимо создать необходимых пользователей и недостающие таблицы в ClickHouse, если они отсутствуют. Для этого выполните следующий скрипт на любом экземпляре кластера ClickHouse:

-- Создать пользователя owner и выдать ему необходимые права.
CREATE USER IF NOT EXISTS owner ON CLUSTER '{cluster}' IDENTIFIED WITH sha256_password BY '<OwnerPassword>';
GRANT ON CLUSTER '{cluster}' ALL on default.* TO 'owner';
GRANT ON CLUSTER '{cluster}' REMOTE on *.* TO 'owner';
GRANT ON CLUSTER '{cluster}' CLUSTER on *.* TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.disks TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.storage_policies TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.query_log TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.columns TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts_columns TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.tables TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.clusters TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.asynchronous_metrics TO 'owner';

-- Создать пользователя writer и выдать ему необходимые права.
CREATE USER IF NOT EXISTS writer ON CLUSTER '{cluster}' IDENTIFIED WITH sha256_password BY '<WriterPassword>';
GRANT ON CLUSTER '{cluster}' SELECT ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' INSERT ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' ALTER UPDATE ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' ALTER DELETE ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' REMOTE on *.* TO 'writer';
GRANT ON CLUSTER '{cluster}' CLUSTER on *.* TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.disks TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.storage_policies TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.query_log TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.columns TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts_columns TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.tables TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.clusters TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.asynchronous_metrics TO 'writer';

-- Создать пользователя reader и выдать ему необходимые права.
CREATE USER IF NOT EXISTS reader ON CLUSTER '{cluster}' IDENTIFIED WITH sha256_password BY '<ReaderPassword>';
GRANT ON CLUSTER '{cluster}' SELECT ON default.* TO 'reader';
GRANT ON CLUSTER '{cluster}' REMOTE on *.* TO 'reader';
GRANT ON CLUSTER '{cluster}' CLUSTER on *.* TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.disks TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.storage_policies TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.query_log TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.columns TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts_columns TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.tables TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.clusters TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.asynchronous_metrics TO 'reader';

-- Создать необходимые распределенные таблицы.
CREATE TABLE IF NOT EXISTS default.disks ON CLUSTER '{cluster}' AS system.disks ENGINE = Distributed('{cluster}', system, disks);
CREATE TABLE IF NOT EXISTS default.storage_policies ON CLUSTER '{cluster}' AS system.storage_policies ENGINE = Distributed('{cluster}', system, storage_policies);
CREATE TABLE IF NOT EXISTS default.parts ON CLUSTER '{cluster}' AS system.parts ENGINE = Distributed('{cluster}', system, parts);
CREATE TABLE IF NOT EXISTS default.query_log ON CLUSTER '{cluster}' AS system.query_log ENGINE = Distributed('{cluster}', system, query_log);
CREATE TABLE IF NOT EXISTS default.columns ON CLUSTER '{cluster}' AS system.columns ENGINE = Distributed('{cluster}', system, columns);
CREATE TABLE IF NOT EXISTS default.parts_columns ON CLUSTER '{cluster}' AS system.parts_columns ENGINE = Distributed('{cluster}', system, parts_columns);
CREATE TABLE IF NOT EXISTS default.tables ON CLUSTER '{cluster}' AS system.tables ENGINE = Distributed('{cluster}', system, tables);
CREATE TABLE IF NOT EXISTS default.clusters ON CLUSTER '{cluster}' AS system.clusters ENGINE = Distributed('{cluster}', system, clusters);
CREATE TABLE IF NOT EXISTS default.asynchronous_metrics ON CLUSTER '{cluster}' AS system.asynchronous_metrics ENGINE = Distributed('{cluster}', system, asynchronous_metrics);

Здесь <OwnerPassword>, <WriterPassword> и <ReaderPassword> — это пароли пользователей owner, writer и reader соответственно.

Необходимо указывать пароли, которые были использованы на этапах настройки общесистемного экземпляра ClickHouse и ClickHouse для событий ИБ при установке системы.

Перезапуск коллекторов и конвейеров

После обновления рекомендуется выключить все работающие коллекторы и конвейеры и включить их заново, чтобы обновить образы коллекторов и конфигурации конвейеров.

Чтобы выполнить вход в систему:

В адресной строке браузера введите URL-адрес, выведенный на экран после обновления системы. На экране отобразится страница авторизации.
Укажите логин и пароль учетной записи пользователя и нажмите на кнопку Войти.

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

Была ли полезна эта страница?

Обратная связь

Обновление системы

Подготовка к обновлению

Подготовительные действия перед обновлением

Смена доменного имени системы

Настройка шифрования трафика между узлами кластера

Включение шифрования трафика

Рекомендации после включения шифрования

Обновление ключей WireGuard

Особенности обновления системы с определенных версий

Обновление системы

Обновление сателлитов

Действия после обновления

Создание недостающих пользователей и таблиц ClickHouse

Перезапуск коллекторов и конвейеров

Авторизация в системе