3 Monitoratge de l'arxiu de registre

Vista general

Es pot emprar Zabbix per fer monitoratge centralitzat i anàlisi dels fitxers de registre amb/sense suport de rotació dels fitxers de registre.

Les notificacions es poden emprar per avisar els usuaris quan un arxiu de registre contingui cadenes o alguns models de cadenes.

Per supervisar-los, hem de tindre:

• Un agent Zabbix executant-se a l'equip
• Un paràmetre de supervisió d'arxiu de registre admès

Configuració

Verificar els paràmetres de l'agent

Assegureu-vos que a l'arxiu de configuració de l'agent:

• El paràmetre Hostname correspon al nom d'equip de la interfície Web.
• S'especifiquen els servidors del paràmetre ServerActive per al tractament de les verificacions actives.

Configuració de l'article

Configura un monitoratge de registre element.

{width="600"}

Tots els camps d'entrada obligatoris estan marcats amb un asterisc vermell.

Específicament per als elements de monitoratge de registre que introduïu:

Notes importants

• El servidor i l'agent mantenen la traça de la mida d'un registre monitoritzat i l'últim temps de modificació (per logrt) en dos comptadors. Addicionalment:
  • L'agent també utilitza internament números d'inode (en UNIX/GNU/Linux), índexs de fitxers (a Microsoft Windows) i MD5 sumes dels primers 512 bytes de fitxer de registre per millorar les decisions quan els fitxers de registre es trunquen i giren.
  • En els sistemes UNIX/GNU/Linux se suposa que els sistemes de fitxers on s'emmagatzemen els fitxers de registre informen de números d'inode, que es poden utilitzar per rastrejar fitxers.
  • A l'agent de Microsoft Windows Zabbix determina el sistema de fitxers tipus els fitxers de registre que resideixen i utilitzen:
    • En els sistemes de fitxers NTFS, índexs de fitxers de 64 bits.
    • En els sistemes de fitxers ReFS (només de Microsoft Windows Server 2012) ID de fitxer de 128 bits.
    • En els sistemes de fitxers on canvien els índexs de fitxers (per exemple, FAT32, exFAT) s'utilitza un algorisme de retrocés per adoptar un enfocament sensible en condicions incertes quan la rotació de fitxers de registre resulta en diversos fitxers de registre amb el mateix temps de modificació.
  • Els números d'inode, els índexs de fitxers i les sumes MD5 són recollits internament per l'agent Zabbix. No es transmeten al servidor de Zabbix i es perden quan s'atura l'agent Zabbix.
  • No modifiqueu l'últim temps modificat d'un fitxer de registre (per exemple, amb touch), i no substituïu un fitxer de registre supervisat copiant un fitxer al seu nom original (això crea un nou inode). En qualsevol cas, Zabbix pot tractar el fitxer com un fitxer diferent i tornar-lo a llegir des del principi, que pot produir alertes duplicades.
  • Si hi ha diversos fitxers de registre coincidents per a l'element logrt[] i l'agent Zabbix segueix el més recent d'ells i aquest fitxer de registre més recent s'elimina, s'ha registrat un missatge d'advertència ""no hi ha fitxers que coincideixin amb "<regexp mask>" a "<directory>". L'agent Zabbix ignora els fitxers de registre amb un temps de modificació inferior al temps de modificació més recent vist per l'agent per a l'element logrt[] que s'està comprovant.
