Zabbix provides many ways to monitor different aspects of your IT infrastructure and indeed, almost anything one might want to hook to it. It can be characterized as a semi-distributed monitoring system with centralized management. While many installations have a single central database, it is possible to use distributed monitoring with nodes and proxies, and most installations will use Zabbix agents.
So what features does Zabbix provide? They are:
Centralized, easy to use web interface
Server that runs on most Unix-like operating systems, including Linux, AIX, FreeBSD, OpenBSD, and Solaris
Native agents for most Unix-like operating systems and Microsoft Windows versions
Ability to directly monitor SNMP (v1, 2, and 3) and IPMI devices
Built-in graphing and other visualization capabilities
Notifications that allow for easy integration with other systems
Flexible configuration, including templating
And a lot of other features that would allow you to implement a sophisticated monitoring solution
If we look at a simplified network from the Zabbix perspective, placing Zabbix server at the center, the communication of the various monitoring aspects matters. The following image depicts a relatively simple Zabbix setup with several of the monitoring capabilities used and different device categories connected.
Our central object is the Zabbix database, with several backends supported. Zabbix server, written in C, and web frontend written in PHP, can both reside on the same machine or on another server. When running each component on a separate machine, both the Zabbix server and the frontend need access to the database, and frontend optionally needs access to Zabbix server to show server status. Required connection directions are depicted by arrows in the following image.
Zabbix server directly monitors multiple devices, but a remote location is separated by a firewall, so it gathers data through a Zabbix proxy. Zabbix proxy and agents, just like the server, are written in C.
While it is perfectly fine to run all three server components on a single machine, there might be good reasons to separate them, like taking advantage of an existing high performance database or web server.
In general, monitored devices have little control over what is monitored most of the configuration is centralized. Such an approach seriously reduces the capabilities of single misconfigured system to bring down the whole monitoring setup.