Facing the same issue.

Same

+1

people, please, stop spamming issues with comments like these and see https://zabbix.org/wiki/Docs/bug_reporting_guidelines ...

Can someone with the right to do that please raise the priority?
I think this is an important feature for all those that excessively use prototype triggers.

I don't understand why we cannot create dependencies between prototype triggers.. I cannot use this feature at all without having this ability.

if I have three triggers related to free disk space over the same volume, 30%/20%/10% left, how am I supposed to make the dependency? Or do you expect that all of them should trigger? There's even an example in the wiki at http://www.zabbix.com/documentation/2.0/manual/discovery/low_level_discovery...

Discovery is incomplete without this feature.

This is a workaround to some of the dependency problems.

Same issue here

A temporary workaround I'm using is to define the upper limit in the trigger expression itself. For example, from the default Template OS Linux discovery trigger:

name: Free disk space is less than 20% on volume

,pfree].last(0)}<20 & {Template OS Linux:vfs.fs.size[

,pfree].last(0)}<20 | {Template OS Linux:vfs.fs.size[

,pfree].last(0)}>10

value < 20 and value >= 10:
{Template OS Linux:vfs.fs.size[

,pfree].last(0)}>10) | {Template OS Linux:vfs.fs.size[

,pfree].last(0)}=10)

slightly easier syntax for 20, 15, and 10% triggers for discovery prototypes to simulate dependencies:

(20%) {Template OS Linux:vfs.fs.size[

,pfree].last(0)}>14
(15%) {Template OS Linux:vfs.fs.size[

,pfree].last(0)}>9
(10%) {Template OS Linux:vfs.fs.size[

,pfree].last(0)}<10

same issue.

workaround commented from Bobby Metz and Christian Lahti
its cool and useful, but...

if value changes 15 to 14 then
mail notify action sends 2 mails
1. PROBLEM - disaster level trigger
2. OK - warning level trigger

it cause mistaken new trouble has occurred and it automatically recovered.

i hope strongly dependency controls...

I found kind of another workaround:

Just do it using the API:
{"auth":"foooo","params":

,"jsonrpc":"2.0","id":1,"method":"trigger.adddependencies"}

The triggerid is the id you got from the discovered trigger, if you fetch all trigger from the host you want.

BR
Tommy

Picture added: Discovered trigger set via API

Hi Tommy,
I tried to use your work around but I'm getting
{"jsonrpc":"2.0","error":

,"id":0}

(I took trigger ids from URL of triggerprototype edit pages and I use zabbix 2.2)

Do you have some idea?

Best regards, Olda

This is definitely not a trivial issue. Severity needs to be adjusted.

The workaround using multiple triggers not only generates notification spam, but can confuse dependent systems that read those messages when they come out of order. They see "bad, worse, ok!"

The workaround using the API is usable for people like me who have some experience with it. But it's pretty kludgy and has a high barrier to entry. That is, I don't think it's a good idea to require users to have API knowledge in order to use a feature. Custom automated processes, sure. But a built-in process should be fully fledged even through the GUI.

cuda, you must get trigger_id from host, not from triggerprototype to use this workaround.

But it's unuseable without scheduler that walk through all hosts and create necessary dependency.

It's very very important to only send one mail on higher trigger.
If you have 2 triggers for free disk space, one at >90% (and ends at <95%), the second at =>95%
When the second is true, the first send "OK", but it's not really ok.

Please, dependencies are a very good features, and prototypes should have this functionality.

That would spam my inbox with lot of e-mails.

I think that setting only one trigger with the highest value as possible is the best option. A value higher enough to avoid triggering and sending spam to your mail, and not so high so you can make an action before it is too late.

But it is still necessary to have dependencies working.

I've been waiting for this to be implemented since upgrading from 1.8 to 2.0. We are now on 2.2.2 and we still cannot take full advantage of prototype triggers due to this very basic feature missing. It is such a limitation.

I think it should've been implemented by now. I've refrained myself from implementing any of the workarounds suggested in the previous posts. It's just not the way this issue should be addressed.

Dependences are a basic feature for most of our clients. I hope it can be done in future versions.

This is the most voted-on feature request in the Zabbix bug tracker, but this issue has been open since 2012. Has any work been done since then? Is it very difficult to implement? Our setup is severely affected by this missing functionality, so a fix would be highly appreciated.

I'm join to the long list of zabbix users that want this feature, I think is very important!

