Monitoraggio dei file di log

Il pacchetto di installazione per l’agente Windows della Comunità Checkmk non contiene un ambiente Python. Tuttavia, un file cabinet 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 sul 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 proveniente dal server Checkmk. Quindi riavvia il servizio agente Checkmk. In Windows PowerShell con diritti di amministratore, puoi farlo con il seguente comando:

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

In alternativa, puoi anche effettuare lo scaricamento e l'installazione di un pacchetto Python aggiornato da python.org. Assicurati di attivare le seguenti opzioni durante l'installazione:

Se vuoi iniziare a testare subito dopo aver installato Python, è fondamentale riavviare il servizio checkmkservice tramite il Task Manager di Windows o con i comandi specificati sopra, altrimenti il servizio non riconoscerà le 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 desideri o hai bisogno di trasferire il file di configurazione logwatch.cfg all'host in un modo diverso, l'opzione Deploy the Logwatch plugin without configuration è comunque disponibile qui.

Continua con l'opzione Retention period. L'impostazione predefinita qui è un minuto, che corrisponde anche all'intervallo di controllo predefinito in Checkmk. Questo valore dovrebbe essere sempre almeno uguale all'intervallo di controllo. Questa opzione serve principalmente a garantire che nessun messaggio di log vada perso a causa di un rilevamento del servizio o dell'esecuzione manuale di cmk -d myhost. Ulteriori dettagli si trovano nell'aiuto in linea dell'opzione e nel Werk #14451 con cui questa opzione è stata introdotta.

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

Ad esempio, se inserisci /var/log/my.log qui, logwatch effettuerà il monitoraggio solo di questo singolo file di log. Se invece inserisci /var/log/*log qui, logwatch effettuerà il monitoraggio di tutti i file che terminano con la stringa log e che si trovano direttamente nella directory /var/log. Se vuoi effettuare il monitoraggio dei file di log in tutte le sottodirectory dirette di /var/, puoi farlo con il seguente glob, ad esempio: /var/*/*log. Qui non offriamo esplicitamente il glob ** per la ricerca ricorsiva di una struttura di directory, perché otterremmo troppo rapidamente un elenco di risultati troppo ampio e perderemmo di vista lo scopo effettivo di logwatch.

La tabella seguente fornisce alcuni esempi utili su come utilizzare i glob per effettuare effettivamente il monitoraggio dei file che richiedono monitoraggio senza doverli specificare tutti singolarmente:

Quindi, quando si tratta di quali file corrispondono nel primo passaggio, non usiamo espressioni regolari e questo potrebbe essere sufficiente per raggiungere tutti i file che desideri.

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