• L'agent comença a llegir el fitxer de registre des del punt en què es va aturar l'hora anterior.
• El nombre de bytes ja analitzats (el comptador de mida) i l'últim temps de modificació (el comptador de temps) s'emmagatzemen a la base de dades Zabbix i s'envien a l'agent per assegurar-se que l'agent comença a llegir el fitxer de registre des d'aquest punt en els casos en què l'agent acaba d'iniciar-se o ha rebut elements que prèviament estaven desactivats o no suportats. Tanmateix, si l'agent ha rebut un comptador de mida diferent de zero del servidor, però l'element logrt[] o logrt.count[] no pot trobar fitxers coincidents, el comptador de mida es reinicia a 0 per analitzar des de l'inici si els fitxers apareixen més tard.
• Cada vegada que el fitxer de registre es fa més petit que el comptador de mida de registre conegut per l'agent, el comptador es restableix a zero i l'agent comença a llegir el fitxer de registre des del principi tenint en compte el comptador de temps.
• Si hi ha diversos fitxers coincidents amb el mateix últim temps de modificació al directori, l'agent intenta analitzar correctament tots els fitxers de registre amb el mateix temps de modificació i evitar saltar-se dades o analitzar les mateixes dades dues vegades, tot i que no es pot garantir en totes les situacions. L'agent no assumeix cap esquema de rotació de fitxers de registre en particular ni determina cap. Quan es presentin diversos fitxers de registre amb el mateix últim temps de modificació, l'agent els processarà en un ordre lexicogràficament descendent. Per tant, per a alguns esquemes de rotació, els fitxers de registre s'analitzaran i informaran en el seu ordre original. Per a altres esquemes de rotació, l'ordre de fitxer de registre original no serà honrat, cosa que pot conduir a informar de registres de fitxers de registre coincidents en ordre alterat (el problema no passa si els fitxers de registre tenen temps de modificació diferents).
• L'agent Zabbix processa nous registres d'un fitxer de registre una vegada per Interval d'actualització segons.
• L'agent Zabbix no envia més de maxlines d'un fitxer de registre per segon. El límit evita la sobrecàrrega de recursos de xarxa i CPU i anul·la el valor per defecte proporcionat pel paràmetre MaxLinesPerSecond en el fitxer de configuració de l'agent.
• Per trobar la cadena requerida Zabbix processarà 10 vegades més línies noves que les establertes a MaxLinesPerSecond. Així, per exemple, si un element log[] o logrt[] té Interval d'actualització d'1 segon, per defecte l'agent no analitzarà més de 200 registres de fitxers de registre i no enviarà més de 20 registres coincidents al servidor Zabbix en una sola comprovació. Mitjançant l'augment de MaxLinesPerSecond en el fitxer de configuració de l'agent o l'establiment de 'maxlines` paràmetre en la clau d'element, el límit es pot augmentar fins a 10000 registres de fitxers de registre analitzats i 1000 registres coincidents enviats al servidor Zabbix en una sola comprovació. Si l'interval Actualització s'estableix en 2 segons els límits d'una comprovació s'establiria 2 vegades més gran que amb Interval d'actualització d'1 segon.
• A més, els valors log i log.count sempre es limiten al 50% de l'agent d'enviar la mida de la memòria intermèdia, fins i tot si no hi ha valors que no hi ha registres. Per tant, perquè els valors maxlines s'enviïn en una connexió (i no en diverses connexions), el paràmetre agent BufferSize ha de ser com a mínim maxlines x 2. L'agent Zabbix pot pujar dades durant la recopilació de registres i, per tant, alliberar el buffer, mentre que l'agent Zabbix 2 deixarà de recollir registres fins que es carreguin les dades i s'alliberi el buffer, que es realitza de manera asíncrona.
• En absència d'elements de registre, tota la mida de la memòria intermèdia de l'agent s'utilitza per a valors que no són de registre. Quan els valors de registre entren, substitueixen els valors no log més antics segons sigui necessari, fins al 50% designat.
• Per als registres de fitxers de registre de més de 256kB, només els primers 256kB coincideixen amb l'expressió regular i la resta del registre s'ignora. No obstant això, si l'agent Zabbix s'atura mentre es tracta d'un llarg registre, l'estat intern de l'agent es perd i el registre llarg es pot analitzar de nou i de manera diferent després que l'agent torni a començar.
• Nota especial per a separadors de camins \: si file_format és file\.log, llavors no hauria d'haver-hi un directori file, ja que no és possible definir sense ambigüitats si "." s'escapa o és el primer símbol del nom del fitxer.
• Les expressions regulars per a logrt només són compatibles amb el nom de fitxer, la concordança d'expressió regular del directori no és compatible.
• A les plataformes UNIX, un element logrt[] esdevé NOTSUPORTAT si no existeix un directori on s'espera que es trobin els fitxers de registre.
• A Microsoft Windows, si no existeix un directori, l'element no es convertirà en NOTSUPPORTED (per exemple, si el directori està mal escrit en la clau d'element).
• Una absència d'arxius de registre per a l'element logrt[] no el fa NOTSUPORTED. Els errors de lectura dels fitxers de registre per a l'element logrt[] es registren com a advertències al fitxer de registre de l'agent Zabbix, però no fan que l'element NO SIGUI SUPOSAT.
• Zabbix agent arxiu de registre pot ser útil per esbrinar per què un element log[] o logrt[] es va fer NOTSUPPORTED. Zabbix pot monitoritzar el seu fitxer de registre d'agent, excepte quan a DebugLevel=4 o DebugLevel=5.
• Cerca d'un signe d'interrogació mitjançant una expressió regular, per exemple, \? 'pot resultar en falsos positius si el fitxer de text conté símbols NUL, ja que aquests són substituïts per? per Zabbix per continuar processant la línia fins al caràcter de la nova línia.

