This is a translation of the original English documentation page. Help us make it better.
Table of Contents

8 Bekende problemen

Proxy-opstart met MySQL 8.0.0-8.0.17

zabbix_proxy op MySQL-versies 8.0.0-8.0.17 mislukt met de volgende "toegang geweigerd" fout:

[Z3001] verbinding met database 'zabbix' mislukt: [1227] Toegang geweigerd; u heeft (ten minste een van) de SUPER, SYSTEM_VARIABLES_ADMIN of SESSION_VARIABLES_ADMIN privileges nodig voor deze bewerking

Dit komt door MySQL 8.0.0 die begint met het afdwingen van speciale rechten voor het instellen van sessievariabelen. Echter, in 8.0.18 is dit gedrag verwijderd: Vanaf MySQL 8.0.18 is het instellen van de sessiewaarde van deze systeemvariabele niet langer een beperkte bewerking.

De workaround is gebaseerd op het verlenen van aanvullende rechten aan de gebruiker zabbix:

Voor MySQL-versies 8.0.14 - 8.0.17:

grant SESSION_VARIABLES_ADMIN on *.* to 'zabbix'@'localhost';

Voor MySQL-versies 8.0.0 - 8.0.13:

grant SYSTEM_VARIABLES_ADMIN on *.* to 'zabbix'@'localhost';

Upgrade

SQL mode setting for successful upgrade

The sql_mode setting in MySQL/MariaDB must have the "STRICT_TRANS_TABLES" mode set. If it is absent, the Zabbix database upgrade will fail (see also ZBX-19435).

Upgrade met MariaDB 10.2.1 en eerder

Het upgraden van Zabbix kan mislukken als database-tabellen zijn aangemaakt met MariaDB 10.2.1 en eerder, omdat in die versies de standaard rij-indeling compact is. Dit kan worden opgelost door de rij-indeling te wijzigen in dynamisch (zie ook ZBX-17690).

Templates

Template compatibility in dual-stack (IPv4/IPv6) environments

In dual-stack environments (systems configured to support both IPv4 and IPv6), the hostname localhost typically resolves to both IPv4 and IPv6 addresses. Due to the common prioritization of IPv6 over IPv4 by many operating systems and DNS resolvers, Zabbix templates may fail to work correctly if the service being monitored is configured to listen only on IPv4.

Services that are not configured to listen on IPv6 addresses may become inaccessible, leading to monitoring failures. Users might configure access correctly for IPv4 but still face connectivity issues due to the default behavior of prioritizing IPv6.

A workaround for this is to ensure that the services (Nginx, Apache, PostgreSQL, etc.) are configured to listen on both IPv4 and IPv6 addresses, and Zabbix server/agent is allowed access via IPv6. Additionally, in Zabbix templates and configurations, use localhost explicitly instead of 127.0.0.1 to ensure compatibility with both IPv4 and IPv6.

For example, when monitoring PostgreSQL with the PostgreSQL by Zabbix agent 2 template, you may need to edit the pg_hba.conf file to allow connections for the zbx_monitor user. If the dual-stack environment prioritizes IPv6 (system resolves localhost to ::1) and you configure localhost but only add an IPv4 entry (127.0.0.1/32), the connection will fail because there is no matching IPv6 entry.

The following pg_hba.conf file example ensures that the zbx_monitor user can connect to any database from the local machine using both IPv4 and IPv6 addresses with different authentication methods:

# TYPE     DATABASE     USER            ADDRESS          METHOD
         host     all          zbx_monitor     localhost        trust
         host     all          zbx_monitor     127.0.0.1/32     md5
         host     all          zbx_monitor     ::1/128          scram-sha-256

If necessary, you can also use the IPv4 address (127.0.0.1) directly when configuring the PostgreSQL by Zabbix agent 2 template macro for the connection string.

Accidental installation of EPEL Zabbix packages

With EPEL repository installed and enabled, installing Zabbix from packages will lead to EPEL Zabbix packages being installed rather than official Zabbix packages.

