All settings on this page are optional — the defaults produce a working deployment. Set them as inputs to the Terraform module.

Data retention (TTL)

ClickHouse retains trace data for a fixed window, after which old data is dropped automatically.

ClickHouse users

The platform provisions a least-privilege ClickHouse user model — one SQL user per access path, each scoped to exactly the operations it performs:

schema_owner, otel, llm_worker, monte_carlo, and probe are always provisioned. readonly_user and admin are opt-in.

Each user's password is generated by the module and stored in Secret Manager (CMEK-encrypted by default — see Encryption), then synced into the cluster by the External Secrets Operator through a per-secret access grant — passwords never transit Helm values. Each user has its own secret, named <cluster_name>-clickhouse-<user> and exposed as a clickhouse_<user>_credentials_secret_id output. The exception is probe, which is deliberately passwordless — its consumer is the kubelet's readiness check, which can't read a Kubernetes secret — and so has no Secret Manager entry. What probe can read is limited to replication-health metadata and table names, with no row data exposed; gateway.allowed_source_ranges (see Network access) governs who can reach it.

To supply your own passwords instead of the generated ones, set the sensitive clickhouse_passwords input (per-user; any user left null is auto-generated). Note that like all Terraform-managed secrets, the values are readable in the Terraform state — protect the state accordingly.

Read-only user

To provision the optional readonly_user (SELECT-only, with per-session SET allowed so JDBC clients such as DataGrip connect cleanly):

helm = {
  chart_registry = "oci://registry-1.docker.io/montecarlodata"
  chart_version  = "4.0.0"

  clickhouse = {
    readonly_user = {
      enabled = true
    }
  }
}

Its secret is exposed as the clickhouse_readonly_user_credentials_secret_id output.

Break-glass admin user

The admin superuser is opt-in and, by default, reachable only over loopback (pod-exec) — it is never on a network path. Enable it for break-glass DBA access:

helm = {
  chart_registry = "oci://registry-1.docker.io/montecarlodata"
  chart_version  = "4.0.0"

  clickhouse = {
    admin = {
      enabled = true
    }
  }
}

Its secret is exposed as the clickhouse_admin_credentials_secret_id output (null when disabled).

Resource sizing

Each managed workload exposes optional Kubernetes resource requests/limits via helm.<workload>.resources. Omit a workload (or a requests/limits map) to use the chart defaults — start modest in development and tune up for production.

helm = {
  chart_registry = "oci://registry-1.docker.io/montecarlodata"
  chart_version  = "4.0.0"

  clickhouse = {
    resources = {
      requests = { cpu = "2", memory = "8Gi" }
      limits   = { cpu = "4", memory = "16Gi" }
    }
  }
  opentelemetry_collector = {
    resources = {
      requests = { memory = "2Gi" }
      limits   = { memory = "6Gi" }
    }
  }
  llm_worker = {
    resources = {
      requests = { cpu = "500m", memory = "1Gi" }
      limits   = { cpu = "2", memory = "4Gi" }
    }
  }
}

requests and limits are maps keyed by Kubernetes resource name (cpu, memory, ephemeral-storage, etc.); either can be omitted independently.

There are no replica-count overrides for the Collector or the LLM worker on GCP — both run at the chart's defaults. ClickHouse replicas are controlled by clickhouse_replica_count (see High availability below).

Node pools (new-cluster path)

On the new-cluster path, you can size the node pools the workloads run on:

The main pool autoscales between its floor and ceiling; the ClickHouse and Keeper pools do not — their capacity is provisioned up front, one node per pool (see High availability).

High availability

The topology inputs below deploy the standard HA shape — how it works, the dev/testing single-replica variant, and day-2 operations are covered on the High availability page.

Both zone lists are required on a module-created cluster (a single-zone entry in each is the dev shape) and must be empty on an existing cluster — see High availability — existing-cluster deployments.

Storage

ClickHouse data is stored on a persistent-disk-backed volume.

Two caveats:

• The StorageClass of an existing deployment is fixed. The ClickHouse StatefulSet's volume claim template is immutable — a deployment must stay on the class it was created with. Choose pd-ssd vs Hyperdisk up front.
• Check your quotas before raising Hyperdisk performance. Provisioned IOPS and throughput draw on per-region Hyperdisk quotas.

Network access

The Gateway's load balancer is internal, but by default accepts traffic from any source that can route to it. Restrict the sources to harden access:

The allow-list is implemented as a regional Cloud Armor security policy attached to the Gateway's backends, evaluated against the original client IP. Remember to include the Monte Carlo Agent's subnet CIDR when you restrict it.

TLS

TLS is enabled by default and is not optional on this platform. The OpenTelemetry Collector and ClickHouse endpoints are served by the internal GKE Gateway (gke-l7-rilb), which terminates publicly trusted Let's Encrypt certificates issued by cert-manager via DNS-01 validation against your Cloud DNS zone — "publicly trusted" describes the certificate chain, not exposure; the load balancer IP is private. cert-manager authenticates to Cloud DNS through its direct Workload Identity binding; no key files are involved. gateway.letsencrypt_email optionally sets the ACME contact (omitting it still auto-renews).

Behind the Gateway, traffic is re-encrypted to the backends: cert-manager maintains an in-cluster CA, and trust-manager (installed by the module) distributes it for the Gateway's backend TLS policy. Traffic between the Collector and ClickHouse inside the cluster is likewise secured with cert-manager-issued certificates.

Because the Gateway is a Layer-7 load balancer, two client-facing constraints apply: telemetry senders must use OTLP/HTTP (the Gateway does not carry OTLP/gRPC), and ClickHouse clients connect over HTTPS on port 8443 (not the native TCP protocol).

DNS-related settings:

Evaluation (Vertex AI)

The LLM worker invokes Claude models through Vertex AI. Access is serverless — the module grants the worker's Workload Identity a custom role containing the single predict permission it needs, rather than a broad Vertex role. The worker honors the model each evaluation row requests; the Claude models themselves must be enabled once in the Model Garden.

Ingestion into the platform is OTLP push only — there is no object-storage (bucket) ingest path on GCP, and the Collector runs with no cloud identity at all.

Encryption (CMEK)

Customer-managed encryption keys are on by default for both sensitive stores, using Cloud KMS keys the module creates (90-day rotation) — or your own:

Cluster version and upgrades

Node and Kubernetes upgrades are customer-managed under the default posture — see High availability — node and Kubernetes upgrades.