About this book

This book will help you to implement a powerful network monitoring solution based on Zabbix. Beginning with the installation of Zabbix, you will be guided through the complex task of designing, configuring, and deploying an enterprise class solution to efficiently monitor the networking infrastructures. Focusing on DNS and proxies, IT admins will learn how to effectively monitor a large network using Zabbix.

Starting with a quick walk-through of the basics, this book will prove to be an invaluable tutorial if you intend to deploy a robust and secure monitoring system for your networking environment with 24/7 automated reporting and logging. With extensive coverage of network topology with maps and graphs, this book will enable you to set up an effective monitoring solution for your network infrastructure. The book's fast-paced, easy-to-follow approach ensures that you'll learn everything quickly and efficiently.

Publication date:
February 2015
Publisher
Packt
Pages
178
ISBN
9781784399764

 

Chapter 1. Installing a Distributed Zabbix Setup

Most likely, if you are reading this book, you have already used and installed Zabbix as a network monitoring solution. Now, in this chapter, we will see how to install Zabbix in a distributed setup, eventually moving on to a large use of proxies. The chapter will take you through all the possible scenarios and explain the main differences between the active and passive proxy setup. Usually, the first Zabbix installation is done as a part of the concept to see whether the platform is good enough for you. Here, the common error is to start using this setup on a large production environment. After reading this chapter, you will be ready to install and set up a large environment ready infrastructure.

In this chapter, we will explain how to prepare and set up a Zabbix installation, which is ready to be grown within your infrastructure, and ready for a large to a very large environment. This book is mainly focused on Zabbix for network monitoring. This chapter will quickly take you through the installation process, emphasizing on all the most important points you need to consider. In the next chapter, we will spend more time describing a better approach to monitor your network devices and how to retrieve all the critical metrics from them. After reading this chapter, you will become aware of the communication between server and proxies being able to mix the active and passive setup in order to improve your infrastructure. You can extend the strong central Zabbix core setup with many lightweight and effective Zabbix proxies acting as a satellite inside your network to improve your monitoring system.

 

Zabbix architectures


Zabbix was born as a distributed network monitoring tool with a central web interface where you can manage almost everything. Nowadays, with Zabbix 2.4, the number of possible architectures has been reduced to a single server setup and a Zabbix-proxies distributed setup.

Note

From Zabbix 2.4, the node-setup was discontinued. More information is available at https://www.zabbix.com/documentation/2.4/manual/introduction/whatsnew240#node-based_distributed_monitoring_removed.

Now, the simplest architecture (which is ready to handle large environments successfully) that you can implement composes of three servers:

  • Web server

  • RDBMS server

  • Zabbix server

To prepare this simple setup for a large environment setting, it's better to use a dedicated server for each one of these components.

This is the simplest setup that can be easily extended and is ready to support a large environment.

The proposed architecture is shown in the following diagram:

This kind of setup can be extended by adding many Zabbix proxies resulting in a proxy-based setup. The proxy-based setup is implemented with one Zabbix server and several proxies: one proxy per branch, data center or, in our case, for each remote network segment you need to monitor.

This configuration is easy to maintain and offers the advantage to have a centralized monitoring solution. This kind of configuration is the right balance between large environment monitoring and complexity.

The Zabbix proxy, like a server, is used to collect data from any number of hosts or devices, acquiring all the metrics requested and acting as a proxy. This means that it can retain this data for an arbitrary period of time, relying on a dedicated database to do so. The proxy doesn't have a frontend and is managed directly from the central server.

Note

The proxy limits itself to data collection without trigger evaluations or actions; all the data is stored in its database. For this reason, it's better to use an efficient robust RDBMS that can prevent data loss in case of a crash.

All these characteristics make the Zabbix proxy a lightweight tool to deploy and offload some checks from the central server. Our objective is to control and streamline the flow of monitored data across networks, and the Zabbix proxy gives us the possibility to split and segregate items and data on the different networks. The most important feature is that the acquired metrics are stored in its database. Therefore, in case of a network loss, you will not lose them.

 