In this case uninstall Zabbix packages from EPEL, i.e.:

dnf remove zabbix-server-mysql

Block Zabbix packages from EPEL. Add the following line in the /etc/yum.conf file:

exclude=zabbix7.0*

Install Zabbix server again:

dnf install zabbix-server-mysql

Notice that official Zabbix packages have the word release in their version string:

7.0.0-release1.el8

Zabbix packages for RHEL on Red Hat UBI environments

When installing Zabbix from Red Hat Enterprise Linux packages on Red Hat Universal Base Image environments, ensure access to required repositories and dependencies. Zabbix packages depend on libOpenIPMI.so and libOpenIPMIposix.so libraries, which are not provided by any package in the default package manager repositories enabled on UBI systems and will result in installation failures.

The libOpenIPMI.so and libOpenIPMIposix.so libraries are available in the OpenIPMI-libs package, which is provided by the redhat-#-for-<arch>-appstream-rpms repository. Access to this repository is curated by subscriptions, which, in the case of UBI environments, get propagated by mounting repository configuration and secrets directories of the RHEL host into the container file-system namespace.

For more information, see ZBX-24291.

Expired signing key for RHEL packages

When upgrading Zabbix on Red Hat Enterprise Linux or its derivatives, you may encounter an expired signing key issue for packages on Zabbix repository. When a signing key expires, attempts to verify package signatures will result in an error indicating that the certificate or key is no longer valid. For example:

error: Verifying a signature using certificate D9AA84C2B617479C6E4FCF4D19F2475308EFA7DD (Zabbix LLC (Jul 2022) <[email protected]>):
         1. Certificiate 19F2475308EFA7DD invalid: certificate is not alive
             because: The primary key is not live
             because: Expired on 2024-07-04T11:41:23Z
         2. Key 19F2475308EFA7DD invalid: key is not alive
             because: The primary key is not live
             because: Expired on 2024-07-04T11:41:23Z

To resolve such issues, manually reinstall the latest zabbix-release package for your specific variant of RHEL (replace the link below with the correct one from Zabbix repository).

For example, on RHEL 9, run:

rpm -Uvh https://repo.zabbix.com/zabbix/7.0/rhel/9/x86_64/zabbix-release-latest.el9.noarch.rpm

Then, update the repository information:

dnf update

For more information, see ZBX-24761.

Database TLS-verbinding met MariaDB

Database TLS-verbinding wordt niet ondersteund met de 'verify_ca'-optie voor de DBTLSConnect parameter als MariaDB wordt gebruikt.

Possible deadlocks with MySQL/MariaDB

When running under high load, and with more than one LLD worker involved, it is possible to run into a deadlock caused by an InnoDB error related to the row-locking strategy (see upstream bug). The error has been fixed in MySQL since 8.0.29, but not in MariaDB. For more details, see ZBX-21506.

Globale gebeurteniscorrelatie

Gebeurtenissen worden mogelijk niet correct gecorreleerd als het tijdsinterval tussen de eerste en tweede gebeurtenis zeer klein is, bijvoorbeeld een halve seconde of minder.

Bereik van numeriek (float) gegevenstype met PostgreSQL 11 en eerder

PostgreSQL 11 en eerdere versies ondersteunen alleen een zwevende-kommawaarde bereik van ongeveer -1,34E-154 tot 1,34E+154.

NetBSD 8.0 en nieuwer

Diverse Zabbix-processen kunnen willekeurig crashen bij het opstarten op de NetBSD-versies 8.X en 9.X. Dit komt door de te kleine standaard stapelgrootte (4 MB), die moet worden vergroot door het volgende uit te voeren:

ulimit -s 10240

Voor meer informatie, zie het bijbehorende probleemrapport: ZBX-18275.

Regular expression limitations in Zabbix agent 2

Zabbix agent 2 does not support lookaheads and lookbehinds in regular expressions due to the standard Go regexp library limitations.

IPMI-controles

