6 Log file 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 het volgende in:

Belangrijke aantekeningen

• De server en agent houden de sporen bij van de grootte en laatste wijzigingstijd (voor logrt) van een gemonitorde log. Bovendien:
  • De agent gebruikt intern ook inode-nummers (op UNIX/GNU/Linux), bestandsindexen (op Microsoft Windows) en MD5-hashes van de eerste 512 bytes van het logbestand om beslissingen te verbeteren wanneer logbestanden worden ingekort en geroteerd.
  • Op UNIX/GNU/Linux-systemen wordt ervan uitgegaan dat de bestandssystemen waarin logbestanden zijn opgeslagen inode-nummers rapporteren, die kunnen worden gebruikt om bestanden te volgen.
  • Op Microsoft Windows bepaalt de Zabbix-agent het type bestandssysteem waarop de logbestanden zich bevinden en gebruikt het:
    • Op NTFS-bestandssystemen 64-bits bestandsindexen.
    • Op ReFS-bestandssystemen (alleen vanaf Microsoft Windows Server 2012) 128-bits bestands-IDs.
    • Op bestandssystemen waar bestandsindexen veranderen (bijv. FAT32, exFAT) wordt een fallback-algoritme gebruikt om een verstandige aanpak te hanteren bij onzekere omstandigheden wanneer logbestand- rotatie resulteert in meerdere logbestanden met dezelfde laatste wijzigingstijd.
  • De inode-nummers, bestandsindexen en MD5-hashes 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 inode- nummer van het bestand). In beide gevallen wordt het bestand geteld als verschillend en wordt het vanaf het begin geanalyseerd, wat kan leiden tot gedupliceerde waarschuwingen.
  • Als er verschillende overeenkomende logbestanden zijn voor het logrt[] item en de Zabbix-agent volgt het meest recente daarvan en dit meest recente logbestand wordt verwijderd, wordt een waarschuwings- bericht "er zijn geen bestanden die overeenkomen met "<regexp mask>" in "<directory>" gelogd. De Zabbix-agent negeert logbestanden met een wijzigingstijd die minder is dan de meest recente wijzigings- tijd die door de agent is gezien voor het te controleren logrt[] item.
