Monitoraggio dei file di log

Il pacchetto di installazione dell'agente Checkmk Raw per Windows non contiene un ambiente Python. Tuttavia, un file corrispondente è già disponibile sul tuo server Checkmk. Puoi trovare questo file chiamato python-3.cab nella directory ~/share/check_mk/agents/windows o in Checkmk tramite Setup > Agents > Windows > Windows Agent. Copia questo file nel tuo host Windows nella directory C:\Program Files (x86)\checkmk\service\install. Esiste già un file con questo nome e una dimensione di 0 byte. Devi sovrascrivere questo file con la versione del server Checkmk. Poi riavvia il servizio agente Checkmk. In Windows PowerShell con diritti di amministratore, puoi farlo con il seguente comando:

Una volta riavviato il servizio di Windows, l'ambiente virtuale Python sarà stato installato automaticamente.

In alternativa, puoi anche scaricare e installare un pacchetto Python completo da python.org. Assicurati di attivare le seguenti opzioni durante l'installazione:

Se vuoi iniziare i test subito dopo l'installazione di Python, è essenziale riavviare checkmkservice tramite il Task Manager di Windows o con i comandi indicati sopra, altrimenti il servizio non saprà delle nuove variabili d'ambiente.

Nelle edizioni commerciali, per prima cosa richiama la regola per il plug-in dell'agente Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Text logfiles (Linux, Solaris, Windows). L'impostazione predefinita Deploy the Logwatch plugin and its configuration dovrebbe normalmente essere lasciata così com'è. Tuttavia, se vuoi o devi trasferire il file di configurazione logwatch.cfg all'host in un modo diverso, l'opzione Deploy the Logwatch plugin without configuration è ancora disponibile.

Continua con l'opzione Retention period. Il valore predefinito è di un minuto, che corrisponde anche all'intervallo di controllo preimpostato in Checkmk. Questo valore dovrebbe essere sempre almeno uguale all'intervallo di controllo. Questa opzione serve principalmente a garantire che non vengano persi messaggi di log a causa del rilevamento di un servizio o dell'esecuzione manuale di cmk -d myhost. Ulteriori dettagli sono disponibili nell'aiuto inline dell'opzione e nel Werk #14451 con cui è stata introdotta questa opzione.

Ora arriva la sezione della regola in cui le cose si fanno davvero interessanti:Configure a logfile section. Inizieremo direttamente con il più grande ostacolo degli ultimi anni. Nel campo Patterns for logfiles to monitor dovrai specificare i file di log che vuoi monitorare. Puoi farlo individualmente ed esplicitamente o con i cosiddetti modelli glob (glob in breve). Qui stiamo usando il modulo Python glob, per il quale esiste una documentazione dettagliata su docs.python.org. Tuttavia, vorremmo fornirti alcuni esempi utili proprio qui.

Ad esempio, se inserisci qui /var/log/my.log, logwatch monitorerà solo questo singolo file di log. Se invece inserisci qui /var/log/*log, logwatch monitorerà tutti i file che terminano con la stringa di caratteri log e che si trovano direttamente nella directory /var/log. Se vuoi monitorare i file di log in tutte le sottodirectory dirette di /var/, puoi farlo con il seguente glob, ad esempio: /var/*/*log. Non offriamo esplicitamente il glob ** per la ricerca ricorsiva in una struttura di directory, perché ci ritroveremmo con un elenco di risultati troppo grande e troppo velocemente e lasceremmo alle spalle lo scopo reale di logwatch.

La tabella seguente ti fornisce alcuni esempi utili di come puoi utilizzare i globi per monitorare effettivamente i file da monitorare senza doverli specificare tutti singolarmente:

Quindi, per quanto riguarda i file che vengono "abbinati" nel primo passaggio, non utilizziamo espressioni regolari e questo potrebbe essere sufficiente per raggiungere tutti i file che desideri.

Tuttavia, se ora hai bisogno di filtrare ulteriormente, puoi utilizzare l'opzione Regular expression for logfile filtering per applicare le espressioni regolari ai risultati del passo 1 in un secondo passo.

