manual:config:triggers:prediction

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
manual:config:triggers:prediction [2018/09/04 08:10]
martins-v adjusting page numbers
manual:config:triggers:prediction [2021/01/27 19:24] (current)
Line 5: Line 5:
 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. ​ 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 through predictive trigger functions.+Zabbix has tools to predict the future ​behavior ​of the monitored system based on historic data. These tools are realized through predictive trigger functions.
  
 === - Functions === === - 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 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.+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 ​signaling ​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 === === - Parameters ===
Line 17: Line 17:
 == - 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 ​analyze ​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 ==
Line 25: Line 25:
 == - 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 analyzed ​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.
  
 <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>​ <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>​
Line 41: Line 41:
 == - 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 analyzed ​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.
  
 ^ ''​mode''​ ^ **forecast** result ^ ^ ''​mode''​ ^ **forecast** result ^
Line 79: Line 79:
 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. 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 === 
- 
-  - [[http://​zabbix.org/​mw/​images/​1/​18/​Prediction_docs.pdf|Predictive trigger functions (pdf)]] on zabbix.org