We can turn to Zabbix internal items to figure out how large the proxy buffer is—that is, how many values it has to send to the Zabbix server:

1. Let's go to Configuration | Hosts, click on Items next to Another host, and click on Create item. Fill in the following values:

• • Name: First proxy: buffer size
  • Type: Zabbix internal
  • Key: zabbix[proxy_history]

2. When done, click on the Add button at the bottom.

With the default proxy configuration update interval of one hour, it might take quite some time before we can see the result of this item. To speed up the configuration update, run the following on the proxy host:

# zabbix_proxy --runtime-control config_cache_reload

The proxy will request item configurations from the server and update its own cache. After a short while, we should be able to see the result in the Latest data page:

What is that value, though? It's quite simply the number of values that are still in the proxy buffer and must be sent to the server. This might allow us to create a trigger against this item. Whenever the buffer is bigger than 100, 200, or 1,000 values, we consider the proxy data not up to date and make all host triggers depend on the buffer size. Except that there's still a significant problem. Values for this item are kept in the same proxy buffer it monitors and are subject to the same sequential sending, with older values being sent first. With this item, we would still suffer from the same problem as before—while the proxy was unavailable, the proxy buffer item would hold 0 or some other small value. As values start to flow in, individual host triggers would fire, and only after some time would we see that the buffer was actually really large. It would be useful for some debugging later, but would not help with masking the hosts behind the proxy. Is there a solution then?