Устранение проблем при эксплуатации системы

В данном разделе приведены возможные проблемы при работе системы и способы их решения.

ClickHouse: не выполняются распределенные запросы (on cluster)

Версия системы: 2.0.0 и выше.

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

В консоли кластера ClickHouse не выполняются распределенные запросы, содержащие секцию on cluster. Например, не создается распределенная таблица test:

create table test on cluster '{cluster}' (id UUID) Engine = MergeTree order by id

Причина: сбой запроса, который привел к невозможности обработки очереди запросов.

Решение:

  1. Получите список подов, на которых расположены шарды ClickHouse:

    kubectl -n <namespace> get pods -l app.kubernetes.io/name=clickhouse

    Здесь:

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

  2. Найдите в логах шардов ошибку очереди запросов:

    kubectl logs -n <namespace> <shard_name> --all-containers=true | grep "DB::Exception: Cannot create status dirs"

    Здесь:

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

    • <shard_name> — имя шарда из списка, полученного на шаге 1, например, clickhouse-shard1-0.

      Пример ошибки очереди запросов:

      2024.12.12 10:31:51.883015 [ 410 ] {} <Error> DDLWorker: Unexpected error (1559 times in a row), will try to restart main thread: Code: 341. DB::Exception: Cannot create status dirs for /clickhouse/task_queue/ddl/query-0007458048, most likely because someone is deleting it concurrently. (UNFINISHED), Stack trace (when copying this message, always include the lines below)

  3. Сохраните идентификатор запроса в очереди, вызвавшего ошибку: в примере выше — /clickhouse/task_queue/ddl/query-0007458048.

  4. Проверьте размер очереди запросов ClickHouse на шарде, на котором возникла ошибка:

    kubectl exec -n <namespace> <clickhouse_shard_name> – clickhouse-keeper-client -h 127.0.0.1 -p 2181 -q "ls 'clickhouse/task_queue/ddl'" 2>/dev/null | tr ' ' "\n"| wc -l

    Здесь:

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

    • <clickhouse_shard_name> — имя шарда ClickHouse, на котором возникла ошибка, например, clickhouse-shard1-0.

  5. Удалите запрос из очереди ClickHouse:

    kubectl exec -n <namespace> <clickhouse_shard_name> -it – clickhouse-keeper-client -h 127.0.0.1 -p 2181 -q "rmr '<query_id>'"

    Здесь:

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

    • <clickhouse_shard_name> — имя шарда ClickHouse, на котором возникла ошибка, например, clickhouse-shard1-0;

    • <query_id> — идентификатор запроса из сообщения об ошибке, полученный на шаге 3.

  6. Повторно проверьте размер очереди запросов ClickHouse, выполнив команду из шага 4. Убедитесь, что размер очереди уменьшается, что подтверждает возобновление ее обработки.

  7. Повторно выполните распределенный запрос.

ClickHouse: ошибка аутентификации при выполнении запросов

Версия системы:

  • ниже 2.3.0 — с использованием Consul;

  • 2.3.0 и выше — с использованием NATS Key/Value.

Проявление: запросы к БД ClickHouse завершаются с ошибкой Authentication failed: password is incorrect, or there is no user with such name. Это может происходить в любом разделе, где осуществляется работа с событиями, например, в разделе Поиск.

Причина: не совпадают пароли пользователей owner, reader или writer в объектном хранилище (Consul или NATS Key/Value) и в конфигурации ClickHouse.

Решение: установите единые пароли в объектном хранилище и в конфигурации ClickHouse. Для этого:

  1. Получите пароли пользователей из объектного хранилища:

    • NATS Key/Value (для версии системы 2.3.0 и выше):

      1. Подключитесь к терминалу управляющего узла кластера.

      2. Подключитесь к терминалу пода nats-main-box, выполнив следующую команду:

        kubectl exec -itn <namespace> deployment/nats-main-box -c nats-box -- sh

        Здесь:

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

      3. Получите пути к ключам, в которых хранятся пароли ClickHouse, выполнив следующую команду:

        nats kv ls siem
        Пример путей к ключам, в которых хранятся пароли ClickHouse 
        space-main/evo-clickhouse1/owner
