the answer by asaveljevs is good. some notes on potential issues.
proxy will be detected as missing, and dependencies will work as expected. but let's assume a proxy is unreachable for an extended period of time - 30 minutes or more. let's assume that it keeps on collecting data. once the connection is restored, it sends the values in.
at this point, server sees that proxy is available (the internal lastaccess item is updated), but a proxy always sends data sequentially (older values first). if the proxy had a large amount of values collected, it will take some time to send in the recent values. for the hosts behind the proxies you would have nodata() triggers on their availability, and these triggers would see that data is missing - and they would fire.
starting with zabbix 2.2, there is a new internal item - zabbix[proxy_history] . theoretically, it could be used to monitor how many unsent values zabbix proxy has and have a trigger (t) if that number is high. then one would have a dependency on that trigger (t) from all the host availability triggers, and trigger (t) in turn would depend on lastaccess trigger. that way if the proxy suddenly disappears, we still have a dep on lastaccess. if it comes back, we would notice the large history backlog and still not alert on anything... except that internal items are subject to the same proxy queue/older first rules. until we got the values about large proxy buffer/history, we would already fire the triggers about hosts behind the proxy.
so is there a solution ? maybe.
the information about proxy buffer can be extracted from the proxy database. our task is to get it to the server as soon as possible once connection is restored. we have two options :
- use an agent that talks directly to the server
zabbix agent would collect the buffer/history size and push that directly to the server without going through the proxy cache/buffer. if this would be a passive agent, we would completely lose buffer values during the downtime and then we would depend on the item interval to get the first value in after connection is back.
if this would be an active agent, we would be able to keep some amount of data (100 or 50 by default) during the downtime. it would probably introduce a tiny, tiny delay to send these values, though. by default agent would try to send these values every 5 seconds or more often.
- use zabbix_sender directly to the server
in this case we would be able to decide whether we care about values during the downtime. if we don't it's simple - collect the values and just push them to the server, ignoring the failures. if we would like to get the value i as soon as possible, we would probably introduce some logic to send the value every 60 seconds, but if that fails, every 5 seconds or so.
if we care about values during downtime, we would have to implement logic to store these values every interval seconds. if sending fails, always retry with older values first, but keep on collecting values (older values must be sent first so that events from the trigger against this item are not all messed up).
compared to discarding values, this might introduce a tiny, tiny delay to get the latest value to the server.
in all these cases there is probably a very small window for race condition which could be potentially eliminated with some clever tricks around triggers (maybe by requiring lastaccess to be recent and making sure that last 3 values of it are all different or something in that direction).
oh, and a potential query to obtain history/buffer size on the proxy db (might not work with all supported databases, adapt as needed) :
select ((select max(proxy_history.id) from proxy_history)-nextid) from ids where field_name='history_lastid';
