Skip to main content

​
FAQ

​
What data leaves my environment?

Two surfaces send data out, both over outbound connections the connector opens itself: the scrape path, which ships operational metadata continuously, and support sessions you enable, which return diagnostics. The scraper sends results from a fixed set of system tables (metric_log, asynchronous_metric_log, tables, warnings, server_settings by default), health and status heartbeats, instance and backup state, and the connector’s own metrics. The default scrape set deliberately excludes system.query_log, so raw SQL text, and any literals or personal data inside it, never leaves through the scrape path unless you explicitly add it. During a session, the default table allowlist includes system.processes, which shows live query text; remove it from the allowlist if that must stay hidden. During an active support session, the troubleshooter additionally returns command output, bounded to allowlisted ClickHouse tables and read-only Kubernetes views including pod logs, and passed through redaction (built-in patterns for IPs, credentials, tokens, and keys, plus your own) before it is sent. Your table data, backups, and query history (system.query_log, system.text_log) stay in your environment unconditionally. The documented exceptions: rows from the allowlisted metric-history tables (system.metric_log, system.asynchronous_metric_log) ship with every scrape, live query text is session-visible through system.processes unless you remove it from the allowlist, and pod logs read during a Kubernetes support session leave after redaction. The complete outbound connection list is on the privilege model page.

​
How do I revoke ClickHouse’s access?

In escalating order:
  1. End interactive access. Disable the session: sudo clicklink clctl troubleshoot session disable on the VM host, or the same command with --gateway-url through the port-forward on Kubernetes (exact commands on the support sessions page). With no active session the troubleshooter refuses every command, even while connected.
  2. Prevent future sessions. Empty the operator allowlist (an empty allowlist closes the gateway) or disable the gateway; on a VM, local session management remains available to root on the host. See the configuration guide.
  3. Cut ClickHouse Cloud connectivity. Block egress to your connector endpoint at your network layer, or empty networkPolicy.allowEgressCIDRs under an enforcing CNI; the connector is outbound-only, so ClickHouse Cloud has no inbound path to restore it. Local reads against your ClickHouse continue until you stop or uninstall the workloads, which is the hard stop.
  4. Revoke credentials. Drop the pcm_scraper and pcm_troubleshooter ClickHouse users and delete the connector’s Secrets (Kubernetes) or the files under /etc/clicklink (VM).
  5. Remove the connector entirely. See operations.

​
Can I run this air-gapped or through my own mirrors?

Yes. Every install-time artifact can come from inside your boundary: mirror the CLI tarball and container image from releases.clicklink.clickhouse.com and the public registry, point image.repository at your mirror, and pass --chart with an oci:// reference, URL, or local archive (with --chart-version; it defaults to the CLI’s own version). If your connector API endpoint is served inside your boundary behind a private CA, --api-private-ca (Kubernetes) or api.tls.ca_file (VM) verifies it against the enrollment bundle’s chain. For enrollment without direct connectivity, init --handoff consumes a bundle obtained out of band, and --no-auto-sign plus init --signed-cert completes certificate signing out of band. See private mirrors and the air-gapped section of onboarding. Note that the connector still needs a route to your org’s connector API endpoint at runtime; without one, ClickHouse Cloud receives no telemetry.

​
What happens if the connector goes down?

Your ClickHouse services are unaffected: the connector only reads from them and sits in no data path. The impact is loss of visibility, so ClickHouse Cloud stops receiving telemetry and support sessions become unavailable until it returns. On a VM, the scraper spools scraped data to /var/lib/clicklink/buffer (up to 168 hours or 1024 MB by default) whenever the API endpoint is unreachable and delivers it on reconnect, so an endpoint outage does not lose telemetry; a crashed daemon is restarted by systemd, and on Kubernetes by the kubelet. To diagnose, check each component’s /livez endpoint (the JSON status field is the signal, not the HTTP code) and run clicklink clctl preflight (with sudo on the VM host), which checks configuration, connectivity, ClickHouse reachability, access, and disk in one pass. See operations; if the connector stays unhealthy, contact ClickHouse Support.

​
How are support sessions audited?

Every gateway call and every troubleshoot command, accepted or blocked, is appended to an audit log at /var/log/clicklink/troubleshoot-audit.log as newline-delimited JSON, attributed per entry: gateway calls carry the token-attested operator email (never a self-reported name), VM local session changes record the invoking host user, and commands executed during a session record the org identity on the authenticated channel. Sessions themselves are time-boxed (4 hours by default, 24 hours maximum) and each enablement records who enabled it, when it expires, and an optional reason, which clicklink clctl troubleshoot session status displays. Read the log with clicklink clctl troubleshoot audit tail; on Kubernetes that command is the supported reader (the runtime image has no shell) and, with the default persistence.enabled: true, the log lives on the troubleshooter’s persistent volume so the trail survives pod rescheduling. Disabling persistence makes the audit log and session state pod-lifetime, which the chart itself marks as suitable for local development only. Rotation keeps 5 files of up to 128 MB for 168 hours by default; see the configuration reference to adjust it, and support sessions for the full trust model.
Last modified on August 18, 2026