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
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:
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
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
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
Please also mark the comments that contributed to the solution of the article
Content-ID: 392411
Url: https://administrator.de/contentid/392411
Printed on: October 15, 2024 at 04:10 o'clock
18 Comments
Latest comment
Schau mal nach PRTG Monitoring.
Nutze ich schon seit einem Jahr, bin sehr zufrieden damit.
PRTG Paessler
Nutze ich schon seit einem Jahr, bin sehr zufrieden damit.
PRTG Paessler
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
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
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 .
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 ...
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 .
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 ...
Moin,
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...).
@clSchak
Gruß,
Dani
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? 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
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 - 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 . 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 ...
Gruß
@clSchak
[...]
[...]
In vielen Bürogebäuden ist inzwischen die Ausleuchtung mit WiFi wesentlich besser als der Empfang von Mobilfunknetzen.
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
Dani
In vielen Bürogebäuden ist inzwischen die Ausleuchtung mit WiFi wesentlich besser als der Empfang von Mobilfunknetzen.
Moin St-Andreas,
Moin Christian,
Gruß,
Dani
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
Hallo,
uns wurde vor einiger Zeit 'Server Eye' vorgeschlagen. Habe ich aber nicht weiter verfolgt.
Gruß
uns wurde vor einiger Zeit 'Server Eye' vorgeschlagen. Habe ich aber nicht weiter verfolgt.
Gruß
Moin,
Gruß,
Dani
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. Gruß,
Dani