space-main/evo-clickhouse1/reader
space-main/evo-clickhouse1/writer

      4. Просмотрите пароли пользователей ClickHouse, выполнив для каждого из них команду:

        nats kv get siem <path_to_key> --raw

        Здесь:

        • <path_to_key> — путь к ключу, где хранится пароль.

    • Consul (для версии системы ниже 2.3.0):

      1. Осуществите проброс портов объектного хранилища, выполнив на хосте с сетевым доступом к управляющему узлу кластера следующую команду:

        kubectl -n <namespace> port-forward service/consul-ui <local_port>:80

        Здесь:

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

        • <local_port> — порт на хосте, по которому будет осуществляться доступ к Consul.

      2. В браузере откройте URL localhost:<local_port>, где <local_port> — порт с предыдущего шага. Отобразится панель управления Consul.

      3. Перейдите в раздел Key/Value → siem → siem/clickhouse1 → users.

      4. Откройте ключи owner, reader и writer. Их значения — пароли соответствующих пользователей.

  2. Определите, пароль какого пользователя в конфигурации ClickHouse не совпадает с паролем в хранилище. Для этого:

    1. Осуществите проброс портов ClickHouse, выполнив на хосте с сетевым доступом к управляющему узлу кластера следующую команду:

      kubectl port-forward -n <namespace> service/clickhouse <local_click_port>:8123

      Здесь:

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

      • <local_click_port> — порт на хосте, по которому будет осуществляться доступ к ClickHouse.

    2. В браузере откройте URL localhost:<local_click_port>/play, где <local_click_port> — порт с предыдущего шага. Отобразится графический клиент ClickHouse.

    3. Выполните следующие действия для каждого из пользователей owner, reader и writer:

      1. Введите логин и пароль в поля в правом верхнем углу экрана.

      2. Выполните любой запрос, например, SELECT * FROM default.disks.

        Если возникает ошибка Authentication failed: password is incorrect, or there is no user with such name. (AUTHENTICATION_FAILED), то пароль текущего пользователя необходимо исправить в таблице пользователей ClickHouse.

  3. Получите список подов, на которых расположены шарды ClickHouse:

    kubectl -n <namespace> get pods -l app.kubernetes.io/name=clickhouse

    Здесь:

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

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

    1. Чтобы получить имя пользователя ClickHouse, выведите подробную информацию о поде шарда:

      kubectl -n <namespace> describe pod <shard_pod>

      Здесь:

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

      • <shard_pod> — имя пода, на котором расположен шард ClickHouse.

        Имя пользователя ClickHouse расположено в разделе Containers → <имя контейнера ClickHouse> → Environment → CLICKHOUSE_ADMIN_USER.

    2. Получите пароль пользователя ClickHouse из секрета clickhouse и декодируйте его из base64:

      kubectl -n <namespace> get secret clickhouse -o jsonpath='{.data.admin-password}' | base64 -d

      Здесь:

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

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

    kubectl exec -n <namespace> <shard_pod> -- clickhouse-client --user <clickhouse_user> --password <clickhouse_password> "ALTER USER <user_to_edit> IDENTIFIED BY '<password_from_storage>'"

    Здесь:

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

    • <shard_pod> — имя пода, на котором расположен шард ClickHouse.

    • <clickhouse_user> — имя пользователя ClickHouse, полученное на шаге 4.

    • <clickhouse_password> — пароль пользователя ClickHouse, полученный на шаге 4.

    • <user_to_edit> — пользователь, пароль которого нужно изменить: owner, reader или writer.

    • <password_from_storage> — пароль пользователя из объектного хранилища, полученный на шаге 1.

  6. Для пользователя writer также следует обновить пароль в карте конфигурации clickhouse. Чтобы открыть ее, выполните следующую команду:

    kubectl -n <namespace> edit configmap clickhouse

    Укажите пароль пользователя writer из объектного хранилища как значение ключа remote_servers → default → shard → replica → password.

    Ключей remote_servers → default → shard → replica → password столько же, сколько шардов. Необходимо установить пароль из объектного хранилища для каждого шарда.

  7. Удалите поды ClickHouse. Они будут пересозданы автоматически и начнут использовать новые пароли:

    kubectl -n <namespace> delete pods -l app.kubernetes.io/name=clickhouse

    Здесь:

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

NATS: переполнение стрима events-siem-audit-prepared-audit

Версия системы: 2.2.0 и выше.

Проявление: внутренние ошибки при работе с различными разделами системы, в том числе Ресурсы → Коллекторы, Ресурсы → Активные списки, Поиск, Инструменты → Аудит источников.

Причина: переполнение стрима NATS events-siem-audit-prepared-audit, сообщения из которого не вычитываются другими сервисами системы.

Проверить размер стрима events-siem-audit-prepared-audit можно следующим образом:

  1. Получите полное имя пода сервиса nats-main-box, выполнив следующую команду:

    kubectl -n <namespace> get pods -l app.kubernetes.io/instance=nats-main | grep nats-main-box

    Здесь:

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

    Пример вывода имени пода nats-main-box 
    nats-main-box-658b9fc759-x9fkb   1/1     Running   2 (61d ago)   118d

    В примере выше полное имя пода nats-main-box — nats-main-box-658b9fc759-x9fkb.

  2. Просмотрите информацию о стриме events-siem-audit-prepared-audit, выполнив следующую команду:

    kubectl exec -n <namespace> <nats_main_box_name> -- nats stream info events-siem-audit-prepared-audit

    Здесь:

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

    • <nats_main_box_name> — полное имя пода nats-main-box, полученное на предыдущем шаге.

    Пример вывода информации о стриме, когда он переполнен 
    Information for Stream events-siem-audit-prepared-audit created 2025-04-24 09:16:55

              Subjects: events.siem.audit.prepared-audit
              Replicas: 1
               Storage: File

Options:

             Retention: Interest
       Acknowledgments: true
        Discard Policy: Old
      Duplicate Window: 2m0s
     Allows Msg Delete: true
          Allows Purge: true
        Allows Rollups: false

Limits:

      Maximum Messages: unlimited
   Maximum Per Subject: unlimited
         Maximum Bytes: unlimited
           Maximum Age: unlimited
  Maximum Message Size: unlimited
     Maximum Consumers: unlimited

State:

              Messages: 3,818,150
                 Bytes: 28 GiB
        First Sequence: 4,237,386 @ 2025-06-16 11:53:57
         Last Sequence: 7,419,535 @ 2025-07-24 10:58:30
      Active Consumers: 1

