[ZBXNEXT-3457] Support of user macros for event tags Created: 2016 Sep 26  Updated: 2017 May 30  Resolved: 2016 Dec 20

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Frontend (F), Server (S)
Affects Version/s: 3.2.0
Fix Version/s: 3.2.2, 3.4.0alpha1, 3.4 (plan)

Type: Change Request Priority: Major
Reporter: Alexander Vladishev Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: context, lld, macro, tags
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ZbxLib.py     HTML File log.html     File zbxnext_3457.robot    

 Description   

User and LLD macros shall be supported in the event tag name and value, as well as correlation tag (which is treated same as tag name).

Also restriction to use "/" in tags must be removed.



 Comments   
Comment by Vladislavs Sokurenko [ 2016 Sep 27 ]

Fixed server side in development branch:
svn://svn.zabbix.com/branches/dev/ZBXNEXT-3457

Comment by Vladislavs Sokurenko [ 2016 Sep 29 ]

(1) [A] Frontend changes need to be implemented:
Frontend does not accept {$PARTITION:“/”} for tag name where macro {$PARTITION:/} has value “root”, it shall detect that slash is in macro and allow.

sasha RESOLVED in r62993

oleg.egorov CLOSED

sasha WON'T FIX See (9)

Comment by Sandis Neilands (Inactive) [ 2016 Sep 30 ]

(2) [S] Consider this scenario which demonstrates poor usability.

Problem expression:

