Archiv

Artikel Tagged ‘System Management’

Es reicht drei Dinge zu überwachen

1. Juni 2010 16 Kommentare

Was mir bei der Überwachung von Servern immer wieder auffällt ist, dass es in 95% aller Fälle ausreicht genau drei Dinge zu überwachen:

  • Diskusage
  • Hardware (Netzteile, Festplatten)
  • Raid-Status

In der Reihenfolge. Alles andere erhöht das Grundrauschen hilft aber selten weiter.

Schöner die Cluster nie schwenken

9. Dezember 2009 7 Kommentare

Es gibt Dinge über die kann man wunderbar streiten: vim oder vi, grub oder lilo, nvidia oder ati und natürlich routinemäßige Clusterschwenks. Ich bin dabei ein großer Anhänger von letzteren, denn vernünftig und kontrolliert ausgeführt gibt es im Normalfall keine Probleme. Das heisst man schwenkt regelmäßig, automatisiert und wenn alle an Bord sind.

Denn seien wir doch mal ehrlich: viele Cluster werden installiert und dann sich selbst überlassen. Man verlässt sich auf die vermeintliche Hochverfügbarkeit nur um festzustellen, das der zweite Knoten nicht funktioniert wie er soll wenn es darauf ankommt. Es ist tiefe Nacht, kurz vor Heiligabend und niemand ist zu erreichen.

Sicherlich kann es bei Routineschwenk zu Probleme kommen, aber dafür weiss man wann dieser passiert und man hat (hoffentlich) das benötigte Personal an Bord. Gefahr erkannt, Gefahr gebannt. Als Lohn gibt es die Gewissheit, das der nächste Schwenk ohne Probleme verläuft und wenn nicht sammelt man genug Erfahrungen um damit umzugehen.

Netzteile sind die neuen Festplatten

6. Dezember 2009 8 Kommentare

Wenn ich ein paar Jahre zurück denke, dann waren es hauptsächlich Festplatten die ausgefallen sind. Seit Einführung der 2,5 Zoll SAS-Platten hat sich das stark geändert. Heute sterben hauptsächlich Netzteile, gefolgt vom Mainboard. Vielleicht tut man da bald auch etwas.

Was man bei der Serverüberwachung beachten sollte

12. Juli 2009 10 Kommentare

Wer aus professionellen Gründen einen oder mehrere Server betreibt kommt um eine permanente Überwachung nicht herum. Gerade im Unternehmensbereich wird dieses Thema immer wichtiger, denn nichts ist peinlicher als von Kunden oder dem Chef auf ausgefallenen System oder Fehlfunktionen hingewiesen zu werden.

Ich möchte in folgenden ein paar Punkte ansprechen auf die man achten sollte. Das Tool der Wahl lasse ich außen vor. Es gibt für jeden Zweck, jede Größe ein passendes Tool, sei es nun Monit, Nagios/Icinga oder Eigenentwicklungen.

Im Idealfall stehen am Anfang drei Fragen über die man Nachdenken sollte:

  • Was möchte ich überwachen?
  • Wie muss es überwacht werden?
  • Wann schlägt die Alarmierung zu?

Bei der Was-Frage geht es darum sich klar darüber zu werden, über welche System- oder Dienstzustände man überhaupt informiert werden möchte. Viele Server verfügen mittlerweile über einfache Mittel zur Hardwareüberwachung. Wenn sie da sind sollte man sie nutzen. Ein Ping-Check auf Erreichbarkeit sollte obligatorisch sein und dann natürlich die laufenden Dienste, wie Webserver oder die Datenbank. Manche Dinge sollte man hinterfragen. Checks für Load, CPU-Last oder Speicherauslastung machen nicht immer Sinn, dazu später mehr.

Beim Wie geht es darum wie der Check gestaltet sein muss. Er sollte eindeutig sein und nicht nur die generelle Erreichbarkeit testen, sondern auch Informationen über die ordnungsgemäße Funktion des Test-Objektes liefern. Ein paar Beispiele: bei der Überwachung eines Webservers sollte nicht nur die Erreichbarkeit des Port 80 getestet werden, sondern auch ob der Server den Status-Code 200 zurückliefert. Tut man es nicht würden z.B. Fehlkonfigurationen am Server nicht auffallen. Anderes Beispiel SSL-Support. Wer nur Port 443 überwacht und nicht das Ablauf-Datum des Zertifikates handelt imho Unprofessionell, da hier wieder die Gefahr besteht von Dritten auf eigene Fehler hingewiesen zu werden. Gleiches gilt für Datenbanken oder Anwendungen die eine Anmeldung (SMTP-Auth, POP3, IMAP) erfordern, ob die Anmeldung funktioniert sollte regelmäßig getestet werden. Auch hier gilt generell, das es wichtig ist nicht nur die Erreichbarkeit, sondern auch die ordnungsgemäße Funktion zu testen.

