with nodes being removed in zabbix 2.4, this is unlikely to be looked into, sorry

As far as I know Zabbix 2.2 is LTS release.
2.4 should have to impact on this.

Probably ZBX-8092?

ZBX-8092 is similar, but my hosts are not disabled.
They have status "Monitored" and Hostname, Agent interface and JMX interface fields filled in the configuration.

This might be the same issue as ZBX-8092, because hosts from non-local nodes are not kept in configuration cache.

Zabbix frontend is showing data properly - it seems to be bug only in the zabbix server e-mail handling...

It also affects version 2.2.3

Will this be looked into? We just upgraded a complex distributed architecture with severals levels of hierarchy and we will stick with 2.2 for a while since 2.4 and 2.6 won't support multi-level DM.

Is there any info about this issue? I think mamy people are now stick to 2.2.X since next LTS release is far away...

After a update from 2.0.13 to 2.2.7 we seem to have the same issue with our node setup. Please have a look at it! Thanks!

Please also add this bug to the known issues section: https://www.zabbix.com/documentation/2.2/manual/installation/known_issues

We did some further debugging and here is an example from one of our alarms. Maybe this helps or anyone has an idea on this one.

 14937:20141127:112216.388 In substitute_simple_macros() data:'XXX : {HOST.HOST}: {TRIGGER.NAME}: {TRIGGER.STATUS} ({TRIGGER.SEVERITY}) = {ITEM.LASTVALUE}'
 14937:20141127:112216.388 In DBget_trigger_value()
 14937:20141127:112216.388 In get_N_itemid() expression:'{200200000007468}=0' N_functionid:1
 14937:20141127:112216.388 In get_N_functionid() expression:'{200200000007468}=0' N_functionid:1
 14937:20141127:112216.388 get_N_functionid() functionid:200200000007468
 14937:20141127:112216.388 End of get_N_functionid():SUCCEED
 14937:20141127:112216.388 End of get_N_itemid():FAIL
 14937:20141127:112216.388 End of DBget_trigger_value():FAIL
 14937:20141127:112216.388 cannot resolve macro '{HOST.HOST}'
 14937:20141127:112216.388 In substitute_simple_macros() data:'Puppet Agent not running'
 14937:20141127:112216.388 In DBitem_lastvalue()
 14937:20141127:112216.388 In get_N_itemid() expression:'{200200000007468}=0' N_functionid:1
 14937:20141127:112216.388 In get_N_functionid() expression:'{200200000007468}=0' N_functionid:1
 14937:20141127:112216.388 get_N_functionid() functionid:200200000007468
 14937:20141127:112216.388 End of get_N_functionid():SUCCEED
 14937:20141127:112216.388 End of get_N_itemid():FAIL
 14937:20141127:112216.388 End of DBitem_lastvalue():FAIL
 14937:20141127:112216.388 cannot resolve macro '{ITEM.LASTVALUE}'
 14937:20141127:112216.388 End substitute_simple_macros() data:'XXX: *UNKNOWN*: Puppet Agent not running: OK (Information) = *UNKNOWN*'

This seems to be caused by the configuration caching mechanism. We came up with the attached patch and it seems to solve the problem.

A bit of background: during the generation of the alarm messages, the "config" structure is used to look for the macros in DBget_trigger_value(). This structure is however only populated with information concerning the current node. That means: if the node is generating alarms for remote nodes, it can't find information about host/item in the "config" structure, leading to the observed symptoms.
The (admittedly dirty) patch attempts to fix this by filling the "config" structure with information about all nodes. After running the patched version of 2.2.7 in production for a few hours we still haven't run into any issues, but YMMV. Since I'm not familiar with the whole code, I can't be sure there aren't any side-effects we still haven't seen.

Thanks again for the good work Leo!

Guess I spoke too soon. Just updated the (still dirty) patch with a second try, but it seems the patch creates a new problem: the .nodata() trigger function started triggering on our patched server, even though data is coming in for the affected items.

Unfortunately, we're considering whether to completely abandon the DM setup and just use proxies (or even independent servers), so I'm not sure I'll be able to dedicate any more time trying to ferret out this side-effect.

note that upgrade to 2.4 will automatically convert child nodes into proxies (as dm is removed in 2.4)

Is the historical data from the child nodes still accessible after an upgrade?

such discussion is out of scope for this issue. any documentation related to the dm removal task should be handled in ZBXNEXT-1343

with nodes being removed since 2.4, this issue is unlikely to be looked in - closing