Learn Zabbix - Auto-registration & Discovery

#Introduction

In episode 5 you added hosts one by one, and episode 10 introduced the proxy for remote locations. But adding hundreds of hosts manually is work that shouldn't happen in a healthy team. Episode 11 teaches Zabbix to discover and register itself: discovery and auto-registration.

This time we cover two layers of automation. The first layer finds unrecognized devices on the network. The second layer registers new hosts with the right template without touching the frontend. Deeper still, low-level discovery (LLD) makes Zabbix adapt to changes inside hosts — a new disk appears, a new interface is detected, and items create themselves.

#Network Discovery

#The Discovery Rule Concept

A discovery rule scans network segments periodically to find new devices. Zabbix sends probes to an IP range and matches the results against configured services — for example an agent listening on port 10050, an SNMP device, or an ICMP ping response.

Discovery is created in the Data collection → Discovery menu. Each rule defines the IP range, the services checked, the interval, and how long results are kept.

#Discovery with SNMP, Agent, and IP Ranges

The three most commonly used services:

• Zabbix agent: probes port 10050 to find hosts with the agent installed.
• SNMP: SNMP v1, v2c, or v3 probes to find network devices.
• ICMP ping: finds live hosts within an IP range.

IP range:    192.168.1.1-254
Service:     Zabbix agent (port 10050)
Update interval: 1h

The discovery result is a list of found hosts that can be used by discovery actions to register hosts, link host groups, and attach templates automatically.

#Auto-registration Actions

#Connecting HostMetadata and Conditions

The HostMetadata concept from episode 5 comes back into play. When a new agent first contacts the server, this metadata is sent along with the hostname. An auto-registration action matches the metadata against conditions to decide how to treat the new host:

HostMetadata contains "system.uname:Linux" → Linux template
HostMetadata contains "k8s:worker"        → Kubernetes template

This mechanism enables a single deployment path for all host types: the provisioning team just installs an agent with the correct metadata, and Zabbix does the rest.

#Provisioning New Hosts Without the Frontend

When the action conditions are met, the server automatically runs the operations: create the host, link the host group, add the interface, and attach the template. Everything is recorded in the frontend and can be audited via the action log.

zabbix_sender -z 192.168.1.10 -p 10051 -s new-host-01 \
  -k zabbix.hostname -o "new-host-01"

The command zabbix_sender -z ... -p 10051 sends data as if it came from a new host — a practical trick to test the auto-registration flow without actually installing an agent.

#Low-level Discovery (LLD)

#LLD at the Template Level

Low-level discovery works inside templates: Zabbix runs a discovery process on one host, finds dynamic entities, then creates items, triggers, and graphs for each found entity. This is what lets the Linux template detect new filesystems without manual intervention.

LLD item prototypes use key patterns with {#MACRO}:

Key: vfs.fs.size[{#FSNAME},pfree]
Name: Free space on {#FSNAME}

{#FSNAME} is a macro replaced with the actual value from the discovery result — for example / or /var. With this pattern, one prototype produces one item per filesystem.

#JSON Macros in LLD Results

The discovery result is a JSON document containing macros. Example result for a network interface:

{
  "data": [
    { "{#IFNAME}": "eth0", "{#IFTYPE}": 1 },
    { "{#IFNAME}": "lo", "{#IFTYPE}": 1 }
  ]
}

The combination of {#IFNAME} and {#IFTYPE} gives Zabbix enough information to create one item per interface. Understanding this macro structure is the key to building custom LLD.

#Custom LLD

LLD isn't limited to what Zabbix ships. You can create custom LLD: a script or agent item returns JSON in the discovery format, and Zabbix turns it into items. This pattern is often used for application-specific service discovery. Here's the simplest example — a script returning a list of containers:

{"data":[{"{#NAME}":"nginx"},{"{#NAME}":"postgres"}]}

#Combining All Three

These three mechanisms work together as a single provisioning pipeline:

network discovery → find devices → auto-registration → template
new host arrives → active agent → metadata → auto-registration → template
active template → LLD → filesystem/interface/disk → item + trigger

Discovery finds the outside world, auto-registration registers hosts, and LLD keeps hosts current from within. At the scale of hundreds of hosts, this pipeline is the difference between a Zabbix that is managed and a Zabbix that manages itself.

#Closing

Episode 11 automated the host lifecycle: network discovery finds new devices, auto-registration with HostMetadata registers and configures hosts, and LLD makes items follow changes inside hosts via JSON macros.

Key takeaways:

• Network discovery scans IP ranges and services to find new hosts.
• Auto-registration matches metadata against conditions and provisions hosts.
• LLD creates items per dynamic entity such as filesystems and interfaces.
• Macros like {#FSNAME} connect prototypes with JSON discovery results.
• Custom LLD extends discovery to applications and containers.

In the next episode 12 we'll discuss data management: history, trends, and housekeeper — the difference between raw data and hourly aggregation, retention settings, and TimescaleDB partitioning to store large-scale data efficiently.