Extracció de la part de concordança de l'expressió regular

De vegades és possible que vulguem extreure només el valor interessant d'un fitxer de destinació en lloc de tornar tota la línia quan es troba una coincidència d'expressió regular.

Els elements de registre tenen la capacitat d'extreure els valors desitjats de les línies coincidents. Això s'aconsegueix mitjançant el paràmetre addicional output en log i logrt items.

L'ús del paràmetre 'output' permet indicar el "grup de captura" de la coincidència que ens pot interessar.

Així, per exemple:

``per defecte log[/path/to/the/file,"assignació de memòria intermèdia de resultats gran. *Entrades: ([0-9]+)",,,\1]

ha de permetre la devolució del recompte d'entrades que es troba en el contingut de:

``per defecte
Fr Feb 07 2014 11:07:36.6690 */ Id de fil 1400 (GLEWF) gran resultat
assignació de memòria intermèdia - /Longitud: 437136/Inscripcions: 5948/Client Ver: >=10/RPC
DNI: 41726453/Usuari: Usuari/Forma: CFG:ServiceLevelAcordement

Només el nombre serà retornat perquè \1 es refereix al primer i únic grup de captura: ([0-9]+).

I, amb la capacitat d'extreure i retornar un nombre, el valor es pot utilitzar per definir els desencadenants.

Ús del paràmetre maxdelay

El paràmetre maxdelay en els elements de registre permet ignorar algunes línies més antigues dels fitxers de registre per tal d'obtenir les línies més recents analitzades dins dels segons maxdelay.

::: avís de nota Especificar maxdelay > 0 pot conduir a ignorar registres de fitxers de registre importants i alertes perdudes. Utilitzeu-lo amb cura sota el vostre propi risc només quan sigui necessari. ::

Per defecte, els elements per a la monitorització de registre segueixen totes les línies noves que apareixen a els arxius de registre. No obstant això, hi ha aplicacions que en algunes situacions comencen a escriure un gran nombre de missatges en els seus arxius de registre. Per exemple, si una base de dades o un servidor DNS no està disponible, aquestes aplicacions inunden els fitxers de registre amb milers de missatges d'error gairebé idèntics fins que es restauri el funcionament normal. Per defecte, tots aquests missatges seran degudament analitzats i les línies de concordança enviades al servidor tal com es configuren en log i logrt elements.

La protecció integrada contra la sobrecàrrega consisteix en un paràmetre configurable (protegeix el servidor de massa línies de registre coincidents entrants) i un límit de 10*'maxlines' (protegeix la CPU de l'amfitrió i l'E / S de la sobrecàrrega per agent en una sola comprovació). Tot i així, hi ha 2 problemes amb la protecció integrada. En primer lloc, un gran nombre de missatges potencialment no tan informatius s'informen al servidor i consumeixen espai a la base de dades. En segon lloc, a causa del nombre limitat de línies analitzades per segon, l'agent pot quedar per darrere dels registres de registre més nous durant hores. Molt probable, és possible que preferiu estar informat més aviat sobre la situació actual en els fitxers de registre en lloc de rastrejar-se a través de registres antics durant hores.

La solució a tots dos problemes és l'ús del paràmetre maxdelay. Si s'especifica maxdelay > 0, durant cada comprovació el nombre de bytes processats, es mesura el nombre de bytes restants i el temps de processament. A partir d'aquests números, l'agent calcula un retard estimat: quants segons trigarien a analitzar tots els registres restants en un fitxer de registre.

Si el retard no supera maxdelay llavors l'agent procedeix amb l'anàlisi del fitxer de registre com de costum.

Si el retard és més gran que maxdelay llavors l'agent ignora un tros d'un fitxer de registre "saltant" sobre ell a una nova posició estimada de manera que les línies restants podrien ser analitzades dins dels segons maxdelay.

Tingueu en compte que l'agent ni tan sols llegeix les línies ignorades en memòria intermèdia, però calcula una posició aproximada per saltar a un arxiu.

El fet de saltar-se les línies de fitxer de registre es registra en el fitxer de registre de l'agent d'aquesta manera:

``per defecte 14287:20160602:174344.206 element:"logrt["/home/zabbix32/test[0-9].log,ERROR,,1000,,,120.0]" logfile:"/home/zabbix32/test1.log" saltant 679858 bytes (des de byte 75653115 fins a byte 76332973) per complir amb maxdelay

El nombre "a byte" és aproximat perquè després del "salt" l'agent ajusta la posició en el fitxer al començament d'una línia de registre que pot estar més lluny en el fitxer o abans.

Depenent de com la velocitat de creixement es compara amb la velocitat d'anàlisi de l'arxiu de registre que pot veure no "salts", rars o sovint "salts", grans o petits "salts", o fins i tot un petit "salt" en cada comprovació.
Les fluctuacions en la càrrega del sistema i la latència de xarxa també afecten el càlcul del retard i, per tant, "salta" per davant per mantenir-se al dia amb el paràmetre `maxdelay`.

L'establiment de `maxdelay` < `interval d'actualització` no es recomana (pot resultar en "salts" petits freqüents).

[comment]: # ({/5076af07-32045a26})

[comment]: # ({70cd03bf-57bbb0a9})
#### Notes sobre la gestió de 'copytruncate' en la rotació del fitxer de registre

`logrt` amb l'opció `copytruncate` assumeix que diferents fitxers de registre tenen registres diferents (almenys les seves marques de temps són diferents), de manera que les sumes MD5 dels blocs inicials (fins als primers 512 octets) seran diferents. Dos fitxers amb les mateixes sumes MD5 de blocs inicials signifiquen que un d'ells és l'original i l'altre n'és una còpia.

`logrt` amb l'opció `copytruncate` intenta gestionar correctament les còpies dels fitxers de registre sense marcar els duplicats. Tanmateix, coses com la producció de diverses còpies dels fitxers de registre amb la mateixa marca de temps, la rotació del fitxer de registre més sovint que l'interval d'actualització de l'element `logrt[]`, no es recomana el reinici freqüent de l'agent. L'agent intenta gestionar totes aquestes situacions de manera raonable, però no es poden garantir bons resultats en totes les circumstàncies.

[comment]: # ({/70cd03bf-57bbb0a9})

[comment]: # ({c5cdb98a-c5cdb98a})
#### Notes sobre fitxers persistents dels elements log\*\[\]

[comment]: # ({/c5cdb98a-c5cdb98a})

[comment]: # ({b5bf484f-99ce1d02})
######

Quan s'inicia l'agent Zabbix, rep una llista de comprovacions actives del servidor Zabbix o del servidor intermediari.
Per a les mètriques `log*[]` rep la mida del registre processat i el temps de modificació per trobar on iniciar el seguiment de fitxers de registre des de.
Depenent de la mida real del fitxer de registre i el temps de modificació reportat pel sistema de fitxers, l'agent decideix continuar el seguiment del fitxer de registre des de la mida del registre processat o tornar a analitzar el fitxer de registre des del principi.

Un agent en execució manté un conjunt més gran d'atributs per al seguiment de tots els fitxers de registre supervisats entre comprovacions.
Aquest estat en\-memòria es perd quan l'agent s'atura.

El nou paràmetre opcional `persistent_dir` especifica un directori per emmagatzemar aquest estat de `log[]`, `logcount[]`, `logrt[]` o `logrt.count[]` en un fitxer.
L'estat de l'element de registre es restaura a partir de l'arxiu persistent després que es reiniciï l'agent Zabbix.

L'ús principal\-cas és el seguiment d'arxiu de registre situat en un sistema de fitxers reflectit.
Fins a algun moment en el temps el fitxer de registre s'escriu a tots dos miralls.
Després es divideixen els miralls.
A la còpia activa, el fitxer de registre segueix creixent, obtenint nous registres.
L'agent Zabbix l'analitza i envia la mida dels registres processats i el temps de modificació al servidor.
A la còpia passiva, el fitxer de registre es manté igual, molt darrere de la còpia activa.
Més tard, el sistema operatiu i l'agent Zabbix es reinicien des de la còpia passiva.
La mida del registre processat i el temps de modificació que rep l'agent Zabbix del servidor pot no ser vàlid per a la situació a la còpia passiva.
Per continuar el seguiment de fitxers de registre des del lloc que l'agent va deixar en el moment de la divisió del sistema de fitxers, l'agent restaura el seu estat des del fitxer persistent.

[comment]: # ({/b5bf484f-99ce1d02})

[comment]: # ({4a4ad569-126798f0})
##### Funcionament de l'agent amb fitxer persistent

A l'inici, l'agent Zabbix no sap res dels fitxers persistents. Només després de rebre una llista de comprovacions actives del \(proxy\) o servidor Zabbix, l'agent entén que alguns elements de registre han de fer una còpia de seguretat mitjançant fitxers persistents als directoris especificats.

Mentre l'agent s'executa, els fitxers persistents s'obren per escriure (amb fopen(nom de fitxer, "w")) i es sobreescriuen amb les dades més recents. El risc de perdre dades de fitxers persistents si la rèplica del sistema de fitxers sobreescriu i es divideix al mateix temps és molt baix, no cal cap tractament especial. L'escriptura en un fitxer persistent NO és seguida d'una sincronització forçada amb el suport d'emmagatzematge \(no es fa la crida a `fsync()`\).

La sobreescriptura amb les dades més recents es fa després d'informar amb èxit del registre o metadades del fitxer de registre corresponent (mida del registre processat i temps de modificació) al servidor Zabbix. Això pot passar tan sovint com cada element comprova si el fitxer de registre continua canviant.

No cal pas cap acció especial en aturar l'agent.

[comment]: # ({/4a4ad569-126798f0})

[comment]: # ({33e68a77-0cf19270})
Després de rebre una llista de comprovacions actives, l'agent marca els fitxers persistents obsolets per esborrar-los.
Un fitxer persistent queda obsolet si:
1. L'element de registre corresponent ja no es monitora;
2. Un element de registre es torna a configurar amb una ubicació `persistent_dir` diferent a la d'abans.

L'esborrat es fa amb un retard de 24 hores perquè els fitxers de registre en estat NO ADMÈS no s'inclouen a la llista de comprovacions actives, però poden ser ADMESOS més tard i els seus fitxers persistents seran útils.

Si l'agent s'atura abans de la caducitat de les 24 hores, els fitxers obsolets no s'esborraran pas perquè l'agent Zabbix ja no rep informació sobre la seva ubicació del servidor Zabbix.

::: notewarning
Torneu a configurar el `persistent\_dir` d'un element de registre a l'antiga ubicació `persistent\_dir` mentre l'agent és inactiu, sense esborrar l'antic fitxer persistent per part de l'usuari; missatges perduts o alertes falses.
:::

[comment]: # ({/33e68a77-0cf19270})

[comment]: # ({77dab398-2ce6da68})
##### Nomenament i ubicació d'arxius persistents

L'agent Zabbix distingeix els controls actius per les seves claus.
Per exemple, `logrt[/home/zabbix/test.log]` i `logrt[/home/zabbix/test.log,]` són elements diferents.
La modificació de l'element `logrt[/home/zabbix/test.log,,,10]` en front endavant a `logrt[/home/zabbix/test.log,,,20]` donarà lloc a l'eliminació de l'element `logrt[/home/zabbix/test.log,,,10]` de la llista de xecs actius de l'agent i la creació de `logrt[/home/zabbix/test.log,,20]

