OpenMetrics — Missing # EOF Marker, Intentionally Invalid (prom)
A document that parses perfectly as Prometheus text and is invalid as OpenMetrics, because the mandatory # EOF terminator is missing. That marker is the format's only defence against a truncated response being accepted as complete — which is the exact failure this file reproduces.
# TYPE shop_orders counter
# HELP shop_orders Orders accepted since process start.
shop_orders_total{service="checkout-api"} 24518
# TYPE process_resident_memory_bytes gauge
process_resident_memory_bytes{service="checkout-api"} 418709504
Specifications
- Families
- 2
- Has Eof
- false
- Intentionally Invalid
- true
- Valid As Prometheus Text
- true
- Rule
- an OpenMetrics document must end with # EOF
Testing contract
Expected to fail- Scenario
- Parse the file once as OpenMetrics and once as Prometheus text exposition.
- Expected result
- The OpenMetrics parse fails on the missing # EOF while the Prometheus text parse succeeds with 2 families, proving the truncation is only detectable in the stricter dialect.
What is a .prom file?
A .prom file holds metrics in the Prometheus text exposition format, the same body a `/metrics` endpoint returns. Each metric family is introduced by `# HELP` and `# TYPE` comments and followed by one sample per line: a metric name, an optional brace-delimited label set, a value, and an optional millisecond timestamp. Counters, gauges, histograms (with `_bucket`, `_sum`, `_count` series and a `+Inf` bucket), and summaries with quantile labels all use this one grammar.
How to use this file
Use an example .prom file to test exposition-format parsers, scrapers, and the node_exporter textfile collector — checking label escaping, histogram bucket ordering and cumulative counts, and the handling of `NaN` and `+Inf` values.
How to use this file for testing
“OpenMetrics — Missing # EOF Marker, Intentionally Invalid (prom)” is a deterministic Novus Examples fixture for Observability, Schema validation, Error handling. Structured and plain-text telemetry with known timestamps, levels, request identifiers, and error states for testing log ingestion, correlation, dashboards, and alert pipelines.
Documented properties for this file: PROM · 238 bytes. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Telemetry fixtures use fixed trace IDs, span IDs, and timestamps so ingestion is reproducible run to run. Point your collector, parser, or query layer at the file and assert the documented span tree, metric families, or severity mix; service and host names are invented.
Related files
- promPrometheus Exposition — Broken Histograms, Intentionally Invalid (prom)Two histogram families that are syntactically fine and semantically wrong: one has non-monotonic buckets and no +Inf bucket, the other reports a _count larger than its +Inf bucket. Intentionally invalid, because histogram_quantile over either produces a confidently wrong number rather than an error.
- promPrometheus Exposition — Duplicate Series, Intentionally Invalid (prom)One label set exposed twice, a second pair that is only a duplicate once labels are sorted, and a repeated HELP line. Intentionally invalid: a scrape must fail rather than let last-write-wins decide which of two values for the same series survives.
- jsonOTLP Trace — All-Zero Trace and Span IDs, Intentionally Invalid (json)A trace whose trace ID and root span ID are all zeroes — the value an uninitialised context produces. Intentionally invalid: the specification defines all-zero IDs as invalid, so a conformant receiver must reject the spans instead of creating a permanent bucket that every broken service writes into.
- jsonOTLP Trace — Duplicate Span IDs, Intentionally Invalid (json)Two different spans share one span ID inside a single trace, which the specification forbids. Intentionally invalid: it is the fixture for the de-duplication path, where a naive store silently overwrites one span with the other and loses a subtree.
- jsonOTLP Trace — Negative and Zero Durations, Intentionally Invalid (json)One span ends 8.4 ms before it started and another has identical start and end timestamps. Intentionally invalid: negative durations poison latency aggregates — a single one can drag a p99 below zero — so this is the fixture for the validation that must sit in front of any duration metric.
- txtW3C traceparent — Valid and Invalid Header Cases (txt)A labelled set of traceparent header values: four that must parse — including a future version with extra fields, which parsers are required to accept — and eight that must be rejected, covering all-zero IDs, version ff, short and uppercase trace IDs, and missing or trailing fields.
Generated by generation/observability.py. Free for any use, no attribution required — license.