This is an old revision of the document!
Several updates have been made in the new version to the high-level overview of the monitored infrastructure offered by the services functionality.
The availability of services in previous Zabbix versions depended on triggers and their states. In the new version that is replaced by a tag-based mapping to problems for the respective service.
The configuring and viewing of services is now merged in Monitoring → Services, and a separate section for service configuration no longer exists in Configuration → Services.
In service configuration, hard and soft dependencies no longer exist. Instead, a service can have multiple parent services.
There are new status calculation rules and flexible additional rules for calculating the status of a parent service based on the statuses and weight of direct children. It is now also possible to set flexible rules for propagating a service status to parent services.
Flexible permissions to services have been implemented on user role level. Read-write or read-only access can be granted to none, all or selected services (based on name or tags).
It is now possible to receive automated alerts about service status changes, similar to the alerts about trigger status changes.
A new service action type has been added to the Actions menu. Service actions may include steps for problem, recovery, and update operations related to services. It is possible to configure two types of actions: sending a message to the specified recipients and executing a remote command on Zabbix server. Similarly to trigger actions, service actions support problem escalation scenarios.
New message templates Service, Service recovery, and Service update have been added to media types and should be defined to enable correct sending of notifications for service actions.
A new expression syntax for triggers and calculated items was introduced in Zabbix 5.4. However, the old syntax still remained in use in simple macros. In the new version, the functionality of simple macros has been transferred to expression macros and the new expression syntax is used. See the comparison below for details of the change:
|In Zabbix 6.0||Before Zabbix 6.0|
Example of an expression macro in the new version.
Example of a simple macro in previous versions.
The existing simple macros will be converted to expression macros during the upgrade. The scope of expression macros covers the same that was offered by simple macros. Thus, expression macros can be used in:
It is now possible to check for monotonic increase or decrease in item values using the new monoinc() or monodec() history functions.
Several new items have been added to Zabbix agent/agent 2:
modeparameter (crc32, md5, sha256)
modeparameter (bytes or lines)
For more details see agent items.
Custom password complexity requirements can now be provided for Zabbix internal authentication method. To prevent Zabbix users from setting weak passwords, it is possible to enforce the following restrictions:
Zabbix get and Zabbix sender utilities now support a
-t <seconds> or
--timeout <seconds> timeout parameter. The valid range is:
Zabbix Prometheus preprocessing query language now supports two additional label matching operators:
Audit log now supports filtering records by frontend operation that caused these entries. If several log records have been created as a result of a single operation, for example, linking/unlinking a template, such records will have the same Recordset ID.
New section Audit log has been added to the Administration→General menu allowing to enable or disable audit logging. Housekeeping settings for audit, previously located under the Housekeeper section, have also been moved to the new Audit log section.
The default language of Zabbix web interface has been changed from British to American English. Support of British English has been dropped.
Audit log functionality has been reworked significantly. The updated Audit log contains records of all configuration changes of Zabbix objects and has an improved filter, which allows to view records grouped by frontend operation. Logging can be switched on or off in the Administration→General menu section.
In order to implement these changes, the previously existing database structure had to be reworked. During an upgrade DB tables
auditlog_details will be replaced by the new table
auditlog with a different format. Existing audit log records will be deleted.