Verteiltes Monitoring 23. Oktober 2014
Inhalt Szenarien Entscheidungskriterien Best practices Was wir nicht verfolgen 2 / 37
Szenarien Mehrere Rechenzentren weltweit Überwachung tausender Märkte Überwachung als Managed Service Netztrennungen (DMZ) Aufteilung von Produktion / Integration Lastverteilungen Kleine Standorte mit 2-3 Geräten Dienste / Server im Internet 3 / 37
Entscheidungskriterien Sicherheit, wer darf auf wen zugreifen Zuverlässigkeit Netzwerkverkehr Konfigurationsaufwand Ist der Standort autonom? Skalierbarkeit Konsistenz der Daten 4 / 37
Best practice mit Check_MK 5 / 37
Multisite Livestatus Zentrale GUI evtl. zentrale Konfiguration Livestatus Socket per TCP als Backend 6 / 37
Multisite Livestatus TCP 6 5 5 7 Instanz 1 Zentrale GUI Get hosts Filter hostname = srvlx1 TCP 6 5 5 7 Instanz 2 7 / 37
Einrichtung Aktivierung auf Instanz Einrichtung auf Zentrale 8 / 37
Vor- und Nachteile Vorteile Sehr einfach zu konfigurieren Bei Verbindungsschwierigkeiten kein Datenverlust oder Verzögerung Nachteile Skalierung nur bis etwa 50-60 Standorte Abfragegeschwindigkeit richtet sich nach langsamster Leitung 9 / 37
Kriterien Datenrichtung: von Master zur Slave Instanz Zuverlässigkeit: hoch Konf.aufwand: einmalig Skalierbarkeit: etwa 60 Instanzen Konsistenz: voll gegeben Funktioniert autonom 10 / 37
Kunden Screenshot 11 / 37
Liveproxyd Sehr schnelles erkennen von schlechten Verbindungen Cachen von statischen Anfragen Aufrechterhalten von Verbindung -> viel kürzere Latenz! 12 / 37
Liveproxyd Zentrale GUI Get hosts Filter hostname = srvlx1 Livestatus proxy TCP 6 5 5 7 Instanz 1 TCP 6 5 5 7 Instanz 2 13 / 37
Notifikationen? 14 / 37
mknotifyd Spoolt Benachrichtigungen zum Master Gleichzeitig Versand auch von Slave möglich 15 / 37
mknotifyd Master Slave Notify Spool Notify Spool Übertragung Notifizierung (Optional) 16 / 37
Livedump Periodischer Abzug aller Monitoring Daten Übertragung der Daten auf beliebigen Weg zum Master Master Instanz wird mit Daten befüllt 17 / 37
Livedump Instanz 1 (b) Cron Zentrale Instanz 1 (a) Dump erzeugen Dump übertragen 18 / 37
Vor- und Nachteile Vorteile Hohe Sicherheit: Zentrale braucht keinen Zugriff auf Remotesites Nachteile Manuelle Einrichtung Acknowledgment in Zentrale auf Remotesite nicht sichtbar 19 / 37
Kriterien Datenrichtung: von Slave zur Master Instanz Zuverlässigkeit: muss überwacht werden Konf.aufwand: etwas erhöht Skalierbarkeit: abhängig von Servicezahl Konsistenz: nicht gegeben 20 / 37
BI Aggregationen Aggregation frei definierbar Abfrage des Gesamtstatus aus Zentrale 21 / 37
Bi Aggregation Aktiver Check Instanz 1 Zentrale Instanz auf Aggr. Status Instanz 2 22 / 37
Vor- und Nachteile Vorteile Skaliert bis zu vielen tausend Standorten Übersichtlich Nachteile Ein aktiver Check pro Instanz Weniger Details direkt im Zentralsystem abrufbar 23 / 37
Kriterien Datenrichtung: von Master zur Slave Instanz Zuverlässigkeit: hoch Konf.aufwand: einmalig nötig Skalierbarkeit: mehrere tausend Instanzen Konsistenz: Systeme sind getrennt 24 / 37
Beispiel EDEKA Point of Sales Monioring bei EDEKA Überwachung von 1.200 Filialen in Norddeutschland Autarkes Monitoring in den Filialen Zentrales Dashboard in Minden Rollout Februar 2012 25 / 37
Ohne dezentralen Monitoringserver einfach die Checks übers Netzwerk laufen lassen Überwachen z.b. über SSH 26 / 37
Ohne dezentralen Monitoringserver Client 1 Master Client 2 27 / 37
Vor- und Nachteile Vorteile Einfach, da kein zusätzlicher Server nötig ist Nachteile Höhere Laufzeiten ständiger Netzwerkverkehr durch Monitoring bei Leitungsausfall kein Monitoring mehr 28 / 37
Kriterien Datenrichtung: von Master zu Client Zuverlässigkeit: hoch Konf.aufwand: normal Skalierbarkeit: abhängig von Servicezahl Konsistenz: voll 29 / 37
Passives übertragen Agenten Ausgabe auf Zentrale übertragen Push per SSH möglich 30 / 37
Passives übertragen Client Monitoring Server Datasource Programs Ausgabe lesen Cron Agent ausführen Ausgabe übertragen 31 / 37
Vor- und Nachteile Vorteile Sehr sicher, ähnlich wie Livedump keine Datenredundanz wie bei Livedump Nachteile Konfigurationsaufwand Versenden der Daten muss selbst geskriptet werden geht nicht für SNMP 32 / 37
Kriterien Datenrichtung: von Client zu Master Zuverlässigkeit: verbindungsabhängig Konf.aufwand: einmalig Skalierbarkeit: abhängig von Servicezahl Konsistenz: voll 33 / 37
Was wir nicht verfolgen 34 / 37
zentrale SQL-Datenbank Sehr hoher Ressourcenverbrauch Zusätzlicher Administrationsaufwand skaliert schlecht Evtl. Datenredundanz mit Remotesystemen NSCA Hoher Konfigurationsaufwand 35 / 37
mod_gearman Wird von Check_MK nicht unterstützt Gleiche Nachteile wie bei direktem Remote- Monitoring 36 / 37
Vielen Dank für Ihre Aufmerksamkeit 37 / 37