6 Naplófájlok figyelése

Áttekintés

A Zabbix a naplófájlok központosított megfigyelésére és elemzésére használható rönkforgatás támogatással/nélkül.

Az értesítések arra használhatók, hogy figyelmeztessék a felhasználókat, ha egy naplófájl bizonyos információkat tartalmaz húrok vagy húrminták.

A naplófájl figyeléséhez rendelkeznie kell:

• Zabbix ügynök fut a gazdagépen
• naplófigyelő elem beállítása

Konfiguráció

Ellenőrizze az ügynök paramétereit

Győződjön meg arról, hogy az agent configuration fájl:

• A 'Hostname' paraméter megegyezik a frontend gazdagép nevével
• A szerverek a 'ServerActive' paraméterben vannak megadva a aktív ellenőrzések feldolgozása

Item configuration

Configure a log monitoring item.

All mandatory input fields are marked with a red asterisk.

Specifically for log monitoring items you enter:

Important notes

• The server and agent keep the trace of a monitored log's size and last modification time (for logrt) in two counters. Additionally:
  • The agent also internally uses inode numbers (on UNIX/GNU/Linux), file indexes (on Microsoft Windows) and MD5 sums of the first 512 log file bytes for improving decisions when logfiles get truncated and rotated.
  • On UNIX/GNU/Linux systems it is assumed that the file systems where log files are stored report inode numbers, which can be used to track files.
  • On Microsoft Windows Zabbix agent determines the file system type the log files reside on and uses:
    • On NTFS file systems 64-bit file indexes.
    • On ReFS file systems (only from Microsoft Windows Server 2012) 128-bit file IDs.
    • On file systems where file indexes change (e.g. FAT32, exFAT) a fall-back algorithm is used to take a sensible approach in uncertain conditions when log file rotation results in multiple log files with the same last modification time.
  • The inode numbers, file indexes and MD5 sums are internally collected by Zabbix agent. They are not transmitted to Zabbix server and are lost when Zabbix agent is stopped.
  • Do not modify the last modification time of log files with 'touch' utility, do not copy a log file with later restoration of the original name (this will change the file inode number). In both cases the file will be counted as different and will be analyzed from the start, which may result in duplicated alerts.
  • If there are several matching log files for logrt[] item and Zabbix agent is following the most recent of them and this most recent log file is deleted, a warning message "there are no files matching "<regexp mask>" in "<directory>" is logged. Zabbix agent ignores log files with modification time less than the most recent modification time seen by the agent for the logrt[] item being checked.
