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

В данном разделе приведены возможные проблемы при установке или обновлении R-Vision SIEM и способы их решения.

Установка: ошибка конфигурации Longhorn

Версия R-Vision SIEM: 1.0.0 и выше. Должен быть установлен провайдер хранилища Longhorn.

Проблема: при установке или обновлении системы возникает ошибка Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[kube-api-access scripts data config tz]: timed out waiting for the condition.

Причина: некорректные настройки Longhorn или на узлах кластера не запущена служба iscsid.

Решение:

  1. Проверьте настройки Longhorn. Для этого выполните следующие действия:

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

      kubectl -n longhorn-system port-forward service/longhorn-frontend <local_port>:80
      bash

      Здесь:

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

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

    3. Чтобы просмотреть и отредактировать конфигурацию узлов (реплик) Longhorn, перейдите в раздел Node.

    4. Если количество узлов Longhorn больше, чем количество рабочих узлов кластера, удалите лишние узлы. Для этого нажмите на кнопку Remove Node в выпадающем меню в столбце Operation для каждого из лишних узлов.

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

      1. В выпадающем меню в столбце Operation нажмите на кнопку Edit node and disks.

      2. Если в поле Storage Reserved выделено больше пространства, чем размер диска узла кластера, уменьшите размер пространства и нажмите на кнопку Save.

        Рекомендуется выделять под Longhorn 30% диска узла кластера.

  2. Если исправление конфигурации Longhorn не решило проблему, проверьте, запущена ли служба iscsid на всех узлах кластера:

    1. На каждом узле кластера выполните команду:

      systemctl status iscsid
      bash

    2. Если статус службы отличается от active (running), запустите ее:

      systemctl start iscsid
      bash

Longhorn: ошибка файловой системы

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

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

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

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

Kafka: INVALID_REPLICATION_FACTOR

Версия R-Vision SIEM: 1.5.1 и выше.

Ошибка в поде 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"

Точка входа типа Database (MS SQL): PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.

Версия R-Vision SIEM: 1.10.2 и выше.

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

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.

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

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

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

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

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

Коллектор: vector::internal_events::codecs: Failed framing bytes. error=Unable to decode input as UTF8

Версия R-Vision SIEM: 1.10.2 и выше.

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

"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.",

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

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

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

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

Версия R-Vision SIEM: 2.0.0 и выше.

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

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

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

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

Решение:

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

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

    Здесь:

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

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

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

    Здесь:

    • <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
    bash

    Здесь:

    • <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>'"
    bash

    Здесь:

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

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

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

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

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

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

Версия R-Vision SIEM: 2.0.0 и выше.

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

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

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

Loki: не работает loki-gateway

Версия R-Vision SIEM: ниже 2.0.0.

Проявление: ошибка при просмотре логов коллектора в интерфейсе:

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

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

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

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

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

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

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

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

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

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

  3. Сравните имена DNS-сервисов:

    echo "K8s DNS: $K8S_DNS_SERVICE"
echo "Loki DNS: $(echo "$LOKI_CONFIG" | grep resolver)"
    bash
    Пример вывода имен DNS-сервисов 
    K8s DNS: kube-dns
Loki DNS: resolver coredns.kube-system.svc.cluster.local.;
    bash

    Если в выводе имена сервисов разные, перейдите к шагу 4.

  4. Откройте карту конфигурации loki-gateway:

    KUBE_EDITOR=nano kubectl edit configmap/loki-gateway -n kube-prometheus-stack
    bash

    Замените имя DNS-сервиса coredns после resolver на значение переменной K8S_DNS_SERVICE. После исправления строка карты конфигурации должна принять вид:

    resolver <dns_name>.kube-system.svc.cluster.local.;

    Здесь:

    • <dns_name> — имя DNS-сервиса Kubernetes, полученное на шаге 3, например, kube-dns.

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

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

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

Версия R-Vision SIEM: 1.0.0 и выше.

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

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

Решение:

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

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

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

    Здесь:

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

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

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

      kubectl -n <namespace> describe pod <shard_pod>
      bash

      Здесь:

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

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

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

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

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

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

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

        echo <encoded_secret> | base64 --decode
        bash

        Здесь:

        • <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'
      bash
      kubectl exec -n <namespace> <shard_pod> -- clickhouse-client --user <clickhouse_user> --password <clickhouse_password> 'SELECT 1 FROM "EventStorage_<TABLE_ID>_local" LIMIT 1'
      bash

      Здесь:

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

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

      • <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>'
        bash

        Здесь:

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

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

        • <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())
          sql

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

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

        Здесь:

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

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

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

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

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

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

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

    kubectl -n <namespace> describe pod postgresql-0
    bash

    Здесь:

    • <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>'"
    bash

    Здесь:

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

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

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

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

    Здесь:

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

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

Поиск: ошибка Address family not supported by protocol (os error 97) при поисковых запросах и построении дашбордов

Версия R-Vision SIEM: 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
      bash

      Здесь:

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

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

        В примере выше полное имя пода 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
        bash

        Здесь:

        • <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
      bash

      Здесь:

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

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

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

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

Версия R-Vision SIEM: 1.0.0 и выше.

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

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

Решение:

  1. Если версия R-Vision SIEM — 1.10.2 и выше:

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

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

      Здесь:

      • <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
        bash

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

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

    wss://<system_url>/api/graphql

    Здесь:

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

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

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

Версия R-Vision SIEM: 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
    bash

    Имя 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
# ...
    yaml

    В этом случае имя 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>
    bash

    Здесь:

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

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

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

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

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

Версия R-Vision SIEM: 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
    bash

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

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

    sysctl -p
    bash

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

    sudo service clickhouse-server restart
    bash

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

Версия R-Vision SIEM: 1.0.0 и выше.

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

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

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

  1. Получите пароли пользователей из Consul:

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

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

      Здесь:

      • <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
      bash

      Здесь:

      • <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
    bash

    Здесь:

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

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

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

      kubectl -n <namespace> describe pod <shard_pod>
      bash

      Здесь:

      • <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
      bash

      Здесь:

      • <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>'"
    bash

    Здесь:

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

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

    • <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
    bash

    Укажите пароль пользователя 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
    bash

    Здесь:

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

+7 (499) 322 80 40 sales@rvision.ru

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

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