IPMI-controles werken niet met de standaard OpenIPMI-bibliotheekpakketten op Debian vóór 9 (stretch) en Ubuntu vóór 16.04 (xenial). Om dit op te lossen, moet je de OpenIPMI-bibliotheek opnieuw compileren met OpenSSL ingeschakeld, zoals besproken in ZBX-6139.

SSH-controles

  • Sommige Linux-distributies zoals Debian en Ubuntu ondersteunen geen versleutelde privésleutels (met wachtwoordzin) als de libssh2-bibliotheek is geïnstalleerd vanuit pakketten. Zie ZBX-4850 voor meer details.

  • Bij het gebruik van libssh 0.9.x op bepaalde Linux-distributies met OpenSSH 8 kunnen SSH-controles af en toe "Kan geen gegevens lezen van SSH-server" rapporteren. Dit wordt veroorzaakt door een libssh probleem (meer gedetailleerd rapport). De fout zou verwacht worden te zijn verholpen door een stabiele release van libssh 0.9.5. Zie ook ZBX-17756 voor details.

  • Het gebruik van de pijp "|" in het SSH-script kan leiden tot een foutmelding "Kan geen gegevens lezen van SSH-server". In dit geval wordt aanbevolen om de versie van de libssh-bibliotheek te upgraden. Zie ook ZBX-21337 voor details.

ODBC-controles

  • De MySQL unixODBC-stuurprogramma mag niet worden gebruikt met een Zabbix-server of Zabbix-proxy die is gecompileerd met de MariaDB-connector bibliotheek en vice versa, indien mogelijk is het ook beter om dezelfde connector niet als stuurprogramma te gebruiken vanwege een upstream bug. Voorgestelde configuratie:

    PostgreSQL, SQLite of Oracle-connector → MariaDB of MySQL unixODBC-stuurprogramma MariaDB-connector → MariaDB unixODBC-stuurprogramma MySQL-connector → MySQL unixODBC-stuurprogramma

Zie ZBX-7665 voor meer informatie en beschikbare oplossingen.

  • XML-gegevens die worden opgevraagd van Microsoft SQL Server kunnen op verschillende manieren worden afgekapt op Linux- en UNIX-systemen.

  • Er is opgemerkt dat het gebruik van ODBC-controles voor het monitoren van Oracle-databases met behulp van verschillende versies van Oracle Instant Client voor Linux ertoe leidt dat de Zabbix-server crasht. Zie ook: ZBX-18402, ZBX-20803.

  • Als u de FreeTDS UnixODBC-stuurprogramma gebruikt, moet u een 'SET NOCOUNT ON'-verklaring voorvoegen aan een SQL-query (bijvoorbeeld, SET NOCOUNT ON DECLARE @strsql NVARCHAR(max) SET @strsql = ....). Anders zal het database-monitor-item in Zabbix er niet in slagen om de informatie op te halen met de foutmelding "SQL-query heeft een leeg resultaat geretourneerd".
    Zie ZBX-19917 voor meer informatie.

Onjuiste verzoeksmethodeparameter in items

De verzoeksmethodeparameter, die alleen wordt gebruikt in HTTP-controles, kan na een upgrade van een pre-4.0 Zabbix-versie mogelijk onjuist worden ingesteld op '1', een niet-standaardwaarde voor alle items. Voor details over hoe u deze situatie kunt oplossen, zie ZBX-19308.

Webmonitoring en HTTP-agent

Zabbix-server lekt geheugen op sommige Linux-distributies vanwege een upstream bug wanneer "SSL verify peer" is ingeschakeld in web-scenario's of de HTTP-agent. Zie ZBX-10486 voor meer informatie en beschikbare oplossingen.

Eenvoudige controles

Er is een bug in fping-versies ouder dan v3.10 die duplicaat-echo-antwoordpakketten verkeerd afhandelt. Dit kan onverwachte resultaten veroorzaken voor items zoals icmpping, icmppingloss en icmppingsec. Het wordt aanbevolen om de nieuwste versie van fping te gebruiken. Zie ZBX-11726 voor meer details.

Errors with fping execution in rootless containers

