Zabbix Reference Card

From Bitbull Wiki
Jump to navigation Jump to search

1 Setup

If you takte Zabbix for production monitoring it is strongly adviced to use one of this operating systems:

Install Requirements
Upgrade Zabbix
Security Best Practice
Known Issues

1.1 Sizing

Name Platform CPU/Memory Database Monitored hosts
Small CentOS Virtual Appliance MySQL InnoDB 100
Medium CentOS 2 CPU cores/2GB MySQL InnoDB 500
Large RedHat Enterprise Linux 4 CPU cores/8GB RAID10 MySQL InnoDB or PostgreSQL >1000
Very large RedHat Enterprise Linux 8 CPU cores/16GB Fast RAID10 MySQL InnoDB or PostgreSQL >10000

2 Architecture Components

2.1 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.

2.2 Database storage

All configuration information as well as the data gathered by Zabbix is stored in a database.

2.3 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.

2.4 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.

2.5 Agent

Zabbix agents are deployed on monitoring targets to actively monitor local resources and applications and report the gathered data to Zabbix server.

2.6 Data flow

  • Host > Item > trigger > action
  • Host > Template > action

Lets say that you want to receive an alert that your CPU load it 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.