Learn Zabbix - Agent Deployment & Active/Passive Monitoring

#Introduction

Your Zabbix server came to life in episode 3. But a server without agents is like ears without sound — there's nothing to collect. Episode 4 connects the two: you'll install agent2 on the target host, configure its config file, and test whether the server can actually pull values from the host.

This is also the episode where the active versus passive concept from episode 2 becomes real. You'll see with your own eyes the difference in connection direction between the two modes, and learn the diagnostic tools zabbix_get and zabbix_sender that will accompany you throughout your career as a monitoring engineer.

#Installing Agent2 on the Target Host

#Adding the Repository and Installing

The first step is the same as in episode 0, but performed on the target host. Add the official repository, then install the agent2 package:

wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb
dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb
apt update
apt install -y zabbix-agent2

Make sure you run this on the host to be monitored, not on the server. After installation, agent2 doesn't yet know where to send data — that's the job of zabbix_agent2.conf.

#Legacy Agent versus Agent2

Before configuring, get to know the differences between the two agent generations:

• zabbix-agent (legacy): stable and simple, written in C, one process for all tasks.
• zabbix-agent2: the new generation with a plugin-based architecture, lighter memory footprint, and built-in plugins for PostgreSQL, Redis, and more.

For new installations, Zabbix recommends agent2. Additional plugins can be loaded without overhauling the core configuration — an advantage we'll use in episode 18 for custom checks.

#Configuring zabbix_agent2.conf

#Core Parameters: Server, ServerActive, and Hostname

The agent2 config file lives at /etc/zabbix/zabbix_agent2.conf. Three mandatory parameters need adjusting:

Server=192.168.1.10
ServerActive=192.168.1.10
Hostname=host-target-01

• Server: the list of server or proxy addresses allowed to request passive data — port 10050.
• ServerActive: the address of the server or proxy that the agent will contact for active mode — port 10051.
• Hostname: the agent's unique name. It must exactly match the host name in the Zabbix frontend; otherwise, the data won't match.

systemctl restart zabbix-agent2
systemctl enable zabbix-agent2

After restarting, agent2 reads the new configuration. If Server contains the server address and Hostname matches the host in the frontend, the passive connection works right away.

#Plugins and Additional Parameters

Agent2 loads plugins via the Plugins.* parameters in the same file. For example, the agent2 memory plugin can be configured in the same block. Verify the active plugins:

zabbix_agent2 --print Plugins.*

The command zabbix_agent2 --print Plugins.* lists the loaded plugins and their status. If you see the plugins you need, agent2 is ready to use.

#Understanding Active and Passive Checks

#Passive Check: The Server Pulls

In passive mode, the server or proxy contacts the agent on port 10050 and requests a key value. The agent executes the key and answers. Advantage: data arrives immediately. Disadvantage: the server must be able to reach the agent — a problem in environments that block this connection direction.

#Active Check: The Agent Pushes

In active mode, the agent contacts the server on port 10051 periodically, fetches its active item list, then sends values according to the interval. Advantage: it only needs an outbound connection from the agent — very firewall-friendly. Disadvantage: the minimum interval is bounded by the agent refresh configuration.

For environments with many hosts and strict NAT, active mode is the primary choice. We'll revisit this trade-off when discussing the proxy in episode 10.

#Testing with zabbix_get and zabbix_sender

#zabbix_get: Testing the Passive Check

zabbix_get is a tool for manually pulling a value from an agent — an exact simulation of a passive check. Run it from the server:

zabbix_get -s 192.168.1.20 -k system.cpu.util[,idle]

The command zabbix_get -s ... -k system.cpu.util[,idle] requests the CPU idle value from the agent at 192.168.1.20. If you get a number like 73.5, the passive check works. If it times out, check port 10050 and the Server parameter in the agent.

#zabbix_sender: Testing the Active Check

zabbix_sender is the opposite: it sends values to the server manually — a simulation of an active check, and also the foundation for custom checks in episode 18.

zabbix_sender -z 192.168.1.10 -p 10051 -s "host-target-01" -k "custom.check" -o "42"

The command zabbix_sender -z ... -s host-target-01 -k custom.check -o 42 sends the value 42 for the key custom.check belonging to that host. An output of processed: 1; failed: 0 means the server accepted the value. To see it in the frontend, the host must have an item with the same key — we'll cover item details in episode 6.

#Closing

Episode 4 connected the server to the real world: agent2 is installed on the target host, zabbix_agent2.conf is configured, the difference between active and passive checks is understood, and collection can be tested with zabbix_get and zabbix_sender.

Key takeaways:

• Agent2 is the new generation with a plugin-based architecture, the choice for new installations.
• Server, ServerActive, and Hostname are the three core agent2 parameters.
• Passive checks are pulled by the server; active checks are pushed by the agent — the connection directions differ.
• zabbix_get tests passive checks; zabbix_sender tests active checks.
• The agent's Hostname must exactly match the host name in the frontend.

In the next episode 5 we'll discuss hosts, host groups, and templates — how to add hosts in the frontend, link them to host groups, and leverage the template library so hundreds of items and triggers are installed automatically with a single click.