Sistemi di monitoraggio di applicazioni / host distribuiti geograficamente, tolleranti ai guasti e "intelligenti"


12

Saluti,

Vorrei chiedere l'opinione collettiva e visualizzare sui sistemi di monitoraggio distribuiti, cosa usi e di cosa sei a conoscenza di quali potrebbero spuntare le mie caselle?

I requisiti sono piuttosto complessi;

  • Nessun singolo punto di errore. Veramente. Sono morto sul serio! Deve essere in grado di tollerare guasti a nodo singolo / multiplo, sia "principale" che "lavoratore" e si può presumere che nessuna posizione di monitoraggio ("sito") contenga più nodi o sia sulla stessa rete. Pertanto, questo probabilmente esclude le tradizionali tecniche HA come DRBD o Keepalive.

  • Logica distribuita, vorrei distribuire 5+ nodi su più reti, all'interno di più data center e in più continenti. Voglio la vista "Birds Eye" della mia rete e delle applicazioni dal punto di vista dei miei clienti, punti bonus per la logica di monitoraggio che non si impantanano quando hai più di 50 nodi o anche più di 500 nodi.

  • Deve essere in grado di gestire un numero abbastanza ragionevole di controlli host / di servizio, a la Nagios, perché le cifre del ballpark presuppongono 1500-2500 host e 30 servizi per host. Sarebbe davvero bello se l'aggiunta di più nodi di monitoraggio ti consentisse di ridimensionare in modo relativamente lineare, forse tra 5 anni potrei voler monitorare 5000 host e 40 servizi per host! Aggiungendo dalla mia nota sopra sulla "logica distribuita" sarebbe bello dire:

    • In circostanze normali, questi controlli devono essere eseguiti su $ n o n% di nodi di monitoraggio.
    • Se viene rilevato un errore, eseguire i controlli su un altro $ n o n% di nodi, correlare i risultati e quindi utilizzarli per decidere se sono stati soddisfatti i criteri per emettere un avviso.
  • Grafici e funzionalità di gestione. Dobbiamo tenere traccia dei nostri SLA e sapere se le nostre applicazioni "altamente disponibili" sono attive 24x7 è alquanto utile. Idealmente, la soluzione proposta dovrebbe essere in grado di riportare "out of the box" con un minimo faff.

  • Deve disporre di un solido sistema API o plug-in per lo sviluppo di controlli su misura.

  • Deve essere sensibile agli avvisi. Non voglio necessariamente sapere (via SMS, alle 3 del mattino!) Che un nodo di monitoraggio calcola che il mio router principale non funziona. Io non voglio sapere se una percentuale definita di loro sono d'accordo che qualcosa di strano sta succedendo;) In sostanza cosa sto parlando qui è la logica "quorum", o l'applicazione di sanità mentale di follia distribuito!

Sono disposto a prendere in considerazione opzioni sia commerciali sia open source, anche se preferirei evitare il software che costa milioni di sterline :-) Sono anche disposto ad accettare che potrebbe non esserci nulla là fuori che spunta tutte quelle caselle, ma volevo chiedere al collettivo che.

Quando si pensa al monitoraggio dei nodi e al loro posizionamento, tenere presente che la maggior parte di questi saranno server dedicati su reti di ISP casuali e quindi ampiamente fuori dalla mia sfera di controllo. Le soluzioni che si basano su feed BGP e altri aspetti complessi della rete probabilmente non sono adatte.

Devo anche sottolineare che in passato ho valutato, distribuito o utilizzato / personalizzato pesantemente la maggior parte degli aromi open source, inclusi Nagios, Zabbix e amici - non sono davvero strumenti cattivi, ma si riducono nel complesso " aspetto "distribuito", in particolare per quanto riguarda la logica discussa nella mia domanda e gli avvisi "intelligenti".

Felice di chiarire tutti i punti richiesti. Saluti ragazzi e ragazze :-)


2
È davvero strano, stavo per fare una domanda simile. Questa settimana abbiamo avuto alcuni reclami dei clienti sulle interruzioni del sito, ma solo da determinate località. I nostri sistemi di allarme non hanno rilevato questi problemi. Abbiamo contattato il nostro fornitore e hanno confermato che alcuni avevano alcuni problemi alla spina dorsale. Quindi sono anche interessato a una soluzione. Grazie!
splattne,

E qual è stata la soluzione finale?
ewwhite,

Risposte:


4

non una risposta davvero, ma alcuni suggerimenti:

  • dai uno sguardo definitivo alla presentazione di nagios @ goldman sachs . hanno affrontato i problemi che lei menziona: ridondanza, scalabilità: migliaia di host, anche generazione automatica della configurazione.

  • avevo una configurazione ridondante di nagios ma su scala molto più piccola - 80 server, ~ 1k servizi in totale. un server master dedicato, un server slave che estrae la configurazione dal master a intervalli regolari alcune volte al giorno. entrambi i server coprivano il monitoraggio delle stesse macchine, avevano un controllo incrociato dello stato reciproco. ho usato nagios principalmente come framework per invocare controlli specifici del prodotto personalizzato [gruppo di cron job che eseguono script facendo "controlli di flusso artificiale", risultati registrati su sql, plugin nrpe che verificavano esecuzioni riuscite / fallite di quelle negli ultimi x minuti]. tutto ha funzionato molto bene.

  • la tua logica del quorum suona bene - un po 'simile ai miei "flussi artificiali" - fondamentalmente vai avanti, implementa te stesso; -]. e fai in modo che nrpe controlli una specie di flag [o sql db con stato timestamp] come stanno andando le cose.

  • probabilmente vorrai costruire una gerarchia da ridimensionare: avrai alcuni nodi che raccolgono una panoramica di altri nodi, guarda la presentazione dal primo punto. il fork di nagios predefinito per ogni singolo controllo è eccessivo con un numero maggiore di servizi monitorati.

