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:
Voor MySQL-versies 8.0.0 - 8.0.13:
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).
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).
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.
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.:
Block Zabbix packages from EPEL. Add the following line in the /etc/yum.conf
file:
Install Zabbix server again:
Notice that official Zabbix packages have the word release
in their version string:
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.
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:
Then, update the repository information:
For more information, see ZBX-24761.
Database TLS-verbinding wordt niet ondersteund met de 'verify_ca'-optie voor de DBTLSConnect parameter als MariaDB wordt gebruikt.
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.
Gebeurtenissen worden mogelijk niet correct gecorreleerd als het tijdsinterval tussen de eerste en tweede gebeurtenis zeer klein is, bijvoorbeeld een halve seconde of minder.
PostgreSQL 11 en eerdere versies ondersteunen alleen een zwevende-kommawaarde bereik van ongeveer -1,34E-154 tot 1,34E+154.
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:
Voor meer informatie, zie het bijbehorende probleemrapport: ZBX-18275.
Zabbix agent 2 does not support lookaheads and lookbehinds in regular expressions due to the standard Go regexp library limitations.
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.
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.
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.
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.
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.
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.
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.:
where "1995" is the zabbix GID. For more details, see ZBX-22833.
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.
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.
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.
Er zijn gevallen geweest waarbij een Zabbix server alerter proces is gecrasht in RHEL 7. Zie ZBX-10461 voor meer details.
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:
Op Debian-gebaseerde systemen, voer het volgende uit:
Voor meer informatie, zie ZBX-23250.
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:
bcdiv
-functie van BC Wiskundefuncties)Wijzigingen in de zomertijd (DST) zorgen voor onregelmatigheden bij het weergeven van X-as labels (dubbele datums, ontbrekende datums, enz.).
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.
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.
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).
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.
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.
Er kunnen veel open gebruikerssessies worden gecreëerd wanneer u aangepaste scripts gebruikt met de user.login
methode zonder daaropvolgende user.logout
.
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.
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.
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.
Er zijn enkele bekende problemen met YAML export/import:
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:
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'.
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.
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.
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:
Vervang dit blok dan door:
location ~ /(api\/|conf[^\.]|include|locale) {
deny all;
return 404;
}
location /vendor {
deny all;
return 404;
}
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.
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.