When containers are running in rootless mode or in a specific-restrictions environment, you may face errors related to fping execution when performing ICMP checks, such as fping: Operation not permitted or all packets to all resources lost.

To fix this problem add --cap-add=net_raw to "docker run" or "podman run" commands.

Additionally fping execution in non-root environments may require sysctl modification, i.e.:

sudo sysctl -w "net.ipv4.ping_group_range=0 1995"

where "1995" is the zabbix GID. For more details, see ZBX-22833.

SNMP-controles

Als het OpenBSD-besturingssysteem wordt gebruikt, kan een use-after-free-bug in de Net-SNMP-bibliotheek tot versie 5.7.3 een crash van de Zabbix-server veroorzaken als de parameter SourceIP is ingesteld in het configuratiebestand van de Zabbix-server. Als workaround, stel de SourceIP-parameter niet in. Hetzelfde probleem geldt ook voor Linux, maar dit zorgt er niet voor dat de Zabbix-server stopt met werken. Een lokale patch voor het net-snmp-pakket op OpenBSD is toegepast en zal worden vrijgegeven met OpenBSD 6.3.

SNMP-gegevenspieken

Er zijn pieken waargenomen in SNMP-gegevens die mogelijk verband houden met bepaalde fysieke factoren, zoals spanningspieken in het elektriciteitsnet. Zie ZBX-14318 voor meer details.

SNMP-traps

Het pakket "net-snmp-perl" dat nodig is voor SNMP-traps is verwijderd in RHEL 8.0-8.2 en opnieuw toegevoegd in RHEL 8.3.

Als je RHEL 8.0-8.2 gebruikt, is de beste oplossing om te upgraden naar RHEL 8.3.

Zie ook ZBX-17192 voor meer informatie.

Crash van het alerter proces in RHEL 7

Er zijn gevallen geweest waarbij een Zabbix server alerter proces is gecrasht in RHEL 7. Zie ZBX-10461 voor meer details.

Upgraden van Zabbix agent 2 (6.0.5 of ouder)

Bij het upgraden van Zabbix agent 2 (versie 6.0.5 of ouder) vanuit pakketten kan een foutmelding met betrekking tot een bestandsconflict met betrekking tot plugins optreden. Om de fout op te lossen, maak een back-up van je agent 2-configuratie (indien nodig), verwijder de agent 2 en installeer deze opnieuw.

Op RHEL-gebaseerde systemen, voer het volgende uit:

dnf remove zabbix-agent2
       dnf install zabbix-agent2

Op Debian-gebaseerde systemen, voer het volgende uit:

apt remove zabbix-agent2
       apt install zabbix-agent2

Voor meer informatie, zie ZBX-23250.

Wisselende frontend-lokalen

Er is opgemerkt dat frontend-lokalen zonder duidelijke logica kunnen wisselen, d.w.z. sommige pagina's (of delen van pagina's) worden weergegeven in de ene taal, terwijl andere pagina's (of delen van pagina's) in een andere taal worden weergegeven. Dit probleem kan zich meestal voordoen wanneer er verschillende gebruikers zijn, waarvan sommige één taalinstelling gebruiken, terwijl anderen een andere taalinstelling gebruiken.

Een bekende workaround hiervoor is om multithreading in PHP en Apache uit te schakelen.

Het probleem heeft te maken met hoe de locale-instelling werkt in PHP: locale-informatie wordt per proces bijgehouden, niet per thread. Dus in een multi-threadomgeving, wanneer er meerdere projecten worden uitgevoerd door hetzelfde Apache-proces, is het mogelijk dat de locale-instelling wordt gewijzigd in een andere thread en dat dit invloed heeft op hoe gegevens kunnen worden verwerkt in de Zabbix-thread.

Voor meer informatie, zie gerelateerde probleemrapporten:

  • ZBX-10911 (Probleem met wisselende frontend-lokalen)
  • ZBX-16297 (Probleem met nummerverwerking in grafieken met gebruik van de bcdiv-functie van BC Wiskundefuncties)

