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

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

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

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

В консоли кластера 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: ошибка аутентификации при выполнении запросов

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

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

Решение: установите единые пароли в NATS Key/Value и в конфигурации ClickHouse. Для этого:

  1. Получите пароли пользователей из NATS Key/Value:

    1. Подключитесь к терминалу master-узла кластера.

    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> — путь к ключу, где хранится пароль.

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

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

      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 также следует обновить пароль в ConfigMap 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: переполнение стрима аудита

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

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

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

  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. Просмотрите информацию о стриме, выполнив следующую команду:

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

    Здесь:

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

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

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

              Subjects: events.streams.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 ГиБ. Нормальный размер стрима должен находиться около 0 КиБ, поскольку при нормальной работе системы сообщения вычитываются в режиме реального времени.

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

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

    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

    Контроллеры Deployment из списка, имя которых начинается с префикса 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. Удалите стрим аудита из NATS, выполнив следующую команду:

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

    Здесь:

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

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

Пространства и сервисы: отсутствуют метрики или логи сервиса

Проявление: в карточке сервиса в разделе Настройки → Пространства и сервисы → Сервисы не отображаются метрики CPU и RAM, используемых сервисом, или отсутствуют логи сервиса.

Возможные причины:

  • Переполнение хранилища логов loki-minio.

  • Недостаточная пропускная способность системы сбора телеметрии.

  • Превышение лимита количества лейблов логов Loki.

  • Сетевая недоступность пространства.

Решение:

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

  1. Соберите информацию о вашем кластере:

    1. Просмотрите статус пространства, в котором запущен сервис, в разделе Настройки → Пространства и сервисы → Пространства веб-интерфейса системы.

    2. Просмотрите статус сервиса в разделе Настройки → Пространства и сервисы → Сервисы веб-интерфейса системы.

    3. Подключитесь к терминалу master-узла кластера.

    4. Выгрузите логи подов системы сбора логов Loki в файл loki-logs.txt, выполнив следующую команду:

      kubectl -n kube-prometheus-stack logs -l app.kubernetes.io/component=write --all-containers=true > loki-logs.txt

    5. Выгрузите логи подов сервиса vector-aggregator в файл vector-aggregator-logs.txt, выполнив следующую команду:

      kubectl -n <namespace> -l app.kubernetes.io/instance=evo.space.vector-aggregator --all-containers=true > vector-aggregator-logs.txt

      Здесь:

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

    6. Выгрузите логи подов сервиса vector-collector в текстовый файл vector-collector-logs.txt, выполнив следующую команду:

      kubectl -n <namespace> -l app.kubernetes.io/instance=evo.space.vector-collector --all-containers=true > vector-collector-logs.txt

      Здесь:

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

    7. Получите информацию о стриме r-space-telemetry в основном экземпляре NATS:

      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. Получите таблицу стримов NATS, выполнив следующую команду:

        kubectl exec -n <namespace> <nats_main_box_name> -- nats s ls

        Здесь:

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

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

      3. Сохраните количество сообщений (Messages) и размер (Size) стрима r-space-telemetry.

    8. Получите информацию о стриме r-space-telemetry в экземпляре NATS для управления пространствами:

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

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

        Здесь:

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

        Пример вывода имени пода nats-space-box 
        nats-space-box-646fb89d4b-st2bd   1/1     Running   1 (7d1h ago)   16d

        В примере выше полное имя пода nats-space-box — nats-space-box-646fb89d4b-st2bd.

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

        kubectl exec -n <namespace> <nats_space_box_name> -- nats s ls

        Здесь:

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

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

      3. Сохраните количество сообщений (Messages) и размер (Size) стрима r-space-telemetry.

    9. Выгрузите ConfigMap vector-aggregator-extravars в файл vector-aggregator-extravars.yml, выполнив следующую команду:

      kubectl -n <namespace> describe configmap vector-aggregator-extravars > vector-aggregator-extravars.yml

      Здесь:

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

    10. Выгрузите ConfigMap vector-collector-extravars в файл vector-collector-extravars.yml, выполнив следующую команду:

      kubectl -n <namespace> describe configmap vector-collector-extravars > vector-collector-extravars.yml

      Здесь:

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

  2. Отправьте в службу поддержки по адресу support@rvision.ru следующую информацию:

    • Технические характеристики вашего кластера:

      • Среднее число событий в секунду (EPS).

      • Количество master- и worker-узлов.

      • Технические характеристики узлов: количество ядер процессора, объем ОЗУ и хранилища, пропускная способность сетевого соединения.

    • Статус сервиса, для которого наблюдается проблема, и пространства, где он развернут.

    • Файлы логов:

      • loki-logs.txt.

      • vector-aggregator-logs.txt.

      • vector-collector-logs.txt.

    • Метрики стримов r-space-telemetry в nats-main и nats-space.

    • Файлы объектов ConfigMap:

      • vector-aggregator-extravars.yml.

      • vector-collector-extravars.yml.

  3. Следуйте инструкциям, полученным в ответ на ваше обращение.

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

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

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

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

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

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

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

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.streams.event-storage-manager

      Здесь:

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

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

        В примере выше полное имя пода event-storage-manager — evo.streams.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.streams.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.streams.search
