Geografisch verteilte, fehlertolerante und „intelligente“ Anwendungs- / Hostüberwachungssysteme


12

Schöne Grüße,

Ich möchte die kollektiven Meinungen und Ansichten zu verteilten Überwachungssystemen einholen, was verwenden Sie und worauf sind Sie sich bewusst, welche davon möglicherweise zutreffend sind?

Die Anforderungen sind recht komplex;

  • Kein einziger Punkt des Versagens. Ja wirklich. Ich mein es todernst! Muss in der Lage sein, einen Ausfall von einem oder mehreren Knoten zu tolerieren, sowohl "Master" als auch "Worker", und Sie können davon ausgehen, dass kein Überwachungsstandort ("Standort") mehrere Knoten enthält oder sich im selben Netzwerk befindet. Daher werden traditionelle HA-Techniken wie DRBD oder Keepalive wahrscheinlich ausgeschlossen.

  • Verteilte Logik, ich möchte mehr als 5 Knoten in mehreren Netzwerken, in mehreren Rechenzentren und auf mehreren Kontinenten bereitstellen. Ich möchte die "Birds Eye" -Ansicht meines Netzwerks und meiner Anwendungen aus der Sicht meiner Kunden, Bonuspunkte für die Überwachungslogik, die bei mehr als 50 Knoten oder sogar mehr als 500 Knoten nicht blockieren.

  • Es muss in der Lage sein, eine angemessene Anzahl von Host- / Serviceprüfungen nach dem Vorbild von Nagios abzuwickeln, da die Zahlen für das Baseballstadion 1500 bis 2500 Hosts und 30 Services pro Host voraussetzen. Es wäre wirklich schön, wenn Sie durch Hinzufügen weiterer Überwachungsknoten eine relativ lineare Skalierung erzielen könnten. Vielleicht würde ich in 5 Jahren 5000 Hosts und 40 Services pro Host überwachen wollen! Wenn ich aus meiner obigen Anmerkung über 'verteilte Logik' etwas hinzufüge, wäre es nett zu sagen:

    • Unter normalen Umständen müssen diese Überprüfungen auf $ n oder n% der Überwachungsknoten ausgeführt werden.
    • Wenn ein Fehler erkannt wird, führen Sie Überprüfungen für weitere $ n oder n% der Knoten durch, korrelieren Sie die Ergebnisse und verwenden Sie sie, um zu entscheiden, ob Kriterien zum Ausgeben einer Warnung erfüllt wurden.
  • Grafiken und verwaltungsfreundliche Funktionen. Wir müssen unsere SLAs nachverfolgen und wissen, ob unsere "hochverfügbaren" Anwendungen rund um die Uhr verfügbar sind. Idealerweise sollte Ihre vorgeschlagene Lösung die Berichterstellung "out of the box" mit minimalem Aufwand durchführen.

  • Muss über eine solide API oder ein Plug-in-System verfügen, um maßgeschneiderte Prüfungen zu entwickeln.

  • Muss bei Warnungen vernünftig sein. Ich möchte nicht unbedingt wissen (per SMS um 3 Uhr morgens!), Dass ein Überwachungsknoten mein Core-Router ausfällt. Ich tun möchte wissen , ob ein bestimmter Prozentsatz von ihnen zustimmen , dass etwas flippiger los ist;) im Wesentlichen über hier , was ich rede ist „Quorum“ Logik oder die Anwendung der Vernunft auf verteilte Wahnsinn!

Ich bin bereit, sowohl kommerzielle als auch Open-Source-Optionen in Betracht zu ziehen, obwohl ich es vorziehen würde, Software zu meiden, die Millionen Pfund kostet :-) Ich bin auch bereit zu akzeptieren, dass es möglicherweise nichts gibt, das all diese Kriterien erfüllt, aber wollte das Kollektiv danach fragen.

Wenn Sie über die Überwachung von Knoten und deren Platzierung nachdenken, denken Sie daran, dass die meisten davon dedizierte Server in zufälligen ISP-Netzwerken sein werden und sich daher weitestgehend meinem Einflussbereich entziehen. Lösungen, die auf BGP-Feeds und anderen komplexen Netzwerkproblemen beruhen, sind wahrscheinlich nicht geeignet.

