Select Page

NETWAYS Blog

Kraut und Rüben: Kleine Helfer für Entwickler und Admins

Heute kurz und schmerzlos: Tools und Features, die ich sehr praktisch finde und niemanden verheimlichen will (..der sie noch nicht kennt).

PSTree

Mit pstree kann man sich seine Prozesse als hierarchischen Baum darstellen lassen. Sehr praktisch um Prozessabhängigkeiten zu erkennen, bzw. zu sehen welcher Prozess was geforkt hat.
Das sieht dann z.B. so aus:


[moja@localhost icinga-core]# pstree -ps 9975
systemd(1)───firefox(9975)─┬─{firefox}(9998)
                           ├─{firefox}(9999)
                           ├─{firefox}(10000)
                           ├─{firefox}(10001)
                           ├─{firefox}(10002)
                           ....
                           ├─{firefox}(20879)
                           └─{firefox}(20925)

Chrome Network Tools – Copy as Curl

In Chrome/ium kam vor kurzen ein neues, sehr praktisches Feature in die Netzwerktools: Mit der ‘Copy as curl’ Funktion kann man einen Request mit allen Headern und Parametern direkt als curl(1) Aufruf in die Zwischenablage kopieren:
Copy as Curl
Kleiner Tipp: Da als ‘Accept-Encoding’ gerne ‘gzip,deflate’ gesetzt ist und man damit eine gezippte Antwort bekommt sollte man entweder den -H “Accept-Encoding” Parameter aus der Anfrage entfernen oder das Ergebnis durch gzip pipen, um Zeichensalat zu verhindern.

Vim

Und ein paar kleine Vim Befehle gehen immer zum Abschluss:

  • tabnew, tabnext und tabprev Erstellen und Navigieren Tabs im VIM. Will man dann noch im Kommandomodus mit Tab zwischen den Tabs wechseln kann man folgendes in seine .vimrc hinzufügen:
    map  :tabnext <CR>
    map  :tabprev <CR>
  • earlier und later erlauben es, undo und redo mit Zeitangabe zu machen, z.B. earlier 5m (springe zu dem Zustand vor 5 Minuten)
  • Rechtschreibprüfung aktivieren (de_de für Deutsch einfügen):
    setlocal spell spelllang=en_us
  • Alle geöffneten Dateien, Fenster, Tabs, etc. speichern und wiederherstellen:
    mksession ~/.lastSession.vim
    vim -S ~/.lastSession.vim

Sneak Peak : HTTP 2.0

Wer ein wenig verfolgt, wie sich das Web entwickelt (z.B. indem man den W3C Blog in Google Reader abonniert!) hat vielleicht am Rande mitbekommen, dass die Spezifikation für HTTP 2.0 so langsam aber sicher beginnt.Google freut sich, denn das SPDY Protokoll wird hierfür als Grundlage genommen – auch wenn der finale Entwurf damit eventuell nicht mehr viel Gemein haben muss.
Jetzt ist natürlich die Frage, warum man einen Artikel über ein Protokoll schreiben soll das bisher noch nicht existiert. Den meisten Menschen ist es Bums, ob jetzt HTML über SPDY oder HTTP 1.1 versendet wird wenn Sie eine Abfrage abschicken. Hauptsache es geht.
Und die Anzahl der Webanwendungen, die aufgrund konkreter Limitierungen in HTTP nicht umgesetzt werden können sollte eher gering sein. Aber ehrlich: Da geht noch mehr. Seit HTTP 1.1 (1999) hat sich in der Netz- und Anwendungs- und Gerätewelt die ein oder andere Sache geändert (wer das noch nicht bemerkt hat soll doch über sein Tablet mal ‘mobile web’ googeln, sofern der WLAN Hotspot des Smartphones noch nicht den Akku gefressen hat).
Ich bin mir sicher (und hoffe es!), dass wir in Zukunft einen Aha-Effekt haben wenn wir auf das Jahr 2013 zurückblicken. Ungefähr so, wie wenn man heute mit einem älteren Firefox surft und sich wundert warum man damals so begeistert über dessen Geschwindigkeit war.
Da vieles bereits in ein paar Monaten obsolet ist, lass ich Protokolldetails aus und spreche nur ein paar Grundpfeiler des neuen Protokolls an. Die Drafts finden sich ja im Netz.
read more…

