3.0

- Supported
- 5.2 (current)
- 5.0
- 4.0
- 3.0
- In development
- 5.4 (devel)
- Unsupported
- 4.4
- 4.2
- 3.4
- 3.2
- 2.4
- 2.2
- 2.0
- 1.8
- Others
- guidelines

manual:config:triggers:prediction

This shows you the differences between two versions of the page.

Both sides previous revision Previous revision Next revision | Previous revision | ||

manual:config:triggers:prediction [2015/09/28 11:54] martins-v explaining what is meant by 'tools' |
manual:config:triggers:prediction [2018/08/09 07:11] (current) martins-v autonumbering removal |
||
---|---|---|---|

Line 1: | Line 1: | ||

- | ==== 8 Forecasting functions ==== | + | ==== 8 Predictive trigger functions ==== |

=== Overview === | === Overview === | ||

- | Sometimes there are signs of the upcoming problem. These signs can be spotted so that actions may be taken in advance to prevent or at least minimize the impact of the problem. Zabbix has tools to predict the future behaviour of the monitored system based on historic data. These tools are realized as predictive trigger functions. | + | Sometimes there are signs of the upcoming problem. These signs can be spotted so that actions may be taken in advance to prevent or at least minimize the impact of the problem. |

- | === - Functions === | + | Zabbix has tools to predict the future behaviour of the monitored system based on historic data. These tools are realized through predictive trigger functions. |

- | Two things one needs to know is how to define a problem state and how much time is needed to take action. Then there are two ways to set up a trigger signalling about a potential unwanted situation. First: trigger must fire when system after "time to act" is expected to be in problem state. Second: trigger must fire when system is going to reach the problem state in less than "time to act". Corresponding trigger functions to use are **forecast** and **timeleft**. Note that underlying statistical analysis is basically identical for both functions. You may set up a trigger whichever way you prefer with similar results. | + | === Functions === |

- | === - Parameters === | + | Two things one needs to know is how to define a problem state and how much time is needed to take action. Then there are two ways to set up a trigger signalling about a potential unwanted situation. First: trigger must fire when the system after "time to act" is expected to be in problem state. Second: trigger must fire when the system is going to reach the problem state in less than "time to act". Corresponding trigger functions to use are **forecast** and **timeleft**. Note that underlying statistical analysis is basically identical for both functions. You may set up a trigger whichever way you prefer with similar results. |

+ | | ||

+ | === Parameters === | ||

Both functions use almost the same set of parameters. Use the list of [[manual/appendix/triggers/functions|supported functions]] for reference. | Both functions use almost the same set of parameters. Use the list of [[manual/appendix/triggers/functions|supported functions]] for reference. | ||

- | == - Time interval == | + | == Time interval == |

First of all you should specify the historic period Zabbix should analyse to come up with prediction. You do it in a familiar way by means of ''sec'' or ''#num'' parameter and optional ''time_shift'' like you do it with **avg**, **count**, **delta**, **max**, **min** and **sum** functions. | First of all you should specify the historic period Zabbix should analyse to come up with prediction. You do it in a familiar way by means of ''sec'' or ''#num'' parameter and optional ''time_shift'' like you do it with **avg**, **count**, **delta**, **max**, **min** and **sum** functions. | ||

- | == - Forecasting horizon == | + | == Forecasting horizon == |

(**forecast** only)\\ Parameter ''time'' specifies how far in the future Zabbix should extrapolate dependencies it finds in historic data. No matter if you use ''time_shift'' or not, ''time'' is always counted starting from the current moment. | (**forecast** only)\\ Parameter ''time'' specifies how far in the future Zabbix should extrapolate dependencies it finds in historic data. No matter if you use ''time_shift'' or not, ''time'' is always counted starting from the current moment. | ||

- | == - Threshold to reach == | + | == Threshold to reach == |