В примере выше стрим переполнен: его размер (State → Bytes) достиг 28 ГБ. Нормальный размер стрима events-siem-audit-prepared-audit должен находиться около 0 КБ, поскольку при нормальной работе системы сообщения вычитываются в режиме реального времени.

Решение:

Если версия системы ниже 2.3.0: необходим дополнительный анализ для поиска сервиса-получателя, который не вычитывает сообщения из стрима. Обратитесь в службу поддержки по адресу support@rvision.ru.

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

  1. Получите список деплойментов коллекторов в системе, выполнив следующую команду:

    kubectl -n <namespace> get deployments | grep -- -collector-

    Здесь:

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

    Пример вывода списка деплойментов 
    collector-9c7baa5d-011a-4fdb-84d9-dd577303782e-main     1/1     1            1           61d
wl.db66eb9e-6a03-4919-a23a-edf8fc8a9de7-collector-main  1/1     1            1           61d

    Деплойменты из списка, имя которых начинается с префикса collector, используют версию коллектора ниже 2.3.0. В примере это collector-9c7baa5d-011a-4fdb-84d9-dd577303782e-main.

  2. Удалите деплойменты коллекторов, использующих версию коллектора ниже 2.3.0, выполнив для каждого из них следующую команду:

    kubectl -n <namespace> delete deployment <deployment>

    Здесь:

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

    • <deployment> — имя деплоймента, полученное на предыдущем шаге.

  3. Получите полное имя пода сервиса nats-main-box, выполнив следующую команду:

    kubectl -n <namespace> get pods -l app.kubernetes.io/instance=nats-main | grep nats-main-box

    Здесь:

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

    Пример вывода имени пода nats-main-box 
    nats-main-box-658b9fc759-x9fkb   1/1     Running   2 (61d ago)   118d

    В примере выше полное имя пода nats-main-box — nats-main-box-658b9fc759-x9fkb.

  4. Удалите стрим events-siem-audit-prepared-audit из NATS, выполнив следующую команду:

    kubectl exec -n <namespace> <nats_main_box_name> -- nats stream rm events-siem-audit-prepared-audit

    Здесь:

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

    • <nats_main_box_name> — полное имя пода nats-main-box, полученное на предыдущем шаге.

Работа с событиями: ошибки в логах сервисов

Версия системы: 1.0.0 и выше. Должен быть установлен провайдер хранилища Longhorn. Инсталляция ClickHouse находится внутри кластера.

Проявление: при работе системы с потоком событий в логах сервисов возникает ошибка, содержащая строку EXT4-fs error (device sdu).

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

Решение: приведите конфигурацию оборудования в соответствие с техническими требованиями системы.

Работа с событиями: не работает поиск, не строятся графики на дашбордах

Версия системы: 1.0.0 и выше.

Проявление: не работает поиск, не строятся графики на дашбордах.

При выполнении поискового запроса в консоли браузера возникает ошибка вида:

search::search::endpoints::simplified_search: error: Invalid state: Unable get connection info: Unable to get connection info for event storage: grpc status: code=13, message=error trying to connect: tcp open error: Address family not supported by protocol (os error 97)

Причина:

  • либо gRPC-порт инсталляции ClickHouse недоступен или не совпадает с указанным при установке системы, поэтому сервис поиска search не может подключиться к ClickHouse;

  • либо сервис поиска не может подключиться к сервису event-storage-manager.

Решение:

  1. Получите номер gRPC-порта из значения ключа grpc_port конфигурации ClickHouse.

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

  3. Просмотрите логи пода event-storage-manager:

    1. Получите полное имя пода сервиса event-storage-manager, выполнив следующую команду:

      kubectl -n <namespace> get pods -l app.kubernetes.io/name=evo.siem.event-storage-manager

      Здесь:

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

        Пример вывода имени пода event-storage-manager 
        NAME                                              READY   STATUS    RESTARTS   AGE
evo.siem.event-storage-manager-7db4bc4c99-wlqlk   1/1     Running   0          21m

        В примере выше полное имя пода event-storage-manager — evo.siem.event-storage-manager-7db4bc4c99-wlqlk.

    2. Для просмотра логов пода event-storage-manager используйте руководство Просмотр логов пода. В качестве имени пода (<pod_name>) укажите полное имя пода event-storage-manager, полученное на предыдущем шаге.

  4. В логах пода может присутствовать номер gRPC-порта ClickHouse, используемого сервисом event-storage-manager, как значение ключа clickHouseConnectionInfo → port. В примере ниже — 9100:

    {"level":10,"time":1738668412977,"pid":1,"hostname":"evo.siem.event-storage-manager-66667479f5-74tn2","context":"EventStorageService","clickHouseConnectionInfo":{"host":"clickhouse","password":"REDACTED","port":9100,"user":"owner"},"requestId":"[missing]","msg":"connection info"}

    1. Если ключ clickHouseConnectionInfo → port присутствует в логах и номер порта отличается от номера в конфигурации ClickHouse:

      1. Укажите номер порта из clickHouseConnectionInfo → port как значение ключа grpc_port конфигурации ClickHouse.

      2. Удалите поды ClickHouse. Они будут пересозданы автоматически и будут использовать новый gRPC-порт:

        kubectl -n <namespace> delete pods -l app.kubernetes.io/name=clickhouse

        Здесь:

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

    2. Если ключ clickHouseConnectionInfo → port отсутствует или номера портов в конфигурации ClickHouse и логах совпадают, удалите поды сервисов search и bff:

      kubectl -n <namespace> delete pods -l app.kubernetes.io/name=evo.siem.search