Se hai raccolto tutti i file /var/log/ e le sue sottodirectory dirette nel primo passaggio con /var/log/ e /var/log/*/*, puoi utilizzare l'espressione regolare error.log$|err$ per ridurre l'elenco dei risultati a tutti i file che terminano con err.log o err. Attenzione: Il "punto" (.) è ancora una volta un carattere arbitrario e potrebbe, ad esempio, lasciare i file /var/log/apache2/error.log, /var/log/mail.err e /var/log/cups/error_log.

Come puoi vedere, ti abbiamo già fornito due strumenti validi e potenti per la selezione dei file da monitorare, in modo che logwatch possa controllare anche gli altri parametri e contenuti in modo molto rapido nella fase successiva, utilizzando un elenco di file gestibile. Puoi approfondire la tua conoscenza di quest'ultimo aspetto nell'articolo Espressioni regolari in Checkmk.

Con l'opzione Restrict the length of the lines puoi indicare a logwatch di troncare le righe troppo lunghe dopo il numero di caratteri specificato.

La seguente opzione Watch the total size of the log file è utile per riconoscere una rotazione difettosa dei log. Se imposti 100 MiB, riceverai un avviso ogni volta che un determinato file di log avrà superato la dimensione specificata.

Il numero massimo di righe che logwatch controlla per ogni esecuzione e per ogni file può essere limitato con Restrict number of processed messages per cycle e con Restrict runtime of logfile parsing puoi assicurarti che logwatch non si soffermi troppo a lungo su un singolo file che potrebbe essere stato invaso da migliaia e migliaia di nuove voci dall'ultimo controllo.

Se attivi una delle ultime due opzioni, devi anche specificare cosa succede se il limite specificato viene superato. Con l'impostazione predefinita, il servizio associato diventa critico e ricevi un messaggio che ti informa che sono state saltate delle righe o che è stato superato il tempo massimo di esecuzione.

Handling of context messages È un'opzione con la quale il volume dei dati trasferiti può diventare molto grande molto rapidamente. Quindi pensa bene se per te è importante solo il messaggio di log che ritieni debba generare un CRIT o un WARN o se tutte le righe che sono state aggiunte dall'ultima esecuzione di logwatch devono essere trasferite al server Checkmk. Per i file di log di piccole dimensioni che crescono solo di poche righe al minuto, l'impostazione Do transfer context non presenta certamente problemi. Tuttavia, se su un host vengono monitorati 50 file di log che improvvisamente contengono 100.000 nuove righe con una lunghezza di 500 caratteri, siamo già nell'ordine dei gigabyte. In un evento del genere, potrebbe essere sufficiente vedere che è stato aggiunto un gran numero di nuovi messaggi dall'ultimo controllo per avviare un controllo direttamente sull'host interessato.

Se hai bisogno del contesto, cioè delle righe prima e dopo il messaggio di log che ti interessa, puoi limitarlo a un certo numero di righe prima e dopo con l'opzione Limit the amount of context data sent to the monitoring server.

Con Limit the amount of data sent to the monitoring server puoi limitare la dimensione dei dati trasferiti in generale.

Process new logfiles from the beginning Questo a volte suscita stupore, perché logwatch non "riconosce" i problemi presenti nei file di log e li trasmette al server Checkmk. A nostro avviso, nulla è più vecchio del giornale di ieri e lo stesso vale per i messaggi di log che erano già presenti in un file di log prima della prima esecuzione di logwatch. Durante questa prima esecuzione, logwatch non fa altro che prendere nota del numero di righe già presenti nel rispettivo file di log. Solo durante la seconda esecuzione i file vengono controllati per verificarne il contenuto, ovvero le righe appena aggiunte.

Logwatch si basa sull'effettiva capacità di leggere i file di log. Sotto il cofano, logwatch fa di tutto per riconoscere la codifica di ogni file di log. Tuttavia, le codifiche dei caratteri troppo esotiche possono causare problemi. Se puoi specificare la codifica dei caratteri dei file di log monitorati, UTF-8 è un'ottima scelta. Se questo non è possibile e logwatch non riesce a scoprire la codifica, puoi specificarla esplicitamente con Codec that should be used to decode the matching files.

Con Duplicated messages management, se attivi questa opzione, puoi ancora una volta risparmiare un po' di banda e l'output successivo in Checkmk sarà anche più leggibile. Se attivi Filter out consecutive duplicated messages in the agent output, Logwatch conta quante volte una riga è stata ripetuta e lo scrive di conseguenza nell'output invece di ripetere le righe.

Infine, le righe dei file di log che ti interessano vengono ora descritte utilizzando un'espressione regolare e assegnate a uno stato. Se vuoi che ogni riga contenente la parola panic porti a un CRIT in Checkmk, è sufficiente inserire panic nel campo Pattern(Regex) dopo aver fatto clic su Add message pattern sotto Regular expressions for message classification. Le funzioni delle altre opzioni offerte sono già descritte in modo molto dettagliato nell'aiuto inline a questo punto e non vengono duplicate qui.

Un punto da notare: lo stato OK può sembrare confuso a prima vista. Viene utilizzato per trasferire le righe da un file di log al server Checkmk per poi effettuare la classificazione finale. Questo ci porta a un punto importante che dimostra quanto logwatch possa essere flessibile se usato correttamente.

Tutte le opzioni spiegate in questa sezione diventano voci nel file di configurazione già citato, che viene memorizzato sul rispettivo host. Se ora vuoi apportare delle modifiche alla classificazione di alcuni messaggi, dovrai prima modificare la regola, quindi creare l'agente e installarlo.

In alternativa, puoi prima trasferire tutti i messaggi interessanti al server Checkmk (ad esempio con lo stato OK ) e poi sul server Checkmk (ri)classificarli con la regola Logfile patterns. In questo modo puoi risparmiarti la fatica di preparare e distribuire il nuovo agente e, dopo aver personalizzato la regola di cui sopra, dovrai attivare rapidamente le modifiche solo una volta. Puoi scoprire come fare esattamente nel capitolo Riclassificazione con modelli di file di log.

In Checkmk Raw puoi configurare il plug-in dell'agente come al solito tramite un file di testo. Di regola, logwatch cerca un file chiamato logwatch.cfg nelle directory /etc/check_mk (Linux) o c:\ProgramData\checkmk\agent\config\ (Windows). Una configurazione (quasi) minima potrebbe essere la seguente:

Per prima cosa, inserisci sempre un pattern glob, seguito da tutte le opzioni da applicare, seguito - con un rientro di uno spazio - da una lettera che rappresenta lo stato o la funzione desiderata e infine da un'espressione regolare che viene confrontata con ogni riga del file di log. Con la configurazione precedente, tutte le nuove righe aggiunte al file di log /var/log/my.log dall'ultima esecuzione di logwatch verrebbero controllate per i due pattern a critical message e something that should only trigger a warning.

Puoi trovare un esempio di configurazione molto completo applicabile a un utente dell'istanza nel file ~/share/check_mk/agents/cfg_examples/logwatch.cfg.

Poiché tutte le opzioni che si possono specificare in un file di configurazione di questo tipo sono già state spiegate nella sezione Configurazione tramite l'agent bakery, qui di seguito ne seguirà solo un elenco e una breve descrizione. Per una spiegazione dettagliata, fai riferimento alla sezione precedente.