• De agent begint het logbestand te lezen vanaf het punt waar het de vorige keer is gestopt.
• Het aantal reeds 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 het logbestand vanaf dit punt begint te lezen 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 van de server heeft ontvangen, maar het logrt[] of logrt.count[] item kan geen overeenkomende bestanden vinden, dan wordt de grootte- teller teruggezet naar 0 om vanaf het begin te analyseren als de bestanden later verschijnen.
• Telkens wanneer het logbestand kleiner wordt dan de loggrootte-teller die bekend is bij de agent, wordt de teller op nul gezet 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 overslaan van gegevens of dubbele analyse van dezelfde gegevens te vermijden, hoewel dit niet in alle situaties kan worden gegarandeerd. De agent gaat niet uit van een bepaald rotatieschema voor logbestanden en bepaalt er ook geen. Bij het presenteren van meerdere logbestanden met dezelfde laatste wijzigingstijd zal de agent ze verwerken in een lexicografisch aflopende volgorde. Zo zullen bij sommige rotatieschema's de logbestanden worden geanalyseerd en gerapporteerd in hun oorspronkelijke volgorde. Bij andere rotatieschema's zal de oorspronkelijke volgorde van logbestanden niet worden gerespecteerd, wat kan leiden tot gerapporteerde overeenkomende logbestandsrecords in gewijzigde volgorde (het probleem doet zich niet voor als logbestanden verschillende laatste wijzigingstijden hebben).
• Zabbix-agent verwerkt nieuwe records van een logbestand eens per Update-interval seconden.
• 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 agentconfiguratiebestand.
• Om de vereiste tekenreeks te vinden, zal Zabbix 10 keer meer nieuwe regels verwerken dan is ingesteld in MaxLinesPerSecond. Zo zal bijvoorbeeld als een log[] of logrt[] item een Update-interval van 1 seconde heeft, 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 te verhogen in het agentconfiguratiebestand of de parameter maxlines in de item key in te stellen, kan de limiet worden verhoogd tot maximaal 10000 geanalyseerde logbestandrecords en 1000 overeenkomende records die naar de Zabbix-server worden gestuurd in één controle. Als het Update-interval is ingesteld op 2 seconden, worden de limieten voor één controle 2 keer hoger ingesteld dan bij een Update-interval van 1 seconde.
• Bovendien zijn de waarden van log en log.count altijd beperkt tot 50% van de grootte van de agent verzendbuffer, zelfs als er geen niet-logwaarden in zitten. Dus voor de waarden van maxlines die in één verbinding moeten worden verzonden (en niet in meerdere verbindingen), moet de parameter BufferSize van de Zabbix-agent ten minste maxlines x 2 zijn. De Zabbix-agent kan gegevens uploaden tijdens het verzamelen van logs en zo de buffer vrijmaken, terwijl Zabbix-agent 2 het verzamelen van logs zal stoppen totdat de gegevens zijn geüpload en de buffer is vrijgemaakt, wat asynchroon wordt uitgevoerd.
• Bij afwezigheid van logitems wordt de volledige agent bufferomvang gebruikt voor niet-logwaarden. Wanneer logwaarden binnenkomen, vervangen ze indien nodig de oudere niet-logwaarden, tot maximaal 50%.
• Voor logbestandsrecords langer dan 256 kB wordt alleen de eerste 256 kB gematcht met de reguliere expressie en de rest van het record wordt genegeerd. Als de Zabbix-agent echter wordt gestopt terwijl deze bezig is met een lang record, gaat de interne toestand van de agent verloren en kan het lange record opnieuw en anders worden geanalyseerd nadat de agent opnieuw is gestart.
• Speciale opmerking voor "\" padafscheiders: als file_format is "file\.log", mag er geen "file"-map 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, reguliere expressie-matching voor 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 key).
• Het ontbreken van logbestanden voor een logrt[] item maakt het niet NOTSUPPORTED. Fouten bij het lezen van logbestanden voor een logrt[] item worden als waarschuwingen gelogd in het logbestand van de Zabbix-agent, 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 is geworden. Zabbix kan het logbestand van zijn agent monitoren, behalve wanneer DebugLevel=4 of DebugLevel=5 is ingesteld.

Het extraheren van het overeenkomende deel van de reguliere expressie

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

Sinds Zabbix 2.2.0 hebben log-items de mogelijkheid om gewenste waarden uit overeenkomende regels te halen. Dit wordt bereikt door de extra 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.

Dus, bijvoorbeeld

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

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

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

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 logitems maakt het mogelijk om sommige oudere regels uit logbestanden te negeren om zo de meest recent geanalyseerde regels te verkrijgen binnen de 'maxdelay'-seconden.

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

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 potentieel niet zo informatieve berichten gerapporteerd aan de server en nemen ze ruimte in de database in beslag. Ten tweede kan de agent als gevolg van het beperkte aantal per seconde geanalyseerde regels uren achterblijven bij de nieuwste logboekrecords. Waarschijnlijk geeft u er de voorkeur aan om eerder op de hoogte te worden gesteld van de huidige situatie in de logbestanden in plaats van urenlang oude gegevens door te spitten.

De oplossing voor beide problemen is het gebruik van de 'maxdelay'-parameter. Als 'maxdelay' > 0 wordt opgegeven, wordt tijdens elke controle het aantal verwerkte bytes, het aantal resterende bytes en de verwerkingstijd gemeten. Op basis van 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 de 'maxdelay' niet overschrijdt, gaat de agent door met het analyseren van het logbestand zoals gewoonlijk.

Als de vertraging groter is dan de '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 toe te springen in een bestand.

Het feit dat logbestandregels worden overgeslagen, wordt gelogd in het agent-logbestand als volgt:

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

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

Afhankelijk van hoe de snelheid van groei zich verhoudt tot de snelheid van het analyseren van het logbestand, ziet u mogelijk geen "sprongen", zeldzame of vaak "sprongen", grote of kleine "sprongen", of zelfs een kleine "sprong" bij elke controle. Schommelingen in de systeembelasting en netwerklatentie beïnvloeden ook de berekening van de vertraging en dus het "springen" vooruit om gelijke tred te houden met de "maxdelay"-parameter.

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

