For large organizations, the key question is whether the new release will provide greater control over environments in which thousands of hosts, applications, and services form a single interconnected system. This is the perspective from which Zabbix 8.0 should be evaluated.
At the time of writing, some features are marked as Ready in the official roadmap, while others remain under development. The final scope should therefore be confirmed in the documentation for the production release.
From infrastructure monitoring to broader observability
For years, Zabbix has been associated primarily with monitoring servers, network devices, databases, and infrastructure parameters. This remains the platform’s foundation, but modern environments require a broader view. Knowing that CPU utilization has reached 90 percent or that an interface has stopped responding is often not enough to determine how a problem affects a business service.
In distributed systems, a failure may originate from a single call between services, a delay in a queue, a database issue, or an external API. Operations teams therefore need to combine infrastructure metrics with logs, traces, and application context. The planned support for OpenTelemetry shows that Zabbix intends to expand further into this area.
OpenTelemetry and trace visualization
The Zabbix 8.0 roadmap includes scalable collection and processing of OpenTelemetry data, which is currently under development, as well as a dedicated view for searching and visualizing traces. OpenTelemetry is a vendor-neutral standard for instrumenting applications and transmitting telemetry data. It separates the way applications generate data from the particular system in which that data is later stored and analyzed.
From an architectural perspective, this provides greater flexibility. Organizations do not have to tie their entire application instrumentation layer to a single vendor. They can also gradually combine infrastructure monitoring with application observability. In practice, the value of this change will depend on the quality of trace search, retention, correlation, and visualization in the final product. Ingesting the data is only the beginning.
Structured data and native JSON support
One feature marked as Ready in the roadmap is a new JSON data type. It is intended to enable the native collection of any structured data that can be represented in this format. This is an important change because modern systems increasingly return information as documents and objects rather than individual numerical values.
Structured data can contain a status, identifiers, service parameters, and additional context at the same time. Native JSON storage may simplify further processing within monitoring logic, reduce the need for additional scripts, and make it easier to develop integrations and templates. For teams maintaining their own integrations, this could mean fewer intermediary layers and more straightforward template development.
Scalability is no longer just about the number of hosts
The scale of a monitoring deployment is no longer defined solely by the number of hosts. A single cluster or application can generate thousands of metrics, logs, and events. Adding application data and traces further increases the load on components such as the server and database.
Zabbix has announced significant server performance improvements and support for new storage engines optimized for large volumes of telemetry data. The roadmap sets a target of collecting millions of data points per second. Faster SNMP data collection has already been marked as Ready.
For enterprises, maximum throughput is not the only consideration. Predictable costs, data retention periods, and the ability to scale without constantly adding resources are equally important.
Complex Event Processing and the fight against alert fatigue
Another area currently under development is the Complex Event Processing (CEP) engine. It is intended to process multiple related events rather than make decisions based on individual alerts. Planned capabilities include filtering, deduplication, changing tags and severity levels, automatically closing outdated events, time-window logic, pattern matching, and custom JavaScript rules.
This is a response to a problem commonly found in enterprise environments: a high number of alerts does not automatically translate into better control. In fact, the opposite is often true. A single incident can generate dozens of notifications across several infrastructure layers, forcing operators to determine manually which event was the cause and which events were merely consequences.
CEP could help reduce noise and provide teams with more useful context. However, it will not replace well-designed thresholds, a clear responsibility model, and a robust incident response process. If an organization has hundreds of poorly configured alerts, a new engine will not put the entire process in order on its own. Technology can support decision-making, but it cannot replace sound operational practices.
Dashboards and configurable views
Not every important improvement needs to involve a new architecture. Dashboard import and export, copying widgets between systems, and configurable table views can significantly improve administrators’ day-to-day work.
In a large organization, a dashboard is rarely a single screen created by one administrator. It is often part of an operational standard: the same view may be required in test, production, and disaster recovery environments, or across several organizational units. The ability to transfer ready-made layouts reduces manual work and helps maintain consistency.
Configurable tables will allow users to change the order and width of columns and hide information that is irrelevant to a particular team. This may appear to be a minor improvement, but when hundreds of problems are analyzed every day, a better-organized view can shorten the time needed to reach relevant information.
Security and business continuity
A monitoring system has extensive knowledge of the environment, so its own security cannot be treated as an afterthought. The roadmap marks the ability to upload SSO certificates directly through the interface and export filtered audit log entries to CSV as Ready. A permissions model for proxies and proxy groups, similar to the permissions used for host groups, is still under development. Support for AppRole authentication in HashiCorp Vault is also planned.
MCP Server: giving AI access to monitoring context
One of the most widely discussed features currently under development is the official Zabbix MCP Server. The Model Context Protocol provides a standardized way for AI tools to access data and operations from external systems. In Zabbix, it is intended to allow AI agents to query monitoring data programmatically, access configuration information, and work with events and alerts.
This could pave the way for faster incident summaries, searches for related events, and assistance for administrators analyzing their environments. However, it does not mean that an AI agent should immediately receive unrestricted access to a production system. Access control, operation auditing, limits on available actions, and the protection of sensitive data will be critical.
MCP should therefore be treated as an integration layer rather than a magic AIOps button. Its actual value will depend on data quality, process maturity, and the decisions an organization genuinely wants to entrust to automation.
Official mobile application
An official mobile application for iOS and Android is expected to be released alongside Zabbix 8.0 LTS. According to the roadmap, it will provide push notifications, access to problems and historical data, and basic problem management features. The application is still under development, so its final scope should be confirmed once the production version is released.
What Zabbix 8.0 means for the enterprise
The most important change is not any single feature, but the direction in which the entire platform is evolving. Zabbix remains an infrastructure monitoring system, but it is increasingly seeking to combine this foundation with application data, stream processing, event correlation, and AI tools.
For large organizations, this could provide an opportunity to reduce tool silos and build a broader layer of operational visibility. Zabbix 8.0 should be treated as an opportunity to review the current monitoring model. Does the system show only the status of individual components, or does it also reveal the impact of an incident on a service? Do alerts lead to decisions, or do they merely add to the queue? Can metrics, logs, and traces be analyzed within a shared context? Only the answers to these questions will reveal which new features provide genuine value to the organization.
Hawatel support - Zabbix Certified Delivery Partner
As a Zabbix Certified Delivery Partner, Hawatel supports organizations in designing, modernizing, and maintaining monitoring and observability environments. We help assess existing architectures, plan platform development, improve alert management, and prepare for a secure transition to a new Zabbix version without disrupting monitoring continuity.
If you are planning to deploy Zabbix 8.0 in an enterprise environment, it is worth starting with an assessment of the needs and limitations of your existing infrastructure. The new version may offer significantly greater capabilities than its predecessor, but their value will depend on sound design and proper implementation.
