Configuration

Predictive analytics is configured in three places: the Webserver’s settings (once), each monitor (one switch), and the prediction service (its environment).

Webserver settings

Settings > Webserver settings window > Predictive Analytics (administrators only). This tab has its own Save prediction settings button: the window’s main Save button does not include it.

The card at the top of the tab shows the four setup steps: the URL is set, the service answers, it accepts this Webserver’s signature, and it reads InfluxDB. Its colour gives the overall state (green: forecasts run; orange: a step to fix; red: unreachable), and the first failing step’s fix is written under it as Next step. Test connection checks the saved settings again and shows the service’s version, its number of models, its training queue and its latency. An edit not saved yet is flagged Unsaved changes next to Save prediction settings: save it before testing.

The Forecasts table lists every monitor with prediction enabled, one line per probe. Chips above it count the monitors forecasting, waiting for a model, in error, without recent checks, with an anomaly and with forecast alerts. Filter monitors narrows it, and it refreshes on its own while models wait for training. When a monitor raises no forecast alert, the reason is written under its forecast.

Monitor settings

In the monitor’s details, tab Prediction (URL, API, TCP, UDP, Ping, DNS, Database, System and WebSocket monitors):

The other settings apply once Enable is on: they are dimmed while it is off. Next to them, the Prediction status box shows, for each probe, the model, the latest forecast with its breach risk, and whether forecast alerts are sent, then a chart of the latest checks with the forecast, its 80 % and 95 % ranges, the thresholds and any anomaly, and how accurate the forecast has been on this monitor (see How it works). Administrators open the Predictive Analytics settings from it.

The predicted status is the risk of reaching the monitor’s own minor / major / critical thresholds (see Breach risk): a monitor without thresholds has no predicted status and no forecast alert. Changing a threshold or the prediction count retrains the monitor’s model, in seconds. Predictive alerts use its on status change notification channels.

Forecast alerts per monitor

The Forecast alerts setting of a monitor:

It covers forecast (breach risk) alerts only: anomaly alerts always follow the global settings, and a forecast alert is still only sent when the monitor’s breach risk is reliable. The change is picked up within 10 minutes (at once with Run predictions now). Turning a monitor’s forecast alerts off withdraws an open forecast alert; turning them on alerts on the current level once two consecutive forecasts confirm it. The Forecast alerts column of the Forecasts table shows the result for each monitor and probe, Default (on) or Default (off) for the current global settings.

Like the other prediction settings, it is part of the monitor’s CSV export, and an import restores it.

Monitors created by a Sentinel agent are configured on the agent.

Prediction service

The service is configured with environment variables, in a .env file next to api.exe, or with --env-file for the container.

Rotate the signing key

1. Rotate key in the Predictive Analytics tab. From now on, requests are signed with the new key.
2. The text box now holds both the new and the previous public key. Copy it to the service’s key file: the service accepts either key until you change the file again.
3. Test connection shows Connected again. Until step 2 is done, it reports that the service refuses this Webserver’s signature.

In a Webserver cluster the key is shared: rotate it once, from any node.

API

Webserver (ADMIN, on the API port, administrator token):

Prediction service (signed requests only, except /health):

Translations

• fr: Configuration