Installation Planning

Make the installation decisions below before writing the hub values file, creating Secrets, configuring ingress, or onboarding monitored clusters.

​

Topology

For production, the recommended topology is a dedicated hub cluster. The hub runs the UI, API, ingestion path, workflow workers, PostgreSQL, ClickHouse, and Temporal, so isolating it keeps observability infrastructure separate from the workload clusters it monitors. Multiple monitored clusters can send telemetry to one hub. This is the normal model for organizations that want one place to query telemetry, compare services across clusters, and operate a single set of stateful hub dependencies. Running the hub in the same Kubernetes cluster as monitored workloads is acceptable for smaller or simpler deployments. It reduces the number of clusters to operate, but it also means hub upgrades, cluster maintenance, workload pressure, and telemetry collection all share the same failure domain. Metoro strongly recommends the dedicated hub cluster model.

​

Network Access

Choose the network-facing base URL before installing. This will be the deploymentUrl in the helm chart later, and it should be a stable http or https URL with no path. It is used for the UI, API, OIDC callback configuration, and telemetry ingestion by default. It is the single point of entry to interface with Metoro from outside the cluster. The next choice to make is split host or shared host for the apiserver and ingester components. A shared host can route UI/API traffic and ingestion traffic through different paths on the same hostname. Split host ingress uses separate hostnames for apiserver and ingester traffic, which can be useful when network policy, certificates, or load balancer ownership are managed separately.

​

Certificate Chains

The simplest path is a when all components are using signed certs with a certificate chain trusted by normal browsers and container images. In that case, no extra CA bundle is needed for hub workloads or monitored-cluster exporters. If the hub URL, OIDC issuer, external database, or object-storage endpoint uses private PKI or a self-signed certificate, you need the shared CA bundle available before installation. The hub chart can mount that bundle from an existing ConfigMap through trustedCAs, adding it without replacing the image’s default trust store.

​

Authentication

How will users access Metoro? Metoro on-prem supports OIDC or local email/password accounts. OIDC is the recommended production path when an identity provider is available, because group mappings can place users into the right Metoro roles without managing every user directly in the hub. Local email/password login is also supported, in this model admins create user account and distribute them to users.

​

Bundled Or External Dependencies

Metoro has two main dependencies: ClickHouse and PostgreSQL. In this section we decide how those are run. Natively in Metoro, PostgreSQL is managed through the CloudNativePG operator, ClickHouse is managed through the Altinity ClickHouse Operator, and Temporal runs in the hub cluster with PostgreSQL persistence. Metoro can install these operators as part of the installation process - meaning the whole dependency chain is managed through the metoro helm chart. Some organizations manage Kubernetes operators centrally. In that model, the CloudNativePG and Altinity operators are installed and upgraded by the platform team, while the hub chart still creates and owns the PostgreSQL and ClickHouse resources that back Metoro. Externally managed PostgreSQL and ClickHouse are also supported. Choose that path when your organization already has operational ownership, monitoring, and lifecycle management for those systems, and Metoro should connect to them rather than creating datastore resources in the hub cluster. For production PostgreSQL CPU, memory, instance, and PVC starting points, see PostgreSQL Sizing before finalizing the dependency model.

​

ClickHouse Storage

ClickHouse stores high volume data, so decide its storage model before sizing the deployment. The recommended path is to keep hot data on retained persistent volumes and move longer-term data to object storage. This allows data to be merged efficiently on fast block storage and then shipped to object storage when it is no longer hot for efficient long-term storage. For production CPU, memory, PVC, local cache, and object-storage estimates, see ClickHouse Sizing before finalizing the storage model. In the recommended model, plan persistent volumes for roughly one day of hot ClickHouse data, then prepare object storage for older telemetry. The object store endpoint must be reachable from the hub cluster, and any private CA used by that endpoint must be included in the trusted CA material prepared before installation. PVC-only storage is simpler operationally because all ClickHouse data stays on Kubernetes persistent volumes. Choose it only when the cluster storage layer is sized for the full retention period and your operations team wants to avoid object storage in the first deployment. If ClickHouse is externally managed, use the same decision to align with the team that owns that service. Metoro still needs to know whether recent and older telemetry are backed by separate storage tiers, even if the hub chart is not creating those resources.

​

Selected Decisions

These decisions are saved in this browser and appear on Install Hub.