6 Logbestand monitoring

Overzicht

Zabbix kan worden gebruikt voor gecentraliseerde monitoring en analyse van logbestanden met/zonder ondersteuning voor logrotatie.

Meldingen kunnen worden gebruikt om gebruikers te waarschuwen wanneer een logbestand bepaalde tekenreeksen of tekenreeksenpatronen bevat.

Om een logbestand te bewaken, moet je het volgende hebben:

• Een Zabbix-agent die op de host wordt uitgevoerd
• Een ingestelde item voor het monitoren van logs

Configuratie

Controleer agentparameters

Zorg ervoor dat in het configuratiebestand van de agent:

• De parameter 'Hostname' overeenkomt met de hostnaam in de frontend.
• Servers zijn gespecificeerd in de parameter 'ServerActive' voor het verwerken van actieve controles.

Itemconfiguratie

Configureer een logmonitoring item.

Alle verplichte invoervelden zijn gemarkeerd met een rode asterisk.

Specifiek voor logmonitoring-items voer je in:

Belangrijke opmerkingen

• De server en agent houden de sporen bij van de grootte en de laatste wijzigingstijd van een gemonitord logbestand (voor logrt) in twee tellers. Daarnaast:
  • De agent gebruikt ook intern inode-nummers (op UNIX/GNU/Linux), bestandsindexen (op Microsoft Windows) en MD5-checksums van de eerste 512 logbestandbytes om beslissingen te verbeteren wanneer logbestanden worden afgekapt en geroteerd.
  • Op UNIX/GNU/Linux-systemen wordt ervan uitgegaan dat de bestandssystemen waarop logbestanden zijn opgeslagen, inode-nummers rapporteren, die kunnen worden gebruikt om bestanden te volgen.
  • Op Microsoft Windows bepaalt de Zabbix-agent het bestandssysteemtype waarop de logbestanden zich bevinden en gebruikt:
    • Op NTFS-bestandssystemen 64-bits bestandsindexen.
    • Op ReFS-bestandssystemen (alleen vanaf Microsoft Windows Server 2012) 128-bits bestands-ID's.
    • Op bestandssystemen waarop bestandsindexen veranderen (bijv. FAT32, exFAT) wordt een fallback-algoritme gebruikt om een verstandige benadering te nemen bij onzekere omstandigheden wanneer rotatie van logbestanden resulteert in meerdere logbestanden met dezelfde laatste wijzigingstijd.
  • De inode-nummers, bestandsindexen en MD5-checksums worden intern verzameld door de Zabbix-agent. Ze worden niet naar de Zabbix-server verzonden en gaan verloren wanneer de Zabbix-agent wordt gestopt.
  • Wijzig de laatste wijzigingstijd van logbestanden niet met het 'touch'-hulpprogramma, kopieer geen logbestand met latere herstelling van de oorspronkelijke naam (dit verandert het bestandsinode-nummer). In beide gevallen wordt het bestand als verschillend geteld en wordt het vanaf het begin geanalyseerd, wat kan leiden tot gedupliceerde waarschuwingen.
  • Als er meerdere overeenkomende logbestanden zijn voor het logrt[] item en de Zabbix-agent het meest recente daarvan volgt en dit meest recente logbestand wordt verwijderd, wordt een waarschuwingsbericht gelogd met de tekst "there are no files matching "<regexp mask>" in "<directory>". De Zabbix-agent negeert logbestanden met een wijzigingstijd die kleiner is dan de meest recente wijzigingstijd die door de agent is gezien voor het logrt[] item dat wordt gecontroleerd.
