I log dei server ESXi sono una di quelle attività che spesso vengono ignorate o gestite frettolosamente da molti amministratori. Tipicamente ci si preoccupa molto di più delle virtual machine che vengono ospitate, e dato che la stabilità di un server di ultima generazione è alta, così come lo è quella di ESXi, si pensa che non si dovrà mai avere bisogno di accedere ai log.
Questo è a mio avviso un atteggiamento profondamente sbagliato, perchè ci preclude la possibilità in futuro di poter analizzare eventuali eventi o errori che dovessero comparire su un server ESXi. E sono più frequenti di quelli che si è portati a ritenere.
Negli incontri con diversi clienti, ho trovato tipicamente tre atteggiamenti, che si riflettono in tre modalità differenti di gestione dei log di ESXi. Vediamoli insieme.
Mettere la polvere sotto il tappeto
In questo scenario, i log sono solo un ulteriore fastidio da gestire, e quindi prima ci se ne libera meglio è. Su un server ESXi dotato di storage locale, il problema nemmeno si pone dato che per default, ESXi quando trova uno storage locale salva i log in /scratch/log.
Sempre più spesso tuttavia, le installazioni di ESXi vengono effettuare su memorie USB o SD, che non vengono però riconosciute come partizioni valide per il salvataggio dei log. Troviamo infatti tipicamente, appena ultimata l’installazione, un errore simile a questo:
Per risolvere l’errore, il metodo “mettere la polvere sotto il tappeto” prevede la selezione rapida di uno dei datastore condivisi a disposizione, e il suo uso come datastore anche per i log. E’ possibile infatti configurare il parametro avanzato Syslog.global.logDir e impostare il datastore prescelto.
Se si desidera usare lo stesso datastore per tutti i server ESXi, è necessario utilizzare anche il paramentro Syslog.global.logDirUnique, in modo che all’interno della cartella LogDir vengano create differenti sottocartelle per i vari server ESXi.
Questo approccio porta con se due problemi.
Il primo è la scarsa gestibilità di questi log; in caso di necessità di consultazione, è possibile utilizzare dal Web Client il Log Browser e consultare in tempo reale i log dei vari server ESXi:
ma questa attività è decisamente pesante e lenta, dato che ogni volta vCenter provvedere a recuperare tutti i log richiesti direttamente dal server ESXi.
Il secondo problema è evidente: se il server ESXi non è raggiungibile,proprio perchè ha un problema, in che modo posso leggerne i log se questi erano all’interno del server stesso? In questo caso è possibile infatti recuperare unicamente i log salvati nel datastore esterno…
Syslog remoto
Un sistema sicuramente più intelligente e proficuo di gestire i log, è inviarli ad un syslog remoto che provveda al loro salvataggio e sul quale è possibile effettuare delle ricerche. In questo modo, dovessimo avere problemi ad un server ESXi e i suoi log locali non fossero raggiungibili, sarà in ogni caso possibile consultare i log del syslog stesso. Questo è particolarmente vero per i server stateless generati con AutoDeploy.
VMware mette a disposizione un syslog server direttamente nell’installazione di vCenter. E’ sufficiente installarlo (Jason Boche ha scritto un ottimo post a riguardo che vi invito a leggere) e configurare in seguito il parametro avanzato Syslog.global.logHost e impostarci quindi il valore tcp://hostname:514 o udp://hostname:514, in dipendenza del protocollo di comunicazione scelto.
Se possedete numerosi server ESXi, è possibile configurare questo parametro direttamente negli Host Profiles, in modo che ogni nuovo server sia già opportunamente configurato.
Analisi dei dati?
Un semplice syslog server, sia esso quello di VMware o un altro sistema, è sicuramente una buona cosa da utilizzare, per tutti i motivi che ho indicato prima. Ma è sempre sufficiente? Ipotizziamo di avere un problema su un componente software di un server ESXi: forse potrebbe interessarci sapere che avviene in realtà da due mesi, sempre alla stessa ora del giorno? Oppure scoprire che lo stesso allarme è presente su tutti i server ESXi installati sull’hardware X?
Ecco che un sistema di analisi dei dati più avanzato di un syslog server potrebbe fare al caso nostro. Tra i molti software esistenti sul mercato, io uso in particolare Splunk. E’ un potentissimo strumento di raccolta log e dati in generale (diciamo che “ingoia” qualsiasi testo gli inviate, senza problemi di formato, sorgente e dimensioni) ma la sua forza sta soprattutto nel classificare e “taggare” tutti i dati raccolti da ogni log.
E’ possibile quindi effettuare a posteriori ricerche di ogni tipo sui dati raccolti, correlarli tra di loro, e ottenere risultati sia in formato testuale che grafico, con la generazione automatica di grafici.
Se siete interessati a provarlo, sappiate che ne esiste una versione completamente gratuita. Splunk viene licenziato per quantità di log che è in grado di salvare ogni giorno, e la versione gratuita consente un limite giornaliero di 500 Mb. Se vi sembrano tanti, sappiate che mediamente un singolo server ESXi può produrre anche 1 GB di dati, quindi ben oltre il limite della versione gratuita.
Quindi, piuttosto che indicarvi un tutorial per l’installazione di Splunk, che è veramente semplice, vi segnalo per concludere questo thread nei forum di Splunk, in cui un utente spiega come ridurre la quantità di log generati da un server ESXi in modo da farla rientrare nei limiti della versione gratuita.
E voi?
Quale livello di dettaglio utilizzate per i vostri log?