This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Auto-adaptive baselining can be configured to trigger alert as per the automatic baselining and reference periods,...etc.
Static-threshold which is decided and provided by the app owner to receive alerts upon specific value violation to take an action.
Seasonal thresholds can be configured as well to pickup the violations which haven't been detected either through automatic baselining and static-based.
Common case for seasonal-baselining: marketing campaigns where excessive number of purchase, payment, delivery ... etc requests are processed and executed by specific services, so you can create a metric events and make as info if you need to be notified, or if you need to have an alert created keep the event type as "custom alert"
As a conclusion
You can create multiple metric events and choose where to receive alerts or not based on the actual use case.
You can create multiple metric events, but ensure there is no conflict in the configurations to receive the accurate alerts.
You can name the metric events if required ex: Exceeding processed requests during Black Friday.
If you have a request attribute configured for example to fetch purchased amounts or other parameter of interest > create multidimensional analysis view > create a metric for example if the total purchased amounts exceeds 1M so you will be notified during the seasonal baselining.
To create metric event: Manage > Settings > Anomaly Detection > Metric events, and simply configure it in meaningful way to be notified and take prober actions.
I recommend using the Davis Anomaly Detector in the new layout as it will not incur any limits etc on your allotment of metric events. Assuming your metric does not begin with ext:
maybe you can try partition in metric selector to apply static threshold and then use baseline, f.e. for cpu util >6% (i added default to fill the gaps with data):
