The new Zabbix 8.0 LTS is here!

Zabbix 8.0 LTS is here!

The new Zabbix 8.0 LTS release brings a range of useful improvements. APM with OpenTelemetry and the new CEP correlation engine are among the biggest additions. Monitoring, the user interface, and security also receive updates. Below is an overview of the main features and their practical use.

New CEP correlation engine (Complex Event Processing)

One of the major new features in Zabbix 8.0 is the new CEP correlation engine, or Complex Event Processing. It builds on the existing event handling model, but takes it a level further: instead of evaluating individual problems in isolation, it allows Zabbix to evaluate relationships between multiple events, work with time windows, tags, host groups, and follow-up operations.

In practice, this addresses one of the most common monitoring problems. One real incident often generates tens or hundreds of events. A network, database, storage, or central service outage can affect many hosts and applications at once. Without additional logic, the administrator is not dealing with one incident, but with a long list of related problems. CEP helps turn those events into a more understandable picture.

The purpose of CEP is not just to show that a problem occurred. The goal is to apply more advanced logic to the event stream: group related problems, evaluate them within a time window, add tags, change severity, suppress less important events, or distinguish between a cause and its symptoms.

The configuration is available under Data collection > Event processing. The same list also contains the original event correlation rules next to the new CEP rules, and the Type filter separates them. The Info column shows a runtime error of the rule, and the Reset time windows button discards the open time windows after the rule has been changed.

Rule detail

The screenshot shows the detail of a CEP rule. The top part defines which events the rule should catch, the middle part contains the time-window and grouping logic, and the lower part defines the operations Zabbix will perform on matching events.

• Name is the operational identifier of the rule. In larger installations, it makes sense to include the rule purpose in the name, such as location, service, incident type, or expected correlation result.
• Type of calculation and Conditions form the input filter. A rule can select events by Event name, Tag name, Tag value, Severity, Host, Host group, and now also Time period. Tag name and Tag value are separate conditions with the Equals, Does not equal, Contains, and Does not contain operators, and severity supports Is more than or equal. In the example, the rule works with a New York host group, a location tag, and minimum severity. This is where Zabbix decides which events enter the correlation logic at all.
• Time window defines how events are processed over time.
  • None means the rule reacts without a time window.
  • Simple keeps matching events for the period set in Duration.
  • Cause and symptoms grouping is intended for cause-versus-symptom relationships.
  • Tag correlation pairs events based on tags.
  • Pattern match evaluates an event pattern. The pattern is written in JavaScript in the Script field, which has access to the events in the window.
• Duration defines the length of the window. A value such as 10m means related events are watched within a ten-minute interval and can be evaluated as one correlation context. A user macro can be used in the field as well.
• Capacity limits the number of events in the window. The Unlimited / Limited switch and a number or macro define how many events the window keeps. After the limit is reached, the oldest event is evicted from the window. Operations executed at Event evicted can then react to that situation, for example by changing severity or adding a tag.
• Group by defines how events inside the window are split into groups. It consists of three independent checkboxes, Host group, Host, and Tag, which can be combined, and multiple tag names can be entered at once, for example location and service. With tags, the exact name including letter case matters. In the Cause and symptoms grouping mode, Group by is not mandatory.
• Event count tag is used in modes where the number of related events matters. The result can be written into a tag, so the scope of the correlation is visible directly on the problem.
• Operations are the rule output. This is where you define what Zabbix should do with the events: add or modify a tag, change severity, suppress a symptom, change the event name, or otherwise affect further processing.
• Stop after this rule stops evaluation of further CEP rules for the same event after the current rule is processed. This is important for rule prioritization and for cases where one rule clearly classifies the incident.
• Sort order defines the evaluation order. Lower values are processed earlier, ties are resolved by rule name, so together with Stop after this rule it can control the priority of the whole correlation logic.

The operation options inside a CEP rule look like this:

In the Operation details dialog, you first define when the operation should run (Execute when) and which events it should apply to. Event selection is handled by a dedicated Conditions block with the same logic as the rule itself: And/Or or Custom expression and condition types Tag name, Tag value, Problem is opened, Problem is symptom, First event in time window, Last event in time window, Problem is suppressed, and Event is cloned. The same CEP logic can therefore perform a different action on the cause, on the symptoms, or only on the first event in the window.

• Event occurred runs when a new matching event enters the rule. It is useful for immediately adding context, such as a tag or an adjusted event name.
• Event added to window runs only when the event is actually placed into the time window. Unlike Event occurred, the First event in time window and Last event in time window conditions can be used here.
• Event evicted runs when an event leaves the time window, for example because of a capacity limit or because time has moved on. This makes it possible to distinguish events that no longer belong to the current correlation group.
• Window closed is evaluated when the time window closes, after the period set in Duration. This is useful for actions that should happen only after the full group of events has been collected.
• Pattern matched belongs to the Pattern match mode, where an event pattern is evaluated by a script. It is useful when a simple count or shared tag is not enough and the sequence or combination of events matters.

The triggers have a fixed order, Event occurred > Event added to window > Event evicted > Window closed > Pattern matched, and the operations in a rule must be sorted this way. Which triggers are available depends on the window type: None offers only Event occurred, and Pattern matched exists only for Pattern match. The set of operations also changes with the trigger, for example Discard is available only at Event occurred and Pattern matched.

The lower Operation part is the actual action Zabbix performs on the selected events. It is therefore not only a filter that finds events, but also the follow-up processing. Depending on the operation type, additional fields are shown, such as a new event name, target severity, tag name, or tag value.

• Set name changes the event name, and macros work in the value. This is useful when you want to turn several technical messages into a more readable incident name.
• Close and Discard work with the event lifecycle. One option closes the event, while the other can remove it from further processing if it no longer adds value in the given correlation context.
• Set severity, Increase severity, and Decrease severity adjust severity based on what CEP detects. A standalone problem may have lower priority, but in combination with other events it may represent a more serious incident.
• Suppress suppresses a selected event, typically a symptom that should not be shown as prominently as the probable cause. It is set either as Duration or Indefinitely. The opposite operation, Unsuppress, removes the suppression. The suppression is recorded in the event history as a CEP action.
• Add tag, Set tag, and Set tag value add or modify tags. This is useful for filtering, notifications, dashboards, and follow-up automation.
• Increase tag value and Decrease tag value work with the tag value as a counter or numeric context, for example for the number of related events in a correlation group.
• Rename tag and Remove tag help normalize event metadata so Zabbix can continue working with consistent naming.
• Clone first and Clone last create a copy of the first or last event in the window. They are available at Event evicted, Window closed, and Pattern matched, and make sense where you want to produce one summary event from the collected group.
• Close (window) closes the whole time window early. It is useful in Pattern match scenarios where the pattern has been found and there is no reason to wait for Duration to expire.
• In the Cause and symptoms grouping mode, Zabbix itself marks the first event in the window as the cause and the others as symptoms; the event details then show the Set as symptom action with a link to the CEP rule.

Example: incident in the New York location

As a simple example, imagine that several problems appear within a short time in the New York location: on an edge gateway, a database cluster, and an application server. Each problem makes sense on its own, but for the operator it is more important to know that they probably belong to the same incident.

