EDV - Ende der Vernunft

Es sind die einfachen Dinge

Joern — Wed, 15 Jul 2009 18:31:36 +0000

Hach ja. Kleine Dinge und Schritte bewegen die Welt. Also vergessen wir mal die großen Heldentaten, hier eine Sache die mich schon seit langem ärgert:

Cursor-Tasten in vim unter Solaris. In die .bashrc,.profile oder wie man es gerne möchte:

# delete key bind '"\e[3~":delete-char' # page up key bind '"\e[5~":history-search-forward' # page down key bind '"\e[6~":history-search-backward'

Jaja, Solaristi und Vimperatoren werden mich Auslachen und mich einen n00b schimpfen, aber ich mag es halt wenn die Systeme überall gleich funktionieren.

Was man bei der Serverüberwachung beachten sollte

Joern — Sun, 12 Jul 2009 18:53:49 +0000

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.

Links for 2009-07-09

Joern — Thu, 09 Jul 2009 19:43:43 +0000

Deduplizierung

Joern — Wed, 08 Jul 2009 18:33:15 +0000

Ich habe gerade Challenge with NetApp deduplication (ASIS) gelesen und dabei ist mir eingefallen, das ich das mal erwähnen muss. Ja, Deduplizierung bei NetApp funktioniert wunderbar. Bis zu 88% Einsparung auf SAN-Luns mit Vmware Images. Man kann allerdings auch negative Raten haben, wenn die Daten zu klein sind und sich zu häufig ändern, trotzdem ein tolle Sache.

Danke Herr Beckmeyer

Joern — Wed, 08 Jul 2009 18:23:40 +0000

Eine Antwort auf Zum Abschied einen Gruss habe ich übrigends nicht erhalten. War wohl gerade kein Pratikant da. Obwohl, wenn sich die SPD mit jedem zukünftigen Nichtwähler auseinandersetzen würde hätte sie verdammt viel zu tun.

Killer Tux

Joern — Tue, 07 Jul 2009 16:49:56 +0000

Ldap oder Datenbank – Teil 2

Joern — Mon, 22 Jun 2009 10:39:19 +0000

Vielen Dank für die Antworten bei Ldap oder Datenbank. Die Frage hatte keinen konkreten technischen Hintergrund. Ich bin nur ein Freund des Prinzips der Einfachheit und das bedeutet für mich auch mal zu Hinterfragen, ob es sinnvoll ist Wissen über zwei Datenbanken vorzuhalten.

Wenn man z.B. einen Sack voll Mysql-Cluster betreibt finde ich es besser sich auf eine Technik zu konzentrieren und diese richtig zu beherrschen, als zwei nur halb. Sicher mag Ldap Vorteile beim Lesen haben und es mag ein Standard-Protokoll sein, aber das ist imho nichts was man mit purer Rechenleistung und ein paar pfiffigen Entwicklern nicht in den Griff bekommt, zumal es heute für fast alle wichtigen Applikations-Programme Schnittstellen für Mysql gibt. Natürlich wird sich im Einzelfall zeigen müssen, ob der Umstieg von Ldap in eine relationale Datenbank funktioniert, aber ganz abwegig scheint mir der Gedanke jedenfalls nicht zu sein.

Zum Abschied einen Gruss

Joern — Sat, 20 Jun 2009 11:54:48 +0000

From: Joern Seemann
To: uwe.beckmeyer@bundestag
Subject: Zum Abschied einen Gruss

Hallo Herr Beckmeyer,

als ehemaliger Wähler möchte ich mich von Ihnen verabschieden. Es gibt viele Gründe hierfür, aber das Zensurgesetz hat mir noch einmal deutlich gemacht, daß die SPD ich uns vollkommen auseinandergelebt haben. Ihr Leitsatz “Demokratie ist Mehrheitssache” dürfte angesichts der letzten Wahlergebnisse ein frommer Wunsch bleiben, aber so ist das mit Wünschen man wird oft bitter enttäuscht – so wie ich von der Politik der SPD in den letzten Jahren.

Gruss Joern Seemann

Bewiesen

Joern — Sat, 20 Jun 2009 10:22:39 +0000

Auf Techcrunch gab es mal ein Posting mit Titel Are Linux Programmers Getting Too Fat?, in dem es um die Entwicklung der T-Shirt Größe auf dem Linux Symposium ging. Wer das für einen Witz gehalten hat – nun hier ist der Bildbeweis:

Ldap oder Datenbank

Joern — Tue, 16 Jun 2009 17:49:38 +0000

Mal so unter uns Kaffeeschwestern: gibt es einen guten Grund Ldap einer Datenbank vorzuziehen oder umgekehrt?