3 Monitoraggio dei file di log

Panoramica

Zabbix può essere utilizzato per il monitoraggio centralizzato e l'analisi dei file di log con o senza supporto per la rotazione dei log.

Le notifiche possono essere utilizzate per avvisare gli utenti quando un file di log contiene determinate stringhe o pattern di stringhe.

Per monitorare un file di log è necessario disporre di:

• Zabbix agent in esecuzione sull'host
• item di monitoraggio dei log configurato

Configurazione

Verificare i parametri dell'agent

Assicurarsi che nel file di configurazione dell'agent:

• Il parametro Hostname corrisponda al nome dell'host nel frontend.
• I server nel parametro ServerActive siano specificati per l'elaborazione dei controlli attivi.

Configurazione dell'item

Configura un item per il monitoraggio dei log.

Tutti i campi di input obbligatori sono contrassegnati da un asterisco rosso.

In particolare, per gli item di monitoraggio dei log inserisci:

Note importanti

• Il server e l'agent tengono traccia della dimensione di un log monitorato e dell'ultima ora di modifica (per logrt) in due contatori. Inoltre:
  • L'agent usa anche internamente i numeri inode (su UNIX/GNU/Linux), gli indici di file (su Microsoft Windows) e le somme MD5 dei primi 512 byte del file di log per migliorare le decisioni quando i file di log vengono troncati e ruotati.
  • Su sistemi UNIX/GNU/Linux si presume che i file system in cui sono archiviati i file di log riportino numeri inode, che possono essere usati per tracciare i file.
  • Su Microsoft Windows Zabbix agent determina il tipo di file system su cui risiedono i file di log e usa:
    • Su file system NTFS indici di file a 64 bit.
    • Su file system ReFS (solo da Microsoft Windows Server 2012) ID file a 128 bit.
    • Su file system in cui gli indici di file cambiano (ad esempio FAT32, exFAT) viene usato un algoritmo di fallback per adottare un approccio sensato in condizioni incerte quando la rotazione dei file di log produce più file di log con la stessa ora di ultima modifica.
  • I numeri inode, gli indici di file e le somme MD5 vengono raccolti internamente da Zabbix agent. Non vengono trasmessi a Zabbix server e vengono persi quando Zabbix agent viene arrestato.
  • Non modificare l'ora dell'ultima modifica di un file di log (ad esempio con touch) e non sostituire un file di log monitorato copiando un file nel suo nome originale (questo crea un nuovo inode). In entrambi i casi Zabbix può trattare il file come un file diverso e rileggerlo dall'inizio, con il rischio di generare avvisi duplicati.
  • Se per l'item logrt[] esistono più file di log corrispondenti e Zabbix agent sta seguendo il più recente di essi, e questo file di log più recente viene eliminato, viene registrato un messaggio di avviso "there are no files matching "<regexp mask>" in "<directory>". Zabbix agent ignora i file di log con un'ora di modifica inferiore all'ora di modifica più recente vista dall'agent per l'item logrt[] in verifica.