Opmerkingen over de behandeling van logboekrotatie met 'copytruncate'

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

logrt met de optie copytruncate doet moeite om logbestandkopieën correct te verwerken zonder duplicaten te melden. Echter, zaken zoals het produceren van meerdere logbestandkopieën met dezelfde tijdstempel, logboekrotatie vaker dan de update-interval van het logrt[]-item, frequent opnieuw starten van de agent worden niet aanbevolen. De agent probeert al deze situaties redelijk goed af te handelen, 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.

Maatregelen bij communicatiestoring tussen agent en server

Elke overeenkomende regel van log[] en logrt[] items en het resultaat van elke log.count[] en logrt.count[] itemcontrole vereist een vrije sleuf in het aangewezen 50% gebied in de agent-verzendbuffer. De elementen van de buffer worden regelmatig naar de server (of proxy) verzonden en de bufferposities zijn dan weer vrij.

Zolang er vrije sleuven zijn in het aangewezen loggebied in de agent-verzendbuffer en de communicatie tussen de agent en de server (of proxy) faalt, worden de resultaten van de logbewaking geaccumuleerd in de verzendbuffer. Dit helpt om korte communicatiestoringen te beheersen.

Tijdens langere communicatiestoringen raken alle logposities bezet en worden de volgende maatregelen genomen:

• Controles van log[] en logrt[] items worden gestopt. Wanneer de communicatie wordt hersteld en er vrije sleuven in de buffer beschikbaar zijn, worden de controles hervat vanaf de vorige positie. Er gaan geen overeenkomende regels verloren, ze worden gewoon later gerapporteerd.
• Controles van log.count[] en logrt.count[] worden gestopt als maxdelay = 0 (standaard). Het gedrag is vergelijkbaar met dat van log[] en logrt[] items zoals hierboven beschreven. Merk op dat dit van invloed kan zijn op de resultaten van log.count[] en logrt.count[]: bijvoorbeeld, één controle telt 100 overeenkomende regels in een logbestand, maar omdat er geen vrije sleuven in de buffer zijn, 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 count = 170 alsof ze werden gevonden in één controle.
• Controles van log.count[] en logrt.count[] met maxdelay > 0: als er tijdens de controle geen "sprong" heeft plaatsgevonden, is het gedrag vergelijkbaar met hierboven beschreven. Als er echter een "sprong" over regels in het logbestand heeft plaatsgevonden, wordt de positie na de "sprong" behouden en wordt het getelde resultaat verworpen. Dus, de agent probeert gelijke tred te houden met een groeiend logbestand, zelfs bij communicatiestoringen.

Behandeling van reguliere expressiecompilatie- en runtimefouten

Als een reguliere expressie die wordt gebruikt in een log[], logrt[], log.count[] of logrt.count[] item niet kan worden gecompileerd door de PCRE- of PCRE2-bibliotheek, wordt het item in de NOTSUPPORTED-status geplaatst met een foutmelding. Om de bewaking van het logitem voort te zetten, moet de reguliere expressie worden aangepast.

Als de reguliere expressie succesvol wordt gecompileerd, maar tijdens runtime (op sommige of op alle logboekrecords) mislukt, blijft het logitem ondersteund en gaat de bewaking door. De runtimefout wordt gelogd in het Zabbix-agentlogboek (zonder het logboekrecord).

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

De logfrequentie is beperkt tot één runtimefout per controle om de Zabbix-agent in staat te stellen zijn eigen logbestand te bewaken. Bijvoorbeeld, als 10 records worden geanalyseerd en 3 records mislukken met een regexp-runtimefout, wordt één record geproduceerd in het agentlogboek.

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

zabbix_agentd logt de itemsleutel 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 metrieken van log*[] ontvangt het de verwerkte logboekgrootte en de wijzigingstijd om te bepalen waar het logbestandsbewaking moet starten. Afhankelijk van de daadwerkelijke logboekgrootte en wijzigingstijd zoals gerapporteerd door het bestandssysteem, beslist de agent of het de bewaking van het logbestand moet voortzetten vanaf de verwerkte logboekgrootte of het logbestand opnieuw moet analyseren vanaf het begin.

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

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

