Server: RHEL 6.4 x86_64 with local mysql database

I second this. There were several situations, in which I also would have used "greater/less then or equal to".

Thanks.
tvtue

The lack of <= and >= is becoming more and more of an annoyance for me, so I've been looking at the source code to try determine what would be involved in fixing this.

Can I get some feedback from a developer? I'm willing to do the work, but I'll need some guidance.

It looks like src/libs/zbxserver/expression.c is where I need to start, specifically evaluate_simple().

It appears that there are at least a couple things that need to change:

1) The large "if" that uses strchr() to check for each of the single-character operators either needs to be reworked to use strstr() and advance the character pointer a variable number of characters (2 if the operator is <= or >=, 1 for all the other operators). Either that, or we need a new "if" before this one, that checks for <= and >=.

2) The switch statement needs to be converted to a sequence of if/else if statements that use strcmp to check for the appropriate operators.
In addition, there needs to be checks for <= and >= that just check cmp_double first and succeed if it does, and then check either < or >, as the existing tests do.

Am I on the right track? If I submit a patch, will you review and provide guidance for improvements?

Me and probably many others would appreciate to see a patch.
But don't expect any guidance or feedback from upstream development team - miracles happen though.

It is scheduled to be implemented in Zabbix 2.4, initial specification is available at https://www.zabbix.org/wiki/Docs/specs/ZBXNEXT-1782

(1) [I] Database patch does not remove extra spaces around operators

asaveljevs RESOLVED in r43962.

wiper CLOSED

ZBX-8014 is also going to be solved under this issue.

The C side implements a new algorithm for evaluating expressions. Performance is dependent on expression complexity, but on an expression like "-5+10*-6-700/(49*(1/(2+5)))=-165" the new algorithm is about 8-9 times faster.

what follows is purely personal opinion

i've been thinking about this for some time. my current conclusion is that it does not seem to provide any significant improvement.

the supposed benefit - making expressions easier to get into for new users - is a very short lived and imho does not trump the drawbacks.
it creates a problem for existing users, makes expressions longer and harder to read.

existing users, when upgrading, would have to adapt. many users have several zabbix installations/versions in parallel - transition period would be fairly confusing for them. people who have to support larger amount of zabbix users with different versions would have their life made harder - that would include those working on it in any capacity, but same goes for community self-help.

expressions being longer makes it harder to grasp what they do quickly. using words (even if short), as opposed to symbols, takes a bit longer to parse mentally - picking out symbols from a character stream is easier.

additionally, it seems to try to solve a problem that is not largely there - the only confusion seems to be usage of # as 'not' for new users - but besides being non-standard it does not cause any problems once they know about this use. once users examine the used operators, they are perfectly clear to them.

adding support for >= and <= without changing existing behaviour would bring much more benefit.

again, all of the above is just my opinion for the record, not meant to change the current direction.

(2) Please review my changes in r44722:44730

asaveljevs Looks very good, thank you. Improved a bit further in r44756. CLOSED.

(9) Implemented trigger expression convertion when importing in r45614 and 45634.

sasha CLOSED

(10) "Undefined index" in "Trigger expression condition" popup

Expression example:

{host:trap.str(abc)}>25w

Error messages:

Undefined index: str[>] [ in popup_trexpr.php:697]
Function "" cannot be used with selected item "host: trap"

jelisejev RESOLVED in r45714.

sasha CLOSED

(11) addToken() method shouldn't add empty 'data' array for simple tokens.

jelisejev I think it's more appropriate to return NULLs instead of not returning the "data" attribute at all. RESOLVED in r45715.

sasha CLOSED

(12) Unable to create database, problems while loading data.sql:

shell> cat schema.sql images.sql data.sql|mysql -uroot zbxnext1782

ERROR 1452 (23000) at line 2936: Cannot add or update a child row: a foreign key constraint fails
(`zbxnext1782`.`triggers`, CONSTRAINT `c_triggers_1` FOREIGN KEY (`templateid`) REFERENCES
`triggers` (`triggerid`) ON DELETE CASCADE)

sasha RESOLVED in r45739

alexei CLOSED

(13) [XML import] C24TriggerExpressionConverter doesn't work correctly.

I added some test cases.

sasha r45750 was successfully tested!

sasha CLOSED

(14) [F] GUI shouldn't support LLD filter expressions without spaces around logical operators

jelisejev RESLOVED in r45758

sasha Please review my changes in r45759.

jelisejev CLOSED.

Available in pre-2.3.0 (trunk) r45764.

(15) In some cases trigger expression parser may retun string with open parentheses. For example I have a trigger expression:

((({common1:eventlog[logtype].regexp(A)})<>0) or (({common1:eventlog[logtype].regexp(B)})<>0))

Parser returnes string:

( ( ( ((float) "0") ) <> ((float) "0") ) or ( ( ((float) "0") ) <> ((float) "0") ) (

Evaulation fails. See attached image.

jelisejev RESOLVED in svn://svn.zabbix.com/branches/dev/ZBXNEXT-1782.

kristsk CLOSED.

Fixed in 2.3.2 r47082.

CLOSED.

for the record, this resulted in a regression : trigger dependencies on triggers with old operators fail to import. ZBX-9346

we also forgot to update web monitoring docs - see ZBX-9412

changelog for this issue said "fixed... not working incorrectly" - reported as ZBX-10635