Practical Guide to Pyrra: The Kubernetes‑Native SLO Monitoring Tool

1. Positioning: Not Just a Rule Generator

Pyrra differs from Sloth in design philosophy: Sloth is a stateless CLI that generates YAML rules and stops, while Pyrra is a stateful long‑running service that defines SLOs via CRDs, continuously syncs rules with an Operator, and provides a Web UI and Grafana dashboards.

2. Architecture Overview

Pyrra consists of three components packaged in a single binary:

Backend / Operator : watches ServiceLevelObjective CRDs (or filesystem files) and creates PrometheusRule objects.

API : reads SLO objects from the backend and exposes data via HTTP.

UI : a React frontend embedded in the API that displays SLO list, error budget, RED metrics, etc.

Two deployment modes are supported: Kubernetes mode (API + Operator Deployments) and filesystem mode (API + reconciler processes).

3. Installation

Three typical installation methods:

Kubernetes with Helm (recommended) – add the Helm repo and install with custom Prometheus URLs.

Native YAML – apply CRDs and Pyrra manifests directly, optionally with the validating webhook.

Docker / filesystem – run the API and the filesystem reconciler containers, mounting SLO YAML files.

Enabling the validating webhook validates target , window , PromQL syntax, and SLI type at kubectl apply time.

4. CRD Specification

The ServiceLevelObjective CRD defines target (string), window, optional description, and an indicator object. Four mutually exclusive SLI types are supported: ratio – error / total, suitable for HTTP error rate, gRPC error rate, etc. latency – histogram bucket with success (must contain le) and total (ends with _count). latencyNative – native Prometheus histograms, only total and a latency threshold are required. bool_gauge – boolean gauge indicating a binary health condition.

The grouping field expands a single SLO definition into multiple independent SLOs (e.g., per route), which the UI lists and can filter.

5. Generated Rules

Pyrra creates recording rules such as http_requests:increase2w and burn‑rate rules for multiple windows (5 m, 15 m, 30 m, 1 h, …). Rule names use the original metric name as a prefix, making them intuitive compared with Sloth’s uniform prefix.

Four alert levels are generated automatically: Critical (fast burn), Warning (medium burn), Slow Burn, and Long Term, each with configurable severity. An additional “absent metric” alert fires when the underlying metric disappears.

6. Alert Configuration

Alert names default to ErrorBudgetBurn and severities to critical, warning, or none. Users can override names and severities in the alerting section, or disable specific alerts entirely.

Alertmanager routing can match on severity, slo, team, or service labels that propagate from pyrra.dev/ metadata.

7. Web UI

The UI shows an SLO list sorted by remaining error budget, searchable by name or label, with column toggles and color‑coded health status. The detail page displays the objective, current availability, error‑budget trend, RED metrics, and a multi‑burn‑rate table.

8. Grafana Integration

Two options are provided: enable --generic-rules to generate Grafana‑compatible dashboards automatically, or import the official dashboard JSON from the Pyrra GitHub repository. Key PromQL queries for remaining error budget, current availability, and real‑time burn rate are documented.

9. Advanced Features

Thanos / Mimir support with partial_response_strategy and tenant IDs.

Custom rule labels via ruleOutput for GitOps workflows.

Performance‑over‑accuracy mode that uses rate() instead of increase().

ConfigMap mode for clusters without a Prometheus Operator.

10. Pitfalls and Best Practices

Always quote the target value because the CRD expects a string.

For latency SLI, include the le label in the success metric.

Avoid high‑cardinality grouping labels (e.g., pod) to prevent rule explosion.

Ensure Prometheus Operator v0.40+ for proper PrometheusRule handling.

Increase Prometheus query timeout for large SLO sets.

Make sure bool_gauge queries return 0 or 1.

11. Pyrra vs Sloth Comparison

A side‑by‑side table (omitted here) highlights differences in positioning, deployment model, configuration format, supported SLI types, grouping, alert levels, missing‑metric alerts, UI, Grafana support, non‑K8s scenarios, OpenSLO support, plugin ecosystem, CI/CD integration, and maintainers.

12. Selection Guidance

Choose Pyrra when you run on Kubernetes, need a Web UI, want automatic grouping, require native latency SLI, and prefer an operational platform. Choose Sloth for non‑Kubernetes environments, simple rule generation, OpenSLO compatibility, or a CLI‑centric workflow. Both can coexist because they generate standard Prometheus rules.

13. Conclusion

Pyrra turns SLOs from static documentation into an observable, manageable practice. The platform provides rule generation, real‑time UI, multi‑level alerts, and Grafana dashboards, allowing teams to focus on reliability decisions rather than manual rule maintenance.