A reliable monitoring platform is not defined only by the software installed on the monitoring server.
The complete architecture includes:
A properly designed architecture ensures that monitoring remains scalable, secure and maintainable as the infrastructure grows.
A typical Zabbix deployment consists of a central Zabbix server that collects, processes and stores monitoring data.
The monitored environment may include:
The following diagram represents a basic centralized monitoring architecture:
Administrators
│
▼
Zabbix Web Interface
│
▼
Zabbix Server
│
┌───────────┴───────────┐
│ │
▼ ▼
Zabbix Database Notification Systems
│ E-mail / SMS / Webhook
│
▼
Monitoring Data and History
▲
│
┌───────────────────────┼────────────────────────┐
│ │ │
▼ ▼ ▼
Zabbix Agents SNMP Devices Web Services
Windows / Linux Routers / Switches / UPS HTTP / HTTPS
│ │ │
└───────────────────────┴────────────────────────┘
│
▼
Monitored Network
In smaller environments, all Zabbix components may run on one server.
In larger environments, the server, database, frontend and proxy components should be separated according to performance, availability and security requirements.
A Zabbix monitoring platform is built from several cooperating components.
The primary components are:
| Component | Purpose |
|---|---|
| Zabbix Server | Central processing and monitoring engine |
| Zabbix Database | Stores configuration, history, trends and events |
| Zabbix Frontend | Web-based administration and visualization interface |
| Zabbix Agent | Collects operating system and application metrics |
| Zabbix Proxy | Collects data from remote or isolated environments |
| Java Gateway | Monitors Java applications using JMX |
| Zabbix Sender | Sends custom monitoring data to Zabbix |
| Zabbix Get | Tests and queries Zabbix agent items |
| Web Service | Provides scheduled report generation and related functions |
Each component has a clearly defined role within the monitoring architecture.
The Zabbix server is the central component of the monitoring environment.
It is responsible for:
The Zabbix server does not normally store monitoring data directly in local files. Configuration and collected data are written to the configured database backend.
A failure of the Zabbix server does not affect the monitored infrastructure itself, but monitoring, event processing and notifications may stop until the service is restored.
For this reason, the Zabbix server should be treated as a critical infrastructure component.
The database stores nearly all persistent information used by Zabbix.
This includes:
Supported database platforms depend on the installed Zabbix version and deployment model.
Common database platforms include:
The database is frequently the most resource-intensive component of a Zabbix deployment.
Database performance directly affects:
A production database should use reliable storage with low latency and sufficient write performance.
The Zabbix frontend provides the graphical management interface.
Administrators use it to:
The frontend is a PHP-based web application typically served by:
The frontend communicates directly with the Zabbix database.
It does not normally communicate directly with monitored hosts.
Administrator
│
▼
Web Browser
│
▼
Nginx or Apache
│
▼
Zabbix Frontend
│
▼
Zabbix Database
Access to the frontend should always be protected using HTTPS.
The Zabbix agent is installed on supported operating systems to collect local metrics.
It can monitor:
Two principal communication modes are available:
The selected mode determines which component initiates the connection.
During a passive check, the Zabbix server or Zabbix proxy initiates the connection to the agent.
Zabbix Server or Proxy
│
│ TCP request
▼
Zabbix Agent
│
│ Item value
▼
Zabbix Server or Proxy
The default Zabbix agent listening port is:
TCP 10050
Passive checks require the monitored host to accept incoming connections from the Zabbix server or proxy.
Advantages include:
Limitations include:
Passive checks are suitable for trusted internal networks where the monitoring server can directly reach the monitored host.
During an active check, the Zabbix agent initiates the connection to the Zabbix server or proxy.
Zabbix Agent
│
│ Requests active item list
▼
Zabbix Server or Proxy
│
│ Returns monitoring instructions
▼
Zabbix Agent
│
│ Sends collected values
▼
Zabbix Server or Proxy
The default Zabbix server trapper port is:
TCP 10051
Advantages include:
Limitations include:
Active checks are recommended for devices located behind firewalls, NAT gateways or remote networks.
Zabbix provides two agent implementations:
The classic Zabbix agent is lightweight and widely supported.
Zabbix Agent 2 provides a newer plugin-based architecture and expanded application monitoring capabilities.
Agent 2 is particularly useful for monitoring:
The exact set of available plugins depends on the installed version and operating system.
For new deployments, Zabbix Agent 2 is generally a strong default choice unless compatibility or operational requirements favor the classic agent.
Simple Network Management Protocol is commonly used to monitor network and infrastructure devices.
Typical SNMP-monitored equipment includes:
A typical SNMP monitoring flow is:
Zabbix Server or Proxy
│
│ SNMP request
▼
Network Device
│
│ SNMP response
▼
Zabbix Server or Proxy
Common SNMP ports are:
| Protocol function | Port |
|---|---|
| SNMP polling | UDP 161 |
| SNMP traps | UDP 162 |
SNMP versions commonly used are:
SNMPv3 should be preferred where supported because it provides authentication and encryption.
SNMPv1 and SNMPv2c use community strings and do not provide modern transport security.
With SNMP polling, Zabbix periodically requests values from a monitored device.
Typical metrics include:
Polling provides predictable and structured data collection.
However, polling intervals must be designed carefully to avoid excessive load on the Zabbix server, proxy, network or monitored device.
SNMP traps are unsolicited event messages sent by monitored devices.
Network Device
│
│ SNMP trap
▼
SNMP Trap Receiver
│
▼
Zabbix Server
Traps can report events such as:
Traps should normally complement polling rather than replace it.
A missed trap may result in an undetected condition unless polling also verifies the current state.
ICMP checks provide basic network availability and latency monitoring.
Typical ICMP measurements include:
Zabbix Server or Proxy
│
│ ICMP echo request
▼
Monitored Host
│
│ ICMP echo reply
▼
Zabbix Server or Proxy
ICMP is useful for quickly determining whether a host is reachable.
However, a successful ping does not confirm that an application or service is functioning correctly.
Similarly, a failed ping does not always mean the device is offline because ICMP may be blocked by a firewall.
ICMP monitoring should therefore be combined with service-level checks.
Simple checks are performed directly by the Zabbix server or proxy without requiring an agent.
They can verify services such as:
Example:
Zabbix Server
│
│ TCP connection test
▼
Application Server
│
▼
Service availability result
Simple checks are useful for determining whether a service is listening and reachable.
They do not necessarily validate the complete application workflow.
Zabbix web scenarios can simulate multi-step HTTP or HTTPS transactions.
A web scenario may verify:
Example:
Step 1: Open login page
Step 2: Submit credentials
Step 3: Verify dashboard content
Step 4: Confirm expected HTTP response
Web monitoring provides a more realistic service-level test than checking only whether TCP port 443 is open.
External checks execute scripts or binaries from the Zabbix server or proxy.
They can be used for:
External checks should be designed carefully.
Poorly written scripts may:
Where possible, scripts should implement:
Trapper items allow external systems to send values to Zabbix.
Data may be submitted using:
zabbix_sender
A typical flow is:
Application or Script
│
│ Custom monitoring value
▼
Zabbix Trapper
│
▼
Zabbix Server
Trapper items are useful for:
The Zabbix server or proxy receives trapper data on:
TCP 10051
Intelligent Platform Management Interface can be used to monitor compatible server hardware independently of the operating system.
Typical IPMI metrics include:
IPMI monitoring is useful for detecting hardware problems even if the operating system is unavailable.
Because IPMI interfaces are highly privileged management interfaces, they should be isolated on a dedicated management network.
Java Management Extensions monitoring is used for Java-based applications.
Examples include:
Zabbix uses the Java Gateway component for JMX monitoring.
Zabbix Server or Proxy
│
▼
Java Gateway
│
▼
Java Application
│
▼
JMX Metrics
The Java Gateway translates monitoring requests between Zabbix and the JMX interface.
A Zabbix proxy collects monitoring data on behalf of the central Zabbix server.
It is commonly deployed in:
A proxy can monitor hosts using:
The proxy buffers collected data locally and forwards it to the central server.
A distributed architecture may look like this:
Central Data Center
┌─────────────────────────┐
│ Zabbix Server │
│ │
│ Database + Frontend │
└────────────┬────────────┘
│
TCP 10051 / TLS
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
Branch Proxy A Branch Proxy B Customer Proxy
│ │ │
┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐
│ │ │ │ │ │
Servers Switches VMs Routers Agents SNMP
The central Zabbix server does not need direct network access to every monitored device when proxies are used.
Only communication between the proxy and server must be permitted.
Zabbix proxies can operate in active or passive mode.
An active proxy initiates the connection to the Zabbix server.
Zabbix Proxy
│
│ Outbound connection
▼
Zabbix Server
This mode is particularly useful when:
In passive mode, the Zabbix server initiates the connection to the proxy.
Zabbix Server
│
│ Connection to proxy
▼
Zabbix Proxy
This requires the central server to reach the proxy directly.
Active proxy mode is generally easier to deploy across NAT and restrictive firewall environments.
A Zabbix proxy stores collected values temporarily in its local database.
If communication with the central server is interrupted:
This provides resilience during:
Proxy storage must be sized according to:
A proxy is not a full replacement for the central Zabbix server.
It does not provide the complete frontend, global event processing or long-term centralized storage.
A centralized architecture uses one Zabbix server to communicate directly with all monitored hosts.
Zabbix Server
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Servers Routers Websites
This design is suitable for:
Advantages include:
Limitations include:
A distributed architecture uses one or more Zabbix proxies.
Zabbix Server
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
Proxy A Proxy B Proxy C
│ │ │
▼ ▼ ▼
Site A Site B Site C
This design is suitable for:
Advantages include:
Limitations include:
This guide uses a modular architecture that can be adapted to both small and enterprise environments.
Internet
│
▼
Firewall or VPN Gateway
│
▼
Management / Monitoring VLAN
│
┌───────────────────────┼───────────────────────┐
│ │ │
▼ ▼ ▼
Zabbix Server Zabbix Database Zabbix Frontend
│
│ TCP 10051
│
┌────┴─────────────────────────────┐
│ │
▼ ▼
Local Infrastructure Remote Proxies
│ │
┌───┼───────────┐ ┌─────┼─────────┐
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
VMs Routers Applications Branch Servers Network Devices
The architecture separates the following functional layers:
The presentation layer consists primarily of the Zabbix frontend.
Its responsibilities include:
The presentation layer should be protected by:
The frontend should not be exposed directly to the public Internet unless there is a documented business requirement and adequate protection.
The processing layer is provided by the Zabbix server.
It performs:
Performance in this layer depends on:
The Zabbix server should monitor its own internal performance metrics.
The database layer stores configuration and monitoring information.
For production deployments, this layer should provide:
The database should not be exposed to untrusted networks.
Only authorized components should be allowed to connect.
The collection layer includes:
This layer interacts directly with monitored infrastructure.
Security controls should therefore restrict each collector to only the systems and protocols it requires.
Zabbix can send events to external systems.
Common integrations include:
A typical event flow is:
Collected Metric
│
▼
Trigger Evaluation
│
▼
Problem Event
│
▼
Action and Escalation
│
▼
Notification or Ticket
Notification channels should be tested regularly.
A monitoring system that detects a failure but cannot notify the responsible team is operationally incomplete.
The following table summarizes common Zabbix communication paths.
| Source | Destination | Default port | Protocol | Purpose |
|---|---|---|---|---|
| Zabbix Server or Proxy | Zabbix Agent | 10050 | TCP | Passive agent checks |
| Zabbix Agent | Zabbix Server or Proxy | 10051 | TCP | Active checks |
| Zabbix Proxy | Zabbix Server | 10051 | TCP | Proxy communication |
| Zabbix Server | Passive Zabbix Proxy | 10051 | TCP | Passive proxy polling |
| Zabbix Server or Proxy | SNMP Device | 161 | UDP | SNMP polling |
| SNMP Device | Trap Receiver | 162 | UDP | SNMP traps |
| Zabbix Server or Proxy | Network Host | N/A | ICMP | Availability and latency |
| Zabbix Frontend | Database | Database-specific | TCP | Configuration and history access |
| Zabbix Server | Database | Database-specific | TCP | Data storage and retrieval |
| Zabbix Server or Proxy | Java Gateway | 10052 | TCP | JMX monitoring |
| Administrator | Zabbix Frontend | 443 | TCP | Secure web access |
| Zabbix Server | SMTP Server | 25, 465 or 587 | TCP | E-mail notifications |
Ports may differ depending on the environment.
Firewall rules should be based on actual communication requirements rather than broad network access.
A monitoring architecture requires carefully planned firewall policies.
The objective is not to allow unrestricted communication between the Zabbix server and all monitored networks.
Instead, allow only the required source, destination, protocol and port combinations.
Example policy:
Zabbix Server → Linux Servers TCP 10050
Zabbix Server → Windows Servers TCP 10050
Zabbix Server → Network Devices UDP 161
Zabbix Agents → Zabbix Server TCP 10051
Zabbix Proxies → Zabbix Server TCP 10051
Administrators → Zabbix Frontend TCP 443
Recommended firewall principles include:
Monitoring systems frequently require access to many infrastructure components.
This makes segmentation particularly important.
A recommended design uses a dedicated monitoring or management network.
Core Firewall
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
User Network Server Network Monitoring VLAN
│
▼
Zabbix Server
Benefits include:
The monitoring network should not automatically receive unrestricted access to every VLAN.
Access should be granted according to the monitoring methods in use.
Remote networks may be monitored across site-to-site VPN connections.
Central Zabbix Server
│
│ Encrypted VPN Tunnel
▼
Remote Network
│
┌────┼────────┐
│ │ │
▼ ▼ ▼
Server Router Switch
This architecture may be suitable when:
For larger or less reliable remote environments, a local Zabbix proxy is preferable.
Central Zabbix Server
│
│ Encrypted connection
▼
Remote Zabbix Proxy
│
▼
Remote Infrastructure
The proxy reduces the number of monitoring connections crossing the VPN and buffers data during tunnel outages.
Direct monitoring across the public Internet should be avoided where possible.
Agents, SNMP services and management interfaces should not be exposed publicly without strong justification.
Preferred approaches include:
A secure Internet-based proxy design may look like this:
Remote Customer Network
│
▼
Active Zabbix Proxy
│
│ Outbound TLS connection
▼
Internet
│
▼
Central Zabbix Server
Only the proxy initiates communication.
The central server does not require direct access to monitored customer devices.
Zabbix communication can be protected using TLS.
Supported trust models may include:
Unencrypted communication should be limited to trusted and isolated networks.
Pre-shared keys provide a practical encryption method for many environments.
Certificate-based encryption is appropriate where:
Encryption should be considered for:
Monitoring becomes increasingly important as infrastructure complexity grows.
The monitoring platform itself should therefore avoid obvious single points of failure.
Potential failure points include:
High availability design may include:
High availability does not remove the need for backups.
Replication protects availability, while backups protect recoverability.
A simplified high availability architecture may look like this:
Load Balancer
│
┌─────────────┴─────────────┐
│ │
▼ ▼
Zabbix Frontend 1 Zabbix Frontend 2
│ │
└─────────────┬─────────────┘
│
▼
Zabbix Server HA Cluster
┌───────┴───────┐
│ │
▼ ▼
Node 1 Node 2
│
▼
Highly Available Database
The precise implementation depends on:
Capacity planning should be performed before production deployment.
Important variables include:
A simplified estimate of collected values can be calculated as:
Values per second =
Total enabled items / Average update interval
Example:
10,000 enabled items / 60 seconds = approximately 167 values per second
This is only a simplified estimate.
Real workloads are affected by:
Not every metric requires the same update interval.
Example classification:
| Metric type | Example interval |
|---|---|
| Critical service availability | 30–60 seconds |
| CPU and memory utilization | 60 seconds |
| Interface traffic | 60 seconds |
| Disk capacity | 5 minutes |
| Installed software inventory | 1–24 hours |
| Configuration inventory | 1–24 hours |
| Certificate expiration | 1–12 hours |
| Static asset information | 24 hours |
Very short intervals increase:
Intervals should match the operational value of the data.
Collecting a static serial number every 30 seconds provides no practical benefit.
Zabbix stores two principal forms of time-series data:
History contains detailed collected values.
Trend data contains aggregated information for longer-term analysis.
Retention planning should consider:
Example policy:
| Data type | Example retention |
|---|---|
| Detailed history | 7–30 days |
| Trend data | 365 days or more |
| Events | According to operational requirements |
| Audit records | According to security requirements |
Long retention periods should be based on a clear business requirement.
Housekeeping removes expired data from the Zabbix database.
It may process:
In large environments, default housekeeping may create significant database load.
Alternative strategies may include:
Housekeeping performance should be monitored.
An overloaded housekeeping process can cause continuous database pressure.
Database storage should be sized according to expected write volume and retention.
Important factors include:
Production recommendations include:
Storage exhaustion can stop data collection and may damage database availability.
A proxy should be placed close to the infrastructure it monitors.
Good proxy placement examples include:
Avoid placing a single proxy across unrelated trust zones unless the design has been reviewed carefully.
Proxy placement should consider:
Managed service providers frequently monitor multiple independent customer environments.
A recommended design uses a dedicated proxy for each customer or customer site.
MSP Zabbix Server
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Customer A Proxy Customer B Proxy Customer C Proxy
│ │ │
▼ ▼ ▼
Customer A LAN Customer B LAN Customer C LAN
This design provides:
Customer host groups, user permissions and naming conventions should also be separated consistently.
Consistent naming is an architectural requirement.
Recommended host naming patterns may include:
SITE-ROLE-NUMBER
Examples:
BUD-DC-01
BUD-HV-01
BUD-SW-01
GYR-FW-01
CUSTOMERA-SRV-01
Useful naming elements include:
Avoid names such as:
Server1
NewRouter
TestMachine
PC-John
Names should remain meaningful even when viewed outside the original network context.
Host groups should represent operational or administrative boundaries.
Possible host group structures include:
Customers/Customer-A/Servers
Customers/Customer-A/Network
Customers/Customer-A/Applications
Sites/Budapest
Sites/Győr
Sites/Debrecen
Infrastructure/Linux
Infrastructure/Windows
Infrastructure/Network
Infrastructure/Virtualization
Host groups are used for:
A host may belong to multiple groups.
Templates provide reusable monitoring configuration.
A layered template model is recommended.
Example:
Template OS Linux
│
├── Template App SSH Service
├── Template App Nginx
└── Template App PostgreSQL
A host can receive multiple templates according to its role.
Example:
Host: WEB-SRV-01
Assigned templates:
- Linux by Zabbix agent
- Nginx by Zabbix agent
- Website certificate monitoring
- Custom backup monitoring
Avoid creating one oversized template containing every possible item.
Modular templates are easier to:
Dependent items reduce duplicate data collection.
A master item collects a larger dataset, such as JSON output.
Dependent items then extract individual values.
Master Item
│
│ JSON payload
▼
Preprocessing
│
├── CPU value
├── Memory value
├── Service state
└── Connection count
Benefits include:
Dependent items are particularly effective for:
Low-level discovery automatically identifies entities such as:
Discovery creates items, triggers and graphs from prototypes.
This improves scalability but must be controlled carefully.
Poorly designed discovery can create:
Discovery filters and override rules should be designed before large-scale deployment.
The Zabbix platform must monitor itself.
Important internal metrics include:
A self-monitoring failure should generate an alert through an independent or redundant notification path where possible.
Architecture planning should consider likely failure scenarios.
Effects:
Effects:
Effects:
Effects:
Effects:
Every critical component should have:
The monitoring platform crosses multiple trust boundaries.
It may collect data from:
Compromise of the monitoring system may expose sensitive infrastructure information.
Security controls should include:
Credentials should not be stored directly in item keys, scripts or public repositories.
Use macros, secret stores or controlled configuration mechanisms where appropriate.
The following table provides a basic architecture selection guide.
| Environment | Recommended architecture |
|---|---|
| Small single-site office | Centralized Zabbix server |
| Medium single-site organization | Separate server and database where required |
| Multiple branch offices | Central server with one proxy per branch |
| Managed service provider | Central server with customer-specific proxies |
| Isolated security zones | Proxy per security zone |
| Unreliable WAN connection | Active proxy with sufficient buffer |
| Mobile or NAT-based endpoints | Active agent checks |
| Large enterprise | Distributed proxies with database and server capacity planning |
| Critical infrastructure | High availability server and database design |
The simplest architecture that satisfies availability, security and scalability requirements is usually the most maintainable.
For a production-oriented deployment, the following baseline is recommended:
Central Zabbix Environment
├── Zabbix Server
├── PostgreSQL Database
├── Zabbix Frontend
├── HTTPS Reverse Proxy
├── Regular Database Backup
└── External Notification Channel
Remote Site
├── Active Zabbix Proxy
├── Local Proxy Database
├── Zabbix Agents
├── SNMP Devices
└── Outbound TLS Connection to Central Server
Core principles:
Before deploying the monitoring platform, verify the following.
Avoid the following design errors:
A monitoring platform should reduce operational risk rather than introduce additional hidden dependencies.
The monitoring architecture defines how Zabbix components communicate with the monitored infrastructure and with each other.
A robust architecture should provide:
Small environments can begin with a centralized Zabbix server.
As the monitored infrastructure grows, Zabbix proxies, separated database services, high availability components and stronger security boundaries can be introduced without redesigning the entire monitoring model.
The next chapter covers the installation and initial deployment of the Zabbix platform.
Continue with: