6 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ó d'un element

Configurar un element de supervisió d'arxiu de registre:

Tots els camps obligatoris són marcats amb un asterisc vermell.

Específicament per els elements de supervisió d'arxius de registre, heu d'entrar:

Notes importants

• El servidor i l'agent fan un seguiment de la mida d'un registre monitorat i modificat durant la darrera hora (per al logrt) a dos comptadors. Addicionalment:
• L'agent també empra internament nombres d'inode (a UNIX/GNU/Linux), índexs de fitxers (a Microsoft Windows) i sumes MD5 dels primers 512 octets de fitxers de registre per millorar les decisions quan els fitxers de registre es trunquen i giren.
• Als sistemes UNIX/GNU/Linux, se suposa que els sistemes de fitxers on s'emmagatzemen els fitxers de registre retornen nombres d'inode, que es poden emprar per fer un seguiment dels fitxers.
• A Microsoft Windows, l'agent Zabbix determina el tipus de sistema de fitxers on resideixen els fitxers de registre i empra:
• En sistemes de fitxers NTFS indexa fitxers de 64 bits.
• En sistemes de fitxers ReFS (només des de Microsft Windows Server 2012) ID de fitxer de 128 bits.
• En sistemes de fitxers on els índexs de fitxers canvien (per exemple, FAT32, exFAT) s'empra un algorisme de reserva per adoptar un enfocament raonable en condicions incertes quan la rotació del fitxer de registre dóna lloc a diversos fitxers de registre amb el mateix temps de modificació.
• Els nombres d'inode, els índexs de fitxers i les sumes MD5 es recullen internament per l'agent Zabbix. No es transmeten al servidor Zabbix i es perden quan s'atura l'agent Zabbix.
• No modifiqueu l'hora de la darrera modificació dels fitxers de registre amb la utilitat 'touch', no recupereu un fitxer de registre conservant el seu nom original (això canviarà el nombre d'inode del fitxer). En qualsevol dels casos, el fitxer es considerarà diferent i s'escanejarà des del principi, la qual cosa pot generar alertes duplicades.
• Si hi ha diversos fitxers de registre coincidents per a l'element ''logrt[]'' i l'agent de Zabbix fa un seguiment del més recent d'ells i s'esborra aquest fitxer de registre més recent, s'envia al registre un missatge d'avís ''"no hi ha cap fitxer que coincideixi"<regexp màscara>" a "<directori>"''. L'agent Zabbix ignora els fitxers de registre el temps de modificació dels quals és 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 de quan es va aturar la vegada anterior.
• El nombre d'octets ja escanejats (el comptador de mida) i la darrera modificació (el comptador de temps) s'emmagatzemen a la base de dades de Zabbix i s'envien a l'agent per assegurar que l'agent comença a llegir el fitxer de registre des d'aquesta ubicació en cas que l'agent acabi d'iniciar-se o hagi rebut elements desactivats o no compatibles. Tanmateix, si l'agent va rebre un comptador de mida diferent de zero del servidor, però l'element logrt[] o logrt.count[] no s'ha trobat i no ha trobat cap fitxer coincident, el comptador de mida es restablirà a 0 si els fitxers apareixen més tard.
• Cada cop que el fitxer de registre sigui més petit que el comptador de mida del fitxer de registre conegut per l'agent, el comptador es reinicia i l'agent comença a llegir el fitxer de registre des del principi tinguent en compte el comptador de temps.
• Si al directori hi ha diversos fitxers corresponents amb el mateix temps de modificació, l'agent analitza tots els fitxers de registre amb el mateix temps de modificació i evita saltar dades o analitzar les mateixes dades dues vegades, encara que això no es pot garantir. L'agent no assumeix cap esquema de rotació de fitxers de registre particular i no en determina cap. Quan es presenten diversos fitxers de registre amb la mateixa hora de darrera modificació, l'agent els processa en ordre lexicogràfic descendent. Així, per a determinats esquemes de rotació, els fitxers de registre s'analitzaran i s'informaran en el seu ordre original. Per a altres esquemes de rotació, no es respectarà l'ordre dels fitxers de registre originals, fet que pot provocar que es generin informes als fitxers de registre corresponents (el problema no es produeix si els fitxers de registre tenen diferents temps de modificació).
• L'agent Zabbix processa nous registres de fitxers de registre una vegada per //interval d'actualització// segons.
• L'agent Zabbix no envia més d'un fitxer de registre maxlines per segon. El límit evita la sobrecàrrega de recursos de la xarxa i de la CPU i anul·la el valor predeterminat proporcionat pel paràmetre MaxLinesPerSecond al fitxer de configuració de l'agent](/manual/appendix/config/zabbix_agentd).
• Per trobar la cadena necessària, Zabbix processarà 10 vegades més noves línies que a MaxLinesPerSecond. Per exemple, si un element log[] o logrt[] té un interval d'actualització d'1 segon, l'agent no analitzarà, de manera predeterminada, 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ó. Augmentant MaxLinesPerSecond al fitxer de configuració de l'agent o establint el paràmetre maxlines a la clau d'element, el límit es pot augmentar fins a 10.000 registres de fitxer de registre escanejats i 1.000 registres coincidents enviats al servidor Zabbix en una sola comprovació. Si l'interval d'actualització s'estableix a 2 segons, els límits d'una comprovació s'establiran 2 vegades més que amb l'interval d'actualització d'1 segon.
• A més, els valors de log i log.count sempre són limitats al 50% de la mida del buffer d'enviament de l'agent, fins i tot si no hi ha valors que no siguin de registre. Per tant, perquè els valors de maxlines s'enviïn en una connexió (i no en diverses connexions), el paràmetre BufferSize de l'agent ha d'ésser com a mínim maxlines x 2.
• Si no hi ha elements de registre, s'empra tota la mida del buffer de l'agent per als valors que no són de registre. Quan arriben els valors dels fitxers de registre, sobreescriuen els valors antics que no són de registre, segons sigui necessari, fins a un 50%.
• Per als registres de fitxers de registre més grans de 256 Ko, només els primers 256Ko coincideixen amb l'expressió regular i la resta del registre s'ignora. Tanmateix, si l'agent Zabbix s'atura mentre processa un registre llarg, l'estat intern de l'agent es perd i el registre llarg es pot analitzar de nou i de manera diferent després de reiniciar l'agent.
• Nota especial per als separadors de camins "\": si filer_format és "file.log", no hi ha d'haver un directori "file" perquè és impossible 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'admeten al nom de fitxer, la concordança d'expressions regulars del directori no és compatible.
• A les plataformes UNIX, logrt[] passa a NO ADMÈS si no existeix un directori on s'hi han de trobar els fitxers de registre.
• A Microsoft Windows, si un directori no existeix, l'element no passarà a NO ADMÈS (per exemple, si el directori s'ha escrit malament a la clau de l'element).
• L'absència de fitxers de registre per a logrt[] no fa que NO S'ADMETI. Els errors de lectura dels fitxers de registre per a logrt[] es registren com a avisos al fitxer de registre de l'agent Zabbix, però no mostren l'element NO ADMÈS.
• El fitxer de registre de l'agent Zabbix pot ésser útil per sapiguer per què un element log[] o logrt[] no s'admet. Zabbix pot monitorar el fitxer de registre de l'agent excepte a DebugLevel=4 i DebugLevel=5.
• Buscar un signe d'interrogació mitjançant una expressió regular, com ara \? pot donar lloc a falsos positius si el fitxer de text conté símbols NUL, ja que es substitueixen per "?" per Zabbix per continuar processant la línia fins al caràcter de nova línia.

Extracció de la part coincident de l'expressió regular

De vegades volem extreure només el valor interessant d'un fitxer de destinació en lloc de retornar tota la fila quan es troba una coincidència d'expressió regular.

Des de Zabbix 2.2.0, els elements del fitxer de registre tenen la capacitat d'extreure els valors desitjats de les fileres corresponents. Això s'aconsegueix mitjançant el paràmetre addicional output als elements log i logrt.

L'ús del paràmetre 'sortida' ens permet indicar el "grup capturat" de la part que ens pot interessar.

Així, per exemple:

 log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

hauria de retornar el nombre d'entrades tal com es troba al contingut de:

 Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result
       buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
       ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement

Només es retornarà el nombre perquè \1 es refereix al primer i únic grup capturat: ([0-9]+)

I, amb la possibilitat d'extreure i retornar un nombre, el valor es pot emprar per establir triggers.

Ús del paràmetre maxdelay

El paràmetre 'maxdelay' als elements de registre permet que es saltin algunes línies més antigues dels fitxers de registre per tal d'analitzar les línies més noves en uns segons 'maxdelay'.

De manera predeterminada, els elements de monitoratge del registre fan un seguiment de totes les línies noves que apareixen als fitxers de registre. Tanmateix, hi ha aplicacions que en determinades situacions comencen a escriure un gran nombre de missatges als seus fitxers de registre. Per exemple, si una base de dades o un servidor DNS no és pas disponible, aquestes aplicacions omplen els fitxers de registre amb milers de missatges d'error gairebé idèntics fins que es restableix el funcionament normal. Per defecte, tots aquests missatges s'analitzaran a fons i les línies corresponents s'enviaran al servidor tal com es configura als elements log i logrt.

