Questa è una domanda canonica sul software di monitoraggio.
Correlati anche: quale strumento usi per monitorare i tuoi server?
Ho bisogno di monitorare i miei server; cosa devo considerare quando devo decidere una soluzione di monitoraggio?
Questa è una domanda canonica sul software di monitoraggio.
Correlati anche: quale strumento usi per monitorare i tuoi server?
Ho bisogno di monitorare i miei server; cosa devo considerare quando devo decidere una soluzione di monitoraggio?
Risposte:
Esistono molte soluzioni di monitoraggio. Ognuno ha le sue preferenze e ogni azienda ha le sue esigenze, quindi non esiste una risposta corretta. Tuttavia, posso aiutarti a capire cosa potresti voler cercare nella scelta di una soluzione di monitoraggio.
In generale, i sistemi di monitoraggio hanno due scopi principali. Il primo è quello di raccogliere e archiviare i dati nel tempo. Ad esempio, potresti voler raccogliere l'utilizzo della CPU e rappresentarlo nel tempo. Il secondo scopo è avvisare quando le cose non rispondono o non rientrano in determinate soglie. Ad esempio, potresti voler ricevere avvisi se un determinato server non può essere raggiunto da ping o se l'utilizzo della CPU supera una determinata percentuale. Esistono anche sistemi di monitoraggio dei log come Splunk, ma li sto trattando come separati per questo.
Questi due ruoli principali a volte ricoprono un singolo prodotto, altre volte e più comune è avere un prodotto dedicato ad ogni scopo.
Poller :
tutti i sistemi di monitoraggio necessitano di una sorta di poller per raccogliere i dati. Non tutti i dati vengono raccolti allo stesso modo. Dovresti guardare il tuo ambiente e decidere quali dati hai bisogno e come potrebbero essere raccolti. Quindi assicurati che il sistema di monitoraggio scelto supporti ciò di cui hai bisogno. Alcuni metodi comuni includono:
Se hai principalmente un SO nel tuo ambiente o un SO primario, alcuni sistemi potrebbero avere più opzioni di altri.
Configurazione :
nei sistemi di monitoraggio si tende a riutilizzare molti oggetti. Ad esempio, si desidera monitorare una determinata applicazione come Apache o IIS su un gruppo di server. Oppure si desidera applicare determinate soglie a gruppi di server. Potresti anche avere determinati gruppi di persone "in chiamata". Pertanto, un buon sistema di template è vitale per un sistema di monitoraggio.
La configurazione viene generalmente eseguita tramite un'interfaccia utente o file di testo. L'opzione dell'interfaccia utente sarà generalmente più semplice, ma i file di testo tendono ad essere migliori per il riutilizzo e le variabili. Quindi, a seconda del personale IT, potresti preferire la semplicità alla potenza.
Interfaccia utente : l' interfaccia
più comune per i sistemi di monitoraggio in questi giorni è un'interfaccia web. Alcune cose da valutare riguardo all'interfaccia web sono:
Motore di
avviso : il motore di avviso deve essere flessibile e affidabile. Esistono molti modi diversi per ricevere le notifiche, tra cui:
Altre caratteristiche da cercare sono:
È importante fidarsi che quando qualcosa va storto riceverai l'avviso. Questo si riduce a due cose:
Archiviazione dati :
se il sistema raccoglie e archivia dati (ovvero sistemi che includono grafici) rispetto a quelli archiviati dal sistema. Un'implementazione molto comune sia per il negozio che per la grafica è RRD per esempio.
Alcune funzionalità da cercare nell'archivio dati sono:
Libreria grafica : i
grafici possono essere utili per identificare rapidamente le tendenze e dare contesto allo stato attuale di qualcosa in base alla sua storia. Alcuni tra cui trend che possono essere utili per prevedere le cose prima che accadano (cioè esaurire lo spazio su disco). Assicurati che i grafici ti forniscano le informazioni di cui pensi di aver bisogno in modo chiaro.
Controlli di accesso :
se hai una grande organizzazione potresti aver bisogno di controlli di accesso perché alcuni amministratori dovrebbero essere in grado di regolare solo determinate cose. Potresti anche volere dashboard rivolti al pubblico. Se questo è importante, è necessario assicurarsi che il sistema di monitoraggio disponga dei controlli necessari.
Rapporti :
un sistema che fornisce buoni rapporti può aiutarti a identificare ciò che deve essere migliorato per lunghi periodi di tempo. Ad esempio, può dare una buona risposta a cose come "quali sistemi vanno di più?". Questo può essere importante quando stai cercando di convincere il management a spendere soldi per certe cose - le imprese sono come prove concrete.
Funzionalità specializzate :
alcuni sistemi di monitoraggio sono mirati a prodotti specifici o hanno un supporto maggiore rispetto ad altri. Ad esempio, se la cosa principale che è necessario monitorare è il server SQL o se si fa un uso intensivo dei prodotti VMWare, è necessario vedere quanto sono supportati.
Modelli di monitoraggio predefiniti :
un sistema dotato di molti modelli predefiniti (o ha una base utenti che ha creato molti modelli) può far risparmiare molto tempo.
Scoperta :
se si dispone di un ambiente ampio o in evoluzione. Alcuni sistemi offrono la possibilità di aggiungere nuovi sistemi tramite un'API o eseguire scansioni per trovare nuovi server o componenti.
Monitoraggio distribuito:
se si hanno più posizioni da monitorare, può essere utile tenere sotto controllo i poller in ciascuna posizione invece che molti sistemi indipendenti effettuano il monitoraggio tramite WAN.
Esistono molti sistemi di monitoraggio. Abbiamo un elenco con un riepilogo su questa vecchia domanda . Per un rapido riferimento, alcuni di cui ho sentito parlare di più sono:
Il motivo per cui non posso dirti cosa usare è perché ogni organizzazione ha le sue esigenze. Se vuoi fare la scelta giusta, dovresti pensare a tutti i componenti sopra e capire quali caratteristiche sono importanti per la tua organizzazione. Quindi trova un sistema o sistemi che affermano di fornire ciò di cui hai bisogno e provali. Alcuni di questi costano un po ', molto o sono gratuiti. Tenendo conto di tutto ciò, puoi fare la tua scelta. Da quello che ho usato sono tutt'altro che perfetti, ma almeno puoi provare a ottenere qualcosa che si adatta.
È utile distinguere tra monitoraggio e allerta. Monitorare significa raccogliere dati e creare grafici. Avvisare significa inviarmi un SMS quando un server si blocca nel cuore della notte.
Nagios è per avvisare. Cactus e Munin sono per il monitoraggio. Altri prodotti combinano le due funzioni. Zenoss e Zabbix sono esempi.
Comincerei rispondendo ad alcune domande:
Devi monitorare server, dispositivi di rete, applicazioni o tutti e tre?
Esistono limitazioni su quali metodi è possibile utilizzare per monitorare? Potete installare client di monitoraggio come NRPE sui server o userete SNMP o forse entrambi?
Chi utilizzerà i grafici e chi utilizzerà gli avvisi? Come vorresti che fosse il risultato finale? È importante l'aspetto dell'interfaccia (gli uomini d'affari lo useranno o solo il personale tecnico?)
Quali sono le tue risorse, sia in termini di tempo, abilità che hardware? Hai almeno una modesta capacità di scripting? Hai bisogno di una soluzione pronta all'uso?
A mio avviso, la prima regola di allerta e monitoraggio dovrebbe essere Keep it Simple! Un'organizzazione può vivere o morire su come avvisa e raccoglie dati, e la maggior parte delle volte si complicherà comunque da sola. Inizia con le basi e costruisci da lì.
Pensa ai servizi forniti dal tuo software , invia avvisi quando questi servizi falliscono o quando aumenta il rischio di un fallimento di questi servizi.
La teoria alla base delle strategie di monitoraggio è quella di collegare il monitoraggio e gli allarmi a una sorta di accordo sul livello di servizio . Dopotutto, vuoi essere avvisato del fatto che stai perdendo soldi, non necessariamente che c'è un picco nel numero di connessioni TCP a nji0019.myserver.com. Esistono vari strumenti che ti daranno tonnellate di avvisi, definiranno dipendenze tra avvisi, ma molti di questi controlli non sono direttamente pertinenti al servizio che fornisci a qualcuno.
Identificare i servizi importanti forniti, come la capacità di servire un sito Web e la possibilità di modificare tale sito Web (ad esempio un CMS di qualche tipo). Questi dovrebbero essere controllati (ad esempio controllando che sia possibile ottenere la pagina Web e che sia possibile). Il fallimento di questi due Servizi (usati qui con la S maiuscola) dovrebbe attivare un avviso per avvisarti.
Se è importante che il sito risponda entro un ragionevole lasso di tempo, anche questo dovrebbe innescare avvisi. Una specie di "violazione dello SLA", se vuoi.
Di solito c'è un rischio intrinseco di guasto di un servizio, e abbastanza spesso tale rischio è mitigato dal fatto che si introduce ridondanza, ad esempio un secondo server, un database slave o schede di rete extra ...
Quando questa ridondanza viene persa, il servizio è ancora corretto, ma il rischio di fallimento del servizio è aumentato.
Questo è il secondo motivo principale per attivare gli avvisi; che la ridondanza è sparita (ad es. che il secondo server è morto) o che esiste un pericolo imminente di aumento del rischio (ad es. sul disco sono rimasti solo 500 Mb o la tendenza del disco indica che il disco si esaurirà in circa 5 ore).
Ma check_mk mi dà 50-60 assegni per host, sono tutti senza valore?
No. Tutto ciò non significa che vuoi abbandonare la pletora di controlli automatici che ottieni, ad esempio check_mk, ma significa che dovresti provare a classificare ciascuno dei controlli in quali servizi potrebbero essere interessati se qualcosa non dovesse funzionare.
Quale servizio verrebbe interessato se la partizione / var / si riempisse? Quale servizio verrebbe interessato se l'interfaccia eth0 non fosse attiva? ... se le connessioni TCP in uscita sono bloccate da alcuni firewall? ... se il numero di thread supera 800? ... se il database non funziona?
Hai 2 server Web e un server di database che serve un sito dietro un servizio di bilanciamento del carico che non possiedi (ad esempio l'ISP). Il servizio fornito è la porta 80 sui due server e hanno enormi cache che possono sopravvivere, ad esempio i tempi di inattività del database (database su un terzo server).
In questo scenario, il completo fallimento di un server Web non comporterebbe l'arresto del sito. Quello che è successo è che la ridondanza è sparita e che il rischio di fallimento è aumentato. Ciò dovrebbe attivare un avviso.
Il completo fallimento del database potrebbe non compromettere la capacità di servire il sito, a causa delle cache ben sintonizzate in atto; Ciò non influisce quindi sul servizio di servizio del sito Web, ma potrebbe influire su un servizio diverso, vale a dire l'aggiornamento del sito Web o l'accettazione di ordini ...
Ogni servizio avrebbe il proprio livello di servizio che indica quanto sia importante ripristinare il servizio o evitare interruzioni
Ogni volta che si riceve un avviso, è necessario effettuare una delle seguenti operazioni: - modificare il sistema da monitorare per risolvere il problema che ha causato l'avviso (ad esempio sostituire l'unità o riconfigurare logrotate o altro) - modificare il sistema di monitoraggio per evitare che l'avviso sia inviato la prossima volta che si presenta la situazione. (ad esempio, modificare i livelli di "disco libero" in modo che il disco possa riempire fino al 90% anziché solo all'80%)
Conosco principalmente Nagios e la sua configurazione dettagliata, e da allora sono stato agganciato sul multisito di Check-mk. Di recente ho imparato che check_mk ha questo concetto di Business Intelligence (dall'1.11) che sembra corrispondere bene a questo modo di pensare. È possibile definire che i controlli nei naghi fanno parte di un servizio più ampio e dispongono di regole che definiscono lo stato del "Servizio" come una funzione dello stato di molti controlli, aggregando allo stato peggiore o migliore .
Uno dei punti più critici che le aziende dimenticano quando scelgono una soluzione di monitoraggio è che non si tratta solo di risolvere problemi operativi immediati, ma di problemi imprevisti di domani! Voglio dire, ovviamente risolvere i problemi immediati è importante, ma credetemi, in molti casi questa strategia miope non garantirà la sopravvivenza di un'azienda.
Ci sono dozzine di grandi soluzioni di monitoraggio sul mercato. La selezione di una piccola serie di soluzioni in grado di soddisfare le vostre esigenze è un compito difficile e lungo, inoltre, trovare una soluzione adatta al vostro budget è ancora più difficile. La parte interessante è trovarne uno in linea con il tuo presente e il tuo futuro . E non esiste un processo di valutazione per rilevarlo, è una questione di esperienza + intuizione + un fattore molto importante: la fiducia , che non è una cosa facile da hackerare .
Come regola generale, cerca e cerca storie di successo della tua serie di soluzioni di monitoraggio selezionate, specialmente se riguarda un'azienda del tuo settore. Chiedi al venditore le loro storie di successo e chiedi anche loro il permesso di parlare con uno dei suoi clienti. Le aziende che non hanno paura di questo spettacolo hanno relazioni reali con i loro clienti e non lo nascondono, e questa è una cosa estremamente rara da trovare al giorno d'oggi.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... hanno tutti i loro alti e bassi, ma il vero problema è trovare quale si adatta meglio al tuo futuro.
Se stai prendendo in considerazione il monitoraggio del sistema remoto, potrebbe essere una buona idea cercare i percorsi effettivi da cui vengono eseguiti i test. I problemi di connettività non appartengono al passato e se il tuo hardware serve un gruppo in una regione specifica, potresti voler assicurarti che le tue risorse siano disponibili in quella particolare posizione.