Understanding Zabbix data flow


The standard Zabbix data flow is composed of several actors that send data to our Zabbix server. Of all the sources that can send data to our Zabbix server, we can identify three main data sources:

  • Zabbix agent

  • Zabbix sender

  • Other agents (external scripts or components built in house)

The other agents represented in the next diagram can be of two main types:

  • Custom and/or third-party agents

  • Zabbix proxy

As the diagram displays the data that gets acquired from many different sources in the form of items. At the end of the diagram, you see the GUI, which practically represents the users connected and the database that is the place where all the values are stored.

In the next section, we will dive deep into the Zabbix proxies' data flow.

 

Understanding the Zabbix proxies' data flow


Zabbix proxies can operate in two different modes, active and passive. The default setup is the active proxy. In this setup, the proxy initiates all connections to the Zabbix server, the one used to retrieve configuration information on monitored objects, and the connection to send measurements back to the server. Here, you can change and tweak the frequency of these two activities by setting the following variables in the proxy configuration file: /etc/zabbix/zabbix_proxy.conf:

ConfigFrequency=3600
DataSenderFrequency=1

Values are expressed in seconds. On the Zabbix server-side, you need to carefully set the value of StartTrappers=.

This value needs to be greater than the number of all active proxies and nodes you deployed. The trapper processes, indeed, manage all the incoming information from the proxies.

Note

Please note that the server will fork extra processes as required, if needed, but it is strongly advisable to prefork all the processes that are needed during the startup. This will reduce the overhead during the normal operation.

On the proxy side, another parameter to consider is:

HeartbeatFrequency

This parameter sets a sort of keep alive, which after the defined number of seconds, will contact the server although it doesn't have any data to send. The proxy availability can be easily checked with the following item:

zabbix[proxy, "proxy unique name", lastaccess]

Here the proxy unique name, of course, is the identifier you assigned to the proxy during deployment. The item will return the number of seconds as the last time that the proxy was contacted, a value you can then use with the appropriate triggering functions.

Tip

It's really important to have a trigger associated to this item, so you can be warned in case of connection loss. Looking at the trend of this trigger, you can learn about an eventual reaping time set on the firewall. Let's look at a practical example: if you notice that after 5 minutes your connections are dropped, set the heartbeat frequency to 120 seconds and check for the last access time above 300 seconds.

In the following diagram, you can see the communication flow between the Zabbix server and the proxy:

As you can see from the diagram, the server will wait to receive requests from the proxy and nothing more.

Note

The active proxy is the most efficient way to offload duties from the server. Indeed, the server will just sit here waiting to be asked about changes in configuration, or to receive new monitoring data.

On the other side, proxies are usually deployed to monitor secure network segments with strict outgoing traffic policies, and are usually installed on DMZs. In these kind of scenarios, normally, it is very difficult to obtain permission for the proxy to initiate the communication with the server. Unfortunately, it's not just due to policies. DMZs are isolated as much as possible from internal networks, as they need to be as secure as they can. Generally, it's often easier and more accepted from a security point of view to initiate a connection from the internal network to a DMZ. In this kind of scenario, the passive proxy is very helpful. The passive proxy is almost a mirrored image of the active proxy setup, as you can see in the following diagram:

With this configuration, the Zabbix server will contact the proxy periodically to deliver the configuration changes and to request the item values the proxy is holding.

This is the proxy configuration to enable the proxy you need to set:

ProxyMode=1

This parameter specifies the passive proxy, you don't need to do anything else. Now, on the server side, you need to set the following parameters:

  • StartProxyPollers=

    This will set the number of processes dedicated to the passive proxies

    Note

    The StartProxyPollers parameter should match the number of passive proxies you have deployed.

  • ProxyConfigFrequency=

    This value expresses the frequency with which the server sends the configuration to its proxy

  • ProxyDataFrequency=

    This is the interval parameter that expresses the number of seconds between two consecutive requests to get the acquired metrics from the proxy

The item used to check a passive proxy's availability is as follows:

zabbix[proxy, "proxy unique name", lastaccess]

This is exactly the same as the active one.

The passive proxy enables us to gather monitoring data from otherwise closed and locked down networks with a slightly increased overhead.

Note

You can mix as many active and passive proxies as you want in your environment. This enables you to expand your monitoring solution to reach each part of the network and to handle a large number of monitored objects. This approach keeps the architecture simple and easy to manage with a strong central core and many simple, lightweight satellites.

If you would like to keep track of all the remaining items that the proxy needs to send, you can set up the proxy to run this query against its database:

SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name='history_lastid'

Tip

Downloading the example code

You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

This query will return the number of items that the proxy still needs to send to the Zabbix server. Considering that you are using MySQL as a database, you need to add the following user parameter in the proxy agent configuration file:

UserParameter=zabbix.proxy.items.sync.remaining, mysql -u <your dbname here> -p '<your password here>' -e 'SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name=history_lastid' 2>&1

Now, all you need to do is set an item on the Zabbix server side and you can see how your proxy is freeing its queue.

 

Installing Zabbix


Zabbix, like all the other software, can be installed in two ways:

  1. Download the latest source code and compile it.

  2. Install it from packages.

Actually, there is another way to have a Zabbix server up and running: using the virtual appliance. The Zabbix server appliance will not be considered in this book as Zabbix itself defines this virtual appliance as not ready for productive environments. This virtual appliance is not a production ready setup for many reasons:

  • It is a monolith where everything is installed on the same server.

  • There is no separation from the database layer and the presentation layer. This means that each one of these components can affect the performance of the other.

  • There is a clear warning on the website that warns us with this statement: The Appliance is not intended for serious production use at this time.

On the other hand, the installation from packages gives us some benefits:

  • The packages make it easy to upgrade and update

  • Dependencies are automatically sorted out

The source code compilation also gives us some benefits:

  • We can compile only the needed features

  • We can build the agent statically and deploy on different Linux flavors

  • Complete control on update

It's quite usual to have different versions of Linux, Unix, and Microsoft Windows on a large environment. This kind of scenario is quite diffused on a heterogeneous infrastructure, and if we use the Zabbix's agent distribution package on each Linux server, we will have different versions of the agent for sure, and different locations for the configuration files.

The more the things are standardized across our server, the easier it will become to maintain and upgrade the infrastructure. The --enable-static option gives us a way to standardize the agent across different Linux versions and release, which is a strong benefit. The agent, statically compiled, can be easily deployed everywhere and, for sure, we will have the same location (and we can use the same configuration file apart from the node name) for the agent and his/her configuration file. The only thing that might vary is the start/stop script and how to register it on the right init runlevel, but at least the deployment will be standardized.

The same kind of concept can be applied to the commercial Unix, bearing in mind to compile it on the target environment so that the same agent can be deployed on different Unix releases of the same vendor.

Installing from packages

The first thing to do to install Zabbix from repo is to add the yum repository to our list. This can be done with the following command:

$ rpm -Uvh http://repo.zabbix.com/zabbix/2.4/rhel/6/x86_64/zabbix-release-2.4-1.el6.noarch.rpm
Retrieving http://repo.zabbix.com/zabbix/2.4/rhel/6/x86_64/zabbix-release-2.4-1.el6.noarch.rpm
warning: /var/tmp/rpm-tmp.dsDB6k: Header V4 DSA/SHA1 Signature, key ID 79ea5ed4: NOKEY
Preparing…         ########################################### [100%]
1:zabbix-release   ########################################### [100%]

Once this is done, we can take advantage of all the benefits introduced by the package manager and have the dependencies automatically resolved by yum.

To install the Zabbix server, you simply need to run:

$ yum install zabbix-server-mysql zabbix-agent zabbix-javagateway

Now, you have your server ready to start. We can't start it now as we need to set up the database, which will be done in the next heading, anyway, what you can do is set up the start/stop runlevel for our zabbix_server and zabbix_agent daemons:

$ chkconfig --level 345 zabbix-server on
$ chkconfig --level 345 zabbix-agent on

Please double check if the previous command ran successfully with the following:

$ chkconfig --list | grep zabbix
zabbix-agent    0:off   1:off   2:off   3:on     4:on   5:on   6:off
zabbix-server   0:off   1:off   2:off   3:on   4:on   5:on   6:off

Setting up a Zabbix agent

Now, as usually happens in a large server farm, it is possible that you have many different variants of Linux. Here, if you can't find the package for your distribution, you can even think to compile the agent from scratch. The following are the steps for the same:

  1. Download the source code from the Zabbix website.

  2. Unpack the software.

  3. Satisfy all the software dependencies, installing all the related -devel packages.

  4. Run the following command: $ ./configure --enable-agent.

    Tip

    Here, you can statically link the produced binary with the --enable-static option. With this, the binary produced will not require any external library. This is really useful to distribute the agent across different versions of Linux.

Compile everything with $ make.

Now, before you run $ make install, you can decide to create your own package to distribute with CheckInstall.

Creating a Zabbix agent package with CheckInstall

The advice is to not run make install, but use CheckInstall to produce the required package for your Linux OS from http://asic-linux.com.mx/~izto/checkinstall/.

Note

We can also use a prebuilt CheckInstall; the current release is checkinstall-1.6.2-20.2.i686.rpm on Red Hat / CentOS. The package will also need the rpm-build package:

rpm-build yum install

Also, we need to create the necessary directories:

mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

This software enables you to create a package for many different versions of the package manager, namely, RPM, deb, and tgz.

Note

CheckInstall will produce packages for Debian, Slackware, and Red Hat, helping us to prepare the Zabbix's agent package (statically linked) and distribute it around our server.

Now, we need to switch to the root account using $ sudo su – . Also, use the checkinstall followed by these options:

$ checkinstall --nodoc --install=yes -y

If you don't face any issue, you should get the following message:

******************************************************************
 Done. The new package has been saved to
 /root/rpmbuild/RPMS/i386/zabbix-2.4.0-1.i386.rpm
 You can install it in your system anytime using:
      rpm -i zabbix-2*.4.0-1.i386.rpm
******************************************************************

Remember that the server binaries will be installed in <prefix>/sbin, utilities will be in <prefix>/bin, and the main pages under the <prefix>/share location.

Tip

To specify a different location for Zabbix binaries, we need to use --prefix on the configure options (for example, --prefix=/opt/zabbix).

Server configuration

For the server configuration, we only have one file to check and edit:

/etc/zabbix/zabbix_server.conf

All the configuration files are contained in the following directory:

/etc/zabbix/

All you need to change for the initial setup is the /etc/zabbix/zabbix_server.conf configuration file and write the username/password and database name here.

Note

Please take care to protect the access to the configuration file with chmod 400 /etc/zabbix/zabbix_server.conf.

The default external scripts location is:

/usr/lib/zabbix/externalscripts

Also, the alert script directory is:

/usr/lib/zabbix/alertscripts

This can be changed by editing the zabbix_server.conf file.

The configuration on the agent side is quite easy; basically, we need to write the IP address of our Zabbix server.

 

Installing a database


The database we will use on this book, as already explained, is MySQL.

Now, considering that you have a Red Hat server, the procedure to install MySQL from the RPM repository is quite easy:

$ yum install mysql mysql-server

Now, you need to set up the MySQL service to start automatically when the system boots:

$ chkconfig --levels 235 mysqld on
$ /etc/init.d/mysqld start

Tip

Remember to set a password for the MySQL root user

To set a password for the root, you can run these two commands:

/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h hostname-of-your.zabbix.db password 'new-password'

Alternatively, you can run:

/usr/bin/mysql_secure_installation

This will also help you to remove the test databases and anonymous user data that was created by default. This is strongly recommended for production servers.

Now, it's time to create the Zabbix database. For this, we can use the following commands:

