Scopri ed elimina eventuali "colli di bottiglia" che rallentano il tuo computer monito-rande costantemente il carico di lavoro a cui sono sottoposti CPU, RAM e Hard Disk
Tutti siamo a conoscenza del fatto che il sistema operativo sfrutta le risorse hardware in suo possesso per eseguire se stesso e i programmi installati con l'obiettivo di soddisfare nel migliore dei modi le richieste di chi lo utilizza. È altrettanto chiaro, però, che le "fonti" dalle quali può attingere l'"energia" necessaria non sono infinite per cui, carichi di lavoro eccessivamente elevati possono provocare problemi di funzionamento: un computer sotto stress (server o workstation che sia) manifesta sempre una drastica riduzione delle performance ed è più esposto ad anomalie e guasti.
Le soluzioni possono essere diverse: potenziare l'hardware (non sempre è possibile, soprattutto per motivi economici), ignorare i problemi di carico elevato (controproducente e pericoloso), oppure, monitorarne le prestazioni in modo costante e cercare di mantenere lo sfruttamento delle risorse su livelli ottimali e proporzionati all'hardware in uso. In quest'ultimo caso, è bene munirsi di un buon sistema di monitoraggio che riesca a tenere sotto controllo efficacemente i componenti vitali del PC e quelli più sfruttati. Proprio quello che faremo noi grazie ad un tool di monitoraggio molto particolare noto con il nome Monitotix. Ma prima di scoprire come funziona e come si usa, cerchiamo di capire quali sono le parti del sistema maggiormente stressate e quali è importante tenere d'occhio più delle altre.
LE RISORSE "VITALI" DEL PC
Le componenti cruciali per il buon funzionamento del computer possono essere legate unicamente all'hardware o dipendere da altri fattori come il consumo e il costo. Generalmente, quelle da monitorare con maggiore impegno possono essere così riassunte:
«CPU: controllare l'uso del o dei processori permette di individuare se la potenza di calcolo è un collo di bottiglia per il sistema. Se l'utilizzo di questa risorsa è sempre al massimo, è utile passare a qualcosa di più potente o alleggerire il carico di lavoro sulla macchina.
Memoria RAM: insieme alla CPU, la memoria è un altro collo di bottiglia critico per l'utilizzo intensivo di diverse applicazioni. Superata l'occupazione della memoria fisica (in pratica la RAM), il sistema tende a usare lo spazio swap, fatto che riduce drasticamente le prestazioni. Nei casi più gravi il sistema va in trashing fino alla chiusura delle applicazioni per mancanza di memoria; Hard Disk: le applicazioni non vivono di sola memoria e potenza di calcolo. Esse devono costantemente scrivere e leggere dati su disco. Purtroppo, la velocità di accesso a questo componente è molto più lenta di quella della memoria, quindi, è fondamentale monitorare sia lo spazio libero che la frequenza di attività e i tempi di accesso. Per migliorare questi valori si può utilizzare hardware più evoluto e potente, oppure ottimizzare le applicazioni utilizzate (quando possibile).
Rete: monitorare il traffico di rete è indispensabile, in particolare su macchine server, per verificare l'utilizzo dei vari servizi e determinare colli di bottiglia che possono causare lentezza. Oltre alle considerazioni tecniche, monitorare la rete assume un aspetto economico quando la banda consumata viene pagata profumatamente.
SISTEMI DI MONITORAGGIO
Un sistema di monitoraggio è un'applicazione o un gruppo di queste il cui scopo è raccogliere e archiviare periodicamente informazioni sul funzionamento del sistema e memorizzarle in una struttura di dati che possono essere successivamente elaborati e visualizzati. Non esiste un metodo unico per la raccolta dei dati, in quanto per ottenere le informazioni sulla risorsa che si sta mo-nitorando è necessario utilizzare programmi specifici o richieste mirate al sistema operativo. Per quanto riguarda GNU/Linux, il sistema per effettuare i rilevamenti dipende fortemente dalla versione del kernel in uso, dal tipo di distribuzione e da eventuali differenze di organizzazione delle risorse. I sistemi più avanzati risolvono questo problema grazie agli "agent", applicazioni in grado di svolgere la rilevazione nella particolare configurazione di sistema in uso.
Per quanto concerne le strutture nelle quali inserire i dati ottenuti dai rilevamenti, spesso si fa uso di sistemi meno complicati del classico database MySQL o simile. La ragione è che i dati statistici raccolti hanno una validità temporale limitata. Ad esempio, è raro che i livelli medi di impegno della CPU vecchi di sei mesi siano di qualche interesse. La visualizzazione delle statistiche in questi sistemi è solitamente possibile attraverso l'uso di applicazioni web piuttosto che con strumenti dedicati, ponendo come requisito obbligatorio la presenza di Apache o di un server \veb equivalente sul sistema. Tuttavia, questo requisito può essere inopportuno per macchine desktop. In questo articolo, come anticipato, illustreremo l'uso e il funzionamento del sistema di monitoraggio per singolo computer (host) chiamato Monito-rix cercando di mostrare i suoi punti di forza e i difetti.
GLI STRUMENTI NECESSARI
Prima di procedere con l'installazione di Monitorix è indispensabile installare il necessario per la raccolta dei dati e la loro visualizzazione. Come anticipato, uno dei requisiti fondamentali è che il server web Apache sia installato sul sistema, operazione relativamente semplice, in quanto esso è contenuto come pacchetto predefinito praticamente su ogni distribuzione. Per il corretto monitoraggio di alcune risorse e per le notifiche via e-mail sono
necessari anche i seguenti programmi:
• lm_sensors (www.lm-sensors.org): permette di interrogare le sonde di temperatura, velocità delle ventole e voltaggio presenti sulle schede madri e su altri tipi di dispositivi;
• hddtemp (www.guzu.net/linux/hddtemp.php). come gli lm_sensors, questo pacchetto permette il controllo della temperatura dei dischi rigidi;
• metamail: questo componente è necessario se si desidera ricevere le e-mail con un sommario delle statistiche. Nelle release future di Monitorix questo programma potrebbe non essere più necessario.
Tutti i software qui descritti sono disponibili nel CD/DVD allegato. Tuttavia, questo non è tutto, manca ancora un componente fondamentale, quello necessario per memorizzare i dati raccolti. Vediamo di cosa si tratta.
RRDTOOL: INDISPENSABILI PER ORGANIZZARE I DATI
Dopo lo stesso Monitorix, il requisito più importante è la presenza degli RRDtool (http://oss.oetiker.ch/rrdtool) sul sistema, necessari per creare la struttura dati per la memorizzazione dei rilevamenti. Il termine RRD è l'acronimo di "Round Robin Database", ovvero una struttura di memorizzazione che segue un flusso di dati temporale basato sull'algoritmo Round Robin (http://it.wikipedia.org/wiki/Round-robin). Le informazioni vengono memorizzate in base all'istante temporale, il cui intervallo è specificato durante la creazione della struttura dati. In questo modo è possibile avere un file a dimensione costante, nella quale i nuovi dati sostituiscono ciclicamente quelli vecchi.
Le strutture dati create con RRDtool vengono usate dalla maggior parte dei software di monitoraggio (professionali e non). Ciò non è un caso, in quanto questo software è stato sviluppato appositamente per questo scopo dal suo autore, il quale aveva già inglobato queste funzionalità nel software MRTG (Multi Router Traffic Gra-pher - http://oss.oetiker.ch/mrtg), da cui derivano gli RRDtools. Da esso infatti sono state ereditate tutte le funzioni per la creazione di diagrammi e grafici statistici pronti per essere visualizzati su una pagina web. Basta unire la facilità di memorizzare dati alla possibilità di creare facilmente i diagrammi per capire il perché della proliferazione di applicazioni di monitoraggio che fanno uso di questo strumento. Data la delicatezza di questo componente, consigliamo l'installazione dai pacchetti precompilati forniti per la propria distribuzione: in particolare è necessario installare "RRDtool" e la sua interfaccia di programmazione per il linguaggio Perl, "rrdtool-perl".
Prima di mostrare come si usa praticamente questa applicazione, affronteremo la sua installazione. Anche se si tratta di un software sviluppato da più di due anni (la prima release risale al 2005), non è pacchettizzato per diverse distribuzioni. Fortunatamente, l'autore fornisce sul sito web il pacchetto RPM per RedHat, Fedo-ra e CentOS e uno generico per tutte le altre (almeno in teoria). Se siete tra i fortunati utilizzatori di una di queste distribuzioni, per installare Monitorix, è sufficiente scaricare il pacchetto monito-rix-l.l.l-l.noarch.rpm ed eseguire il comando seguente:
rpm -ihv monitorix-l.l.l.noarch.rpm
Terminata l'installazione il software è subito pronto per essere configurato. I "guai" arrivano nel momento in cui si sceglie di utilizzare l'archivio di installazione generico. Dopo aver decompresso il file "monitorix-l.l.l.tar.gz'"(tar -xzf monitorix-l.l.l.tar.gz) in una directory temporanea, possiamo eseguire lo script di installazione:
ed monitorix-l.l.l ./instali.sh
Per prima cosa ci verrà chiesto di indicare la distribuzione in uso scegliendola tra quelle disponibili. Al momento il sistema è compatibile con Debian GNU/Linux. Slackware, Gentoo e un enigmatico "Generic". Nel secondo passo, invece, è necessario confermare i percorsi di installazione dei vari componenti di Monitorix, assicurandoci che siano quelli corretti prima di andare a scrivere le modifiche su disco. È anche possibile effettuare un'installazione totalmente manuale, nel caso in cui qualcosa non dovesse funzionare. Tuttavia, la documentazione non indica adeguatamente le operazioni da svolgere. Purtroppo, nei test da noi effettuati lo script di installazione ha fallito il proprio compito sia su Debian GNU/Linux sia su Slackware, ma l'errore è imputabile in parte alla maggiore cura del progetto per le distro basate su Red Hat.
DIAGRAMMI E RISORSE DA MONITORARE
Prima di occuparci delle personalizzazioni avanzate dei diagrammi e delle risorse da monitorare, modifichiamo le poche voci che ci permettono di avere da subito un sistema di monitoraggio funzionante. Apriamo il file "/etc/monitorix.conf" e assicuriamoci di impostare correttamente le seguenti voci:
our $TITLE="Linuxmagazine, II";
our $HOSTNAME="testmachine.edmaster.it";
our $OSTYPE="Linux-RHFC";
our $IDATE="01 Jan 2008";
our $EMAIL="admin\@kbytesys.bogus";
Le prime due righe permettono di impostare un titolo e l'ho-stname della macchina che stiamo monitorando. La terza riga specifica il tipo di sistema operativo (distribuzione) ed è possibile scegliere una tra le seguenti opzioni:
• Linux-RHFC per distribuzioni basate su RedHat, tra cui CentOS e Federa:
• Linux-Debian per le distribuzioni Debian based;
• Linux-Gentoo per Gentoo;
• Linux-Slack per Slackware;
• Linux-Generic per le altre distribuzioni, anche se non si garantiscono i risultati voluti.
Prima di modificare questo campo assicuriamoci di scrivere correttamente la voce scelta, altrimenti il programma non funzionerà come dovrebbe e, soprattutto, lo farà senza avvertirci dell'errore di configurazione. Le ultime due righe del blocco di configurazione mostrato in precedenza fanno riferimento rispettivamente alla data relativa all'inizio della raccolta dati e all'indirizzo e-mail a cui inviare i rapporti. A questo punto, salvato il file, è sufficiente riavviare Monitorix utilizzando il comando /etc/init.d/monito-rix restart. Infine, per visualizzare le statistiche di monitoraggio è necessario collegarci con il browser (ad esempio Konqueror o Firefox) alla pagina "http://ipmacchina/monitorlxf.
LA CONFIGURAZIONE DI SELINUX CON MONITORIX
Nelle ultime release di RedHat, CentOS e Federa la configurazione di default fa uso della piattaforma SELinux per aumentare la sicurezza del sistema. Purtroppo, le operazioni effettuate dal monitoraggio rientrano tra quelle bloccate dalle politiche di default di questo componente. A questo punto, molti suggeriscono la disattivazione di SELinux. ma in realtà esistono diverse soluzioni per risolvere il problema creando un modulo di policy di sicurezza ad-hoc per Monitorix.
C'È ANCHE STRESSLINUX
Una distro per mettere sotto stress il PC
All'indirizzo www.stresslinux.org è disponibile una vera e propria distribuzione GNU/Linux, chiamata appunto Stres-slinux, awiabile direttamente da CD che permette di eseguire una serie di test atti a verificare le performance del sistema e il carico di lavoro che è in grado di sopportare. La distribuzione offre come predefiniti strumenti di analisi e monitoraggio come stress, cpuburn, hddtemp, lm_sen-sors e moltissimi altri.
Una soluzione semplice può essere quella seguente: fermiamo tutti i servizi non essenziali, in modo da non generare violazioni catturate da SELinux non dovute a Monitorix e svuotiamo il file "/var/log/audit/audit.log". Avviarne Monitorix ed apriamo la pagina del browser con le statistiche. Se tutti i grafici si vedono correttamente, non abbiamo bisogno di effettuare ulteriori modifiche, altrimenti passiamo al punto successivo. Eseguiamo il seguente comando in una direc-tory temporanea:
audit2allow -i /var/log/audit/audit.log -M 1
MonitorixPolicies
Grazie al comando precedente abbiamo generato una policy con le regole per accettare quello che era stato precedentemente negato. Infine, carichiamo la policy in SELinux utilizzando il comando seguente:
semodule -i MonitorixPolicies.pp
Fatto ciò, torniamo nuovamente al secondo passo per essere sicuri di avere catturato tutte le funzioni in precedenza negate dal sistema di sicurezza. Ovviamente, questa guida è utile anche qualora usassimo una distribuzione diversa, ma sempre con il sistema SELinux attivo.
GUARDIAMO DENTRO MONITORIX. ECCO COME E FATTO
Per capire meglio i punti di forza e le debolezze di questo software è necessario spiegare come esso è strutturato. Monitorix è composto da due script Perl più una serie di file di configurazione preparati per le diverse distribuzioni. Tutto il sistema di monitoraggio può essere così riassunto:
* monitorix.pl - svolge tutte le funzioni di raccolta dati. Invoca to dallo script situato nella directory "/etc/init.d" provvede a creare i file rrd, la directory e il file HTML di presentazione nella Document Root di Apache. Inoltre, sempre lo stesso script Perl, configura il crontab dell'utente amministratore per essere seguito periodicamente in automatico. Infatti, nel momento in cui viene eseguito da cron, il programma effettua la raccolta dei dati;
* monitorix.cgi: lo script COI invocato da Apache si occupa di recuperare i dati archiviati, generare le immagini attraverso le funzioni di RRDtool e mostrarli all'utente.
I due script così organizzati dovrebbero portare ad una capacità di adattamento maggiore. In pratica, lo script principale di Monitorix ha il difetto di inglobare l'invocazione dei controlli unicamente in base alla voce relativa alla distribuzione nella configurazione. Questo approccio ha notevoli difetti, il più importante dei quali è la difficoltà di aggiungere il supporto ad una nuova distribuzione o mantenere aggiornati i controlli quando una distribuzione precedentemente supportata cambia qualcosa di rilevante per Monitorix. Inoltre, lo script non dispone di una gestione di agenti remoti, per cui è possibile monitorare unicamente la macchina corrente, mentre sistemi di monitoraggio concorrenti permettono di centralizzare i controlli di una intera LAN. Tuttavia, Monitorix è consigliato per monitoraggi semplici che non richiedono particolari esigenze.
CONFIGURAZIONE AVANZATA
Gli aspetti finora analizzati riguardano il funzionamento di base del sistema di monitoraggio, ma c'è molto di più. Intervenendo sulle impostazioni avanzate di Monitorix, oltre che personalizzare esteticamente i grafici, la parte più importante riguarda l'opportunità di stabilire quali risorse monitora-re.
Applicare semplici modifiche non è complicato, ma fare aggiunte non è una pratica alla portata di tutti. In sostanza, anche se è vero che non bisogna essere veri esperti, è comunque necessario conoscere in modo abbastanza approfondito il linguaggio di programmazione Perl, la cui sintassi deve essere rispettata anche nel file di configurazione di Monitorix. Se, ad esempio, volessimo monitorare il traffico gestito dal servizio "OpenVPN" (in pratica quello relativo alle reti private virtuali), potremmo "sacrificare", nel senso di modificare, il grafico di un servizio non di nostro interesse e adattarlo al monitoraggio di quello nuovo. Ad esempio, per quanto riguarda OpenVPN, basterebbe applicare le seguenti modifiche:
our $PORT09="4559"; -> our $PORT09="1194"; our $PORT09_NAME="FAX"; -> our $PORT09_ J
NAME="Openvpn";
In effetti, è evidente che la personalizzazione di un grafico o la creazione di una direttiva a partire da una già esistente sono abbastanza semplici e alla portata di tutti, anche di chi
è a digiuno di programmazione Perl. Al contrario, l'aggiunta di una nuova direttiva ex novo, implica la creazione di due nuove voci per la porta e l'impostazione dei limiti posti nelle direttive stesse:
our $PORT13_RIGID="2"; our $PORT13_LIMIT="1000";
Per la posizione del grafico sulla griglia e il limite superiore, infine, è necessario aggiungere quanto segue:
our %GRAPHS =("CPU load" => "_cpul", [Omissis]
"Port 13 traffic" => "_port!3", [Omissis]
Purtroppo fare aggiunte è molto complesso in quanto Monitorix è stato sviluppato senza tenere conto della possibilità di espansione che un sistema maggiormente modulare avrebbe potuto offrire. Questo aspetto comunque, non intacca la validità generale del software, che resta utilissimo per il monitoraggio dei singoli sistemi, sopratutto all'interno di una rete, in particolare se di grandi dimensioni, dove l'opportunità di poter tenere sotto controllo decine di computer attraverso una comune connessione di rete e un semplice browser web è importante per qualsiasi amministratore. Tutto questo al prezzo di una procedura di installazione tutto sommato semplice, almeno su alcune disribuzio-ni in particolare e con pochi strumenti di cui ogni sistema GNU/Linux, anche quelli desktop oriented, dispone.
Aggiornamenti:
Ultima versione stabile rilasciata: 1.5.1 (23/06/2010)
Changelog:
- Changed the default $ENABLE_MAIL option to 'N'.
- Added a second decimal in the Mail statistics graph in order to have more
accurated values.
- Added a missing "--lower-limit=0" to all graphs (except MTA stats).
- Changed the default value of rigid (RIGID = 2) to 0 in all network port graphs.
- Included a number of necessary adjustments in the install.sh script to adapt
it better to the FreeBSD installation process.
(thanks to Michael Brune, admin AT mjbrune.org)
- Added the description of the @NET_RIGID and @NET_LIMIT arrays in the man page
monitorix.conf(5).
- Fixed some bugs and a bad code design in the Interrupts graph that prevented
showing correctly the graph on systems with some interrupts numbers greater
than 256.
(thanks to Dimitri Yioulos, dyioulos AT firstbhph.com)
- Fixed the Memory graph to display correctly the value in MB. This bug affected
only the FreeBSD systems.
- Fixed to be able to enable only the LAN devices monitoring without having to have
enabled the network ports monitoring.
(thanks to Niklas Janzon, niklas.janzon AT gmail.com)
- Fixed the iptables rules section in order to avoid its execution on FreeBSD
systems.
- Fixed a bug in the init script that prevented executing it during the system
shutdown on RedHat/Fedora/CentOS systems. The path of the lock file has
changed from /var/lock/ to /var/lock/subsys.
Nessun commento:
Posta un commento
Non inserire link cliccabili altrimenti il commento verrà eliminato. Metti la spunta a Inviami notifiche per essere avvertito via email di nuovi commenti.