La protecció de sobrecàrrega integrada consisteix en un paràmetre configurable 'maxlines' (protegeix el servidor contra massa línies de registre coincidents entrants) i un límit de 10*'maxlines' (protegeix la CPU de l'equip i les E/S de la sobrecàrrega de l'agent en un sol control). Tanmateix, hi ha 2 problemes amb la protecció integrada: En primer lloc, un gran nombre de missatges potencialment poc informatius s'informa al servidor i consumeixen espai a la base de dades. En segon lloc, a causa del nombre limitat d'arxius processats per segon, l'agent pot endarrerir els registres de registre més recents durant hores. El més probable és que preferiu rebre una notificació de la situació actual als fitxers de registre més aviat en lloc de navegar per registres antics durant hores.

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

Si el retard no supera 'maxdelay', l'agent procedeix a analitzar el fitxer de registre com de costum.

Si el retard és superior a 'maxdelay', l'agent omet un tros d'un fitxer de registre fent un "salt" per sobre a una nova posició estimada de manera que les línies restants es puguin escanejar en "maxdelay" segons.

Tingueu en compte que l'agent ni tan sols llegeix les línies saltades a la memòria intermèdia, sinó que calcula una posició aproximada a la qual saltar en un fitxer.

Ometre les línies del fitxer de registre es registra al fitxer de registre de l'agent com aquest:

 14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
       logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
        (de l'octet 75653115 a l'octet 76332973 per complir amb el retard màxim)

El nombre "per octet" és aproximat perquè després del "salt" l'agent ajusta la posició al fitxer al començament d'una línia de registre que pot ser més tard al fitxer o abans.

Depenent de com es compari la velocitat de creixement amb la velocitat d'anàlisi del fitxer de registre, és possible que no veieu cap "salt", veureu "salts" rars o freqüents, "salts grans o petits" o fins i tot un petit "salt" amb cada control. Les fluctuacions en la càrrega del sistema i la latència de la xarxa també afecten el càlcul del retard i, per tant, "saltar" endavant per seguir la configuració "maxdelay".

No es recomana establir 'maxdelay' < 'interval d'actualització' (pot donar lloc a freqüents petits "salts").

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.

Notes sobre fitxers persistents dels elements log*[]

Objectiu dels fitxers persistents

Quan s'inicia l'agent Zabbix, rep una llista de comprovacions actives del servidor o proxy Zabbix. Per a les mètriques de registre*[], rep la mida del registre processat i el temps de modificació per trobar on començar a monitorar el fitxer de registre. En funció de la mida real del fitxer de registre i del temps de modificació informat pel sistema de fitxers, l'agent decideix si continua monitorant el fitxer de registre en funció de la mida del registre processat o torna a escanejar el fitxer de registre des del principi.

Un agent en execució manté un conjunt més gran d'atributs per fer el seguiment de tots els fitxers de registre monitorats entre comprovacions. Aquest estat a la memòria es perd quan s'atura l'agent.

El nou paràmetre opcional persistent_dir especifica un directori on emmagatzemar aquest estat de l'element log[], log.count[], logrt[] o logrt.count[] a la carpeta A. L'estat de l'element de registre es restaura des del fitxer persistent després de reiniciar l'agent Zabbix.

