This episode dissects the Zabbix architecture thoroughly: Zabbix Server, Agent, Proxy, Frontend, Database, and API. You will also understand the data flow from collection to notification, and the difference between active and passive collection modes.

Episode 1 explained why Zabbix exists. Episode 2 answers how it works — a question more fundamental than you might think. Before adding your first host, you need to understand the six architectural components and how data flows between them.
Treat this episode as an architectural map. Every term you learn here — item, trigger, event, action, proxy — will be used continuously through episode 22. Take your time, understand the flow, and all the following episodes will feel like assembling Lego blocks you already know.
Zabbix Server is the brain of everything. The server is responsible for collecting data from agents and pollers, processing raw data into history and trends, trigger evaluation, and alerting. The server reads all configuration from the database and runs hundreds of worker processes whose names are configured in zabbix_server.conf — such as poller, trapper, and housekeeper.
Zabbix Agent is the endpoint installed on the monitored host. The agent runs items, measures values inside the host, and sends the results to the server. There are two generations:
Since episode 0 we've been using agent2, and this whole series follows that choice. We'll dissect the zabbix_agent2.conf configuration in episode 4.
Zabbix Proxy is the server's extension arm for remote environments. The proxy collects data on behalf of the server at distant locations, stores it temporarily, then forwards it to the server. This reduces network load and enables monitoring through firewalls. Full details on the proxy are in episode 10.
Zabbix Frontend is the PHP-based web interface that is the face of Zabbix — where you manage hosts, view dashboards, and read reports. The Database (MySQL or PostgreSQL) stores all configuration and metric data. Zabbix API is the JSON-RPC interface at /api_jsonrpc.php that enables full automation, which we'll cover in episode 14.
Zabbix Frontend (Web UI) + Zabbix API
│
Zabbix Server ─────────────── Database (MySQL/PostgreSQL)
│
┌────┴────┐
Agent/Agent2 Proxy (remote location)The data flow begins when metric values are collected. There are two main paths to the server:
Values received by the server become history (raw data per second interval) and are aggregated into trends (hourly averages). We'll cover history and trends in episode 12. From here, the frontend reads the database to display graphs and dashboards.
This is the heart of Zabbix monitoring logic — a five-stage chain:
item → trigger → event → action → notificationAn item defines what is measured. A trigger evaluates item values against a condition, for example avg CPU above 90 percent. When the condition is met, the trigger changes state and generates a problem event. An action responds to the event with operations — sending a message, running a remote command, or escalating. Finally, the notification is sent through a media type such as email or Telegram. We'll dissect each stage starting from episode 6.
A fundamental difference you must master right now:
systemctl status zabbix-server
systemctl status zabbix-agent2The command systemctl status zabbix-agent2 shows the status of the agent2 installed in episode 0. If both services are active (running), your basic architecture is alive.
Before moving on, get to know the three most basic objects:
system.cpu.util for CPU usage.A host can have hundreds of items, and each item produces values periodically according to its interval. The combination of hosts and items is what determines the database size — an important consideration in episodes 12 and 17.
A template is a reusable configuration package: a collection of items, triggers, and actions defined once, then linked to many hosts. Instead of manually creating 50 items for 100 hosts, you create one template and link it. The template concept will be a major theme in episodes 5 and 18.
Tip
Adopt a template mindset from the start. Hosts monitored via templates are far easier to manage, because a change only needs to be made in one place and it propagates to every host linked to it.
Episode 2 gave you the architectural foundation: six interconnected Zabbix components, the data flow from collection to storage, the item-to-notification chain, and the difference between active and passive collection modes. With this, you're ready to understand every feature to come.
Key takeaways:
item → trigger → event → action → notification.In the next episode 3 we'll discuss all-in-one server installation and configuration — MySQL database initialization, schema import, zabbix_server.conf configuration, and completing the frontend setup wizard. By the end of episode 3, you'll have a genuinely live Zabbix server ready to be monitored.