kubectl -n <namespace> delete pods -l app.kubernetes.io/name=evo.core.bff

      Здесь:

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

        Удаленные поды будут автоматически пересозданы в течение нескольких минут. Когда поды будут иметь статус Running, можно будет повторить поиск или построение графика.

        Если после пересоздания подов поиск и графики на дашбордах не работают, обратитесь в службу поддержки.

WebSocket: ошибки запросов

Версия системы: 1.0.0 и выше.

Проявление: не работают функции, использующие протокол WebSocket: например, поиск, импорт элементов экспертизы или скачивание отчетов. В консоли браузера запросы по протоколу WebSocket завершаются с ошибками.

Причина: для сервиса API evo.siem.bff не включены подписки WebSocket, или есть проблема с соединениями WebSocket на уровне инфраструктуры.

Решение:

  1. Если версия системы — 1.10.2 и выше:

    1. Откройте карту конфигурации evo.siem-bff-env, выполнив следующую команду:

      kubectl -n <namespace> edit configmap evo.siem-bff-env

      Здесь:

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

    2. Если переменная SIEM_BFF_GRAPHQL_ENABLE_PLAYGROUND имеет значение "false", включите подписки WebSocket:

      1. Установите для переменной SIEM_BFF_GRAPHQL_SUBSCRIPTION_TRANSPORT_WS_ENABLED значение "true".

      2. Закройте карту конфигурации.

      3. Удалите под сервиса evo.siem.bff, выполнив следующую команду:

        kubectl -n <namespace> delete pods -l app.kubernetes.io/name=evo.siem.bff

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

  2. Если версия системы ниже 1.10.2, или способ выше не решил проблему, или переменная SIEM_BFF_GRAPHQL_ENABLE_PLAYGROUND уже имеет значение "true", выполните запрос с помощью любой утилиты wss, например, wscat, к следующему URL:

    wss://<system_url>/api/graphql

    Здесь:

    • <system_url> — URL, по которому осуществляется доступ к системе.

      Если попытка установить WSS-соединение завершается с ошибкой, то вероятная причина проблемы — нарушения в инфраструктуре, в которой установлена система: например, сбой сети, некорректные настройки прокси или ограничение файрвола.

Коллекторы: падение или отсутствие EPS

Версия системы: 1.10.2 и выше.

Проявление: значительное падение EPS (количества событий в секунду) или отсутствие событий на коллекторе.

Ошибки в логе коллектора:

"line": "2024-11-28T11:39:52.739224Z ERROR source{component_kind=\"source\" component_id=4b5ae224-78fc-4c00-9614-5ecb41871f2b_eJ__wBp4vtuHe9YVoOxCm_syslog component_type=socket}: vector::internal_events::codecs: Failed framing bytes. error=Unable to decode input as UTF8 error_code=\"decoder_frame\" error_type=\"parser_failed\" stage=\"processing\" internal_log_rate_limit=true",
"line": "2024-11-28T11:39:52.753215Z ERROR source{component_kind=\"source\" component_id=4b5ae224-78fc-4c00-9614-5ecb41871f2b_eJ__wBp4vtuHe9YVoOxCm_syslog component_type=socket}: vector::topology: An error occurred that Vector couldn't handle: the task panicked and was aborted.",

Причина: выбран некорректный тип точки входа, не соответствующий формату поступающих событий; например, в точку входа типа Syslog поступают события в формате JSON.

Решение: необходимо проверить конфигурацию точек входа конвейеров, установленных в коллекторе, и привести их типы в соответствие с форматом поступающих событий.

Коллекторы: не отображаются метрики коллекторов, конвейеров и элементов конвейеров

Версия системы: 1.0.0 и выше.

Проявление: в карточках коллекторов и конвейеров, а также на элементах конвейеров в режиме активной версии не отображаются метрики.

Причина: поду сервиса сбора метрик Prometheus не хватает размера тома (Persistent Volume Claim) для хранения данных.

Решение: нужно увеличить PVC для Prometheus. Для этого:

  1. Получите имя PVC Prometheus, выполнив следующую команду:

    kubectl -n kube-prometheus-stack describe pod prometheus-kube-prometheus-stack-prometheus-0

    Имя PVC Prometheus является значением ключа Volumes → <prometheus_volume_name> → ClaimName.

    Пример имени PVC Prometheus 
    # ...
Volumes:
  prometheus-kube-prometheus-stack-prometheus-db:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  prometheus-kube-prometheus-stack-prometheus-db-prometheus-kube-prometheus-stack-prometheus-0
    ReadOnly:   false
# ...

    В этом случае имя PVC Prometheus — prometheus-kube-prometheus-stack-prometheus-db-prometheus-kube-prometheus-stack-prometheus-0.

  2. Откройте конфигурацию PVC для Prometheus, выполнив следующую команду:

    kubectl -n kube-prometheus-stack edit pvc <prometheus_pvc_name>

    Здесь:

    • <prometheus_pvc_name> — имя PVC Prometheus, полученное на предыдущем шаге.

  3. Увеличьте размер PVC, отредактировав значение ключа spec → resources → requests → storage. Формат и единицы измерения размеров PVC приведены в документации Kubernetes.

    # ...
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      # Отредактируйте значение этого ключа.
      storage: 15Gi
