IT organizations rely on monitoring data for immediate feedback about the status of operations and to discover...
faults within the infrastructure. Over time, it also helps optimize IT operations and informs long-term planning. The Zabbix approach to this vital task focuses on flexibility.
Zabbix is an open source option for enterprise IT infrastructure monitoring, capable of both agentless and agent-based operation. It tracks data on a range of components and supplies an API that enables third-party software integration for better extensibility and programmatic access to Zabbix monitoring features and data.
The tool's many options mean that users should research how it works, its five components and what they want to monitor before attempting to deploy Zabbix.
Zabbix monitoring coverage
Zabbix monitoring is distributed, meaning the load is spread across the environment, with centralized administration. Zabbix uses five basic components: a server, agents, a database, a front end and a proxy. A Zabbix server is a central repository and a means to configure, collect and organize metrics. A corresponding database, such as Oracle or MySQL, stores and sorts the collected data from agents. The front end is provided through a web interface, for local or remote management. The front end often runs on the same hardware that supports the Zabbix server. A proxy operates in place of the Zabbix server, distributing the monitoring workload.
The tool automatically discovers hundreds of thousands of devices across the infrastructure: servers and other hardware devices, networks and network devices, and applications and services. It finds processors and cores, file systems, Windows services, network interfaces and Simple Network Management Protocol (SNMP) object identifiers by default, and administrators can create custom items, triggers and graphs for other desired devices or services.
Zabbix collects and reports metrics via several mechanisms. Agentless monitoring checks an array of standard services, such as Simple Mail Transfer Protocol. Zabbix also supports agentless monitoring over existing checking mechanisms, including SNMP, Intelligent Platform Management Interface and other common device and communication protocols. Zabbix gathers a significant amount of detail about heterogeneous devices, software and services without agents by default.
Zabbix monitoring also occurs through agents, which collect and report detailed information from a given system. For example, a user can install an agent on specific Unix and Windows systems to monitor processor and storage utilization, as well as network traffic levels.
Zabbix supports data collection through polling and trapping. When polling, which is a pull setup, Zabbix makes periodic requests for information from devices. Trapping means that devices send information -- a push approach -- to the Zabbix monitoring software when certain conditions are met. Reporting occurs via consoles, dashboards and direct notifications and can include a business-level view of monitored resources, as well as service-level agreement (SLA) and key performance indicator tracking for tactical users.
Make Zabbix monitoring part of a toolchain
With a web-based API based on the JSON-RPC 2.0 protocol, Zabbix integrates with other software tools or even with new software that developers create to work with it. Teams can also use the API to automate many of the routine tasks that Zabbix performs. The API in Zabbix 3.4 offers four different functional categories: monitoring, configuration, administration and API information. The monitoring category provides functions that handle history, trends, events, problems and service monitoring. By comparison, the configuration category offers functions that control hosts and host groups, items and applications, triggers, graphs, templates, imports, exports, discovery, actions and alerts, dashboards and more.
Setup and performance
Zabbix is designed for monitoring flexibility, and it supports a range of hosts, metrics (called items), triggers and services. However, not all such entities are automatically detected or monitored by default, so administrators need to do some legwork to create the Zabbix monitoring setup they want.
For example, Zabbix supports myriad hosts, where a host can be a server, VM, application, network device (such as a switch) or another item. The administrator needs to create hosts and give them names, groups and other details. Zabbix reports on the communication status of each host and displays host communication errors.
Similarly, Zabbix reports on diverse metrics, but administrators might need to create and configure those metrics for each host. Items are the desired data points that Zabbix gathers. Administrators can define a desired item associated with a specific host and set how that data is displayed and its storage period, among other details. After a significant amount of time has passed, administrators can use Zabbix monitoring data to visualize trends.
Zabbix users typically apply triggers, which set thresholds and actions to incoming items. Triggers define the level of acceptable metrics. If the levels exceed the trigger point, a problem state alerts administrators to potential issues.
Zabbix service monitoring enables a hierarchical view of the available elements of the infrastructure. Service monitoring shows the availability of certain parts of the environment, SLA adherence and other business-oriented information. The hierarchy is assembled using a parent/child approach, and services can be set with a status calculation, acceptable SLA percentage and other controls.
Zabbix requires experience and expertise in order to configure and manage the many hosts, metrics, triggers and services involved throughout the infrastructure. Changes in the infrastructure usually need to be reflected in the Zabbix configuration, so it may be necessary to add Zabbix management to the enterprise change management process.