Templates are one of the most important architectural elements in a Zabbix environment.
They define how monitoring logic is reused across hosts and determine whether the platform remains manageable as the number of monitored systems grows.
A poorly designed template structure creates:
A well-designed template model provides:
Templates should therefore be treated as reusable monitoring components rather than collections of unrelated items.
A Zabbix template may contain:
When a template is linked to a host, its monitoring logic is inherited by that host.
Template
├── Items
├── Triggers
├── Discovery Rules
├── Graphs
├── Macros
└── Tags
│
▼
Host
This inheritance model allows administrators to manage monitoring behavior centrally.
A change made in one template can be applied to every linked host.
In a mature monitoring environment, templates should be treated similarly to application configuration or infrastructure code.
They should be:
A template is not merely a frontend object.
It represents executable monitoring logic that can:
Template changes should therefore be handled with the same discipline as firewall, backup or infrastructure configuration changes.
A good template architecture should satisfy several objectives.
The same template should be usable across multiple hosts with similar roles.
The same monitored condition should produce the same result on equivalent systems.
Templates should be divided into logical functions instead of combining all monitoring into one large object.
Thresholds and credentials should be configurable without editing template internals.
The number of linked hosts should not make template maintenance impractical.
Items and triggers should clearly describe what they monitor and why.
Templates should not generate excessive traffic, database writes or false alarms.
There are two common approaches to template design:
A monolithic template contains most or all monitoring logic for a host type.
Example:
Template Windows Server Complete
├── Operating system metrics
├── Disk monitoring
├── Service monitoring
├── Event log monitoring
├── SQL monitoring
├── Backup monitoring
├── Certificate monitoring
└── Application checks
This may appear convenient because only one template must be linked.
However, it creates several problems:
A large template may also contain hundreds or thousands of items that are irrelevant for many hosts.
A modular architecture separates monitoring by function.
Example:
Template OS Windows
Template App Microsoft SQL Server
Template Service Veeam Backup
Template Certificate Monitoring
Template Hardware Dell iDRAC
A database server may then receive:
Host: AACP-BUD-DB-01
Linked templates:
- Template OS Windows
- Template App Microsoft SQL Server
- Template Service Veeam Backup
- Template Certificate Monitoring
This design allows the same application template to be reused across multiple operating system or infrastructure roles.
A practical enterprise template model can be divided into several layers.
Host
├── Operating System Template
├── Hardware Template
├── Application Template
├── Service Template
├── Network Template
└── Organization-Specific Template
Each layer should have a clear responsibility.
Operating system templates monitor the base system.
Typical metrics include:
Examples:
Template OS Linux by Zabbix Agent 2
Template OS Windows by Zabbix Agent 2
Operating system templates should not normally contain application-specific monitoring.
A Windows template should not assume that every Windows host runs:
Hardware templates monitor physical infrastructure.
Examples include:
Typical monitored values include:
Hardware monitoring should remain separate from operating system monitoring because the data source and failure domain are different.
An operating system may appear healthy while the underlying hardware is reporting a predictive disk failure.
Application templates monitor specific software platforms.
Examples:
Template App PostgreSQL
Template App Microsoft SQL Server
Template App Nginx
Template App Apache
Template App Docker
Template App Redis
Template App MySQL
Application templates may monitor:
Application templates should monitor the application independently of the underlying operating system wherever possible.
Service templates monitor operational functions rather than software products.
Examples:
Template Service Backup Status
Template Service Certificate Expiration
Template Service DNS Resolution
Template Service SMTP Availability
Template Service File Synchronization
A service template may be linked to different host types.
For example, certificate monitoring may apply to:
This is why service templates should not be embedded unnecessarily into operating system templates.
Network templates monitor devices and communication services.
Examples:
Template Network MikroTik RouterOS
Template Network Cisco Switch
Template Network ICMP Availability
Template Network WAN Link
Template Network SNMP Interface Discovery
Network templates commonly use:
They should account for:
Some monitoring logic is unique to a business, customer or operational process.
Examples:
Template SARABEL Backup Compliance
Template AACP Application Health
Template Hotel PMS Service Monitoring
Template Customer SLA Monitoring
These templates may contain:
Organization-specific logic should remain separated from vendor templates.
This makes upgrades and troubleshooting easier.
Template names should indicate their purpose clearly.
A recommended naming pattern is:
Template <Category> <Technology or Function> <Method>
Examples:
Template OS Linux Agent 2
Template App PostgreSQL Agent 2
Template Network MikroTik SNMP
Template Service Certificate Expiration
Template Hardware Dell iDRAC
Possible categories include:
| Category | Purpose |
|---|---|
| OS | Operating system monitoring |
| App | Application monitoring |
| Network | Network device or protocol monitoring |
| Service | Operational service monitoring |
| Hardware | Physical hardware monitoring |
| Custom | Organization-specific monitoring |
Avoid vague names such as:
Template Server
Template Monitoring
Template New
Template Custom Final
Template Test 2
Zabbix provides official templates for many operating systems, applications and devices.
Vendor or official templates offer several advantages:
However, official templates should still be reviewed before production use.
They may:
Official templates should be treated as a baseline, not an unquestionable final configuration.
Avoid modifying official templates directly where possible.
Direct modification creates upgrade problems because future template imports may overwrite or conflict with local changes.
A better approach is to create a separate custom template.
Template OS Linux by Zabbix Agent
│
└── Template Custom Linux Baseline
The custom template may add:
This separates vendor-maintained logic from organization-specific logic.
Templates may be linked directly to hosts or to other templates.
Example template inheritance:
Template Custom Linux Production
├── Template OS Linux Agent 2
├── Template Service Backup
└── Template Service Certificate Monitoring
A host may then link only:
Template Custom Linux Production
This approach can simplify host onboarding.
However, excessive template inheritance may make troubleshooting difficult.
Administrators should be able to determine where each item or trigger originates.
Template inheritance should remain understandable.
A shallow structure is generally preferable:
Host
└── Role Template
├── OS Template
├── Application Template
└── Service Template
Avoid deeply nested chains:
Host
└── Template A
└── Template B
└── Template C
└── Template D
└── Template E
Deep inheritance creates problems when:
A role template combines several functional templates for a specific server role.
Example:
Template Role Windows SQL Server
├── Template OS Windows Agent 2
├── Template App Microsoft SQL Server
├── Template Service Backup
└── Template Service Certificate Monitoring
Role templates can simplify provisioning, but they should not duplicate the underlying monitoring logic.
Their purpose is orchestration, not implementation.
Items define the individual values collected by Zabbix.
Each item should have:
Example:
Name:
CPU utilization
Key:
system.cpu.util
Type:
Zabbix agent
Value type:
Numeric float
Units:
%
Item names should describe the value without requiring the administrator to interpret the key.
Good examples:
CPU utilization
Available memory
File system free space
Backup age
Certificate days remaining
WAN packet loss
Poor examples:
CPU
Value 1
Check
Status
Test metric
The item name should remain understandable in:
Item keys identify the collected metric.
Examples:
system.cpu.util
vm.memory.size[available]
vfs.fs.size[/,pfree]
net.if.in[eth0]
Custom item keys should use a structured naming convention.
Example:
sarabel.backup.status
sarabel.backup.age
sarabel.service.health
Avoid generic keys such as:
custom.check
script.value
test
Unique prefixes reduce the risk of conflicts.
Update intervals should reflect the operational importance and rate of change of the metric.
Example:
| Metric | Recommended interval |
|---|---|
| Critical service state | 30–60 seconds |
| CPU utilization | 60 seconds |
| Memory utilization | 60 seconds |
| Disk capacity | 5 minutes |
| Certificate expiration | 1–12 hours |
| Software inventory | 12–24 hours |
| Hardware serial number | 24 hours |
Shorter intervals are not automatically better.
Every collected value affects:
Some checks require different collection frequencies during specific periods.
Examples:
Intervals should be designed around operational needs rather than arbitrary defaults.
Each item may define how long detailed history and trend data are retained.
Detailed history supports:
Trend data supports:
Static or low-value items may not require long history retention.
Retention settings should align with the database capacity plan.
Dependent items extract multiple values from one master item.
Example:
Master item:
Application API status
Returned data:
{
"status": "healthy",
"connections": 42,
"queue": 3,
"errors": 0
}
Dependent items:
Application health
Active connections
Queue size
Error count
This model reduces:
Dependent items are strongly recommended for structured data sources such as:
Preprocessing transforms collected values before storage.
Common preprocessing methods include:
Example:
Raw value:
{"backup_age_seconds": 7200}
JSONPath:
$.backup_age_seconds
Stored value:
7200
Preprocessing should remain simple and predictable.
Complex JavaScript processing should be documented and tested carefully.
A preprocessing failure may cause an item to become unsupported.
Possible strategies include:
Failure handling should depend on the metric.
Returning 0 for missing data may create a false impression that a system is healthy.
Unknown and healthy are not equivalent states.
Triggers evaluate item values and define problem conditions.
A trigger should answer:
What operational condition requires attention?
Examples:
CPU utilization is critically high
Backup has not completed within the expected period
File system free space is below the minimum threshold
Network device is unavailable
Certificate expires within 14 days
Triggers should represent actionable conditions.
A trigger name should explain:
Good examples:
File system free space is below 10%
Latest backup is older than 24 hours
WAN interface packet loss exceeds 20%
PostgreSQL service is not running
Poor examples:
Disk problem
Backup error
High value
Warning
Critical issue
Problem names should be clear even when displayed outside the host context.
Trigger expressions should be:
Example:
CPU utilization exceeds 90% for 10 minutes
This is usually more useful than:
CPU utilization exceeds 90% once
Single-sample conditions often generate unstable alerts.
Thresholds should normally be defined using macros.
Example:
{$CPU.UTIL.CRIT}=90
{$DISK.FREE.WARN}=20
{$DISK.FREE.CRIT}=10
{$BACKUP.MAX.AGE}=86400
Benefits include:
Hard-coded thresholds reduce flexibility.
Context macros allow thresholds to vary by discovered entity.
Example:
{$FS.FREE.MIN:"/"}=15
{$FS.FREE.MIN:"/var"}=10
{$FS.FREE.MIN:"/backup"}=5
This allows different file systems to use different limits without duplicating triggers.
Context macros are particularly useful for:
Dependencies suppress secondary alarms when a root cause is already known.
Example:
Router unavailable
│
├── Switch unavailable
├── Server unavailable
└── Printer unavailable
Without dependencies, one network failure may generate dozens of alerts.
With dependencies:
Primary problem:
Router unavailable
Suppressed secondary symptoms:
Downstream devices unavailable
Dependencies should reflect real infrastructure relationships.
Incorrect dependencies may hide genuine problems.
Zabbix trigger severities should have documented operational meanings.
Example:
| Severity | Recommended interpretation |
|---|---|
| Not classified | Informational or uncategorized |
| Information | No immediate action required |
| Warning | Review required |
| Average | Service degradation |
| High | Major operational impact |
| Disaster | Critical business interruption |
Severity should reflect business impact, not technical interest.
A failed temperature sensor may be critical on one device and informational on another.
Some conditions require a separate recovery rule.
Example:
Problem:
Packet loss exceeds 20%
Recovery:
Packet loss remains below 5% for 5 minutes
Recovery hysteresis prevents repeated problem and recovery transitions around a single threshold.
It is useful for:
Triggers should add structured event tags.
Examples:
service=backup
component=database
scope=availability
customer=AACP
priority=critical
Event tags support:
Tagging strategy should remain consistent across templates.
Low-level discovery automatically identifies dynamic resources.
Examples:
A discovery rule creates entities from prototypes.
Discovery Rule
├── Item Prototypes
├── Trigger Prototypes
├── Graph Prototypes
└── Host Prototypes
Discovery allows one template to adapt to different hosts.
Discovery filters determine which entities should be monitored.
Example:
Discover:
- physical interfaces
- active interfaces
- production file systems
Exclude:
- loopback interfaces
- temporary mounts
- virtual adapters
- removable media
Unfiltered discovery can create large numbers of unnecessary objects.
Overrides modify discovery behavior for selected entities.
Examples:
Overrides reduce the need to clone templates for minor variations.
When a discovered entity disappears, Zabbix may:
This is important for environments with:
Deleting discovered objects too quickly may remove useful history.
Retaining them indefinitely may create clutter.
Value maps convert numeric or symbolic values into readable states.
Example:
0 → Down
1 → Up
2 → Degraded
3 → Unknown
Value maps improve:
They should be reused consistently across related templates.
Graphs provide visual context for collected metrics.
Useful graphs include:
Graphs should group related metrics.
Avoid graphs containing too many unrelated values.
A graph should answer a specific operational question.
Templates may provide dashboards that become available for linked hosts.
Example dashboard sections:
Host Overview
├── Availability
├── Performance
├── Capacity
├── Application Health
└── Recent Problems
Template dashboards improve consistency across similar hosts.
They should remain compact and role-specific.
Templates may include web scenarios for application monitoring.
A reusable web template may use macros:
{$WEB.URL}
{$WEB.USER}
{$WEB.PASSWORD}
{$WEB.EXPECTED.TEXT}
This allows the same scenario to monitor multiple applications.
Credentials should use secure macros.
Template macros define configurable defaults.
Example:
{$CPU.UTIL.CRIT}=90
{$MEMORY.AVAILABLE.MIN}=10
{$PING.LOSS.MAX}=20
{$CERT.EXPIRE.WARN}=30
Macro names should be:
Avoid:
{$LIMIT1}
{$VALUE}
{$TEST}
Every non-obvious macro should include a description.
Example:
Macro:
{$BACKUP.MAX.AGE}
Default:
86400
Description:
Maximum accepted backup age in seconds before a problem is generated.
This reduces configuration errors during host onboarding.
A host may override template defaults.
Example:
Template:
{$DISK.FREE.CRIT}=10
Host override:
{$DISK.FREE.CRIT}=5
Overrides should be used only when justified.
Excessive host-level customization makes the environment inconsistent.
When many hosts require the same override, create:
Templates should apply standard host or event tags where appropriate.
Examples:
monitoring_source=agent
technology=postgresql
category=database
Do not duplicate tags unnecessarily across multiple linked templates.
Conflicting values may complicate filtering and automation.
Templates may call custom scripts using:
Custom scripts should:
Scripts should be stored in version control.
User parameters extend Zabbix agent functionality.
Example:
UserParameter=sarabel.backup.status,/usr/local/bin/check-backup.sh
The corresponding item key:
sarabel.backup.status
User parameters should not execute arbitrary input.
Unsafe parameters may create command injection risks.
Templates should explicitly define whether items use:
Avoid mixing monitoring methods without a clear reason.
For remote systems behind NAT, active agent items are often preferable.
For internal servers with direct connectivity, passive checks may be easier to test.
Every template adds workload.
Before deploying a template widely, estimate:
Number of hosts
×
Number of enabled items
÷
Average update interval
A template with 200 items linked to 500 hosts creates:
100,000 monitored items
At a 60-second average interval:
Approximately 1,667 values per second
This does not include:
Do not collect data only because it is technically available.
Each item should support:
Examples of low-value collection:
Monitoring should optimize signal, not volume.
Templates should be tested for unsupported items before broad deployment.
Common causes include:
Unsupported items should not be ignored.
They may indicate:
Every new or modified template should be tested on a limited number of hosts.
Recommended test stages:
Development
→ Laboratory
→ Pilot Hosts
→ Limited Production
→ General Deployment
Validation should include:
Maintain one or more dedicated test hosts for template development.
Examples:
LAB-LNX-01
LAB-WIN-01
LAB-SNMP-01
LAB-APP-01
Test hosts reduce the risk of generating production alerts during development.
Templates should include version information.
Example:
Template version: 1.2.0
Maintainer: SARABEL Informatika
Last review: 2026-07-12
Compatible Zabbix version: 7.x
Versioning helps track:
A semantic model may be used:
MAJOR.MINOR.PATCH
Example:
2.1.3
Changes can be classified by risk.
Examples:
Examples:
Examples:
Major changes require broader testing.
Templates should be exported regularly.
Exports provide:
Common export formats include:
YAML is often suitable for human-readable version control.
A recommended repository structure:
templates/
├── operating-systems/
├── applications/
├── network/
├── hardware/
├── services/
├── custom/
└── archive/
Example:
templates/
├── operating-systems/
│ ├── linux-agent2.yaml
│ └── windows-agent2.yaml
├── network/
│ └── mikrotik-snmp.yaml
└── services/
└── backup-monitoring.yaml
Each template should include supporting documentation.
Template documentation should describe:
Example:
Template:
SARABEL Backup Monitoring
Purpose:
Validate backup completion and maximum backup age.
Required macro:
{$BACKUP.MAX.AGE}
Required item source:
Zabbix Sender or custom agent item
Default threshold:
24 hours
A template should be reviewed before production deployment.
Review areas include:
A second administrator should review high-impact templates where possible.
Template updates should follow a controlled process.
Recommended sequence:
Do not modify widely used templates directly in production without a rollback path.
Removing a template from a host requires careful consideration.
Two common actions are:
Removes the relationship while preserving inherited entities on the host.
Removes the template relationship and inherited configuration.
This may remove:
Use unlink and clear only when the effect is understood.
Template migration may be required when:
A migration plan should identify:
Running old and new templates in parallel temporarily may help validate the transition.
Zabbix does not allow duplicate item keys on the same host.
Duplicate keys may occur when:
Before linking templates, review overlapping items.
To reduce conflicts:
A template may work correctly alone but fail when linked with others.
Templates may contain sensitive or high-risk functionality.
Examples include:
Security controls should include:
Never commit real credentials into template exports.
Remote commands may support automation and remediation.
However, they introduce significant risk.
Examples:
Remote commands should require:
Monitoring should not automatically become unrestricted remote administration.
A production Windows application server may use:
Template Role Windows Application Server
├── Template OS Windows Agent 2
├── Template Service ICMP Availability
├── Template Service Backup Compliance
├── Template Service Certificate Expiration
└── Template Custom Application Health
A MikroTik router may use:
Template Role MikroTik Edge Router
├── Template Network MikroTik SNMP
├── Template Service ICMP Availability
├── Template Service WAN Monitoring
└── Template Custom Router Security
This provides standardization without creating one oversized template.
Templates
├── Operating Systems
│ ├── Linux Agent 2
│ └── Windows Agent 2
├── Applications
│ ├── PostgreSQL
│ ├── Microsoft SQL Server
│ └── Nginx
├── Network
│ ├── MikroTik SNMP
│ ├── Cisco SNMP
│ └── ICMP Availability
├── Services
│ ├── Backup Compliance
│ ├── Certificate Expiration
│ └── DNS Availability
├── Hardware
│ ├── Dell iDRAC
│ ├── HPE iLO
│ └── UPS SNMP
└── Roles
├── Linux Web Server
├── Windows Application Server
└── MikroTik Edge Router
Template governance defines who may:
A small organization may use a simple review process.
A larger environment may require:
Avoid the following:
For a scalable template environment:
Templates define the reusable monitoring logic of a Zabbix environment.
A strong template architecture provides:
Templates should be modular, documented, versioned and tested.
The next chapter explains how to design and implement reliable SNMP monitoring for network and infrastructure devices.