Would you trust this telemetry?
Each case shows real, anonymized OpenTelemetry® data and a conclusion someone drew from it. Some conclusions hold up, some don't. Make the call, then see the tell and the fix.
Ready when you are
10 conclusions. Does the telemetry back them up?
Someone read this telemetry and drew a conclusion. Sometimes the data is broken, sometimes the reading is. Half the conclusions hold. No timer and no sign-up.
Anonymized, but real. Every case comes from production OpenTelemetry data that OllyGarden sampled and analyzed. We invented every service, host, endpoint, and ID name and removed anything that could identify the source. Status codes, span structure, and ratios are as measured.
How it works
01 Read the situation
An on-call moment and the conclusion someone drew from the telemetry, the way it would come up in an incident channel.
02 Inspect the telemetry
A trace waterfall, log records, a span, a table, a chart, or a service map, as your backend would show it.
03 Make the call
Does the telemetry back the conclusion up? Half the conclusions hold, so doubting everything won't win.
04 See the tell
Each reveal says whether the data or the reading was at fault, points at the detail that settles it, and shows the fix.
What you'll practice
20 cases across traces, logs, spans, and metrics. Each game deals 10 of them, half that hold up and half that don't.
- Span status and span kinds
- When ERROR marks a real failure, and which parent and child spans may overlap.
- Log severity
- Why a severity filter can come back empty while the service is failing.
- Timestamps
- Event time, observed time, and what a time-range search can miss.
- Trace context
- How parent and child links carry a request across services and message brokers.
- Service identity
- What service.name tells you, and what an SDK default hides.
- Protocol status
- Where HTTP and gRPC each report success and failure.
About the game
Where the cases come from and what OllyGarden does with telemetry like this.
Is this real customer data?
Yes, anonymized. Every case comes from OpenTelemetry data that OllyGarden sampled from production systems. Every service, host, endpoint, and ID name is invented, and nothing identifies the source. Status codes, span structure, and ratios are kept as measured; where a timing is illustrative, the reveal says so.
What makes telemetry deceptive?
Two things. Sometimes the data itself says the wrong thing: errors logged at INFO or with no severity, timestamps at the Unix epoch or an hour off, traces missing their root, or services reporting under an SDK default name. Sometimes accurate data is easy to misread: a gRPC failure behind HTTP 200, a long-poll wait that looks like latency, or a retry loop that looks like an outage. Queries, alerts, and dashboards inherit both mistakes. What is telemetry quality? →
How does OllyGarden catch these problems?
OllyGarden Insights analyzes the telemetry you already send and flags quality problems per service, such as missing service names, single-span traces, and duplicate log records, with the fix for each. Rose reviews the instrumentation code that produces it. Explore OllyGarden Insights →