There is an important character in scenarios where Zabbix is used—the user. The perception of this character can compromise the deployment. If Zabbix's frontend doesn't have adequate performance or is slow in loading screens, it doesn't matter how many values per second (VPS) our Zabbix server is managing to process, because you get a negative experience when trying to access data. The aim of this chapter is to take a look at this component of Zabbix (frontend) and seek the best alternative web servers and settings for any software. In this chapter, we are going to talk about:
- Things users usually complain about
- Differences between web servers
- Main configuration parameters
- Other alternatives
Generally, when we start using Zabbix, only the technicians who have installed Zabbix and are working as supporters for the environment have access to the frontend. But after a while, others will have access to the Zabbix frontend. So, the frontend performance will be tested and required much more than before.
As we already know, users can do amazing things with the software—things that developers cannot even think of during development. For example, in each user's profile configuration, it is possible to change their own settings:
- Language
- Theme
- Auto-login
- Auto-logout (minimum 90 seconds)
- Refresh (in seconds)
- Rows per page
- URL (after login)
Well, where is the risk with these settings? You may have noticed that the risk is in Refresh and Rows per page. If the user decides to change Refresh to 5 and Rows per page to 10,000 then what will happen? We will have a problem—a user complaining that Zabbix screens are too slow to load.
Another point is the fact that we will create maps, screens, slide shows, and graphics. Each of these components needs to read host data, triggers, items, and so on. The more maps, screens, and graphics, the more data is delivered to users at all times. At this point, the frontend becomes really necessary.
What do users often complain about? Of course, slow loading of Zabbix screens. In practice, all screens that require user validation (that is, almost all Zabbix screens) will use more resources, especially if we have a lot of users and host groups. This can cause a big problem. In Zabbix version 2.2, there was a change in the permission validation algorithm. This was done to minimize the impact of validation on screens. Until version 2.2 of Zabbix, we had a piece of logic for validation of permissions where it was necessary to validate all user groups to see whether the user had denied access to some of them to the host group. From version 2.2 onwards, this logic was changed, and Zabbix started to validate user access to data from a host in the first group where the user had permission to participate but not pass through other groups. This made Zabbix faster when validating permissions.
Going back to user complaints, we have other complaints, such as delays in assembling data in a graph or access to available reports. The fact is that the web server can directly impact the delivery of data to users.
We need to think and understand how to read and deliver data faster to users.