per rispondere ad alcune domande:

  • nel mio caso l'ambiente monitorato era la tipica configurazione master-slave [sql primario o app server + hot standby], nessun master-master.
  • la mia installazione prevedeva un "fattore di filtro umano" - gruppo risolutore che era un "backup" per la notifica di sms. c'era già un gruppo retribuito di tecnici che per altri motivi aveva turni di 24/5, ottenevano il "controllo della posta di nagios" come compito aggiuntivo che non caricava troppo. e si occupano di assicurarsi che db-admins / it-ops / app-admins ware si alzi effettivamente e risolva i problemi; -]
  • ho sentito molte cose positive su zabbix - per avvisare e tracciare tendenze, ma non l'ho mai usato. per me munin fa il trucco, ho hackerato un semplice plug-in nagios verificando che ci sia un colore "critico" rosso sulla lista dei server di munin - solo un ulteriore controllo. puoi anche leggere i valori da munin rrd-files per ridurre il numero di query che invii alla macchina monitorata.

1
@astinus - bene per avvisi sensibili ho usato uno script di notifica personalizzato. invece di fare affidamento su nagios di notifica via mail / cercapersone ho archiviato il messaggio in fifo que e avevo un consumatore che ha inviato un messaggio basato su una logica personalizzata [basata su un programma di chiamata abbastanza flessibile ecc.], inoltre c'era un limite di messaggi inviati all'ora quindi uno non ottiene 50 colpi in breve tempo. vedo approcci simili su scale più grandi: nagios è solo scheletro e le persone lo scrivono attorno e in realtà usano sempre meno le sue funzionalità.
pQd

1
Per quanto riguarda la gerarchia, quello che ho al momento è una configurazione Nagios interamente "modulare" in cui la directory etc / contiene una configurazione "core" condivisa (e identica) su tutti gli host e quindi etc / modules / $ NAME (es. : Posta, Web, rete, DNS) che è portatile al 100% tra i server. Includi con cfg_dir =) Metti tutti i comandi specifici del modulo, i plugin e tutto in quella directory. Far eseguire> 1 server a questi controlli è abbastanza semplice poiché basta copiare il modulo in tutte le caselle Nagios richieste, tuttavia, ancora una volta, la logica di avviso causa problemi :-)
nixgeek

1
@ Astinus # 2. nel mio caso config replication master-> slave si verifica ogni 6h. se il master muore [interruzione di corrente, ecc.], lo slave avviserà tutti della morte del master [controllo incrociato tra server]. si può immaginare un altro scenario - quando il maestro muore a causa di un'errata configurazione. se ciò accade fino a 5 minuti prima della configurazione della sincronizzazione con lo slave, ci sarà una notifica. se è appena prima della configurazione della sincronizzazione - sfortunatamente finiamo per non avere il sistema di monitoraggio. "chi guarderà il guardiano"? beh forse l'ennesimo nagios molto semplice.
pQd

1
@pQd - interessante, concordo sul fatto che l'implementazione della logica negli script di notifica personalizzati sia probabilmente la strada da percorrere. Tuttavia, diventa piuttosto complicato evitare le notifiche duplicate da 2+ host, quando dici 50 host di monitoraggio, e devo ancora vedere qualcuno (in pubblico) mettere la propria logica condivisa in un sistema di passaggio dei "messaggi" come Rabbit o Amazon SQS.
nixgeek,

1
@ astinus # 3 nel mio caso era la soluzione "Livello 8" [del modello iso osi]: i nagios primari stavano inviando sms "alle persone in chiamata + mail al" gruppo risolutore "24/5, mentre i nagios secondari stavano solo spedendo" gruppo risolutore ". spettava a quel gruppo filtrare i duplicati prima di aumentare;
pQd

1

Quello che stai chiedendo sembra molto simile a quello che Shinken ha fatto per Nagios.

Shinken è una riscrittura di Nagios.

  • Linguaggio moderno (Python)
  • Quadro moderno di programmazione distribuita (Pyro)
  • Realm di monitoraggio (multi-tenancy), HA, ricambi
  • API Livestatus
  • Plugin Nagios compatibile
  • Esecuzione nativa di NRPE
  • Criticità aziendale degli oggetti
  • Le regole aziendali possono essere applicate allo stato degli oggetti (gestione della disponibilità di cluster o pool)
  • La rappresentazione grafica può utilizzare PNag4nagios basati su Graphite o RRDtool
  • Stabile e distribuito in ambienti di grandi dimensioni
  • Le grandi distribuzioni possono prendere in considerazione l'associazione con Splunk per la creazione di report o esaminare la grafite in cui RRDtool non è adatto.

Questo dovrebbe essere uno spunto di riflessione.

Saluti

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.