• De agent begint met het lezen van het logbestand vanaf het punt waar het de vorige keer is gestopt.
• Het aantal geanalyseerde bytes (de grootte-teller) en de laatste wijzigingstijd (de tijd-teller) worden opgeslagen in de Zabbix-database en worden naar de agent verzonden om ervoor te zorgen dat de agent begint met het lezen van het logbestand vanaf dit punt in gevallen waarin de agent net is gestart of items heeft ontvangen die eerder waren uitgeschakeld of niet werden ondersteund. Als de agent echter een niet-nul grootte-teller heeft ontvangen van de server, maar het logrt[] of logrt.count[] item kan geen overeenkomende bestanden vinden, wordt de grootte-teller gereset naar 0 om vanaf het begin te analyseren als de bestanden later verschijnen.
• Wanneer het logbestand kleiner wordt dan de grootte-teller van het log die de agent kent, wordt de teller gereset naar nul en begint de agent het logbestand vanaf het begin te lezen met inachtneming van de tijd-teller.
• Als er meerdere overeenkomende bestanden zijn met dezelfde laatste wijzigingstijd in de map, probeert de agent alle logbestanden met dezelfde wijzigingstijd correct te analyseren en dataverlies of het tweemaal analyseren van dezelfde gegevens te voorkomen, hoewel dit niet in alle situaties kan worden gegarandeerd. De agent gaat er niet van uit dat er een bepaald rotatieschema voor logbestanden is en bepaalt er ook geen. Bij het presenteren van meerdere logbestanden met dezelfde laatste wijzigingstijd, zal de agent ze in lexicografisch dalende volgorde verwerken. Zo zullen bij sommige rotatieschema's de logbestanden worden geanalyseerd en gerapporteerd in hun oorspronkelijke volgorde. Bij andere rotatieschema's wordt de oorspronkelijke volgorde van de logbestanden niet gerespecteerd, wat kan leiden tot het rapporteren van overeenkomende logbestandrecords in gewijzigde volgorde (dit probleem doet zich niet voor als logbestanden verschillende laatste wijzigingstijden hebben).
• De Zabbix-agent verwerkt nieuwe records van een logbestand eenmaal per Update interval seconden.
• De Zabbix-agent stuurt niet meer dan maxlines van een logbestand per seconde. De limiet voorkomt overbelasting van netwerk- en CPU-bronnen en overschrijft de standaardwaarde die wordt geleverd door de parameter MaxLinesPerSecond in het configuratiebestand van de agent.
• Om de benodigde string te vinden, zal Zabbix 10 keer meer nieuwe regels verwerken dan ingesteld in MaxLinesPerSecond. Dus bijvoorbeeld, als een log[] of logrt[] item een Update interval van 1 seconde heeft, zal de agent standaard niet meer dan 200 logbestandrecords analyseren en niet meer dan 20 overeenkomende records naar de Zabbix-server sturen in één controle. Door MaxLinesPerSecond in het configuratiebestand van de agent te verhogen of de parameter maxlines in de item-sleutel in te stellen, kan de limiet worden verhoogd tot 10000 geanalyseerde logbestandrecords en 1000 overeenkomende records die in één controle naar de Zabbix-server worden verzonden. Als het Update interval is ingesteld op 2 seconden, zijn de limieten voor één controle 2 keer hoger dan bij een Update interval van 1 seconde.
• Bovendien worden log- en log.count-waarden altijd beperkt tot 50% van de grootte van de agent-verzendbuffer, zelfs als er geen niet-log-waarden in zitten. Dus om de maxlines waarden in één verbinding te kunnen verzenden (en niet in verschillende verbindingen), moet de parameter BufferSize van de agent ten minste maxlines x 2 zijn. De Zabbix-agent kan gegevens uploaden tijdens het verzamelen van loggegevens en daardoor de buffer vrijmaken, terwijl Zabbix-agent 2 het verzamelen van loggegevens zal stoppen totdat de gegevens zijn geüpload en de buffer is vrijgemaakt, wat asynchroon wordt uitgevoerd.
• Bij afwezigheid van log-items wordt de volledige buffergrootte van de agent gebruikt voor niet-logische waarden. Wanneer logwaarden binnenkomen, vervangen ze de oudere niet-logwaarden zoals nodig, tot 50% van de aangewezen waarde.
• Voor logbestandrecords langer dan 256 kB wordt alleen de eerste 256 kB overeenkomstig de reguliere expressie gezocht en de rest van het record wordt genegeerd. Als de Zabbix-agent echter wordt gestopt terwijl het bezig is met een lang record, gaat de interne status van de agent verloren en kan het lange record opnieuw en anders worden geanalyseerd nadat de agent opnieuw is gestart.
• Speciale opmerking voor "\" scheidingstekens in paden: als file_format "file\.log" is, mag er geen "file"-directory zijn, aangezien het niet mogelijk is om ondubbelzinnig te bepalen of "." is ontsnapt of het eerste symbool van de bestandsnaam is.
• Reguliere expressies voor logrt worden alleen ondersteund in de bestandsnaam, overeenkomst van reguliere expressie in mappen wordt niet ondersteund.
• Op UNIX-platforms wordt een logrt[] item NOTSUPPORTED als een map waarin de logbestanden worden verwacht, niet bestaat.
• Op Microsoft Windows wordt het item niet NOTSUPPORTED als een map niet bestaat (bijvoorbeeld als de mapnaam verkeerd is gespeld in de item-sleutel).
• De afwezigheid van logbestanden voor het logrt[] item maakt het niet NOTSUPPORTED. Fouten bij het lezen van logbestanden voor het logrt[] item worden als waarschuwingen in het logbestand van de Zabbix-agent geregistreerd, maar maken het item niet NOTSUPPORTED.
• Het logbestand van de Zabbix-agent kan nuttig zijn om erachter te komen waarom een log[] of logrt[] item NOTSUPPORTED werd. Zabbix kan het logbestand van de agent controleren, behalve wanneer DebugLevel=4 of DebugLevel=5 is ingesteld.