Die komplizierteste Frage, die zugleich ein wenig Fingerspitzengefühl und gleichzeitig Erfahrung im Umgang mit dem Monitoring erfordert ist Wann die Alarmierung losgehen soll. So einfach ist es nämlich leider nicht. Da steht am Anfang zum Beispiel die Frage, ob man in der Nacht für eine kaputte Festplatte aus dem Bett geklingelt werden möchte, wenn der Ersatz erst am Morgen geliefert wird. In der ersten Begeisterung über die Möglichkeiten einer Überwachung wird oftmals zu viel zu oft alarmiert. Die Folge sind schlaflose Nächte für nichts oder ein Ignorieren der Alarme, was auch nicht im Sinne des Ganzen sein kann. Wichtig ist es daher nur zu Alarmieren wenn wirklich etwas wichtiges passiert ist. Das Überwachungstool sollte daher nicht nur Alarmieren können, sondern in Abstufungen Warnen oder einfach nur Informationen von sich geben können. Beispiel: wer die Disk-Usage überwacht sollte einen sinnvollen Schwellwert haben ab wann gewarnt wird. So kann zum Beispiel am Freitag noch die 80% Warnung kommen und entsprechend gehandelt werden, anstatt am frühen Sonntagmorgen per Alarmierung aus den Bett geworfen zu werden. Wichtig ist auch die Abbildung von Abhängigkeiten. Gibt es für einen Server sieben Checks, sollte man bei einem Total-Ausfall im Idealfall nur die Meldung für den gescheiterten Ping-Check bekommen. Alles andere wäre zuviel Information. Der Gau für Systeme ohne Abhängigkeiten sind virtualisierte Umgebungen. Fällt hier ein Systeme mit zig Instanzen aus ersäuft man in Informationen. Dann ist es gar nicht so einfach den Wust zu sichten und auf den eigentlichen Kern des Problems, den ausgefallenen ESX-Server zu stoßen. Dann gibt es noch Dinge die Nice-to-Know sind, aber nicht unbedingt 24/7 alarmierungswürdig sind. Wer seine Server per NTP syncronisiert wird sicherlich wissen wollen wenn der Server trotzdem abdriftet, aber muss das mitten in der Nacht sein? Morgens reicht meist auch. Grenzwertig sind auch Dinge wie Load, CPU-Last und Speicherverbrauch. Server haben immer mal wieder Lastspitzen, aber vielfach reicht es auch aus es einfach nur als Information herauszugeben. Jetzt gilt es noch zu klären wie die Alarme/Informationen den Adressaten erreichen. Per Mail ist keine gute Idee. Das landet oftmals in /dev/null, aber brauchen tut man es doch. SMS und Pager sind Mittel der Wahl und Jabber sollte nicht fehlen. Besonders auf Jabber möchte ich nicht mehr missen. Morgens macht man den Client an und sieht was die Nacht so gewesen ist.

Sich mit dem Thema Serverüberwachung auseinanderzusetzen ist eine lohnenswertge Aufgabe. Man bekommt auf Dauer eine tiefere Einsicht wie die Systeme ticken und die gesamte Umgebung profitiert enorm von einer sinnvollen Überwachung durch eine höhere Verfügbarkeit. Manchmal ergeben sich auch intressante Einsichten. Wie zum Beispiel das die Überwachung innerhalb des Betriebssystems mit den Hersteller-Agenten nicht unbedingt eine gute Wahl ist. Gerät so ein System unter Last können die Überwachungs-Checks in Timeouts laufen, besser ist es in diesen Fall Server mit einen unabhängigen Service-Prozessor zu haben. Intressant ist es auch die Alarme in ein Ticket-System zu füttern. Da werden dann fröhlich Tickets auf- und zugemacht oder bleiben stehen, damit sich jemand des Problems annehmen kann, aber das würde jetzt zu weit führen.

Linux oder Solaris?

7. Juni 2009 10 Kommentare

In den Kommentaren zu Ächtz bin ich gebeten worden mich zu erklären, warum ich Solaris in manchen Punkten für besser als Linux halte und wann ich Solaris einsetzen würde.

