Whatsapp

Zabbix Datasheet

Zabbix is an enterprise-class open source distributed monitoring solution.

Zabbix is a software that monitors numerous parameters of a network and the health and integrity of servers, virtual machines, applications, services, databases, websites, the cloud and more. Zabbix uses a flexible notification mechanism that allows users to configure e-mail based alerts for virtually any event. This allows a fast reaction to server problems. Zabbix offers excellent reporting and data visualization features based on the stored data. This makes Zabbix ideal for capacity planning.

Zabbix supports both polling and trapping. All Zabbix reports and statistics, as well as configuration parameters, are accessed through a web-based frontend. A web-based frontend ensures that the status of your network and the health of your servers can be assessed from any location. Properly configured, Zabbix can play an important role in monitoring IT infrastructure. This is equally true for small organizations with a few servers and for large companies with a multitude of servers.

Architecture

Server

Zabbix server is the central component to which agents report availability and integrity information and statistics. The server is the central repository in which all configuration, statistical and operational data are stored.

Database storage

All configuration information as well as the data gathered by Zabbix is stored in a database. Web interface . For an easy access to Zabbix from anywhere and from any platform, the web-based interface is provided. The interface is part of Zabbix server, and usually (but not necessarily) runs on the same physical machine as the one running the server.

Proxy

Zabbix proxy can collect performance and availability data on behalf of Zabbix server. A proxy is an optional part of Zabbix deployment; however, it may be very beneficial to distribute the load of a single Zabbix server.

Agent

Zabbix agents are deployed on monitoring targets to actively monitor local resources and applications and report the gathered data to Zabbix server. Since Zabbix 4.4, there are two types of agents available: the Zabbix agent (lightweight, supported on many platforms, written in C) and the Zabbix agent 2 (extra-flexible, easily extendable with plugins, written in Go).

Data Flow

All configuration information as well as the data gathered by Zabbix is stored in a database. In addition it is important to take a step back and have a look at the overall data flow within Zabbix. In order to create an item that gathers data you must first create a host. Moving to the other end of the Zabbix spectrum you must first have an item to create a trigger. You must have a trigger to create an action. Thus if you want to receive an alert that your CPU load is too high on Server X you must first create a host entry for Server X followed by an item for monitoring its CPU, then a trigger which activates if the CPU is too high, followed by an action which sends you an email. While that may seem like a lot of steps, with the use of templating it really isn’t. However, due to this design it is possible to create a very flexible setup

Zabbix Requirement

Hardware

Zabbix requires both physical and disk memory. The amount of required disk memory obviously depends on the number of hosts and parameters that are being monitored. If you’re planning to keep a long history of monitored parameters, you should be thinking of at least a couple of gigabytes to have enough space to store the history in the database. Each Zabbix daemon process requires several connections to a database server. The amount of memory allocated for the connection depends on the configuration of the database engine.

Zabbix and especially Zabbix database may require significant CPU resources depending on number of monitored parameters and chosen database engine.

A serial communication port and a serial GSM modem are required for using SMS notification support in Zabbix. USB-to-serial converter will also work.

Examples of hardware configuration

The table provides examples of hardware configuration, assuming a Linux/BSD/Unix platform.

These are size and hardware configuration examples to start with. Each Zabbix installation is unique. Make sure to benchmark the performance of your Zabbix system in a staging or development environment, so that you can fully understand your requirements before deploying the Zabbix installation to its production environment.

Edit
Installation SizeMonitored Metrics¹CPU/vCPU CoresMemory (GB)DatabaseAmazon EC2²
Small1 00028MySQL Server, Percona Server, MariaDB Server, PostgreSQLm6i.large/m6g.large
Medium10 000416MySQL Server, Percona Server, MariaDB Server, PostgreSQLm6i.xlarge/m6g.xlarge
Large100 0001664MySQL Server, Percona Server, MariaDB Server, PostgreSQL, Oraclem6i.4xlarge/m6g.4xlarge
Very large1 000 0003296MySQL Server, Percona Server, MariaDB Server, PostgreSQL, Oraclem6i.8xlarge/m6g.8xlarge

Due to security requirements and the mission-critical nature of the monitoring server, UNIX is the only operating system that can consistently deliver the necessary performance, fault tolerance, and resilience. Zabbix operates on market-leading versions.

Zabbix components are available and tested for the following platforms:

Database Size

Zabbix configuration data require a fixed amount of disk space and do not grow much.
Zabbix database size mainly depends on these variables, which define the amount of stored historical data:

This is the average number of new values Zabbix server receives every second. For example, if we have 3000 items for monitoring

with a refresh rate of 60 seconds, the number of values per second is calculated as 3000/60 = 50. It means that 50 new values are added to Zabbix database every second.

Zabbix keeps values for a fixed period of time, normally several weeks or months. Each new value requires a certain amount of disk space for data and index.

So, if we would like to keep 30 days of history and we receive 50 values per second, the total number of values will be around (30*24*3600)* 50 = 129.600.000, or about 130M of values.

Depending on the database engine used, type of received values (floats, integers, strings, log files, etc), the disk space for keeping a single value may vary from 40 bytes to hundreds of bytes. Normally it is around 90 bytes per value for numeric items2. In our case, it means that 130M of values will require 130M * 90 bytes = 10.9GB of disk space.

Note:
The size of text/log item values is impossible to predict exactly, but you may expect around 500 bytes per value.

Zabbix keeps a 1-hour max/min/avg/count set of values for each item in the table trends. The data is used for trending and long period graphs. The one hour period can not be customized.

Zabbix database, depending on the database type, requires about 90 bytes per each total. Suppose we would like to keep trend data for 5 years. Values for 3000 items will require 3000*24*365* 90 = 2.2GB per year, or 11GB for 5 years.



