Edit in SignalFlow
Objective
Refactor the wizard-generated detector to:
- Separate threshold calculation from alert logic
- Compose multiple conditions in a single
detect()statement - Introduce a static operational guardrail
- Surface dynamic anomaly thresholds for reuse in alert messages
Edit in SignalFlow
From the detector action menu in the upper right hand corner (⋯), select Edit in SignalFlow
You should still be in the Detector UI for the detector you just saved, if not:
Navigate to:
Alerts & Detectors → Detectors
Locate your detector and open it, then Edit in SignalFlow.
Generated SignalFlow
Choose the SignalFlow tab and review the generated SignalFlow for the historical anomaly detector.
Notice on Format
Note that the format of against_periods.detector_mean_std function is on a single line. You an either add line returns after each parameter or copy and paste the same formatted SignalFlow below for readability.
Why We Are Refactoring
The wizard generated the detector using:
This helper function:
- Calculates historical baseline thresholds
- Applies fire and clear logic
- Applies orientation (
above/below) - Handles auto-resolve timing
- Publishes the detector in a single call
While convenient, this structure bundles threshold generation and alert behavior together.
To build multi-condition logic, we must separate threshold calculation from detection logic.
SignalFlow Detector Library
Explore the underlying helper functions and threshold stream implementations used in this lab.
Step 1 – Replace the Import
Remove:
Replace with:
streamsgenerates reusable threshold streams.conditionsenables logical composition indetect().
Step 2 – Rename the Signal Stream
Rename the signal from A to CPU for clarity.
Replace:
With:
Step 3 – Convert the Helper Call into Threshold Streams
The wizard-generated helper already contains the anomaly tuning we want to preserve:
window_to_compare='10m'space_between_windows='1d'num_windows=4fire_num_stddev=2.5clear_num_stddev=2discard_historical_outliers=True
We will keep these values.
Locate:
Replace only the function name with:
Update the stream argument:
Replace:
With:
Remove Helper-Only Alert Parameters
streams.mean_std_thresholds() generates threshold streams only.
It does not implement detector behaviors such as orientation or auto-resolve.
Remove:
Remove the Helper Publish
The helper call publishes a detector directly:
streams.mean_std_thresholds() does not publish a detector.
Remove .publish('XYZ_AdvancedDetector')
Step 4 – Add Multi-Condition Detect Logic
Now that threshold generation and alert logic are separated, you must explicitly define the detection criteria.
First, define the static guardrail as its own stream by appending:
This creates a constant threshold stream at 90%.
By defining it as a stream (instead of embedding threshold(90) directly inside detect()), it can be published, visualized, and referenced in alert messages.
Next, define the multi-condition detection logic:
This detect statement evaluates two independent conditions:
Historical baseline anomaly
CPU > fire_top
The 10-minute moving average exceeds the dynamically calculated anomaly threshold.Static operational guardrail with duration
when(CPU > static_threshold, lasting='15m')
CPU must remain above 90% for 15 consecutive minutes.
Both conditions must evaluate to true before the detector fires.
You now control exactly how anomaly behavior and operational thresholds interact. This introduces:
- Historical baseline anomaly:
CPU > fire_top - Static operational guardrail:
CPU > static_threshold - Sustained violation requirement: 15 minutes
- Explicit detector publication
Step 5 – Publish Threshold Streams for Preview and Messaging
To surface both thresholds for detector preview and alert messaging:
Result
You have transformed a wizard convenience helper into:
- Explicit threshold generation
- Composable multi-condition alert logic
- Static guardrail enforcement
- Sustained evaluation logic
- Reusable anomaly and static threshold streams
This structure provides greater precision, flexibility, and clarity in detector behavior.
Static Threshold in Alert Messages
Because the static guardrail is defined and published:
it is now available in the custom alert message as:
Any published stream in SignalFlow becomes accessible as inputs.<stream_name>.value in alert messaging.