+1

Low level discovery is what makes Zabbix so great compared to rivals. The failure to create dependencies on Trigger Prototypes means I am stuck with manually adding over 200+ dependancies.....

How can we help?

syndeysider, the "fast-lane" is probably sponsoring implementation or teaming up with other users to do so.

Hello everyone!

This feature development was added to Zabbix Development Services co-sponsoring list thanks to a company which is willing to contribute 10% of total development cost. To follow the progress or add your company as a co-sponsor, please visit Development Services page.

(1) improved processing of trigger prototypes in svn://svn.zabbix.com/branches/dev/ZBXNEXT-1229 r50051.

Performance Testing Results:

One discovery rule with 16 trigger prototypes, 1024 discovered entities. 16384 triggers were created.

Before changes:

After changes:

wiper CLOSED

Where's the "Like" button?

how about reinvent trigger itself, where we can define many expressions for different severities. for all things about "free spaces" metrics in only one trigger. You would add expression to trigger for different severities like we add interfaces to host.

how about thath? it will be great work-around for dependeces and great feature by itself.

for example,

trigger name: Low disk space {#SNMPVALUE} - {ITEM.LASTVALUE}
warning expression: {bla-bla}.vs_free_space.last() < 20
average expression: {bla-bla}.vs_free_space.last() < 10

after all this expressions applied, zabbix should choice only high triggered.

xocolate, I believe this might make things more complicated. See ZBXNEXT-637.
Personally, I'd rather like to see the trigger dependency functionality even more extended (e.g. to solve ZBXNEXT-46)

You are right! With ZBXNEXT-46 it will be more flexible

I commented on ZBXNEXT-46 as well. I don't think that "host triggers" really makes any sense. Any trigger, regardless of what you call it, can be the "host trigger" that determines the overall state of the host. All other triggers can then list the one you specify as a dependency, thus creating the same effect.

Take a router, for instance. A router can have 15 different interfaces. But if five of those interfaces go down, it doesn't mean the router is unavailable. It means there was a fiber cut or a single module in the router died or something.

However, if the management interface of the router goes away, it is reasonable to say that "the router is down". It may still be forwarding traffic, but at the very least, I no longer have any visibility into that router, so all of my monitoring is at risk.

So I would declare to myself that the trigger on the "simple check" Item on the management interface on the router is the "Host Trigger" for this router. All other triggers on this router would depend upon that trigger, without making any changes to Zabbix.

Since a LOT of those other triggers were created by prototypes, I DO still need to be able to list a trigger dependency in the prototype. However, I DON'T need an extra "host trigger" function to create the rest of the dependency structure. That just a trigger choice I need to make based on the needs of my system.

Allowing macros in the expression would solve the issue.
So this could be introduced into the Trigger prototypes

({TRIGGER.NSEVERITY}=5 & {Template OS AIX:vfs.fs.size[{#FSNAME},pfree].last(0)} = 0)
|
({TRIGGER.NSEVERITY}=4 & {Template OS AIX:vfs.fs.size[{#FSNAME},pfree].last(0)} < 2)
|
({TRIGGER.NSEVERITY}=3 & {Template OS AIX:vfs.fs.size[{#FSNAME},pfree].last(0)} < 5)
|
({TRIGGER.NSEVERITY}=2 & {Template OS AIX:vfs.fs.size[{#FSNAME},pfree].last(0)} < 10)

not sure severity macros/variables could help like that - trigger would only have one severity anyway...

I would think one would select "Not defined" as severity and the TRIGGER.NSEVERITY would set the actual severity depending on free space.

Perhaps this specific macro wouldn't help but being able to do something similar might be worth considering.

(2) added validation of discovered trigger dependencies.

RESOLVED in r51837,r51854

sasha CLOSED

(3) [S] trigger->dependants is uninitialized in function lld_triggers_validate()

==1520== Conditional jump or move depends on uninitialised value(s)
==1520==    at 0x457A1A: zbx_vector_ptr_destroy (vector.c:28)
==1520==    by 0x48B588: lld_trigger_free (lld_trigger.c:199)
==1520==    by 0x457E7A: zbx_vector_ptr_clear_ext (vector.c:28)
==1520==    by 0x48F0A8: lld_update_triggers (lld_trigger.c:1578)
==1520==    by 0x48501B: lld_process_discovery_rule (lld.c:560)
==1520==    by 0x482191: process_mass_data (proxy.c:2221)
==1520==    by 0x482C15: process_hist_data (proxy.c:2430)
==1520==    by 0x420DA2: process_trap (trapper.c:58)
==1520==    by 0x421895: trapper_thread (trapper.c:642)
==1520==    by 0x45A0F4: zbx_thread_start (threads.c:120)
==1520==    by 0x415152: MAIN_ZABBIX_ENTRY (server.c:864)
==1520==    by 0x458FAB: daemon_start (daemon.c:380)

wiper RESOLVED in r52233

sasha CLOSED

(4) [S] trigger dependency cache can be initialized incorrectly. Valid pointer to a "trigger_node" can be lost inside the loop

static void     lld_trigger_cache_add_trigger(...)
{
        ...
        trigger_node = lld_trigger_cache_append(cache, trigger->triggerid, trigger);

        for (i = 0; i < trigger->dependencies.values_num; i++)
        {
                ...
                if (NULL == trigger_ref->trigger && NULL == zbx_hashset_search(cache, trigger_ref))
                {
                       ...
                       trigger_node = lld_trigger_cache_append(cache, trigger_ref->triggerid, NULL);
                }
        }
}

sasha RESOLVED in r52239

wiper CLOSED

(5) [S] take a look at my changes in r52240, r52262 and r52270

wiper Thanks, CLOSED

On the server side the trigger dependency validation was successfully tested!

(6) New translation strings:

• Cannot create dependency on trigger prototype itself.
• Duplicate dependencies in trigger prototype "%1$s".
• Trigger prototype "%1$s" depends on trigger "%2$s", which does not exist.
• Trigger prototype cannot be dependent on a trigger that is inherited from it.

sasha RESOLVED

oleg.egorov CLOSED

(7) [F] Frontend initial implementation is ready for testing in r52298. Import/Export is not yet implemented, since it's waiting for ZBX-7654 to be finished.

sasha RESOLVED in r53647.

oleg.egorov CLOSED

(8) [F] Take a look at my changes in r52466. Changes in new trigger prototype views:

• removed useless hidden variable 'hostid' in trigger.prototype.edit and trigger.prototype.massupdate;
• removed useless URL parameters from form buttons;
• replaced 'noempty=0' with 'noempty=1' for trigger popup windows;
• removed useless URL parameter 'noempty=0' for trigger prototype popup windows;
• added error column for tree view in trigger prorotype form

iivs I checked r52551 as well. So far looks good. Thanks!
CLOSED.

(9) [F] frontends/php/include/forms.inc.php:1325

    $data['dependencies'] = API::Trigger()->get(array(
        'output' => array('triggerid', 'flags', 'description'),
        'selectHosts' => array('hostid', 'name'),
        'triggerids' => $data['dependencies'],
        'filter' => array(
            'flags' => array(ZBX_FLAG_DISCOVERY_NORMAL,ZBX_FLAG_DISCOVERY_PROTOTYPE, ZBX_FLAG_DISCOVERY_CREATED)
        ),
        'preservekeys' => true
    ));

frontends/php/include/forms.inc.php:1497

    $data['db_dependencies'] = API::Trigger()->get(array(
        'output' => array('triggerid', 'description', 'flags'),
        'selectHosts' => array('hostid', 'name'),
        'triggerids' => $data['dependencies'],
        'preservekeys' => true,
        'filter' => array(
            'flags' => array(ZBX_FLAG_DISCOVERY_NORMAL, ZBX_FLAG_DISCOVERY_PROTOTYPE, ZBX_FLAG_DISCOVERY_CREATED)
        )
    ));

frontends/php/trigger_prototypes.php:410

        $dependencyTriggers = API::Trigger()->get(array(
            'output' => array('triggerid', 'description', 'status', 'flags'),
            'selectHosts' => array('hostid', 'name'),
            'triggerids' => array_keys($depTriggerIds),
            'filter' => array(
                'flags' => array(ZBX_FLAG_DISCOVERY_NORMAL, ZBX_FLAG_DISCOVERY_PROTOTYPE)
            ),
            'preservekeys' => true
        ));

This API call must be split into two calls: API::Trigger()->get() and API::TriggerPrototype()->get().
This logic should not be executed with empty $data['dependencies'].

... and please review with this code. Seems we can remove this lines:

    foreach ($data['dependencies'] as &$dependency) {
        if (count($dependency['hosts']) > 1) {                          <--
            order_result($dependency['hosts'], 'name', ZBX_SORT_UP);
        }                                                               <--

        $dependency['hosts'] = array_values($dependency['hosts']);      <--
        $dependency['hostid'] = $dependency['hosts'][0]['hostid'];
    }

iivs Additionally I removed

$dependency['hostid'] = $dependency['hosts'][0]['hostid'];

as well, since we don't actually need a 'hostid' for edit form.
I aslo changed host name sorting the same way you did

$depTriggerDescription = CHtml::encode(implode(', ', zbx_objectValues($dependency['hosts'], 'name')).NAME_DELIMITER.$dependency['description']);

RESOLVED in r52731

sasha Thanks a lot! CLOSED

(10) [F] Take a look at my changes in r52668:52678.

iivs

• triggers.php: 173 and trigger_prototypes: 178
  the 'dependencies' in output is not a field. I removed it and re-orderd fields as they appear in database. Also sorted $triggers in same way, so it's easier to keep track of all fields.

• configuration.trigger.prototype.list: 122 the . should be on previous line and requires indentation. I fixed it.

• configuration.triggers.list: 124 and configuration.trigger.prototypes: 108
  NAME_DELIMITER should not be used as just a colon, so I changed it to simple :

Please, review r52713

sasha Thanks! I removed NAME_DELIMITER in triggers.inc.php and tr_status.php in r52831. Please take a look.

iivs Thanks!
CLOSED.

(11) [F] seems 'name' field in 'selectHosts' option is unused

frontends/php/trigger_prototypes.php:393

    $data['triggers'] = API::TriggerPrototype()->get(array(
        'output' => array('triggerid', 'expression', 'description', 'status', 'priority', 'templateid'),
        'selectHosts' => array('hostid', 'host', 'name'),
        'selectItems' => array('itemid', 'type', 'hostid', 'key_', 'status', 'flags'),

iivs RESOLVED in r52721

sasha CLOSED

(12) updated to latest from trunk with new design and resolved conflicts, please review r53571

wiper server side looks ok

sasha Looks good, but please take a look at my changes in r53642.

iivs Thanks,
CLOSED.

(13) Updated export changelog at Changes from 2.4 till 3.0

sasha RESOLVED

oleg.egorov CLOSED

(14) File: zbx_export_hosts (18).xml
Possible crash XML import with circular dependencies.

<trigger_prototype>
	<expression>{ZBXNEXT-1229:item.last()}=2</expression>
	<name>trigger2</name>
	<url/>
	<status>0</status>
	<priority>0</priority>
	<description/>
	<type>0</type>
	<dependencies>
		<dependency>
			<name>trigger2</name>
			<expression>{ZBXNEXT-1229:item.last()}=2</expression>
		</dependency>
	</dependencies>
</trigger_prototype>

This problem possible reproduce via trigger prototype mass update(replace trigger dependencies)

sasha also fixed "Undefined index" errors while creating or updating trigger prototype dependencies.

RESOLVED in r53747 and r53749.

iivs CLOSED.

Available in pre-2.5.0 r53781.

(15) Documentation

martins-v Updated so far:

• https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew300#defining_dependencies_between_trigger_prototypes
• https://www.zabbix.com/documentation/3.0/manual/config/triggers/dependencies#overview
• https://www.zabbix.com/documentation/3.0/manual/discovery/low_level_discovery#discovery_of_file_systems (with trigger prototype definition)

RESOLVED.

<richlv> let's advertise discovery performance improvements in what's new as well

martins-v Added as: https://www.zabbix.com/documentation/3.0/manual/introduction/whatsnew300#performance_improvements. Please review.

sasha Thanks a lot! CLOSED

(16) code (src/libs/zbxdbhigh/lld_trigger.c) uses word "dependant" - this seems to be used in context of a person only. we should probably use "dependent". to be verified by maartinjsh

martins-v "Dependent" is just American English for the same thing as "dependant" (usually meaning a person that depends on another like their parents). I don't think there's much benefit in changing.

sasha Will be fixed under ZBXNEXT-2683 (23). CLOSED

"Dependent" is an adjective that describes something that depends upon something else in the logical sense, like when one Trigger depends upon another trigger.

"Dependant" (with an "a") is ALWAYS a PERSON and is typically used in legal or tax contexts. "Dependant" is NEVER an adjective.

Subissue still open: 16