# ...

  4. Закройте файл. Kubernetes перераспределит дисковое пространство в соответствии с обновленным PVC, и размер тома изменится через некоторое время.

Коллекторы: при установке нового конвейера или перезапуске коллектора не поступают события

Версия системы: 2.1.1 и выше.

Проявление: при установке нового конвейера в коллектор не поступают события на конвейер, или при перезапуске коллектора перестают поступать события в весь коллектор.

Причина: занят порт, который используют конвейеры коллектора.

Решение:

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

  2. Скопируйте идентификатор коллектора из его карточки.

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

    kubectl -n <namespace> get svc | grep <collector_id>

    Здесь:

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

    • <collector_id> — идентификатор коллектора, полученный на предыдущем шаге.

    Пример вывода команды для коллектора с идентификатором a6985d07-6400-49ef-a47c-e5c1a411f8f3 
    wl-a6985d07-6400-49ef-a47c-e5c1a411f8f3-collector-main         ClusterIP   10.233.37.47    <none>        31537/TCP,8686/TCP
wl-a6985d07-6400-49ef-a47c-e5c1a411f8f3-collector-main-ports   NodePort    10.233.10.154   <none>        31537:31537/TCP

    Один из конвейеров, запущенных в коллекторе, использует TCP-порт 31537.

  4. Обратите внимание на сервис main-ports с типом NodePort:

    1. Если в выводе команды есть все порты, используемые конвейерами, но события все равно не поступают в систему, обратитесь в службу поддержки по адресу support@rvision.ru.

    2. Если сервис main-ports отсутствует в выводе команды, или в списке его портов нет какого-либо из портов, который используют конвейеры, выполните следующие действия:

      1. Получите полное имя пода коллектора, выполнив команду ниже.

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

        		 
        kubectl -n <namespace> get pods -l app.kubernetes.io/name=wl-<collector_id>

        Здесь:

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

        • <collector_id> — идентификатор коллектора, полученный на предыдущем шаге.

        Пример вывода имени пода для коллектора с идентификатором d712394d-90ae-41fb-b998-2dd5b580d77d 
        NAME                                                              READY   STATUS    RESTARTS   AGE
wl.d712394d-90ae-41fb-b998-2dd5b580d77d-collector-main-59fzz62v   2/2     Running   0          3h10m

      2. Получите список событий пода коллектора, выполнив следующую команду:

        kubectl -n <namespace> events --for pod/<collector_pod_name>

        Здесь:

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

        • <collector_pod_name> — полное имя пода коллектора, полученное на предыдущем шаге.

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

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

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

Точка входа типа Database: загрузка драйвера прекращается по таймауту

Версия системы: 2.3.0 и выше.

Проявление: загрузка файла драйвера в точку входа типа Database происходит слишком долго и прекращается по таймауту.

Причина: недостаточно ресурсов сервиса evo.siem.driver-manager.

Решение: увеличьте ресурсы сервиса evo.siem.driver-manager. Для этого:

  1. Подключитесь к кластеру с помощью Lens.

  2. В выпадающем меню свойств кластера выберите пункт Workloads → Deployments.

  3. Выберите пространство имен, в котором установлен кластер, в выпадающем списке Select Namespace в правой части экрана.

  4. Выберите сервис evo.siem.driver-manager из списка.

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

  6. В отобразившейся конфигурации увеличьте значения лимитов оперативной памяти и процессора в секции resources:

    resources:
  limits:
    cpu: 500m
    memory: 300Mi
  requests:
    cpu: 25m
    memory: 100Mi

  7. Нажмите на кнопку Save. Новая конфигурация будет применена.

Точка входа типа Database (MS SQL): не поступают события

Версия системы: 1.10.2 и выше.

Проявление: не поступают события в точку входа типа Database с драйвером MS SQL.

Ошибки в логе коллектора:

ERROR vector::sources::database: JDBC Server unexpected stopped error=Unable to open JDBC Connection
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.

Причина: ошибка при разборе сертификата сервера БД, что приводит к невозможности установить защищенное SSL-соединение.

Решение: отключите SSL для соединения с БД. Для этого измените настройки точки входа, добавив в Адрес подключения параметры trustServerCertificate=false и encrypt=false.

Пример строки подключения:

jdbc:sqlserver://localhost;user=user;password=password;trustServerCertificate=false;encrypt=false
Если подобная ошибка возникает при использовании другой СУБД, кроме MS SQL, получите информацию о способах отключения SSL в официальной документации JDBC-драйвера соответствующей СУБД.

Базы данных событий: не удается зарегистрировать новую базу данных

Версия системы: 1.0.0 и выше. ClickHouse установлен на выделенном сервере (вынесенная установка).

Проявление: в интерфейсе системы не удается зарегистрировать новую базу данных событий. В логах сервера ClickHouse возникает ошибка вида:

Error when deleting table of event storage: All connection tries failed while connecting to ZooKeeper. nodes: [fe80::20c:29ff:fe89:fa80%ens33]:9181\nPoco::Exception. Code: 1000, e.code() = 111, Connection refused (version 24.3.2.23 (official build)), [fe80::20c:29ff:fe89:fa80%ens33]:9181\n

