Sisthemes di monitoraggio applicativi / host geograficamente distribuiti, fault tolerant e "intelligenti"

Saluti,

Vorrei chiedere all'opinione collettiva e alla visualizzazione dei sisthemes di monitoraggio distribuiti, che cosa utilizzi e quali sono i sensi di cui possono indicare le mie scatole?

  • HP DL380 G6: Dove è il sensore di temperatura 30 (zona di scheda di I / O)?
  • Come automatizzare gli scenari web zabbix per vhosts?
  • Errore intermittente munin-cron "Non c'è nulla da fare, in quanto non esistono nodes con nessun plugin"
  • Il command Nagios non trasmette tutti gli argomenti
  • Come posso get un avviso di posta elettronica quando l'arrays RAID è degradato? VMware ESXi 5.0, MegaRAID SAS 9260-4i
  • monit: controllo process senza pidfile
  • I requisiti sono abbastanza complessi;

    • Nessun singolo punto di fallimento. Veramente. Sono morto seriamente! Ha bisogno di essere in grado di tollerare un errore singolo o multiplo di nodes, sia "master" che "worker" e si può supporre che nessuna posizione di monitoraggio ("sito") abbia nodes multipli in esso o siano sulla stessa networking. Pertanto questo probabilmente esclude le tecniche tradizionali HA come DRBD o Keepalive.

    • Logica distribuita, vorrei distribuire 5+ nodes in più reti, in più datacentre e su più continenti. Voglio vedere la vista "Occhio degli uccelli" della mia networking e delle applicazioni dalla prospettiva dei miei clienti, punti bonus per la logica di monitoraggio che non si blocca quando hai 50+ nodes o anche 500+ nodes.

    • Ha bisogno di essere in grado di gestire un numero abbastanza ragionevole di controlli host / service, a la Nagios, per le figure di ballpark assumere 1500-2500 host e 30 servizi per host. Sarebbe bello se l'aggiunta di altri nodes di monitoraggio ti permettesse di scalare in modo relativamente lineare, forse in 5 anni potrei cercare di monitorare 5000 host e 40 servizi per host! Aggiungendo dalla mia nota sopra di "logica distribuita" sarebbe bello dire:

      • In circostanze normali, questi controlli devono essere eseguiti su $ n o n% dei nodes di monitoraggio.
      • Se viene rilevato un errore, eseguire controlli su un altro $ n o n% di nodes, correlare i risultati e quindi utilizzare per determinare se i criteri sono stati soddisfatti per emettere un avviso.
    • Grafici e funzionalità amichevoli di gestione. Dobbiamo seguire i nostri SLA e sapere se le nostre applicazioni "altamente disponibili" sono aumentate di 24×7 è un po 'utile. Idealmente la soluzione proposta dovrebbe fare la segnalazione "fuori dalla scatola" con il minimo faff.

    • Deve avere un solido API o un sistema plugin per lo sviluppo di controlli su misura.

    • Ha bisogno di essere sensibili sugli avvisi. Non voglio sapere necessariamente (via SMS, alle 3 del mattino!) Che un nodo di monitoraggio calcola che il mio router principale è in discesa. Voglio sapere se una percentuale definita di essi concorda sul fatto che qualcosa di funky sta succedendo;) Essenzialmente quello che sto parlando qui è la logica "quorum", o l'applicazione della sanità alla follia distribuita!

    Sono disposto a prendere in considerazione sia le opzioni commerciali che quelle open source, anche se preferisco evitare il software che costa milioni di sterline 🙂 Sono anche disposto ad accettare che non ci sia niente che squilla tutte quelle caselle, ma voleva chiedere al collettivo che.

    Quando si pensa al monitoraggio dei nodes e al loro posizionamento, tenere a mente la maggior parte di questi saranno server dedicati su reti ISPs casuali e quindi largamente fuori dalla mia sfera di controllo. Soluzioni che si basano sui feed di BGP e su altre anticaglie di networking complesse probabilmente non soddisfano.

    Devo anche sottolineare che ho valutato, distribuito o utilizzato in gran parte la maggior parte dei sapori open source in passato, inclusi Nagios, Zabbix e amici – non sono davvero strumenti cattivi ma sono piuttosto piatti nel complesso " distribuito ", in particolare per quanto riguarda la logica discussa nella mia domanda e gli avvisi" intelligenti ".

    Felice di chiarire i punti richiesti. Ciao ragazzi e ragazze 🙂

  • Aggiornare i pacchetti di Red Hat Enterprise Linux solo a rilascio specifico
  • È ansible impostare l'affinità CPU per un particolare utente?
  • Come posso eseguire la riparazione di avvio in un server Windows Server virtualizzato KVM?
  • Active Directory: Server 2008 e RHEL 5.10
  • Utilizzo di systemd per le variables di ambiente Apache o SetEnv?
  • Quali sono le differenze "effettive" tra CentOS, RHEL e OEL?
  • 2 Solutions collect form web for “Sisthemes di monitoraggio applicativi / host geograficamente distribuiti, fault tolerant e "intelligenti"”

    non una risposta veramente, ma alcuni indicatori:

    • definitivamente dare un'occhiata alla presentazione su nagios @ goldman sachs . si sono affrontati problemi che si menziona – ridondanza, scalabilità: migliaia di host, anche generazione di configuration automatizzata.

    • ho avuto un setup ridondante di nagios ma su scala molto più piccola – 80 server, ~ 1k servizi in totale. un server master dedicato, un server slave che tira configuration dal master a intervalli regolari poche volte al giorno. entrambi i server hanno coperto il monitoraggio delle stesse macchine, avevano un controllo incrociato tra loro. ho usato nagios principalmente come quadro per ricall controlli specifici del prodotto [un gruppo di lavori cron che eseguono script eseguendo 'controlli artificiali di stream', risultati ware registrati in sql, plugin plugin nrpe per verificare le esecuzioni di successo negli ultimi x minuti]. tutti funzionavano molto bene.

    • la tua logica del quorum suona bene – un po 'simile ai miei' flussi artificiali '- fondamentalmente continui, ipmplement your self; -]. e avere nrpe basta controllare qualche tipo di flag [o sql db con timestamp-status] come stanno facendo le cose.

    • probabilmente vuoi build una certa gerarchia per scalare – avrai alcuni nodes che raccolgono una panoramica di altri nodes, guarda la presentazione dal primo punto. il predefinito nagios forking per each singolo controllo è overkill al maggior numero di servizi monitorati.

    per rispondere a alcune domande:

    • nel mio caso l'ambiente monitorato era tipico setup master-slave [sql primario o app server + hot standby], nessun master-master.
    • la mia installazione ha coinvolto il fattore di filtraggio umano – gruppo resolver che era un 'backup' per la notifica di sms. c'era già un gruppo di tecnici pagati che per altri motivi avevano 24/5 turni, avevano "controllato le mail nagios" come task aggiuntivo non mettendo troppa carico su di essi. e si occupano di fare in modo che gli amministratori db-admins / it-ops / app-admins effettivamente si alzino e risolvano i problemi; -]
    • Ho sentito tante cose buone su zabbix – per avvisare e tracciare le tendenze, ma non l'ho mai usata. per me munin fa il trucco, ho hackato un semplice plugin nagios che controlla se c'è un 'colore rosso' [critico] nell'elenco dei server di munin – solo un controllo aggiuntivo. puoi anche leggere i valori da munin rrd-files per diminuire il numero di query inviate alla macchina monitorata.

    Quello che chiedete suona molto come quello che Shinken ha fatto per Nagios.

    Shinken è una riscrittura di Nagios.

    • Lingua moderna (Python)
    • Quadro moderno di programmazione distribuito (Pyro)
    • Monitoraggio Realms (multi-tenancy), HA, ricambi
    • Livestatus API
    • Nagios plugin compatibile
    • Esecuzione NRPE nativa
    • Critica aziendale degli oggetti
    • Le regole aziendali possono essere applicate allo stato degli oggetti (gestione cluster o disponibilità pool)
    • Il grafico può utilizzare PNP4nagios basato su Graphite o RRDtool
    • Stabile e schierato in grandi ambienti
    • Le grandi implementazioni possono considerare l'accoppiamento con Splunk per segnalare o guardare in Graphite where RRDtool non è una buona misura.

    Questo dovrebbe essere cibo per il pensiero.

    Saluti

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.