Sample logs, traces and metrics

Explore ClickHouse Observability using sample logs, sessions, traces, and metrics from an e-commerce store. Both deployment modes use the same dataset and investigation workflow. Before you begin, complete the fully managed getting started guide or the self-managed getting started guide.

Configure your connection

Choose your deployment and set the following variables in the terminal where you will load the sample data.

Fully managed
Self-managed

Open Team Settings → Data and find Managed Telemetry. Under OpenTelemetry Collector, use the URL option to copy the OTLP HTTP endpoint and API key. Select Reveal key to view the full values.Set the base endpoint without a signal path such as /v1/logs. Include the Bearer prefix in the authorization value:

export CLICKSTACK_OTLP_ENDPOINT='<your-managed-otlp-http-endpoint>'
export CLICKSTACK_AUTHORIZATION='Bearer <your-api-key>'

You do not need to deploy a collector for this example.

You need a running ClickStack OpenTelemetry collector connected to your ClickHouse Cloud service. Follow the Ingesting with OpenTelemetry guide to configure the connection, or the deployment guide to start a collector.Set the collector’s OTLP HTTP endpoint, reachable from the machine running the upload command. Use the base URL without a signal path such as /v1/logs:

export CLICKSTACK_OTLP_ENDPOINT='http://<collector-host>:4318'
export CLICKSTACK_AUTHORIZATION=''

If the collector requires authentication, set CLICKSTACK_AUTHORIZATION to its receiver token. For a ClickStack collector secured with OTLP_AUTH_TOKEN, use that value without a Bearer prefix. Leave the value empty for a receiver that does not require authentication. Do not use your ClickHouse database password here.

Download sample data

In order to populate the UI with sample data, download the following file:Sample data

# curl
curl -O https://storage.googleapis.com/hyperdx/sample.tar.gz
# or
# wget https://storage.googleapis.com/hyperdx/sample.tar.gz

This file contains example logs, metrics, and traces from our public OpenTelemetry demo - a simple e-commerce store with microservices. Copy this file to a directory of your choosing.

Load sample data

Run the following commands in Bash from the directory containing sample.tar.gz. They send the sample data to the endpoint configured above, adding an authorization header only when one is required.

set -eo pipefail

auth_headers=()
if [ -n "${CLICKSTACK_AUTHORIZATION:-}" ]; then
  auth_headers=(-H "Authorization: ${CLICKSTACK_AUTHORIZATION}")
fi

for filename in $(tar -tf sample.tar.gz); do
  endpoint="${CLICKSTACK_OTLP_ENDPOINT%/}/v1/${filename%.json}"
  echo "loading ${filename%.json}"
  tar -xOf sample.tar.gz "$filename" | while read -r line; do
    printf '%s\n' "$line" | curl --fail-with-body -sS -X POST "$endpoint" \
      -H "Content-Type: application/json" \
      "${auth_headers[@]}" \
      --data-binary @-
  done
done

This simulates OTLP log, trace, and metric sources sending data. In production, these sources may be application SDKs, agents, or OpenTelemetry Collectors.In the ClickHouse Cloud console, select your service and open ClickHouse Observability.Return to Search to view the loaded data. Select the Logs source and a time range that includes the sample events’ timestamps. The screenshot below shows sample logs arriving in Live Tail:Data loading will take a few minutes. Allow for the load to be completed before progressing to the next steps.

Explore sessions

Suppose we have reports that our users are experiencing issues paying for goods. We can view their experience using session replay.Select Client Sessions from the left menu and set a time range that includes the loaded sample sessions.This view lists sessions from the demo store, including anonymous sessions and sessions identified by an email address.Some sessions have a nonzero error count. In this example, the highlighted session has one error.Select the highlighted session to open its replay. Use the play button at the bottom of the player to watch the session.The replay shows the user navigating the site, adding items to their cart. Feel free to skip to later in the session where they attempt to complete a payment.

Error events are marked in red in the event list.

Scroll to the bottom of the event list on the left. The highlighted POST /api/checkout request returned HTTP 500, with a console error recorded at the same time.Select the failed POST /api/checkout event to inspect the request and its trace.

Explore traces

Open the Trace tab to see the distributed trace, including related spans and correlated logs.Scroll down the trace and select the oteldemo.PaymentService/Charge span in the checkout service.In the Overview tab, inspect Top Level Attributes. The StatusCode is Error, and the StatusMessage indicates that the credit card has expired.In the trace, select the payment error log beneath the payment service span. Its row has a log icon, distinguishing it from the error span event. In Overview, the log’s Body confirms that the credit card has expired. The attributes identify the payment service and an error severity, providing context alongside the trace.We’ve traced this failed checkout to a payment request rejected because the credit card had expired.

Explore logs

To investigate other payment failures, return to Search.Select Logs as the source and choose payment under the ServiceName filter. Use a time range that includes the session you investigated.The results include the expired-card error from the session we investigated, as well as repeated Visa cache full: cannot add new item. errors. To see when errors occur across the payment service, chart these error logs over time.

Chart payment errors

Open Chart Explorer, select Time Series, and choose Logs as the data source. Select Count of Events as the aggregation.In Where, select Lucene and enter the following filter:

SeverityText:"error" ServiceName:"payment"

Set a time range covering the sample data and select Run.The chart shows the number of matching error logs in each time interval. It includes all errors from the payment service, including expired-card and cache-full errors. These are log-event counts, not a count of unique failed payments.

Introduction

Features

Administration

Guides

Integration partners

Self-managed