Try the OTel Demo

The OpenTelemetry Demo is a shopping site built from about twenty services in a dozen languages, all instrumented, with a load generator and a set of deliberate failure modes you can switch on. It is the fastest way to see what atrim.ai does with a system that is genuinely distributed — no instrumentation work of your own required.

The demo is designed to bring your own backend: its collector reads an extras file that is merged over the base config, so adding atrim.ai is a few lines and changes nothing else about how the demo runs.

Point the demo at atrim.ai

Clone the demo.

git clone --depth 1 --branch 3.0.0 \
  https://github.com/open-telemetry/opentelemetry-demo.git
cd opentelemetry-demo

Add atrim.ai as an extra exporter.

Edit the demo’s otelcol-config-extras.yml (under src/otel-collector) — the file it provides for exactly this purpose. It is deep-merged over the base collector config, so the demo’s own Jaeger, Prometheus and OpenSearch pipelines keep working:
src/otel-collector/otelcol-config-extras.yml
```
exporters:
  otlphttp/atrim:
    endpoint: https://otlp.atrim.ai
    headers:
      x-api-key: atrim_key_YOUR_KEY_HERE
    timeout: 30s

service:
  pipelines:
    traces:
      exporters: [otlphttp/atrim]
    metrics:
      exporters: [otlphttp/atrim]
    logs:
      exporters: [otlphttp/atrim]
```
Your key is in the app under Admin & Governance → Settings.
Start it.
```
docker compose up --force-recreate --remove-orphans --detach
```
The demo’s own UI comes up at http://localhost:8080. Its load generator starts producing traffic immediately, so you do not have to click anything for data to flow.
Watch it arrive in atrim.ai.

First spans usually land within a minute. Services appear as they take their first request, so the graph fills in rather than appearing all at once.

What to look at

Service Topology is the obvious first stop — the demo’s call graph is deep enough to be interesting, with a frontend fanning out to cart, checkout, payment, shipping, currency and product catalog, and a Kafka hop between checkout and the downstream services. Every edge carries rate, error and duration, so the slow and failing hops are visible on the map before you open a single trace.

Critical Paths is where the demo earns its keep. Rather than a list of slow spans, it ranks the request paths through the system by where the time and the errors actually accumulate, which for this workload means the checkout flow and its Kafka-mediated tail. Open one and analyse it: the analysis names the hop that dominates and what the evidence for that is.

Traces and Logs are there when you want the individual request or line behind a finding rather than the aggregate.

Break something on purpose

The demo ships feature flags that inject real failures. Turn one on at http://localhost:8080/feature, leave it running for a few minutes, and watch what changes in atrim.ai:

Flag	What it does	Where it shows up
`paymentFailure`	Fails a chosen percentage of payment charges (10% through 100%)	Error rate on the payment node; the checkout critical path degrades
`cartFailure`	Cart operations fail	Cart node turns red; failing traces in the checkout path
`productCatalogFailure`	Product catalog errors on one specific product	A subset of requests fail — a partial failure, not a total one
`adManualGc`	Forces garbage collection in the ad service	Latency spikes with no change in error rate
`kafkaQueueProblems`	Kafka queue overload and consumer lag	Latency on the asynchronous hop out of checkout

The partial failures are the interesting ones. A service that is entirely down is easy for any tool to find; a service that fails for one product, or gets slower without failing, is the case that separates a topology view from a dashboard.

Clean up

docker compose down --volumes --remove-orphans

Your telemetry stays in atrim.ai after the demo is gone, so the topology and the critical paths you were looking at are still there.