Какие данные покидают мою среду?
metric_log, asynchronous_metric_log, tables, warnings, server_settings), сигналы работоспособности и статуса, состояние экземпляра и резервных копий, а также собственные метрики коннектора. Набор для сбора по умолчанию намеренно исключает system.query_log, поэтому исходный текст SQL, а также любые содержащиеся в нём литералы или персональные данные не покидают среду через путь сбора, если вы явно не добавите эту таблицу. Во время сеанса список разрешённых таблиц по умолчанию включает system.processes, в которой отображается текст выполняемых запросов; удалите её из списка разрешённых, если эти данные должны оставаться скрытыми.
Во время активного сеанса поддержки средство устранения неполадок также возвращает вывод команд, ограниченный разрешёнными таблицами ClickHouse и представлениями Kubernetes только для чтения, включая журналы подов, и перед отправкой пропускает его через маскирование (встроенные шаблоны для IP-адресов, учётных данных, токенов и ключей, а также заданные вами). Данные ваших таблиц, резервные копии и история запросов (system.query_log, system.text_log) безусловно остаются в вашей среде. Документированные исключения: строки из разрешённых таблиц истории метрик (system.metric_log, system.asynchronous_metric_log) отправляются при каждом сборе, текст выполняемых запросов доступен в сеансе через system.processes, если вы не удалите эту таблицу из списка разрешённых, а журналы подов, считываемые во время сеанса поддержки Kubernetes, покидают среду после маскирования. Полный список исходящих подключений приведён на странице модели привилегий.
Как отозвать доступ ClickHouse?
- Завершите интерактивный доступ. Отключите сеанс: на хосте ВМ выполните
sudo clicklink clctl troubleshoot session disable, а в Kubernetes — ту же команду с --gateway-url через проброс порта (точные команды приведены на странице сеансов поддержки). При отсутствии активного сеанса средство устранения неполадок не выполняет никакие команды, даже при наличии подключения.
- Предотвратите будущие сеансы. Очистите список разрешённых операторов (пустой список закрывает шлюз) или отключите шлюз; на ВМ локальное управление сеансами остаётся доступным пользователю root на хосте. См. руководство по настройке.
- Отключите ClickHouse Cloud от коннектора. Заблокируйте исходящий трафик к конечной точке коннектора на сетевом уровне или очистите
networkPolicy.allowEgressCIDRs при использовании CNI с принудительным применением политик; коннектор работает только с исходящими подключениями, поэтому у ClickHouse Cloud нет входящего пути для его восстановления. Локальное чтение из ClickHouse продолжится, пока вы не остановите или не удалите рабочие нагрузки — это окончательная мера.
- Отзовите учётные данные. Удалите пользователей ClickHouse
pcm_scraper и pcm_troubleshooter, а также Secrets коннектора в Kubernetes или файлы в /etc/clicklink на ВМ.
- Полностью удалите коннектор. См. operations.
Можно ли развернуть это в среде, изолированной от интернета, или через собственные зеркала?
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 и раздел об изолированной от интернета среде в онбординге. Обратите внимание: во время работы коннектору всё равно нужен маршрут к конечной точке API коннектора вашей организации; без него ClickHouse Cloud не получает телеметрию.
Что произойдёт, если коннектор перестанет работать?
/var/lib/clicklink/buffer (по умолчанию до 168 часов или 1024 МБ), когда конечная точка API недоступна, и передаёт их после повторного подключения, поэтому сбой конечной точки не приводит к потере телеметрии; аварийно завершившийся демон перезапускается systemd, а в Kubernetes — Кубелетом. Для диагностики проверьте конечную точку /livez каждого компонента (индикатором служит поле JSON status, а не код HTTP) и выполните clicklink clctl preflight (на хосте ВМ — с sudo): эта команда за один проход проверяет конфигурацию, подключение, доступность ClickHouse, права доступа и диск. См. раздел операции; если коннектор остаётся неисправным, обратитесь в 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 часов; см. справочник по конфигурации, чтобы изменить эти параметры, и сеансы поддержки с полным описанием модели доверия. Последнее изменение 26 августа 2026 г.