Nicht nur für mobile Endgeräte: Responsive-Web mit Media-Queries

Im Buzzwort-Bingo hat beim heutigen Blogpost ‘Responsive Web’ zugeschlagen.
Nachdem Tablets und Smartphones in sehr kurzer Zeit zur potentiellen Zielgruppe für die meisten Webapplikationen gelten, geistert ‘Responsive Web’ als Paradigma durch das Web – und meint damit eigentlich nur, dass man jetzt wirklich darauf achten sollte dass Webseiten auch auf kleineren Displaygrößen benutzbar sind. Man tut dem ganzen aber Unrecht wenn man es nur als Mobile-Thema abtut – auch wer ‘nur’ mit dem Desktopbrowser surft kann von den Techniken profitieren.
Kernelement des ganzen sind CSS Media Queries. Diese stellen im Grunde eine Verfeinerung der media-types da, die alle Browser (ausser IE, der kann es ohne Hacks erst ab Version 9) seit Urzeiten unterstützen. mit
@media print {
... CSS für Druckausgabe ...
}
@media screen {
... CSS für Bildschirmausgabe ...
}

… stellen unzählige Angebote bereits Ihre Druckseiten anders dar als die Browseransicht (z.B. andere Schriftgrößen).
Media-Queries gehen noch einen Schritt weiter: Mit ihnen kann man CSS in Abhängigkeit der Fenstergröße, der Bildschirmorientierung (z.B. wenn man das Tablet dreht), des Höhe/Breite Verhältnisses, der Pixeldichte und vielen mehr anpassen. Die Query
@media screen and (max-width: 1024px) {
... css ...
}

definiert z.B. Regeln,die nur dann gelten, wenn das Browserfenster 1024px klein ist und greift auch, sobald der Nutzer das Fenster kleiner zieht. Meistens sieht man so etwas wenn es darum geht Mobilgeräte zu unterstützen, z.B. indem Werbebanner anders angezeigt werden sobald ein Gerät mit bestimmter Pixeldichte und Auflösung auf die Seite kommt. Man muss sich jedoch bewusst sein dass auch ein Desktopbrowser mit den gleichen Eigenschaften gerade die Seite anschauen könnte. Einen eigenen Medientyp für Smartphones oder Tablets gibt es nämlich nicht.
Allerdings sind media-queries in variablen Umgebungen wie dem Desktop-Browser fast praktischer: Da die Fenstergröße hier von sehr groß bis klein variieren kann sollte man als Entwickler auf Skalierbarkeit achten. Das fängt bei Netbooks an, geht zu Nutzern weiter die auch mal ein einzelnes Fenster klein gezogen haben, bis zu der (nicht mal so unpraktischen) Split-View von Windows 8.
Hier kann man mit Media-Queries ohne viel Aufwand auf Größenänderungen reagieren und die Seite anhand des vorhandenen Platzes anpassen. Denkbar wäre es je nach vorhandener Breite z.B. Icons kleiner zu machen, Bereiche nicht mehr nebeneinander, sondern untereinander darzustellen, u.v.m.
Als Demo habe ich mal ein kleines (extrem gestyltes) Szenario erstellt. Zieht man das Result-Fenster kleiner, ändert sich die Icongröße, der Text wird abgeschnitten und nur bei Mouseover angezeigt.
Zwar ist das keine Wunderwaffe für alle Szenarien, gezielt eingesetzt kann man damit aber den vorhandenen Platz oft besser Ausnutzen – ohne massig JavaScript schreiben zu müssen.