• The agent starts reading the log file from the point it stopped the previous time.
• The number of bytes already analyzed (the size counter) and last modification time (the time counter) are stored in the Zabbix database and are sent to the agent to make sure the agent starts reading the log file from this point in cases when the agent is just started or has received items which were previously disabled or not supported. However, if the agent has receives a non-zero size counter from server, but the logrt[] or logrt.count[] item has not found and does not find matching files, the size counter is reset to 0 to analyze from the start if the files appear later.
• Whenever the log file becomes smaller than the log size counter known by the agent, the counter is reset to zero and the agent starts reading the log file from the beginning taking the time counter into account.
• If there are several matching files with the same last modification time in the directory, then the agent tries to correctly analyze all log files with the same modification time and avoid skipping data or analyzing the same data twice, although it cannot be guaranteed in all situations. The agent does not assume any particular log file rotation scheme nor determines one. When presented multiple log files with the same last modification time, the agent will process them in a lexicographically descending order. Thus, for some rotation schemes the log files will be analyzed and reported in their original order. For other rotation schemes the original log file order will not be honored, which can lead to reporting matched log file records in altered order (the problem does not happen if log files have different last modification times).
• Zabbix agent processes new records of a log file once per Update interval seconds.
• Zabbix agent does not send more than maxlines of a log file per second. The limit prevents overloading of network and CPU resources and overrides the default value provided by MaxLinesPerSecond parameter in the agent configuration file.
• To find the required string Zabbix will process 10 times more new lines than set in MaxLinesPerSecond. Thus, for example, if a log[] or logrt[] item has Update interval of 1 second, by default the agent will analyze no more than 200 log file records and will send no more than 20 matching records to Zabbix server in one check. By increasing MaxLinesPerSecond in the agent configuration file or setting maxlines parameter in the item key, the limit can be increased up to 10000 analyzed log file records and 1000 matching records sent to Zabbix server in one check. If the Update interval is set to 2 seconds the limits for one check would be set 2 times higher than with Update interval of 1 second.
• Additionally, log and log.count values are always limited to 50% of the agent send buffer size, even if there are no non-log values in it. So for the maxlines values to be sent in one connection (and not in several connections), the agent BufferSize parameter must be at least maxlines x 2.
• In the absence of log items all agent buffer size is used for non-log values. When log values come in they replace the older non-log values as needed, up to the designated 50%.
• For log file records longer than 256kB, only the first 256kB are matched against the regular expression and the rest of the record is ignored. However, if Zabbix agent is stopped while it is dealing with a long record the agent internal state is lost and the long record may be analyzed again and differently after the agent is started again.
• Special note for "\" path separators: if file_format is "file\.log", then there should not be a "file" directory, since it is not possible to unambiguously define whether "." is escaped or is the first symbol of the file name.
• Regular expressions for logrt are supported in filename only, directory regular expression matching is not supported.
• On UNIX platforms a logrt[] item becomes NOTSUPPORTED if a directory where the log files are expected to be found does not exist.
• On Microsoft Windows, if a directory does not exist the item will not become NOTSUPPORTED (for example, if directory is misspelled in item key).
• An absence of log files for logrt[] item does not make it NOTSUPPORTED. Errors of reading log files for logrt[] item are logged as warnings into Zabbix agent log file but do not make the item NOTSUPPORTED.
• Zabbix agent log file can be helpful to find out why a log[] or logrt[] item became NOTSUPPORTED. Zabbix can monitor its agent log file except when at DebugLevel=4.

A reguláris kifejezés egyező részének kinyerése

Néha előfordulhat, hogy csak az érdekes értéket szeretnénk kivonni a célfájlt ahelyett, hogy az egész sort adja vissza, ha egy szabályos kifejezés egyezés található.

A Zabbix 2.2.0 óta a naplóelemek képesek a kívánt értékek kinyerésére illesztett sorokból. Ezt a további kimenet éri el paraméter a "log" és a "logrt" elemekben.

Az 'output' paraméter használata lehetővé teszi a "rögzítési csoport" jelzését az a meccs, ami érdekelhet minket.

Tehát például

log[/path/to/the/file,"nagy eredménypuffer kiosztása.*Bejegyzések: ([0-9]+)",,,,\1]

lehetővé kell tennie a bejegyzések számának visszaküldését, ahogyan az a következők tartalmában található:

Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) nagy eredmény
       puffer kiosztás - /Hossz: 437136/Bejegyzések: 5948/Client Ver: >=10/RPC
       ID: 41726453/Felhasználó: AUser/Űrlap: CFG:ServiceLevelAgreement

Csak a szám kerül visszaadásra, mert a \1 az első és csak rögzítő csoport: ([0-9]+).

És egy szám kinyerésének és visszaadásának képességével az érték lehet triggerek meghatározására használják.

Using maxdelay parameter

The 'maxdelay' parameter in log items allows ignoring some older lines from log files in order to get the most recent lines analyzed within the 'maxdelay' seconds.

By default items for log monitoring follow all new lines appearing in the log files. However, there are applications which in some situations start writing an enormous number of messages in their log files. For example, if a database or a DNS server is unavailable, such applications flood log files with thousands of nearly identical error messages until normal operation is restored. By default, all those messages will be dutifully analyzed and matching lines sent to server as configured in log and logrt items.

