 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introduzione
Il monitoraggio delle attività elaborate regolarmente o su richiesta, così come dei processi in esecuzione permanente, può essere effettuato, ad esempio, analizzando i file di log o di stato. Tuttavia, questo comporta spesso un lavoro aggiuntivo, poiché spesso è necessario leggere grandi volumi di dati per estrarre poche informazioni.
Per ridurre questo sforzo, Checkmk offre la possibilità di far scrivere l'output di un programma direttamente in un file nel formato dell'agente Checkmk. Messi nella cosiddetta directory spool, l'agente raccoglie tutti questi file e integra il loro contenuto nell'output dell'agente. Il metodo che usa la directory spool è utile, ad esempio, per
l'analisi regolare dei file di log,
monitoraggio dei backup automatici,
la creazione e la verifica delle statistiche di utilizzo da un database,
quando il plug-in "
mk-job" non è sufficiente per il controllo dei cronjob,lo sviluppo di check personalizzati per testare l'output di esempio.
In Checkmk, la directory spool è supportata dagli agenti nei seguenti sistemi operativi: Windows, Linux, AIX, FreeBSD, OpenWrt e Solaris.
Per assicurarti di poter utilizzare questa funzione senza problemi, ci sono alcuni punti da tenere a mente.
2. Percorsi delle directory dei file
Il percorso predefinito della directory di spool è /var/lib/check_mk_agent/spool/ su Linux e altri sistemi Unix, e C:\ProgramData\checkmk\agent\spool\ su Windows.
Per Linux e Unix puoi personalizzare il percorso della directory principale con la regola Agent rules > Installation paths for agent files (Linux, UNIX) e l'opzione Base directory for variable data (caches, state files) disponibile lì.
Se stai lavorando su un host in monitoraggio, puoi filtrare la directory di spool configurata lì dall'output dell'agente:
Checkmk utilizza una singola directory di spool, che per impostazione predefinita è di proprietà di root.
Non sono previste directory multiple con proprietari diversi.
Tuttavia, puoi ovviamente creare file (inizialmente vuoti) nella directory di spool e assegnarne la proprietà a un altro utente, che potrà quindi sovrascrivere il contenuto del proprio file.
|
Tieni presente che l'agente non effettua alcun controllo del contenuto dei file di spool! I file di spool manipolati possono sovrascrivere le sezioni regolari dell'agente e creare così l'illusione di un funzionamento senza problemi. Anche senza intenzioni malevole, esiste il rischio potenziale che un file di spool possa contenere un output dell'agente danneggiato, con il risultato che le parti successive dell'output dell'agente vengano completamente ignorate. |
3. Nomi e contenuti dei file
I file di spool possono contenere output di testo in qualsiasi formato supportato da Checkmk. I file vengono concatenati in ordine di presenza nella directory di spool. L'estensione del file non ha importanza.
Se vuoi usare uno schema numerico per l'ordinamento, anteponi al nome del file un trattino basso (_), poiché i nomi dei file che iniziano con numeri servono per verificare la data di creazione.
I file che iniziano con un punto vengono ignorati.
Per evitare confusione nel contenuto dei file concatenati, ogni file di spool dovrebbe
iniziare con un header di sezione, ovvero una riga racchiusa tra
<<<e>>>— anche se nel file viene utilizzato solo il formato di check locale,terminare con un carattere di nuova riga.
Quindi, un check locale che fornisce un servizio immediatamente potrebbe apparire così:
<<<local>>>
0 "Spool Test Dummy" - This static service is always OKAllo stesso modo, puoi eliminare gli output che richiedono un plug-in di controllo sul lato Checkmk:
<<<waterlevels>>>
rainbarrel 376
pond 15212
pool 1237323.1. Terminazione della sezione piggyback
Se utilizzi sezioni piggyback in un file, termina questo file con la riga <<<<>>>>.
Questo è l'unico modo per garantire che, se l'ordine di lettura cambia, l'output che segue l'output piggyback venga riassegnato all'host stesso.
4. Check dell'età dei file
Se un programma riesce a scrivere correttamente nel proprio file di output, va tutto bene, indipendentemente dal fatto che il processo sia andato a buon fine o meno. Ma cosa succede se un programma si interrompe prima di scrivere su disco, o se un errore del file system impedisce la scrittura di nuovi file?
In questa situazione hai la possibilità di anteporre al nome del file un numero intero, ad esempio 600MyCronjob.
In questo caso il numero verrà interpretato come l'età massima del file in secondi.
Se il file è più vecchio, verrà ignorato dall'agente e il servizio associato in Checkmk passerà allo stato SCONOSCIUTO a causa dell'output mancante.
Nell'esempio di un file chiamato 3900_hourly_cleaner.txt, il numero è quindi scelto in modo appropriato per un cronjob che gira ogni ora, per il quale si prevede un tempo di esecuzione inferiore a cinque minuti.
5. Un esempio pratico
Supponiamo che tu gestisca un servizio in cui gli utenti effettuano l'accesso e l'uscita. Nei file di log del servizio troverai righe dei seguenti tre tipi:
21/Oct/2022:12:42:09 User harrihirsch logged in from 12.34.56.78
21/Oct/2022:12:42:23 User zoezhang logged out after 10 min idle
21/Oct/2022:13:00:00 Current user count: 739Il processo non scrive la riga con Current user count dopo ogni login/uscita, ma a intervalli fissi.
Se il numero di righe nel file di log è abbastanza basso da poter essere letto rapidamente, puoi programmare un check locale.
Questo check legge l'intero file di log riga per riga ogni volta e imposta sempre il conteggio degli utenti sul valore visualizzato quando trova la riga Current user count.
Quando trova le righe logged in e logged out, aumenta o diminuisce il conteggio degli utenti.
Alla fine, il tuo check stampa una riga simile alla seguente:
1 "Frobolator User Count" count=1023 Watch out! Limit nearly used up.Man mano che il tuo servizio diventa più popolare, il check locale viene eseguito per periodi sempre più lunghi, fino a quando, a un certo punto, questa soluzione, e persino l'esecuzione come plug-in dell'agente asincrono, non è più praticabile. È qui che un uso corretto della directory di spool può aumentare notevolmente l'efficienza dell'esecuzione del check. Nei prossimi paragrafi ti mostreremo come modificare il programma che ha fornito il tuo check locale in modo che faccia un uso efficace della directory di spool.
Innanzitutto, il programma non dovrebbe terminarsi quando raggiunge la fine del file, ma scrivere un file di spool che contenga lo stato attualmente determinato del servizio quando il file di log è stato completamente valutato:
<<<local>>>
2 "Frobolator User Count" count=1200 Maximum number of users reached!Quindi fai in modo che il tuo programma attenda per un certo periodo di tempo — che siano pochi secondi o diversi minuti dovrebbe dipendere dalla frequenza delle nuove voci di log aggiunte. Dovrebbe quindi valutare solo le righe appena aggiunte e ricalcolare lo stato. Se i numeri sono cambiati, riscriverà il file di spool.
Programma questa procedura come un ciclo infinito.
Per rilevare un possibile crash di questo programma, dovresti nominare il file di spool di conseguenza, ad esempio 1800_frobolator.txt — se 30 minuti senza aggiornamento del file di spool indicano problemi con il servizio o con il programma di valutazione.
Invece della directory dei plugin dell’agente, avvia ora il programma come daemon utilizzando le opzioni del tuo sistema operativo. Presta attenzione al riavvio automatico, nel caso in cui il programma crashi o venga terminato. Molte applicazioni server offrono anche l’opzione di reindirizzare l’output del log a un altro programma invece di, o in aggiunta alla, scrittura dei normali file di log. Utilizzare questo meccanismo per uno script di valutazione che scrive file di spool è anche una buona idea.
6. Alcuni aspetti da tenere in considerazione
La lettura dei file può presentare altre insidie rispetto al normale avvio dei processi da parte dell'agente. Tieni conto dei seguenti punti per un funzionamento senza intoppi.
6.1. Set di caratteri
Checkmk si aspetta che l'output dell'agente sia codificato esclusivamente in UTF-8 (senza Byte Order Mark / BOM) con un semplice carattere di nuova riga (0x0A o \n) come interruzione di riga.
Eventuali deviazioni possono, nel peggiore dei casi, comportare un output dell'agente che non può essere letto oltre il primo carattere di un file di spool formattato in modo errato.
Nello specifico, questo significa:
Soprattutto sui sistemi Windows e Linux più vecchi, assicurati che i file di spool non siano scritti con la codifica Windows 1250-1258 o ISO 8859. Se questo è inevitabile, assicurati che venga utilizzata solo l'intersezione con UTF-8 — di fatto ASCII a 7 bit.
Soprattutto sui sistemi Windows più recenti, assicurati che i file di spool non siano scritti con la codifica UTF-16 utilizzata come standard in questi sistemi.
Non usare il BOM. In particolare, i linguaggi di scripting su Windows spesso scrivono automaticamente questa sequenza di caratteri, che indica la codifica utilizzata, nei file di output. Nell'output dell'agente, questo impedisce che il carattere di interruzione di riga
<<<appaia all'inizio di una riga.Usa il carattere di interruzione di riga Unix (
0x0Ao\n). Anche in questo caso, Windows usa spesso la stringaCRLF(0x0D 0x0Ao\r\n).
Se un file di spool causa un comportamento indesiderato, esamina le sue prime righe con un editor esadecimale:
0xFF 0xFEindica un file codificato in UTF-16: In questo caso, modifica i tuoi script in modo che l'output sia in UTF-8.0xEF 0xBB 0xBFvisualizza UTF-8 con BOM. In questo caso, di solito è sufficiente scrivere il file senza BOM in futuro.
6.2. Soft link e pipe con nome
In linea di principio, i file nella directory di spool possono essere anche soft links o pipe con nome. Va notato che il controllo dell'età tramite i nomi dei file qui non funziona, perché viene valutata l'età del soft link o della pipe con nome stessa e non l'età dei dati scritti. Per le pipe con nome, devi anche assicurarti che il processo che scrive nella pipe fornisca sempre dati. Se non vengono forniti dati, l'agente Checkmk aspetterà all'infinito e alla fine andrà in timeout.
Se devi consentire a utenti senza privilegi di scrivere nei file di spool, crea dei file vuoti per questi utenti e imposta la proprietà di conseguenza. Questi utenti potranno quindi creare un soft link autonomamente o scrivere direttamente nel file di spool.
6.3. Blocco e bufferizzazione
Quando si scrivono programmi più lunghi che scrivono più righe di stato in un file di spool, si è tentati di aprire il file di output in scrittura all’avvio del programma. Tuttavia, in questo caso il file rimarrà completamente vuoto finché il buffer di scrittura non viene prima svuotato e scritto nella destinazione, e sarà incompleto finché il programma di scrittura non avrà chiuso il file. Lo stesso vale se un file viene bloccato in modo esclusivo per tutta la durata di una lunga operazione di scrittura.
Per questo motivo, dovresti scrivere nel file di output solo quando l'intero contenuto da scrivere è disponibile, oppure scrivere in un file temporaneo che poi copierai nella directory di spool — oppure, rispettivamente, utilizzare cat per trasferire il contenuto di un file temporaneo in uno esistente nella directory di spool.
6.4. Mantenere una visione panoramica
Un altro problema può verificarsi quando diversi programmi cercano di scrivere su file con lo stesso nome. Con molti file di spool, è facile perdere di vista quale programma scriva effettivamente su quale file di spool. In particolare, se un file di spool formattato in modo errato rende inutilizzabile parte dell'output dell'agente, ciò è molto fastidioso e può comportare una ricerca che richiede molto tempo.
Puoi mantenere l'ordine creando un file con lo stesso nome — preceduto da un punto — per ogni file di spool, che contenga informazioni sul lavoro e, se del caso, su una persona di contatto. Il contenuto di questo file nascosto non viene trasferito insieme ad esso.