neoclassic2077

While using Prophet for purely "forecasting" setup might not guarantee consistent high-quality results out of the box, especially for noisy and complicated time series data, at VictoriaMetrics we found it practically useful for anomaly detection task:

In our vmanomaly product, Prophet is one of the go-to models for anomaly detection in metrics data and it usually requires little tuning to achieve considerable results. The main purpose for the use of Prophet or similar forecasting models is to reformulate the task of anomaly detection:

- given fitted model M, ground truth Y_i for particular data point X_i, we produce forecast Yhat_i and its uncertainty estimate [Yhat_lb, Yhat_ub] - if ground truth Y_i falls beyond the range of [Yhat_lb, Yhat_ub], we consider this point an anomaly - the further Y_i is from the range, the higher the anomaly score would be. In our particular implementation for easier alerting purposes, anomaly_score > 1 means "anomaly"

here's a small visual example: https://docs.victoriametrics.com/vmanomaly.html#examples

Not directly from machine learning perspective, rather touching stability of use in production setup. We at VictoriaMetrics allow Prophet to be one of the models to use for time series anomaly detection in vmanomaly product. When it comes to cloud environment, Prophet, which uses `cmdstanpy` under the hood, allows little to no control over the backend, thus, resulting in unexpected crashes for read-only filesystems like Red Hat OpenShift, after the backend attempts to create assets in /tmp directory during model fit stage, so such dependencies may limit usage of a product in real-world scenarios.