At a glance
Facts as published by each vendor on 2 October 2026.
| Zabbix | AtlasEye | |
|---|---|---|
| Vendor | Zabbix SIA, Riga, Latvia | cdnCore, Lda., Covilhã, Portugal |
| Licence | AGPLv3 from version 7.0; GPLv2 up to 6.4 | Commercial subscription per installation |
| Price | No licence fee; support and services sold separately | Plus €79/month (up to 50 devices), Pro €199/month (up to 250), Enterprise on request |
| Current release | 7.0 LTS (June 2024, full support until June 2027) and 7.4 (July 2025); 8.0 LTS planned for Q4 2026 | 1.2.341 |
| Data collection | Zabbix agent and agent 2, SNMP, IPMI, JMX, HTTP, scripts; a large template library | ICMP, SNMP v1/v2c/v3 with LLDP neighbours, HTTP(S) and TCP checks, MikroTik RouterOS API, Proxmox VE, node_exporter, cAdvisor |
| Syslog | No built-in syslog receiver; usually rsyslog plus agent log items | Built-in receiver on UDP and TCP 514, with full-text search and GeoIP context |
| Incidents | Problems, acknowledgements and actions; ticketing through integrations | Incident lifecycle with timeline and the Article 23 milestones (Pro and Enterprise) |
| NIS2 reporting | Not part of the product | JSON/XML export for the CSIRTs of the 27 Member States, sent by e-mail (Pro and Enterprise) |
| High availability | Native server HA cluster since 6.0; proxies, load-balanced in proxy groups since 7.0 | Single node, no geo-redundant HA |
| Network administration | Network discovery; no IPAM or DNS management | IPAM, Cloudflare DNS, nginx virtual hosts and certificates (Pro and Enterprise) |
| Deployment | Packages for the major Linux distributions, containers, appliance images | Linux x86_64 with Docker Compose, or a dedicated instance operated by cdnCore in Portugal |
Two design philosophies
Zabbix is a framework as much as a product. A server, a relational database, a web frontend, optional proxies and agents form a system that can monitor almost anything that exposes data, provided someone designs the templates, triggers and housekeeping. That flexibility is why Zabbix runs estates of tens of thousands of hosts. It is also why running Zabbix well is a specialist skill: database growth, history and trend retention, template inheritance and trigger dependencies all need continuing attention.
AtlasEye makes the opposite trade-off. The modules are fixed (monitoring, syslog and security events, incidents, IP address management, DNS and service management), the integrations are fewer, and there is less to configure. Each installation serves one organisation, which makes data separation simple and caps the architecture at what one node can carry.
Logs and security events
Zabbix is not a log platform. Its agent can follow log files and match patterns, and a common way to bring syslog from network devices into Zabbix is to receive it with rsyslog and let an agent read the resulting files. Organisations that need searchable logs usually pair Zabbix with Graylog, OpenSearch or a SIEM.
AtlasEye receives syslog directly on UDP and TCP port 514, indexes it for full-text search, adds GeoIP context to each source and raises alerts for brute-force log-in attempts and port scans. These are specific detections, not a correlation engine; an organisation that needs custom correlation rules across many log sources still needs a SIEM.
Incidents and NIS2
In Zabbix, a problem is a trigger in a bad state. Acknowledgements, comments and actions record the response, and webhook media types connect to ticketing systems such as Jira or ServiceNow. That is sound operational alerting. The NIS2 reporting sequence, however (a record opened at awareness, the 24-hour, 72-hour and one-month milestones, and a structured submission to the CSIRT), has to be built in the ticketing system.
AtlasEye treats the incident as an object of its own, with a timeline and the three Article 23 milestones, exports reports in JSON or XML for the CSIRTs of the 27 Member States, and keeps actions in a hash-chained audit log. The regulatory background is set out in What NIS2 asks of network monitoring.
Scale, availability and cost
Zabbix has no licence fee; its cost is engineering time and infrastructure. Its server has been able to run as a high-availability cluster since version 6.0, and proxies, load-balanced in groups since 7.0, distribute collection across sites. For a large or geographically distributed estate this is a decisive advantage.
AtlasEye costs a subscription that is easy to forecast: €79 a month for up to 50 devices, €199 for up to 250, and Enterprise pricing on request beyond that. The architecture is a single node without geo-redundant high availability, deployed with Docker Compose; Kubernetes is not supported. For an entity bound by Implementing Regulation (EU) 2024/2690, which requires redundant monitoring systems, that is a point to assess before choosing.
Which one to choose
Choose Zabbix when the estate is large or heterogeneous, when the monitoring system itself must be highly available or distributed across sites, when engineers will own the templates and the database, or when an open-source licence is a requirement.
Choose AtlasEye when the network is small or mid-sized (up to 250 devices on Pro), when monitoring, syslog, incidents and NIS2 reporting should live in one console rather than in three integrated products, when a vendor in Portugal and, optionally, a dedicated instance operated on infrastructure in Portugal matter, and when a single-node architecture is acceptable.
The two are not mutually exclusive. Some teams keep Zabbix for metrics and use a second product for logs and the incident record. Whether that is simpler than one integrated console depends on who will maintain the integration.
Sources
- Zabbix licence: zabbix.com/license
- Zabbix blog, "Striking the right balance: Zabbix 7.0 to be released under AGPLv3 license": blog.zabbix.com
- Zabbix life cycle and release policy: zabbix.com
- What's new in Zabbix 7.0 LTS: zabbix.com
- Zabbix documentation, log file monitoring: zabbix.com
- AtlasEye pricing, integrations and requirements, verified against version 1.2.341 on 30 September 2026: pricing, integrations, requirements