Hosts are the central objects of a Zabbix monitoring environment.
A host represents any monitored entity, including:
Effective host management requires more than creating individual objects.
A scalable design must also define:
Each host contains the configuration required for Zabbix to collect and interpret monitoring data.
A typical host configuration includes:
Host
├── Host name
├── Visible name
├── Host groups
├── Interfaces
├── Templates
├── Tags
├── Macros
├── Inventory
├── Proxy assignment
├── Encryption settings
└── Monitoring status
The design should remain consistent across all environments.
Inconsistent host configuration leads to:
The host name is the primary technical identifier used by Zabbix.
It should be:
A recommended naming format is:
CUSTOMER-SITE-ROLE-NUMBER
Examples:
SAR-BUD-ZBX-01
SAR-BUD-PVE-01
SAR-BUD-FW-01
AACP-BUD-SRV-01
AACP-BUD-SW-01
HOTEL-GYR-AP-03
Possible naming components:
| Component | Example | Meaning |
|---|---|---|
| Customer | AACP | Customer or organization |
| Site | BUD | Physical location |
| Role | SRV | Server role |
| Number | 01 | Sequence number |
Example role abbreviations:
| Device type | Code |
|---|---|
| Zabbix Server | ZBX |
| Zabbix Proxy | ZXP |
| Physical Server | SRV |
| Virtual Machine | VM |
| Domain Controller | DC |
| File Server | FS |
| Terminal Server | TS |
| Hypervisor | HV |
| Proxmox Host | PVE |
| Router | RTR |
| Firewall | FW |
| Switch | SW |
| Wireless Access Point | AP |
| Network Attached Storage | NAS |
| Uninterruptible Power Supply | UPS |
| Printer | PRN |
| Database Server | DB |
| Web Server | WEB |
| Application Server | APP |
The abbreviations should be documented and reused consistently.
Zabbix distinguishes between:
The host name is the internal technical identifier.
Example:
AACP-BUD-SRV-01
It is used by:
The visible name is displayed in the frontend.
Example:
AACP Primary Application Server
The visible name may be more descriptive than the host name.
Recommended configuration:
Host name: AACP-BUD-SRV-01
Visible name: AACP Primary Application Server
The host name should remain stable even if the server function changes slightly.
Avoid host names such as:
Server
Server1
NewServer
MikroTik
MainPC
NAS
Switch
Test
Temp
These names do not identify:
Ambiguous names create operational problems when multiple sites or customers are monitored.
Navigate to:
Data collection
→ Hosts
→ Create host
Configure the basic fields.
Example:
Host name: AACP-BUD-SRV-01
Visible name: AACP Application Server
Assign at least one host group.
Example:
Customers/AACP/Servers
Operating Systems/Windows
Sites/Budapest
Add the appropriate interface and templates.
Save the host.
Host groups organize hosts according to operational, technical or administrative boundaries.
Host groups are used for:
A host may belong to multiple groups.
A hierarchical naming model improves clarity.
Example:
Customers
├── AACP
│ ├── Servers
│ ├── Network
│ ├── Workstations
│ ├── Applications
│ └── Infrastructure
├── Customer-B
│ ├── Servers
│ └── Network
└── Customer-C
├── Servers
└── Network
Additional technical groups:
Operating Systems
├── Linux
├── Windows
└── Network Devices
Infrastructure
├── Zabbix Servers
├── Zabbix Proxies
├── Hypervisors
├── Storage
└── Backup Systems
Sites
├── Budapest
├── Győr
├── Debrecen
└── Remote
A host group should represent a useful operational boundary.
Good examples:
Customers/AACP/Servers
Customers/AACP/Network
Sites/Budapest
Operating Systems/Linux
Infrastructure/Proxmox
Poor examples:
Important
New
Old
Temporary
Other
Miscellaneous
Avoid creating groups without a clear long-term purpose.
Interfaces define how Zabbix reaches a monitored host.
Supported interface types include:
A host can have multiple interfaces.
Example:
Agent interface:
192.168.10.20
TCP 10050
SNMP interface:
192.168.10.1
UDP 161
The agent interface is used for passive Zabbix agent checks.
Example:
Type: Agent
Connect to: IP
IP address: 192.168.10.20
Port: 10050
Default: Yes
The server or proxy must be able to reach the configured address.
Test connectivity:
nc -zv 192.168.10.20 10050
Using Zabbix Get:
zabbix_get -s 192.168.10.20 -k agent.ping
Expected output:
1
A host interface may use:
Example DNS interface:
Connect to: DNS
DNS name: server01.example.local
Port: 10050
DNS resolution must work from the Zabbix server or assigned proxy.
Test:
getent hosts server01.example.local
The SNMP interface is used for SNMP polling.
Example:
Type: SNMP
IP address: 192.168.10.1
Port: 161
Default: Yes
Test SNMP connectivity:
snmpwalk -v2c \
-c COMMUNITY_STRING \
192.168.10.1 \
1.3.6.1.2.1.1
For SNMPv3:
snmpwalk -v3 \
-l authPriv \
-u zabbix \
-a SHA \
-A AUTH_PASSWORD \
-x AES \
-X PRIVACY_PASSWORD \
192.168.10.1 \
1.3.6.1.2.1.1
SNMPv3 is recommended where supported.
A host may require more than one interface.
Example MikroTik router:
SNMP interface:
192.168.10.1
UDP 161
Agent interface:
Not configured
Example Linux server with IPMI:
Agent interface:
192.168.10.20
TCP 10050
IPMI interface:
192.168.20.20
UDP 623
Example Java application server:
Agent interface:
192.168.10.30
TCP 10050
JMX interface:
192.168.10.30
TCP 12345
Each interface should exist only if it is actively used.
When multiple interfaces of the same type exist, one must be marked as default.
Example:
Agent interface 1:
192.168.10.20
Default: Yes
Agent interface 2:
10.10.10.20
Default: No
Items without an explicitly selected interface use the default interface.
Incorrect default selection can cause monitoring failures.
A Zabbix host may be:
Zabbix collects data and evaluates triggers.
Zabbix does not poll the host or process new item values.
Use disabled status when:
Do not disable hosts merely to suppress expected alarms.
Use maintenance mode instead.
Templates contain reusable monitoring configuration.
A host can inherit:
Example Windows server templates:
Windows by Zabbix agent
Microsoft SQL Server
Website certificate monitoring
Custom backup monitoring
Example MikroTik router templates:
MikroTik RouterOS by SNMP
ICMP Ping
Custom WAN Monitoring
Templates are covered in detail in the next chapter.
Navigate to the host configuration and select:
Templates
→ Link new templates
Search for the required template.
Example:
Linux by Zabbix agent
Add the template and save the host.
Inherited entities become visible in the host configuration.
A host inherits monitoring entities from linked templates.
Template
├── Items
├── Triggers
├── Graphs
└── Discovery Rules
│
▼
Host
Changes made to the template are applied to all linked hosts.
This reduces configuration duplication.
Zabbix provides two template removal options:
Removes the template relationship but leaves inherited entities on the host.
Removes the relationship and deletes the inherited entities.
Use Unlink and clear carefully.
It may remove:
Historical data behavior depends on the removed entities and database retention.
Macros store reusable configuration values.
Host-level macros apply only to a specific host.
Example:
{$SNMP_COMMUNITY}
{$AGENT.TIMEOUT}
{$BACKUP.MAX.AGE}
{$CPU.UTIL.MAX}
A host macro can override a template macro.
Example template macro:
{$CPU.UTIL.MAX}=90
Host-specific override:
{$CPU.UTIL.MAX}=95
This allows one host to use a different threshold without modifying the template.
Sensitive values should use protected macro types.
Examples:
Do not store secrets in:
Example secret macros:
{$SNMP.USER}
{$SNMP.AUTH.PASSWORD}
{$SNMP.PRIV.PASSWORD}
{$API.TOKEN}
Macros may be defined at multiple levels:
Global macro
│
▼
Template macro
│
▼
Host macro
More specific definitions override broader definitions.
A host-level macro normally overrides the same macro inherited from a template.
Example:
Global:
{$PING.LOSS.MAX}=20
Template:
{$PING.LOSS.MAX}=10
Host:
{$PING.LOSS.MAX}=5
The host uses:
5
Macro behavior should be documented to avoid unexpected trigger thresholds.
Tags attach structured metadata to hosts, items, triggers and events.
Examples:
customer=AACP
site=Budapest
environment=production
service=accounting
priority=high
owner=SARABEL
Tags are useful for:
Use a small, consistent tag vocabulary.
Example:
| Tag | Example value |
|---|---|
| customer | AACP |
| site | Budapest |
| environment | production |
| device_type | server |
| operating_system | Windows |
| service | file-server |
| priority | critical |
| owner | SARABEL |
Avoid inconsistent variants:
site=Budapest
location=BUD
office=Budapest
city=BP
Use one standard tag name.
Recommended rules:
Good examples:
environment=production
customer=AACP
priority=critical
Poor examples:
Environment=Prod
env=Live
priority=Very Important Server
notes=Password is admin123
Host inventory stores descriptive asset information.
Typical inventory fields include:
Inventory modes include:
In manual mode, administrators enter values directly.
Example:
Type: Virtual Server
Name: AACP Application Server
OS: Windows Server
Serial number: VM-AACP-001
Location: Budapest
Vendor: Microsoft
Manual inventory is useful for fields that cannot be collected automatically.
Automatic inventory values are populated by monitored items.
Example item configuration:
Item:
system.uname
Inventory field:
OS
Another example:
Item:
system.hw.serialnumber
Inventory field:
Serial number
Automatic inventory reduces manual administration.
However, it depends on:
At minimum, consider maintaining:
Name
Type
Model
Serial number
Asset tag
Operating system
Location
Vendor
Contact
Installation date
Hardware
Software
For network devices:
Device type
Model
Serial number
Firmware version
Management IP
Physical location
Rack position
Support expiration
A host may be monitored:
Example direct monitoring:
Monitored by: Server
Example proxy monitoring:
Monitored by: Proxy
Proxy: AACP-BUD-ZXP-01
The selected proxy performs:
Use a proxy when:
Example:
Central Zabbix Server
│
▼
AACP-BUD-ZXP-01
│
▼
AACP-BUD-SRV-01
Hosts at the same remote site should normally use the same local proxy.
Avoid configurations where:
Remote server → Proxy
Remote switch → Central server
Remote router → Different proxy
unless there is a documented technical reason.
Inconsistent proxy assignment complicates:
For passive checks, configure the monitored agent.
Linux Agent 2 example:
Server=192.168.10.20
Hostname=AACP-BUD-SRV-01
Windows Agent 2 example:
Server=192.168.10.20
Hostname=AACP-BUD-SRV-01
When using a proxy:
Server=192.168.20.10
Hostname=AACP-BUD-SRV-01
The Server parameter should contain the IP address of the Zabbix server or proxy allowed to query the agent.
For active checks:
ServerActive=192.168.10.20
Hostname=AACP-BUD-SRV-01
When using a proxy:
ServerActive=192.168.20.10
Hostname=AACP-BUD-SRV-01
The hostname must match the Zabbix frontend exactly.
Example mismatch:
Agent:
Hostname=AACP-SRV-01
Frontend:
AACP-BUD-SRV-01
This causes active checks to fail.
Zabbix agent and proxy communication may use:
Host encryption settings define:
A PSK-based host configuration includes:
Connections to host:
PSK
Connections from host:
PSK
PSK identity:
AACP-BUD-SRV-01
PSK:
Generated secret value
Generate a PSK on Linux:
openssl rand -hex 32
Example output:
a38f54f77f82c0183df4f7311234567890abcdef1234567890abcdef12345678
Store it securely:
mkdir -p /etc/zabbix/keys
chmod 700 /etc/zabbix/keys
Create the key file:
nano /etc/zabbix/keys/agent.psk
Set permissions:
chown zabbix:zabbix /etc/zabbix/keys/agent.psk
chmod 600 /etc/zabbix/keys/agent.psk
Example Agent 2 configuration:
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=AACP-BUD-SRV-01
TLSPSKFile=/etc/zabbix/keys/agent.psk
Restart the agent:
systemctl restart zabbix-agent2
Review logs:
journalctl -u zabbix-agent2 -n 100 --no-pager
The PSK identity and value must match the frontend host configuration.
The description field should contain operationally useful information.
Example:
Primary application server for AACP.
Services:
- RLB application
- PostgreSQL database
- File synchronization
Owner:
SARABEL Informatika
Backup:
Daily incremental backup
Weekly full backup
Maintenance window:
Sunday 20:00–22:00
Avoid placing sensitive credentials in descriptions.
Host-specific configuration should be used only when necessary.
Possible host-level entities include:
Where configuration is reusable, create a template instead.
Example:
Bad approach:
Create the same backup item manually on 30 hosts
Better approach:
Create one backup monitoring template
Link it to 30 hosts
Cloning is useful when creating similar devices.
Navigate to:
Data collection
→ Hosts
→ Select host
→ Clone
Review all cloned settings:
Do not save a clone without changing unique identifiers.
Common cloning errors include:
Mass update modifies multiple hosts simultaneously.
Navigate to:
Data collection
→ Hosts
→ Select hosts
→ Mass update
Possible changes include:
Mass updates should be used carefully.
A configuration error may affect hundreds of hosts.
Before applying:
Hosts can be imported from configuration files.
Supported import formats may include:
Navigate to:
Data collection
→ Hosts
→ Import
Import options control whether Zabbix should:
Review import rules before execution.
Incorrect deletion options may remove valid configuration.
Hosts can be exported for:
Navigate to:
Data collection
→ Hosts
→ Select hosts
→ Export
Exported configuration may include:
Sensitive information should be reviewed before committing exports to a repository.
The Zabbix API can automate host creation and updates.
Typical automation tasks include:
Example workflow:
Asset Management System
│
▼
Automation Script
│
▼
Zabbix API
│
▼
Host Created and Configured
API automation should enforce the same naming and tagging standards as manual administration.
Hosts may be created or identified through:
Discovered hosts should not remain unmanaged.
An automated workflow should assign:
Discovery is covered in a later chapter.
Active agents can autoregister with Zabbix.
Typical autoregistration metadata:
Host name
IP address
Agent metadata
Proxy
Example agent configuration:
ServerActive=192.168.10.20
Hostname=AACP-BUD-SRV-01
HostMetadata=windows-server
An autoregistration action can:
Autoregistration is useful for:
Every host should follow a defined lifecycle.
Example:
Planned
→ Deployed
→ Monitoring Enabled
→ Production
→ Maintenance
→ Decommissioned
→ Disabled
→ Removed
Lifecycle procedures should define:
Recommended onboarding process:
Do not delete a host immediately when a device is retired.
Recommended process:
Example tag:
lifecycle=decommissioned
Example description:
Decommissioned: 2026-07-12
Replacement: AACP-BUD-SRV-02
Approved by: Infrastructure Manager
A disabled host may be retained temporarily for:
Define a retention policy.
Example:
Disabled hosts retained for 90 days.
Configuration exported before deletion.
Without a policy, obsolete hosts accumulate and reduce administrative clarity.
Duplicate hosts may occur because of:
Indicators include:
Review duplicates regularly.
Cloned virtual machines require special attention.
Before starting the clone:
Example Agent 2 change:
Hostname=AACP-BUD-SRV-02
Restart:
systemctl restart zabbix-agent2
A cloned VM using the original hostname may send data to the wrong Zabbix host.
The frontend displays interface availability.
Possible states include:
Availability is tracked separately for:
An unavailable interface does not always mean the host is completely offline.
Example:
ICMP: Available
Agent: Unavailable
Possible causes:
From the server or proxy:
zabbix_get \
-s 192.168.10.20 \
-p 10050 \
-k agent.ping
Test hostname:
zabbix_get \
-s 192.168.10.20 \
-k system.hostname
Check the TCP port:
nc -zv 192.168.10.20 10050
If the TCP connection works but zabbix_get fails, review:
Server= configuration;On the monitored host, review the agent log.
Linux:
journalctl -u zabbix-agent2 -n 100 --no-pager
Windows:
C:\Program Files\Zabbix Agent 2\zabbix_agent2.log
Common errors:
host not found
no active checks
cannot connect to server
connection rejected
TLS handshake failed
Verify:
ServerActive=
Hostname=
TLSConnect=
TLSPSKIdentity=
TLSPSKFile=
Test device reachability:
ping -c 4 192.168.10.1
Test UDP port behavior where possible:
nmap -sU -p 161 192.168.10.1
Test SNMP directly:
snmpget \
-v2c \
-c COMMUNITY_STRING \
192.168.10.1 \
1.3.6.1.2.1.1.3.0
Expected result:
SNMPv2-MIB::sysUpTime.0
If testing works manually but not in Zabbix, verify:
Maintenance mode suppresses or controls problem generation during planned work.
Use maintenance for:
Do not disable hosts for normal maintenance.
Maintenance periods are covered in a later chapter.
Each host should have a defined owner.
Ownership may be stored using:
Example tags:
owner=SARABEL
support_team=infrastructure
customer=AACP
Ownership helps determine:
Hosts may be classified according to operational impact.
Example:
| Priority | Description |
|---|---|
| Critical | Business operation stops if unavailable |
| High | Major service degradation |
| Medium | Limited operational impact |
| Low | Non-critical or informational system |
Example tag:
priority=critical
Priority tags can control:
Separate production and non-production hosts using tags or groups.
Example:
environment=production
environment=test
environment=development
Do not rely only on host names such as:
TEST-SRV
A consistent environment tag is easier to use in:
Each host should include enough information for another administrator to understand its purpose.
Recommended documentation:
Purpose
Customer
Location
Owner
Primary services
Dependencies
Backup method
Maintenance window
Support contact
Replacement device
Special monitoring notes
Example description:
Purpose:
Primary file server for AACP.
Dependencies:
- MikroTik router
- Synology NAS
- UPS-01
Backup:
Daily Veeam incremental backup.
Weekly full backup on Sunday.
Monitoring:
Zabbix Agent 2 through AACP-BUD-ZXP-01.
Hosts should be reviewed regularly.
Recommended review frequency:
| Environment | Review interval |
|---|---|
| Critical infrastructure | Monthly |
| Production servers | Quarterly |
| Network devices | Quarterly |
| Workstations | Every 6–12 months |
| Disabled hosts | Monthly |
| Temporary hosts | Monthly |
Review:
Useful frontend filters include:
Hosts without templates
Disabled hosts
Hosts without interfaces
Hosts with unsupported items
Hosts without inventory
Hosts with duplicate visible names
Hosts assigned to the wrong proxy
Hosts without customer tags
The API may be used for more advanced audits.
Avoid the following:
When a host has no data, follow a structured process.
Confirm:
Host status: Enabled
Check:
Confirm the host is assigned to the expected server or proxy.
ping -c 4 <HOST_IP>
nc -zv <HOST_IP> 10050
Agent:
zabbix_get -s <HOST_IP> -k agent.ping
SNMP:
snmpget -v2c -c <COMMUNITY> <HOST_IP> 1.3.6.1.2.1.1.3.0
Confirm the required templates are linked.
Check credentials and thresholds.
Server:
tail -n 100 /var/log/zabbix/zabbix_server.log
Proxy:
tail -n 100 /var/log/zabbix/zabbix_proxy.log
Agent:
journalctl -u zabbix-agent2 -n 100 --no-pager
Example Windows application server:
Host name:
AACP-BUD-SRV-01
Visible name:
AACP Primary Application Server
Host groups:
Customers/AACP/Servers
Operating Systems/Windows
Sites/Budapest
Environment/Production
Agent interface:
192.168.10.20
TCP 10050
Monitored by:
AACP-BUD-ZXP-01
Templates:
Windows by Zabbix agent active
ICMP Ping
Veeam Backup Monitoring
Windows Security Monitoring
Tags:
customer=AACP
site=Budapest
environment=production
device_type=server
priority=critical
owner=SARABEL
Macros:
{$CPU.UTIL.MAX}=90
{$DISK.FREE.MIN}=15
{$BACKUP.MAX.AGE}=86400
Inventory:
Automatic
Encryption:
PSK
Example MikroTik router:
Host name:
AACP-BUD-FW-01
Visible name:
AACP Main MikroTik Router
Host groups:
Customers/AACP/Network
Network Devices/MikroTik
Sites/Budapest
Environment/Production
SNMP interface:
192.168.10.1
UDP 161
Monitored by:
AACP-BUD-ZXP-01
Templates:
MikroTik RouterOS by SNMP
ICMP Ping
WAN Availability Monitoring
Tags:
customer=AACP
site=Budapest
environment=production
device_type=firewall
vendor=MikroTik
priority=critical
owner=SARABEL
Macros:
{$SNMP.USER}=zabbix
{$SNMP.AUTH.PASSWORD}=Secret macro
{$SNMP.PRIV.PASSWORD}=Secret macro
Inventory:
Automatic and manually completed
Host management defines how monitored systems are identified, organized and maintained.
A scalable host management model requires:
The next chapter explains how to create, link and maintain reusable Zabbix templates.