Before correlation

Without correlation, this is a normal list of problems. We can see several events with shared context, such as site=nyc, region=us-east, or similar services, but Zabbix still displays them primarily as separate problems. The operator has to infer the relationship from names, hosts, severity, and tags.

• the problems occurred in the same time period,
• some of them share location tags, such as site=nyc and region=us-east,
• some events can be marked as candidates for further analysis, for example ai.candidate=yes,
• without additional logic, it is not immediately clear what the main cause is and what is only a symptom.

After correlation

After the CEP rule processes the events, they start behaving as a related group. In the example, the database problem is marked as the probable cause and the other problems are treated as symptoms. The Problems view also shows the number of linked symptoms and the output tag cep.count=5, which adds the correlation scope directly into the event metadata.

• Root cause remains visible as the main problem the operator should focus on first.
• Symptoms do not disappear, but they are linked to the main cause. They provide context without pretending to be separate incidents of the same importance.
• Shared tags, such as cep.scope=nyc-outage-window, make later filtering, reporting, notifications, and automation easier.
• Count tag, for example cep.count=5, shows the number of related symptoms or the scope of the affected group directly in event data.

The practical effect is that monitoring no longer presents only a longer list of individual problems. Events get context: what probably belongs together, what looks like the cause, which problems are symptoms, and how large the related event group is.

We see CEP as one of the main changes in Zabbix 8.0. It is not a replacement for the existing problem workflow, but a new level of event management: Zabbix can maintain context over events, link them into related groups, and automatically add information that administrators would otherwise have to find manually.

From an operational point of view: time windows are stored in the database and survive a server restart, CEP has its own workers with an internal item for statistics and a section in diaginfo, and the API gained cep_ruleid in the output of event.get and problem.get. Changes made by CEP appear in the event history as a separate action type.

The original global event correlation rules remain available and can still be used. In Event processing, the Event correlation type distinguishes them from CEP. The new CEP adds time windows and broader processing options; existing rules are not automatically converted to it.

Zabbix mobile app and push notifications

Zabbix 8.0 brings an official mobile application and, with it, a new media type called Push. Problem notifications go straight to the phone, without e-mail, an SMS gateway, or a third-party webhook. On the server side this is new infrastructure: management of linked devices, permissions in user roles, and an encrypted channel between the server and the app.

How it works

Zabbix server does not send push messages directly. Between the server and the mobile platform sits the Bridge Adapter, a separate service with a JSON-RPC interface over HTTP(S), which the server contacts when a device is linked (device.init) and for every notification (device.notify). The server passes it the problem.created, problem.updated, and problem.resolved events including severity, priority, title, and message body.

The Zabbix Mobile App is a separate client for iOS and Android, not part of the web frontend or Zabbix server package. Device pairing, permissions, and push media are configured in Zabbix; the mobile client and an available Bridge Adapter are additional components. See the official Zabbix Mobile App page for information about the application.

The Bridge Adapter is not part of the Zabbix server installation. The server connects to it through a configured URL; the server source does not include its implementation. Mobile notifications therefore require an available adapter and a working connection to the server. Installing the server alone does not enable push notifications.

The notification content is encrypted for the specific device. Each phone gets its own encryption key during linking, the bridge adapter sees only the encrypted payload and never the problem text. The app authenticates to the API with DPoP tokens (proof-of-possession, ES256 signature) with replay protection, so a stolen token cannot be misused without the device key.

Server configuration

The whole feature is disabled by default. It is enabled in zabbix_server.conf:

EnableMobileDevices=1
BridgeAdapterURL=https://bridge-adapter.example.com:10005/rpc
# optional: connect elsewhere than the URL says (e.g. through a tunnel)
BridgeAdapterConnectTo=127.0.0.1:10054

As long as EnableMobileDevices=0, the Devices items do not appear in the frontend at all and the device.* API methods are not available. Without a reachable bridge adapter, linking fails with Cannot initialize mobile device, cannot connect to bridge-adapter.

Linking a device

Users add their phone themselves in User settings > Devices > Add device. The frontend generates a QR code valid for 10 minutes (the countdown runs directly in the dialog), the app scans it, and once linking completes the device appears in the list as Active. No manual typing of server addresses or API tokens.

The QR code is a deep link zabbix://v1/link_device and carries everything the app needs for linking: the Zabbix server identifier and name, the device ID, the bridge adapter address, two one-time enrollment tokens (for Zabbix and for the bridge), and the adapter public key. The server identifier is the new Zabbix server ID shown in System information, so the app can tell multiple Zabbix instances apart.

Administrators see all devices in Users > Devices: name, Device ID, user, role, when it was linked, and when it was last active. The states are New (pairing initiated), Active, and Unassigned. Devices can be filtered by user, role, or group and removed; administrators can also initiate pairing for another user.

Permissions

User roles gained a separate Devices section: enabling the feature for the role, the Manage own devices and Manage user devices actions, and default access to newly added actions. In addition, there is a new Users > Devices item among the UI elements. You can, for example, allow push notifications for everyone but leave management of other people’s devices to the helpdesk only.

Push media type

The new Push media type sits next to Email, SMS, Script, and Webhook. The form is minimal: name, type, and description, plus a Bridge adapter connection indicator that immediately shows whether the server has the adapter configured. The default message templates for problem, recovery, and update look like {HOST.NAME} - {EVENT.NAME} and [RESOLVED] {HOST.NAME} - {EVENT.NAME}, and macros work as with the other types.

For a user, the media is then configured as usual, except that Send to is not an address but a choice between Active devices (all active devices of the user) and Selected devices. Actions and escalations are configured the same way as for other media types; push is just another escalation step.

What it means in practice

Smaller teams can use mobile push notifications instead of a paid SMS gateway. For larger environments, what matters is that linking is self-service, devices are centrally visible and can be removed, and notification content never leaves Zabbix in readable form. Verify device linking and delivery of an actual notification during deployment.

New look: Dark blue theme, Inter font, and rounded interface

Zabbix 8.0 is the first release in a long time that changes not only the features but also how the interface looks. There are three changes: a new Dark blue color theme, a new font embedded directly in the frontend, and modernized components with rounded corners and better accessibility. None of this changes the page layout; administrators find their way around exactly as in 7.x.

Dark blue theme