Simpel, schnell und praktisch – Webapplikationen mit Flask erstellen

Auf dem Planeten der serverseitigen Webtechnologien herrscht eine unbegrenzte Artenvielfalt. In den verschiedensprachigen Ländern und Inseln (Java, Pythonien, etc.) tummeln sich viele kleine Technologievölker und verehren ihre vielen Frameworks, die allesamt unermesslich Mächtig und Allumfassend sind. Unerbittliche Kriege werden geführt, welches Framework und welche Sprache besser ist, Neulinge kämpferisch missioniert und für die eigene Sache geworben.
Manchmal wünscht man sich einen kleinen Kometen, der ein wenig für Ordnung sorgt. Daher will ich zumindest in Python einen kleinen Tipp geben, wenns mal weniger sein darf:
Zur Vorgeschichte: Auch ich bin auf den Raspberry Pi Zug aufgesprungen und finde die Kiste als kleinen Programmierspielkasten wirklich sehr spaßig. Da ich für kleinere Spielereien Python oder NodeJS bevorzuge, war ich also auf der Suche nach einem kleinen Python Webframework – direkt gegen die WSGI zu programmieren empfinde ich doch als etwas unkomfortabel. Nun ist es hier nicht so einfach, ein passendes Framework zu finden, das mir nicht von vornherein MV* aufdrängt (manchmal braucht man das nicht, ehrlich), klein ist und sich ‘elegant anfühlt’.
Nachdem die Liste im Python wiki überflogen habe, bin ich erstmal aus dem Raum gegangen und habe ein wenig geweint. Django, Pylon, Zope… das war mir alles (auf den ersten Blick) zu groß, zu Vereinnahmend. Klar, große Frameworks mit ORM, SOAP support, MVC und allen möglichen Schnittstellen, Helfern und Features haben Ihren Sinn, aber manchmal ist auch bei der Webentwicklung weniger mehr (und mit NodeJS habe ich ja auch in ein paar Zeilen einen HTTP Server laufen ohne vorher ein Projektskeleton auf der Konsole zu erstellen).
Dann bin ich über Flask gestolpert und allein schon das Beispiel auf der Startseite hat die Tränen etwas trocknen lassen. Ein paar Zeilen, schon hat man einen Webdienst am Laufen, ein paar Zeilen mehr und man kann komplexe Templates einbinden. Formulare, Uploads, Routing, etc. – alles ist vorhanden. Dabei ist es egal ob man ein paar Funktionen über Urls ansprechen will oder man auf Klassenbasierte Views setzt – das Framework skaliert hier recht gut mit (aber zugegeben: Letzteres haben andere Frameworks schon eleganter umgesetzt).
Für mich wird das wohl das Pythonframework meiner Wahl für kleine und mittelgroße Projekte im Web (auch wenn es natürlich auch andere Frameworks, wie z.B. bottle gibt, die ähnlich kompakt sind). Für wirklich größere Anwendungen mit vielen Schnittstellen, Ausgabeformaten, Lokalisierung, etc. würde ich dann allerdings doch auf Django oder Zope umsteigen, hier ergibt der Mehraufwand beim Konfigurieren und der Größe dann auch wirklich Sinn.

InGraph – The ultimate guide 4/5