• L'agent inizia a leggere il file di log dal punto in cui si era fermato la volta precedente.
• Il numero di byte già analizzati (il contatore della dimensione) e l'ora dell'ultima modifica (il contatore del tempo) vengono memorizzati nel database di Zabbix e vengono inviati all'agent per assicurare che l'agent inizi a leggere il file di log da questo punto nei casi in cui l'agent è appena stato avviato o ha ricevuto item che in precedenza erano disabilitati o non supportati. Tuttavia, se l'agent ha ricevuto da server un contatore della dimensione diverso da zero, ma l'item logrt[] o logrt.count[] non riesce a trovare file corrispondenti, il contatore della dimensione viene reimpostato a 0 per analizzare dall'inizio se i file compaiono in seguito.
• Ogni volta che il file di log diventa più piccolo del contatore della dimensione del log noto all'agent, il contatore viene reimpostato a zero e l'agent inizia a leggere il file di log dall'inizio tenendo conto del contatore del tempo.
• Se nella directory esistono più file corrispondenti con la stessa ora di ultima modifica, l'agent cerca di analizzare correttamente tutti i file di log con la stessa ora di modifica ed evitare di saltare dati o analizzare due volte gli stessi dati, anche se ciò non può essere garantito in tutte le situazioni. L'agent non presume alcuno schema particolare di rotazione dei file di log né ne determina uno. Quando vengono presentati più file di log con la stessa ora di ultima modifica, l'agent li elaborerà in ordine lessicografico decrescente. Pertanto, per alcuni schemi di rotazione i file di log verranno analizzati e segnalati nel loro ordine originale. Per altri schemi di rotazione l'ordine originale dei file di log non verrà rispettato, il che può portare a segnalare i record dei file di log corrispondenti in un ordine alterato (il problema non si verifica se i file di log hanno ore di ultima modifica diverse).
• Zabbix agent elabora i nuovi record di un file di log una volta ogni Update interval secondi.
• Zabbix agent non invia più di maxlines di un file di log al secondo. Il limite impedisce il sovraccarico delle risorse di rete e CPU e sostituisce il valore predefinito fornito dal parametro MaxLinesPerSecond nel file di configurazione dell'agent.
• Per trovare la stringa richiesta Zabbix elaborerà 10 volte più nuove righe rispetto a quanto impostato in MaxLinesPerSecond. Quindi, ad esempio, se un item log[] o logrt[] ha Update interval di 1 secondo, per impostazione predefinita l'agent analizzerà non più di 200 record del file di log e invierà non più di 20 record corrispondenti a Zabbix server in un singolo controllo. Aumentando MaxLinesPerSecond nel file di configurazione dell'agent o impostando il parametro maxlines nella chiave dell'item, il limite può essere aumentato fino a 10000 record del file di log analizzati e 1000 record corrispondenti inviati a Zabbix server in un singolo controllo. Se Update interval è impostato a 2 secondi, i limiti per un singolo controllo saranno impostati a un valore 2 volte superiore rispetto a Update interval di 1 secondo.
• Inoltre, i valori di log e log.count sono sempre limitati al 50% della dimensione del buffer di invio dell'agent, anche se non vi sono valori non di log al suo interno. Quindi, affinché i valori maxlines vengano inviati in una singola connessione (e non in più connessioni), il parametro BufferSize di Zabbix agent deve essere almeno pari a maxlines x 2. Zabbix agent può caricare i dati durante la raccolta dei log e quindi liberare il buffer, mentre Zabbix agent 2 interromperà la raccolta dei log fino a quando i dati non saranno caricati e il buffer non sarà liberato, operazione eseguita in modo asincrono.
• In assenza di item di log, l'intera dimensione del buffer dell'agent viene usata per i valori non di log. Quando arrivano valori di log, essi sostituiscono i valori non di log più vecchi secondo necessità, fino al 50% designato.
• Per record di file di log più lunghi di 256kB, solo i primi 256kB vengono confrontati con l'espressione regolare e il resto del record viene ignorato. Tuttavia, se Zabbix agent viene arrestato mentre sta elaborando un record lungo, lo stato interno dell'agent viene perso e il record lungo può essere analizzato di nuovo e in modo diverso dopo il riavvio dell'agent.
• Nota speciale per i separatori di percorso "\": se file_format è "file\.log", allora non dovrebbe esistere una directory "file", poiché non è possibile definire in modo univoco se "." è escapato oppure è il primo simbolo del nome del file.
• Le espressioni regolari per logrt sono supportate solo nel nome del file, la corrispondenza tramite espressione regolare sulla directory non è supportata.
• Su piattaforme UNIX un item logrt[] diventa NOTSUPPORTED se non esiste una directory in cui ci si aspetta di trovare i file di log.
• Su Microsoft Windows, se una directory non esiste l'item non diventerà NOTSUPPORTED (ad esempio, se la directory è scritta in modo errato nella chiave dell'item).
• L'assenza di file di log per l'item logrt[] non lo rende NOTSUPPORTED. Gli errori di lettura dei file di log per l'item logrt[] vengono registrati come warning nel file di log di Zabbix agent ma non rendono l'item NOTSUPPORTED.
• Il file di log di Zabbix agent può essere utile per capire perché un item log[] o logrt[] è diventato NOTSUPPORTED. Zabbix può monitorare il file di log del proprio agent, tranne quando è impostato DebugLevel=4 o DebugLevel=5.
• La ricerca di un punto interrogativo tramite un'espressione regolare, ad esempio \?, può produrre falsi positivi se il file di testo contiene simboli NUL, poiché questi vengono sostituiti con "?" da Zabbix per continuare a elaborare la riga fino al carattere di nuova riga.

