lordgurke
Goto Top

Empfehlung für Server-Monitoring gesucht

Moin,

wir sehen uns momentan ein wenig nach einer Alternative zu unserem jetzigen Server-Monitoring um. Getestet habe ich bisher noch nichts, aber vielleicht hat jemand einen Tipp für mich, was ich mir als erstes vornehmen sollte - gerne auch etwas unbekannteres abseits von Zabbix und Nagios, was aber gut funktioniert face-wink
Unser jetziges Monitoring-System wurde irgendwann um 2004 von irgendwem aus der Firma selbst geschrieben, funktioniert aber grundsätzlich. Wir hätten nur gerne mal langsam ein paar Funktionen, bei denen sich niemand findet, der diese freiwillig in den alten (und teils schlimmen) Code hineinfrickeln will.

Abgesehen von der reinen Überwachung per Ping oder HTTP hat der Monitor ein paar Besonderheiten was die Alarmierung angeht und die haben einen gewissen Komfort-Faktor, den wir gerne beibehalten wollen:

Wenn etwas ausfällt gibt es eine Telegram-Nachricht an diejenigen, die Rufbereitschaft haben. Dann muss man zu einem Browser laufen, dort den Monitor aufrufen und klicken, dass man sich kümmert.
Reagiert man darauf nicht, kommt nach kurzer Zeit eine SMS (weil könnte ja sein, dass Telegram eine Störung hat).
Und als Eskalation gibt es dann irgendwann (Zeit pro Server einstellbar) einen Telefonanruf an eine Auswahl von Leuten, wo einem per TTS vorgelesen wird was das Problem ist und man sich doch bitte ENDLICH darum bemühen sollte dass das weg geht.

Der Monitor müsste, um das abzubilden, in der Lage sein Scripte oder HTTP-Aufrufe im Alarmfall machen können.
Damit das TTS "schön" funktioniert müsste es zudem möglich sein, eine Art Beschreibung für einen Server/Dienst hinzufügen zu können - denn dieser Text ist, was per TTS verlesen wird.

Außerdem kann das Monitoring im Augenblick Monitoring-Ergebnisse verknüpfen, um bestimmte Dinge zu prüfen und zu eskalieren.
So haben wir z.B. als Überwachung für ganze Standorte konfiguriert, dass wir von dort die Erreichbarkeit der Root-Nameserver prüfen, aber den großen Alarm nur dann schlagen, wenn auch wirklich mindestens 5 von denen unerreichbar sind.

Für externes Monitoring haben wir (is ja klar) bei einem Anbieter einen Server angemietet, der kleinere Teile der Monitoring-Config repliziert bekommt - denn er kann ja nur die Dienste prüfen, die auch aus dem Internet erreichbar sind. Da beschränken wir uns darauf, die Erreichbarkeit von ein paar definierten Diensten (DNS, ein paar wichtige Webseiten) zu prüfen.

Das neue System sollte also die Möglichkeit bieten:
  • Alarm-Trigger per Script oder HTTP-Aufruf (und vielleicht auch reagieren, wenn das einen Fehler zurückliefert)
  • Alarm-Trigger basierend auf der Eskalationsstufe wählen
  • Monitoring auch ohne auf dem Server installierten Client ermöglichen - sonst könnten wir z.B. keine IP-Kameras überwachen
  • HTTP-Monitoring sollte auf Statuscode oder zurückgelieferten Text suchen können. Momentan überwachen wir PHP-FPM bspw. so, dass wir eine Datei anlegen welche einen definierten String per "echo" ausgibt. Und sollte das nicht mehr kommen, ist was mit dem FPM faul
  • HTTPS-Monitoring: Es sollte grundsätzlich Möglich sein, eine Webseite per HTTPS zu prüfen. Lacht nicht, diese Funktionalität fehlt manchmal...
  • Mit IPv6 klar kommt
  • Eine API anbieten, mit der man den Status abfragen kann
  • Ausreichend schnell sein: Unser jetziges System braucht für die Abfrage der ca. 200 konfigurierten Server um die 20 Sekunden. Das ermöglicht problemlos einen 60 Sekunden-Prüfintervall.
  • BONUS: Es sollte eine Möglichkeit geben, die konfigurierten KONTAKTE für die Alarmierung zu replizieren, zumindest aber per API abzurufen damit diese automatisch mit den externen Monitoren synchron gehalten werden.