Built-in protection against overload consists of a configurable 'maxlines' parameter (protects server from too many incoming matching log lines) and a 10*'maxlines' limit (protects host CPU and I/O from overloading by agent in one check). Still, there are 2 problems with the built-in protection. First, a large number of potentially not-so-informative messages are reported to server and consume space in the database. Second, due to the limited number of lines analyzed per second the agent may lag behind the newest log records for hours. Quite likely, you might prefer to be sooner informed about the current situation in the log files instead of crawling through old records for hours.

The solution to both problems is using the 'maxdelay' parameter. If 'maxdelay' > 0 is specified, during each check the number of processed bytes, the number of remaining bytes and processing time is measured. From these numbers the agent calculates an estimated delay - how many seconds it would take to analyze all remaining records in a log file.

If the delay does not exceed 'maxdelay' then the agent proceeds with analyzing the log file as usual.

If the delay is greater than 'maxdelay' then the agent ignores a chunk of a log file by "jumping" over it to a new estimated position so that the remaining lines could be analyzed within 'maxdelay' seconds.

Note that agent does not even read ignored lines into buffer, but calculates an approximate position to jump to in a file.

The fact of skipping log file lines is logged in the agent log file like this:

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
       logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
       (from byte 75653115 to byte 76332973) to meet maxdelay

The "to byte" number is approximate because after the "jump" the agent adjusts the position in the file to the beginning of a log line which may be further in the file or earlier.

Depending on how the speed of growing compares with the speed of analyzing the log file you may see no "jumps", rare or often "jumps", large or small "jumps", or even a small "jump" in every check. Fluctuations in the system load and network latency also affect the calculation of delay and hence, "jumping" ahead to keep up with the "maxdelay" parameter.

Setting 'maxdelay' < 'update interval' is not recommended (it may result in frequent small "jumps").

Megjegyzések a naplófájl 'copytruncate' elforgatásának kezeléséhez

A logrt a copytruncate opcióval különböző naplófájlokat feltételez különböző rekordokkal rendelkeznek (legalábbis az időbélyegük különbözik), ezért a kezdeti blokkok MD5 összege (legfeljebb az első 512 bájt) lesz különböző. Két fájl azonos MD5-ös kezdeti blokkokkal azt jelenti az egyik az eredeti, a másik egy másolat.

A logrt a copytruncate opcióval törekszik a helyes feldolgozásra naplófájl-másolatok másolatok jelentése nélkül. Azonban olyan dolgok, mint több naplófájl másolat készítése ugyanazzal az időbélyeggel, naplófájllal rotáció gyakrabban, mint logrt[] tétel frissítési időköz, gyakori a szer újraindítása nem javasolt. Az ügynök mindent megpróbál kezelni ezek a helyzetek ésszerűen jók, de jó eredmény nem garantálható minden körülmények között.

Megjegyzések a napló*[] elemek állandó fájljaihoz

Az állandó fájlok célja

Amikor a Zabbix ügynök elindul, megkapja az aktív ellenőrzések listáját a Zabbixtól szerver vagy proxy. A log*[] metrikákhoz megkapja a feldolgozott naplóméretet és a módosítási idő annak megállapítására, hogy honnan kezdje el a naplófájl figyelését. A naplófájl tényleges méretétől és a fájlonként jelentett módosítási időtől függően rendszerben az ügynök úgy dönt, hogy folytatja a naplófájl figyelését a feldolgozott naplóméretet, vagy elemezze újra a naplófájlt az elejétől.

Egy futó ügynök nagyobb attribútumkészletet tart fenn az összes megfigyelt nyomon követéséhez naplófájlokat az ellenőrzések között. Ez a memóriában lévő állapot elveszik, amikor az ügynök megállt.

Az új opcionális persistent_dir paraméter megadja a könyvtárat a log[], log.count[], logrt[] vagy logrt.count[] elem ezen állapotának tárolása egy fájlban. A naplóelem állapota visszaáll az állandó fájlból a következő után A Zabbix ügynök újraindul.