Grafieken

Zomertijd

Wijzigingen in de zomertijd (DST) zorgen voor onregelmatigheden bij het weergeven van X-as labels (dubbele datums, ontbrekende datums, enz.).

Som-aggregatie

Bij het gebruik van som-aggregatie in een grafiek voor een periode die korter is dan één uur, worden onjuiste (vermenigvuldigde) waarden weergegeven wanneer de gegevens afkomstig zijn van trends.

Tekst overlapping

Voor sommige frontend-talen (bijv. Japans) kunnen lokale lettertypen leiden tot tekst overlapping in de legenda van de grafiek. Om dit te voorkomen, gebruik versie 2.3.0 (of later) van de PHP GD-extensie.

Logbestandsmonitoring

log[] en logrt[] items blijven logbestanden herhaaldelijk vanaf het begin lezen als het bestandssysteem 100% vol is en het logbestand wordt bijgevoegd (zie ZBX-10884 voor meer informatie).

Trage MySQL queries

De Zabbix-server genereert trage SELECT-queries in het geval van niet-bestaande waarden voor items. Dit probleem doet zich voor in MySQL-versies 5.6/5.7 (voor een uitgebreide discussie, zie ZBX-10652), en in specifieke gevallen kan het ook voorkomen in latere MySQL-versies. Een workaround hiervoor is het uitschakelen van de index_condition_pushdown of prefer_ordering_index optimizer in MySQL. Let op dat deze workaround mogelijk niet alle problemen met trage queries oplost.

Slow configuration sync with Oracle

Configuration sync might be slow in Zabbix 6.0 installations with Oracle DB that have high number of items and item preprocessing steps. This is caused by the Oracle database engine speed processing nclob type fields.

To improve performance, you can convert the field types from nclob to nvarchar2 by manually applying the database patch items_nvarchar_prepare.sql. Note that this conversion will reduce the maximum field size limit from 65535 bytes to 4000 bytes for item preprocessing parameters and item parameters such as Description, Script item's field Script, HTTP agent item's fields Request body and Headers, Database monitor item's field SQL query. Queries to determine template names that need to be deleted before applying the patch are provided in the patch as a comment. Alternatively, if MAX_STRING_SIZE is set you can change nvarchar2(4000) to nvarchar2(32767) in the patch queries to set the 32767 bytes field size limit.

For an extended discussion, see ZBX-22363.

API-aanmelding

Er kunnen veel open gebruikerssessies worden gecreëerd wanneer u aangepaste scripts gebruikt met de user.login methode zonder daaropvolgende user.logout.

Probleem met IPv6-adres in SNMPv3-traps

Vanwege een bug in net-snmp kan een IPv6-adres mogelijk niet correct worden weergegeven bij het gebruik van SNMPv3 in SNMP-traps. Voor meer details en een mogelijke oplossing, zie ZBX-14541.

Ingekorte lange IPv6 IP-adressen in mislukte aanmeldingsinformatie

Een melding van een mislukte aanmeldpoging zal alleen de eerste 39 tekens van een opgeslagen IP-adres weergeven, omdat dat het tekenlimiet is in het databaseveld. Dit betekent dat IPv6 IP-adressen langer dan 39 tekens onvolledig worden weergegeven.

Zabbix-agentcontroles op Windows

Niet-bestaande DNS-vermeldingen in een Server-parameter van het Zabbix-agentconfiguratiebestand (zabbix_agentd.conf) kunnen de responstijd van de Zabbix-agent op Windows verhogen. Dit gebeurt omdat de Windows DNS-cachingservice geen negatieve antwoorden voor IPv4-adressen in de cache opslaat. Voor IPv6-adressen worden echter wel negatieve antwoorden gecachet. Een mogelijke oplossing hiervoor is het uitschakelen van IPv4 op de host.

YAML-export/import

Er zijn enkele bekende problemen met YAML export/import:

  • Foutmeldingen zijn niet vertaalbaar;
  • Geldige JSON met een .yaml-bestandsextensie kan soms niet worden geïmporteerd;
  • Onaangehaalde, leesbare datums worden automatisch omgezet naar Unix-tijdstempels.