El nom del fitxer es compon de la suma MD5 de la clau d'element amb la longitud de la clau d'element afegida per reduir la possibilitat de col·lisions.
Per exemple, l'estat de `logrt[/home/zabbix50/test.log,,,,,,,/home/zabbix50/agent_private]` es mantindrà en un fitxer persistent c963ade4008054813bbc0a650bb0b092666.

Diversos elements de registre poden utilitzar el mateix valor de `persistent_dir`.

`persistent_dir` s'especifica tenint en compte els dissenys específics del sistema de fitxers, els punts de muntatge i les opcions de muntatge i la configuració de rèplica d'emmagatzematge: el fitxer persistent hauria d'estar al mateix sistema de fitxers reflectit que el fitxer de registre supervisat.

Si el directori `persistent_dir` no es pot crear o no existeix, o els drets d'accés per a l'agent Zabbix no permeten crear/escriure/llegir/eliminar fitxers l'element de registre no s'ADMINISTRA.

[comment]: # ({/77dab398-2ce6da68})

[comment]: # ({8d97a3fc-e74fd773})
Si els drets d'accés als arxius d'emmagatzematge persistent s'esborren durant el funcionament de l'agent o si hi ha altre errors (per exemple, disc dur ple), els errors s'afegiran a l'arxiu de registre de l'agent però l'element de registre serà NO SUPORTAT.

[comment]: # ({/8d97a3fc-e74fd773})

[comment]: # ({38e18d73-975fe8d1})
##### Càrrega d' E/S

