Service Level Objectives — Two SLOs in One Multi-Document YAML (yaml)
Two SLOs — availability and latency — in one multi-document YAML separated by ---, each defined as a ratio of good events to total over a rolling 28-day window. The latency SLO measures the le="1" bucket against the count, which is the correct way to do it from a histogram.
# Service level objectives in the OpenSLO shape. All targets are invented.
apiVersion: openslo/v1
kind: SLO
metadata:
name: checkout-availability
displayName: Checkout availability
labels:
service: checkout-api
team: shop
spec:
description: >-
Successful checkout requests as a fraction of all checkout requests,
measured at the load balancer over a rolling 28 day window.
service: checkout-api
indicator:
metadata:
name: checkout-success-ratio
spec:
ratioMetric:
counter: true
good:
metricSource:
type: Prometheus
spec:
query: sum(rate(http_requests_total{service="checkout-api",status!~"5.."}[5m]))
total:
metricSource:
type: Prometheus
spec:
query: sum(rate(http_requests_total{service="checkout-api"}[5m]))
timeWindow:
- duration: 28d
isRolling: true
budgetingMethod: Occurrences
objectives:
- displayName: 99.9% of checkout requests succeed
target: 0.999
---
apiVersion: openslo/v1
kind: SLO
metadata:
name: checkout-latency
labels:
service: checkout-api
team: shop
spec:
service: checkout-api
indicator:
metadata:
name: checkout-latency-ratioSpecifications
- Documents
- 2
- Slos
- 2
- Window Days
- 28
- Rolling Window
- true
- Budgeting Method
- Occurrences
- Availability Target
- 0.999
- Latency Target
- 0.99
- Has Document Separator
- true
Testing contract
Expected to pass- Scenario
- Load every document in the file and compute the error budget for each objective.
- Expected result
- Both documents load from the single file rather than only the first, and a 99.9% target over 28 days yields roughly 40 minutes of budget while the 99% latency target yields about 6.7 hours.
What is a .yaml file?
YAML (YAML Ain't Markup Language) is a human-readable data-serialization format using indentation, key-value pairs, and lists, and is a superset of JSON. It supports comments, anchors, and multiple documents per file, favoring readability for configuration. Its indentation sensitivity makes it error-prone to hand-edit.
How to use this file
Use an example YAML file to test config parsers, indentation and anchor handling, multi-document streams, and safe-loading to avoid arbitrary object construction.
How to use this file for testing
“Service Level Objectives — Two SLOs in One Multi-Document YAML (yaml)” is a deterministic Novus Examples fixture for Observability, Config parsing, Schema validation. 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: YAML · 1,880 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.
Code examples
import yaml # pip install pyyaml
with open("openslo-service-level-objectives.yaml") as f:
data = yaml.safe_load(f)
print(data)Related files
- txtB3 Propagation — Single and Multi-Header Forms (txt)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 must be rejected.
- txtW3C tracestate — List Members, Limits and Rejects (txt)tracestate header values covering vendor-prefixed keys, optional whitespace, the exact 32-member limit and a 33-member case that must lose its last member rather than its first — plus duplicate keys, uppercase keys, a bare key and an over-long key that must be rejected.
- yamlAlertmanager Config — Routing Tree, Inhibition and Mute Windows (yaml)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 matching critical, and a weekend mute window.
- confFluent Bit — Tail, Enrich and Forward Pipeline (conf)A Fluent Bit configuration in its INI-like section format: a tail input using the CRI multiline parser that reassembles the partial-line fixture, Kubernetes enrichment, a modify filter dropping two of the high-cardinality fields, and a throttle. Keys are space-aligned, not delimited.
- yamlOpenTelemetry Collector — Tail-Sampling Policies (yaml)Six tail-sampling policies including an inverted regex match that drops health checks and a composite policy with its own rate limit and ordered sub-policies. Policies are OR-ed and one match keeps the entire trace, which is the semantic most people get backwards.
- yamlOpenTelemetry Collector — Three-Signal Pipeline Configuration (yaml)A Collector configuration wiring traces, metrics and logs through separate pipelines, with named component instances, a filelog receiver that parses the CRI log fixture, OTTL statements performing the semantic-convention migration from the paired trace fixtures, and a redaction processor.
Generated by generation/observability.py. Free for any use, no attribution required — license.