Estrazione della parte corrispondente di un'espressione regolare

A volte potremmo voler estrarre solo il valore interessante da un file di destinazione invece di restituire l'intera riga quando viene trovata una corrispondenza con un'espressione regolare.

Gli item di tipo log hanno la possibilità di estrarre i valori desiderati dalle righe corrispondenti. Questo viene realizzato tramite il parametro aggiuntivo output negli item log e logrt.

L'uso del parametro 'output' consente di indicare il "gruppo di cattura" della corrispondenza che potrebbe interessarci.

Quindi, ad esempio

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

dovrebbe consentire di restituire il conteggio delle voci trovato nel contenuto di:

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

Verrà restituito solo il numero perché \1 si riferisce al primo e unico gruppo di cattura: ([0-9]+).

E, con la possibilità di estrarre e restituire un numero, il valore può essere utilizzato per definire i trigger.

Utilizzo del parametro maxdelay

Il parametro maxdelay negli item di log consente di ignorare alcune righe più vecchie dei file di log per analizzare entro i secondi di maxdelay le righe più recenti.

Per impostazione predefinita, gli item per il monitoraggio dei log seguono tutte le nuove righe che compaiono nei file di log. Tuttavia, esistono applicazioni che in alcune situazioni iniziano a scrivere un numero enorme di messaggi nei propri file di log. Ad esempio, se un database o un server DNS non è disponibile, tali applicazioni inondano i file di log con migliaia di messaggi di errore quasi identici fino al ripristino del normale funzionamento. Per impostazione predefinita, tutti questi messaggi verranno analizzati diligentemente e le righe corrispondenti verranno inviate al server come configurato negli item log e logrt.