(**timeleft** only)\\ Parameter ''threshold'' specifies a value the analysed item has to reach, no difference if from above or from below. Once we have determined f(t) (see below) we should solve equation f(t) = ''threshold'' and return the root which is closer to now and to the right from now or 999999999999.9999 if there is no such root. | (**timeleft** only)\\ Parameter ''threshold'' specifies a value the analysed item has to reach, no difference if from above or from below. Once we have determined f(t) (see below) we should solve equation f(t) = ''threshold'' and return the root which is closer to now and to the right from now or 999999999999.9999 if there is no such root. | ||

- | == - Fit functions == | + | <note tip>When item values approach the threshold and then cross it, **timeleft** assumes that intersection is already in the past and therefore switches to the next intersection with ''threshold'' level, if any. Best practice should be to use predictions as a complement to ordinary problem diagnostics, not as a substitution.((For example, a simple trigger like <code>{host:item.timeleft(1h,,X)} < 1h</code> may go into problem state when the item value approaches X and then suddenly recover once value X is reached. If the problem is item value being below X use: <code>{host:item.last()} < X or {host:item.timeleft(1h,,X)} < 1h</code> If the problem is item value being above X use: <code>{host:item.last()} > X or {host:item.timeleft(1h,,X)} < 1h</code>))</note> |

+ | == Fit functions == | ||

Default ''fit'' is the //linear// function. But if your monitored system is more complicated you have more options to choose from. | Default ''fit'' is the //linear// function. But if your monitored system is more complicated you have more options to choose from. | ||

Line 31: | Line 34: | ||

^ ''fit'' ^ x = f(t) ^ | ^ ''fit'' ^ x = f(t) ^ | ||

|//linear// |x = a + b*t | | |//linear// |x = a + b*t | | ||

- | |//polynomialN//((Polynomial degree can be from 1 to 6, //polynomial1// is equivalent to //linear//. However, use higher degree polynomials with caution ([[https://en.wikipedia.org/wiki/Runge's_phenomenon|More info here]]). If the evaluation period contains less points than needed to determine polynomial coefficients, polynomial degree will be lowered (e.g //polynomial5// is requested, but there are only 4 points, therefore //polynomial3// will be fitted).)) |x = a<sub>0</sub> + a<sub>1</sub>*t + a<sub>2</sub>*t<sup>2</sup> + ... + a<sub>n</sub>*t<sup>n</sup> | | + | |//polynomialN//((Polynomial degree can be from 1 to 6, //polynomial1// is equivalent to //linear//. However, use higher degree polynomials [[https://en.wikipedia.org/wiki/Runge's_phenomenon|with caution]]. If the evaluation period contains less points than needed to determine polynomial coefficients, polynomial degree will be lowered (e.g //polynomial5// is requested, but there are only 4 points, therefore //polynomial3// will be fitted).)) |x = a<sub>0</sub> + a<sub>1</sub>*t + a<sub>2</sub>*t<sup>2</sup> + ... + a<sub>n</sub>*t<sup>n</sup> | |

|//exponential// |x = a*exp(b*t) | | |//exponential// |x = a*exp(b*t) | | ||

|//logarithmic// |x = a + b*log(t) | | |//logarithmic// |x = a + b*log(t) | | ||

|//power// |x = a*t<sup>b</sup> | | |//power// |x = a*t<sup>b</sup> | | ||

- | == - Modes == | + | == Modes == |