$ mysql -u root -p
$ mysql> CREATE DATABASE zabbix CHARACTER SET UTF8;
Query OK, 1 row affected (0.00 sec)
$ mysql> GRANT ALL PRIVILEGES on zabbix.* to 'zabbixuser'@'localhost' IDENTIFIED BY 'zabbixpassword';
Query OK, 0 rows affected (0.00 sec)
$ mysql> FLUSH PRIVILEGES;
$ mysql> quit

Next, we need to restore the default Zabbix MySQL database files:

$ mysql -u zabbixuser -pzabbixpassword zabbix< /usr/share/doc/zabbix-server-mysql-2.4.0/create/schema.sql
$ mysql -u zabbixuser -pzabbixpassword zabbix < /usr/share/doc/zabbix-server-mysql-2.4.0/create/images.sql
$ mysql -u zabbixuser -pzabbixpassword zabbix < /usr/share/doc/zabbix-server-mysql-2.4.0/create/data.sql

Now, our database is ready. Before we begin to play with the database, it's important to do some consideration about database size and heavy tasks against it.

Considering the database size

Zabbix uses two main groups of tables to store its data:

  • History

  • Trends

Now, the space consumed by these tables is influenced by:

  • Items: This is the number of items you're going to acquire

  • Refresh rate: This is the mean average refresh rate of our items

  • Space to store values: This depends on RDBMS

The space used to store data can vary due to the database, but we can resume the space used by these tables in the following table:

Type of measure

Retention in days

Space required

History

30

10.8 G

Events

1825 (5 years)

15.7 GB

Trends

1825 (5 years)

26.7 GB

Total

NA

53.2 GB

This calculation is, of course, done considering the environment after 5 years of retention. Anyway, we need to have an environment ready to survive this period of time and retain the same shape that it had when it was installed. We can easily change the history and trends retention policy per item. This means that we can create a template with items that have a different history retention by default. Normally, the history is set to 30 days, but for some kind of measure (such as in web scenarios) or other particular measures, we need to keep all the values for more than a week. This permits us to change this value on each item.

MySQL partitioning

Now that we are aware of how big our database will be, it's easy to imagine that housekeeping will be a heavy task and the time, CPU, and resource consumed by this one will grow together with the database size.

Housekeeping is in charge to remove the outdated metrics from the database and the information deleted by a user, and as we've seen the history, trends, and events tables are, after some time, huge tables. This explains why the process is so heavy to manage.

The only way we can improve performances once we have reached this volume of data is by using partitioning and disabling the housekeeper altogether.

Partitioning the history and trend tables will provide us with many major benefits:

  • All history data in a table for a particular defined window time are self-contained in its own partition. This allows you to easily delete old data without impacting the database performance.

  • When you use MySQL with InnoDB, and if you delete data contained in a table, the space is not released. The space freed is marked as free, but the disk space consumed will not change. When you use partition, and if you drop a partition, the space is immediately freed.

  • Query performance can be improved dramatically in some situations, in particular, when there is heavy access to the table's rows in a single partition.

  • When a query updates a huge amount of data or needs access to a large percentage of the partition, the sequential scan is often more efficient than the index usage with a random access or scattered reads against this index.

Unfortunately, Zabbix is not able to manage the partitions. So, we need to disable housekeeping, and use an external process to accomplish housekeeping.

What we need to have is a stored procedure that does all the work for us.

The following is the stored procedure:

DELIMITER $$
CREATE PROCEDURE `partition_maintenance`(SCHEMA_NAME VARCHAR(32), TABLE_NAME VARCHAR(32), KEEP_DATA_DAYS INT, HOURLY_INTERVAL INT, CREATE_NEXT_INTERVALS INT)
BEGIN
  DECLARE OLDER_THAN_PARTITION_DATE VARCHAR(16);
  DECLARE PARTITION_NAME VARCHAR(16);
  DECLARE LESS_THAN_TIMESTAMP INT;
  DECLARE CUR_TIME INT;