Nun, am einfachsten ist die Erklärung wann ich Solaris nicht einsetzen würde, dazu zählt zum Beispiel wenn man viel forkt. Die initiale Erklärung die ich dafür hatte war, das Solaris beim Fork wirklich den gesamten Adressraum kopiert, während Linux via Copy-on-Write nur Teile kopieren muss. Solaris soll (einen offziellen Link dazu habe ich nicht gefunden) mittlerweile auch Copy-on-Write einsetzen, aber geändert hat sich dadurch für mich nichts. Richtig schlimm macht sich das auf CMT-Maschinen bemerkbar, daher immer zu Pre-Fork Modellen greifen. Ein anderes düsteres Thema ist halbwegs aktuelle Software unter Solaris (ich rede hier nicht von OpenSolaris). Die Companion-CD und auch die Grundinstallation enthalten gut abgehangene Software, aber der Umfang ist doch sehr bescheiden. Es gibt zwar Projekte wie Blastwave, OpenCSW oder OpenPkg, aber die können wirklich nur die allergrößten Schmerzen lindern. Ich möchte die Arbeit der wenigen Leute nicht schmälern, aber von Packaging-Standards und -Funktionalitäten wie im Linux-Bereich sind sie weit entfernt.

Hat man keine Probleme mit obigen kann man Solaris ruhigen Gewissens einsetzen. Das ist wie früher Mercedes E-Klasse fahren, eine sichere Wahl und einmal am Laufen durch nichts aufzuhalten. Klar im Vorteil gegenüber Linux ist Solaris in anderen Gebieten.

Langzeitstabilität zum Beispiel. Software, ja selbst Kernel-Treiber die auf Solaris 2.8 funktionieren laufen auch unter Solaris 10. Das Volume-Management mit SDS und Software-RAID macht unter Solaris Spaß. Mir gehen die Nackenhaare hoch beim Gedanken an LVM und MD-Raid, die mit ihren Kommando-Zeilen Orgien einen zur Verzweifelung bringen können. Unter Solaris sind das nur ein paar Befehle, von ZFS mal ganz zu Schweigen. Genauso sieht es bei IPfilter versus IPTables aus. Keine Ahnung wer mehr kann, dafür sind IPF-Regelwerke imho einfacher zu lesen. Insgesamt setzt Solaris nicht auf ellenlange Konfigurations-Dateien, sondern auf Tools mit denen man Dienste via Kommando-Zeile konfiguriert. Mal ein Beispiel:

# dhtadm -M -m 188.25.62.0 -e 'LeaseTim=57600'

Das setzt die DHCP-Leasetime für einen IP-Bereich unter Solaris. Beim ISC-DHCPD (Ok, nicht Linux-Spezifisch, aber ich will nur das Prinzip erklären) müßte man die Konfigurations-Datei parsen, was nicht gerade trivial ist. Diese Tools unter Solaris machen das Scripten aus meiner Sicht sehr viel einfacher.

Ein anderes Beispiel hatte ich ja bereits angesprochen, die Installation. Das Jumpstart Enterprise Toolkit zur Installation von Solaris ist wirklich eine tolle Sache. Ich denke FAI könnte unter Linux da noch am ehesten herankommen, während Redhats Kickstart noch letztes Jahrtausend ist.

Alles im allem ist es, wie so oft, eine Frage der eigenen Präferenzen. Leute mit BSD-Hintergrund werden sich eher in Solaris zurechtfinden und es zu schätzen Wissen. Wer mit Linux aufgewachsen ist, wird Zeit und Geduld investieren müssen. Viele Dinge sind einfach anders und wenn es nur Details sind. Aber aus meiner Sicht lohnt es sich, sich mit beiden zu beschäftigen, denn es erweitert den Horizont und zwingt zu genaueren, bewußteren Arbeiten.

Erfolgreich scheitern

24. Mai 2009 2 Kommentare

Vom ehemaligen NASA-Mitarbeiter Gene Kranz stammt der Ausspruch Failure is not an option. Scheitern ist, wenn es um Menschenleben geht, definitiv keine Option, wenn es aber um Technik und den Umgang damit geht, gehört es für mich immer dazu.

Wichtig ist, das man es von vornherein einplant, einen Plan B (aka. Rollback) hat und die Einsicht sich selbst das Scheitern einzugestehen. Nichts ist lähmender als die vage Aussicht auf eine Lösung, die es vielleicht gar nicht gibt. Da ist ein geordneter Rückzug auf den Ursprungszustand wesentlich besser, als am Ende mit einem Haufen kaputten Systemen dazustehen. Dann ist man wirklich gescheitert.

Twitter zur Serverüberwachung

11. März 2009 Kommentare ausgeschaltet

Das Thema Twitter und Serverüberwachung hatte ich schonmal. Heute mal was ganz einfaches. Einfach einen neuen Twitter-Account aufsetzen, den auf Protected setzen. Nun können andere nur noch nach Freigabe den Feed folgen. Mit dem eigentlichen Twitter-Account nun den Neuen folgen. Diesen neuen Twitter-Account bei Twittermail anmelden und die dort genannte Email-Adresse unter set alert in die monitrc eintragen. Monit neu starten. Fertig.

Links for 2009-03-09

9. März 2009 1 Kommentar

Links for 2009-02-19

19. Februar 2009 2 Kommentare

Links for 2009-02-05

5. Februar 2009 2 Kommentare