Ich sollte auch darauf hinweisen, dass ich in der Vergangenheit die meisten Open-Source-Varianten, einschließlich Nagios, Zabbix und Freunden, entweder evaluiert, bereitgestellt oder stark genutzt / angepasst habe. verteilter "Aspekt, insbesondere im Hinblick auf die in meiner Frage diskutierte Logik und" intelligente "Warnungen.

Gerne klären wir eventuelle Punkte ab. Prost Jungs und Mädels :-)


2
Das ist wirklich seltsam, ich wollte gerade eine ähnliche Frage stellen. Diese Woche hatten wir einige Kundenbeschwerden über Standortausfälle, jedoch nur von bestimmten Standorten. Unsere Warnsysteme haben diese Probleme nicht erkannt. Wir kontaktierten unseren Provider und er bestätigte, dass einige Probleme mit dem Backbone hatten. Ich bin also auch an einer Lösung interessiert. Vielen Dank!
Splattne

Und was war die endgültige Lösung?
Ewwhite

Antworten:


4

Eigentlich keine Antwort, aber einige Hinweise:

  • Schauen Sie sich auf jeden Fall die Präsentation zu Nagios @ Goldman Sachs an . Sie hatten mit den von Ihnen genannten Problemen zu kämpfen - Redundanz, Skalierbarkeit: Tausende von Hosts, auch automatisierte Konfigurationsgenerierung.

  • Ich hatte redundante Nagios-Setup, aber in viel kleinerem Maßstab - 80 Server, ~ 1k Dienste insgesamt. ein dedizierter Master-Server, ein Slave-Server, der mehrmals täglich in regelmäßigen Abständen die Konfiguration vom Master abruft. Beide Server deckten die Überwachung der gleichen Maschinen ab, sie hatten gegenseitige Integritätsüberprüfungen. Ich habe Nagios hauptsächlich als Framework zum Aufrufen benutzerdefinierter produktspezifischer Überprüfungen verwendet [eine Reihe von Cron-Jobs, die Skripten ausführen, die 'künstliche Flusskontrollen' ausführen, Ergebnisse in SQL protokolliert und in den letzten x Minuten nach erfolgreichen / fehlgeschlagenen Ausführungen gesucht]. alles hat sehr gut funktioniert.

  • Ihre Quorum-Logik klingt gut - ein bisschen ähnlich wie meine 'künstlichen Flüsse' - machen Sie einfach weiter, setzen Sie sich selbst um; -]. und lassen Sie nrpe einfach eine Art Flag [oder sql db mit timestamp-status] überprüfen, wie sich die Dinge entwickeln.

  • Wahrscheinlich möchten Sie eine skalierbare Hierarchie aufbauen. Einige Knoten bieten einen Überblick über andere Knoten. Schauen Sie sich die Präsentation vom ersten Punkt an an. Das Standard-Nagios-Forking für jeden einzelnen Check ist bei einer höheren Anzahl von überwachten Services übertrieben.

um einige fragen zu beantworten:

  • In meinem Fall war die überwachte Umgebung ein typisches Master-Slave-Setup [primärer SQL- oder App-Server + Hot-Standby], kein Master-Master.
  • Mein Setup beinhaltete "Human Filtering Factor" - eine Resolver-Gruppe, die ein "Backup" für die SMS-Benachrichtigung war. Es gab bereits eine bezahlte Gruppe von Technikern, die aus anderen Gründen 24/5-Schichten hatten. Sie bekamen das "Überprüfen von Nagios-Mails" als zusätzliche Aufgabe, die sie nicht zu sehr belastete. und sie sind dafür verantwortlich, dass db-admins / it-ops / app-admins tatsächlich aufstehen und Probleme beheben ;-)
  • Ich habe viele gute Dinge über zabbix gehört - zum Warnen und Aufzeichnen von Trends, aber ich habe es nie benutzt. Für mich ist Munin der Trick. Ich habe ein einfaches Nagios-Plugin gehackt, um zu überprüfen, ob auf der Munin-Liste der Server eine "rote" [kritische] Farbe vorhanden ist - nur eine zusätzliche Überprüfung. Sie können auch Werte aus munin rrd-Dateien lesen, um die Anzahl der Abfragen zu verringern, die Sie an den überwachten Computer senden.