El cas d'ús principal és monitorar el fitxer de registre situat en un sistema de fitxers duplicat. Fins a un cert punt, el fitxer de registre s'escriu als dos miralls. Després es divideixen els miralls. A la còpia activa, el fitxer de registre continua creixent, obtinguent nous registres. L'agent Zabbix l'analitza i envia la mida i el temps de modificació dels registres processats al servidor. A la còpia passiva, el fitxer de registre continua sent el mateix, molt per 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 l'agent Zabbix rep del servidor poden no ser vàlids per a la situació de la còpia passiva. Per continuar monitorant el fitxer de registre des d'on el va deixar l'agent quan es va dividir la rèplica del sistema de fitxers, l'agent restaura el seu estat des del fitxer persistent.

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 (fsync() no s'anomena).

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.

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.

Nomenament i ubicació dels arxius persistents

L'agent Zabbix distingeix les validacions actius per les seves claus. Per exemple, logrt[/home/zabbix/test.log] i logrt[/home/zabbix/test.log,] són elements diferents. Si canvieu l'element logrt[/home/zabbix/test.log,,,10] a la interfície a logrt[/home/zabbix/test.log,,,20] farà que l'element logrt[/home /zabbix/test.log,,,10] s'esborri de la llista de comprovacions actives de l'agent creant l'element logrt[/home/zabbix/test.log,,,20] (alguns atributs es passen quan s'editen a la interfície/servidor, no pas a l'agent).

El nom del fitxer es composa de la suma MD5 de la clau d'element amb la longitud de la clau d'element afegida per reduir el risc de col·lisions. Per exemple, l'estat de l'element logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] es mantindrà al fitxer persistent c963ade4008054813bbc0a650bb8e09266.

Diversos elements de registre poden emprar el mateix valor persistent_dir.

persistent_dir s'especifica tinguent 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 ha d'ésser al mateix sistema de fitxers duplicat que el fitxer de registre monitorat.

Si no es pot crear el directori persistent_dir o no existeix, o si els drets d'accés per a l'agent Zabbix no permeten crear/escriure/llegir/esborrar fitxers, el registre d'elements esdevindrà NO SUPORTAT.

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.

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.

Accions a emprendre si la comunicació entre l'agent i el servidor falla

Cada línia coincident de l'element log[] i logrt[] i el resultat de cada log.count[] i logrt.count[] requereix un espai lliure a l'àrea designada del 50% a buffer que envia l'agent. Els elements de memòria intermèdia s'envien regularment al servidor (o al proxy) i els espais de memòria de memòria intermèdia tornen a ésser lliures.

Tot i que hi ha espais lliures a l'àrea de fitxer de registre designada a la memòria intermèdia d'enviament de l'agent i la comunicació entre l'agent i el servidor (o el proxy), els registres de resultats de la supervisió de fitxers s'acumulen a la memòria intermèdia d'enviament. Això ajuda a esmorteir els errors de comunicació puntuals.

Durant errors de comunicació més llargs, totes les ubicacions de registre són ocupades i es duen a terme les accions següents:

• Les comprovacions dels elements log[] i logrt[] són aturades. Quan es restableix la comunicació i s'alliberen els espais a la memòria intermèdia, les comprovacions es reprenen des de la posició anterior. No es perd cap filera coincident, només es trasllada.
• Les comprovacions log.count[] i logrt.count[] s'aturen si maxdelay = 0 (per defecte). El comportament és similar als elements log[] i logrt[] descrits anteriorment. Tingueu en compte que això pot afectar els resultats de log.count[] i logrt.count[]: per exemple, una comprovació compta 100 línies coincidents en un fitxer de registre, però com que no hi ha espai lliure a la memòria intermèdia, el control s'atura. Quan es restableix la comunicació, l'agent compta les mateixes 100 línies coincidents i 70 noves línies coincidents. L'agent ara envia counter=170 com si es trobés en una validació.
• Les comprovacions log.count[] i logrt.count[] amb maxdelay > 0: si no hi ha hagut cap "salt" durant la comprovació, el comportament és similar al descrit anteriorment. Si s'ha produït un "salt" per sobre de les línies del fitxer de registre, es conserva la posició després del "salt" i es descarta el resultat comptat. Per tant, l'agent intenta mantindre's al dia amb un fitxer de registre en expansió, fins i tot quan la comunicació falla.

Gestió de la compilació d'expressions regulars i els errors d'execució

Si una expressió regular emprada a l'element log[], logrt[], log.count[] o logrt.count[] no es pot compilar per la biblioteca PCRE o PCRE2, l'element entra a Estat NO ADMÈS amb un missatge d'error. Per continuar monitorant l'element de registre, s'hauria de corregir l'expressió regular.

Si l'expressió regular es compila correctament, però falla en temps d'execució (en alguns o en tots els registres de registre), aleshores l'element de registre continua sent compatible i el monitoratge continua. L'error d'execució es registra al fitxer de registre de l'agent Zabbix (sense el registre del fitxer de registre).

Tingueu en compte que el registre d'errors d'execució d'expressions regulars és compatible des de Zabbix 6.4.6.

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

Excepció: si MaxLinesPerSecond=1 i l'interval d'actualització=1 (només es permet analitzar 1 registre per comprovació), no es registren els errors d'execució de l'expressió regular.

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