(**forecast** only)\\ Every time a trigger function is evaluated it gets data from the specified history period and fits a specified function to the data. So, if the data is slightly different the fitted function will be slightly different. If we simply calculate the value of the fitted function at a specified time in the future you will know nothing about how the analysed item is expected to behave between now and that moment in the future. For some ''fit'' options (like //polynomial//) a simple value from the future may be misleading. | (**forecast** only)\\ Every time a trigger function is evaluated it gets data from the specified history period and fits a specified function to the data. So, if the data is slightly different the fitted function will be slightly different. If we simply calculate the value of the fitted function at a specified time in the future you will know nothing about how the analysed item is expected to behave between now and that moment in the future. For some ''fit'' options (like //polynomial//) a simple value from the future may be misleading. | ||

Line 47: | Line 50: | ||

|//avg// |average of f(t) (now <nowiki><=</nowiki> t <nowiki><=</nowiki> now + ''time'') according to [[https://en.wikipedia.org/wiki/Mean_of_a_function|definition]] | | |//avg// |average of f(t) (now <nowiki><=</nowiki> t <nowiki><=</nowiki> now + ''time'') according to [[https://en.wikipedia.org/wiki/Mean_of_a_function|definition]] | | ||

- | === - Details === | + | === Details === |

To avoid calculations with huge numbers we consider the timestamp of the first value in specified period plus 1 ns as a new zero-time (current epoch time is of order 10<sup>9</sup>, epoch squared is 10<sup>18</sup>, double precision is about 10<sup>-16</sup>). 1 ns is added to provide all positive time values for //logarithmic// and //power// fits which involve calculating log(t). Time shift does not affect //linear//, //polynomial//, //exponential// (apart from easier and more precise calculations) but changes the shape of //logarithmic// and //power// functions. | To avoid calculations with huge numbers we consider the timestamp of the first value in specified period plus 1 ns as a new zero-time (current epoch time is of order 10<sup>9</sup>, epoch squared is 10<sup>18</sup>, double precision is about 10<sup>-16</sup>). 1 ns is added to provide all positive time values for //logarithmic// and //power// fits which involve calculating log(t). Time shift does not affect //linear//, //polynomial//, //exponential// (apart from easier and more precise calculations) but changes the shape of //logarithmic// and //power// functions. | ||

- | === - Potential errors === | + | === Potential errors === |

Functions return -1 in such situations: | Functions return -1 in such situations: | ||

Line 62: | Line 65: | ||

)). | )). | ||

- | Note: No warnings or errors are flagged if chosen fit poorly describes provided data or there is just too few data for accurate prediction. | + | <note tip>No warnings or errors are flagged if chosen fit poorly describes provided data or there is just too few data for accurate prediction.</note> |

+ | | ||

+ | === Examples and dealing with errors === | ||

+ | | ||

+ | To get a warning when you are about to run out of free disk space on your host you may use a trigger expression like this: | ||

+ | <code>{host:vfs.fs.size[/,free].timeleft(1h,,0)}<1h</code> | ||

+ | | ||

+ | However, error code -1 may come into play and put your trigger in a problem state. Generally it's good because you get a warning that your predictions don't work correctly and you should look at them more thoroughly to find out why. But sometimes it's bad because -1 can simply mean that there was no data about the host free disk space obtained in the last hour. If you are getting too many false positive alerts consider using more complicated trigger expression((But in this case -1 can cause your trigger to recover from the problem state. To be fully protected use: <code>{host:vfs.fs.size[/,free].timeleft(1h,,0)}<1h and ({TRIGGER.VALUE}=0 and {host:vfs.fs.size[/,free].timeleft(1h,,0)}<>-1 or {TRIGGER.VALUE}=1)</code>)): | ||

+ | <code>{host:vfs.fs.size[/,free].timeleft(1h,,0)}<1h and {host:vfs.fs.size[/,free].timeleft(1h,,0)}<>-1</code> | ||

+ | | ||

+ | Situation is a bit more difficult with **forecast**. First of all, -1 may or may not put the trigger in a problem state depending on whether you have expression like <code>{host:item.forecast(...)}<...</code> or like <code>{host:item.forecast(...)}>...</code> | ||

+ | | ||

+ | Furthermore, -1 may be a valid forecast if it's normal for the item value to be negative. But probability of this situation in the real world situation is negligible (see [[manual/config/triggers/expression|how]] operator **=** works). So add <code>... or {host:item.forecast(...)}=-1</code> or <code>... and {host:item.forecast(...)}<>-1</code> if you want or don't want to treat -1 as a problem respectively. | ||

=== See also === | === See also === | ||

- | - [[http://zabbix.org/mw/images/1/18/Prediction_docs.pdf|Forecasting trigger functions (pdf)]] on zabbix.org | + | - [[http://zabbix.org/mw/images/1/18/Prediction_docs.pdf|Predictive trigger functions (pdf)]] on zabbix.org |

© 2001-2020 by Zabbix SIA. All rights reserved.

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International