La protezione integrata contro il sovraccarico consiste in un parametro configurabile maxlines (protegge il server da troppe righe di log corrispondenti in ingresso) e in un limite pari a 10*'maxlines' (protegge la CPU e l'I/O dell'host dal sovraccarico da parte dell'agent in un singolo controllo). Tuttavia, ci sono ancora 2 problemi con la protezione integrata. Primo, un gran numero di messaggi potenzialmente poco informativi viene segnalato al server e occupa spazio nel database. Secondo, a causa del numero limitato di righe analizzate al secondo, l'agent può rimanere indietro rispetto ai record di log più recenti per ore. Molto probabilmente, preferirai essere informato prima sulla situazione attuale nei file di log invece di dover scorrere per ore vecchi record.

La soluzione a entrambi i problemi è l'uso del parametro maxdelay. Se viene specificato maxdelay > 0, durante ogni controllo vengono misurati il numero di byte elaborati, il numero di byte rimanenti e il tempo di elaborazione. Da questi numeri l'agent calcola un ritardo stimato: quanti secondi servirebbero per analizzare tutti i record rimanenti in un file di log.

Se il ritardo non supera maxdelay, l'agent procede con l'analisi del file di log come di consueto.

Se il ritardo è maggiore di maxdelay, l'agent ignora un blocco di un file di log "saltandolo" fino a una nuova posizione stimata, in modo che le righe rimanenti possano essere analizzate entro maxdelay secondi.

Nota che l'agent non legge nemmeno le righe ignorate nel buffer, ma calcola una posizione approssimativa a cui saltare nel file.

Il fatto di saltare righe del file di log viene registrato nel file di log dell'agent in questo modo:

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

Il numero "to byte" è approssimativo perché dopo il "jump" l'agent adatta la posizione nel file all'inizio di una riga di log, che può trovarsi più avanti nel file oppure prima.

A seconda di come la velocità di crescita si confronta con la velocità di analisi del file di log, potresti non vedere alcun "jump", "jump" rari o frequenti, "jump" grandi o piccoli, oppure persino un piccolo "jump" a ogni controllo. Le fluttuazioni nel carico del sistema e la latenza di rete influenzano anch'esse il calcolo del ritardo e quindi il "jump" in avanti per tenere il passo con il parametro maxdelay.

Non è consigliato impostare maxdelay < update interval (potrebbe causare frequenti piccoli "jump").

Note sulla gestione della rotazione dei file di log 'copytruncate'

logrt con l'opzione copytruncate presuppone che file di log diversi contengano record diversi (almeno i loro timestamp sono diversi), pertanto le somme MD5 dei blocchi iniziali (fino ai primi 512 byte) saranno diverse. Due file con le stesse somme MD5 dei blocchi iniziali significano che uno di essi è l'originale, l'altro una copia.

logrt con l'opzione copytruncate si impegna a elaborare correttamente le copie dei file di log senza segnalare duplicati. Tuttavia, non sono consigliate situazioni come la creazione di più copie dello stesso file di log con lo stesso timestamp, la rotazione del file di log più frequentemente dell'intervallo di aggiornamento dell'item logrt[], o il riavvio frequente di agent. L'agent cerca di gestire tutte queste situazioni in modo ragionevole, ma non è possibile garantire risultati ottimali in tutte le circostanze.

Note sui file persistenti per gli item log*[]

Scopo dei file persistenti

Quando Zabbix agent viene avviato, riceve un elenco di controlli attivi da Zabbix server o proxy. Per le metriche log*[] riceve la dimensione del log elaborato e l'ora di modifica per individuare da dove iniziare il monitoraggio del file di log. A seconda della dimensione effettiva del file di log e dell'ora di modifica riportate dal file system, l'agent decide se continuare il monitoraggio del file di log dalla dimensione del log elaborato oppure rianalizzare il file di log dall'inizio.

Un agent in esecuzione mantiene un insieme più ampio di attributi per tenere traccia di tutti i file di log monitorati tra un controllo e l'altro. Questo stato in memoria viene perso quando l'agent viene arrestato.

Il nuovo parametro opzionale persistent_dir specifica una directory in cui memorizzare questo stato dell'item log[], log.count[], logrt[] o logrt.count[] in un file. Lo stato dell'item log viene ripristinato dal file persistente dopo il riavvio di Zabbix agent.

Il caso d'uso principale è il monitoraggio di un file di log situato su un file system mirrorato. Fino a un certo momento il file di log viene scritto su entrambi i mirror. Poi i mirror vengono separati. Sulla copia attiva il file di log continua a crescere, ricevendo nuovi record. Zabbix agent lo analizza e invia a server la dimensione del log elaborato e l'ora di modifica. Sulla copia passiva il file di log rimane invariato, molto indietro rispetto alla copia attiva. In seguito il sistema operativo e Zabbix agent vengono riavviati dalla copia passiva. La dimensione del log elaborato e l'ora di modifica che Zabbix agent riceve da server potrebbero non essere validi per la situazione sulla copia passiva. Per continuare il monitoraggio del file di log dal punto in cui l'agent si era fermato al momento della separazione del mirror del file system, l'agent ripristina il proprio stato dal file persistente.

Operazione dell'agent con file persistenti

All'avvio, Zabbix agent non sa nulla dei file persistenti. Solo dopo aver ricevuto un elenco di controlli attivi da Zabbix server (proxy), l'agent vede che alcuni item di log devono essere supportati da file persistenti nelle directory specificate.

Durante il funzionamento dell'agent, i file persistenti vengono aperti in scrittura (con fopen(filename, "w")) e sovrascritti con i dati più recenti. La probabilità di perdere i dati del file persistente se la sovrascrittura e la divisione del mirror del file system avvengono contemporaneamente è molto bassa; non è prevista alcuna gestione speciale. La scrittura nel file persistente NON è seguita da una sincronizzazione forzata sul supporto di memorizzazione (fsync() non viene chiamata).

La sovrascrittura con i dati più recenti viene eseguita dopo la corretta segnalazione a Zabbix server del record del file di log corrispondente o dei metadati (dimensione del log elaborata e ora di modifica). Ciò può accadere anche a ogni controllo dell'item se il file di log continua a cambiare.

Nessuna azione speciale durante l'arresto dell'agent.

Dopo aver ricevuto un elenco di controlli attivi, l'agent contrassegna i file persistenti obsoleti per la rimozione. Un file persistente diventa obsoleto se:

1. Il corrispondente item di log non è più monitorato.
2. Un item di log viene riconfigurato con una posizione persistent_dir diversa rispetto a prima.

La rimozione viene eseguita con un ritardo di 24 ore perché i file di log nello stato NOTSUPPORTED non sono inclusi nell'elenco dei controlli attivi, ma potrebbero diventare SUPPORTED in seguito e i loro file persistenti saranno utili.

Se l'agent viene arrestato prima che siano trascorse 24 ore, i file obsoleti non verranno eliminati, poiché Zabbix agent non riceve più da Zabbix server informazioni sulla loro posizione.

Denominazione e posizione dei file persistenti

Zabbix agent distingue i controlli attivi in base alle loro chiavi. Ad esempio, logrt[/home/zabbix/test.log] e logrt[/home/zabbix/test.log,] sono item diversi. La modifica dell'item logrt[/home/zabbix/test.log,,,10] nel frontend in logrt[/home/zabbix/test.log,,,20] comporterà l'eliminazione dell'item logrt[/home/zabbix/test.log,,,10] dall'elenco dei controlli attivi dell'agent e la creazione dell'item logrt[/home/zabbix/test.log,,,20] (alcuni attributi vengono trasferiti durante la modifica nel frontend/server, non nell'agent).

Il nome del file è composto dal checksum MD5 della chiave dell'item con la lunghezza della chiave dell'item aggiunta in coda, per ridurre la possibilità di collisioni. Ad esempio, lo stato dell'item logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] verrà mantenuto nel file persistente c963ade4008054813bbc0a650bb8e09266.

Più item di log possono usare lo stesso valore di persistent_dir.

persistent_dir viene specificato tenendo conto di layout specifici del file system, punti di mount e opzioni di mount e della configurazione di mirroring dello storage - il file persistente deve trovarsi sullo stesso file system mirrorato del file di log monitorato.

Se la directory persistent_dir non può essere creata o non esiste, oppure se i diritti di accesso per Zabbix agent non consentono di creare/scrivere/leggere/eliminare file, l'item di log diventa NOTSUPPORTED.

Se i diritti di accesso ai file di archiviazione persistente vengono rimossi durante il funzionamento dell'agent oppure si verificano altri errori (ad esempio, disco pieno), gli errori vengono registrati nel file di log dell'agent, ma l'item di log non diventa NOTSUPPORTED.

Carico su I/O

Il file persistente dell'item viene aggiornato dopo l'invio riuscito di ogni batch di dati (contenente i dati dell'item) al server. Ad esempio, il valore predefinito di BufferSize è 100. Se un item di log ha trovato 70 record corrispondenti, i primi 50 record verranno inviati in un unico batch, il file persistente verrà aggiornato, quindi i restanti 20 record verranno inviati (forse con un certo ritardo quando vengono accumulati più dati) nel secondo batch, e il file persistente verrà aggiornato di nuovo.

Azioni se la comunicazione fallisce tra agent e server

Ogni riga corrispondente da un item log[] e logrt[] e il risultato di ogni controllo di item log.count[] e logrt.count[] richiede uno slot libero nell'area dedicata al 50% nel buffer di invio dell'agent. Gli elementi del buffer vengono inviati regolarmente al server (o proxy) e gli slot del buffer tornano liberi.

Finché ci sono slot liberi nell'area log dedicata nel buffer di invio dell'agent e la comunicazione fallisce tra agent e server (o proxy), i risultati del monitoraggio dei log vengono accumulati nel buffer di invio. Questo aiuta a mitigare brevi interruzioni di comunicazione.

Durante interruzioni di comunicazione più lunghe, tutti gli slot dei log vengono occupati e vengono eseguite le seguenti azioni:

• I controlli degli item log[] e logrt[] vengono interrotti. Quando la comunicazione viene ripristinata e sono disponibili slot liberi nel buffer, i controlli riprendono dalla posizione precedente. Nessuna riga corrispondente viene persa, viene solo segnalata in un secondo momento.
• I controlli log.count[] e logrt.count[] vengono interrotti se maxdelay = 0 (predefinito). Il comportamento è simile a quello degli item log[] e logrt[] descritto sopra. Si noti che questo può influire sui risultati di log.count[] e logrt.count[]: ad esempio, un controllo conta 100 righe corrispondenti in un file di log, ma poiché non ci sono slot liberi nel buffer il controllo viene interrotto. Quando la comunicazione viene ripristinata, l'agent conta le stesse 100 righe corrispondenti e anche 70 nuove righe corrispondenti. L'agent ora invia count = 170 come se fossero state trovate in un unico controllo.
• I controlli log.count[] e logrt.count[] con maxdelay > 0: se durante il controllo non si è verificato alcun "salto", il comportamento è simile a quello descritto sopra. Se si è verificato un "salto" oltre le righe del file di log, viene mantenuta la posizione dopo il "salto" e il risultato conteggiato viene scartato. In questo modo, l'agent cerca di tenere il passo con un file di log in crescita anche in caso di guasto della comunicazione.

Gestione degli errori di compilazione ed esecuzione delle espressioni regolari

Se un'espressione regolare usata in un item log[], logrt[], log.count[] o logrt.count[] non può essere compilata dalla libreria PCRE o PCRE2, l'item passa allo stato NOTSUPPORTED con un messaggio di errore.
Per continuare a monitorare l'item di log, l'espressione regolare deve essere corretta.

Se l'espressione regolare viene compilata correttamente, ma fallisce in fase di esecuzione (su alcuni o su tutti i record di log), allora l'item di log rimane supportato e il monitoraggio continua.
L'errore di esecuzione viene registrato nel file di log dell'agent Zabbix (senza il record del file di log).

La frequenza di registrazione è limitata a un errore di esecuzione per controllo, per consentire all'agent Zabbix di monitorare il proprio file di log.
Ad esempio, se vengono analizzati 10 record e 3 record falliscono con un errore di runtime dell'espressione regolare, nel log dell'agent viene prodotto un solo record.

Eccezione: se MaxLinesPerSecond=1 e l'intervallo di aggiornamento è 1 (è consentito analizzare solo 1 record per controllo), allora gli errori di runtime dell'espressione regolare non vengono registrati.

zabbix_agentd registra la chiave dell'item in caso di errore di runtime, mentre zabbix_agent2 registra l'ID dell'item per aiutare a identificare quale item di log presenta errori di runtime.
In caso di errori di runtime, si consiglia di riprogettare l'espressione regolare.