Wo stelle ich den Monitoring Server hin?

Hallo,
ich führe oft mit Kunden die Diskussion, wo der Monitoring Server positioniert werden soll. In den meisten Fällen möchte der Kunden den checkmk Server als virtuelle Appliance in seine bestehende Umgebung implementieren. Aus meiner Sicht, nicht optimal. Meiner Meinung ist eine Hardware oder virtuelle Umgebung die ausserhalb der Produktionsumgebung liegt die bessere Lösung. Wie ist euer Vorgehen, arbeitet ihr eher mit isolierten oder doch mit integrierten Lösungen? Was könnten die Vor- und Nachteile sein?

Gruß

Karsten

1 Like

Hi Karsten,

das ist die Diskussion, die wir auch immer wieder führen: Sitzt auf dem Ast, monitorst den Baum…

Die reine Lehre wäre sicherlich, was Du sagst, so unabhängig wie möglich. Ist dann halt mehr Aufwand, den manche Kunden scheuen. Es kommt sicherlich auch darauf an, wie gut sie den Rest der Infrastruktur im Griff haben. Wenn in ihrer Virtualisierungsumgebung selten was schiefgeht, dann ist das vielleicht ein vertretbares Risiko, wenn da all 3 Tage alles den Bach runter geht, maybe not so much…

1 Like

Ein Problem was ich noch sehe ist die Darstellung der Abhängigkeiten (Parents). Nach Ausführung einer Live Migration auf eine anderen Host, kann das Parent z.B. ein Switch ein ganz anderes sein als vor der Migration. Gibt es hier ein Automatismus der dieses anpasst?

Tja,
aus anderen Projekten kann ich nur sagen lass dem Kunden seinen Willen solange es nicht völliger Nonsense ist und der Kunde seine Umgebung offenkundig halbwegs oder sogar ganz im Griff hat.
Sonst hast du bei Problemen immer eine zusätzliche offene Flanke.
Gruß

3 Likes

Generell laufen bei uns ALLE Monitoring Server als virtuelle hosts unter VMWare.
Wir haben quasie pro Rechenzentrum eine virtual Appliance oder eine CentOS welche wiederum dann von einem zentralen Master aus überwacht werden. Die einzelnen Monitoring Server schicken autonom Ihre Nachrichten entweder per SMS (Local Monitoring) oder per snmp trap an IBM Omnibus/DASH wo ein zentrales Team 24x7 dann entsprechend darauf reagriert (Central Monitoring). Im ‘Central Monitoring’ senden wir alle 5 Minuten eine heart beat notification von jedem monitoring server an Omnibus. Wenn der ausbleibt wird ein Alarm im Omnibus ausgelöst. Damit können wir sicherstellen dass die Kommunikation funktiert. Alle snmptraps werden mit snmpinform versandt, damit wir im Monitoring sehen wenn eine Notification nicht ihr Ziel erreicht.

Bei unserem ‘Central Monitoring’ überwachen wir “virtuelle Rechenzentren” die über mehrere physikalische Rechenzentren verteilt sind. Wir sprechen da von “Security zones”. Jede “Security zone” hat ihren eigenen Monitoring Server. Dort betreiben wir die Virtual Appliances als cluster mit jeweils einem node auf einem ESX in dem jeweiligen physikalischen Rechenzentrum und ein virtual node per security zone, wie bereits erwähnt.
Wenn also der ESX Host auf dem der Monitoring Server läuft runter fällt, der Core Switch abraucht oder die Firewall nicht mehr mag wird zumindest über den Master alarmiert dass der Monitoring Server nicht mehr erreicht werden kann. Der zentrale Master alarmiert allerdings auch wenn z.B. die WAN Verbindung zu dem Monitoring Server nicht mehr funktioniert, was nicht zwangsläufig bedeuted dass das Monitoring an dem Standort nicht mehr funktioniert. Im Local Monitoring benutzen wir SMS für die Notification’s, damit ist das Monitoring an dem Standort unabhängig von zentralen Diensten.

Ich hoffe das hilft Euch ein weing weiter.

Gruß

Michael

2 Likes

Hallo Michael,
Danke, für die ausführliche Erklärung.

Gruß

Karsten

Kein Problem. Lass von Dir höhren wie Ihr es umgesetzt habt.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.