{dummy_host_0:dummy_item_0.regexp("[a-z]+ {$SERVICE_DOWN}",#1)}=1

Tag "reason" value:

{{ITEM.LASTVALUE}.regsub("[a-z]+ {$SERVICE_DOWN}",\2)}

Both expressions formatted for comparison:

{dummy_host_0:dummy_item_0.regexp("[a-z]+ {$SERVICE_DOWN}",#1)}=1
{{ITEM.LASTVALUE}         .regsub("[a-z]+ {$SERVICE_DOWN}",\2)}

Expected: both expressions work fine (since the regex is the same.
Actual: tag value expression fails and the tag has a value "UNKNOWN"

vso User macros are not supported in function macros.

sandis.neilands That is exactly the point. There are many arbitrary (surprising) limitation in the Zabbix macro language applications. Anyway you are right that this is out of scope for this feature. Created ZBXNEXT-3488 and CLOSED.

Comment by Erik De Neve [ 2016 Oct 04 ]

Will inventory macro's be supported too in event tags?

sandis.neilands Support of inventory macros is out-of-scope for this feature. Please consider creating a separate ZBXNEXT for that.

sandis.neilands Thanks erik! ZBXNEXT-3480

Comment by Sandis Neilands (Inactive) [ 2016 Oct 04 ]

(3) [S] Trigger prototype:

  • OK event closes: All problems if tag values match
  • Tag for matching: {#NAME}
    * Tag name: {#NAME}
  • Tag value: {#VALUE}

    Forward slash is discovered in both {#NAME} and {#VALUE}

    .

./zabbix_sender -z 192.168.3.252 -s dummy_host_0 -k dummy_lld_0 -o "{ \"data\": [ { \"{#NAME}\": \"/\", \"{#VALUE}\": \"/\" } ] }"
info from server: "processed: 1; failed: 0; total: 1; seconds spent: 0.015290"

Expected: trigger is not created from the prototype since tag names cannot begin with "/" (and thus events cannot be correlated by non-existent tags);

Actual: trigger is created from prototype, Tag for matching "/" but no tags added. Discovery rule has this error "Cannot create trigger tag: tag "/" contains '/' character.".

Related: ZBX-11314

vso RESOLVED in r63008

sasha WON'T FIX See (9)

Comment by Sandis Neilands (Inactive) [ 2016 Oct 05 ]

(4) [S] Trigger level correlation doesn't work when correlation tag name is a user macro since user macros are not resolved in "Tag for matching" field. My expectation was that "Tag for matching" supports everything that is supported in tag names.

This leads to especially poor usability if one is configuring a complex regex in the regsub() macro function for the tag name and wonders why it doesn't work.

See correlate_events_by_trigger_rules():

        if (0 == strcmp(tag->tag, event->trigger.correlation_tag))
                zbx_vector_str_append(&values, tag->value);

vso RESOLVED in r63022

sasha CLOSED

Comment by Vladislavs Sokurenko [ 2016 Oct 06 ]

(5) [D] Documentation shall explicitly say that forward slash is not allowed in tag name and tag value for matching.

sasha WON'T FIX See (9)

Comment by Vladislavs Sokurenko [ 2016 Oct 06 ]

(6) [A] Frontend Changes need to be implemented:
Expected:
Same rules must apply to Tag for Matching as for Tag name
Actual:
Tag name {$MACRO: /} is accepted but Tag for Matching is not.

sasha RESOLVED in r63105

sasha WON'T FIX See (9).

Comment by Alexander Vladishev [ 2016 Oct 11 ]

(7) [S] src/libs/zbxdbhigh/lld_trigger.c: validate_tag_name() function is incorrectly formatted

  1. SPACE instead of TAB used to separate data type and function name
  2. declaration of the variables is not properly aligned

sasha WON'T FIX See (9)

Comment by Alexander Vladishev [ 2016 Oct 11 ]

(8) [S] Possible to create invalid trigger tag. For example, when macros in trigger prototype's tag are resolved into "{h:k[/].f()}"

sasha WON'T FIX See (9)

Comment by Alexander Vladishev [ 2016 Oct 11 ]

(9) [A] [S] Was decided to remove restriction to use forward slash / in trigger tags

sasha RESOLVED in r63106.

sandis.neilands CLOSED for [S]. frontend-team should check [F].

gunarspujats CLOSED for [A]

Comment by Alexander Vladishev [ 2016 Oct 11 ]

(10) Validation for empty trigger tags is missing

sasha Moved to ZBX-11349

CLOSED

Comment by Sandis Neilands (Inactive) [ 2016 Oct 12 ]

(11) [A] Why does problem.get escapes forward-slashes in tags with a backslashes?

A typical use case could be a Unix path in the tag value.

Request

{  
   "jsonrpc":"2.0",
   "id":21,
   "auth":"a505a0152ee786414a518630850bc8b0",
   "method":"problem.get",
   "params":{  
      "output":"eventid",
      "selectTags":"extend",
      "hostids":[  
         "10335"
      ]
   }
}

Response

{  
   "jsonrpc":"2.0",
   "result":[  
      {  
         "eventid":"448",
         "tags":[  
            {  
               "tag":"\/",
               "value":"\/"
            }
         ]
      }
   ],
   "id":21
}

sandis.neilands WONTFIX. http://stackoverflow.com/a/9735430

asaveljevs See also ZBX-5116.

Comment by richlv [ 2016 Oct 12 ]

sandis.neilands, see ZBX-5116 on json escaping

Comment by Sandis Neilands (Inactive) [ 2016 Oct 13 ]

(12) [D] Spent some time figuring out why user macro context with LLD macro doesn't work (e.g. LLD macro was not expanded). Turns out our documentation had an error. LLD macro in user macro context must be always quoted.

https://www.zabbix.com/documentation/3.2/manual/discovery/low_level_discovery

It was:
{host:vfs.fs.size[{#FSNAME},pfree].last()}<{$LOW_SPACE_LIMIT:{#FSNAME}}

It should be (LLD macro must be quoted):
{host:vfs.fs.size[{#FSNAME},pfree].last()}<{$LOW_SPACE_LIMIT:"{#FSNAME}"}

Thanks martins-v for fixing that. wiper, what are your thoughts on stating this requirement explicitly in user macros page (https://www.zabbix.com/documentation/3.2/manual/config/macros/usermacros )?

wiper Havent we done it already ?

Macro context is quoted with " if the context contains a } character or starts with a " character. Quotes inside quoted macros must be escaped with the \ character. The \ character itself is not escaped, which means it's impossible to have a quoted macro ending with the \ character - the macro {$MACRO:"a:\b\c\"} is invalid.

sandis.neilands Arguments for stating this explicitly in user macros page:

  • LLD macros are expanded at different time than the resulting user macros so the paragraph you cited can be read as applying only to the user macro expansion time;
  • in no other place (correct me if I'm wrong here) we have to always put the LLD macro in quotes;
  • until today the only example regarding LLD macro as context in our documentation told otherwise.

martins-v Changed "Macro context is quoted" to "Macro context must be quoted". It probably resolves the issue.

sandis.neilands CLOSED.

Comment by Sandis Neilands (Inactive) [ 2016 Oct 14 ]

Code: OK.
Valgrind: OK.
TCs: OK (see attached).
Coverity: TBD when merged to trunk.
Documenatiation: TBD.

Comment by Sandis Neilands (Inactive) [ 2016 Oct 14 ]

(13) [D] This change must be documented.

martins-v Updated documentation:

sandis.neilands Thanks! CLOSED.

Comment by Gunars Pujats (Inactive) [ 2016 Oct 14 ]

(14) Translation string changes
Strings deleted:

  • unacceptable characters are used

sasha CLOSED

Comment by Vladislavs Sokurenko [ 2016 Oct 17 ]

Fixed in:

  • 3.2.2 r63162
  • 3.3.0 (trunk) r63161
Comment by Aleksandrs Saveljevs [ 2016 Oct 17 ]

Sub-issues still open: (12), (13), (16).

Comment by Gunars Pujats (Inactive) [ 2016 Nov 30 ]

(16) [D] API documentation updated:

sasha CLOSED

Generated at Fri Mar 29 14:58:00 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.