Het extraheren van het overeenkomende deel van een reguliere expressie

Soms willen we mogelijk alleen de interessante waarde extraheren uit een doelbestand in plaats van de hele regel terug te geven wanneer er een overeenkomst met een reguliere expressie is gevonden.

Sinds Zabbix 2.2.0 hebben log-items de mogelijkheid om gewenste waarden uit overeenkomende regels te extraheren. Dit wordt bereikt door de aanvullende parameter output in log en logrt items.

Het gebruik van de 'output' parameter maakt het mogelijk om de "capturing group" van de overeenkomst aan te geven waarin we mogelijk geïnteresseerd zijn.

Bijvoorbeeld,

log[/pad/naar/het/bestand,"grote resultaatbuffer toewijzing.*Inzendingen: ([0-9]+)",,,,\1]

zou moeten toestaan om het aantal inzendingen terug te geven zoals gevonden in de inhoud van:

Vr februari 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) grote resultaatbuffer toewijzing - /Lengte: 437136/Inzendingen: 5948/Client Ver: >=10/RPC
       ID: 41726453/User: EenGebruiker/Formulier: CFG:Dienstverleningsovereenkomst

Alleen het getal wordt teruggegeven omdat \1 verwijst naar de eerste en enige capturing group: ([0-9]+).

En met de mogelijkheid om een getal te extraheren en terug te geven, kan de waarde worden gebruikt om triggers te definiëren.

Gebruik van de maxdelay-parameter

De 'maxdelay'-parameter in log-items maakt het mogelijk om sommige oudere regels in logbestanden te negeren om de meest recente regels binnen de 'maxdelay'-seconden te analyseren.

Standaard volgen items voor log monitoring alle nieuwe regels die in de logbestanden verschijnen. Er zijn echter toepassingen die in bepaalde situaties een enorm aantal berichten in hun logbestanden beginnen te schrijven. Bijvoorbeeld, als een database of een DNS-server niet beschikbaar is, overstromen dergelijke toepassingen logbestanden met duizenden vrijwel identieke foutmeldingen totdat de normale werking is hersteld. Standaard worden al die berichten zorgvuldig geanalyseerd en overeenkomende regels zoals geconfigureerd in log en logrt items naar de server gestuurd.

Ingebouwde bescherming tegen overbelasting bestaat uit een configureerbare 'maxlines'-parameter (beschermt de server tegen te veel binnenkomende overeenkomende logregels) en een limiet van 10*'maxlines' (beschermt de host-CPU en I/O tegen overbelasting door de agent in één controle). Toch zijn er 2 problemen met de ingebouwde bescherming. Ten eerste worden een groot aantal mogelijk niet zo informatieve berichten aan de server gerapporteerd en gebruiken ze ruimte in de database. Ten tweede, vanwege het beperkte aantal regels dat per seconde wordt geanalyseerd, kan de agent achterblijven bij de nieuwste logrecords gedurende uren. Waarschijnlijk wilt u eerder op de hoogte worden gebracht van de huidige situatie in de logbestanden in plaats van urenlang door oude gegevens te kruipen.

De oplossing voor beide problemen is het gebruik van de 'maxdelay'-parameter. Als 'maxdelay' > 0 is gespecificeerd, wordt tijdens elke controle het aantal verwerkte bytes, het aantal resterende bytes en de verwerkingstijd gemeten. Uit deze cijfers berekent de agent een geschatte vertraging - hoeveel seconden het zou duren om alle resterende records in een logbestand te analyseren.

