How to Use PrometheusRule Resources with Another Rule Engine
Sources and verification
- Source dates
- Oldest source check: 12 September 2026.
- Technical verification
- Separate technical verification has not been recorded.
Publication approval and technical verification are recorded separately. Automated link checks establish reachability, not accuracy. A checked example verifies only its stated test cases, not the whole article or your production setup.
In short
A PrometheusRule resource only becomes active when an authorized controller selects it and supplies its rules to an evaluator. For another engine, use a documented integration or an explicit conversion pipeline. Verify namespaces, labels, updates and deletion behavior, then inspect the rules actually loaded by the engine. API object existence does not prove that an alert is evaluating.
Key takeaways
- Trace a rule from Kubernetes resource through conversion to loaded evaluator state.
- Test deletion explicitly; some integrations retain converted objects by default.
- Keep one authoritative writer to prevent controllers from overwriting each other.
Find the missing handoff
When a rule resource exists but no alert evaluates, identify the controller expected to discover it. Check its watched namespaces, label selectors and permission to list or watch the resource. Then identify how the selected rule reaches the actual evaluator.
The Prometheus Operator API reference (opens in a new tab) documents rule-related resources and selectors. Those resources describe desired configuration; merely installing their definitions does not make every monitoring engine discover them.
Inspect controller events and logs using a read-only account first. A selector mismatch, denied API request and rejected expression are different failures and require different fixes.
Choose a supported bridge or a controlled conversion
Some operators include an integration for Prometheus resources. For example, VictoriaMetrics documents conversion (opens in a new tab) into corresponding operator objects. Verify the installed version and its configured behavior before relying on that integration.
A custom bridge needs a clear owner, source resource identity and reconciliation policy. Preserve the source namespace, name and version in its generated metadata so a responder can trace an active rule back to its origin. Reject unsupported fields visibly rather than silently dropping semantics.
If a repository generates rule files instead, define how resource changes enter that repository and how deployment status returns to the operator. A manual export with no update process creates a second copy that will drift.
Test create, update and delete independently
Use a test namespace and an unmistakable rule name. Start with a simple expression that produces a known result. Confirm all three stages: source resource, generated destination and loaded evaluator rule.
| Operation | Acceptance evidence |
|---|---|
| Create | Exactly one intended rule appears in the evaluator |
| Update expression | Loaded expression and observed result change |
| Update labels | Routing identity changes only as intended |
| Remove selector match | Documented removal or retention behavior occurs |
| Delete source | Destination follows the agreed lifecycle policy |
| Recreate source | No obsolete duplicate remains active |
Deletion deserves special attention. The VictoriaMetrics integration documentation states that converted objects are retained after source deletion by default, with configurable behavior. A test that checks only creation can therefore leave a supposedly retired rule running.
Establish one writer and a rollback
Decide whether the original resource, converted object or generated file is authoritative. Avoid letting two controllers continuously rewrite the same destination. Restrict direct edits if reconciliation would overwrite them, and show operators where a durable correction belongs.
Store the previous accepted configuration and define how to restore it. If conversion fails for one rule group, verify whether the evaluator retains its last good configuration or loses that group; do not assume the behavior is identical across engines.
Verify evaluation and notification separately
A successfully converted resource may still contain a query the destination cannot execute. Inspect evaluation errors and compare its value and labels with the source engine where available. Then trigger a controlled alert and recovery into a review receiver.
For recording rules, confirm the output reaches the configured write destination as described by the evaluator documentation (opens in a new tab). A loaded rule and a successful query do not prove persistence.
Keep the lifecycle test with the integration's deployment review. Repeat it after controller, CRD or engine upgrades, especially when selectors and conversion defaults change. This makes discovery behavior reviewable instead of a hidden assumption in the cluster.
Did this help?
Your answer helps us improve this guide. We save only the page and your choice for 30 days.
No name, email, or incident details are requested.
Sources
Vendor facts change. Each source below shows the date this page last checked it.
- Prometheus Operator API reference — Prometheus Operator. Checked 12 September 2026.
- Prometheus operator integration — VictoriaMetrics. Checked 12 September 2026.
- vmalert documentation — VictoriaMetrics. Checked 12 September 2026.
Related
One practical idea, occasionally
The On-Call Brief: short field notes, templates, and operational lessons.
Follow the field guide
Email subscriptions are not open yet. Read new guides in your feed reader — no email address needed.
Subscribe with RSS