Metric anomaly detection
Evaluate departures from learned resource behavior with explicit baseline and missing-data states.
Anomaly rules compare recent measurements with a trained baseline for the selected resource and metric. They complement explicit thresholds rather than changing resource health definitions automatically.
Create a rule
Open Observe → Anomalies, select a metric and resource selector, and choose sensitivity and evaluation duration. The rule records metric unit, aggregation, training window, and minimum usable history.
A new resource or changed metric can remain Learning until the required history exists. Learning and missing data are not healthy or anomalous verdicts. The evaluation view identifies why a resource has not produced a verdict.
Baseline membership
Baselines follow stable resource IDs. A replacement guest does not inherit another guest's learned history merely because it reuses the same name or labels. A service-level aggregate can intentionally establish a baseline across a changing member set when configured for that purpose.
A new deployment, resize, or traffic change can alter normal behavior. Record those operations alongside anomaly history and review retraining rather than suppressing every new result indefinitely.
Sensitivity and notifications
Sensitivity changes how a departure is classified. Pending duration controls how long the rule must observe the departure before notifying. A change creates a rule revision and can reset its pending evaluation.
Routes use the same destination and ownership controls as alerts. Acknowledgement records response ownership; it does not teach the model that the measurement is normal. Maintenance suppression and baseline retraining are separate actions.
Missing observations
Collection gaps do not become zero-valued training points. A baseline can become stale when its source disappears or its retained history is insufficient. Use no-data alerts for that condition.
An anomaly event alone does not authorize resizing or terminating infrastructure. An autoscaling policy must explicitly select its accepted metric conditions and safety bounds.
Inspect metric sources and availability reports before using anomaly history as evidence of service downtime.