Причина: если во время установки системы выбрана вынесенная установка ClickHouse и указано полное доменное имя (FQDN) сервера ClickHouse, то при выполнении запроса доменное имя по умолчанию преобразуется в адрес IPv6. Это приводит к ошибке, если у сервера ClickHouse нет IPv6-адреса.

Решение: следует отключить использование IPv6 на сервере, на котором установлен ClickHouse. Для этого выполните следующие действия на сервере, на котором установлен ClickHouse:

  1. Откройте файл /etc/sysctl.conf.

  2. Добавьте в файл следующие строки:

    net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.local.disable_ipv6 = 1

  3. Сохраните файл.

  4. Примените изменения с помощью следующей команды:

    sysctl -p

  5. Перезагрузите службу ClickHouse:

    sudo service clickhouse-server restart

Хранилища событий: не отображаются события за последние несколько минут

Версия системы: 2.0.0 и выше.

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

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

Решение: настройте синхронизацию времени на узлах согласно документации операционной системы, которая установлена на этих узлах. Например, документация по синхронизации времени в Astra Linux расположена на справочном портале разработчика ОС.

Хранилища событий: не поступают новые события из-за превышения максимального размера события

Версия системы: 2.3.0 и выше.

Проявление: в хранилище событий не поступают события. В логах пода nats-space возникают ошибки, содержащие сообщение maximum payload exceeded, например:

[74] 2025/07/23 09:03:12.276656 [ERR] 10.233.112.88:45352 - cid:401631 - maximum payload exceeded: 13466645 vs 4194304

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

Решение: увеличьте значение параметра max_payload. Для этого:

  1. Добавьте параметр max_payload в карты конфигурации nats-main-config и nats-space-config. Для каждой из них выполните следующие действия:

    1. Откройте карту конфигурации, выполнив следующую команду:

      kubectl -n <namespace> edit configmap <configmap>

      Здесь:

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

      • <configmap> — имя карты конфигурации: nats-main-config или nats-space-config.

    2. По пути data → nats.conf добавьте ключ max_payload. В качестве значения этого ключа укажите необходимый максимальный размер события в байтах.

      Пример карты конфигурации с ключом max_payload 
      data:
  nats.conf: |
    {
      "http_port": 8222,
      "jetstream": {
        "domain": "main",
        "max_file_store": 30Gi,
        "max_memory_store": 0,
        "store_dir": "/data"
      },
      "lame_duck_duration": "30s",
      "lame_duck_grace_period": "10s",
      "leafnodes": {
        "no_advertise": true,
        "port": 7422
      },
      # Добавьте данный ключ.
      "max_payload": 13631488,
      "pid_file": "/var/run/nats/nats.pid",
      "port": 4222,
      "server_name": $SERVER_NAME
    }

  2. Подождите несколько минут. Когда Kubernetes применит новую конфигурацию, события начнут поступать в систему.

    Если новая конфигурация не применяется в течение длительного времени, удалите поды nats-main и nats-space, выполнив следующие команды:

    kubectl -n <namespace> delete pods -l app.kubernetes.io/instance=nats-main
kubectl -n <namespace> delete pods -l app.kubernetes.io/instance=nats-space

    Здесь:

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

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

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

  1. Перейдите в раздел Поиск.

  2. В списке хранилищ событий выберите хранилище, для которого наблюдалась проблема.

  3. Выполните следующий запрос:

    select * where length(toString(data)) > <event_size>

    Здесь:

    • <event_size> — размер события в байтах.

Возможные причины появления событий большого размера:

  • Если проблема возникает в хранилище аудита:

    • Некорректная настройка параметров системы.

    • Ошибка в логике работы системы.

  • Если проблема возникает не в хранилище событий аудита: ошибка настройки конвейера, отправляющего события в глобальную шину, которая использует NATS.

Если вы считаете, что события большого размера появились из-за ошибки в логике работы системы, обратитесь в службу поддержки по адресу support@rvision.ru.

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

Версия системы: 1.0.0 и выше.

Проявление: возникает внутренняя ошибка сервера при поиске в хранилище событий аудита или в хранилище событий аудита не поступают новые события.

Причина: на некоторых шардах ClickHouse отсутствует таблица, соответствующая хранилищу событий аудита.

