> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# FAQ
> Часто задаваемые вопросы о коннекторе ClickHouse
## FAQ
### Какие данные покидают мою среду?
Данные передаются за пределы среды по двум каналам — оба используют исходящие подключения, которые коннектор открывает самостоятельно: путь сбора, непрерывно передающий операционные метаданные, и включаемые вами сеансы поддержки, в рамках которых возвращаются диагностические данные.
Скрапер отправляет результаты из фиксированного набора системных таблиц (по умолчанию `metric_log`, `asynchronous_metric_log`, `tables`, `warnings`, `server_settings`), сигналы работоспособности и статуса, состояние экземпляра и резервных копий, а также собственные метрики коннектора. Набор для сбора по умолчанию намеренно исключает `system.query_log`, поэтому исходный текст SQL, а также любые содержащиеся в нём литералы или персональные данные не покидают среду через путь сбора, если вы явно не добавите эту таблицу. Во время сеанса список разрешённых таблиц по умолчанию включает `system.processes`, в которой отображается текст выполняемых запросов; удалите её из списка разрешённых, если эти данные должны оставаться скрытыми.
Во время активного [сеанса поддержки](/docs/ru/products/bring-your-own-cloud/connector/support-sessions) средство устранения неполадок также возвращает вывод команд, ограниченный разрешёнными таблицами ClickHouse и представлениями Kubernetes только для чтения, включая журналы подов, и перед отправкой пропускает его через маскирование (встроенные шаблоны для IP-адресов, учётных данных, токенов и ключей, а также заданные вами). Данные ваших таблиц, резервные копии и история запросов (`system.query_log`, `system.text_log`) безусловно остаются в вашей среде. Документированные исключения: строки из разрешённых таблиц истории метрик (`system.metric_log`, `system.asynchronous_metric_log`) отправляются при каждом сборе, текст выполняемых запросов доступен в сеансе через `system.processes`, если вы не удалите эту таблицу из списка разрешённых, а журналы подов, считываемые во время сеанса поддержки Kubernetes, покидают среду после маскирования. Полный список исходящих подключений приведён на странице [модели привилегий](/docs/ru/products/bring-your-own-cloud/connector/reference/privilege-model).
### Как отозвать доступ ClickHouse?
В порядке усиления мер:
1. **Завершите интерактивный доступ.** Отключите сеанс: на хосте ВМ выполните `sudo clicklink clctl troubleshoot session disable`, а в Kubernetes — ту же команду с `--gateway-url` через проброс порта (точные команды приведены на странице [сеансов поддержки](/docs/ru/products/bring-your-own-cloud/connector/support-sessions)). При отсутствии активного сеанса средство устранения неполадок не выполняет никакие команды, даже при наличии подключения.
2. **Предотвратите будущие сеансы.** Очистите список разрешённых операторов (пустой список закрывает шлюз) или отключите шлюз; на ВМ локальное управление сеансами остаётся доступным пользователю root на хосте. См. [руководство по настройке](/docs/ru/products/bring-your-own-cloud/connector/configuration).
3. **Отключите ClickHouse Cloud от коннектора.** Заблокируйте исходящий трафик к конечной точке коннектора на сетевом уровне или очистите `networkPolicy.allowEgressCIDRs` при использовании CNI с принудительным применением политик; коннектор работает только с исходящими подключениями, поэтому у ClickHouse Cloud нет входящего пути для его восстановления. Локальное чтение из ClickHouse продолжится, пока вы не остановите или не удалите рабочие нагрузки — это окончательная мера.
4. **Отзовите учётные данные.** Удалите пользователей ClickHouse `pcm_scraper` и `pcm_troubleshooter`, а также Secrets коннектора в Kubernetes или файлы в `/etc/clicklink` на ВМ.
5. **Полностью удалите коннектор.** См. [operations](/docs/ru/products/bring-your-own-cloud/connector/operations).
### Можно ли развернуть это в среде, изолированной от интернета, или через собственные зеркала?
Да. Все артефакты, необходимые для установки, можно получать изнутри вашего периметра: создайте зеркала архива CLI и образа контейнера из `releases.clicklink.clickhouse.com` и публичного реестра, укажите зеркало в `image.repository` и передайте `--chart` со ссылкой `oci://`, URL или локальным архивом (с `--chart-version`; по умолчанию используется версия самого CLI). Если конечная точка API коннектора размещена внутри вашего периметра и использует private CA, `--api-private-ca` (Kubernetes) или `api.tls.ca_file` (ВМ) проверит её по цепочке сертификатов из пакета регистрации. Для регистрации без прямого подключения `init --handoff` использует пакет, полученный по внешнему каналу, а `--no-auto-sign` вместе с `init --signed-cert` позволяет выполнить подписание сертификата по внешнему каналу. См. [private mirrors](/docs/ru/products/bring-your-own-cloud/connector/configuration) и раздел об изолированной от интернета среде в [онбординге](/docs/ru/products/bring-your-own-cloud/connector/onboarding). Обратите внимание: во время работы коннектору всё равно нужен маршрут к конечной точке API коннектора вашей организации; без него ClickHouse Cloud не получает телеметрию.
### Что произойдёт, если коннектор перестанет работать?
Ваши сервисы ClickHouse не затронуты: коннектор только считывает из них данные и не находится на пути передачи данных. Это приведёт к потере наблюдаемости: ClickHouse Cloud перестанет получать телеметрию, а сеансы поддержки будут недоступны, пока коннектор не восстановится. На виртуальной машине скрапер сохраняет собранные данные в буфере `/var/lib/clicklink/buffer` (по умолчанию до 168 часов или 1024 МБ), когда конечная точка API недоступна, и передаёт их после повторного подключения, поэтому сбой конечной точки не приводит к потере телеметрии; аварийно завершившийся демон перезапускается systemd, а в Kubernetes — Кубелетом. Для диагностики проверьте конечную точку `/livez` каждого компонента (индикатором служит поле JSON `status`, а не код HTTP) и выполните `clicklink clctl preflight` (на хосте ВМ — с `sudo`): эта команда за один проход проверяет конфигурацию, подключение, доступность ClickHouse, права доступа и диск. См. раздел [операции](/docs/ru/products/bring-your-own-cloud/connector/operations); если коннектор остаётся неисправным, обратитесь в ClickHouse Support.
### Как аудитируются сеансы поддержки?
Каждый вызов шлюза и каждая команда устранения неполадок — независимо от того, принята она или заблокирована, — добавляются в журнал аудита `/var/log/clicklink/troubleshoot-audit.log` в формате JSON с разделением по строкам и с указанием субъекта для каждой записи: вызовы шлюза содержат подтверждённый токеном адрес электронной почты оператора (но не указанное им имя), изменения локального сеанса ВМ фиксируют пользователя хоста, который их инициировал, а команды, выполненные во время сеанса, фиксируют идентичность org в аутентифицированном канале. Время сеансов ограничено (по умолчанию — 4 часа, максимум — 24 часа), а при каждом включении записываются сведения о том, кто его включил, когда оно истекает и, при необходимости, причина. Эти сведения отображает `clicklink clctl troubleshoot session status`.
Просматривайте журнал с помощью `clicklink clctl troubleshoot audit tail`; в Kubernetes эта команда является поддерживаемым средством чтения журнала (в образе среды выполнения нет оболочки), а при установленном по умолчанию значении `persistence.enabled: true` журнал хранится в постоянном томе средства устранения неполадок, поэтому сохраняется при перепланировании пода. При отключении сохранения журнал аудита и состояние сеанса существуют только в течение жизни пода; сама chart отмечает этот вариант как подходящий только для локальной разработки. По умолчанию ротация хранит 5 файлов размером до 128 МБ в течение 168 часов; см. [справочник по конфигурации](/docs/ru/products/bring-your-own-cloud/connector/reference/configuration), чтобы изменить эти параметры, и [сеансы поддержки](/docs/ru/products/bring-your-own-cloud/connector/support-sessions) с полным описанием модели доверия.