Het primaire gebruiksscenario is het bewaken van een logbestand dat zich bevindt op een gespiegeld bestandssysteem. Tot op zekere hoogte in de tijd wordt het logbestand geschreven naar beide spiegels. Vervolgens worden de spiegels gesplitst. Op de actieve kopie groeit het logbestand nog steeds en worden er nieuwe records toegevoegd. De Zabbix-agent analyseert het en stuurt de verwerkte logboekgrootte en wijzigingstijd naar de server. Op de passieve kopie blijft het logbestand hetzelfde, ver achter op de actieve kopie. Later worden het besturingssysteem en de Zabbix-agent opnieuw opgestart vanaf de passieve kopie. De verwerkte logboekgrootte en wijzigingstijd die de Zabbix-agent van de server ontvangt, zijn mogelijk niet geldig voor de situatie op de passieve kopie. Om de bewaking van het logbestand voort te zetten vanaf het punt waarop de agent stopte op het moment van het splitsen van het bestandssysteem, herstelt de agent zijn status vanuit het persistente bestand.

Werking van de agent met persistente bestanden

Bij het opstarten weet de Zabbix-agent niets over persistente bestanden. Pas nadat hij een lijst met actieve controles van de Zabbix-server (proxy) heeft ontvangen, ziet de agent dat sommige logitems moeten worden ondersteund door persistente bestanden in gespecificeerde 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 dat persistente bestandsgegevens verloren gaan als het overschrijven en het splitsen van het bestandssysteem op hetzelfde moment plaatsvinden, is zeer klein, er is geen speciale behandeling voor nodig. Schrijven naar een persistent bestand wordt NIET gevolgd door afgedwongen synchronisatie naar opslagmedia (fsync() wordt niet aangeroepen).

Het overschrijven met de nieuwste gegevens gebeurt na succesvolle rapportage van overeenkomende logboekrecord of metagegevens (verwerkte logboekgrootte en wijzigingstijd) aan de Zabbix-server. Dat kan zo vaak gebeuren als elke itemcontrole als het logbestand blijft veranderen.

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

Nadat de agent een lijst met actieve controles heeft ontvangen, markeert de agent verouderde persistente bestanden voor verwijdering. Een persistent bestand wordt als verouderd beschouwd als: 1) het overeenkomstige logitem niet langer wordt bewaakt, 2) een logitem opnieuw is geconfigureerd met een andere persistent_dir-locatie dan voorheen.

Het verwijderen gebeurt met een vertraging van 24 uur omdat logbestanden in de NOTSUPPORTED-status niet zijn opgenomen in de lijst met actieve controles, maar later als SUPPORTED kunnen worden beschouwd en hun persistente bestanden nuttig kunnen zijn.

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

Benaming en locatie van persistente bestanden

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. Het wijzigen van het item logrt[/home/zabbix/test.log,,,10] in de frontend naar logrt[/home/zabbix/test.log,,,20] zal resulteren in het verwijderen van het item logrt[/home/zabbix/test.log,,,10] uit de lijst met actieve controles van de agent en het creëren van het logrt[/home/zabbix/test.log,,,20] item (sommige attributen worden overgedragen bij wijziging in de frontend/server, niet in de agent).

De bestandsnaam bestaat uit de MD5-hash van de itemsleutel met de lengte van de itemsleutel toegevoegd om de kans op botsingen te verminderen. Bijvoorbeeld, de status van het item logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] wordt opgeslagen in het persistente bestand c963ade4008054813bbc0a650bb8e09266.

Meerdere logitems kunnen dezelfde waarde van persistent_dir gebruiken.

De persistent_dir wordt gespecificeerd rekening houdend met specifieke bestandssysteemindelingen, koppelpunten, koppelopties en opslag-spiegelconfiguraties - het persistente bestand moet zich op hetzelfde gespiegelde bestandssysteem bevinden als het bewaakte logbestand.

Als de persistent_dir-directory niet kan worden gemaakt of niet bestaat, of als de toegangsrechten voor de Zabbix-agent het niet toestaan om bestanden te maken/schrijven/lezen/verwijderen, wordt het logitem NOTSUPPORTED.

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.