Remote Demo Dataset

[Edit this page](https://github.com/ClickHouse/clickhouse-docs/blob/main/docs/use-cases/observability/clickstack/example-datasets/remote-demo-data.md)

**The following guide assumes you have deployed Open Source ClickStack using the [instructions for the all-in-one image](/docs/use-cases/observability/clickstack/getting-started/oss), or [Local Mode Only](/docs/use-cases/observability/clickstack/deployment/local-mode-only) and completed initial user creation. Alternatively, you can skip all local setup and simply connect to our ClickStack hosted demo [play-clickstack.clickhouse.com](https://play-clickstack.clickhouse.com) which uses this dataset.**

This guide uses a sample dataset hosted on the public ClickHouse playground at [sql.clickhouse.com](https://sql.clickhouse.com), which you can connect to from your local ClickStack deployment.

Not supported with Managed ClickStack

Remote databases aren't supported when using Managed ClickStack. This dataset is therefore not supported.

It contains approximately 40 hours of data captured from the ClickHouse version of the official OpenTelemetry (OTel) demo. The data is replayed nightly with timestamps adjusted to the current time window, allowing users to explore system behavior using HyperDX's integrated logs, traces, and metrics.

Data variations

Because the dataset is replayed from midnight each day, the exact visualizations may vary depending on when you explore the demo.

## Demo scenario[​](#demo-scenario "Direct link to Demo scenario")

In this demo, we investigate an incident involving an e-commerce website that sells telescopes and related accessories.

The customer support team has reported that users are experiencing issues completing payments at checkout. The issue has been escalated to the Site Reliability Engineering (SRE) team for investigation.

Using HyperDX, the SRE team will analyze logs, traces, and metrics to diagnose and resolve the issue—then review session data to confirm whether their conclusions align with actual user behavior.

## OpenTelemetry Demo[​](#otel-demo "Direct link to OpenTelemetry Demo")

This demo uses a [ClickStack maintained fork](https://github.com/ClickHouse/opentelemetry-demo) of the official OpenTelemetry demo.

### Demo Architecture[​](#demo-architecture "Direct link to Demo Architecture")

The demo is composed of microservices written in different programming languages that talk to each other over gRPC and HTTP and a load generator that uses Locust to fake user traffic. The original source code for this demo has been modified to use [ClickStack instrumentation](/docs/use-cases/observability/clickstack/sdks).

*Credit: <https://opentelemetry.io/docs/demo/architecture/>*

Further details on the demo can be found in:

- [OpenTelemetry documentation](https://opentelemetry.io/docs/demo/)
- [ClickStack maintained fork](https://github.com/ClickHouse/opentelemetry-demo)

## Demo steps[​](#demo-steps "Direct link to Demo steps")

**We have instrumented this demo with [ClickStack SDKs](/docs/use-cases/observability/clickstack/sdks), deploying the services in Kubernetes, from which metrics and logs have also been collected.**

Connect to the demo server

### Connect to the demo server[​](#connect-to-the-demo-server "Direct link to Connect to the demo server")

Local-Only mode

This step can be skipped if you clicked `Connect to Demo Server` when deploying in Local Mode. If using this mode, sources will be prefixed with `Demo_` e.g. `Demo_Logs`

Navigate to `Team Settings` and click `Edit` for the `Local Connection`:

Rename the connection to `Demo` and complete the subsequent form with the following connection details for the demo server:

- `Connection Name`: `Demo`
- `Host`: `https://sql-clickhouse.clickhouse.com`
- `Username`: `otel_demo`
- `Password`: Leave empty

Modify the sources

### Modify the sources[​](#modify-sources "Direct link to Modify the sources")

Local-Only mode

This step can be skipped if you clicked `Connect to Demo Server` when deploying in Local Mode. If using this mode, sources will be prefixed with `Demo_` e.g. `Demo_Logs`

Scroll up to `Sources` and modify each of the sources - `Logs`, `Traces`, `Metrics`, and `Sessions` - to use the `otel_v2` database.

Note

You may need to reload the page to ensure the full list of databases is listed in each source.

Adjust the time frame

### Adjust the time frame[​](#adjust-the-timeframe "Direct link to Adjust the time frame")

Adjust the time to show all data from the previous `1 day` using the time picker in the top right.

You may a small difference in the number of errors in the overview bar chart, with a small increase in red in several consecutive bars.

Note

The location of the bars will differ depending on when you query the dataset.

Filter to errors

### Filter to errors[​](#filter-to-errors "Direct link to Filter to errors")

To highlight occurrences of errors, use the `SeverityText` filter and select `error` to display only error-level entries.

The error should be more apparent:

Identify the error patterns

### Identify the error patterns[​](#identify-error-patterns "Direct link to Identify the error patterns")

With HyperDX's Clustering feature, you can automatically identify errors and group them into meaningful patterns. This accelerates user analysis when dealing with large volumes of log and traces. To use it, select `Event Patterns` from the `Analysis Mode` menu on the left panel.

The error clusters reveal issues related to failed payments, including a named pattern `Failed to place order`. Additional clusters also indicate problems charging cards and caches being full.

Note that these error clusters likely originate from different services.

Explore an error pattern

### Explore an error pattern[​](#explore-error-pattern "Direct link to Explore an error pattern")

Click the most obvious error clusters which correlates with our reported issue of users being able to complete payments: `Failed to place order`.

This will display a list of all occurrences of this error which are associated with the `frontend` service:

Select any of the resulting errors. The logs metadata will be shown in detail. Scrolling through both the `Overview` and `Column Values` suggests an issue with the charging cards due to a cache:

`failed to charge card: could not charge the card: rpc error: code = Unknown desc = Visa cache full: cannot add new item.`

Explore the infrastructure

### Explore the infrastructure[​](#explore-the-infrastructure "Direct link to Explore the infrastructure")

We've identified a cache-related error that's likely causing payment failures. We still need to identify where this issue is originating from in our microservice architecture.

Given the cache issue, it makes sense to investigate the underlying infrastructure - potentially we have memory problem in the associated pods? In ClickStack, logs and metrics are unified and displayed in context, making it easier to uncover the root cause quickly.

Select the `Infrastructure` tab to view the metrics associated with the underlying pods for the `frontend` service and widen the timespan to `1d`:

The issue doesn't seem to infrastructure related - no metrics have appreciably changed over the time period: either before or after the error. Close the infrastructure tab.

Explore a trace

### Explore a trace[​](#explore-a-trace "Direct link to Explore a trace")

In ClickStack, traces are also automatically correlated with both logs and metrics. Let's explore the trace linked to our selected log to identify the service responsible.

Select `Trace` to visualize the associated trace. Scrolling down through the subsequent view we can see how HyperDX is able to visualize the distributed trace across the microservices, connecting the spans in each service. A payment clearly involves multiple microservices, including those that performance checkout and currency conversions.

By scrolling to the bottom of the view we can see that the `payment` service is causing the error, which in turn propagates back up the call chain.

Searching traces

### Searching traces[​](#searching-traces "Direct link to Searching traces")