First, I will ask a question: what is the best storage for Zabbix? This question is generic and, no doubt, the answer to it is: the fastest possible. But what is the best storage for Zabbix considering your environment? Here, the answers are many and everyone has to find their own. But why not simply use the fastest existing storage in the world? If you have that kind of cash to invest in it, it will be great for you. Zabbix will run perfectly, without performance issues and for a long time.

We have to consider that the vast majority of users and companies that make the choice of Zabbix are also in search of reduction and/or adjustments in operating costs. It makes little sense to propose a project that always considers the most modern hardware and existing edge in the market. Certainly, we need to make some settings to suit all the premises of a Zabbix deployment project. We can't forget that at the beginning of the project, we will have to make acquisitions (services, hardware, training, and so on). In some companies, it is common to reuse existing hardware for a project involving Zabbix.

In this scenario, where resources are limited, we must think about what the best storage and configuration that can be used is. We can't forget that one of the goals of this book is to understand the Zabbix data flow for better use of the hardware resources we have.

One of the recurring questions we have in forums about Zabbix, and even from customers during the project is: can I use Zabbix in a virtualized environment? As always, we have some answers to this question, and all of them take into account a number of factors that must be evaluated when making decisions.

The main point to be considered in this question is: do we intend to virtualize all the major components of Zabbix? (the database, Zabbix server, and Zabbix GUI).

Some Zabbix components can be virtualized without major concerns:

What about the database? Here, the scenario changes completely because the database is where all of the data will flow. Any oscillation in the storage's virtualized environment can affect the writing or reading of Zabbix and infringe the platform's performance as a whole because the Zabbix server will have difficulty delivering the data to the database (directly affecting the cache, buffer, DBSyncer, and so on), and the Zabbix GUI will have difficulties reading the data (directly affecting the graphics display, screen, maps, triggers, and so on). Especially, almost every virtualized environment will use network storage, such as the EBS in AWS. This kind of network storage will have a great impact on the IO performance, and furthermore, it will delay the data flow.

As we can see, the first point raised was to use or not to use all the virtualized Zabbix components, and this is extremely important because we need to decide between the flexibility of a virtualized environment and—as a result—a shared environment or to have the stability of a physical environment, and thereby, isolated. Primer monitoring teaches us that we should keep the monitoring environment as isolated as possible from our production environment (that is, the monitored environment), as an oscillation in the production environment could affect the monitoring environment. Then we may have false positives or false negatives. Other than isolation, we must carry out the monitoring of the monitoring system itself.

Some people have certainly thought that the hardware, software, and atmosphere used for virtualization today are fairly robust and meet far more critical applications and services than Zabbix, and that would be enough to decide on using a virtualized environment. But we should not blindly trust such information. For example, I have seen Zabbix suffering in times of high occupancy of shared storage cache. The bottleneck of Zabbix is always the I/O bottleneck of database hardware (physical, virtual, shared storage, and so on).

The trick is to use local storage (dedicated) whenever possible because this decision will facilitate troubleshooting when necessary. It will also allow us to isolate the monitoring environment from the production environment.

In this dedicated storage, which is the proper hardware? Does it need to be a specific hardware for storage? Can I use the local disk? What RAID should I use?

Well, here the questions become more specific and it is easier to find the answers. Even though the focus here is on performance, we can't help but think about the redundancy of such data. So, to get the answers to these questions, let's consider the alternatives to ensure performance and data security.

Do we need specific hardware for storage? I would say no in most environments. Usually, the disks existing on the servers are sufficient to guarantee the good performance of Zabbix. Of course, we can't fail to consider the estimated size of the database, and thus measure the size needed for the disks we intend to use. In the Zabbix manual (considering version 2.4) there is a formula that helps us understand the growth of Zabbix's database.

In reality, the size of the database should be calculated for the sizes of the tables according to these rules:

Considering this information, add these values: configuration + history + trends + events.

Thus, we obtain the total space that will be occupied by Zabbix.

It is important to emphasize and draw attention to the fact that the events tables can grow quite large in the case of environments with a lot of oscillations and flap triggers.

In certain environments, the events table can be as large as the history tables. This also depends on the housekeeping settings for the events (retention time).