Als de vertraging niet groter is dan 'maxdelay', gaat de agent verder met het analyseren van het logbestand zoals gewoonlijk.

Als de vertraging groter is dan 'maxdelay', negeert de agent een deel van een logbestand door er "overheen te springen" naar een nieuwe geschatte positie, zodat de resterende regels binnen 'maxdelay' seconden kunnen worden geanalyseerd.

Merk op dat de agent zelfs geen genegeerde regels in de buffer leest, maar een geschatte positie berekent om naar een bestand te springen.

Het feit dat logbestandregels worden overgeslagen, wordt gelogd in het agent-logbestand zoals dit:

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
       logfile:"/home/zabbix32/test1.log" overslaan 679858 bytes
       (van byte 75653115 tot byte 76332973) om aan maxdelay te voldoen

Het "tot byte"-nummer is bij benadering omdat de agent na de "sprong" de positie in het bestand aanpast naar het begin van een logregel die verder in het bestand kan staan of eerder.

Afhankelijk van hoe de snelheid van groei zich verhoudt tot de snelheid van het analyseren van het logbestand, kunt u geen "sprongen" zien, zelden of vaak "sprongen", grote of kleine "sprongen", of zelfs een kleine "sprong" in elke controle. Schommelingen in de systeembelasting en netwerklatentie beïnvloeden ook de berekening van de vertraging en daarmee het "overslaan" om bij de "maxdelay"-parameter te blijven.

Het instellen van 'maxdelay' < 'update interval' wordt niet aanbevolen (dit kan leiden tot frequente kleine "sprongen").

Opmerkingen over het omgaan met logbestandsrotatie met 'copytruncate'

logrt met de optie copytruncate gaat ervan uit dat verschillende logbestanden verschillende records hebben (ten minste hun tijdstempels zijn verschillend), daarom zullen MD5-hashes van de eerste blokken (tot de eerste 512 bytes) verschillend zijn. Twee bestanden met dezelfde MD5-hash van de eerste blokken betekent dat een van hen het origineel is en de andere een kopie.

logrt met de optie copytruncate doet zijn best om logbestandkopieën correct te verwerken zonder duplicaten te rapporteren. Dingen als het produceren van meerdere logbestandkopieën met dezelfde tijdstempel, het vaker roteren van logbestanden dan de logrt[] item-update-interval, het frequent opnieuw starten van de agent worden echter niet aanbevolen. De agent probeert al deze situaties redelijk goed te behandelen, maar goede resultaten kunnen niet in alle omstandigheden worden gegarandeerd.

Opmerkingen over persistente bestanden voor log*[] items

Belasting op I/O

Het persistente bestand van het item wordt bijgewerkt na het succesvol verzenden van elke batch gegevens (met daarin de gegevens van het item) naar de server. Bijvoorbeeld, de standaard 'BufferSize' is 100. Als een log-item 70 overeenkomende records heeft gevonden, worden de eerste 50 records in één batch verzonden, het persistente bestand wordt bijgewerkt, vervolgens worden de resterende 20 records verzonden (misschien met enige vertraging wanneer er meer gegevens worden verzameld) in de 2e batch, en het persistente bestand wordt opnieuw bijgewerkt.

Acties bij communicatiestoring tussen agent en server

Voor elke overeenkomende regel van het log[] en logrt[] item en het resultaat van elke log.count[] en logrt.count[] itemcontrole is een vrije slot nodig in het aangewezen gebied van 50% in de agent zendbuffer. De bufferelementen worden regelmatig naar de server (of proxy) verzonden en de bufferslots zijn dan weer vrij.

Terwijl er vrije slots zijn in het aangewezen loggebied in de agent zendbuffer en de communicatie tussen agent en server (of proxy) mislukt, worden de log monitoringresultaten opgeslagen in de zendbuffer. Dit helpt bij het verzachten van korte communicatiestoringen.

Tijdens langere communicatiestoringen raken alle logslots bezet en worden de volgende acties ondernomen:

