Migrate Health Rules to detectors

Learn how to migrate Splunk AppDynamics Health Rules to Splunk Observability Cloud detectors and review their translated logic.

Migrate supported Splunk AppDynamics Health Rules to Splunk Observability Cloud detectors. Open the migrated detector and review its SignalFlow program. Confirm that it selects the intended metric and scope, applies the correct aggregation and evaluation window, and triggers and clears alerts according to the source Health Rule. Correct any translated values or conditions that do not preserve the intended alerting behavior.

Generate representative traffic and use the detector preview to confirm when the detector triggers and clears. See Preview detector alerts.

Health Rules and detectors provide similar operational outcomes but use different application and metric models. Automated translation does not remove the need for rule-by-rule review.

Detectors created programmatically display their alert signal and conditions as a SignalFlow program instead of the standard Alert signal, Alert condition, and Alert settings tabs. See Edit detectors through the SignalFlow tab.

Prerequisites

Confirm that:

  • The Health Rule inventory identifies the rules in the migration wave.

  • Approve Business Transaction and service naming.

  • Activate required Monitoring MetricSets.

  • Make every referenced custom metric available in Splunk Observability Cloud.

  • Document source schedules, baselines, wait times, severities, actions, and recipients.

  • Make application and notification owners available to review the target behavior.

Run the migration

  1. Follow New Migration Job.

  2. Select the approved source and destination connections.

  3. Select the Health Rules tab and the applicable application.

  4. Select only the Health Rules approved for the migration wave.

  5. Review the migration summary and tag.

  6. Start the job.

  7. Review artifact-level results in the Migration Jobs Dashboard.

  8. Open every created detector in Splunk Observability Cloud.

Review the mapping

Splunk AppDynamics Target detector element

Health Rule

Detector

Violation

Alert

Affected entity

Metric and dimension filters

Metric expression

SignalFlow query or detector signal

Warning and critical thresholds

Alert rules with corresponding severities

Evaluation window

SignalFlow aggregation and duration

Policy and action

Notification recipients or integrations

Wait time after violation

No direct equivalent; define an approved target behavior

Review detector logic

For every detector:

  1. Verify the metric, unit, filters, and grouping dimensions.

  2. Verify static thresholds and duration conditions.

  3. Review how the source Health Rule combines its conditions. Map all conditions are met to AND logic and any condition is met to OR logic in the detector. Use parentheses to preserve nested condition groups. Preview the detector against representative telemetry to confirm that it triggers only under the intended combination of conditions.

    Example:

    An Splunk AppDynamics Health Rule contains:

    • Error rate exceeds 5%.

    • Average response time exceeds 2 seconds.

    • All conditions are met.

    Translate it as:

    Trigger when (error rate > 5%) AND (response time > 2 seconds).

    If the rule uses Any condition is met, translate it as:

    Trigger when (error rate > 5%) OR (response time > 2 seconds).

    Translate the warning and critical criteria separately. Although both criteria can use the same signals, preserve the threshold, AND or OR condition grouping, evaluation duration, clear condition, and severity defined for each criterion.

  4. Verify X-out-of-Y behavior, such as three violations in five minutes.

  5. Review baseline rules that require explicit mean, standard-deviation, percentage, or timeshift calculations.

  6. Verify warning and critical severity behavior.

  7. Verify clear and missing-data behavior.

  8. Review notification recipients, messages, runbook links, and deep links.

  9. Confirm that the detector does not page production unintentionally before validation.

See Create detectors to trigger alerts, Best practices for creating detectors, and Analyze incoming data using SignalFlow.

Review known differences

  • Splunk AppDynamics wait-time behavior does not have a direct equivalent.

  • Use a different target design for some source schedules.

  • When warning and critical conditions both hold, the target sends notifications for both severities. Use mutually exclusive conditions or approved downstream deduplication when required.

  • Baseline detectors require sufficient representative target history before calibration.

  • Custom metrics and dimensions must exist before the detector can evaluate correctly.

Record every manual change, accepted behavior difference, and required Phase 5 test.

Complete this task when every selected Health Rule has a detector, an approved alternative, or an assigned disposition, and every detector has a validation method and owner.