We've already discussed several caches in Zabbix and what they're used for. As these caches fill up, it can have different effects on Zabbix. Let's take a look at how we can monitor how much of some of those caches is free or used.

We could monitor the free space in the first cache we found out about, the configuration cache:

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

• • Name: Zabbix configuration cache, % free
  • Type: Zabbix internal
  • Key: zabbix[rcache,buffer,pfree]
  • Type of information: Numeric (float)
  • Units: %

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

For this item key, we used the rcache keyword, which stands for read cache. Coupled with buffer, it refers to the configuration cache. With pfree, we're requesting free space in this cache as a percentage. Notice how we're setting Type of information to Numeric (float); we could have left it at Numeric (unsigned), in which case, Zabbix would cut off the decimal part, which isn't suggested in this case. Check this item in the Latest data page:

On our system, it's highly unlikely to see the free configuration cache size drop below 90% with the default settings.

There're other internal caches on the server we can monitor. We'll discuss what they hold in more detail, and the suggested sizes, when we look at the daemon configuration parameters a bit later, but let's have a quick list for now:

• Configuration cache: We're monitoring it already. It holds host, item, trigger, and other configuration information.
• Value cache: This holds historical values to speed up triggers, calculated items, aggregate items, and other things.
• VMware cache: This holds fairly raw VMware data.
• History cache and history cache index: These two hold historical values before they're processed for triggers and written to the database.
• Trend cache: This holds trend information for the current hour for all items that're receiving values.

Note that most of the caches can be monitored for Zabbix proxies, too. This can be done by assigning the host with those items to be monitored by a specific Zabbix proxy. At that point, these internal items will return information about that proxy. Only relevant items will work; for example, monitoring the trend cache on a proxy isn't possible simply because there's no trend cache on a proxy. The same approach with having such a host assigned to a proxy works also for the items under the internal process busy rate, which we'll discuss next.