close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Folien - Mathias Kettner

EinbettenHerunterladen
Verteiltes Monitoring
23. Oktober 2014
Inhalt
●
Szenarien
●
Entscheidungskriterien
●
Best practices
●
Was wir nicht verfolgen
2 / 37
23.10.14
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
23.10.14
Entscheidungskriterien
●
Sicherheit, wer darf auf wen zugreifen
●
Zuverlässigkeit
●
Netzwerkverkehr
●
Konfigurationsaufwand
●
Ist der Standort autonom?
●
Skalierbarkeit
●
Konsistenz der Daten
4 / 37
23.10.14
Best practice mit Check_MK
5 / 37
23.10.14
Multisite Livestatus
●
Zentrale GUI
●
evtl. zentrale Konfiguration
●
Livestatus Socket per TCP als Backend
6 / 37
23.10.14
Multisite Livestatus
Zentrale
GUI
TCP
6
5
5
7
Instanz 1
TCP
6
5
5
7
Instanz 2
Get hosts
Filter hostname = srvlx1
7 / 37
23.10.14
Einrichtung
Aktivierung auf Instanz
Einrichtung
auf
Zentrale
8 / 37
23.10.14
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
23.10.14
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
23.10.14
Kunden Screenshot
11 / 37
23.10.14
Liveproxyd
●
●
●
Sehr schnelles erkennen von schlechten
Verbindungen
Cachen von statischen Anfragen
Aufrechterhalten von Verbindung -> viel kürzere
Latenz!
12 / 37
23.10.14
Liveproxyd
Zentrale
GUI
Get hosts
Filter hostname = srvlx1
TCP
6
5
5
7
Instanz 1
TCP
6
5
5
7
Instanz 2
Livestatus
proxy
13 / 37
23.10.14
Notifikationen?
14 / 37
23.10.14
mknotifyd
●
Spoolt Benachrichtigungen zum Master
●
Gleichzeitig Versand auch von Slave möglich
15 / 37
23.10.14
mknotifyd
Master
Slave
Notify Spool
Notify Spool
Übertragung
Notifizierung
(Optional)
16 / 37
23.10.14
Livedump
●
●
●
Periodischer Abzug aller Monitoring Daten
Übertragung der Daten auf beliebigen Weg
zum Master
Master Instanz wird mit Daten befüllt
17 / 37
23.10.14
Livedump
Instanz 1 (b)
Cron
Zentrale
Instanz 1 (a)
Dump erzeugen
Dump übertragen
18 / 37
23.10.14
Vor- und Nachteile
Vorteile
●
Hohe Sicherheit: Zentrale braucht keinen
Zugriff auf Remotesites
Nachteile
●
●
Manuelle Einrichtung
Acknowledgment in Zentrale auf Remotesite
nicht sichtbar
19 / 37
23.10.14
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
23.10.14
BI Aggregationen
●
Aggregation frei definierbar
●
Abfrage des Gesamtstatus aus Zentrale
21 / 37
23.10.14
Bi Aggregation
Instanz 1
Aktiver Check
Zentrale
Instanz
Instanz 2
auf Aggr. Status
22 / 37
23.10.14
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
23.10.14
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
23.10.14
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
23.10.14
Ohne dezentralen Monitoringserver
●
●
einfach die Checks übers Netzwerk laufen
lassen
Überwachen z.B. über SSH
26 / 37
23.10.14
Ohne dezentralen Monitoringserver
Client 1
Master
Client 2
27 / 37
23.10.14
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
23.10.14
Kriterien
●
Datenrichtung:
von Master zu Client
●
Zuverlässigkeit: hoch
●
Konf.aufwand:
normal
●
Skalierbarkeit:
abhängig von Servicezahl
●
Konsistenz:
voll
29 / 37
23.10.14
Passives übertragen
●
Agenten Ausgabe auf Zentrale übertragen
●
Push per SSH möglich
30 / 37
23.10.14
Passives übertragen
Client
Monitoring Server
Cron
Datasource
Programs
Agent ausführen
Ausgabe
lesen
Ausgabe
übertragen
31 / 37
23.10.14
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
23.10.14
Kriterien
●
Datenrichtung:
von Client zu Master
●
Zuverlässigkeit: verbindungsabhängig
●
Konf.aufwand:
einmalig
●
Skalierbarkeit:
abhängig von Servicezahl
●
Konsistenz:
voll
33 / 37
23.10.14
Was wir nicht verfolgen
34 / 37
23.10.14
●
●
zentrale SQL-Datenbank
●
Sehr hoher Ressourcenverbrauch
●
Zusätzlicher Administrationsaufwand
●
skaliert schlecht
●
Evtl. Datenredundanz mit Remotesystemen
NSCA
●
Hoher Konfigurationsaufwand
35 / 37
23.10.14
●
mod_gearman
●
●
Wird von Check_MK nicht unterstützt
Gleiche Nachteile wie bei direktem RemoteMonitoring
36 / 37
23.10.14
Vielen Dank für Ihre Aufmerksamkeit
37 / 37
23.10.14
Document
Kategorie
Technik
Seitenansichten
35
Dateigröße
460 KB
Tags
1/--Seiten
melden