Cosa sto cercando in una soluzione di monitoraggio?


21

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:


19

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.

A cosa servono i sistemi 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.

Quali sono i componenti e le caratteristiche principali nei sistemi di monitoraggio?

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:

  • SNMP (Simple Network Management Protocol)
  • WMI (Strumentazione gestione Windows)
  • Esecuzione di script (ad esempio, l'esecuzione di uno script sul computer che viene monitorato o l'esecuzione di uno script dalla casella di monitoraggio stessa che utilizza il proprio metodo di polling). Questi possono includere elementi come script Bash, script Perl, eseguibili e script Powershell
  • Monitoraggio basato sull'agente. Con questi un processo viene eseguito su ciascun client e raccoglie tali dati. Questi dati vengono inviati al server di monitoraggio oppure il server di monitoraggio esegue il polling dell'agente. Alcuni amministratori sono d'accordo con gli agenti, ad altri non piacciono perché possono lasciare un'impronta maggiore sul server monitorato.
  • API focalizzate (ad es. API VMWare o possibilità di eseguire query SQL)

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:

  • Buone panoramiche
  • Buone pagine di dettaglio
  • Velocità (quando è necessario trovare informazioni in modalità di crisi, un'interfaccia lenta può essere molto frustrante
  • Sensazione generale. Trascorrerai molto tempo nell'interfaccia, se risulta ingombrante il tuo personale IT si sentirà resistente all'uso
  • Personalizzazione. Ogni organizzazione ha certe cose che sono importanti e altre che non lo sono. È importante essere in grado di personalizzarlo in base alle proprie esigenze

Motore di
avviso : il motore di avviso deve essere flessibile e affidabile. Esistono molti modi diversi per ricevere le notifiche, tra cui:

  • sms
  • E-mail
  • Telefono
  • Altre cose come IM / Jabber

Altre caratteristiche da cercare sono:

  • Escalation (notifica a qualcuno se l'altra persona non ha riconosciuto o corretto l'avviso)
  • Rotazioni e turni
  • Gruppi (alcuni gruppi devono essere informati di determinate cose)

È importante fidarsi che quando qualcosa va storto riceverai l'avviso. Questo si riduce a due cose:

  1. Un sistema affidabile
  2. Una configurazione senza avvertimenti. Nei sistemi di monitoraggio non è raro pensare di dover ricevere un avviso, ma a causa di alcuni dettagli nella configurazione l'avviso non è mai stato attivato.

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:

  • Accesso non elaborato ai dati. Questo può essere utile per sviluppare o creare grafici personalizzati con qualcosa come Excel.
  • Scalabilità. A seconda della quantità di dati che raccogli, questi possono sommarsi rapidamente, se hai intenzione di raccogliere molto, vuoi assicurarti che si ridimensioni.

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.

Altre caratteristiche

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.

Alcuni sistemi di monitoraggio popolari

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:

  • Nagios
  • cactus
  • OpenNMS
  • Venti solari
  • Zabbix
  • Vari sistemi di monitoraggio basati su cloud
  • Microsoft System Center
  • Questo non è ancora popolare, ma Stack Exchange ha aperto il suo sistema di monitoraggio http://bosun.org

Come decidere in base a quanto sopra

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.


2
Sotto "Alerting Engine" hai davvero bisogno di "limitazione della velocità di notifica" come caratteristica. Essere il bersaglio di "tempeste" di notifica di centinaia o migliaia di avvisi a causa di fallimenti a cascata o sbattimenti falliti (è su, è giù, è su, è giù-- oh, ehi, è di nuovo su ...) non è divertente.
Evan Anderson,

8

È 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ì.


4

tl; dr

Pensa ai servizi forniti dal tuo software , invia avvisi quando questi servizi falliscono o quando aumenta il rischio di un fallimento di questi servizi.

Accordi sul livello di servizio

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.

Violazione del servizio

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.

Rischio aumentato

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).

Che dire di tutti quegli indicatori?

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?

Esempio

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

Sii agile

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%)

La mia esperienza

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 .


Caspita, due downvotes e nessun commento. Buona forma.
mogsie,

1
Le persone hanno paura se pensi troppo avanti :)
Florian Heigl,

1

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.


0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.