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.

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.

Denn Sys-Admins sind für mich Künstler, die auf ihre Weise kreativ sind. Das können sie nur, wenn man neue Eindrücke gewinnt, zusammen mit den alten verarbeitet und dann das Beste für sich daraus macht. Ob das dann immer so aussieht wie sich manche Hersteller das vorstellen steht auf einen anderen Blatt.

Where typical IT organizations had one system administrator managing 15-25 systems, many system administrators in the high performers were managing more than 100 systems!
Metrics that Matter, Part 4: Server to System Administration Ratio

Ich war zuerst etwas skeptisch was die Zahlen angeht, denn Tripwire verkauft Configuration-Control Software und hat damit einen Grund solche Zahlen zu nennen. Beim weiteren Graben findet man aber noch größere Zahlen wie die 300:1 bei TicketMaster und wenn man diesen Thread im ArsTechnica Forum quer liest, die Bestätigung, das ein Verhältnis von 100:1 dieser Tage durchaus normal ist.

Die eine Hälfte verplant die UID/GID schön in Blöcken. 0-1000 Systemaccounts, 1001-5000 Mitarbeiter und Externe fangen bei 55000 an. Genauso sieht es bei den GIDs aus. Der anderen Hälfte ist das meiste davon schnurz egal. Ok, die Systemaccounts sollte man frei lassen, aber wenn intressiert schon die UID/GID, hauptsache sie ist überall gleich.

Zu welcher Hälfte gehörst Du und warum?

“If we began to experience a similar outage more than about two or three business hours per quarter, we’d probably make Google Apps and Gmail a backup solution to a locally hosted mail system, if we used it at all. And it would likely be years before we’d try a cloud-based collaborative system again from any vendor,” Proffitt said.

Bei drei Ausfällen im Quartal je 2 Stunden bin ich bei 24 Stunden im Jahr, was über 99% Verfügbarkeit entspricht. Der Herr betreut 40 Benutzer, bei jährlichen Google Apps Kosten von 50$, sind das 2000$ was die Firma im Jahr bezahlt. Bedenkt man, das dafür keine Anschaffungs-, sowie kaum Betriebs- und Unterhaltskosten entstehen ist das viel Gejammer für sehr wenig Geld.

If you have all your DNS servers virtualized which cannot be started because of network or shared storage issues, you can run into problems starting other servers and services that rely on DNS.
Recovering servers, virtual machines after power failure

Man sollte sich immer im Klaren darüber sein, das jede zusätzlich eingebrachte Komponente (Storage, Virtualisierung etc) Probleme machen kann – trotz Hochverfügbarkeit. Lieber viele kleine, als wenige grosse Systeme, ist zumindest meine Erfahrung.

Ich hab dabei Bauchschmerzen, selbst bei einzelnen Systemen wo man vorher alles am Test-System getestet und abgenommen hat. An automatische Updates bei mehreren Systemen mag ich garnicht denken, da hab ich immer den GAU vor Augen, wo man morgens zur Arbeit kommt und nichts mehr geht. Bin ich jetzt ein Feigling und Übervorsichtig?

Zuerst sollte man davon Abstand nehmen Hostnamen zu wählen, der auch gleichzeitig einen Dienst darstellt. Nennt man seinen Server zum Beispiel www mag das auf den ersten Blick eine tolle Idee sein, wenn man aber irgendwann mal auf einen anderen Server migrieren möchte geht das Drama los. Viel besser ist es einen abweichenden Hostnamen zu wählen und später einfach nur den DNS-Eintrag für den Dienst zu schwenken.

Oftmals kann man Hosts in Gruppen einsortieren und ihnen eine Funkion zuweisen. Um beim Beispiel Web zu bleiben:

• http-srv – beschreibt einen Web-Server
• http-db – ist eine Datenbank für Web-Server
• http-script – dort liegt die Provisionierung der Web-Server

Logischerweise hat man oftmals mehrere Maschinen mit gleicher Funktion, weswegen eine Durchnummerierung notwendig ist. Kein grosses Ding, man sollte sich nur Gedanken darüber machen, was passiert wenn z.B. http-srv0 abgelöst werden soll. Heisst der neue Server nun auch http-srv0 oder doch lieber http-srv1? Ich halte letzteres für die bessere Lösung. Es ist ein sauberer Schnitt. Keine doppelten oder Spielereien mit temporären Namen und der nächste kann ja wieder http-srv0 heissen.

An dieser Stelle muss der Name noch nicht Zuende sein. Man kann noch weitere Informationen im Hostnamen ablegen wie z.B. den Status des Systemes, ob es sich um eine physikalische Maschine handelt oder eine virtuelle und, wer mag, den Standort.

So ergibt sich z.B. ein Hostname wie http-script0-vta. Also ein Provisionierungs-Server für das Web-System, ein (v)irtueller Server, ein (T)est-System am Standort A.

Als Host-Typ würde mir spontan (v)irtuell oder VMWare, (p)hysikalische Maschine, Solaris-(Z)one einfallen. Beim Status wären es (p)roduktiv, (A)bnahme oder (T)est-System. Der Standort wiederum sollte sich an die Gegebenheiten orientieren. Meist reicht Standort A oder B, sind die Hosts über Deutschland verteilt bieten sich Auto-Kennzeichen an.

Letztlich ist es wichtig eine maximale Länge von Hostnamen vorzugeben. Niemanden ist geholfen mit einen Bandwurm-Namen, andererseits gibt es die Hostname Tab Completion in der Bash und ZSH.