Installatiewizard op SUSE met NGINX en php-fpm

De frontend-installatiewizard kan geen configuratiebestand opslaan op SUSE met NGINX + php-fpm. Dit wordt veroorzaakt door een instelling in het bestand /usr/lib/systemd/system/php-fpm.service, waardoor Zabbix niet naar /etc kan schrijven (ingevoerd in PHP 7.4).

Er zijn twee workaround-opties beschikbaar:

  • Stel de ProtectSystem optie in op 'true' in plaats van 'full' in de systemd-eenheid van php-fpm.
  • Sla handmatig het bestand /etc/zabbix/web/zabbix.conf.php op.

Chromium voor Zabbix webdienst op Ubuntu 20

Hoewel de Zabbix-webdienst in de meeste gevallen kan worden uitgevoerd met Chromium, veroorzaakt het gebruik van Chromium op Ubuntu 20.04 de volgende fout:

Kan gegevens niet ophalen: chrome kon niet worden gestart: cmd_run.go: 994:
       WAARSCHUWING: kan geen gebruikersgegevensmap maken: kan 
       "/var/lib/zabbix/snap/chromium/1564" niet maken: mkdir /var/lib/zabbix: toegang geweigerd
       Sorry, home directories outside of /home are not currently supported. See https://forum.snapcraft.io/t/11209 for details.

Deze fout treedt op omdat /var/lib/zabbix wordt gebruikt als de thuisdirectory van gebruiker 'zabbix'.

Aangepaste MySQL-foutcodes

Als Zabbix wordt gebruikt met een MySQL-installatie op Azure, kan een onduidelijke foutmelding [9002] Some errors occurred in Zabbix-logs verschijnen. Deze generieke fouttekst wordt door de database naar de Zabbix-server of -proxy gestuurd. Om meer informatie te krijgen over de oorzaak van de fout, controleer de Azure-logs.

Ongeldige reguliere expressies na overstappen op PCRE2

In Zabbix 6.0 is ondersteuning voor PCRE2 toegevoegd. Hoewel PCRE nog steeds wordt ondersteund, zijn de Zabbix-installatiepakketten voor RHEL 7 en nieuwer, SLES (alle versies), Debian 9 en nieuwer, Ubuntu 16.04 en nieuwer bijgewerkt om PCRE2 te gebruiken. Hoewel dit veel voordelen biedt, kan overschakelen naar PCRE2 ertoe leiden dat bepaalde bestaande PCRE-reguliere expressiepatronen ongeldig worden of zich anders gedragen. Dit heeft met name invloed op het patroon ^[\w-\.]. Om deze reguliere expressie weer geldig te maken zonder de betekenis te beïnvloeden, verandert u de uitdrukking in ^[-\w\.]. Dit komt doordat PCRE2 het minteken behandelt als een scheidingsteken, waardoor er een bereik binnen een tekenklasse wordt gecreëerd.

Fout bij Geomap-widget

De kaarten in de Geomap-widget worden mogelijk niet correct geladen als u hebt bijgewerkt vanuit een oudere Zabbix-versie met NGINX en tijdens de upgrade niet bent overgestapt naar het nieuwe NGINX-configuratiebestand.

Om het probleem op te lossen, kunt u het oude configuratiebestand verwijderen, het configuratiebestand uit het pakket van de huidige versie gebruiken en het opnieuw configureren zoals beschreven in de downloadinstructies in sectie e. Configure PHP for Zabbix frontend.

Als alternatief kunt u handmatig een bestaand NGINX-configuratiebestand bewerken (meestal /etc/zabbix/nginx.conf). Open hiervoor het bestand en zoek het volgende blok op:

location ~ /(api\/|conf[^\.]|include|locale|vendor) {
               deny            all;
               return          404;
       }

Vervang dit blok dan door:

location ~ /(api\/|conf[^\.]|include|locale) {
               deny            all;
               return          404;
       }
       
       location /vendor {
               deny            all;
               return          404;
       }

