Zabbix Documentation 4.2

2.23.04.04.2 (current)In development:4.4 (devel)Unsupported:1.82.02.43.23.4

User Tools

Site Tools


manual:config:triggers:expression

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:expression [2018/05/09 06:27]
SergejP [Operators]
manual:config:triggers:expression [2019/07/08 05:42] (current)
martins-v 'sum' is evaluated starting with the first received value
Line 7: Line 7:
 A simple useful expression might look like:  A simple useful expression might look like: 
   {<​server>:<​key>​.<​function>​(<​parameter>​)}<​operator><​constant>​   {<​server>:<​key>​.<​function>​(<​parameter>​)}<​operator><​constant>​
 +
 +While the syntax is exactly the same, from the functional point of view there are two types of trigger expressions:​
 +  * problem expression - defines the conditions of the problem
 +  * recovery expression (optional) - defines additional conditions of the problem resolution
 +
 +When defining a problem expression alone, this expression will be used both as the problem threshold and the problem recovery threshold. As soon as the problem expression evaluates to TRUE, there is a problem. As soon as the problem expression evaluates to FALSE, the problem is resolved.
 +
 +When defining both problem expression and the supplemental recovery expression, problem resolution becomes more complex: not only the problem expression has to be FALSE, but also the recovery expression has to be TRUE. This is useful to avoid trigger flapping in [[#​hysteresis|hysteresis]].
  
 === Functions === === Functions ===
Line 21: Line 29:
  
 ^FUNCTION CALL^MEANING^ ^FUNCTION CALL^MEANING^
-|**sum(600)** |Sum of all values ​within ​600 seconds| +|**sum(600)** |Sum of all values ​in no more than the latest ​600 seconds| 
-|**sum(#​5)** ​ |Sum of the last 5 values|+|**sum(#​5)** ​ |Sum of all values in no more than the last 5 values|
  
 The function **last** uses a different meaning for values when prefixed with the hash mark - it makes it choose the n-th previous value, so given the values 3, 7, 2, 6, 5 (from most recent to least recent), **last(#​2)** would return //7// and **last(#​5)** would return //5//. The function **last** uses a different meaning for values when prefixed with the hash mark - it makes it choose the n-th previous value, so given the values 3, 7, 2, 6, 5 (from most recent to least recent), **last(#​2)** would return //7// and **last(#​5)** would return //5//.
Line 30: Line 38:
 You can use the supported [[manual/​appendix/​suffixes|unit symbols]] in trigger expressions,​ for example '​5m'​ (minutes) instead of '​300'​ seconds or '​1d'​ (day) instead of '​86400'​ seconds. '​1K'​ will stand for '​1024'​ bytes. You can use the supported [[manual/​appendix/​suffixes|unit symbols]] in trigger expressions,​ for example '​5m'​ (minutes) instead of '​300'​ seconds or '​1d'​ (day) instead of '​86400'​ seconds. '​1K'​ will stand for '​1024'​ bytes.
  
 +Numbers with a '​+'​ sign are not supported.
 === Operators === === Operators ===
  
Line 137: Line 146:
 Use of function fuzzytime():​ Use of function fuzzytime():​
   {MySQL_DB:​system.localtime.fuzzytime(10)}=0   {MySQL_DB:​system.localtime.fuzzytime(10)}=0
-The trigger will change to the problem state in case when local time on server MySQL_DB and Zabbix server differs by more than 10 seconds. +The trigger will change to the problem state in case when local time on server MySQL_DB and Zabbix server differs by more than 10 seconds. ​Note that '​system.localtime'​ must be configured as a [[:​manual:​appendix:​items:​activepassive#​passive_checks|passive check]].
 == Example 11 == == Example 11 ==
  
Line 165: Line 173:
 === Hysteresis === === Hysteresis ===
  
-Sometimes ​we need an interval between ​an OK and Problem ​states, rather than a simple threshold. For example, we would like to define a trigger ​which becomes Problem ​when server room temperature goes above 20C and we want it to stay in that state until the temperature drops below 15C.+Sometimes an interval ​is needed ​between ​problem ​and recovery ​states, rather than a simple threshold. For example, ​if we want to define a trigger ​that reports a problem ​when server room temperature goes above 20°C and we want it to stay in the problem ​state until the temperature drops below 15°C, a simple trigger threshold at 20°C will not be enough. 
 + 
 +Instead, we need to define a trigger expression for the problem event first (temperature above 20°C). Then we need to define an additional recovery condition (temperature below 15°C). This is done by defining an additional //Recovery expression//​ parameter when [[:​manual/​config/​triggers/​trigger|defining]] a trigger. 
 + 
 +In this case, problem recovery will take place in two steps: 
 + 
 +  * First, the problem expression (temperature above 20°C) will have to evaluate to FALSE 
 +  * Second, the recovery expression (temperature below 15°C) will have to evaluate to TRUE
  
-In order to do this, we first define the trigger ​expression ​for the problem event. Then select '​Recovery expression'​ for //OK event generation//​ and enter a recovery expression for the OK event+The recovery ​expression ​will be evaluated only when the problem event is resolved first.
  
-Note that the recovery expression ​will be evaluated only when the problem event is resolved first. It is not possible to resolve a problem ​by recovery expression ​if the problem ​condition ​still persists.+<note warning>​The ​recovery expression ​being TRUE alone does not resolve a problem if the problem ​expression is still TRUE!</​note>​
  
 == Example 1 == == Example 1 ==