Se nel primo passo hai effettuato la raccolta di tutti i file /var/log/ e delle sue sottodirectory dirette con /var/log/ e /var/log/*/*, potresti usare 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" (.) è anche in questo caso un carattere arbitrario. Questo 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 selezionare i file da monitorare, in modo che logwatch possa controllare molto rapidamente anche gli altri parametri e contenuti nel passaggio successivo utilizzando un elenco di file gestibile. Puoi approfondire la tua conoscenza di questi ultimi nell'articolo Espressioni regolari in Checkmk.

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

L'opzione seguente Watch the total size of the log file è utile per riconoscere una rotazione dei log difettosa. Se imposti qui 100 MiB, riceverai un avviso ogni volta che un particolare file di log avrà nuovamente 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 impieghi troppo tempo su un singolo file che potrebbe essere stato inondato da migliaia e migliaia di nuove voci dall'ultimo check.

Se attivi una delle ultime due opzioni, devi anche specificare cosa deve succedere se il limite specificato viene superato. Con la nostra impostazione predefinita, il servizio associato diventa critico e ricevi un messaggio che indica che alcune righe sono state saltate o che il tempo di esecuzione massimo è stato superato.

Handling of context messages È un'opzione con cui il volume dei dati trasferiti può diventare molto grande molto rapidamente. Quindi valuta attentamente se per te è importante solo il messaggio di log che ritieni debba generare un CRIT o un WARN, oppure se tutte le righe aggiunte dall'ultima esecuzione di logwatch debbano essere trasferite al server Checkmk. Per file di log piccoli che crescono solo di poche righe al minuto, l'impostazione Do transfer context è sicuramente senza 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 tal caso, potrebbe essere sufficiente vedere che è stato aggiunto un gran numero di nuovi messaggi dall'ultimo check per avviare un check direttamente sull'host in questione.

Se hai bisogno del contesto, ovvero 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 in generale la dimensione dei dati trasferiti.

Process new logfiles from the beginning È disattivata di default. Questo a volte crea 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 primissima esecuzione, logwatch non fa altro che annotare quante righe sono già contenute nel rispettivo log. Solo durante la seconda esecuzione i file vengono checkati per il loro contenuto, ovvero le righe appena aggiunte.

Logwatch si basa sulla possibilità di leggere effettivamente i file di log. Dietro le quinte, logwatch fa di tutto per riconoscere la codifica di ogni file di log. Tuttavia, codifiche di 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 individuare 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 risparmiare ancora un po' di larghezza 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 nell'output invece di ripetere le righe.

Infine, le righe nei file di log che ti interessano vengono ora descritte utilizzando un'espressione regolare e viene loro assegnato 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 cliccato 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 in linea a questo punto e non vengono duplicate qui.

Una cosa da notare: lo stato "OK" potrebbe sembrare un po' confuso a prima vista. Questo serve per trasferire prima le righe da un file di log al server Checkmk, per poi effettuare la classificazione finale. Questo ci porta a un punto importante che mostra quanto logwatch possa essere flessibile se usato correttamente.

Tutte le opzioni spiegate in questa sezione diventano voci nel file di configurazione già menzionato, che è memorizzato sul rispettivo host. Se ora vuoi apportare modifiche alla classificazione di determinati messaggi, potresti dover prima modificare la regola, poi ricompilare l'agente e installarlo.

In alternativa, puoi prima trasferire tutti i messaggi di interesse al server Checkmk (ad esempio con lo stato "OK"), e poi sul server Checkmk (ri)classificarli con la regola "Logfile patterns". In questo modo ti risparmi la fatica di compilare e distribuire il nuovo agente, e dopo aver personalizzato la regola sopra menzionata di conseguenza, dovrai — una sola volta — attivare rapidamente le modifiche. Puoi scoprire esattamente come farlo più avanti nel capitolo Riclassificazione con modelli di file di log.

Nella comunità Checkmk , configuri il plug-in dell'agente come al solito tramite un file di testo. Di norma, logwatch cerca un file chiamato logwatch.cfg nelle directory /etc/check_mk (Linux) o c:\ProgramData\checkmk\agent\config\ (Windows). Una configurazione (quasi) minimale potrebbe essere simile a questa:

Per prima cosa, inserisci sempre qui un pattern glob, seguito da tutte le opzioni da applicare. A questo segue — con un’indentazione di uno spazio — una lettera che rappresenta lo stato o la funzione desiderata e, infine, un’espressione regolare che viene confrontata con ogni riga del file di log. Con la configurazione sopra riportata, tutte le nuove righe che sono state aggiunte al file /var/log/my.log dall’ultima esecuzione di logwatch verrebbero checkate per i due pattern a critical message e something that should only trigger a warning.

Nel file ~/share/check_mk/agents/cfg_examples/logwatch.cfg puoi trovare un esempio di configurazione molto completo applicabile a un utente dell’istanza.

Poiché tutte le opzioni che puoi specificare in un file di configurazione di questo tipo sono già state spiegate nella sezione Configurazione tramite agent bakery, qui di seguito trovi solo un elenco e una breve descrizione. Fai riferimento alla sezione precedente per una spiegazione dettagliata.