> ## 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 > Frequently asked questions about the ClickHouse Connector

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](/docs/products/bring-your-own-cloud/connector/support-sessions), 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](/docs/products/bring-your-own-cloud/connector/reference/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](/docs/products/bring-your-own-cloud/connector/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](/docs/products/bring-your-own-cloud/connector/configuration). 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](/docs/products/bring-your-own-cloud/connector/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](/docs/products/bring-your-own-cloud/connector/configuration) and the air-gapped section of [onboarding](/docs/products/bring-your-own-cloud/connector/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](/docs/products/bring-your-own-cloud/connector/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](/docs/products/bring-your-own-cloud/connector/reference/configuration) to adjust it, and [support sessions](/docs/products/bring-your-own-cloud/connector/support-sessions) for the full trust model.