Observability pipelines are hard to test because the interesting data only appears in production. These fixtures reproduce it on disk. Traces ship as OTLP JSON and in the Jaeger and Zipkin shapes, with the same span tree across formats so a converter can be scored. Metrics come as Prometheus exposition text and OTLP metric documents covering counters, gauges, histograms, and exemplars. Logs arrive as structured JSON Lines and plain text with documented severity mixes, stack traces, multi-line records, and deliberately truncated tails. Dashboards, recording and alerting rules, collector configuration, and alert-webhook payloads complete the set. Timestamps, trace IDs, and span IDs are fixed, so two runs of your parser produce identical output.
Filter observability on Browse · 120 files · 5 subcategories
Results start with a representative from each related test family. Use a card’s variant menu or the filters below to reach a specific format, profile, or failure case; every sample retains its own detail page and download.
OTLP JSON traces, metrics, and logs, plus Jaeger and Zipkin trace shapes, Prometheus exposition text, structured JSON Lines logs, dashboards, recording/alerting rules, and alert-webhook payloads.
Yes. IDs, timestamps, and durations are fixed and recorded in each file's spec, so two runs of your parser or ingest pipeline produce identical output.
No, every service name, host, and user identifier is invented. These are synthetic fixtures shaped like production data, with no real infrastructure behind them.
Start with one example from each use-case group, then continue through its other test families. Choose a use case, search, or filter to find a specific profile; a card’s variant menu contains its related samples.
45 test families · 120 available files · Page 1 of 3
Alerts
Sixteen state transitions across four alerts, each moving inactive to pending to firing to resolved with the previous state recorded. The pending stage is where a for: duration is being served and no notification is sent
Logs
A .NET exception whose inner exception is introduced by the ---> marker and closed by End of inner exception stack trace, wrapped in pipe-delimited log lines. Error groupers that key on the outermost message alone merge
Metrics
The same 90 samples as the query_range response, exported one row per observation with both epoch and ISO 8601 timestamps. The long layout every dataframe library prefers, and half of a reshaping pair.
Profiles
An allocation profile in the same folded syntax as the CPU profiles, but weighted in bytes rather than samples. The format carries no unit, so a viewer that assumes samples renders 65 MB of allocation as 68 million sampl
Traces
B3 context propagation in both shapes (the compact single b3 header including the debug flag, a legacy 64-bit trace ID and the sampling-only form, plus the five X-B3-* multi-header fields) with two malformed values that
Alerts
An Alertmanager configuration with the routing behaviour that is hard to reason about without a fixture: a continue: true branch so a critical alert reaches two receivers, an inhibition rule suppressing warnings under a
Logs
The CRI log format Kubernetes nodes actually write: an RFC 3339 nanosecond timestamp, a stream name, and an F or P tag marking whether the line is full or a partial continuation. One long message is split across several
Metrics
A complete OpenMetrics document (the _total and _created series a counter really has, UNIT metadata, an info metric carrying build metadata and a stateset with exactly one active state) terminated by the mandatory # EOF.
Profiles
The .cpuprofile shape V8 emits: a node tree with call frames, a samples array of node IDs and a parallel timeDeltas array, plus the synthesized (idle), (program) and (garbage collector) nodes. Counting those synthetic fr
Traces
The checkout trace in the Jaeger query-API shape: a data array holding one trace, spans carrying microsecond startTime and duration, CHILD_OF references, typed tags and a per-service processes map. The same span tree as
Alerts
The JSON body Alertmanager POSTs to a webhook when an alert fires, including the detail that catches everyone: endsAt is Go's zero time rather than null or absent, so a receiver that parses it as a real timestamp records
Logs
Forty service-mesh proxy access records with the fields that make mesh debugging possible: response_flags distinguishing an upstream failure from an overflow, upstream_service_time against total duration, upstream host a
Metrics
An exponential histogram at scale 3 (eight buckets per power of two) with a negative offset, a zero bucket and its threshold. Bucket i covers (base^(offset+i), base^(offset+i+1)], and getting that indexing wrong silently
Profiles
The same workload after a change: JSON decoding costs four times as much and gains a new reflect frame, while cache lookups get cheaper. Paired with the baseline so a differential flamegraph can be scored against a known
Traces
A single-service trace 48 levels deep: a recursive GraphQL-style resolver where every span is the child of the one before it. A depth fixture for waterfall renderers, tree-layout code and any parser that recurses over pa
Alerts
One notification carrying twelve grouped alerts with truncatedAlerts set to 8, meaning twenty were firing. Receivers that count the alerts array report a smaller incident than actually exists: the field is there precisel
Logs
An OTLP logs export across two resources: five records spanning DEBUG to FATAL with both severityNumber and severityText, separate event and observed timestamps, trace and span correlation, and one record whose body is a
Metrics
Cumulative sums whose start timestamp stays fixed across exports, so every point is the running total since process start. Paired with a delta-temporality twin covering the same window, because converting between the two
The use-case group filter replaces the long list of category sections.