Until here, we have declared the variable we need after. Now, on the next line, we will call the stored procedure responsible to check whether a partition is already present and if not, we will create them:

        CALL partition_verify(SCHEMA_NAME, TABLE_NAME, HOURLY_INTERVAL);
        SET CUR_TIME = UNIX_TIMESTAMP(DATE_FORMAT(NOW(), '%Y-%m-%d 00:00:00'));
        IF DATE(NOW()) = '2014-04-01' THEN
          SET CUR_TIME = UNIX_TIMESTAMP(DATE_FORMAT(DATE_ADD(NOW(), INTERVAL 1 DAY), '%Y-%m-%d 00:00:00'));
        END IF;
        SET @__interval = 1;
        create_loop: LOOP
          IF @__interval > CREATE_NEXT_INTERVALS THEN
            LEAVE create_loop;
          END IF;
        SET LESS_THAN_TIMESTAMP = CUR_TIME + (HOURLY_INTERVAL * @__interval * 3600);
        SET PARTITION_NAME = FROM_UNIXTIME(CUR_TIME + HOURLY_INTERVAL * (@__interval - 1) * 3600, 'p%Y%m%d%H00');

Now that we have calculated all the parameters needed by the create_partition procedure, we can run it. This stored procedure will create the new partition on the defined schema:

                CALL partition_create(SCHEMA_NAME, TABLE_NAME, PARTITION_NAME, LESS_THAN_TIMESTAMP);
                SET @[email protected]__interval+1;
        END LOOP;
        SET OLDER_THAN_PARTITION_DATE=DATE_FORMAT(DATE_SUB(NOW(), INTERVAL KEEP_DATA_DAYS DAY), '%Y%m%d0000');

The section that follows is responsible to remove the older partitions, using the OLDER_TAN_PARTITION_DATE procedure, which we have calculated on the lines before:

        CALL partition_drop(SCHEMA_NAME, TABLE_NAME, OLDER_THAN_PARTITION_DATE); 
END$$
DELIMITER ;

This stored procedure will be the core of our housekeeping. It will be called with the following syntax:

CALL partition_maintenance('<zabbix_db_name>', '<table_name>', <days_to_keep_data>, <hourly_interval>, <num_future_intervals_to_create>)

The procedure works based on 1 hour intervals. Next, if you want to partition on a daily basis, the interval will be 24 hours. Instead, if you want 1 hour partitioning, the interval will be 1.

You need to specify the number of intervals that you want created in advance. For example, if you want 2 weeks interval of future partitions, use 14. If your interval is 1 (for hourly partitioning), then the number of intervals to create is 336 (24*14).

This stored procedure uses some other stores procedures:

  • partition_create: This creates the partition for the specified table

  • partition_verify: This checks whether the partition is enabled on a table, if not, then create a single partition

  • partition_drop: This drops partitions older than a timestamp

For all the details about these stored procedures, see Appendix A, Partitioning the Zabbix Database.

Once you've created all the required stored procedures, you need to change two indexes to enable them in order to be ready for a partitioned table:

