Forecast graphs

The last field in the line Metric can already have a considerable influence on how meaningful the prediction will be. The default at this point is always the Maximum option, because in the context of capacity management, this option most frequently provides an indication of the very prediction — bottlenecks at peak loads. For example, if you used look only at average values for the CPU utilisation service, you might see that the average utilisation is still acceptable. However, in the foreseeable future, you would only notice in the monitoring that your CPU is constantly reaching its limits during peak loads when the actual situation arises.

With this option you can determine which period of the historical data is to be used as the basis for calculating the forecast. In general, it can be said that many data points are needed to enable a good fit. However, if you always want to take the measured values of the previous month as a basis, for example, you can do this by selecting the Last month option. This does not mean from the past 30 days, but rather from the previous calendar month.

Another reason to limit the period could be, for example, an upgrade of individual components on a server. The inclusion of data before this upgrade could possibly distort the prediction.

The forecast starts on the last day of the period selected under Consider history of. This is worth mentioning, because depending on the selection a prediction is also calculated for a period in which real measurement data has already been accumulated. Within this overlap, it is therefore already possible to see how close the prediction was to the actual values.

Furthermore, it only remains to say here that the further you try to look into the future, the more imprecise the prediction will naturally become. However, this banality is illustrated very well in the forecast graph by the ever-increasing orange shading.

When observing and analysing time ranges — in this case, the values recorded for your services — so-called structural breaks or changepoints play a very important role. To put it simply, these changepoints are those moments in the time ranges at which more or less large changes can be observed. During the analysis of the time frames Checkmk now identifies a whole series of these changepoints and uses them in order to reuse them in the forecast and thus make it more precise. How strongly Checkmk adjusts the curve of the forecast graph to these changepoints, can be determined via the five Trend flexibility options. If the adjustment is too strong — a so-called overfitting — the prediction function would too closely resemble a simple update (basically a copy) of the previous time series. An underfitting on the other hand, would make the prediction extremely inaccurate. Checkmk provides a standard value that is good for many situations and we can use this with Medium. Should your forecast graph be too inaccurate — underfitting — you would have to increase the flexibility of the trend curve by selecting High or Very High. In the opposite case — i.e. overfitting — you would still have the two options Low and None (linear), although we do not recommend using None (linear), because this is only available for the sake of completeness.

At this point you will need to determine how the forecast graph should handle recurring and seasonal demands on your infrastructure. Two time frames are automatically considered in the forecast graphs — weekly recurring requirements, such as for a five-day working week and weekends, and annual or seasonal requirements, such as those related to public holidays and staff holidays. Checkmk recognises this seasonality automatically, so all you have to do is select how you want it to be forecast.

The Additive option includes these changed requirements in the prediction only once. As the name suggests, the increased or decreased demand is simply added to the trend.

With the selection of Multiplicative, on the other hand, the future seasonal demand increases or decreases proportionally to the trend.

At this point you will need to determine the confidence level for your prediction. In simple terms, this is where you specify the probability with which the values to be expected should lie within the confidence interval resulting from this level. The aim of such a selection is, from the highest possible level, to always obtain an interval that is as narrow as possible. The more historical data that is available, the more successful the forecast graphs can be in achieving this. It is important that this selection does not influence the actual 'fit'. Only the area surrounding it (i.e. the visualisation of the interval) becomes correspondingly larger at higher levels.

In the forecast graph, on the left-hand side you see — separated by a vertical yellow line — the visualisation of a specified number of days of actually excellent data. You can specify how many days should be displayed here. This value has no effect on the calculation of the forecast itself, but only influences the display.

And the last option again only influences the display of the graph. If you check Model parameters, the previously selected parameters will be displayed below the finished graph. This makes it easier for the viewer to interpret the graph.

The error message Cannot create graph - Metric historical data has less than 2 days of valid values is largely self-explanatory. To be able to make meaningful predictions Checkmk needs more than 2 full days of historical measurement data. With fewer measurement points as a basis, a halfway serious fit is simply not possible.