Simplifying Zabbix

Zabbix's basic objective is data gathering. Basically, this is what Zabbix does. Of course, the collected data will be processed and stored for future comparisons or consultations at regular time periods. The data will also be compared with thresholds (triggers) and viewed by users on screens, maps, and charts. It needs to be cleaned on a routine basis. At this point, things start becoming more complex with Zabbix. Although the platform has a very simple concept (work in data gathering and evaluation), there are factors related to the processing of such data that must be evaluated, and some parameters need to be adjusted to ensure that Zabbix operates properly. This leads to satisfaction of the users and administrators.

In later chapters, we will talk about the concepts and terminology that we define here in this chapter, for your better understanding.

Zabbix was born with its own concepts, terms, and ways of monitoring functions. As you may know, Zabbix was created by Alexei Vladishev in 1998 (in 2001, he published Zabbix's first release). Since the first release, Zabbix has had specific guidelines to work:

• All rules about thresholds, triggers, and alerts are managed by the Zabbix server (not the Zabbix agent).
• Almost all configuration tasks are done at the Zabbix GUI.
• The Zabbix GUI is PHP-based (using a web server and a web browser).
• All of the data (configuration and historical) is stored in a relational database (we are close to storing historical data in a NoSQL database).
• The Zabbix server was developed in the C language (mainly because C has a small footprint).

With this information, we need to start thinking mainly about four Zabbix components: the Zabbix server, Zabbix proxy, Zabbix database, and Zabbix GUI. Each one has its own characteristics and requirements:

• Zabbix server: This is the engine—the collector itself—responsible for gathering and/or receiving data from the environment. It is written in the C language and communicates with the Zabbix agents, Zabbix proxy, and Zabbix database. It is the main component of this environment, and manages all the rules (collections, triggers, alerts, and so on).
• Zabbix GUI: This is the Zabbix interface where users can see the data gathered by the Zabbix server in the environment. It is written in PHP, uses a web server (supporting PHP), and communicates with the Zabbix database. The Zabbix GUI communicates with the Zabbix server for some minor functions.
• Zabbix database: This is the Zabbix data repository. The backend database of Zabbix can be Oracle, IBM DB2, PostgreSQL, MySQL, or SQLite3. In this book, we will cover examples and case studies used with MySQL as the database.
• Zabbix proxy: This is an optional component, but as we will see throughout the chapters, when it comes to Zabbix's performance, it is of utmost importance. Its main function is to assist the Zabbix server in data gathering in the monitored hosts. The data gathered by the Zabbix proxy is first kept in a temporary database, and is subsequently sent to the Zabbix server.

  These four components create the Zabbix monitoring solution. Throughout this book, we will cover the main aspects related to the performance of each of these components, looking for a clearer and more objective view of the elements and configuration parameters that will directly influence performance.