Weitere Sachen wie SNMP-Abfragen müssen nicht zwingend sein, da haben wir ein funktionierendes System. Aber wenn da was brauchbares mitgeliefert wird, nehmen wir das natürlich gerne mit face-wink

Content-ID: 392411

Url: https://administrator.de/contentid/392411

Printed on: October 15, 2024 at 04:10 o'clock

Der.ITler
Der.ITler Nov 11, 2018 at 14:16:14 (UTC)
Goto Top
Schau mal nach PRTG Monitoring.

Nutze ich schon seit einem Jahr, bin sehr zufrieden damit.


PRTG Paessler
aqui
aqui Nov 11, 2018, updated at Feb 14, 2019 at 09:29:05 (UTC)
Goto Top
Line21
Line21 Nov 11, 2018 at 15:35:56 (UTC)
Goto Top
nEmEsIs
nEmEsIs Nov 11, 2018 at 17:33:06 (UTC)
Goto Top
Hi

Check_mk

https://mathias-kettner.de

Mit freundlichen Grüßen Nemesis
certifiedit.net
certifiedit.net Nov 11, 2018 at 17:47:13 (UTC)
Goto Top
Guten Abend, @LordGurke,

ich denke damit sollte (fast) jede Lösung klar kommen, wichtiger als die Rundfrage ist daher die eigene Evaluation, wie es euch passt, da es final auch immer Geschmackssache ist.

Viele Grüße,

Christian
clSchak
clSchak Nov 11, 2018 at 18:42:11 (UTC)
Goto Top
Hi @LordGurke,

