Review and enable migrated alerts
Goal: keep migrated alert rules safe. obs-migrate creates emitted Kibana rules disabled and tagged obs-migration; enabling them is a deliberate production decision after query, threshold, connector, and rollback review.
Inputs
Assume the user installed the package (obs-migrate on PATH); prefix .venv/bin/ only for a repo checkout.
| What you need |
File / command |
| Alert comparison payloads |
Grafana: <output-dir>/alerts/alert_comparison_results.json; Datadog: <output-dir>/alerts/monitor_comparison_results.json |
| Rule creation results |
Grafana: <output-dir>/alerts/alert_rule_upload_results.json; Datadog: <output-dir>/alerts/monitor_rule_upload_results.json |
| Which assets ran |
<output-dir>/run_summary.json (ran.alerts) |
| Self-cleaning write proof |
obs-migrate verify-alert-rules --comparison <...> |
| Read-only rule audit |
obs-migrate audit-rules --kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY" |
| Disable migrated rules if needed |
obs-migrate audit-rules ... --disable-enabled |
| Delete migrated rules if backing out |
obs-migrate delete-rules dry run, then --confirm after user approval |
Review sequence
Confirm alerts were in scope — read run_summary.json. If ran.alerts: false, stop; there are no migrated alert rules to enable from this run.
Read comparison results first — open alert_comparison_results.json or monitor_comparison_results.json. Identify rules with semantic losses, unsupported constructs, missing queries, or manual notes.
Read upload results — open alert_rule_upload_results.json or monitor_rule_upload_results.json. Separate created, failed, and skipped rules. Do not enable a rule that failed or was skipped.
Run a self-cleaning verification when possible:
obs-migrate verify-alert-rules \
--comparison <output-dir>/alerts/alert_comparison_results.json \
--kibana-url "$KIBANA_ENDPOINT" \
--kibana-api-key "$KEY"
Use the Datadog monitor_comparison_results.json path for Datadog. This creates rules disabled, checks they did not come back enabled, then deletes them unless --keep-rules.
Audit persisted migrated rules:
obs-migrate audit-rules \
--kibana-url "$KIBANA_ENDPOINT" \
--kibana-api-key "$KEY"
audit-rules is read-only unless --disable-enabled is passed. It lists rules tagged obs-migration or named [migrated] ... and reports enabled state.
Review connectors/actions manually — confirm each rule's connector exists, credentials work, destination is production-correct, escalation policy is accepted, and message templates still make sense in Kibana. The migration can create rule shells; connector/action parity is not automatically proven unless the artifacts and Kibana review show it.
Canary before bulk enablement — enable one low-risk rule first, watch execution history for several cycles, then enable by tier/owner. Keep source alerts running during overlap.
Enablement decision
- READY TO ENABLE — comparison clean enough for owner, upload succeeded,
verify-alert-rules passed or existing rules audit clean, connectors/actions reviewed, rollback path known.
- ENABLE WITH CONDITIONS — owner accepts semantic losses or muted/no-action canary period.
- DO NOT ENABLE — rule failed/skipped creation, comparison has unresolved semantic gaps, connector routing unknown, target data/field mapping is unresolved, or rollback owner is missing.
Rollback / safety
If migrated rules are unexpectedly enabled, disable them with:
obs-migrate audit-rules \
--kibana-url "$KIBANA_ENDPOINT" \
--kibana-api-key "$KEY" \
--disable-enabled
To remove migrated rules, dry-run first:
obs-migrate delete-rules --kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY"
obs-migrate delete-rules --kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY" --confirm
Honest limits / Do NOT enable
- Do NOT enable migrated alert rules solely because they were created. Creation proves the payload was accepted, not that production notifications are safe.
- Do NOT claim connectors/actions are migrated perfectly without inspecting the rule and destination. Notification semantics may need manual review.
- Do NOT treat
verify-alert-rules as a persistent enablement step. It is self-cleaning unless --keep-rules; it proves create/disabled/cleanup behavior.
- Do NOT run
delete-rules --confirm without explicit user approval. Dry run first.
- Do NOT disable rules with
audit-rules --disable-enabled unless the user wants a mutating safety action.
See also
evaluate-o11y-permissions — prove the Kibana key can read/create alert rules.
migrate-all-supported-assets / migrate-selected-assets — create rules disabled with --create-alert-rules.
prepare-production-cutover — include alert-rule readiness in the final go/no-go.
revert-migration — target-side rollback for migrated rules.
obs-migrate verify-alert-rules --help, obs-migrate audit-rules --help, obs-migrate delete-rules --help — authoritative installed-package flags.
1---2name: review-and-enable-migrated-alerts3description: Use when obs-migrate created Kibana alerting rules and the user asks whether they can enable them, verify them, review connectors/actions, audit migrated rules, or safely roll alert rules into production.4---56# Review and enable migrated alerts78Goal: keep migrated alert rules safe. `obs-migrate` creates emitted Kibana rules **disabled** and tagged `obs-migration`; enabling them is a deliberate production decision after query, threshold, connector, and rollback review.910## Inputs1112Assume the user **installed the package** (`obs-migrate` on `PATH`); prefix `.venv/bin/` only for a repo checkout.1314| What you need | File / command |15|---|---|16| Alert comparison payloads | Grafana: `<output-dir>/alerts/alert_comparison_results.json`; Datadog: `<output-dir>/alerts/monitor_comparison_results.json` |17| Rule creation results | Grafana: `<output-dir>/alerts/alert_rule_upload_results.json`; Datadog: `<output-dir>/alerts/monitor_rule_upload_results.json` |18| Which assets ran | `<output-dir>/run_summary.json` (`ran.alerts`) |19| Self-cleaning write proof | `obs-migrate verify-alert-rules --comparison <...>` |20| Read-only rule audit | `obs-migrate audit-rules --kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY"` |21| Disable migrated rules if needed | `obs-migrate audit-rules ... --disable-enabled` |22| Delete migrated rules if backing out | `obs-migrate delete-rules` dry run, then `--confirm` after user approval |2324## Review sequence25261. **Confirm alerts were in scope** — read `run_summary.json`. If `ran.alerts: false`, stop; there are no migrated alert rules to enable from this run.272. **Read comparison results first** — open `alert_comparison_results.json` or `monitor_comparison_results.json`. Identify rules with semantic losses, unsupported constructs, missing queries, or manual notes.283. **Read upload results** — open `alert_rule_upload_results.json` or `monitor_rule_upload_results.json`. Separate created, failed, and skipped rules. Do not enable a rule that failed or was skipped.294. **Run a self-cleaning verification when possible**:3031 ```bash32 obs-migrate verify-alert-rules \33 --comparison <output-dir>/alerts/alert_comparison_results.json \34 --kibana-url "$KIBANA_ENDPOINT" \35 --kibana-api-key "$KEY"36 ```3738 Use the Datadog `monitor_comparison_results.json` path for Datadog. This creates rules disabled, checks they did not come back enabled, then deletes them unless `--keep-rules`.395. **Audit persisted migrated rules**:4041 ```bash42 obs-migrate audit-rules \43 --kibana-url "$KIBANA_ENDPOINT" \44 --kibana-api-key "$KEY"45 ```4647 `audit-rules` is read-only unless `--disable-enabled` is passed. It lists rules tagged `obs-migration` or named `[migrated] ...` and reports enabled state.486. **Review connectors/actions manually** — confirm each rule's connector exists, credentials work, destination is production-correct, escalation policy is accepted, and message templates still make sense in Kibana. The migration can create rule shells; connector/action parity is not automatically proven unless the artifacts and Kibana review show it.497. **Canary before bulk enablement** — enable one low-risk rule first, watch execution history for several cycles, then enable by tier/owner. Keep source alerts running during overlap.5051## Enablement decision5253- **READY TO ENABLE** — comparison clean enough for owner, upload succeeded, `verify-alert-rules` passed or existing rules audit clean, connectors/actions reviewed, rollback path known.54- **ENABLE WITH CONDITIONS** — owner accepts semantic losses or muted/no-action canary period.55- **DO NOT ENABLE** — rule failed/skipped creation, comparison has unresolved semantic gaps, connector routing unknown, target data/field mapping is unresolved, or rollback owner is missing.5657## Rollback / safety5859- If migrated rules are unexpectedly enabled, disable them with:6061 ```bash62 obs-migrate audit-rules \63 --kibana-url "$KIBANA_ENDPOINT" \64 --kibana-api-key "$KEY" \65 --disable-enabled66 ```6768- To remove migrated rules, dry-run first:6970 ```bash71 obs-migrate delete-rules --kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY"72 obs-migrate delete-rules --kibana-url "$KIBANA_ENDPOINT" --kibana-api-key "$KEY" --confirm73 ```7475## Honest limits / Do NOT enable7677- **Do NOT enable migrated alert rules solely because they were created.** Creation proves the payload was accepted, not that production notifications are safe.78- **Do NOT claim connectors/actions are migrated perfectly without inspecting the rule and destination.** Notification semantics may need manual review.79- **Do NOT treat `verify-alert-rules` as a persistent enablement step.** It is self-cleaning unless `--keep-rules`; it proves create/disabled/cleanup behavior.80- **Do NOT run `delete-rules --confirm` without explicit user approval.** Dry run first.81- **Do NOT disable rules with `audit-rules --disable-enabled` unless the user wants a mutating safety action.**8283## See also8485- `evaluate-o11y-permissions` — prove the Kibana key can read/create alert rules.86- `migrate-all-supported-assets` / `migrate-selected-assets` — create rules disabled with `--create-alert-rules`.87- `prepare-production-cutover` — include alert-rule readiness in the final go/no-go.88- `revert-migration` — target-side rollback for migrated rules.89- `obs-migrate verify-alert-rules --help`, `obs-migrate audit-rules --help`, `obs-migrate delete-rules --help` — authoritative installed-package flags.