Skip to main content
This page covers self-managed ClickHouse Observability. For the recommended fully managed experience, see the documentation here.
This guide covers data source settings, the collector you run, and database schema configuration for Self-managed ClickHouse Observability.

User interface

Data source settings

The UI relies on the user defining a source for each of the Observability data types/pillars:
  • Logs
  • Traces
  • Metrics
  • Sessions
Open Team Settings → Data → Sources to configure a source. Select Configure Optional Fields to access additional settings, as highlighted below for logs: Each source needs a table and column mappings that allow the UI to query its data. OTel metric sources use separate tables for each metric type; select the tables containing the metrics you collect. If using the default OpenTelemetry (OTel) schema distributed with ClickStack, these columns can be automatically inferred for each of the sources. If modifying the schema or using a custom schema, users are required to specify and update these mappings.
The ClickStack collector creates its default tables through bundled schema migrations. These schemas build on the ClickHouse exporter for the OTel collector and the OpenTelemetry data model.
The following tables list source settings. Inferred values depend on the columns and tables present in your database. Optional mappings enable the corresponding features, such as trace correlation; they are not required to save a source.

Logs

Traces

Metrics

Sessions

Materialized views

Materialized views can be registered against Log and Trace data sources so that eligible aggregation queries are answered from the pre-aggregated view instead of the source table. For guidance on creating and registering views, see “Materialized views”. Each registered view is configured with the following settings: When you select the target table, the UI attempts to infer these settings from the view schema. Review the inferred values and complete any missing fields.

Metadata materialized views

Metadata materialized views are materialized views which accelerate field discovery for filters and autocomplete. They can be configured on Log and Trace data sources.

Highlighted Attributes

Highlighted Attributes and Highlighted Trace Attributes can be configured on Log and Trace data sources.
  • Highlighted Attributes are columns or expressions which are displayed for each log or span, when viewing log or span details.
  • Highlighted Trace Attributes are columns or expressions which are queried from each log or span in a trace, and displayed above the trace waterfall.
These attributes are defined in the source configuration and can be arbitrary SQL expressions. If the SQL expression returns a value that is in the format of a URL, then the attribute will be displayed as a link. Empty values aren’t displayed. Each attribute is configured with the following settings: For example, this trace source has been configured with a Highlighted Attribute and a Highlighted Trace Attribute: These attributes are displayed in the side panel after clicking on a log or span: Clicking on an attribute provides options for using the attribute as a search value. If the optional Lucene expression is provided in the attribute configuration, then the Lucene expression will be used for the search instead of the SQL expression.

Correlated sources

To enable full cross-source correlation, you must configure correlated sources for logs, traces, metrics, and sessions. This allows the UI to associate related data and provide rich context when rendering events.
  • Logs: Can be correlated with traces and metrics.
  • Traces: Can be correlated with logs, sessions, and metrics.
  • Metrics: Can be correlated with logs.
  • Sessions: Can be correlated with traces.
Setting these correlations enables several features. For example, the UI can render relevant logs alongside a trace and navigate between related sources. Correlation also depends on the appropriate ID and attribute mappings; selecting a source alone does not create those relationships. For example, below is the Logs source configured with correlated sources:

OpenTelemetry collector

See “ClickStack OpenTelemetry Collector” for more details.
  • CLICKHOUSE_ENDPOINT
    • Default: None (required) for the standalone collector image.
    • Description: The ClickHouse connection URL used by the exporter.
    • Guidance:
      • Use a secure ClickHouse Cloud endpoint, such as https://<host>:8443 or tcp://<host>:9440?secure=true
      • Required for the collector to send data to ClickHouse
  • CLICKHOUSE_USER
    • Default: default in the migration tool; set explicitly for the standalone collector.
    • Description: Username used to authenticate with the ClickHouse instance.
    • Guidance:
      • The user needs permission to insert telemetry and, when schema creation or migrations are enabled, to create or alter the required database objects
      • Recommended to create a dedicated user for ingestion
  • CLICKHOUSE_PASSWORD
    • Default: None (required if authentication is enabled)
    • Description: Password for the specified ClickHouse user.
    • Guidance:
      • Required if the user account has a password set
      • Store securely via secrets in production deployments
  • HYPERDX_LOG_LEVEL
    • Default: Deployment-specific; set explicitly, for example info.
    • Description: Log verbosity level for the collector.
    • Guidance:
      • Accepts values like debug, info, warn, error
      • Use debug during troubleshooting
  • OTLP_AUTH_TOKEN
    • Default: None. Used only for standalone image.
    • Description: Sets the token required for standalone OTLP ingestion. The current collector accepts its value in the Authorization header either directly or with a Bearer prefix. Older collector versions may require the bare token. Ignored when OIDC authentication is configured.
    • Guidance:
      • Configure authentication before exposing the collector. Without a token or OIDC configuration, the standalone OTLP receiver accepts unauthenticated requests.
  • HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE
    • Default: default in the migration tool; set explicitly for the standalone collector.
    • Description: ClickHouse database the collector writes telemetry data to.
    • Guidance:
      • Set if using a custom database name
      • Ensure the specified user has access to this database

ClickHouse

To tune ClickHouse effectively, you should understand key storage concepts such as parts, partitions, shards and replicas, and how merges occur at insert time. We recommend reviewing the fundamentals of primary indices, sparse secondary indices, and data skipping indices, along with techniques for managing data lifecycle e.g. using a TTL lifecycle. You can use schema customization - you may modify column types, extract new fields (e.g. from logs), apply codecs and dictionaries, and accelerate queries using projections. Additionally, materialized views can be used to transform or filter data during ingestion, provided that data is written to the source table of the view and the application reads from the target table. Materialized views can also be used to accelerate queries natively in the service. For more details, refer to ClickHouse documentation on schema design, indexing strategies, and data management best practices - most of which apply directly to Self-managed deployments.