Each Zabbix event requires approximately 250 bytes of disk space1. It is hard to estimate the number of events generated by Zabbix daily. In the worst-case scenario, we may assume that Zabbix generates one event per second.

For each recovered event, an event_recovery record is created. Normally most of the events will be recovered so we can assume one event_recovery record per event. That means additional 80 bytes per event.

Optionally events can have tags, each tag record requiring approximately 100 bytes of disk space¹. The number of tags per event (#tags) depends on configuration. So each will need an additional #tags * 100 bytes of disk space.

It means that if we want to keep 3 years of events, this would require 3*365*24*3600* (250+80+#tags*100) = ~30GB+#tags*100B disk space².

Note:
1. More when having non-ASCII event names, tags and values.
2. The size approximations are based on MySQL and might be different for other databases.

The table contains formulas that can be used to calculate the disk space required for Zabbix system:

So, the total required disk space can be calculated as:

Configuration + History + Trends + Events

The disk space will NOT be used immediately after Zabbix installation. Database size will grow then it will stop growing at some point, which depends on housekeeper settings.

Time synchronization

It is very important to have precise system time on the server with Zabbix running. ntpd is the most popular daemon that syn- chronizes the host’s time with the time of other machines. It’s strongly recommended to maintain synchronized system time on all systems Zabbix components are running on.

Software

Zabbix is built around modern web servers, leading database engines, and PHP scripting language. Mandatory requirements are needed always. Optional requirements are needed for the support of the specific function.

SoftwareMandatory StatusComments
MySQL/Percona
MariaDB
Oracle PostgreSQL TimescaleDB for PostgreSQL 		One ofRequired if MySQL (or Percona) is used as Zabbix backend database. InnoDB engine is required.

We recommend using the C API (libmysqlclient) library for building server/proxy.
InnoDB engine is required.

We recommend using the MariaDB Connector/C `library for building server/proxy.

Required if Oracle is used as Zabbix backend database. Required if PostgreSQL is used as Zabbix backend database. Required if TimescaleDB is used as a PostgreSQL database extension. Make sure to install TimescaleDB Community Edition, which supports compression.
SQLite
smartmontools who
dpkg
pkgtool
rpm
pacman
q applets 		OptionalNote that PostgreSQL 15 is supported since TimescaleDB 2.10. SQLite is only supported with Zabbix proxies. Required if SQLite is used as Zabbix proxy database.
Required for Zabbix agent 2.
Required for the user count plugin.
Required for the system.sw.packages plugin.
Required for the system.sw.packages plugin.
Required for the system.sw.packages plugin.
Required for the system.sw.packages plugin.
qlist and qsize, as part of q applets, are required for the system.sw.packages plugin on Gentoo Linux.
Apache
PHP
PHP extensions: gd
bcmath
ctype
libXML

YesIt is recommended to use PHP 8.0 or newer, because PHP 7.4 is no longer supported by the vendor
PHP GD extension must support PNG images (--with-png-dir), JPEG (--with-jpeg-dir) images and FreeType 2 (--with-freetype-dir). php-bcmath (--enable-bcmath)
php-ctype (--enable-ctype)
php-xml, if provided as a separate package by the distributor
Xmlreader
xmlwriter
session
sockets
mbstring
gettext
ldap
openssl
mysqli
oci8
pgsql 		Nophp-xmlreader, if provided as a separate package by the distributor. php-xmlwriter, if provided as a separate package by the distributor. php-session, if provided as a separate package by the distributor. php-net-socket (--enable-sockets). Required for user script support. php-mbstring (--enable-mbstring)
php-gettext (--with-gettext). Required for translations to work. php-ldap. Required only if LDAP authentication is used in the frontend.
php-openssl. Required only if SAML authentication is used in the frontend.
Required if MySQL is used as Zabbix backend database. Required if Oracle is used as Zabbix backend database. Required if PostgreSQL is used as Zabbix backend database

Zabbix Features

  • Availability and performance checks
  • Support for SNMP (both trapping and polling), IPMI, JMX, VMware monitoring
  • Custom checks
  • Gathering desired data at custom intervals
  • Performed by server/proxy and by agents
  • You can define very flexible problem thresholds, called triggers, referencing values from the backend database
  • Sending notifications can be customized for the escalation schedule, recipient, media type
  • Notifications can be made meaningful and helpful using macro variables
  • Automatic actions include remote commands
  • Monitored items are immediately graphed using the built-in graphing functionality
  • Zabbix can follow a path of simulated mouse clicks on a web site and check for functionality and response time
  • Ability to create custom graphs that can combine multiple items into a single view • network maps
  • Slideshows in a dashboard-style overview
  • Reports
  • High-level (business) view of monitored resources
  • Data stored in a database
  • Configurable history
  • Built-in housekeeping procedure
  • Add monitored devices as hosts
  • Host are picked up for monitoring, once in the database
  • Apply templates to monitored devices
  • Grouping checks in templates
  • Templates can inherit other templates
  • Automatic discovery of network devices
  • Agent auto registration
  • Discovery of file systems, network interfaces and SNMP OIDs
  • A web-based frontend in PHP
  • Accessible from anywhere
    You can click your way through
  • Audit log
  • Zabbix API provides programmable interface to Zabbix for mass manipulations, third-party software integration and other purposes.
  • Secure user authentication
  • Certain users can be limited to certain views
  • Deployed on monitoring targets
  • Can be deployed on both Linux and Windows
  • Written in C, for performance and small memory footprint
  • Easily portable
  • Remote monitoring made easy by using a Zabbix proxy

Contact Us!