Решение:

  1. Получите ID хранилища событий (далее <TABLE_ID>) из его карточки.

  2. Получите список подов, на которых расположены шарды ClickHouse:

    kubectl -n <namespace> get pods -l app.kubernetes.io/name=clickhouse

    Здесь:

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

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

    1. Чтобы получить имя пользователя ClickHouse, выведите подробную информацию о поде шарда:

      kubectl -n <namespace> describe pod <shard_pod>

      Здесь:

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

      • <shard_pod> — имя пода, на котором расположен шард ClickHouse.

        Имя пользователя ClickHouse расположено в разделе Containers → <имя контейнера ClickHouse> → Environment → CLICKHOUSE_ADMIN_USER.

    2. Получите пароль пользователя ClickHouse из секрета clickhouse:

      1. Получите значение секрета:

        kubectl get secret clickhouse -o jsonpath='{.data}'
        Пример вывода значения секрета 
        {"admin-password":"ABCDEF=="}

      2. Декодируйте значение секрета из base64. Результат декодирования — пароль пользователя ClickHouse.

        echo <encoded_secret> | base64 --decode

        Здесь:

        • <encoded_secret> — закодированное значение admin-password с предыдущего шага, например, ABCDEF==.

  4. На каждом шарде ClickHouse проверьте, существуют ли таблицы EventStorage_<TABLE_ID> и EventStorage_<TABLE_ID>_local. Если они отсутствуют, создайте их. Для этого:

    1. Выполните следующие запросы:

      kubectl exec -n <namespace> <shard_pod> -- clickhouse-client --user <clickhouse_user> --password <clickhouse_password> 'SELECT 1 FROM "EventStorage_<TABLE_ID>" LIMIT 1'
      kubectl exec -n <namespace> <shard_pod> -- clickhouse-client --user <clickhouse_user> --password <clickhouse_password> 'SELECT 1 FROM "EventStorage_<TABLE_ID>_local" LIMIT 1'

      Здесь:

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

      • <shard_pod> — имя пода, на котором расположен шард ClickHouse.

      • <clickhouse_user> — имя пользователя ClickHouse.

      • <clickhouse_password> — пароль пользователя ClickHouse.

    2. Изучите результат выполнения запросов:

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

        kubectl exec -n <namespace> <shard_pod> -- clickhouse-client --user <clickhouse_user> --password <clickhouse_password> 'SHOW CREATE TABLE <table_name>'

        Здесь:

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

        • <shard_pod> — имя пода, на котором расположен шард ClickHouse.

        • <clickhouse_user> — имя пользователя ClickHouse.

        • <clickhouse_password> — пароль пользователя ClickHouse.

        • <table_name> — имя таблицы.

          Пример 1. Пример вывода запроса для создания таблицы
          CREATE TABLE default.EventStorage_91bbadf5_0c77_4719_b4d0_dc6b8f298cab\n(\n    `id` UUID,\n    `sourceIp` IPv6,\n    `tenantId` LowCardinality(String),\n    `art` DateTime,\n    `raw` String,\n    `collectorId` LowCardinality(String),\n    `timestamp` DateTime,\n    `type` Enum8(\'Unspecified\' = -1, \'исходное событие\' = 0, \'нормализованное событие\' = 1, \'агрегированное событие\' = 2, \'корреляционное событие\' = 3, \'событие аудита\' = 4),\n    `dvc` IPv6,\n    `rt` DateTime,\n    `suser` LowCardinality(String),\n    `eventType` LowCardinality(String),\n    `moduleKey` LowCardinality(String),\n    `eventRiskLevel` Enum8(\'Unspecified\' = -1, \'DEBUG\' = 1, \'LOW\' = 2, \'MEDIUM\' = 3, \'HIGH\' = 4, \'CRITICAL\' = 5, \'FATAL\' = 6, \'ACCIDENT\' = 7),\n    `data` String,\n    `meta` String\n)\nENGINE = Distributed(\'{cluster}\', \'default\', \'EventStorage_91bbadf5_0c77_4719_b4d0_dc6b8f298cab_local\', rand())

      • Если в результате запроса отображается ошибка UNKNOWN_TABLE, значит, таблица на шарде отсутствует. Чтобы создать ее, используйте запрос, полученный с другого шарда:

        kubectl exec -n <namespace> <shard_pod> -- clickhouse-client --user <clickhouse_user> --password <clickhouse_password> '<create_query>'

        Здесь:

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

        • <shard_pod> — имя пода, на котором расположен шард ClickHouse.

        • <clickhouse_user> — имя пользователя ClickHouse.

        • <clickhouse_password> — пароль пользователя ClickHouse.

        • <create_query> — запрос на создание таблицы, полученный с шарда, на котором она существует.

  5. Получите имя пользователя PostgreSQL, выведя подробную информацию о поде PostgreSQL:

    kubectl -n <namespace> describe pod postgresql-0

    Здесь:

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

      Имя пользователя ClickHouse расположено в разделе Containers → postgresql → Environment → POSTGRES_USER.

  6. Удалите запись о таблице, соответствующей хранилищу событий аудита, из таблицы event_storage БД event_storage PostgreSQL:

    kubectl exec -n <namespace> postgresql-0 -- psql -d event_storage --username=<postgresql_user> -c "DELETE FROM event_storage WHERE table_name = 'EventStorage_<TABLE_ID>'"

    Здесь:

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

    • <postgresql_user> — имя пользователя PostgreSQL.

  7. Удалите под audit-manager:

    kubectl -n <namespace> delete pods -l app.kubernetes.io/name=evo.siem.audit-manager

    Здесь:

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

      При пересоздании пода audit-manager таблица, соответствующая хранилищу событий аудита, будет создана заново.

Если после выполнения вышеописанных действий события аудита не начали поступать в систему и версия системы 2.3.0 и выше, обратитесь к разделу Хранилища событий: не поступают новые события из-за превышения максимального размера события.

Хранилища событий и активные списки: внутренние ошибки после изменения конфигурации ClickHouse

Версия системы: 2.5.0 и выше.

Проявление: при работе в разделах Поиск и Ресурсы → Активные списки возникают сообщения о внутренних ошибках. Проблема проявляется после изменения конфигурации ClickHouse: например, переустановки СУБД или ее переноса в новый кластер.

Причина: таблицы хранилищ событий или активных списков создались не во всех шардах или репликах кластера ClickHouse.

Решение: перезапустите сервис event-storage-manager, выполнив следующую команду:

kubectl -n <namespace> rollout restart deployment/evo.siem.event-storage-manager

Здесь:

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

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

Активные списки: не добавляются записи из-за ошибки конфигурации Kafka

Версия системы: от 1.5.1 до 2.2.0.

Проявление: не добавляются записи в активный список.

Ошибка в поде Kafka:

INVALID_REPLICATION_FACTOR (Unable to replicate the partition 3 time(s): The target replication factor of 3 cannot be reached because only 1 broker(s) are registered.) (org.apache.kafka.controller.ReplicationControlManager)

Причина: при автоматическом создании топиков используется параметр репликации offsets.topic.replication.factor со значением по умолчанию 3. При количестве реплик контроллера Kafka менее 3 возникает ошибка.

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

cd /opt/r-vision/common/helm/stateful
helm upgrade -n siem kafka ./kafka -f ./kafka/custom_values.yaml --set controller.replicaCount=1 --set extraConfig="offsets.topic.replication.factor=1"

Активные списки: таблица активных списков не отображается

Версия системы: 1.5.1 и выше.

Проявление: в разделе Ресурсы → Активные списки не отображается таблица активных списков. Вместо нее отображается сообщение о внутренней ошибке.

В логах пода ClickHouse возникает ошибка, содержащая сообщение MEMORY_LIMIT_EXCEEDED, например:

2025.07.24 12:52:17.464721 [ 234 ] {} <Error> MergeTreeBackgroundExecutor: Exception while executing background task {08280789-8eee-4778-8445-009a607256e1::202507_536822_541220_179}: Code: 241. DB::Exception: Memory limit (total) exceeded: would use 1.13 GiB (attempt to allocate chunk of 5047923 bytes), maximum: 1.08 GiB. OvercommitTracker decision: Memory overcommit isn't used. Waiting time or overcommit denominator are set to zero. (MEMORY_LIMIT_EXCEEDED), Stack trace (when copying this message, always include the lines below):

Причина: лимиты памяти для подов ClickHouse недостаточны.

Решение: увеличьте лимиты оперативной памяти для подов ClickHouse. Для этого:

  1. Получите список контроллеров (Stateful Sets), управляющих ресурсами, которые выделяются для подов ClickHouse:

    kubectl -n <namespace> get sts -l app.kubernetes.io/name=clickhouse

    Здесь:

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

  2. Для каждого шарда увеличьте лимиты памяти:

    1. Откройте конфигурацию контроллера Stateful Set, соответствующего поду:

      kubectl -n <namespace> edit sts <shard_stateful_set>

      Здесь:

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

      • <shard_stateful_set> — имя Stateful Set.

    2. Увеличьте лимит оперативной памяти в значении ключа resources → limits → memory:

      Пример 2. Пример содержимого секции resources → limits
      resources:
  limits:
    cpu: 300m
    memory: 1288490188800m

      Примеры возможных значений лимита памяти:

      • В мегабайтах: 2560Mi.

      • В гигабайтах: 3Gi.

      Список доступных единиц измерения памяти приведен в документации Kubernetes.

    3. Сохраните изменения.

Поды шардов ClickHouse будут перезагружены для применения изменений, и доступ к разделу Ресурсы → Активные списки восстановится. Если этого не произошло, обратитесь в службу поддержки по адресу support@rvision.ru.

Экспертиза: не удается импортировать элементы экспертизы

Версия системы: 2.3.0 и выше.

Проявление: импорт некоторых элементов экспертизы завершается с ошибкой Worker terminated.

Причина: сервис evo.siem.pipeline-verification обладает недостаточными ресурсами для полной обработки импорта.

Решение:

  1. Подключитесь к кластеру с помощью Lens.

  2. Увеличьте значения таймаутов для сервиса evo.siem.pipeline-verification. Для этого:

    1. В выпадающем меню свойств кластера выберите пункт Config → Config Maps.

    2. Выберите пространство имен, в котором установлен кластер, в выпадающем списке Select Namespace в правой части экрана.

    3. Выберите карту конфигурации evo.siem.pipeline-verification-env из списка.

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

      • SIEM_PIPELINE_VERIFICATION_ROBJECT_RUN_TEST_TIMEOUT — таймаут для выполнения тестов элемента экспертизы в миллисекундах. Значение по умолчанию: 60000.

      • SIEM_PIPELINE_VERIFICATION_ROBJECT_CHECK_SCHEMA_TIMEOUT — таймаут для проверки конфигурации элемента экспертизы в миллисекундах. Значение по умолчанию: 60000.

  3. Увеличьте лимиты ресурсов для сервиса evo.siem.pipeline-verification. Для этого:

    1. В выпадающем меню свойств кластера выберите пункт Workloads → Deployments.

    2. Выберите пространство имен, в котором установлен кластер, в выпадающем списке Select Namespace в правой части экрана.

    3. Выберите сервис evo.siem.pipeline-verification из списка.

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

    5. В отобразившейся конфигурации увеличьте значения лимитов оперативной памяти и процессора в секции resources:

      resources:
  limits:
    cpu: 1500m
    memory: 600Mi
  requests:
    cpu: 100m
    memory: 200Mi

    6. Нажмите на кнопку Save. Новая конфигурация будет применена.

+7 (499) 755 55 70 sales@rvision.ru

О компании Пользовательское соглашение Политика cookies