Az elsődleges felhasználási eset a tükrözött fájlban található naplófájl figyelése rendszer. Egy bizonyos pillanatig a naplófájl mindkét tükörbe íródik. Akkor a tükrök szét vannak osztva. Az aktív példányon a naplófájl még mindig növekszik, egyre új rekordok. A Zabbix ügynök elemzi és elküldi a feldolgozott naplók méretét és módosítási idő a szerverhez. A passzív másolaton a naplófájl változatlan marad, jóval az aktív példány mögött. Később az operációs rendszer és a Zabbix ügynök újraindult a passzív másolatról. A feldolgozott napló mérete és módosítási ideje a kiszolgálótól kapott Zabbix ügynök nem biztos, hogy érvényes az adott helyzetben passzív másolat. A naplófájlok figyelésének folytatása onnan, ahol az ügynök elhagyta off a fájlrendszer tükörfelosztásának pillanatában az ügynök visszaállítja állapotát az állandó fájl.

Ügynökművelet állandó fájllal

Indításkor a Zabbix ügynök semmit sem tud az állandó fájlokról. Csak azután az aktív ellenőrzések listájának vétele a Zabbix szervertől (proxy) az ügynök látja, hogy néhány naplózás Az elemeket meghatározott könyvtárakban lévő állandó fájloknak kell támogatniuk.

Az ügynök működése során a perzisztens fájlok megnyitásra kerülnek írásra (a fopen(fájlnév, "w")), és felülírják a legfrissebb adatokkal. Az esélye annak állandó fájladatok elvesztése, ha a felülírás és a fájlrendszer tükör kettéválik történjen ugyanakkor nagyon kicsi, nincs különösebb kezelés hozzá. Írás perzisztens fájlba NEM követi kényszerített szinkronizálás a tárolóval média (fsync() nincs hívva).

A legfrissebb adatokkal történő felülírás az egyeztetés sikeres jelentése után történik naplófájl rekord vagy metaadat (feldolgozott naplóméret és módosítási idő) a Zabbix szerver. Ez olyan gyakran előfordulhat, mint minden elem ellenőrzése, hogy a naplófájl megtartja-e változó.

Nincs különleges művelet az ügynök leállítása során.

Miután megkapta az aktív ellenőrzések listáját, az ügynök elavultnak és tartósnak jelöli fájlokat az eltávolításhoz. Egy állandó fájl elavulttá válik, ha: 1) a megfelelő a naplóelem már nem figyelhető meg, 2) egy naplóelemet újrakonfigurálnak egy másikkal persistent_ir hely, mint korábban.

Az eltávolítás 24 órás késéssel történik, mivel a naplófájlok NEM TÁMOGATOTT állapotban vannak nem szerepelnek az aktív ellenőrzések listáján, de TÁMOGATOTT válhatnak később, és az állandó fájljaik hasznosak lesznek.

Ha az ügynököt 24 óra lejárta előtt leállítják, akkor az elavult fájlok is leállnak nem törölhető, mivel a Zabbix ügynök nem kap információt a tartózkodási helyéről Zabbix szerver már.

Állandó fájlok elnevezése és helye

A Zabbix ügynök kulcsaik alapján különbözteti meg az aktív ellenőrzéseket. Például, a logrt[/home/zabbix/test.log] és a logrt[/home/zabbix/test.log,] különböző tételek. A logrt[/home/zabbix/test.log,,,10] elem módosítása itt: a logrt[/home/zabbix/test.log,,,20] kezelőfelület törlését eredményezi elem logrt[/home/zabbix/test.log,,,10] az ügynök aktív ellenőrzéseinek listájáról és logrt[/home/zabbix/test.log,,,20] elem létrehozása (egyes attribútumok átviszik a módosításokon a frontend/szerveren, nem pedig az ügynökön).

A fájlnév az elemkulcs MD5 összegéből áll, hozzáfűzve az elemkulcs hosszát az ütközések lehetőségének csökkentése érdekében. Például az állam logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] elem a c963ade4008054813bbc0a650bb8e09266 állandó fájlban tárolandó.