• Controles van log[] en logrt[] items worden gestopt. Wanneer de communicatie wordt hersteld en er vrije slots in de buffer beschikbaar zijn, worden de controles hervat vanaf de vorige positie. Er gaan geen overeenkomende regels verloren, ze worden alleen later gerapporteerd.
• Controles van log.count[] en logrt.count[] items worden gestopt als maxdelay = 0 (standaard). Het gedrag is vergelijkbaar met dat van log[] en logrt[] items zoals hierboven beschreven. Let op dat dit de resultaten van log.count[] en logrt.count[] items kan beïnvloeden: bijvoorbeeld, één controle telt 100 overeenkomende regels in een logbestand, maar omdat er geen vrije slots zijn in de buffer wordt de controle gestopt. Wanneer de communicatie wordt hersteld, telt de agent dezelfde 100 overeenkomende regels en ook 70 nieuwe overeenkomende regels. De agent stuurt nu een telling van 170 alsof ze in één controle zijn gevonden.
• Controles van log.count[] en logrt.count[] items met maxdelay > 0: als er tijdens de controle geen "jump" heeft plaatsgevonden, is het gedrag vergelijkbaar met wat hierboven is beschreven. Als er een "jump" over logbestandregels heeft plaatsgevonden, wordt de positie na de "jump" behouden en het getelde resultaat wordt verworpen. Dus, de agent probeert gelijke tred te houden met een groeiend logbestand, zelfs in geval van communicatiestoring.

Afhandeling van reguliere expressiecompilatie- en runtimefouten

Als een reguliere expressie die wordt gebruikt in log[], logrt[], log.count[] of logrt.count[] item niet kan worden gecompileerd door de PCRE- of PCRE2-bibliotheek, dan gaat het item naar de NIET-ONDERSTEUNDE toestand met een foutmelding. Om het logitem blijven te monitoren, moet de reguliere expressie worden hersteld.

Als de reguliere expressie succesvol compileert, maar fouten veroorzaakt tijdens runtime (op sommige of op alle logregels), blijft het logitem ondersteund en gaat het monitoren door. De runtimefout wordt gelogd in het Zabbix agent logbestand (zonder de logregel).

Merk op dat het loggen van runtimefouten van reguliere expressies wordt ondersteund sinds Zabbix 6.0.21.

Het loggen van runtimefouten is beperkt tot één fout per controle om Zabbix agent in staat te stellen zijn eigen logbestand te monitoren. Bijvoorbeeld, als 10 records worden geanalyseerd en 3 records fouten veroorzaken met een reguliere expressie-runtimefout, wordt één record geproduceerd in het agent logboek.

Uitzondering: als MaxLinesPerSecond=1 en de update-interval=1 (slechts 1 record mag per controle worden geanalyseerd), worden reguliere expressie-runtimefouten niet gelogd.

zabbix_agentd logt de item sleutel in geval van een runtimefout, zabbix_agent2 logt de item ID om te helpen identificeren welk logitem runtimefouten heeft. Het wordt aanbevolen om de reguliere expressie opnieuw te ontwerpen in geval van runtimefouten.

Doel van persistente bestanden

Wanneer de Zabbix-agent wordt gestart, ontvangt deze een lijst met actieve controles van de Zabbix-server of proxy. Voor log*[] metingen ontvangt hij de verwerkte loggrootte en de wijzigingstijd om te bepalen waar het monitoren van het logbestand moet beginnen. Afhankelijk van de werkelijke logbestandsgrootte en de wijzigingstijd die door het bestandssysteem wordt gerapporteerd, besluit de agent of het monitoren van het logbestand moet worden voortgezet vanaf de verwerkte loggrootte of dat het logbestand opnieuw vanaf het begin moet worden geanalyseerd.

Een actieve agent houdt een grotere set attributen bij om alle gemonitorde logbestanden tussen controles in bij te houden. Deze in-memory status gaat verloren wanneer de agent wordt gestopt.

De nieuwe optionele parameter persistent_dir geeft een directory aan voor het opslaan van deze status van log[], log.count[], logrt[] of logrt.count[] items in een bestand. De status van het log-item wordt hersteld uit het persistente bestand nadat de Zabbix-agent opnieuw is opgestart.

Het belangrijkste gebruiksscenario is het monitoren van een logbestand dat zich bevindt op een gespiegelde bestandssysteem. Tot op een bepaald moment in de tijd wordt het logbestand naar beide spiegels geschreven. Vervolgens worden de spiegels gesplitst. Op de actieve kopie blijft het logbestand groeien en nieuwe records ontvangen. De Zabbix-agent analyseert het en stuurt de verwerkte loggrootte en wijzigingstijd naar de server. Op de passieve kopie blijft het logbestand echter hetzelfde, ver achter op de actieve kopie. Later worden het besturingssysteem en de Zabbix-agent opnieuw opgestart vanaf de passieve kopie. De verwerkte loggrootte en wijzigingstijd die de Zabbix-agent van de server ontvangt, zijn mogelijk niet geldig voor de situatie op de passieve kopie. Om het monitoren van het logbestand voort te zetten vanaf het punt waar de agent was gebleven op het moment van de splitsing van het bestandssysteemspiegel, herstelt de agent zijn status uit het persistente bestand.