kubectl -n <namespace> delete pods -l app.kubernetes.io/name=evo.core.bff

      Здесь:

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

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

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

Диспетчер запросов: отсутствуют метрики запросов

Проявление: в разделе Инструменты → Диспетчер запросов не отображаются метрики RQL-запросов, такие как время выполнения и выделенная память. Для установки ClickHouse был использован существующий кластер.

Причина: при настройке кластера ClickHouse не были созданы служебные распределенные таблицы.

Решение: создайте таблицы в кластере ClickHouse. Для этого:

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

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

    Здесь:

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

  2. На любом шарде выполните следующие действия:

    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> — название пространства имен, в котором установлена система.

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

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

      Здесь:

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

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

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

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

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

      SELECT distinct cluster FROM system.clusters

    5. Выполните следующие запросы для создания служебных таблиц:

      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);

      Здесь:

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

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

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

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

Решение:

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

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

    Здесь:

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

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

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

    2. Закройте ConfigMap.

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

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

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

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

    wss://<system_url>/api/graphql

    Здесь:

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

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

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

Проявление: значительное падение 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.

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

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

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

Причина: поду сервиса сбора метрик Prometheus не хватает размера тома, определяемого ресурсом PVC (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, и размер тома изменится через некоторое время.

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

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

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

Решение:

  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: загрузка драйвера прекращается по таймауту

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

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

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

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

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

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

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

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

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

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

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

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

Проявление: не поступают события в точку входа типа 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-драйвера соответствующей СУБД.

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

Проявление: в интерфейсе системы не удается зарегистрировать новую базу данных событий. 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.d создайте файл 99-disable-ipv6.conf со следующим содержимым:

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

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

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

    sudo sysctl --system

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

    sudo service clickhouse-server restart

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

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

Причина: сбой чтения событий аудита из стрима NATS.

Решение: проверьте, совпадает ли номер последней переданной последовательности в стриме и consumer (потребителе) событий аудита. Для этого:

  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-streams-audit-system-audit:

    1. Получите информацию о стриме events-streams-audit-system-audit, выполнив следующую команду:

      kubectl exec -n <namespace> <nats_main_box_name> -- nats stream info events-streams-audit-system-audit

      Здесь:

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

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

      Пример вывода информации о стриме events-streams-audit-system-audit 
      Information for Stream events-streams-audit-system-audit created 2025-06-27 01:40:48

                Subjects: events.streams.audit.v1.SystemAuditEvent
                Replicas: 1
                 Storage: File

Options:

               Retention: WorkQueue
         Acknowledgments: true
          Discard Policy: Old
        Duplicate Window: 2m0s
       Allows Msg Delete: true
            Allows Purge: true
  Allows Per-Message TTL: false
          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:

            Host Version: 2.11.2
      Required API Level: 0 hosted at level 1
                Messages: 40
                   Bytes: 19 KiB
          First Sequence: 131,385 @ 2025-11-01 13:55:26
           Last Sequence: 131,424 @ 2025-11-01 14:29:15
        Active Consumers: 1
      Number of Subjects: 1

    2. Сохраните номер последней переданной последовательности, указанный в значении ключа Last Sequence. В примере выше — 131,424.

  3. Получите номер последней полученной последовательности из информации о consumer nats_system_audit_events:

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

      kubectl exec -n <namespace> <nats_main_box_name> -- nats consumer info events-streams-audit-system-audit nats_system_audit_events

      Здесь:

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

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

      Пример вывода информации о consumer nats_system_audit_events 
      Information for Consumer events-streams-audit-system-audit > nats_system_audit_events created 2025-10-10T11:06:44Z

Configuration:

                    Name: nats_system_audit_events
               Pull Mode: true
         Filter Subjects: events.streams.audit.v1.SystemAuditEvent
          Deliver Policy: All
              Ack Policy: Explicit
                Ack Wait: 30.00s
           Replay Policy: Instant
         Max Ack Pending: 1,000
       Max Waiting Pulls: 512

State:

            Host Version: 2.11.2
      Required API Level: 0 hosted at level 1
  Last Delivered Message: Consumer sequence: 307,282 Stream sequence: 205,215 Last delivery: 268s ago
    Acknowledgment Floor: Consumer sequence: 307,184 Stream sequence: 205,175 Last Ack: 1h32m6s ago
        Outstanding Acks: 40 out of maximum 1,000
    Redelivered Messages: 40
    Unprocessed Messages: 0
           Waiting Pulls: 2 of maximum 512

    2. Сохраните номер последнего полученного сообщения, указанный в поле Last Delivered Message, в значении ключа Stream sequence. В примере выше — 205,215.

  4. Сравните номер последней переданной последовательности, полученный из информации о стриме, с номером последнего полученного сообщения. В примере выше — 205,215. Этот номер значительно больше, чем 131,424. В таком случае переданные последовательности не читаются из стрима до тех пор, пока их номер не достигнет Last Delivered Message, что и приводит к отсутствию новых событий в хранилище.

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

    1. Удалите consumer, выполнив следующую команду:

      kubectl exec -n <namespace> <nats_main_box_name> -- nats consumer rm events-streams-audit-system-audit nats_system_audit_events

      Здесь:

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

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

    2. Удалите под audit-manager, выполнив следующую команду:

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

      Здесь:

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

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

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

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

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

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

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

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

Проявление: в хранилище событий не поступают события. В логах пода 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 в объекты ConfigMap nats-main-config и nats-space-config. Для каждой из них выполните следующие действия:

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

      kubectl -n <namespace> edit configmap <configmap>

      Здесь:

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

      • <configmap> — имя ConfigMap: nats-main-config или nats-space-config.

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

      Пример ConfigMap с ключом 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.

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

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

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

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

  1. Откройте ConfigMap сервиса evo.streams.event-storage-manager. Для этого выполните следующую команду:

    kubectl -n <namespace> edit configmap evo.streams-event-storage-manager-env

    Здесь:

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

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

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

    1. Откройте конфигурацию контроллера Deployment evo.streams.event-storage-manager, выполнив следующую команду:

      kubectl -n <namespace> edit deployment evo.streams.event-storage-manager

      Здесь:

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

    2. Скопируйте и сохраните текущие значения параметров в секции livenessProbe.

      Пример содержимого секции livenessProbe 
      livenessProbe:
  grpc:
    port: 3000
    service: ''
  initialDelaySeconds: 10
  timeoutSeconds: 3
  periodSeconds: 10
  successThreshold: 1
  failureThreshold: 3

    3. Увеличьте значения параметров timeoutSeconds, periodSeconds и failureThreshold.

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

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

  3. Удалите под сервиса evo.streams.event-storage-manager, выполнив следующую команду:

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

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

  4. Дождитесь, когда под evo.streams.event-storage-manager перейдет в статус Running. Инструкция по проверке статуса пода приведена в разделе Просмотр состояния подов кластера.

  5. Когда под перейдет в статус Running, перейдите в веб-интерфейс системы и убедитесь, что поиск по хранилищам событий выполняется успешно и события поступают в хранилища.

  6. Откройте ConfigMap сервиса evo.streams.event-storage-manager. Для этого выполните следующую команду:

    kubectl -n <namespace> edit configmap evo.streams-event-storage-manager-env

    Здесь:

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

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

  8. Если вы меняли интервал liveness-проб, восстановите интервал по умолчанию в конфигурации evo.streams.event-storage-manager. Ее можно открыть, выполнив следующую команду:

    kubectl -n <namespace> edit deployment evo.streams.event-storage-manager

    Здесь:

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

Активный список: не выполняется поиск или не обновляются записи

Проявление: возникает внутренняя ошибка сервера при поиске в активном списке или записи в нем не обновляются.

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

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

  1. Откройте ConfigMap сервиса evo.streams.active-list-manager. Для этого выполните следующую команду:

    kubectl -n <namespace> edit configmap evo.streams-active-list-manager-env

    Здесь:

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

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

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

    1. Откройте конфигурацию контроллера Deployment evo.streams.active-list-manager, выполнив следующую команду:

      kubectl -n <namespace> edit deployment evo.streams.active-list-manager

      Здесь:

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

    2. Скопируйте и сохраните текущие значения параметров в секции livenessProbe.

      Пример содержимого секции livenessProbe 
      livenessProbe:
  grpc:
    port: 3000
    service: ''
  initialDelaySeconds: 10
  timeoutSeconds: 3
  periodSeconds: 10
  successThreshold: 1
  failureThreshold: 3

    3. Увеличьте значения параметров timeoutSeconds, periodSeconds и failureThreshold.

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

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

  3. Удалите под сервиса evo.streams.active-list-manager, выполнив следующую команду:

    kubectl -n <namespace> delete pods -l app.kubernetes.io/name=evo.streams.active-list-manager

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

  4. Дождитесь, когда под evo.streams.active-list-manager перейдет в статус Running. Инструкция по проверке статуса пода приведена в разделе Просмотр состояния подов кластера.

  5. Когда под перейдет в статус Running, перейдите в веб-интерфейс системы и убедитесь, что поиск по активным спискам выполняется успешно и записи в них обновляются.

  6. Откройте ConfigMap сервиса evo.streams.active-list-manager. Для этого выполните следующую команду:

    kubectl -n <namespace> edit configmap evo.streams-active-list-manager-env

    Здесь:

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

  7. Измените значение переменной EVO_STREAMS_ACTIVE_LIST_MANAGER_RECREATE_ACTIVE_LISTS обратно на "false".

  8. Если вы меняли интервал liveness-проб, восстановите интервал по умолчанию в конфигурации evo.streams.active-list-manager. Ее можно открыть, выполнив следующую команду:

    kubectl -n <namespace> edit deployment evo.streams.active-list-manager

    Здесь:

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

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

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

В логах пода 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. Получите список контроллеров StatefulSet, управляющих ресурсами, которые выделяются для подов ClickHouse:

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

    Здесь:

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

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

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

      kubectl -n <namespace> edit sts <shard_stateful_set>

      Здесь:

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

      • <shard_stateful_set> — имя Stateful Set.

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

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

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

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

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

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

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

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

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

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

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

Решение:

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

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

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

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

    3. Выберите ConfigMap evo.streams.pipeline-verification-env из списка.

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

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

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

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

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

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

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

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

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

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

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

Шлюзы: шлюз регулярно перезапускается

Проявление: шлюз в системе регулярно отключается и включается заново.

Причина: не хватает оперативной памяти для работы шлюза.

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

  1. Получите идентификатор шлюза из его карточки.

  2. Подключитесь к терминалу master-узла кластера.

  3. Получите идентификатор контроллера Deployment нужного шлюза, выполнив следующую команду:

    kubectl -n <namespace> get deployment | grep <gateway_id>

    Здесь:

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

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

    Пример вывода имени контроллера шлюза 
    wl.5db08c79-b5f3-4f07-a7b7-49e3b2ac6202-gateway           1/1     1            1           26h

    В примере выше имя контроллера шлюза — wl.5db08c79-b5f3-4f07-a7b7-49e3b2ac6202-gateway.

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

    kubectl -n <namespace> edit deployment <deployment_id>

    Здесь:

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

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

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

    - name: GOMEMLIMIT
  value: 1536MiB
    Рекомендуется устанавливать лимит в 75% от общего объема оперативной памяти, выделенной для кластера Kubernetes.

  6. Сохраните изменения в конфигурации контроллера.

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

Nginx: не загружаются файлы больших размеров

Проявление: не удается загрузить файл размером больше 1 МБ через веб-интерфейс системы. В инструментах разработчика в браузере отображается ошибка запроса с кодом HTTP 413.

Причина: превышен лимит на размер загружаемых файлов (по умолчанию 1 МБ).

Решение: увеличьте максимальный размер загружаемых файлов. Инструкция приведена в разделе Настройка ограничений размера загружаемых файлов.

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

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

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

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