Predictions

Predictions forecast a monitor’s future response time from its recent history and turn that forecast into a predicted status — so you can see a degradation coming before it breaches your thresholds.

Mugnsoft reads a monitor’s response-time history from InfluxDB, sends it to an external machine-learning service, and stores the forecast alongside the monitor. The forecast is compared against the monitor’s minor / major / critical thresholds to derive a predicted status (OK, MINOR, MAJOR, or CRITICAL).

Prerequisites

Predictions rely on two external pieces:

InfluxDB holding the monitor’s response-time history (v1, v2, or v3 are all supported). See Integration with InfluxDB.
The prediction engine — a Python service (train.py to build a per-monitor model, api.py to serve forecasts) that Mugnsoft calls over HTTP.

How it works

As monitors run, the Webserver queries InfluxDB for the last 30 days of the monitor’s responseTime for the given probe.
It sends that series to the prediction engine’s /predict endpoint, requesting a number of future points (the prediction count, default 5).
The engine returns the forecast values.
The Webserver takes the worst (highest) predicted value and compares it to the monitor’s thresholds to derive the predicted status.
The result is stored and shown against the monitor.

Predictions run asynchronously and never block monitor execution. Each monitor+probe has a cooldown, so a busy monitor is not re-forecast on every run.

A model must be trained first

The engine can only forecast a monitor it has a trained model for. If no model exists, the stored result carries a model not found error and a ready-to-run training command. Train the model once per monitor+probe (see Train a model), then predictions start succeeding.

Configure the prediction engine

Prediction settings are global and stored in the Webserver. Configure them from the Settings page (ADMIN only) or through the API.

Setting	Description	Default
Prediction API URL	Base URL of the Python prediction service	`http://localhost:5000`
Prediction API key	Optional API key sent to the prediction service	(empty)
InfluxDB URL	InfluxDB endpoint the engine reads history from	(required)
InfluxDB version	Query dialect: `v1`, `v2`, or `v3`	`v2`
InfluxDB org / token / bucket / database	Connection and auth for the selected InfluxDB version	(required)
Default prediction count	How many future points to forecast per monitor	`5`

Which InfluxDB fields apply

The version you pick decides which fields matter: v1 uses database, v2 uses org + bucket, v3 uses database + bucket. The token is used by v2 and v3. Mugnsoft builds the correct query dialect (Flux for v2, InfluxQL for v1, SQL for v3) automatically.

Update the settings via the API:


curl -X POST https://webserver:8050/updatePredictionSettings \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "predAPIURL": "http://predictor:5000",
    "predAPIKey": "",
    "predInfluxURL": "http://influxdb:8086",
    "predInfluxOrg": "mugnsoft",
    "predInfluxToken": "<influx-token>",
    "predInfluxBucket": "monitoring",
    "predInfluxVersion": "v2",
    "predDefaultCount": 5
  }'

Train a model

Each monitor+probe needs its own model before it can be forecast. The stored prediction result for an untrained monitor includes a pre-filled training command — copy it and run it on the host where the prediction engine lives. The command pulls a longer history (about 280 days) and trains for 100 epochs:


python train.py \
  --token "<influx-token>" \
  --bucket "monitoring" \
  --url "http://influxdb:8086" \
  --data_name "myservice_probe1" \
  --query "<pre-filled InfluxDB query>" \
  --epochs 100

The data_name is derived from the monitor and probe names (lowercased, with spaces, /, -, and . replaced by underscores), so each monitor+probe maps to a distinct model.

View and trigger predictions

Predictions surface against each monitor once a model exists and the engine has been reachable at least once.

Automatically — as monitors run, eligible ones are forecast in the background (subject to the per-monitor cooldown).
On demand — trigger a full recompute for every monitor:


curl -X POST https://webserver:8050/runPredictions \
  -H "Authorization: Bearer $TOKEN"

Read a single monitor’s latest forecast:


curl https://webserver:8050/prediction/myservice/probe1 \
  -H "Authorization: Bearer $TOKEN"

The response includes the predicted values, the derived predictedStatus, when it was lastUpdated, and — if the model is missing — the trainCmd to fix it.

Troubleshooting

Symptom	Cause	Fix
Result shows `model not found`	No trained model for this monitor+probe	Run the pre-filled training command
No predictions appear at all	InfluxDB URL not configured	Set the InfluxDB connection in prediction settings
Predicted status always `OK`	Monitor has no minor/major/critical thresholds set	Set alert thresholds on the monitor
Forecast looks wrong or empty	InfluxDB holds too little history, or the wrong version/dialect is selected	Confirm 30+ days of data exist and the InfluxDB version matches your deployment