Next to the existing Dark theme comes Dark blue: a dark blue background (#001F42), blue accents (#004FA8), and light text, designed not to glare on large screens in a monitoring center while staying more readable than a purely black theme. It also has its own palette for classic graphs, so line colors match the background.

Own font instead of the system one

The frontend now ships its own Inter font (a variable font, italic included) and Noto Sans for Japanese, Korean, Chinese, Georgian, and Hebrew. Zabbix therefore looks the same on Windows, macOS, and Linux and no longer depends on which fonts the browser has available. Along with this, forms where longer texts used to overflow were adjusted (graph widget, preprocessing, setup wizard).

Anyone who prefers the previous look can use the Blue (classic) and Dark (classic) themes with the existing font set. The list of themes is therefore: Blue, Blue (classic), Dark, Dark (classic), High-contrast light, High-contrast dark, and the new Dark blue.

Modernized interface

Input fields, buttons, tables, filters, tabs, and dashboard widgets received uniformly rounded corners and adjusted borders. A small detail at first glance, but overall the interface feels lighter and more consistent. The same screen in 7.4 and 8.0 side by side:

The second part of the modernization is accessibility: a Skip to main content link for keyboard navigation (it appears after pressing Tab), better focus highlighting, and corrected contrasts. Selected text fields also resize automatically to their content (names, expressions, descriptions), so long values no longer have to be scrolled through in a single-line box.

Related details: tooltips and hint boxes can be dragged elsewhere when they cover what you need to see; automatic dashboard slideshows are now off by default and controlled by a URL parameter; and most configuration forms run in modal windows with inline validation, so an error shows up right at the field, not only after saving.

What it means in practice

For users it mainly means the certainty that Zabbix looks the same everywhere and can be operated comfortably from the keyboard. For companies with their own frontend branding (logo and colors via brand.conf.php) nothing changes, the mechanism stays. If you have custom modules or widgets with their own CSS, plan a check on the new themes, especially Dark blue and the classic variants.

APM and OpenTelemetry: traces, metrics, and logs directly in Zabbix

The biggest architectural change in 8.0 fits into one sentence: Zabbix starts accepting OpenTelemetry data. Applications instrumented with an OpenTelemetry SDK or the OpenTelemetry Collector send traces, metrics, and logs to Zabbix proxy, which provides the built-in OTLP/gRPC receiver and stores the data in ClickHouse. Zabbix server has no OTLP collector of its own: it reads stored data using Telemetry query items and derives values for triggers, graphs, and alerts. The frontend browses the data in the Traces, Metrics, and Logs views. Zabbix thereby enters the APM (Application Performance Monitoring) space, where until now you had to reach for Jaeger, Tempo, or commercial tools.

A proxy is therefore required for the built-in OTLP receiver, not for the server to read telemetry. It can run on the same machine as Zabbix server; a separate server or virtual machine is not required. If another collector writes data to compatible ClickHouse telemetry tables, Zabbix server can read it without collection through Zabbix proxy. The proxy can also execute Telemetry query items.

A trace captures a request as it passes through an application. It consists of spans: individual operations such as handling an HTTP request, querying a database, or calling a payment gateway. A shared Trace ID and parent-child span relationships join these operations into one request path. Collection requires OpenTelemetry instrumentation or another OTLP data source; installing Zabbix alone does not create traces.

It consists of three parts that together form one chain:

• Collection: an OTLP/gRPC collector in Zabbix proxy (port 4317 by default).
• Browsing: a new top-level menu section APM with the Traces, Metrics, and Logs views over a global APM data source.
• Processing: a new item type, Telemetry query, which turns telemetry data into values for triggers, graphs, and dashboards.

Collection: OpenTelemetry collector in Zabbix proxy

The built-in OpenTelemetry receiver is exclusively a proxy component. Zabbix server has no collector and there are no options for it in zabbix_server.conf; even in environments that never needed a proxy before, you deploy one for built-in collection. The proxy gets a new APM collector process with an OTLP/gRPC interface and writes the received data to ClickHouse. The APM store and the optional ClickHouse backend for ordinary item history are two separate configurations. The configuration lives in zabbix_proxy.conf:

StartAPMCollectors=1
APMListenIP=0.0.0.0
APMListenPort=4317
TelemetryProvider=clickhouse;url=http://clickhouse:8123,db=zabbix,username=zabbix,password=zabbix
# TLS for OTLP clients: APMTLSCAFile, APMTLSCertFile, APMTLSKeyFile

The ClickHouse password can be stored in HashiCorp Vault (vault_path=), just as for the server database. Collection requires a proxy with APM support. A prebuilt package that includes this support needs no additional compilation; enable the collector through configuration. Only when building from source do you enable support with --enable-proxy --with-apm, using the gRPC and protobuf libraries. Check support in the specific package, not just the proxy version number.

The built-in collector accepts OTLP/gRPC, on port 4317 by default. OTLP/HTTP on port 4318 is not its second interface: the exporter must use gRPC, or an OpenTelemetry Collector must forward the application data over the supported protocol.

APM proxy settings in the frontend

Alongside the collector configuration, the proxy form gains a new APM tab. It enables data collection, sets the export-message limit, and adds environment or site attributes. The settings are split into Input and Process:

In the frontend, the proxy form gets a new APM tab with two parts. Input: the Data collection enabled switch and a Max messages per second limit (Unlimited / Custom), so that one chatty application cannot flood the storage. Process: an Add resource attributes table, i.e. attributes the proxy adds to all received data (for example environment or location) without configuring them in every application. If the collector is not enabled in the proxy configuration file, the frontend says so right in the form.

Max messages per second limits export messages, not the number of spans inside a message. The collector rejects requests above the limit; retries depend on the exporter. Enabling collection in this tab and starting the collector in the proxy configuration are separate requirements.

Browsing: Traces, Metrics, and Logs

The main menu gains a new APM section right below Monitoring, with three views. Traces filters by Trace ID, Span ID, service and operation name, scope, duration (min/max), status (Ok / Error / Unset), and arbitrary attributes with And/Or logic, and lists entire traces with span counts, errors, start time, and duration. The screenshots below show the trace list of a simulated itemMAX PRO purchase on the initMAX website and the same view narrowed down to slow payment gateway calls. Logs searches the record body, severity (Trace to Fatal), and attributes, and links a log to its trace via Trace ID / Span ID. Metrics filters metrics by name, type, service, and scope. All three views use the same time selector as the rest of Zabbix.

The example uses our services: itemMAX on the initMAX website, the e-shop, and the initMAX Portal. The simulated request links order preparation, a product lookup in the Portal catalog, and a test payment. These are synthetic OpenTelemetry data, not a record of a real purchase, outage, or the exact production architecture.

The service filter searches within a trace, while the list shows the whole request. With Service name = Payment provider (demo) and Min. duration = 1s, the rows therefore show initMAX web, where the simulated request started. The number 6 is the span count; the red 4 is the number of error spans. Open the detail to see where waiting for the test payment service delayed the itemMAX PRO purchase.

Trace detail: span tree and timeline

In APM > Traces, you can open the details of an entire trace. Instead of separate rows, you get a span tree and a waterfall timeline: relationships between operations on the left, start times and durations on the right. Expand a branch to inspect child calls, or select a time range to focus on one part of the request.

• Span tree shows parent-child relationships between operations. It lets you follow a request across services when instrumentation propagates the trace context.
• Waterfall shows which operations ran sequentially and which overlapped. Adding every span duration together therefore does not give the total request duration.
• Span details includes the operation name, service, scope, timestamp, and duration. It also shows resource attributes, span attributes, and events recorded within the span.

The selected Payment provider (demo) / Authorize payment (demo) span shows the duration, HTTP status 502, and a payment.timeout event. Resource attributes describe the service and environment, such as deployment.environment.name=demo and the nyc site. Span attributes belong to the individual operation: here, the itemMAX product, PRO edition, and a test order. Events add records within the span: TimeoutError, retry.count=2, and gateway=demo-provider. Instrumentation supplies these details; Zabbix does not infer them from duration.

For a slow checkout, start by filtering the service and longer durations. The trace detail then shows whether most of the time was spent querying a database, waiting for a payment gateway, or processing the application itself. The selected span attributes and events provide specific error context; the timeline does not automatically identify the root cause.

In APM > Logs, the same Trace ID finds the test payment-service message: DEMO: itemMAX PRO payment timeout; order returned HTTP 502. The filter connects the request path through the website and e-shop with its application log. Severity, message body, and attributes help explain what happened during that request.

APM > Metrics adds operational context. The Gauge metric eshop.checkout.queue.depth reports waiting orders, alongside simulated active product-page requests and Portal downloads. Unlike a trace, these metrics describe service state over time, not the path of one request. The metric name, service, and attributes identify the relevant time series.

APM data source: connecting to telemetry in ClickHouse

The views read from a global APM data source configured in Administration > Data source > APM: database type (ClickHouse), URL, authentication (username and password, or none), database name, and for HTTPS the certificate and hostname verification. It is the same ClickHouse the proxy writes to, just from the frontend’s point of view; the data sits in the standard tables of the OpenTelemetry ClickHouse exporter (otel_traces, otel_logs, and otel_metrics_*), so other tools can read it as well.

The frontend data source does not replace TelemetryProvider in the server or proxy configuration. The frontend uses it to browse data, while the server and proxy use it to execute Telemetry query items. All components need access to the intended telemetry database. The history* tables of the ClickHouse history backend do not replace the telemetry tables.

This is the ClickHouse configuration for APM, not the backend for ordinary item history. The history backend is covered in a separate chapter. Both uses can share a database cluster, but they have separate configurations and different tables.

Processing: the Telemetry query item type

The new Telemetry query item type connects the OpenTelemetry world with classic Zabbix. Alongside the item key, you compose a query: category (Traces, Metrics, Logs), for metrics their type (Sum, Gauge, Histogram, or Exponential histogram), the columns to read, aggregated columns with a function and alias, and conditions on attributes with And/Or logic or a custom expression. Three time parameters define how the query is evaluated: Granularity (size of the aggregation bucket), Time shift (shifting the window back), and Lookback limit (how far back to catch up unprocessed intervals).

The result is an ordinary item value, so triggers, graphs, dashboards, and escalations all work on top of it. A typical example: the 95th percentile of the initMAX e-shop service response time in minute-sized intervals as a numeric item with a trigger at 800 ms. Zabbix server (or proxy) needs its own TelemetryProvider in the configuration for this, and these queries have a separate timeout, timeout_telemetry_query.

• Granularity defines the aggregation interval. A value of 1m gives minute-sized results even if the item is checked every 30s.
• Time shift moves the processed interval into the past. For example, 15s leaves time for data arriving in ClickHouse with a short delay.
• Lookback limit defines how far back unprocessed intervals can be caught up. It is not the data retention period in ClickHouse.

Dedicated processes controlled by StartTelemetryQueryPollers execute the queries. Their utilization can be monitored just like that of other Zabbix processes.

Granularity alone does not guarantee a complete, closed interval. When the item update interval is shorter than the granularity, query windows can overlap; the form displays a warning. A Time shift that is too short can also include only the data that has arrived so far. For counts and percentiles, configure timing according to actual ingestion delay, not just the desired graph refresh rate.

Demo: from traces to a trigger

We tried the whole chain with a simulated itemMAX PRO purchase: data passes through the Zabbix proxy OTLP/gRPC collector into ClickHouse, and the server calculates Telemetry query items from it. Order-preparation p95 uses Traces, aggregations of percentile(Duration, 95), avg(Duration), and count, and conditions of ServiceName equals initMAX e-shop and SpanName equals Prepare itemMAX PRO order. Both granularity and the update interval are 1m; Time shift is 2m to allow for data arriving in export batches. Other spans of the same service are therefore excluded from order latency and counts.

The server translates the query into ClickHouse SQL and returns an aggregation result as JSON, for example {"columns": {"p95": 1438000000, "avg": 1386000000, "cnt": 29}}. Duration is in nanoseconds. A JSONPath preprocessing step of $.columns.p95 and a Custom multiplier of 1.0E-6 convert p95 to milliseconds; the item uses the unit ms. The same approach provides average latency, order counts, test payment-service p95, and failed order counts.

A plain count over traces counts spans, not automatically unique orders. The initMAX e-shop service has three spans in one journey. The example therefore also selects SpanName equals Prepare itemMAX PRO order: exactly one order-preparation span. Failed orders add StatusCode equals Error. Without the operation condition, internal catalog and payment-service calls would also be included.

Triggers work on top of these items like any others: last(/initMAX digital experience demo/apm.eshop.latency.p95)>800 watches order-preparation p95, while last(/initMAX digital experience demo/apm.eshop.errors)>=3 watches failed orders in a minute-sized interval. When the test payment service slows down in the simulated workload, latency rises in the graph and a problem appears in Problems with the service=initMAX e-shop tag. Find the request in APM > Traces by time, service, or Trace ID. A problem tag alone does not create an automatic link to a specific trace.

What it means in practice

For teams that already instrument their applications with OpenTelemetry, 8.0 means infrastructure monitoring and APM in one tool, with the same users, permissions, and notifications. Keep in mind that it brings a new building block for APM, ClickHouse, and with it disk and operational demands. A sensible start is one proxy with the collector for one environment and a few Telemetry query items on key services; the Traces and Logs views then serve to find the root cause when a trigger fires.

ClickHouse is not mandatory for every Zabbix installation, but for this telemetry component. Monitor the volume of traces, metrics, and logs, configure retention, and check Telemetry query poller utilization. Limit sensitive attributes at the instrumentation layer or in the OpenTelemetry Collector.

Design the production APM ClickHouse deployment in advance, including high availability. The proxy writes to it, while the server, optionally the proxy, and the frontend read from it; a storage outage affects collection, queries, and browsing. For critical workloads, plan replicated tables, an available ClickHouse Keeper coordination service, and a stable access endpoint with failover. Simply running two database nodes does not provide HA.

Plan network access, TLS, permissions, and capacity in advance as well. Applications or an OpenTelemetry Collector need access to the proxy over OTLP/gRPC (TCP 4317 by default); the proxy, server, and frontend each need their own HTTP(S) connection to ClickHouse. Include internal replica and Keeper traffic, backups, retention, and outage testing. High availability is neither a backup nor a guarantee of zero telemetry loss; write, replication, and exporter queue settings also matter.

Security and control: Vault AppRole, feature flags, API disabled by default

Zabbix 8.0 brings several changes that are invisible on a dashboard but matter to anyone running Zabbix for multiple teams or customers: safer defaults (API disabled in roles, no legacy protocols on the trapper), better handling of secrets (HashiCorp Vault AppRole), and tools to trim an installation down to what the operator really wants to allow (feature flags, regular expressions for agent keys, restricting users to specific proxies).

HashiCorp Vault: AppRole instead of a token

Logging in to HashiCorp Vault used to require a static token in both the server and the frontend configuration. 8.0 adds AppRole: the server gets VaultAppRoleID and VaultAppSecretID, the frontend $DB['VAULT_APP_ROLE_ID'] and $DB['VAULT_APP_SECRET_ID'], and it requests the token itself. For the security team this is the standard way to issue Zabbix an identity with a limited policy and rotate the secret ID, instead of a long-lived token in a file.

### zabbix_server.conf
Vault=HashiCorp
VaultURL=https://vault.example.com:8200
VaultDBPath=secret/zabbix/db
VaultAppRoleID=8a1c2f7e-0b3d-4c5e-9f10-1a2b3c4d5e6f
VaultAppSecretID=...

The frontend setup wizard has a new Vault authentication type: Token / AppRole switch in the Configure DB connection step. The same option applies to the ClickHouse password of the APM data source (vault_path= in TelemetryProvider).

API disabled by default

New user roles have Access to API disabled, including the Super admin type. Integrations, scripts, or our Zabbix MCP server require API access to be enabled explicitly in the role. An empty allow list now permits no API methods. When using allow-list mode, add the required methods; enabling API access alone is not enough. Existing roles retain their API access setting during an upgrade, but the new empty-allow-list behavior also applies to them. Check both parts of the permissions before upgrading.

Feature flags: system-level limits on frontend features

zabbix.conf.php gains a $ZBX_FEATURE_FLAGS array that switches off whole frontend features at the system level, regardless of user permissions:

$ZBX_FEATURE_FLAGS['modules_config_enabled'] = false;   // block management; active modules remain loaded
$ZBX_FEATURE_FLAGS['http_auth_enabled'] = false;        // no HTTP authentication
$ZBX_FEATURE_FLAGS['media_type_denylist'] = ['script', 'webhook'];  // no editing of selected media types
$ZBX_FEATURE_FLAGS['banners_enabled'] = false;          // no informational banners

modules_config_enabled=false hides the Modules page and blocks module management through the frontend and corresponding API methods. It does not automatically uninstall or disable already active modules. Loading modules is a separate operation based on their stored status and permissions. Similarly, media_type_denylist restricts editing selected media types, not delivery of already configured notifications. This lets the operator centrally restrict configuration changes, including those made by administrators.

The other switches have different meanings: http_auth_enabled=false disables HTTP authentication itself, not just its settings page. banners_enabled=false disables informational banners. Distinguish restrictions on configuration management from disabling a feature itself.

Trapper without legacy protocols and regular expressions for agent keys

The server and proxy trapper no longer accepts the legacy plain-text and XML protocols used before Zabbix 1.6. This is not a blanket removal of all pre-4.x versions. Before upgrading, check very old agents and custom senders using these historical formats and replace them with a supported client or the current Zabbix protocol.

The minimum compatible classic Zabbix agent version therefore rises from 1.4 to 1.6. This does not change the minimum agent 2 version, which remains the 4.4 series.

The agent configuration (agent 2 as well) gains AllowKeyRegexp and DenyKeyRegexp. Until now keys could only be allowed with wildcards; now a rule can be written as a PCRE2 expression that must match the whole key. All AllowKey, DenyKey, AllowKeyRegexp, and DenyKeyRegexp rules are merged into one list in the order they appear in the file, and the first match decides:

AllowKeyRegexp=^vfs\.fs\.(size|inode)\[/(var|opt)(/[^,]*)?,.*\]$
DenyKey=system.run[*]

Restricting users to specific proxies

For service providers serving multiple customers on one Zabbix, there is a Proxy access list in the user group: a list of proxies and proxy groups (allow or deny) that the group’s users may assign hosts to and see in discovery. Newly created groups default to allow-list mode, so without an explicit permission a user cannot reach someone else’s proxy; hosts monitored by an inaccessible proxy show up as Inaccessible proxy.

A complementary user-role permission, Select “Server” for monitoring and discovery, controls whether users can assign monitoring directly to the server. In a multi-customer environment, this lets you restrict not only proxy and proxy-group selection but also the option of bypassing those limits by choosing the server. A proxy access list does not by itself grant access to every host; host-group permissions still apply.

Server identity

Every server now has a Zabbix server ID (UUID) shown in System information together with an Export button that exports the system overview including HA nodes. The ID is used by the mobile app to tell instances apart and is handy wherever information from multiple Zabbix instances is collected, for example in support or in an inventory.

What it means in practice

Before the upgrade, review the roles and integrations that use the API and prepare method allow lists. Consider moving the Vault token to AppRole, convert complex AllowKey masks on agents to regular expressions, and in multi-team environments set feature flags and proxy access lists before users start settling into the installation.

Maintenance and suppression: ad-hoc maintenance from a problem, suppression recorded in the event

Maintenance in Zabbix used to mean planning: create a maintenance for a host group in advance, set the window and hope nobody forgets. Zabbix 8.0 adds a second path, ad-hoc maintenance started directly from a problem in a few clicks, extends maintenance targets with triggers and event names, and above all records suppression by maintenance in the event history, so the question “why did I not get a notification” finally has an answer in the UI.

Ad-hoc maintenance straight from Problems

The problem context menu has a new Maintenance section with four options: Suppress host, Suppress trigger, Suppress by event name and Suppress by tags. Each opens the maintenance form already prefilled from the selected problem: name Ad-hoc: event name, start now, end after the default period, and the host, trigger, event name or tags of the problem as the target. Check and save.

The same Suppress trigger link is available in the Update problem dialog, and when updating several problems at once it becomes Suppress triggers with the matching trigger count. The window length comes from the new Default maintenance period field in the user profile (1 hour by default), so an operator who typically resolves incidents within 30 minutes sets 30m and the ad-hoc maintenance never forgets to end on their behalf. The options are shown only to users whose role allows creating maintenance and who have edit rights to the host or trigger in question.

Maintenance on a trigger and on an event name

Besides groups and hosts, the maintenance form gets a new Triggers target and a new Event name condition (Contains / Does not contain). Tag operators gain Does not equal and Does not contain. You can suppress a single trigger on a host waiting for a disk replacement and leave the rest of the monitoring running, or suppress every problem with “certificate expires” in its name across hosts until the certificates are renewed. In the API this maps to the triggerids and event_names parameters of maintenance.create / maintenance.update and selectTriggers, selectEventNames in maintenance.get:

{
  "jsonrpc": "2.0",
  "method": "maintenance.create",
  "params": {
    "name": "Ad-hoc: certificate renewal",
    "active_since": 1788080400,
    "active_till": 1788084000,
    "groupids": ["2"],
    "event_names": [{"operator": 2, "value": "certificate expires"}],
    "timeperiods": [{"timeperiod_type": 0, "period": 3600}]
  },
  "id": 1
}

Suppression by maintenance is visible in the event history

Until now maintenance silently hid a problem and once it ended there was no trace of why a particular event did not trigger an action. In 8.0 the server records every suppression and unsuppression by maintenance as an entry in the event history, together with the maintenance that caused it and the time the suppression was valid until. In Event details it appears in the Actions section as a crossed-out eye icon with the hint Suppressed till … / Maintenance: …, and once the maintenance ends an Unsuppressed by maintenance entry is added. The same information is in the API: event.get with selectAcknowledges returns entries with action 512 (suppressed) or 1024 (unsuppressed), maintenanceid and suppress_until. The change also includes more precise handling of overlapping maintenance periods and of edits to a running maintenance.

Proxy group condition in discovery and autoregistration

Network discovery and autoregistration actions get a new Proxy group condition type (equals / does not equal). Anyone running proxy groups per site or per customer can now write an action like “put hosts registered through the DC Prague group into the Prague host group and link template X” without listing individual proxies, and nothing needs to change when a proxy is added to the group. The Proxy condition in autoregistration was also fixed to behave the same way as in discovery.

What it means in practice

Give users a sensible Default maintenance period and teach operators to use Suppress trigger instead of disabling triggers that then never get re-enabled. When auditing incidents, get used to opening Event details: the suppression-by-maintenance record is the new source of truth for why an alert was not sent. And in environments with proxy groups, rewrite discovery and autoregistration actions from a list of proxies to a Proxy group condition.

Widget Scatter Plot

Simply put: you take two metrics (X and Y axis) and Zabbix will plot points for each host/time interval. At a glance, you can see correlations (or the lack of them), clusters of problematic machines, and anomalies that could easily be missed in a classic time-series chart.

Benefits

• Metric relationships: e.g., “when CPU increases, does RAM also increase?”
• Outliers: quickly detect servers that stand out.
• Visual triage: instantly see where to focus first.

How it works

• Datasets: multiple sets; each has an X-Axis item and a Y-Axis item.
• Host filtering: Host patterns / Host groups / Host tags.
• Aggregation: Aggregation interval (e.g., 1m) + function (e.g., avg) → one point per window.
• Appearance: choose marker and size; tooltips with values; time shift for period comparison.

Thresholds

Combined conditions for X and Y change the point’s color, e.g., X ≥ 5 AND Y ≥ 36. Multiple rules = multiple colors → anomalies become instantly visible (see image).

Example Scenarios

• CPU load vs. Memory usage
  X axis: average CPU load
  Y axis: percentage of RAM used
  → Quickly shows whether hosts with high CPU also have high RAM usage. Great first diagnostic for “CPU bound” vs. “RAM bound.”
• Disk usage vs. I/O latency
  X axis: disk utilization (%)
  Y axis: latency (ms)
  → Identifies servers with overloaded storage. The combination of high utilization + high latency is a red flag for I/O.
• Network traffic vs. Error rate
  X axis: outgoing/incoming traffic (bps)
  Y axis: error rate (dropped packets, errors)
  → Finds machines with low traffic but many errors – typically bad links, duplex, MTU, or driver issues.
• Response time vs. Availability (services/apps)
  X axis: average response time (ms)
  Y axis: availability (%)
  → Differentiates “slow but stable” vs. “fast but unreliable” services. A strategic view for prioritizing team effort.

ClickHouse backend and significant improvements for Elastic

A major new feature is support for ClickHouse as an optional storage backend for historical data. The main motivation is clearly its close connection to the new support for JSON data types-with this volume and structure of data, an analytical backend like ClickHouse makes perfect sense.

The concept and configuration are very similar to what many of you already know from the optional Elastic integration. Zabbix can store historical data in an alternative backend without changing the core architecture. ClickHouse can store all history data types except BIN, which covers the vast majority of both common and advanced use cases.

A big advantage is that you can combine Elastic and (now) ClickHouse and split data types based on what makes the most sense-while keeping PostgreSQL as the primary backend for most standard history.

A typical scenario could be, for example:

• LOG / TEXT / CHAR → Elastic (search, full-text, log analytics, and text-based observability queries)
• Numeric data (float/uint) → PostgreSQL (a stable, proven time-series backend for classic metrics and trends; simplicity, compatibility, and battle-tested operation)
• JSON → ClickHouse (high analytical performance for semi-structured data, aggregations, filtering, and wide queries over JSON structures)

And of course, you can adjust the strategy based on your priorities-e.g., if you want to push as much as possible to an analytical backend, or if you prefer the simplest architecture and use ClickHouse only where it brings the biggest impact (typically JSON).

Frontend configuration (Zabbix UI / frontend)

Frontend configuration is defined in /etc/zabbix/web/zabbix.conf.php using the $HISTORY_PROVIDERS array. Each backend (ClickHouse, Elastic) is listed as a separate item in this array-therefore the individual blocks are separated by commas (standard PHP syntax). In practice, you can set ClickHouse as the primary provider for selected value types and add another provider (e.g., Elastic) right below it for str.

Server configuration (Zabbix server)

The second part of the configuration is in /etc/zabbix/zabbix_server.conf, where individual providers are defined on separate lines using the repeated HistoryProvider directive. Unlike the frontend, this is not a “list of items” but a configuration in the form provider;options, where the options themselves (url=..., db=..., username=...) are comma-separated.

Using these backends is also very easy to verify directly in the Zabbix server log-right at startup, Zabbix prints the list of active history providers (including the detected version and assigned value_types), so you immediately know where each type of historical data is being stored.

In the frontend, the data looks exactly the same-there is no UI-level difference whether historical data is stored in PostgreSQL, ClickHouse, or Elastic. Zabbix transparently displays the latest values, history, and graphs regardless of the backend used; the only exception is BIN values, which remain stored in the server’s primary database (PostgreSQL/MySQL).

Elasticsearch

The Elastic backend has also undergone significant internal changes-the biggest difference is in the way it communicates. It now relies more on connection reuse and other optimizations in the network layer and request handling. As a result, this backend is noticeably faster from Zabbix’s perspective, especially in environments with a high query rate and a large volume of stored data.

Multi-host connection string for PostgreSQL backend

For us, this is one of the best practical improvements to the PostgreSQL backend so far. The ability to specify multiple host:port entries in DBHost (comma-separated) and let Zabbix automatically find the first available read-write node at startup significantly simplifies deployment and operations-especially in HA environments. In practice, this often means fewer dependencies on an external load balancer and a cleaner, more self-contained configuration directly within Zabbix.

New option to store data in JSON format

We’ve finally got it: in Zabbix’s (almost) native JSON world, there is now an option to store such data directly in the database – in JSON format. The feature is available on both the proxy and the server side. Conceptually, it’s similar to the Binary storage type we already know (used, for example, for storing screenshots). Partitioning support for the new table is included as well, and the change is also reflected in the Elastic implementation.

One more important advantage: unlike Binary storage, this type can be used not only for master items, but also for dependent items.

We see the primary use case in scenarios with a large number of master items. The maximum size of stored data per single write is 128 MiB.

Just like with the Binary type (available since Zabbix 7.0), it is not possible to create triggers for this data type – and that’s not the purpose of storing data this way. The reason is that such triggers could put an extreme load on the server’s value cache. So this is primarily a practical capacity/performance limitation (to ensure the data fits into the memory used by the value cache), rather than something that would be impossible to implement technically.

Dashboard export and import

Dashboard export and import are finally available. You could achieve something similar via the API before, but you had to map individual entities precisely by their IDs – otherwise the import would fail.

Now the UI provides two buttons: one for Export (in the familiar Zabbix export format) and one for Import.

You’ll find the Import button in the top-right corner of the dashboards overview, right next to Create dashboard.

The import process itself is straightforward: you can create entirely new dashboards, and if they already exist, you can update the existing ones. The import also supports pages, if you use them within your dashboards.

During import, individual objects are not matched by ID, but by name. In our example, the host was renamed from “Zabbix server” to “Zabbix server RENAMED”, and the system was then unable to find it. The fix is straightforward: you can adjust the mapping directly in the UI during import, or by editing the exported file.

Before the actual import, you’ll also see a summary of what will be added, removed, and updated – including the specific changes.

GeoMap Clustering

In the GeoMap widget, you can now configure different host clustering behavior for your maps. You can choose between Auto (the previous/default behavior) and a new Zoom level option. With Zoom level, clustering changes at a defined zoom threshold – for example, if the threshold is set to 8, only a few host markers split into individual elements when you zoom in; if you lower it to 5, many more markers remain clustered, so the map stays grouped and cleaner until you zoom further in.

Example video of GeoMap clustering

Visual Inherited Tag Indicator

Zabbix now makes inherited tags a first-class part of the UI, so you can immediately tell whether a tag comes from a template/parent object or if it was created directly on the current level. This is especially handy in large environments where many objects share the same names and you rely on tags for routing, filtering, and consistent classification across hosts, templates, items, and triggers.

In the list views, inherited tags are marked with a small page/document icon on the left side of the tag pill, and when you hover over it you’ll see a tooltip like “Inherited tag” (as highlighted in the screenshot). Tags without this icon are not inherited – they were added directly at that level. In the example below, most tags are inherited, while initMAX is a non-inherited tag created locally, making the difference instantly visible.

Add custom tags to triggers created from trigger prototypes

This feature allows you to assign custom tags to triggers that are created from trigger prototypes.

It is especially useful for controlling notifications (send / do not send alerts based on tags) and for labeling triggers by specific services, teams, or use cases, enabling more precise alert routing, filtering, and service-level correlation.

Customizable table views on selected pages

This feature lets you customize list tables on supported pages via the column settings in the top-right corner. You can show or hide entire columns and resize their widths; renaming is currently available only for duplicated tag columns (as shown in the screenshot).

Where it’s available:

• Monitoring → Hosts
• Monitoring → Latest data
• Monitoring → Problems
• Data collection → Hosts
• Data collection → Templates

All changes are stored in your user profile, so the layout is personal and not shared with other users. We also plan to update our User Filter Manager (https://www.initmax.com/product/user-filter-manager/) to support this functionality as well.

In the second screenshot, you can see an example of a duplicated “Tags” column, where we can apply filtering and also rename that duplicated tag column. This is a really cool feature and makes it much easier to keep tag-heavy views clean and focused.

Here’s a short video showing how you can resize columns and hide them in the Triggers view.

Storing SAML certificates directly in the database

You can now configure Zabbix to store SAML certificates directly in the database. Simply set the following option in the frontend configuration file (typically /etc/zabbix/web/zabbix.conf.php):

$SSO['CERT_STORAGE'] = 'database';

This eliminates the need to upload certificates directly to the server’s file system. This solution brings several benefits, especially:

• Easy configuration directly via the web interface.
• Unified certificate management in High Availability (HA) deployments.
• Simplified administration of the entire SAML configuration.

Overview of minor improvements

Audit log export to CSV

The audit log is getting CSV export. It is a smaller change, but a very useful one in practice. In larger installations, audit records are often handed over outside Zabbix, archived, compared, or used during change reviews. Direct export reduces the need for manual copying or additional scripts.

Safer default settings for trapper items

Zabbix adds a default value for Allowed hosts in trapper items and introduces the global macro {$TRAPPER.ALLOWED_HOSTS}. This helps especially with templates, imports, and bulk management, where it is better to have a unified and easily adjustable default mode instead of manually filling the same setting in many places.

New agent keys net.if.get and vfs.dev.get

The agent gets two new discovery keys: net.if.get returns network interfaces and vfs.dev.get block devices (Linux and AIX) as a single JSON with all attributes, with no need to assemble them from several items. The Linux and AIX by Zabbix agent templates already use them, and they are handy for custom LLD rules too.

vfs.fs.get also gains mode and mountpoint parameters to select the output mode and a specific mount point. Operating-system templates use it for filesystem collection; one JSON response can provide data for discovery and dependent items.

DNS via c-ares with caching and failover

Server, proxy and agent can resolve DNS through the c-ares library with caching and failover between resolvers (a build option, also available for the Windows agent). An outage or slowdown of one DNS server no longer stalls polling of hosts configured by name.

SNMPv3 engine ID caching

SNMPv3 caches the engine ID of a device after the first discovery and no longer needs the initial exchange before every request. On large SNMP networks that means noticeably fewer packets and faster polling.

SNMP: Retries and macros for Max repetition count

SNMP interfaces gain Retries for the retry count of native bulk requests. Max repetition count now accepts user macros. This lets you tune polling for slower or constrained devices and manage bulk-request size through macros instead of editing each interface separately.

Monitoring of the trend function cache

The internal item zabbix[tcache,cache,paccessed] reports the share of trend function cache entries accessed in the past 24 hours. Alongside pitems and pmisses, it is collected by the server health templates. Both server and proxy health templates now also monitor Telemetry query poller utilization, helping identify bottlenecks when processing APM items.

HTTP agent and LLD: more lenient inputs

The HTTP agent accepts formally invalid JSON or XML in the request body, an HTTP agent discovery rule has an option to convert the response to JSON, and LLD macros are resolved in nested JSON in prototypes. VMware *.alarms.get items return entity details and the real host name.

Agent 2: Oracle over TLS, Ceph as a loadable plugin

The agent 2 Oracle plugin supports TCPS (TLS), the Ceph plugin is now loadable, and the MySQL plugin uses SHOW REPLICA STATUS alongside the older SHOW SLAVE STATUS, so it works on current MySQL versions.

HTTP redirects and agent 2 profiling

The web.page.get, web.page.perf, and web.page.regexp keys gain an optional redirect_limit parameter controlling how many HTTP redirects are followed. Agent 2 also adds a pprof profiler for diagnosing CPU and memory usage. It is a tool for investigating agent behavior, not application profiling in APM.

New functions jsonpath, xmlxpath, contains and substring

History and macro functions gain jsonpath() and xmlxpath() for extracting values from JSON or XML content, plus contains() and substring() for working with text. JSONPath and XMLXPath in trigger expressions operate on string item types (Character, Text, and Log). This does not add direct trigger support to the new JSON storage type; preprocessing can still extract the required values into dependent items.

Preprocessing diagnostics and the post-login page

The server and proxy provide more detailed preprocessing diagnostic output to help investigate item-processing bottlenecks. A user role can also enforce a post-login page, such as a shared operations dashboard, so the initial team view does not depend on individual preferences.

Inline form validation

Practically every form in the frontend has been rewritten to use inline validation: errors appear next to the field immediately, not after submitting. Discovery rules and host prototypes open in a modal window like the rest of the configuration, a Skip to main content link was added for screen readers and keyboard users, and the tag filter in Problems lost its redundant radio buttons (an empty tag list means all tags).

Inverted values in graphs

The Graph widget has an Invert values option per data set: the metric is drawn mirrored below the axis, so inbound and outbound traffic or disk reads and writes fit into one graph without overlapping.

Item patterns in the Top items widget

Columns of the Top items widget accept item-name patterns instead of selecting individual items. For example, Checkout:* includes items whose names start with Checkout: across the selected hosts. The pattern matches the name, not the item key. Item tags can narrow the selection further, with sorting and the number of displayed items configured separately.

Dashboard slideshow off by default

Newly created dashboards have Start slideshow turned off, and the slideshow can be enabled with a URL parameter (&slideshow=1). Handy for shared links to screens in an operations centre, where one link should rotate and another stay put.

Import and export of global regular expressions

Global regular expressions get Import and Export in the same YAML/JSON/XML format as templates, so they can be versioned and moved between instances like the rest of the configuration.

Create proxy in Cloud and the Subscriptions menu

The proxies page gets a Create proxy in Cloud button for installations connected to Zabbix Cloud, and in the help menu the obsolete Support entry is replaced by Subscriptions.

Email threads for problem and recovery

Emails from Zabbix carry a Message-ID header and a properly filled In-Reply-To, so a problem and its recovery collapse into one thread in the mail client. The {EVENT.RECOVERY.TAGS} macro is now resolved when a problem is closed manually as well.

Housekeeper: deleting events and deferred deletion

When a trigger is deleted, the housekeeper removes its events too, not only problems, and deleting large volumes of history after items are removed runs through a deferred-task table, so deleting an item in the UI no longer waits for the database.

What to watch out for when upgrading

Test the upgrade against a copy of the database and configuration first; check integrations, custom modules, and role behavior as well as availability. APM requires extra operational components only when you choose to use it. The component versions below describe the supported Zabbix 8.0 range, not a recommendation to run an older unsupported database.

Minimum versions

Supported ranges are PHP 8.2–8.5, MySQL and Percona 8.4–9.7, MariaDB 10.11–12.3, PostgreSQL 15–18, and TimescaleDB 2.20–2.29. These are supported versions, not the lower technical limit at which the server can still start. The optional ClickHouse backend for ordinary item history supports 25.8.22–26.4; this configuration is separate from the APM telemetry store. Choose supported stable versions for production and verify PostgreSQL and TimescaleDB compatibility with each other.

Removed API methods

The host.massupdate, template.massupdate, hostgroup.massupdate, templategroup.massupdate and hostinterface.replacehostinterfaces methods are removed; use the regular *.update and massadd / massremove instead. New user roles have API access disabled (see the security chapter).

Removed macros

The long-deprecated {ACK.DATE}, {ACK.TIME}, {ACK.MESSAGE}, {EVENT.ACK.HISTORY}, {IPADDRESS}, {HOSTNAME}, {TRIGGER.KEY}, {TRIGGER.COMMENT}, {STATUS}, {PROFILE.*} and {USER.ALIAS} are gone. Before upgrading, review media types, actions and scripts and replace them with the current equivalents ({EVENT.UPDATE.*}, {HOST.IP}, {HOST.NAME}, {ITEM.KEY}, {TRIGGER.DESCRIPTION}, {TRIGGER.STATUS}, {INVENTORY.*}, {USER.USERNAME}).

Protocols

Support for the legacy plain-text and XML protocols from before Zabbix 1.6 has been removed. Check very old agents and custom senders; ordinary installations using the current Zabbix protocol do not need to change their value format.

The minimum compatible classic Zabbix agent version therefore rises from 1.4 to 1.6. This does not change the minimum agent 2 version, which remains the 4.4 series.

New and updated templates

Alongside new integrations, Zabbix adds OpenTelemetry templates. They provide ready-made items, discovery, and triggers instead of requiring every telemetry query to be assembled manually.

New templates:

• OpenTelemetry: Generic OpenTelemetry by OTLP (a general view of traces, metrics, and logs), Proxmox VE by OTLP (virtualization-node metrics), Envoy Proxy by OTLP (proxy traces, metrics, and logs), and OpenRouter traces by OTLP (model request behavior and errors).
• Cloud and costs: Oracle Cloud Costs by HTTP, GCP Cost monitoring by HTTP, Google Cloud Storage by HTTP, GCP Cloud Run Service by HTTP, GCP Application Load Balancer by HTTP, Oracle Cloud Load Balancer by HTTP, Azure Container Apps by HTTP, Azure Sentinel by HTTP
• Databases: MariaDB by Zabbix agent / agent active / by ODBC, Percona by Zabbix agent / agent active / by ODBC
• Containers and virtualization: Kubernetes Cluster by HTTP, Podman by Zabbix agent / agent active / by HTTP, Microsoft Hyper-V by SSH (cluster and standalone)
• Applications and AI: OpenAI Platform by HTTP, Claude API by HTTP, GitHub organization by HTTP (including Copilot), GLPI by HTTP
• Network: Ribbon SBC Edge / SWe core / SWe CE by HTTP, VeloCloud SD-WAN Edge by HTTP, Huawei AR600 by SNMP, Cradlepoint NCM v2 by HTTP and Cradlepoint NCM v2 device by HTTP
• Other: Domain expiration by RDAP, webhook for IBM Maximo (service request creation)

Updated templates:

• Linux, Windows, and AIX: filesystem collection through vfs.fs.get; Linux also gains new dashboards, net.if.get, and vfs.dev.get, while AIX collects block-device data through vfs.dev.get.
• MySQL by Zabbix agent and by ODBC (new metrics, discovery of tables and replicas, new dashboards, new syntax support), PostgreSQL by Zabbix agent and by ODBC
• Proxmox VE by HTTP (nested LLD, SMART status mapping), VMware (alarm discovery), Veeam Backup & Replication and Veeam Backup Enterprise Manager by HTTP (updated for Veeam 13.1).
• Microsoft 365 reports by HTTP (Copilot), GitHub repository by HTTP
• Zabbix server health (trend function cache) and both server and proxy health templates (Telemetry query poller utilization).
• SNMP templates (better device uptime trigger), Cisco (version regex), Meraki (status mapping, new trigger), Ciena 3906 by SNMP (filesystem, CPU load), Vyatta Virtual Router by SNMP
• AWS Cost Explorer and Azure Cost Management by HTTP (new dashboards), shared multi-cloud dashboards for virtual machines and costs.
• Redis by Zabbix agent 2 (authentication macros), Ceph by Zabbix agent 2 (native connection mode)
• Nextcloud by HTTP, NetApp AFF A700 by HTTP, MSSQL, Stormshield SNS by SNMP, RabbitMQ (minor fixes)

Zabbix downloads and other useful links

• Download Zabbix 8.0 LTS: official Zabbix packages.
• Build from source: Zabbix source packages.
• Documentation: What’s new in Zabbix 8.0.

As official partners and strong enthusiasts of the Zabbix platform, we offer comprehensive, top-level services in all areas of Zabbix monitoring. If you’re interested in a live demonstration of Zabbix installations at our customers’ sites, we’d be happy to show you Zabbix in action.