The request sounds a bit illogical.

If we compare with actions - there "IS NOT" used to compare a variable and its value, but not to estimate logical expression.

In lld discovery it's the same - "IS NOT" could be used in regexp (global one or directly in the rule filters) but not in logical expression.

Problem is that server (Posix ERE) doesn't support negation in regexp, that's why the only way to use global regexps with FALSE condition.
So it leads to ZBX-3924

I don't think this feature could be implemented as requested.

IMHO, custom expression support is incomplete without not keyword (AFAIR, in boolean algebra there is no way to express not with only and and or operators).

Yes, there is "not like" for received value in actions, but there is not "is not" in LLD filter (unlike global regexps, see screenshot). So, there is no way not filter out some bad values in LLD discovery (my real-life use-case).

Why do you relate this ticket to regexps handling? It is about custom logical expressions handling

Actually used global regexp it's possible to filter out bad values.
Issue description asks to do that without global regexps usage.

If could be possible to implement the feature by replacing "matches" word by a drop-down with options: 'matches, doesn't match':

But I'm not sure it's strongly required to do as it's possible to get the same results now using global regexps.

So you suggest to use global regexps to filter out bad values from every LLD discovery rule of every template? Sure, it is possible right now, but it is bad "solution". IMHO, all settings for LLD rule filter, related to template, must be attached on template itself, without global settings, otherwise template will not be self-contained (export template / import template in other installations will not work).

Sure, implementing logical not by replacing "matches" to "not matches" is one of options (but ZBX-3924 must be fixed first). Other option - implement logical not just like or and and in logical expression handler.

Agree with Iskra Zabbix.

Referencing global regular expressions for negated regex is not enough.

LLD discovery rules should either have a "NOT" logic added to current "AND & OR", or, alternatively, a "not matches" switch to complement the current "matches" implementation.

Iskra and Ilya are both correct, you really need a NOT operator for custom expressions (and/or "not matches'). Global regexps don't export with the template and require manual editing, so they're not a good substitute.

I second this. I find that I could regularly use a NOT operator in the discovery filters.

Though I would be fine with a drop down too.

I'd also like to have the NOT operator available. Sometimes you do not exactly know each possible value for a LLD macro but some to filter out. So there is no alternative to negate the match within the filters.

(5) [D] need to add 'not' option in Custom expression description
https://www.zabbix.com/documentation/4.0/manual/config/event_correlation/global
https://www.zabbix.com/documentation/4.0/manual/config/notifications/action/conditions

natalja.cernohajeva: RESOLVED

s.paskevics CLOSED

Implemented in pre-4.0.0alpha6 (trunk) in r80012

(6) [D] API documentation updated:

• https://www.zabbix.com/documentation/4.0/manual/api/reference/discoveryrule/object
• https://www.zabbix.com/documentation/4.0/manual/api/changes_3.4_-_4.0

sasha

added support for not operator in custom expression filter formula and value 9 in the filter condition operator.

Information about affected places should be mentioned (lld rule custom expression and conditions, action conditions custom expression, correlation rule conditions custom espression)

REOPENED

s.paskevics Do you mean about documentation manual or API call documentation?

iivs Corrected information in https://www.zabbix.com/documentation/4.0/manual/api/changes_3.4_-_4.0

RESOLVED

sasha Thanks! CLOSED

(7) The changelog entry says added support "NOT" keyword in custom expression fields - looks like "for" is missing there to make a sentence.

iivs Looks like you're right. Resolved in r82873 and
CLOSED