Több naplóelem is használhatja ugyanazt a persistent_dir értéket.

A persistent_dir az adott fájlrendszer figyelembevételével kerül meghatározásra elrendezések, rögzítési pontok és rögzítési lehetőségek, valamint a tárolási tükrözés konfigurációja - az állandó fájlnak ugyanazon a tükrözött fájlrendszeren kell lennie, mint a megfigyeltnek log fájl.

Ha a persistent_dir könyvtárat nem lehet létrehozni vagy nem létezik, vagy hozzáférhet A Zabbix ügynök jogai nem teszik lehetővé a fájlok létrehozását/írását/olvasását/törlését A naplóelem NEM TÁMOGATVA lesz.

Ha az ügynök működése során eltávolítják a perzisztens tárolófájlok hozzáférési jogait vagy más hiba lép fel (pl. a lemez megtelt), akkor a hibák bekerülnek az ügynöknaplóba fájlt, de a naplóelem nem válik NEM TÁMOGATVA.

Betöltés az I/O-n

A tétel állandó fájlja minden köteg sikeres elküldése után frissül adatok (tartalmazza az elem adatait) a szerverre. Például az alapértelmezett "BufferSize" 100. Ha egy naplóelem 70 egyező rekordot talált, akkor az első 50 rekord egy kötegben kerül elküldésre, az állandó fájl frissül, majd a maradék 20 a rekordok elküldésre kerülnek (talán némi késéssel, ha több adat gyűlik össze) be a 2. köteg, és az állandó fájl ismét frissül.

Actions if communication fails between agent and server

Each matching line from log[] and logrt[] item and a result of each log.count[] and logrt.count[] item check requires a free slot in the designated 50% area in the agent send buffer. The buffer elements are regularly sent to server (or proxy) and the buffer slots are free again.

While there are free slots in the designated log area in the agent send buffer and communication fails between agent and server (or proxy) the log monitoring results are accumulated in the send buffer. This helps to mitigate short communication failures.

During longer communication failures all log slots get occupied and the following actions are taken:

• log[] and logrt[] item checks are stopped. When communication is restored and free slots in the buffer are available the checks are resumed from the previous position. No matching lines are lost, they are just reported later.
• log.count[] and logrt.count[] checks are stopped if maxdelay = 0 (default). Behavior is similar to log[] and logrt[] items as described above. Note that this can affect log.count[] and logrt.count[] results: for example, one check counts 100 matching lines in a log file, but as there are no free slots in the buffer the check is stopped. When communication is restored the agent counts the same 100 matching lines and also 70 new matching lines. The agent now sends count = 170 as if they were found in one check.
• log.count[] and logrt.count[] checks with maxdelay > 0: if there was no "jump" during the check, then behavior is similar to described above. If a "jump" over log file lines took place then the position after "jump" is kept and the counted result is discarded. So, the agent tries to keep up with a growing log file even in case of communication failure.

Handling of regular expression compilation and runtime errors

If a regular expression used in log[], logrt[], log.count[] or logrt.count[] item cannot be compiled by PCRE or PCRE2 library then the item goes into NOTSUPPORTED state with an error message. To continue monitoring the log item, the regular expression should be fixed.

If the regular expression compiles successfully, but fails at runtime (on some or on all log records), then the log item remains supported and monitoring continues. The runtime error is logged in the Zabbix agent log file (without the log file record).

Note that the logging of regular expression runtime errors is supported since Zabbix 6.0.21.

The logging rate is limited to one runtime error per check to allow Zabbix agent to monitor its own log file. For example, if 10 records are analyzed and 3 records fail with a regexp runtime error, one record is produced in the agent log.

Exception: if MaxLinesPerSecond=1 and update interval=1 (only 1 record is allowed to analyze per check) then regexp runtime errors are not logged.

zabbix_agentd logs the item key in case of a runtime error, zabbix_agent2 logs the item ID to help identify which log item has runtime errors. It is recommended to redesign the regular expression in case of runtime errors.