Zabbix

## The item: Zabbix's unit of collection Everything Zabbix stores starts as an **item**. An item belongs to exactly one host and is defined by four things: a **key** naming what to collect (`agent.ping`, `system.cpu.load[all,avg1]`, `vfs.fs.size[/,pfree]`, `net.if.in[eth0]`), a **type** saying who produces the value, a **value type** (numeric unsigned, numeric float, character, log or text) deciding how it is stored, and an **update interval**. The key is not free text: its name and bracketed parameters together identify the item on the host, which is how "free space on `/`" and "free space on `/var`" coexist as two separate items. Each value the item yields is written to **history** with a timestamp, and Zabbix separately keeps **trends** — hourly minimum, average, maximum and count per item — so a year-long graph does not have to read raw history. Nothing alerts on an item directly; triggers are configured separately and read the item's history. The item **type** is where the collection mechanism is chosen, and the list is long: Zabbix agent, Zabbix agent (active), SNMP agent, Zabbix trapper, simple check, external check, database monitor, HTTP agent, calculated, dependent item and more. The two that matter for the agent are the first two — and note that passive versus active is a property of the **item type**, not of which agent binary is installed. ## Passive checks: the server asks An item of type **Zabbix agent** is passive. On each update interval a poller process on the Zabbix server or proxy opens a TCP connection to the agent's listening port, **10050**, sends the item key, reads one value back and closes. Two things follow. First, the Zabbix server needs a route to every agent and inbound firewall permission to 10050 on each one. Second, the agent's `Server` configuration parameter is an allow-list of addresses permitted to ask; a request from anywhere else is refused. You can reproduce exactly what the server does with the `zabbix_get` command-line tool, which is the fastest way to prove that a failing item is a network or permission problem rather than a configuration problem in the frontend. ## Active checks: the agent tells An item of type **Zabbix agent (active)** inverts the direction. The agent periodically contacts the address in its `ServerActive` parameter — the Zabbix server or proxy on port **10051** — and asks which active items are configured for the host named in its `Hostname` parameter. The server replies with the list and the intervals, the agent collects on its own schedule, and it pushes accumulated values back to 10051 in batches. Three consequences of that design: 1. **The agent must identify itself.** The `Hostname` in the agent's configuration has to match the host name configured in Zabbix, or the server has no list to hand back and the items never start. This is the most common active-check failure by a wide margin. 2. **The agent holds state.** Because it drives its own schedule it can buffer values locally when the server is unreachable and send them on reconnect, and it can remember a read position in a file — which is why log-file items (`log[]`, `logrt[]`) exist only as active checks. 3. **Configuration changes are not instant.** The agent re-fetches its list on the interval set by `RefreshActiveChecks`, so a newly added active item starts collecting after that delay rather than the moment it is saved. ## Which one survives the network | | Passive (Zabbix agent) | Active (Zabbix agent (active)) | |---|---|---| | Who opens the connection | server or proxy to agent | agent to server or proxy | | Port used | agent's 10050 | server's 10051 | | Firewall requirement | inbound to every host | outbound from every host | | When the link drops | the value is simply missed | agent buffers, sends on reconnect | | Who owns the schedule | the server | the agent | | Cost on the server | a poller occupied per check | batched, cheaper per value | **A firewall that permits outbound connections only leaves active checks as the only option.** That is the everyday case for hosts in a DMZ, in a customer's network, or behind NAT with no reachable address: you cannot connect *to* them, so you let them connect to you. The trade is that you lose the liveness signal a passive check gives away for free — a refused or timed-out connection is itself information — and you have to detect silence explicitly instead. ## Practical consequences Mixing the two on one host is normal and usually right. Keep a cheap availability item passive so the server sees a connection failure the moment the host stops answering, and push everything voluminous — per-filesystem, per-interface, log monitoring — to active so the collection cost sits on the monitored host rather than on a poller. At fleet scale the balance shifts further toward active, because a passive check occupies a server process for the whole round trip while an active one arrives pre-batched and needs only to be accepted. Two operational habits follow. Because active agents choose when to speak, a dead agent looks identical to one with nothing to say unless you monitor for absence deliberately. And because `Hostname` is the join key, renaming a host in the frontend silently breaks its active collection until the agent config matches again.