Im vorletzten Teil unseres großen InGraph Reiseführers geht es nicht direkt um das Graphing an sich, sondern um das Monitoring Plugin check_ingraph, das InGraph mitliefert.
Viele Probleme sind zum Glück schnell erklärt, aber leider auch genauso schnell verursacht: Switch kaputt, Festplatte tot, Zahlendreher beim ‘kill’.
Gelegentlich gibt es aber Situationen, die nicht einfach ad-hoc erscheinen, sich für das Adlerauge eines Sysadmins jedoch am Graphen erkennen lassen. Wenn normale, zeitlich begrenzte Lastanstiege im Lauf der Zeit immer stärker ausschlagen, kann man das im Wochenverlauf des Graphen erkennen – noch bevor es kritisch wird.
Aber: Schön und gut wenn man solche Probleme an den Werten des Graphen erkennt – nur wer vergleicht schon jeden Tag die aktuelle Last mit der Last von letzter Woche (vor allem wenn die Maschinen keine Probleme bereiten) ?
Ich weiß wer: check_ingraph!
Der kleine Streber ist simpel, aber effizient: Das Plugin vergleicht bestimme Werte (hier z.B. die Serverlast) aus einem Interval mit den Werten eines Intervals aus der Vergangenheit und geht auf Warning/Critical wenn sich zu starke Abweichungen zwischen den Intervallen ergeben. Man kann so z.B. überprüfen, ob die Lastwerte der letzten 2 Stunden sich stark von den Lastwerten der letzten zwei Stunden vor einer Woche unterscheiden. Im Falle des Falles kann das Plugin dann präventiv darauf hinweisen, dass die Last im Vergleich ungewöhnlich hoch ist (selbst wenn Sie noch nicht im kritischen Rahmen für das System ist).
In der unteren Grafik ist ein check_ingraph Check grafisch dargestellt, der prüft ob die Werte der letzten Woche sich stark von denen dieser Woche unterscheiden:
Screen Shot 2012 11 22 at 11.49.05 AM
Der Aufruf ist dabei wie folgt:
check_ingraph -H http1 -S "Current Load" -P load1 -F average -f -360 -g -192 -s -192 -t 0 -w 10 -c 20
Und, damit ich nicht einfach die tolle Dokumentation kopiere, etwas genauer:

  • -H http1 -S “Current Load” : -H ist der Parameter für den Host, -S für den Service. Hier überprüfen wir also den Current Load check vom Host ‘http1’
  • -P load1 : Perfdaten können ja beliebig viele Parameter enthalten, hier entscheiden wir uns für die Werte, die als load1 bezeichnet sind
  • -F average: Gibt an, dass der Durchschnitt der Intervalle verglichen wird. Hier kann man auch ‘trend’ für Trendwerte, ‘stddev’ für die Standardabweichung oder ‘hw’ für Holt-Winters Forecasting verwenden
  • -f -360: Das erste Interval beginnt vor 15 Tagen  (= -1 (da in der Vergangenheit) * 15  * 24 (Stunden))
  • -g -192: Das erste Interval endet vor 8 Tagen
  • -s 192: Das zweite Interval beginnt vor 8 Tagen
  • -t 0 : Das zweite Interval endet genau jetzt
  • -w 10: Bei 10% Abweichung wird ein warning zurückgegeben
  • -c 20: Bei 20% Abweichung wird ein critical zurückgegeben

Das sind zugleich auch die wichtigsten Parameter für die meisten Checks.
Zwar ist das Plugin recht einfach zu bedienen, die Effizienz hängt jedoch stark vom individuellen Anwendungsfall ab. Hier ein paar Fragen, die man sich beim Konfigurieren gerne stellen kann:

  • Ist meine Intervallgröße passend gewählt? Zu große Intervalle neigen dazu Abweichungen zu verschlucken, zu kleine Intervalle geben kleinen Abweichungen zu viel Gewicht.
  • Ergeben meine Intervalle Sinn? Wenn ein Datenbankserver nur unter der Woche belastet wird ergibt ein Vergleich zum Vortag keinen Sinn, da Samstage und Montage immer Alarm schlagen werden.
  • Ergibt Forecasting einen Sinn? Wenn ja – ergibt es einen Sinn bei meinem Intervall?

Check_ingraph bietet damit eine sinnvolle Ergänzung zum visuellen Monitoring mit Graphen. Der ein oder andere schleichende Ausfall lässt sich beim richtigen Einsatz des Plugin früh erkennen und der Admin schläft damit mal wieder etwas ruhiger.
Also runterladen und ausprobieren!