> ## 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. # Setting up your OpenTelemetry Collector > Setting up an OpenTelemetry Collector for Managed ClickStack This guide walks you through deploying an OpenTelemetry collector against an existing Managed ClickStack service, or adapting your existing collector, before verifying that data is flowing through. Install the official ClickHouse agent skills before using the setup assistant: ```bash theme={null} npx skills add clickhouse/agent-skills ``` If you already have [`clickhousectl`](https://clickhouse.com/docs/concepts/features/interfaces/cli), you can install the same skills into the coding agents it detects instead: ```bash theme={null} clickhousectl skills --detected-only ``` To target one agent, pass `--agent` (for example, `--agent claude`). Add `--global` to install into your home directory rather than the current project. Agent-Assisted Setup `Use the clickstack-otel-collector skill to wire an OpenTelemetry collector into my Managed ClickStack service.` Copy Prompt Copied Your agent will set up the ClickStack OpenTelemetry collector for you. Works with Claude Code, Cursor, Codex, and other coding agents. [ClickHouse/agent-skills](https://github.com/ClickHouse/agent-skills) The collector runs as a **gateway**: a single OTLP endpoint that your applications, SDKs, and agent collectors send to. The gateway batches events, applies any processing you've configured, and writes them to ClickHouse via the [ClickHouse exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/clickhouseexporter). This pattern keeps collection logic out of your application code and lets you scale ingestion independently of the workloads producing data. For background on gateway versus agent roles, see [Collector roles](https://clickhouse.com/docs/clickstack/ingesting-data/collector.md#collector-roles). > [!NOTE] > > **Existing collector** > > If you're using an existing OpenTelemetry collector, we assume it's already configured in a **gateway** role. We don't recommend using this process for reconfiguring collectors in the **agent** role. Pick the tab that matches your situation: > [tab] I don't have a collector > > **1. Gather your credentials** > > You'll need: > > * The HTTPS endpoint of your ClickHouse Cloud service, including protocol and port, for example `https://abc123xyz.us-central1.gcp.clickhouse.cloud:8443`. > * A ClickHouse username and password for ingestion. > > If you don't have these recorded, open your service in the [ClickHouse Cloud console](https://console.clickhouse.cloud) and select **Connect**. Record the url from the subsequent dialog. We will create a dedicated user for ingestion below. > > ![Service connect panel showing HTTPS endpoint and password](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-cloud-connect.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=3c52fcace4a2f7017b40dfd367553abf) > > **2. Create an ingestion user** > > We recommend creating a dedicated user for the collector rather than reusing `default`. Connect to your service via the SQL console and run: > > ```sql theme={null} > CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY 'ClickH0u3eRocks123!'; > GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest; > ``` > > > [!TIP] > > > > Replace the password in the snippet above with a strong value. > > The collector creates the schema for logs, traces, and metrics inside the `otel` database on first use. For more guidance on production user setup, see [Going to production](https://clickhouse.com/docs/clickstack/managing/production.md#create-a-database-ingestion-user-managed). > > **3. Deploy the collector** > > Deploy the **ClickStack distribution of the OpenTelemetry collector**, which is preconfigured for Managed ClickStack. In the example below, we run the collector locally and generate artificial telemetry from the same machine for simplicity. > > > [!NOTE] > > > > In production, you would typically deploy the collector in a Kubernetes cluster, or on a virtual machine that can be reached by your OpenTelemetry SDKs, agents, and other collectors. This allows telemetry from across your environment to be centrally collected and forwarded to ClickStack. > > Pick a shared secret to authenticate clients sending data to the collector, then export it alongside your connection details and chosen password for the `hyperdx_ingest` user: > > ```shell theme={null} > export CLICKHOUSE_ENDPOINT= > export CLICKHOUSE_USER=hyperdx_ingest > export CLICKHOUSE_PASSWORD=ClickH0u3eRocks123! > export OTLP_AUTH_TOKEN="a-strong-shared-secret" > ``` > > Run the ClickStack OTel collector: > > ```shell theme={null} > docker run -d \ > -e OTLP_AUTH_TOKEN=${OTLP_AUTH_TOKEN} \ > -e CLICKHOUSE_ENDPOINT=${CLICKHOUSE_ENDPOINT} \ > -e CLICKHOUSE_USER=${CLICKHOUSE_USER} \ > -e CLICKHOUSE_PASSWORD=${CLICKHOUSE_PASSWORD} \ > -e HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=otel \ > -p 4317:4317 \ > -p 4318:4318 \ > clickhouse/clickstack-otel-collector:latest > ``` > > The collector now exposes OTLP gRPC on `4317` and OTLP HTTP on `4318`. Applications, SDKs, and agent collectors should send to these ports with `authorization: $OTLP_AUTH_TOKEN` in the request headers. > > > [!NOTE] > > > > **Production deployments** > > > > For production, we recommend enabling TLS on the OTLP endpoint. See [Securing the collector](https://clickhouse.com/docs/clickstack/ingesting-data/collector.md#securing-the-collector). > > **4. Verify the endpoint** > > Generate some synthetic traffic against the collector to confirm the full pipeline works. We use [`telemetrygen`](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/cmd/telemetrygen), the OpenTelemetry Collector Contrib generator, which emits OTLP logs, traces, and metrics and exposes flags to shape the data across services, severities, span statuses, and metric types. > > Run it from its Docker image (no install required). Define a small wrapper so the commands below stay readable; `--add-host` lets the container reach a collector listening on the host: > > ```shell theme={null} > telemetrygen() { > docker run --rm --add-host=host.docker.internal:host-gateway \ > ghcr.io/open-telemetry/opentelemetry-collector-contrib/telemetrygen:latest "$@" > } > export OTEL_ENDPOINT=host.docker.internal:4317 > ``` > > Or install the binary with Go and target `localhost` instead: > > ```shell theme={null} > go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest > export OTEL_ENDPOINT=localhost:4317 > ``` > > > [!NOTE] > > > > **What to expect** > > > > Each `tg` run lasts about 20 seconds (set by `--duration 20s`) and streams verbose logs the whole time, that's expected; each run returns on its own once its 20 seconds elapse. The logs below are enough to confirm the pipeline; the optional richer set adds several more runs and takes a few minutes. > > Define a small `tg` helper so each command only specifies what varies (service, severity, status, attributes): > > ```shell theme={null} > tg() { local signal=$1; shift; telemetrygen "$signal" \ > --otlp-endpoint ${OTEL_ENDPOINT} --otlp-insecure \ > --otlp-header "authorization=\"${OTLP_AUTH_TOKEN}\"" \ > --rate 5 --duration 20s "$@"; } > ``` > > Send logs as a realistic mix of severities across services, mostly informational with a warning and an error rather than one uniform error stream: > > ```shell theme={null} > tg logs --service frontend --severity-text Info --severity-number 9 --body "GET /api/products 200" \ > --otlp-attributes 'deployment.environment="production"' \ > --telemetry-attributes 'http.method="GET"' --telemetry-attributes 'http.status_code="200"' > tg logs --service checkout --severity-text Warn --severity-number 13 --body "retrying payment authorization" \ > --otlp-attributes 'deployment.environment="production"' \ > --telemetry-attributes 'http.method="POST"' > tg logs --service payment --severity-text Error --severity-number 17 --body "payment gateway timeout" \ > --otlp-attributes 'deployment.environment="production"' \ > --telemetry-attributes 'http.status_code="500"' > ``` > > Logs alone confirm the endpoint is working. For a richer demo dataset, a multi-service Service Map and charts across metric types, expand and run the commands below as well. They reuse the `tg` helper, so run them in the same shell. > > > [accordion] Generate richer telemetry (optional) > > > > Send multi-span traces from several healthy services plus one failing dependency. This gives the Service Map a realistic shape, mostly healthy with one erroring service, and still populates the error views: > > > > ```shell theme={null} > > # Healthy services: the bulk of the traffic, all spans Ok > > for svc in frontend checkout cart; do > > tg traces --service "$svc" --child-spans 3 --span-duration 80ms --status-code Ok \ > > --otlp-attributes 'deployment.environment="production"' \ > > --telemetry-attributes "http.route=\"/$svc\"" > > done > > > > # One slow dependency returning errors > > tg traces --service payment --child-spans 3 --span-duration 450ms --span-links 1 --status-code Error \ > > --otlp-attributes 'deployment.environment="production"' \ > > --telemetry-attributes 'http.route="/charge"' > > ``` > > > > Send metrics across the three common types, so charts have a counter, a gauge, and a distribution: > > > > ```shell theme={null} > > tg metrics --service frontend --metric-type Sum --otlp-metric-name http.server.requests --aggregation-temporality cumulative > > tg metrics --service frontend --metric-type Gauge --otlp-metric-name system.memory.usage > > tg metrics --service payment --metric-type Histogram --otlp-metric-name http.server.duration > > ``` > > > > For even more variety, add a couple more services and an exponential histogram: > > > > ```shell theme={null} > > tg traces --service catalog --child-spans 2 --span-duration 60ms --status-code Ok \ > > --otlp-attributes 'deployment.environment="production"' --telemetry-attributes 'http.route="/catalog"' > > tg traces --service inventory --child-spans 2 --span-duration 220ms --status-code Ok \ > > --otlp-attributes 'deployment.environment="staging"' --telemetry-attributes 'http.route="/inventory"' > > tg metrics --service payment --metric-type ExponentialHistogram --otlp-metric-name db.query.duration > > ``` > > For the full set of flags and more variations, see [Synthetic data with telemetrygen](https://clickhouse.com/docs/clickstack/example-datasets/telemetrygen.md). > > **5. Confirm in the ClickStack UI** > > Open your service in the [ClickHouse Cloud console](https://console.clickhouse.cloud) and select **ClickStack** from the left menu and then **Start Ingestion**. > > ![Launch ClickStack](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-cloud-first-time.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=e79f6d11184a956f6ae36350ed29cba3) > > The next step can be skipped, as you've already configured your collector. Click **Launch ClickStack** to continue. > > ClickStack will open in a new tab and you should be automatically directed to the **Getting Started** page. If not, select **Getting Started** from the left-hand menu, then click **Start Ingestion** followed by **Next**. > > ![ClickStack Start Ingestion](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-start-ingestion.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=e085e78defc67b60cb5d8aaab787ac47) > > You'll land on the **Getting Started** page. If you're prompted to begin ingestion, proceed through the onboarding screens that guide you to start a Docker collector. Since you've already completed that step, you can simply click through them. ClickStack will automatically detect your telemetry data and tables, after which you can select **Start Exploring** to begin using the platform. > > ![ClickStack Start Exploring](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-start-exploring.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=d5e3d2a0f2f04ef1454f5a72e6e94aa7) > > Switch the source to `Logs` and set the time range to **Last 15 minutes**. The synthetic logs from `telemetrygen` should appear within a few seconds. > > ![ClickStack Search view with logs appearing](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-search.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=6939a7b4fa87ff373273cbb57b7988b4) > > If nothing shows up: > > * Confirm the auth header value passed to `telemetrygen` matches the one your collector expects. > * Tail your collector's logs and look for export errors. > * Verify the ClickHouse endpoint configured on the collector includes both the protocol and port (`https://...:8443`). > [tab] I have a collector > > **1. Gather your credentials** > > You'll need: > > * The HTTPS endpoint of your ClickHouse Cloud service, including protocol and port, for example `https://abc123xyz.us-central1.gcp.clickhouse.cloud:8443`. > * A ClickHouse username and password for ingestion. > > If you don't have these recorded, open your service in the [ClickHouse Cloud console](https://console.clickhouse.cloud) and select **Connect**. Record the url from the subsequent dialog. We will create a dedicated user for ingestion below. > > ![Service connect panel showing HTTPS endpoint and password](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-cloud-connect.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=3c52fcace4a2f7017b40dfd367553abf) > > **2. Create an ingestion user** > > We recommend creating a dedicated user for the collector rather than reusing `default`. Connect to your service via the SQL console and run: > > ```sql theme={null} > CREATE USER hyperdx_ingest IDENTIFIED WITH sha256_password BY 'ClickH0u3eRocks123!'; > GRANT SELECT, INSERT, CREATE DATABASE, CREATE TABLE, CREATE VIEW ON otel.* TO hyperdx_ingest; > ``` > > > [!TIP] > > > > Replace the password in the snippet above with a strong value. > > The collector creates the schema for logs, traces, and metrics inside the `otel` database on first use. For more guidance on production user setup, see [Going to production](https://clickhouse.com/docs/clickstack/managing/production.md#create-a-database-ingestion-user-managed). > > **3. Adapt your collector configuration** > > Extend your existing collector configuration to write to Managed ClickStack via the [ClickHouse exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/clickhouseexporter). > > > [!NOTE] > > > > **ClickHouse exporter required** > > > > If you're using your own distribution, ensure it includes the ClickHouse exporter. The upstream [contrib image](https://github.com/open-telemetry/opentelemetry-collector-contrib) already does. > > Below is an example configuration that uses the ClickHouse exporter with the receivers, processors, and pipelines expected by the ClickStack UI. It matches the behavior of the ClickStack distribution, including the Session Replay (`rrweb`) routing path. Substitute `` and `` with the credentials for the `hyperdx_ingest` user created above: > > ```yaml theme={null} > receivers: > otlp/hyperdx: > protocols: > grpc: > include_metadata: true > endpoint: "0.0.0.0:4317" > http: > cors: > allowed_origins: ["*"] > allowed_headers: ["*"] > include_metadata: true > endpoint: "0.0.0.0:4318" > > processors: > batch: > memory_limiter: > # 80% of maximum memory up to 2G, adjust for low memory environments > limit_mib: 1500 > # 25% of limit up to 2G, adjust for low memory environments > spike_limit_mib: 512 > check_interval: 5s > > connectors: > routing/logs: > default_pipelines: [logs/out-default] > error_mode: ignore > table: > - context: log > statement: route() where IsMatch(attributes["rr-web.event"], ".*") > pipelines: [logs/out-rrweb] > > exporters: > clickhouse: > database: otel > endpoint: > username: hyperdx_ingest > password: > ttl: 720h > timeout: 5s > retry_on_failure: > enabled: true > initial_interval: 5s > max_interval: 30s > max_elapsed_time: 300s > clickhouse/rrweb: > database: otel > endpoint: > username: hyperdx_ingest > password: > ttl: 720h > logs_table_name: hyperdx_sessions > timeout: 5s > retry_on_failure: > enabled: true > initial_interval: 5s > max_interval: 30s > max_elapsed_time: 300s > > service: > pipelines: > traces: > receivers: [otlp/hyperdx] > processors: [memory_limiter, batch] > exporters: [clickhouse] > metrics: > receivers: [otlp/hyperdx] > processors: [memory_limiter, batch] > exporters: [clickhouse] > logs/in: > receivers: [otlp/hyperdx] > exporters: [routing/logs] > logs/out-default: > receivers: [routing/logs] > processors: [memory_limiter, batch] > exporters: [clickhouse] > logs/out-rrweb: > receivers: [routing/logs] > processors: [memory_limiter, batch] > exporters: [clickhouse/rrweb] > ``` > > A few things to note: > > * The `otlp/hyperdx` receiver listens on both gRPC (`4317`) and HTTP (`4318`); applications and agents should target these ports on your collector host. > * The `clickhouse` exporter writes logs, traces, and metrics into the `otel` database, matching the layout the ClickStack UI expects. The `clickhouse/rrweb` exporter handles Session Replay events routed by the `routing/logs` connector into `otel.hyperdx_sessions`. > * Authentication on the OTLP receivers is left to your existing setup. Configure it via collector [extensions](https://opentelemetry.io/docs/collector/configuration/#extensions) (for example `bearertokenauth`) or a TLS-fronted reverse proxy if you need to require an ingestion token. > > Reload your collector with the new configuration. Applications, SDKs, and agent collectors should then send to the OTLP endpoints exposed by your collector with whatever auth header your setup expects. > > For further details on configuring OpenTelemetry collectors against Managed ClickStack, see [Ingesting with OpenTelemetry](https://clickhouse.com/docs/clickstack/ingesting-data/opentelemetry.md). > > **4. Verify the endpoint** > > Generate some synthetic traffic against your collector to confirm the full pipeline works. We use [`telemetrygen`](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/cmd/telemetrygen), the OpenTelemetry Collector Contrib generator, which emits OTLP logs, traces, and metrics and exposes flags to shape the data across services, severities, span statuses, and metric types. > > Run it from its Docker image (no install required). Substitute `` with the host your collector listens on, and set the `authorization` header (or alternative auth method) to whatever your collector expects: > > ```shell theme={null} > telemetrygen() { > docker run --rm --add-host=host.docker.internal:host-gateway \ > ghcr.io/open-telemetry/opentelemetry-collector-contrib/telemetrygen:latest "$@" > } > export OTEL_ENDPOINT=:4317 > export OTLP_AUTH_TOKEN= > ``` > > Or install the binary with Go: > > ```shell theme={null} > go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest > ``` > > > [!NOTE] > > > > **What to expect** > > > > Each `tg` run lasts about 20 seconds (set by `--duration 20s`) and streams verbose logs the whole time, that's expected; each run returns on its own once its 20 seconds elapse. The logs below are enough to confirm the pipeline; the optional richer set adds several more runs and takes a few minutes. > > Define a small `tg` helper so each command only specifies what varies (service, severity, status, attributes): > > ```shell theme={null} > tg() { local signal=$1; shift; telemetrygen "$signal" \ > --otlp-endpoint ${OTEL_ENDPOINT} --otlp-insecure \ > --otlp-header "authorization=\"${OTLP_AUTH_TOKEN}\"" \ > --rate 5 --duration 20s "$@"; } > ``` > > Send logs as a realistic mix of severities across services, mostly informational with a warning and an error rather than one uniform error stream: > > ```shell theme={null} > tg logs --service frontend --severity-text Info --severity-number 9 --body "GET /api/products 200" \ > --otlp-attributes 'deployment.environment="production"' \ > --telemetry-attributes 'http.method="GET"' --telemetry-attributes 'http.status_code="200"' > tg logs --service checkout --severity-text Warn --severity-number 13 --body "retrying payment authorization" \ > --otlp-attributes 'deployment.environment="production"' \ > --telemetry-attributes 'http.method="POST"' > tg logs --service payment --severity-text Error --severity-number 17 --body "payment gateway timeout" \ > --otlp-attributes 'deployment.environment="production"' \ > --telemetry-attributes 'http.status_code="500"' > ``` > > Logs alone confirm the endpoint is working. For a richer demo dataset, a multi-service Service Map and charts across metric types, expand and run the commands below as well. They reuse the `tg` helper, so run them in the same shell. > > > [accordion] Generate richer telemetry (optional) > > > > Send multi-span traces from several healthy services plus one failing dependency. This gives the Service Map a realistic shape, mostly healthy with one erroring service, and still populates the error views: > > > > ```shell theme={null} > > # Healthy services: the bulk of the traffic, all spans Ok > > for svc in frontend checkout cart; do > > tg traces --service "$svc" --child-spans 3 --span-duration 80ms --status-code Ok \ > > --otlp-attributes 'deployment.environment="production"' \ > > --telemetry-attributes "http.route=\"/$svc\"" > > done > > > > # One slow dependency returning errors > > tg traces --service payment --child-spans 3 --span-duration 450ms --span-links 1 --status-code Error \ > > --otlp-attributes 'deployment.environment="production"' \ > > --telemetry-attributes 'http.route="/charge"' > > ``` > > > > Send metrics across the three common types, so charts have a counter, a gauge, and a distribution: > > > > ```shell theme={null} > > tg metrics --service frontend --metric-type Sum --otlp-metric-name http.server.requests --aggregation-temporality cumulative > > tg metrics --service frontend --metric-type Gauge --otlp-metric-name system.memory.usage > > tg metrics --service payment --metric-type Histogram --otlp-metric-name http.server.duration > > ``` > > > > For even more variety, add a couple more services and an exponential histogram: > > > > ```shell theme={null} > > tg traces --service catalog --child-spans 2 --span-duration 60ms --status-code Ok \ > > --otlp-attributes 'deployment.environment="production"' --telemetry-attributes 'http.route="/catalog"' > > tg traces --service inventory --child-spans 2 --span-duration 220ms --status-code Ok \ > > --otlp-attributes 'deployment.environment="staging"' --telemetry-attributes 'http.route="/inventory"' > > tg metrics --service payment --metric-type ExponentialHistogram --otlp-metric-name db.query.duration > > ``` > > For the full set of flags and more variations, see [Synthetic data with telemetrygen](https://clickhouse.com/docs/clickstack/example-datasets/telemetrygen.md). > > **5. Confirm in the ClickStack UI** > > Open your service in the [ClickHouse Cloud console](https://console.clickhouse.cloud) and select **ClickStack** from the left menu and then **Start Ingestion**. > > ![Launch ClickStack](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-cloud-first-time.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=e79f6d11184a956f6ae36350ed29cba3) > > The next step can be skipped, as you've already configured your collector. Click **Launch ClickStack** to continue. > > ClickStack will open in a new tab and you should be automatically directed to the **Getting Started** page. If not, select **Getting Started** from the left-hand menu, then click **Start Ingestion** followed by **Next**. > > ![ClickStack Start Ingestion](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-start-ingestion.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=e085e78defc67b60cb5d8aaab787ac47) > > You'll land on the **Getting Started** page. If you're prompted to begin ingestion, proceed through the onboarding screens that guide you to start a Docker collector. Since you've already completed that step, you can simply click through them. ClickStack will automatically detect your telemetry data and tables, after which you can select **Start Exploring** to begin using the platform. > > ![ClickStack Start Exploring](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-start-exploring.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=d5e3d2a0f2f04ef1454f5a72e6e94aa7) > > Switch the source to `Logs` and set the time range to **Last 15 minutes**. The synthetic logs from `telemetrygen` should appear within a few seconds. > > ![ClickStack Search view with logs appearing](https://mintcdn.com/private-7c7dfe99/uAzQoYEGwuyhrO3W/images/use-cases/observability/clickstack-search.webp?fit=max\&auto=format\&n=uAzQoYEGwuyhrO3W\&q=85\&s=6939a7b4fa87ff373273cbb57b7988b4) > > If nothing shows up: > > * Confirm the auth header value passed to `telemetrygen` matches the one your collector expects. > * Tail your collector's logs and look for export errors. > * Verify the ClickHouse endpoint configured on the collector includes both the protocol and port (`https://...:8443`). ## Next steps: send your own data The synthetic burst above only proves the pipeline works. To start sending real telemetry, instrument your own services with the [ClickStack SDKs](https://clickhouse.com/docs/clickstack/ingesting-data/sdks/index.md), which provide instrumentation for Node.js, Python, Go, Java, and other languages that export OTLP to the collector endpoint you just verified. For a complete worked example, follow [Instrument an application](https://clickhouse.com/docs/clickstack/managed-onboarding/instrument-application). To collect from infrastructure rather than application code: * [Monitoring Kubernetes](https://clickhouse.com/docs/clickstack/managed-onboarding/monitoring-kubernetes): collect logs, infrastructure metrics, and Kubernetes events from a cluster. * [Monitoring AWS CloudWatch logs](https://clickhouse.com/docs/clickstack/managed-onboarding/monitoring-aws-cloudwatch-logs): forward CloudWatch logs via the OpenTelemetry CloudWatch receiver. ## Further reading This guide covers a single collector instance in its simplest form. The [OpenTelemetry collector reference](https://clickhouse.com/docs/clickstack/ingesting-data/collector.md) covers what to do next: * [Deploying the collector in Kubernetes](https://clickhouse.com/docs/clickstack/ingesting-data/collector.md#configuring-the-collector) with the upstream OpenTelemetry Helm chart and the ClickStack collector image. * [Securing the collector](https://clickhouse.com/docs/clickstack/ingesting-data/collector.md#securing-the-collector) with TLS on the OTLP endpoint and least-privilege ingestion users. * [Processing, filtering, and enriching](https://clickhouse.com/docs/clickstack/ingesting-data/collector.md#processing-filtering-transforming-enriching) events at the gateway. * [Extending the collector configuration](https://clickhouse.com/docs/clickstack/ingesting-data/collector.md#extending-collector-config) with custom receivers, processors, and pipelines. * [Estimating resources](https://clickhouse.com/docs/clickstack/ingesting-data/collector.md#estimating-resources) for gateway and agent deployments at your expected throughput. * [Going to production](https://clickhouse.com/docs/clickstack/managing/production.md)