ergänzend zu den genannten Systemen kann, bis auf das TTS (das will ich jetzt auch haben (: ) PRTG abbilden, nebst der API kann man auch Meldungen versenden in Abhängigkeit des aktuellen Status und wie lange der schon anhält. Eingerichtet hat man das System an einem Tag und dann kann sich Templates für erstellen die man dann auf die Systeme loslassen kann - die "automatische Suche" würde ich direkt sein lassen face-wink.

SNMPv1-3 ist natürlich möglich, wobei ich bei >5.000 Sensoren nur noch SNMPv2 fahren würde und >2000 WMI Sensoren mind. 2 weitere Server auf Blech (keine VM's) planen würde. Wir haben jetzt run 9k Sensoren am laufen (SNMP, Scriptabfragen, SSH, sFlow, WMI usw.) und das System rennt verteilt auf drei Server (keine Maßlosen Maschinen) ohne jegliche Probleme selbst mit Remote-Standorten.

Wenn man mag, kann man auch die Patchstände der Windowsserver überwachen, ebenso SSL Zertifikate (inkl. Ablaufdatum und darauf Meldungen setzen). Das bisher "komplizierteste" war die Einrichtung der Abfrage auf einen HP Server und dessen Festplattenstatus, bei den älteren Generationen kann man das nicht direkt über das ILO abfragen, ebenso die Abfrage der Leistungsdaten einer Grafikkarte von nVIDIA lässt sich realisieren (hab das in Nagios bisher nicht hinbekommen).

Display-Anzeigen kann man sich auch erstellen, wobei mir die gelieferten Icons nicht so sehr gefallen, ich hab bei uns vereinzelt mit Visio ein Hintergrundbild erstellt und die Sensoranzeigen dann passend platziert :>

Einzige Wermutstropfen sind der Preis und die mangelnden (3. Anbieter) Addons und fertige Schnittstellen zu gängigen anderen Systemen - wobei man mit der REST API schon sehr viel machen kann - z.B. den aktuellen Status eines Sensors auslesen.

Gruß
@clSchak

PS: nein ich arbeite nicht für PRTG ... face-smile
Dani
Dani Nov 11, 2018 updated at 19:57:46 (UTC)
Goto Top
Moin,
Gibt's nen Protokoll oder nen Eintrag in VMWare, der genau dieses Verhalten bewirkt?
Icinga2 - Hat mit Nagios nichts mehr zu tun - Wurde von Grund auf neu entwickelt.

Ansonsten bin ich bei @clSchak. Wobei viele WMI Sensoren inzwischen auch als SNMP vorliegen. Mit einem ordentlichen Design von Core und Probe-Server kann man die Sensoren vernüftig verteilen (Gebäude, Standorte, Security Zones, etc...).

Wenn etwas ausfällt gibt es eine Telegram-Nachricht an diejenigen, die Rufbereitschaft haben. Dann muss man zu einem Browser laufen, dort den Monitor aufrufen und klicken, dass man sich kümmert.
Auf den Step würde ich verzichten. SMS ist hier meiner Meinung nach das Zuverlässigste Mittel. Kommt auch an, wenn der Empfang Edge ist.

Und als Eskalation gibt es dann irgendwann (Zeit pro Server einstellbar) einen Telefonanruf an eine Auswahl von Leuten, wo einem per TTS vorgelesen wird was das Problem ist und man sich doch bitte ENDLICH darum bemühen sollte dass das weg geht.
Wenn solche technischen Maßnahmen notwendig sind, stimmt etwas am Prozess nicht. Da würde ich eher auf organisatorsische Maßnahmen setzen.

@clSchak
ergänzend zu den genannten Systemen kann, bis auf das TTS (das will ich jetzt auch haben (: )
Kein NOC? face-big-smile


Einzige Wermutstropfen sind der Preis und die mangelnden (3. Anbieter) Addons und fertige Schnittstellen zu gängigen anderen Systemen
Was vermisst du bisher an Sensoren bzw. Addons?


Gruß,
Dani
AlFalcone
AlFalcone Nov 11, 2018 at 22:39:33 (UTC)
Goto Top
ohne wenn und aber PRTG oder Advanced Hostmonitor, alles andere ist viel zu viel gefrimmel und anpassen ohne Ende.
clSchak
clSchak Nov 11, 2018 at 23:52:15 (UTC)
Goto Top
Zitat von @Dani:


Einzige Wermutstropfen sind der Preis und die mangelnden (3. Anbieter) Addons und fertige Schnittstellen zu gängigen anderen Systemen
Was vermisst du bisher an Sensoren bzw. Addons?


Gruß,
Dani

Ein direktes Visio Addin würde mir gefallen, die Maps Funktion ist zwar brauchbar, aber mit Visio kann man besser arbeiten, dann eine Schnittstelle Richtung OTRS und I-DOIT ... kann man sicherlich auch alles selbst programmieren oder für Geld zukaufen... Der Wunsch nach einer "Eierlegendenwollmilchsau" ist halt immer gegeben face-smile - Sensoren habe ich jetzt keinen den ich vermisse, wenn wir etwas überwachen wollen was nicht funktioniert liegt es eher am Gerät wie an der Software.

Bzgl. der Remotestandorte, die Probe läuft immer mit auf dem DC (ja ich weis - soll man nicht machen) da vor Ort ansonsten nichts andere steht, Last verursacht das nahezu nix, selbst wenn an dem Standort mal >200 Sensoren aktiv sind.

Und nein, ein NOC in der Ausstattung haben wir nicht :> wäre evtl. auch ein wenig oversized bei uns face-smile. Bzgl. WMI und SNMP gebe ich dir recht, allerdings nutzen wir WMI vorallem bei SQL und Mailservern und wir Überwachen damit auch Dateiablagen von einigen Applikationsservern und den Wachstum einzelner Dateien (DB Files z.B. um Forecasts vom Wachstum zu bekommen wenn mal was neues angeschafft werden muss).

Der Hauptgrund damals zu PRTG zu gehen war allerdings die schnelle und einfache Bereitstellung, man hat mit 1-2 T Aufwand das meiste aufgenommen, was am längsten Zeit zieht ist das ermitteln der korrekten OID's wenn man gezielt was überwachen möchte, z.B. aktuelle Stromverbrauch bei Servern - man will ja nicht jede MIB importieren ... face-smile

Gruß
@clSchak
St-Andreas
St-Andreas Nov 12, 2018 at 06:35:21 (UTC)
Goto Top
Zitat von @Dani:

Moin,
[...]
Wenn etwas ausfällt gibt es eine Telegram-Nachricht an diejenigen, die Rufbereitschaft haben. Dann muss man zu einem Browser laufen, dort den Monitor aufrufen und klicken, dass man sich kümmert.
Auf den Step würde ich verzichten. SMS ist hier meiner Meinung nach das Zuverlässigste Mittel. Kommt auch an, wenn der Empfang Edge ist.
[...]
Gruß,
Dani

In vielen Bürogebäuden ist inzwischen die Ausleuchtung mit WiFi wesentlich besser als der Empfang von Mobilfunknetzen.
MarkBeaker
MarkBeaker Nov 12, 2018 at 08:17:20 (UTC)
Goto Top
Ich kann dir auch Check_MK empfehlen.
Habe damit eine sehr große Infrastrucktur überwacht,
funktioniert super bei uns!

Gruß
Christian
Dani
Dani Nov 12, 2018 updated at 09:28:41 (UTC)
Goto Top
Moin St-Andreas,
In vielen Bürogebäuden ist inzwischen die Ausleuchtung mit WiFi wesentlich besser als der Empfang von Mobilfunknetzen.
es geht doch um eine sogenannte Rufbereitschaft. D.h. ein Mitarbeiter/Kollege sitzt zu Hause oder darf sich sogar im Umkreis von 50km frei bewegen, muss aber greifbar sein. Da würde ich schon sagen, dass Edge immer vorhanden ist.

Moin Christian,
Habe damit eine sehr große Infrastrucktur überwacht,
was heißt groß in diesem Fall?


Gruß,
Dani
Dilbert-MD
Dilbert-MD Nov 12, 2018 at 10:07:24 (UTC)
Goto Top
Hallo,

uns wurde vor einiger Zeit 'Server Eye' vorgeschlagen. Habe ich aber nicht weiter verfolgt.

Gruß
JohnDorian
JohnDorian Nov 12, 2018 at 14:57:33 (UTC)
Goto Top
Hallo!

wir haben ebenfalls seit einigen Jahren PRTG von Paessler im Einsatz und sind hochzufrieden!
Die Möglichkeiten sind sehr hoch, bei geringem Konfigurationsaufwand. Es lassen sich auch hervorragend Maps kreieren, mit denen man immer einen schnellen Überblick hat.

Gruß, JD
LordGurke
LordGurke Nov 12, 2018 at 17:36:18 (UTC)
Goto Top
Danke euch allen für den Input!

Für PRTG hatten wir uns vor einiger Zeit WIMRE mal eine Demo geben lassen, die Kollegen waren aber nur mäßig begeistert.
Wir hätten ja sogar extra dafür einen Windows-Server aufgesetzt und, aber die Monitoring-Funktionen für die Linux-Server waren dann auch eher nicht ganz so wie wir uns das vorstellten.
Ich habe das gerade nur kurz überflogen, aber es scheint als sei das noch immer ausschließlich Windows-Basiert, ohne geprüft zu haben wie gut das jetzt per SNMP mit Linux-System harmoniert.
Das hatte ich eingeangs vergessen zu erwähnen: Bei uns findet man maximal Restspuren von Microsoft-Systemen, an sich ist alles Linux, Cisco, Foundry oder Teles face-wink



Ui, das kannte ich noch nicht, sieht aber vielversprechend aus! Vor allem weil das Out-of-the-Box OSPF und BGP monitoren kann!
Damit könnte ich dann ein Monitoring-System für das Netzwerk weitesgehend einstampfen...
Und schon alleine wegen dem Spionage-Hamster will ich das ausprobieren face-big-smile


Zitat von @nEmEsIs:
Check_mk

Das sieht auch ganz gut aus, das wird auf jeden Fall tiefergehend getestet.
Insgesamt wirkt das so, als wenn das eher ein Framework für Monitoring ist, was mir sehr gefällt.
Denn das Monitoring muss ja an die zu überwachenden Systeme angepasst werden können, nicht umgekehrt.


Zitat von @Dani:
Wenn etwas ausfällt gibt es eine Telegram-Nachricht an diejenigen, die Rufbereitschaft haben. Dann muss man zu einem Browser laufen, dort den Monitor aufrufen und klicken, dass man sich kümmert.
Auf den Step würde ich verzichten. SMS ist hier meiner Meinung nach das Zuverlässigste Mittel. Kommt auch an, wenn der Empfang Edge ist.

Die Telegram-Benachrichtigung haben wir eingeführt, weil wir immer wieder Probleme mit der SMS-Zustellung hatten.
Zuerst traf es das o2-Netz, was einfach Wochenlang nicht richtig beim Kollegen funktionierte (voller Empfang, aber keine Funktion),
dann hatte ich auch mal Probleme mit einer defekten SIM-Karte der Telekom die sich eines Nachts einfach verabschiedete und ich somit keinen Empfang mehr hatte.
Telegram kam dank WLAN immer an und ist auch geräteunabhängig face-wink
Und inzwischen kommen die Telegram-Nachrichten mit einem Button, den man direkt drücken kann und der Monitor weiß, dass jemand die Nachricht bekommen hat.
Wenn das nicht rechtzeitig gedrückt wird, wird als Failover der Anruf geschickt.


Und als Eskalation gibt es dann irgendwann (Zeit pro Server einstellbar) einen Telefonanruf an eine Auswahl von Leuten, wo einem per TTS vorgelesen wird was das Problem ist und man sich doch bitte ENDLICH darum bemühen sollte dass das weg geht.
Wenn solche technischen Maßnahmen notwendig sind, stimmt etwas am Prozess nicht. Da würde ich eher auf organisatorsische Maßnahmen setzen.

Dieser Anruf kommt, weil wir damit eine Echtzeit-Bestätigung haben, dass ein bestimmtes Telefon erreichbar und jemand rangegangen ist (man muss währenddessen die Taste 5 als Bestätigung drücken). Außerdem lässt sich ein Anruf tendenziell auch im tiefsten Tiefschlaf schlechter überhören als eine einzelne Messenger-Benachrichtigung.
Das ist nur der Failover dafür, falls wirklich die normalen Benachrichtigungen versagen.
Damit wurde sehr erfolgreich die nicht funktionierende Funkzelle von o2 abgefangen, ebenso wie meine defekte SIM-Karte, denn der Anruf kam (wie die SMS) auch nicht durch
und es konnten automatisch die Alternativkontakte mit den Ausfallmeldungen beworfen werden.
Es werden also technische Probleme mit technischen Maßnahmen erschlagen face-wink
Dani
Dani Nov 12, 2018 at 20:30:58 (UTC)
Goto Top
Moin,
Ich habe das gerade nur kurz überflogen, aber es scheint als sei das noch immer ausschließlich Windows-Basiert, ohne geprüft zu haben wie gut das jetzt per SNMP mit Linux-System harmoniert.
wir überwachen damit eine dreistellige Anzahl von Linuxsystemen (Debian, Ubuntu, CentOS). Da würde mich mal interssieren, welchen speziellen Anforderungen ihr da habt.

bei uns findet man maximal Restspuren von Microsoft-Systemen, an sich ist alles Linux, Cisco, Foundry oder Teles
Linux und Cisco funktioniert im Rahmen unserer Anforderungen problemlos.

Die Telegram-Benachrichtigung haben wir eingeführt, weil wir immer wieder Probleme mit der SMS-Zustellung hatten.
SMS ist zu 99% informativ für die Fachabteiliungen. Sachen gibt's... bin ich froh, dass wir ein NOC haben. Technische Probleme mit organisatorischen Maßnahmen erschlagen. face-big-smile


Gruß,
Dani
Kuemmel
Kuemmel Feb 13, 2019 at 19:39:26 (UTC)
Goto Top
@LordGurke
Und? Gibt es schon Neuigkeiten? Habt ihr euch entschieden?

Gruß
Kümmel
LordGurke
LordGurke Feb 22, 2019 at 02:03:44 (UTC)
Goto Top
Zitat von @Kuemmel:
@LordGurke
Und? Gibt es schon Neuigkeiten? Habt ihr euch entschieden?

Es ist auf jeden Fall jetzt ein Observium in den Einsatz gegangen, um speziell das Netzwerk und die Infrastruktur drumherum (PDUs, Temperatursensoren in den Räumen u.s.w.) zu monitoren. Exakt dafür ist das offenbar auch optimiert, das Monitoring von Server-Diensten lässt dann aber leider doch viele Wünsche offen.

Da testen wir gerade check_mk aus, was sich da einfach aufgrund der großen Flexibilität anbietet - und im Moment spricht alles dafür, dass wir check_mk auch beibehalten.

Für die Alarmierung haben wir jetzt eine selbst entwickelte API im Einsatz, die einfach nur die Meldungen entgegen nimmt (egal, ob sie aus Observium, check_mk oder OTRS kommt) und dann an die jeweiligen Empfänger über verschiedene Wege weitergibt.

Danke nochmal an Alle für die Tipps!