[ZBXNEXT-4724] Advanced preprocessing: validation and throttling rules, discarding values and setting errors Created: 2018 Sep 12  Updated: 2024 Apr 10  Resolved: 2019 Feb 15

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Proxy (P), Server (S)
Affects Version/s: None
Fix Version/s: 4.2.0alpha2, 4.2 (plan)

Type: Change Request Priority: Trivial
Reporter: Rostislav Palivoda Assignee: Andris Zeila
Resolution: Fixed Votes: 4
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: PNG File Selection_137.png    
Issue Links:
Causes
causes ZBX-15378 Unused parameter warning when compili... Closed
caused by ZBXNEXT-3544 retrieving item values upon events Open
caused by ZBXNEXT-1846 do not duplicate identical history va... Closed
caused by ZBXNEXT-3695 Allow Zabbix agent(active) to report ... Closed
Duplicate
is duplicated by ZBXNEXT-4016 Extend item preprocessing with subsam... Closed
Sub-task
part of ZBXNEXT-4894 Improve throttling by using md5 hash Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
ZBXNEXT-4742 Front-end changes for advanced prepro... Change Request (Sub-task) Closed Andrejs Griščenko  
Team: Team A
Sprint: Sprint 42, Sprint 43, Sprint 44, Sprint 45, Sprint 46, Nov 2018, Sprint 47, Dec 2018, Sprint 48, Jan 2019, Sprint 49 (Feb 2019)
Story Points: 5

 Description   

Zabbix Acceptance

Item preprocessing rules will be internally classified as:

  • transformation rules: transform input value into output value using function, fail if something goes wrong
  • validation rules: validate input value, fail if input value is not valid

New validation rules must be supported (menu → submenu) for items and item prototypes:

  • Validation → In range [min] [max]: check that numeric value is in range of 'min' to 'max' (inclusive), fail otherwise
    • min, max - optional numeric (can be negative) values, at least one must exist
  • Validation → Matches regular expression [regex]: check that value matches 'regex', fail otherwise
  • Validation → Does not match regular expression [regex]: check that value does not match 'regex', fail otherwise
  • Validation → Check for error in JSON [path]: extract and set error message by JSON path if exists and stop preprocessing; ignore this step otherwise
  • Validation → Check for error in XML [path]: extract and set error message by XML xpath if exists and stop preprocessing; ignore this step otherwise
  • Validation → Check for error using regular expression [pattern] [output]: extract and error message by regular expression and stop preprocessing; ignore this step otherwise
    • For all "Validation → Set error" rules: if an empty error message is returned then it will be replaced with "Returned empty error message" automatically
  • Throttling → Discard value if new value is the same as the last one
  • Throttling → Discard value if new value is the same as the last one and time difference is less than N seconds [N]

Zabbix user may specify optional "On fail" action for each rule, which will be executed if this rule fails:

  1. Discard value: preprocessing will stop immediately and Zabbix will ignore the value as it never existed
  2. Return value + "<value>": Zabbix will set result of preprocessing to <value> and preprocessing will stop
  3. Set error + "<error message>": preprocessing will fail and error message will be set to provided non empty "<error message>"
  4. If no action is specified then Set error is executed with internal error message set by Zabbix Server

The following preprocessing rules will never fail:

  • Trim, Left trim, Right trim
  • Validation → Check for error in JSON
  • Validation → Check for error in XML
  • Validation → Check for error using regular expression
  • Throttling → Discard value if new value is the same as the last one
  • Throttling → Discard value if new value is the same as the last one and time difference is less than N seconds

Other transformation and validation rules will fail if (depending on rule):

  • no match or failed for whatever reason, also:
    • Custom multiplier: not numeric, out of range
    • Simple change, Change per second: not numeric, out of range
    • Octal to decimal, Hexadecimal to decimal: not octal/hex, out of range
    • In range: not numeric

Design of the preprocessing configuration must not be too cluttered, it must be as simple as possible for those who will use this functionality.

When comparing values the new value must be casted to the type (unsigned int, float) of the last value stored in the database. Therefore, new string value "123.00' will be equal to the old numeric value of "123".

Use cases

  1. Skip erroneous (incorrect, noise) values. It may happen if a counter is not initialized yet (empty or 'N/A')
  2. Skip out of range values. For example, temperature sensor returns +999C if it is off, normal range is -100C up-to +100C
  3. Skip values that match some regular expression
  4. Set a human readable error message in case if a preprocessing rule fails
  5. Set a human readable message in case if a value is out of range or does not match some pattern. For example, I expect temperature in '[0-9]+C' format
  6. Process value only if it is changed
  7. Support of subsampling for dependant items. Master is updated every 10 seconds, a dependant item should be updated every minute
  8. Collect a value every 10 seconds. Unconditionally process it every 60 seconds (for nice graphs, for example) or if a new value differs from last one for real-time alerting
  9. Throttling together with   ZBXNEXT-4087 - Allow preprocessing of LLD rules OPEN  will allow to reduce rule delays without overloading server
  10. Extract error message provided in incoming data. For example, a JSON object may contain field "error". Therefore if the field exists then preprocessing must be able to extract its value and set it as an error message for the item
  11. Use a default value if input value does not match certain criteria

Open questions

  1. There is a new functionality to discard values in plan using preprocessing. But it doesn't address problem how to discard temporary errors that happened with items w/o preprocessing. So it will only solve part of such cases. see Preprocessing, throttling and ZBX_ERROR


 Comments   
Comment by Vitaly Zhuravlev [ 2018 Nov 26 ]

Dear users/watchers, we have a preprocessing function here 'Discard value' that will discard/drop identical values to keep history tables small. It would only store value if it is different. 

 

There will be another version of this function that will discard similar values but at some time save them, so users know that item is still being collected and alive.

In your opinion, which short name describes better what this preprocessing function does?

  • Discard value with heartbeat
  • Discard value within time period

Tell us what sounds better to you

Comment by Glebs Ivanovskis [ 2018 Nov 26 ]

I think the answer is in your question:

so users know that item is still being collected and alive

I would call it Deduplication with/without keep-alive. A bit difficult to translate, but I'm sure anyone even slightly related to IT will know what "keep-alive" usually means.

Comment by Vitaly Zhuravlev [ 2018 Nov 26 ]

The similar idea is behind 'with heathbeat'

Comment by Dimitri Bellini [ 2018 Dec 12 ]

Hi guys,
please also considering this kind of scenario (Dependant Item going on "unsupported state" on preprocessing step fail) https://support.zabbix.com/browse/VIT-2, I think it could be useful for some Log monitoring cases.
Thank you

Comment by Vitaly Zhuravlev [ 2018 Dec 12 ]

dimitri.bellini, I think this is included, see:

  1. Set error + "<error message>": preprocessing will fail and error message will be set to provided non empty "<error message>"
Comment by Dimitri Bellini [ 2018 Dec 12 ]

@Vitaly: Good, it's not easy to understand all of the Acceptance lines and understand the real scope

Comment by Andrejs Griščenko [ 2019 Jan 07 ]

Available in pre-4.2.0alpha2 r88082

Generated at Thu Apr 25 00:12:07 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.