mysql> Alter table history_text drop primary key, add index (id), drop index history_text_2, add index history_text_2 (itemid, id);
Query OK, 0 rows affected (0.49 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> Alter table history_log drop primary key, add index (id), drop index history_log_2, add index history_log_2 (itemid, id);
Query OK, 0 rows affected (2.71 sec)
Records: 0  Duplicates: 0  Warnings: 0

Once this is done, you need to schedule the partition_maintenance_all stored procedure with a cron job. For more details about the partition_maintenance_all procedure, please check the instructions contained in Appendix A, Partitioning the Zabbix Database. The cron job needs to execute the following command:

mysql -h <zabbix_db_host> -u<zabbixuser> -p<zabbixpassword> zabbixdatabase -e "CALL partition_maintenance_all('zabbix');" 

Once this has been set, you need to bear in mind to disable the housekeeping for history and trends. Verify that the Override item <trend/history> period Zabbix configuration is checked for both history and trends. Here, you need to set the Data storage period (in days) box for history and trends to the value you've defined in your procedure, our example in Appendix A, Partitioning the Zabbix Database is of 28 and 730.

 

Installing a Zabbix proxy


Installation of the Zabbix proxy from packages is a quite simple task. Once you've added the Zabbix repository, you only need to run the following command:

$ yum install zabbix-proxy-mysql

This will install the required packages:

Installation:
 zabbix-proxy-mysql  x86_64  2.4.0-1.el6  zabbix  390 k
Installing for dependencies:
zabbix-proxy  x86_64  2.4.0-1.el6  zabbix  21 k

The Zabbix proxy installation is quite similar to the server one. Once you've installed the server, you need to install MySQL, create the database, and import the DB schema:

$ mysql -u root -p
$ mysql> CREATE DATABASE zabbix CHARACTER SET UTF8;
Query OK, 1 row affected (0.00 sec)
$ mysql> GRANT ALL PRIVILEGES on zabbix.* to 'zabbixuser'@'localhost' IDENTIFIED BY 'zabbixpassword';
Query OK, 0 rows affected (0.00 sec)
$ mysql> FLUSH PRIVILEGES;
$ mysql> quit

Next, we need to restore the default Zabbix MySQL database files:

$ mysql -u zabbixuser -pzabbixpassword zabbix < /usr/share/doc/zabbix-proxy-mysql-2.4.0/create/schema.sql

Now, we need to start the database, configure the proxy, and start the service. In this example, we have considered to use a Zabbix proxy that relies on a MySQL with InnoDB database. This proxy can be performed in two different ways:

  • Lightweight (and then use SQLite3)

  • Robust and solid (and then use MySQL)

Here, we have chosen the second option. In a large network environment where the proxy, in case of issue, needs to preserve all the metrics acquired until the server acquires the metrics, it's better to reduce, at the minimum, the risk of data loss. Also, if you consider this scenario in a large network environment, you most likely will have thousands of subnetworks connected to the Zabbix server with all the possible network devices in-between. Well, exactly, this is necessary to use a database that can prevent any data corruptions.

 

Installing the WebGUI interface


The WebGUI interface will be done once more using the RPMs.

To install the web interface, you need to run the following command:

$ yum install zabbix-web-mysql

Yum will take care to resolve all the dependencies. Once you're done, the process of this component is quite easy: we need to open a web browser, point at the following URL: http://your-web-server/zabbix, and follow the instructions.

On the standard Red Hat system, you simply need to change these parameters on your /etc/php.ini file:

php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 2M
php_value max_input_time 300

Also, set your time zone on the same file (for example, php_value date.timezone Europe/Rome).

Now, it's time to start up Apache, but before this, we need to check whether we have SELinux enabled and on which mode? To check your SELinux status, you can run:

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 24
Policy from config file:        targeted

Now, you need to check whether you have the httpd daemon enabled to use the network with the following command:

# getsebool httpd_can_network_connect
httpd_can_network_connect --> off

Most likely, you will have the same kind of result, then all we need to do is enable the httpd_can_network_connect option using the next command with –P to preserve the value after a reboot:

# setsebool –P httpd_can_network_connect on
# getsebool httpd_can_network_connect
httpd_can_network_connect --> on 

Now, all that we still have to do is enable the httpd daemon and start our httpd server:

# service httpd start
Starting httpd:                              [  OK  ]

Next, enable the httpd server as a service:

# chkconfig httpd on

We can check the change done with the next command:

# chkconfig --list httpd
httpd       0:off   1:off   2:on    3:on    4:on    5:on    6:off

Once you've done this, you only need to follow the wizard, and in a few clicks, you will have your web interface ready to start up.

Tip

If you know that the load against the web server will be high, due to a high number of accounts that will access it, probably, it's better to consider using Nginx.

Now, you can finally start your Zabbix server and the first entry in the /var/log/zabbix/zabbix_server.log file will look something like the following code:

37909:20140925:091128.868 Starting Zabbix Server. Zabbix 2.4.0 (revision 48953).
37909:20140925:091128.868 ****** Enabled features ******
 37909:20140925:091128.868 SNMP monitoring:           YES
 37909:20140925:091128.868 IPMI monitoring:           YES
 37909:20140925:091128.868 WEB monitoring:            YES
 37909:20140925:091128.868 VMware monitoring:         YES
 37909:20140925:091128.868 Jabber notifications:      YES
 37909:20140925:091128.868 Ez Texting notifications:  YES
 37909:20140925:091128.868 ODBC:                      YES
 37909:20140925:091128.868 SSH2 support:              YES
 37909:20140925:091128.868 IPv6 support:              YES
 37909:20140925:091128.868 ****************************** 37909:20140925:091128.868 using configuration file: /etc/zabbix/zabbix_server.conf******************************

Next, you can start to implement and acquire all the items critical for your network.

 

Summary


In this chapter, we covered a large number of components. We started with defining what a large environment is. We also saw how the network setup can be designed and how it can evolve within your infrastructure. We saw the heaviest task on the server side (housekeeping) and how to avoid performance degradation due to this. We discussed MySQL partitioning in-depth. We also briefly discussed the differences between active and passive proxies; you will now be able to decide how to set them up and which one to choose once you know your network topology. Also, we saw how to acquire some critical metrics to monitor the Zabbix proxy connection and the amount of items that it still needs to send us.

As you can see, we covered a lot of arguments in just one chapter; we did this because we would like to use more space in the upcoming chapters. In the next chapter, we will explore the different appliances and protocols at layer 2 and layer 3 of the ISO/OSI stack. Also, you will see how to best extrapolate meaningful monitoring data from the collected measure for the protocol layers 2 and 3.

About the Authors

  • Andrea Dalle Vacche

    Andrea Dalle Vacche is a highly skilled IT professional with over 15 years of industry experience.

    He graduated from Univeristà degli Studi di Ferrara with an information technology certification. This laid the technology foundation that Andrea has built on ever since. He has acquired various other industry-respected accreditations from big players in the IT industry, which include Cisco, Oracle, ITIL, and of course, Zabbix. He also has a Red Hat Certified Engineer certification. Throughout his career, he has worked on many large-scale environments, often in roles that have been very complex, on a consultant basis. This has further enhanced his growing skillset, adding to his practical knowledge base and concreting his appetite for theoretical technical studying.

    Andrea's love for Zabbix came from the time he spent in the Oracle world as a database administrator/developer. His time was mainly spent on reducing "ownership costs" with specialization in monitoring and automation. This is where he came across Zabbix and the technical and administrative flexibility that it offered. With this as a launch pad, Andrea was inspired to develop Orabbix, the first piece of open source software to monitor Oracle that is completely integrated with Zabbix. He has published a number of articles on Zabbix-related software, such as DBforBIX. His projects are publicly available on his website at http://www.smartmarmot.com.

    Currently, Andrea is working as a senior architect for a leading global investment bank in a very diverse and challenging environment. His involvement is very wide ranging, and he deals with many critical aspects of the Unix/Linux platforms and pays due diligence to the many different types of third-party software that are strategically aligned to the bank's technical roadmap.

    Andrea also plays a critical role within the extended management team for the security awareness of the bank, dealing with disciplines such as security, secrecy, standardization, auditing, regulator requirements, and security-oriented solutions.

    In addition to this book, he has also authored the following books:

    • Mastering Zabbix, Packt Publishing
    • Zabbix Network Monitoring Essentials, Packt Publishing

    Browse publications by this author
  • Stefano Kewan Lee

    Stefano Kewan Lee is an IT consultant with more than 12 years of experience in system integration, security, and administration. He is a certified Zabbix specialist in large environments holds a Linux administration certification from the LPI and a GIAC GCFW certification from SANS Institute. When he's not busy breaking websites, he lives in the countryside with his two cats and two dogs and practices martial arts. In addition to this title, Stefano Kewan Lee is a coauthor of Mastering Zabbix, Packt Publishing.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Good book, decently illustrated for its difficulty level.
Book Title
Access this book and the full library for just $5/m.
Start FREE trial