Werking van de agent met persistente bestanden

Bij het opstarten weet de Zabbix-agent niets van persistente bestanden. Pas nadat de agent een lijst met actieve controles van de Zabbix-server (of proxy) heeft ontvangen, ziet hij dat sommige log-items ondersteund moeten worden door persistente bestanden in de opgegeven mappen.

Tijdens de werking van de agent worden de persistente bestanden geopend voor schrijven (met fopen(filename, "w")) en overschreven met de nieuwste gegevens. De kans op het verliezen van gegevens in persistente bestanden als het overschrijven en de splitsing van het bestandssysteemspiegel tegelijkertijd plaatsvindt, is zeer klein, er is geen speciale behandeling voor nodig. Het schrijven naar het persistente bestand wordt NIET gevolgd door verplichte synchronisatie naar opslagmedia (fsync() wordt niet aangeroepen).

Het overschrijven met de nieuwste gegevens gebeurt nadat een overeenkomend logbestandrecord of metagegevens (verwerkte loggrootte en wijzigingstijd) succesvol zijn gemeld aan de Zabbix-server. Dit kan zo vaak gebeuren als bij elke itemcontrole als het logbestand blijft veranderen.

Er zijn geen speciale acties nodig tijdens het afsluiten van de agent.

Na ontvangst van een lijst met actieve controles markeert de agent verouderde persistente bestanden voor verwijdering. Een persistente bestand wordt verouderd als: 1) het overeenkomstige log-item niet langer wordt gecontroleerd, 2) een log-item opnieuw is geconfigureerd met een andere persistent_dir-locatie dan voorheen.

Het verwijderen wordt met een vertraging van 24 uur uitgevoerd, omdat logbestanden in de staat NOTSUPPORTED niet worden opgenomen in de lijst met actieve controles, maar later wel SUPPORTED kunnen worden en hun persistente bestanden nuttig kunnen zijn.

Als de agent wordt gestopt voordat 24 uur zijn verstreken, worden de verouderde bestanden niet verwijderd, omdat de Zabbix-agent geen informatie meer krijgt over hun locatie van de Zabbix-server.

De Zabbix-agent onderscheidt actieve controles op basis van hun sleutels. Bijvoorbeeld, logrt[/home/zabbix/test.log] en logrt[/home/zabbix/test.log,] zijn verschillende items. Als je het item logrt[/home/zabbix/test.log,,,10] in de frontend wijzigt naar logrt[/home/zabbix/test.log,,,20], zal dit resulteren in het verwijderen van het item logrt[/home/zabbix/test.log,,,10] uit de lijst van actieve controles van de agent en het aanmaken van het logrt[/home/zabbix/test.log,,,20] item (sommige attributen worden overgebracht bij wijzigingen in de frontend/server, niet in de agent).

De bestandsnaam wordt samengesteld uit de MD5-hash van de item-sleutel, gevolgd door de lengte van de item-sleutel om de kans op botsingen te verkleinen. Bijvoorbeeld, de status van het logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] item wordt opgeslagen in het persistente bestand c963ade4008054813bbc0a650bb8e09266.

Meerdere log-items kunnen dezelfde waarde van persistent_dir gebruiken.

De locatie van persistent_dir wordt bepaald rekening houdend met specifieke bestandssysteemindelingen, koppelpunten, koppelopties en configuratie voor opslagmirroring - het persistente bestand moet zich bevinden op hetzelfde gespiegelde bestandssysteem als het gemonitorde logbestand.

Als de persistent_dir-directory niet kan worden aangemaakt of niet bestaat, of als de toegangsrechten voor de Zabbix-agent het niet toestaan om bestanden te maken/schrijven/lezen/verwijderen, wordt het log-item NIET ONDERSTEUND.

Als de toegangsrechten tot persistente opslagbestanden tijdens de werking van de agent worden verwijderd of als er andere fouten optreden (bijvoorbeeld een volle schijf), worden fouten gelogd in het agent-logbestand, maar het log-item wordt niet ONDERSTEUND.