Trigger expressions and calculated items support the same set of trigger functions, operators, (more or less) macros. However, there are very significant differences which both worsen user experience and make development harder.
|Frontend-side syntax validation||Yes||No|
|Configurable update interval||No||Yes|
|Can be referenced||No||Yes, by host:key in triggers, other calculated items and aggregated items|
|Can trigger Actions||Yes||No|
|Guaranteed reevaluation for every new value||Yes||No|
|Support for LLD macros in function parameters||No (
Under the hood triggers are preprocessed by frontend and stored in two separate DB tables, while calculated items are stored as single piece raw formula and server needs to do the same preprocessing as frontend before using trigger functions for calculated item evaluation.
This code separation between frontend and server and between triggers and calculated items hinders development of new features a lot. Most recent example are context based macros - added half a year ago, but still not fully supported (
ZBX-11206, ZBX-11207, ZBX-11211). Imagine, to add a new feature for both triggers and calculated items (macro functions, for example) we need to update code in 6 places:
- frontend trigger expression validation;
- (nonexistent so far) frontend calculated item formula validation;
- server-side trigger expression evaluation;
- server-side calculated item formula evaluation;
- server-side creation of LLD triggers out of trigger prototypes;
- server-side creation of LLD calculated items out of prototypes.
Let's put all eggs in one basket. It should not be that difficult to perform automatic upgrade of all calculated item formulas to trigger-like syntax. Server does it on-the-fly every time it polls calculated item.