L'arxiu persistent de l'element s'actualitza després de l'enviament correcte de cada lot de dades \(que contenen les dades de l'element\) cap al servidor.
Per exemple, `BufferSize` per defecte és 100.
Si un element de registre ha trobat 0 registres corresponents, els primers 0 s'enviaran en un sol lot, l'arxiu persistent s'actualitzarà, i els 20 registres restants s'enviaran \(potser amb un cert endarreriment quan s'acumulin més dades\) al segon lot, i l'arxiu persistent serà actualitzat de nou.

[comment]: # ({/38e18d73-975fe8d1})

[comment]: # ({0f412795-df734a31})
### # Accions si la comunicació falla entre l'agent i el servidor

Cada línia corresponent des de l'element `log[]` i `logrt[]` i un resultat de cada `log.count[]` i `logrt.count[]` de comprovació d'element requereix una ranura lliure a l'àrea 50% designada en l'agent enviar memòria intermèdia.
Els elements de memòria intermèdia s'envien regularment al servidor (o proxy) i les ranures de memòria intermèdia tornen a ser gratuïtes.

Tot i que hi ha ranures gratuïtes a l'àrea de registre designada a l'agent, envieu memòria intermèdia i la comunicació falla entre l'agent i el servidor (o el servidor intermediari) els resultats de monitorització de registre s'acumulen a la memòria intermèdia d'enviament.
Això ajuda a mitigar els fracassos de comunicació curts.

Durant les fallades de comunicació més llargues, totes les ranures de registre s'ocupen i es prenen les següents accions:

- `log[]` i `logrt[]` els xecs d'element s'aturen.
Quan es restaura la comunicació i es disposa de ranures gratuïtes a la memòria intermèdia, es reprenen les comprovacions de la posició anterior.
No es perden línies coincidents, només s'informa més tard.
- `log.count[]` i `logrt.count[]` els xecs s'aturen si `maxdelay = 0` (per defecte).
El comportament és similar als elements `log[]` i `logrt[]` com es descriu més amunt.
Tingueu en compte que això pot afectar els resultats de `log.count[]` i `logrt.count[]`: per exemple, un xec compta 100 línies coincidents en un fitxer de registre, però com que no hi ha ranures lliures a la memòria intermèdia, la comprovació s'atura.
Quan es restaura la comunicació, l'agent compta amb les mateixes 100 línies coincidents i també 70 noves línies coincidents.
L'agent ara envia compte = 170 com si es trobessin en un sol xec.
- `log.count[]` i `logrt.count[]` comprova amb `maxdelay` > 0: si no hi va haver "salta" durant el xec, llavors el comportament és similar al descrit anteriorment.
Si es va produir un "saltar" sobre les línies de fitxer de registre, es manté la posició després de "saltar" i es descarta el resultat comptat.
Per tant, l'agent tracta de mantenir-se al dia amb un arxiu de registre en creixement, fins i tot en cas de fallada de comunicació.

[comment]: # ({/0f412795-df734a31})

[comment]: # ({3b1e0096-5233be27})
#### El maneig de la compilació d'expressió regular i els errors de temps d'execució

Si una expressió regular utilitzada en l'element `log[]`, `logrt[]`, `logt.count[]` o `logrt.count[]` no pot ser compilada per la biblioteca PCRE o PCRE2, llavors l'element entra en 
Estat NO compatible amb un missatge d'error.
Per continuar supervisant l'element de registre, s'ha de corregir l'expressió regular.

Si l'expressió regular es compila amb èxit, però falla en temps d'execució (en alguns o en tots els registres de registre), llavors l'element de registre roman suportat i 
El seguiment continua.
L'error de temps d'execució està registrat al fitxer de registre de l'agent Zabbix (sense el registre de fitxers de registre).

La taxa de registre es limita a un error de temps d'execució per comprovació per permetre a l'agent Zabbix controlar el seu propi fitxer de registre.
Per exemple, si s'analitzen 10 registres i 3 registres fallen amb un error de temps d'execució de regexp, es produeix un registre al registre de l'agent.

Excepció: si `MaxLinesPerSecond=1` i update interval=1 (només es permet analitzar 1 registre per comprovació) llavors els errors de temps d'execució de regexp no es registren.

zabbix_agentd registra la clau de l'element en cas d'un error en temps d'execució, zabbix_agent2 registra l'ID d'element per ajudar a identificar quin element de registre té errors de temps d'execució.
Es recomana redissenyar l'expressió regular en cas d'errors de temps d'execució.

[comment]: # ({/3b1e0096-5233be27})