1
@astinus - gut für sinnvolle Warnungen habe ich benutzerdefinierte Benachrichtigungsskript verwendet. Anstatt mich auf Nagios zu verlassen, die per Mail / Pager benachrichtigt wurden, speicherte ich die Nachricht in der FIFO-Warteschlange und ließ den Konsumenten die Nachricht basierend auf einer benutzerdefinierten Logik [basierend auf einem recht flexiblen Bereitschaftsplan usw.] versenden bekommt nicht 50 smses in kurzer zeit. Ich sehe ähnliche Ansätze in größeren Maßstäben - Nagios ist nur ein Gerüst und die Leute schreiben darum herum und verwenden tatsächlich immer weniger seiner Funktionen.
pQd

1
In Bezug auf die Hierarchie habe ich im Moment ein völlig "modulares" Nagios-Setup, bei dem Ihr etc / -Verzeichnis eine "Kern" -Konfiguration enthält, die auf allen Hosts gemeinsam (und identisch) ist und dann etc / modules / $ NAME (dh : Mail, Web, Netzwerk, DNS), das zu 100% zwischen Servern portierbar ist. Include with cfg_dir =) Sie fügen alle modulspezifischen Befehle, Plugins und alles in dieses Verzeichnis ein. Es ist ziemlich einfach,> 1 Server zum Ausführen dieser Überprüfungen zu bringen, da Sie das Modul einfach auf so viele Nagios-Boxen kopieren, wie erforderlich. Die Warnungslogik führt jedoch erneut zu Problemen :-)
nixgeek

1
@ Astinus # 2. In meinem Fall tritt die Konfigurationsreplikation Master-> Slave alle 6 Stunden auf. Wenn der Master gerade stirbt (Stromausfall usw.), benachrichtigt der Slave alle, dass der Master tot ist (Gegenprüfung zwischen den Servern). Man kann sich ein anderes Szenario vorstellen - wenn der Master aufgrund einer Fehlkonfiguration stirbt. Wenn dies bis zu 5 Minuten vor der Konfigurationssynchronisierung mit dem Slave geschieht, erfolgt eine Benachrichtigung. Wenn es kurz vor der Konfigurationssynchronisierung ist, haben wir leider kein Überwachungssystem. "Wer wird den Wächter beobachten?" na vielleicht noch ein ganz einfacher nagios.
pQd

1
@pQd - interessant, ich stimme zu, dass die Implementierung der Logik in benutzerdefinierten Benachrichtigungsskripten wahrscheinlich der richtige Weg ist. Es wird jedoch ziemlich schwierig, doppelte Benachrichtigungen von über 2 Hosts zu vermeiden, wenn Sie sagen, dass 50 Hosts überwacht werden und ich noch niemanden (in der Öffentlichkeit) gesehen habe, der seine gemeinsame Logik in ein geeignetes System zur Weitergabe von Nachrichten wie Rabbit oder Amazon integriert SQS.
Nixgeek

1
@ astinus # 3 in meinem Fall war es die "Level 8" -Lösung [des Iso-Osi-Modells]: Primäre Nagios schickten SMS an Leute auf Abruf + E-Mails an 24/5 "Resolver-Gruppe", während sekundäre Nagios nur sendeten. Resolver-Gruppe '. Es lag an dieser Gruppe, Duplikate vor der Eskalation zu filtern.
pQd

1

Was Sie verlangen, klingt sehr nach dem, was Shinken für Nagios getan hat.

Shinken ist ein Nagios-Rewrite.

  • Moderne Sprache (Python)
  • Modernes verteiltes Programmierframework (Pyro)
  • Überwachungsbereiche (Mandantenfähigkeit), HA, Ersatzteile
  • Livestatus API
  • Nagios Plugin kompatibel
  • Native NRPE-Ausführung
  • Geschäftskritikalität von Objekten
  • Geschäftsregeln können auf den Status von Objekten angewendet werden (Verwalten der Cluster- oder Poolverfügbarkeit)
  • Die grafische Darstellung kann mit PNP4nagios auf Graphite- oder RRDtool-Basis erfolgen
  • Stabil und in großen Umgebungen einsetzbar
  • Bei großen Bereitstellungen kann eine Kopplung mit Splunk für die Berichterstellung in Betracht gezogen werden, oder es kann ein Blick auf Graphite geworfen werden, wo RRDtool nicht gut passt.

Dies sollte zum Nachdenken anregen.

Prost

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.