Managed

Your table must align with the output schema produced by Vector. Adjust the schema as needed for your data, following the recommended [schema best practices](/docs/best-practices/select-data-types).

We strongly recommend understanding how [Primary keys](/docs/primary-indexes) work in ClickHouse and choosing an ordering key based on your access patterns. See the [ClickStack-specific](/docs/use-cases/observability/clickstack/performance_tuning#choosing-a-primary-key) guidance on choosing a primary key.

Once the table exists, copy the configuration snippet shown. Adjust the input to consume your existing pipelines, as well as the target table and database if required. Credentials should be pre-populated.

For more examples of ingesting data with Vector, see ["Ingesting with Vector"](/docs/use-cases/observability/clickstack/ingesting-data/vector) or the [Vector ClickHouse sink documentation](https://vector.dev/docs/reference/configuration/sinks/clickhouse/) for advanced options.

Navigate to the ClickStack UI

### Navigate to the ClickStack UI[​](#navigate-to-clickstack-ui-cloud-create-new "Direct link to Navigate to the ClickStack UI")

Select 'Launch ClickStack' to access the ClickStack UI (HyperDX). You will automatically authenticated and redirected.

- OpenTelemetry- Vector

Data sources will be pre-created for any OpenTelemetry data.

If you're using Vector, you will need to create your own data sources. You will be prompted to create one on your first login. Below we show an example configuration for a logs data source.

This configuration assumes an Nginx-style schema with a `time_local` column used as the timestamp. This should be, where possible, the timestamp column declared in the primary key. **This column is mandatory**.

We also recommend updating the `Default SELECT` to explicitly define which columns are returned in the logs view. If additional fields are available, such as service name, log level, or a body column, these can also be configured. The timestamp display column can also be overridden if it differs from the column used in the table's primary key and configured above.

In the example above, a `Body` column doesn't exist in the data. Instead, it is defined using a SQL expression that reconstructs an Nginx log line from the available fields.

For other possible options, see the [configuration reference](/docs/use-cases/observability/clickstack/config).

Once created, you should be directed to the search view where you can immediately begin exploring your data.

  

And that’s it — you’re all set. 🎉

Go ahead and explore ClickStack: start searching logs and traces, see how logs, traces, and metrics correlate in real time, build dashboards, explore service maps, uncover event deltas and patterns, and set up alerts to stay ahead of issues.

Select a service

### Select a service[​](#select-service "Direct link to Select a service")

From the ClickHouse Cloud landing page, select the service for which you wish to enable managed ClickStack.

Estimating resources

This guide assumes you have provisioned sufficient resources to handle the volume of observability data you plan to ingest and query with ClickStack. To estimate the required resources, refer to the [Estimating Resources](/docs/use-cases/observability/clickstack/estimating-resources) guide.

If your ClickHouse service already hosts existing workloads, such as real-time application analytics, we recommend creating a child service using [ClickHouse Cloud's warehouses feature](/docs/cloud/reference/warehouses) to isolate the observability workload. This ensures your existing applications aren't disrupted, while keeping the datasets accessible from both services.

Navigate to the ClickStack UI

### Navigate to the ClickStack UI[​](#navigate-to-the-clickstack-ui-existing "Direct link to Navigate to the ClickStack UI")

Select 'ClickStack' from the left navigation menu. You will be redirected to the ClickStack UI and automatically authenticated based on your ClickHouse Cloud permissions.

If any OpenTelemetry tables exist already in your service, these will be auto-detected, and corresponding data sources created.

Auto-detection of datasources

Auto-detection relies on the standard OpenTelemetry table schema provided by the ClickStack distribution of the OpenTelemetry collector. Sources are created for the database with the most complete set of tables. Additional tables can be added as [separate data sources](/docs/use-cases/observability/clickstack/config#datasource-settings) if needed.

If auto detection is successful, you should be directed to the search view where you can immediately begin exploring your data.

If this step is successful, that that's it — you’re all set 🎉, otherwise proceed to setting up ingestion.

Setup ingestion

### Setup ingestion[​](#setup-ingestion-existing-service "Direct link to Setup ingestion")

If auto-detection fails, or you have no existing tables, you will be prompted to set up ingestion.

Select "Start Ingestion" and you'll be prompted to select an ingestion source. Managed ClickStack supports OpenTelemetry and [Vector](https://vector.dev/) as its main ingestion sources. However, users are also free to send data directly to ClickHouse in their own schema using any of the [ClickHouse Cloud support integrations](/docs/integrations).

OpenTelemetry recommended

Use of the OpenTelemetry is strongly recommended as the ingestion format.
It provides the simplest and most optimized experience, with out-of-the-box schemas that are specifically designed to work efficiently with ClickStack.

- OpenTelemetry- Vector

To send OpenTelemetry data to Managed ClickStack, you're recommended to use an OpenTelemetry Collector. The collector acts as a gateway that receives OpenTelemetry data from your applications (and other collectors) and forwards it to ClickHouse Cloud.

If you don't already have one running, start a collector using the steps below. If you have existing collectors, a configuration example is also provided.

### Start a collector[​](#start-a-collector-existing "Direct link to Start a collector")

The following assumes the recommended path of using the **ClickStack distribution of the OpenTelemetry Collector**, which includes additional processing and is optimized specifically for ClickHouse Cloud. If you're looking to use your own OpenTelemetry Collector, see ["Configure existing collectors."](#configure-existing-collectors)

To get started quickly, copy and run the Docker command shown.

**Modify this command with your service credentials, recorded when you created your service.**

Deploying to production

While this command uses the `default` user to connect Managed ClickStack, you should create a dedicated user when [going to production](/docs/use-cases/observability/clickstack/production#create-a-database-ingestion-user-managed) and modifying your configuration.

Running this single command starts the ClickStack collector with OTLP endpoints exposed on ports 4317 (gRPC) and 4318 (HTTP). If you already have OpenTelemetry instrumentation and agents, you can immediately begin sending telemetry data to these endpoints.

### Configure existing collectors[​](#configure-existing-collectors-existing "Direct link to Configure existing collectors")

It's also possible to configure your own existing OpenTelemetry Collectors or use your own distribution of the collector.

ClickHouse exporter required

If you're using your own distribution, for example the [contrib image](https://github.com/open-telemetry/opentelemetry-collector-contrib), ensure that it includes the [ClickHouse exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/clickhouseexporter).

For this purpose, you're provided with an example OpenTelemetry Collector configuration that uses the ClickHouse exporter with appropriate settings and exposes OTLP receivers. This configuration matches the interfaces and behavior expected by the ClickStack distribution.

An example of this configuration is shown below (environment variables will be pre-populated if copying from the UI):