Use case with global variables shared across webhook calls

As global variables are shared across different webhook calls, the following code will result in the tag value counter gradually increasing:

try 
       {
          aa = aa + 1;
       }
       catch(e)
       {
          aa = 0;
       }

       result = {
               'tags': {
                   'endpoint': aa
               }
           };
       return JSON.stringify(result);

Using local variables instead of global ones is recommended to make sure that each script operates on its own data and that there are no collisions between simultaneous calls.

Server crash with PostgreSQL/TimescaleDB after upgrade from 7.0

Upgrading to Zabbix 7.0.1 (or later) from Zabbix 7.0.0 with PostgreSQL/TimescaleDB results in a server crash. This issue is caused by a workaround to a compression job issue in the auditlog table in Zabbix 7.0 that irreversibly changed the compression policy of the auditlog table.

To fix the issue, please perform a manual rebuild of the auditlog table. The buggy auditlog table can be detected using this query:

SELECT config FROM timescaledb_information.jobs WHERE application_name LIKE 'Compression%' AND hypertable_schema='public' AND hypertable_name='auditlog';.

If it returns a JSON object containing property compress_after (like {"hypertable_id": 14, "compress_after": 612000}) then you should rebuild the table.

Make sure that Zabbix server is at least 7.0.1rc2 version (or later); otherwise it will set the wrong compression policy again.

The simplest way for rebuilding the auditlog table is:

    CREATE TABLE auditlog_tmp (
               LIKE auditlog INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES
           );

           PERFORM create_hypertable('auditlog_tmp', 'auditid', chunk_time_interval => 604800,
                   time_partitioning_func => 'cuid_timestamp', migrate_data => true, if_not_exists => true);

           WITH moved_rows AS (
               DELETE FROM auditlog
               RETURNING *
           )
           INSERT INTO auditlog_tmp
           SELECT * FROM moved_rows;

           DROP TABLE auditlog;
           ALTER TABLE auditlog_tmp RENAME TO auditlog;

See also TimescaleDB documentation for more optimized ways to migrate data.

Since the timestamp required for partitioning is extracted from the auditid field with a custom-made function the helper procedures used for data migration from timescaledb-extras will not work.

Database restore error with PostgreSQL/TimescaleDB after upgrade from 7.0.0-7.0.4

Using pg_restore to restore a PostgreSQL/TimescaleDB backup created in Zabbix 7.0.0-7.0.4 will result in a missing base36_decode function error, causing the restore to fail:

ERROR:  function base36_decode(text) does not exist
       LINE 1: CAST(base36_decode(substring(cuid FROM 2 FOR 8))/1000 AS int...
                    ^
       HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

This error occurs when restoring a backup created with pg_dump.

To fix this issue, please replace the cuid_timestamp function in your Zabbix database before creating the backup (stopping PostgreSQL/TimescaleDB before running the script is recommended):

CREATE OR REPLACE FUNCTION cuid_timestamp(cuid varchar(25)) RETURNS integer AS $$
       DECLARE
           base36 varchar;
           a char[];
           ret bigint;
           i int;
           val int;
           chars varchar;
       BEGIN
           base36 := substring(cuid FROM 2 FOR 8);
       
           chars := '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ';
       
           FOR i IN REVERSE char_length(base36)..1 LOOP
               a := a || substring(upper(base36) FROM i FOR 1)::char;
           END LOOP;
           i := 0;
           ret := 0;
           WHILE i < (array_length(a, 1)) LOOP
               val := position(a[i + 1] IN chars) - 1;
               ret := ret + (val * (36 ^ i));
               i := i + 1;
           END LOOP;
       
           RETURN CAST(ret/1000 AS integer);
       END;
       $$ LANGUAGE 'plpgsql' IMMUTABLE;
       DROP FUNCTION IF EXISTS base36_decode(character varying);

See also ZBX-24955 (for additional details on the error) and TimescaleDB documentation (for additional backup and restore options).