Select Page

NETWAYS Blog

Grafana 8 ist da!

by | Jun 17, 2021 |

Ich weiß nicht, wie es euch geht — ich bin ein großer Grafana-Fan, vom ersten Moment an. Ob es nun darum geht, die per Icinga2 oder Prometheus gesammelten Daten darzustellen, das Smart Home zu visualisieren oder schlimmstenfalls den Gewichtsverlauf des Kindes für den Kinderarzt aufzubereiten: Grafana ist super. Wie Torkel Ödegaard in seinem Blogpost vom 8. Juni 2021 bekannt gab ist Grafana nun in Version 8 veröffentlicht.

Und dieses Update ist einen oder durchaus auch zwei Blicke wert: so wurden die verfügbaren Panels beispielsweise zum Teil überarbeitet und ergänzt — und allein für das „Status history panel“ habe ich direkt schon mehrere Anwendungsfälle im Hinterkopf. Außerdem ist das „Real-time streaming“ nun fester Bestandteil der Applikation und wurde erweitert: sende deine Updates über Websocket-Verbindungen aus MQTT-Datenquellen, über Streams von cURL/ Telegraf oder über den neuen Endpunkt /api/live/push in Echtzeit an deine Dashboards. Die Macher versprechen, das gehe ganz einfach — und erste Berichte Neugieriger bestätigen das bislang vollumfänglich.

Besonderes Augenmerk solltest du auch auf das „Alerting“ legen: dieses wurde vollständig überarbeitet und bietet nun eine übergreifende und durchsuchbare Oberfläche für Alarmmeldungen sowohl aus Grafana als auch aus Prometheus-kompatiblen Datenquellen, was neben Prometheus selbst auch Tools wie beispielsweise Cortex oder Loki einschließt. Und dass Alarme von Dashboards entkoppelt wurden und nun auch eine voll funktionsfähige API zur Verfügung steht dürfte ebenfalls so manchen überaus fröhlich stimmen.

Ich habe bislang zwei Instanzen — eine „gedockerte“ sowie eine über Pakete installierte — jeweils von 7.x auf 8.0.2 angehoben; verwendete Datenquellen waren Prometheus, Graphite und InfluxDB. Beide Upgrades liefen nahtlos durch, und auch wenn ich es nicht mit Zahlen belegen kann scheint die „Schwuppdizität“ (danke, Jan!) tatsächlich eine bessere zu sein als zuvor. Allerdings werde ich bei Gelegenheit ein wenig Zeit investieren müssen, um die einzelnen Panels zu prüfen und gegebenenfalls umzustellen — beispielsweise von „Graph (old)“ auf „Time Series“, so noch nicht geschehen. Aber da hältst du ohnehin bestimmt mehr Ordnung als ich, oder? 😇

Wenn du noch mehr über die neusten Änderungen erfahren möchtest, dann wirfst du am besten einen Blick in die Release Notes, schaust dich in der von Grafana bereitgestellten Demo auf play.grafana.org um — oder installierst das Update zeitnah. Es lohnt sich.

The Need For Speed

by | Mar 4, 2021 | ,

Eine Sache, mit der man sich immer mal wieder konfrontiert sieht, sind „langsame Webinterfaces“: in erster Linie ist solch eine Aussage eine sehr subjektive Sache, und ohne Zahlen ist sie als Bugreport nicht übermäßig belastbar. Doch es gibt viele Tools die dabei helfen, aus dem Gefühl eine nachvollziehbare — und somit idealerweise leichter behebbare — Tatsache zu machen.

Ich für meinen Teil fange da ja gerne an, indem ich die Developer Tools des Browers (Chrome zumeist) und gerne auch im „Inkognito Mode“ nutze; der Reiter „Network“ zeigt sehr detailliert, was in welcher Reihenfolge geladen wird, inklusive Request- sowie Response Headers.

TTFB - Time To First Byte

Reiter „Network“ der Chrome Developer Tools

In obenstehendem Beispiel wird ersichtlich, dass moderate Zeiten verwendet werden auf die Namensauflösung, den initialen Verbidungsaufbau, das SSL/TLS-Handling und den eigentlichen Download der Seite. Was ins Auge springt – und mit mehr als zwei Sekunden auch wirklich schon signifikant ist – ist „TTFB (Waiting)“.

TTFB steht für „Time To First Byte“ und definiert sozusagen die Zeit die mein Browser darauf warten muss, das erste Byte vom Webserver zu erhalten. Die Praxisrelevanz, insbesondere für Suchmaschinen-Rankings, ist nicht unumstritten; man muss sich auch nicht verrückt machen um eine TTFB von 400ms auf 200ms zu drücken (es sei denn, man sieht es als sportliche Herausforderung).

Bei vollen zwei Sekunden verlässt man jedoch die Komfortzone von „nicht relevant“; Wartezeiten im Sekundenbereich machen die User überaus unglücklich, und sie können Akzeptanz, Klicks und schlimmstenfalls jede Menge zukünftiger Besuche kosten. Es kann sich also durchaus lohnen, an dieser Stelle Zeit zu investieren. Einen guten, wenn auch recht strengen Einstieg in die Thematik bietet die Analyse von Google PageSpeed Insights; andere Anbieter stellen eigene Analysetools zur Verfügung.

Nun stellt jedoch nicht jede Umgebung einen Browser nebst Developer Tools bereit; das Kommandozeilen-Tool cURL erweist sich in solchen Fällen eventuell als nützliches kleines Helferlein. Wie ich im Zuge meiner Analysen lernen durfte unterstützt cURL nämlich formatierte Ausgaben. Um dem Timing-Problem auf die Schliche zu kommen erstelle ich mir eine Datei namens curl-timing-template mit folgendem Inhalt:

time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
———\n
time_total: %{time_total}\n

time_starttransfer entspricht hierbei „Time To First Byte“ und beinhaltet den Wert von time_pretransfer; die manpage von cURL gibt Aufschluss über alle verfügbaren Variablen sowie deren genaue Bedeutung (Stichwort „-write-out“). Im nächsten Schritt erfolgt der Aufruf der vermeintlich zu langsamen Adresse – natürlich unter Verwendung des eben erstellten Templates.

$ curl -w "@curl-timing-template" -o /dev/null -s https://example.com
time_namelookup: 0.002013
time_connect: 0.020424
time_appconnect: 0.076721
time_pretransfer: 0.076771
time_redirect: 0.000000
time_starttransfer: 13.158706
———
time_total: 13.158734

Autsch. Inzwischen liegt die Verzögerung bei ganzen 13 Sekunden – und es wird ersichtlich, dass das nicht durch die Namensauflösung (beispielsweise) verursacht wird. Die zielgerichtete Flaschenhalssuche kann nun also beginnen

Nicht selten sind Verzögerungen dieser Art abhängig von Uhrzeiten, Wochentagen oder ähnlichem; deshalb ist es praktisch, dass sich ein kontinuierlicher Test auf diese Art sehr einfach skripten, per Cron ausführen oder gar in andere Systeme integrieren lässt.

Daily business: der Editor vim

by | Sep 18, 2020 | ,

Es ist unerfreulich lange her, dass ich das erste Mal mit vim in Berührung kam — anno 1997, um genau zu sein, während meiner ersten verzweifelten Gehversuche in Sachen S.u.S.E. Linux. Oder war das noch vi? So irgendwie habe ich das Tool über die Jahre dann hinter mir her geschleift wie eine altmodische Handtasche, mich aber viel zu spät erst ernsthafter damit befasst — ein blöder Fehler, vor dem ich einige von euch ja vielleicht bewahren kann. Denn was viele (und gerade auch Neueinsteiger) gar nicht zu ahnen scheinen: vim ist üblicherweise auf Systemen vorhanden, kann viel, ist ziemlich cool und in der Handhabung auch gar nicht so widerlich, wenn man sich erst leidlich eingearbeitet hat.

Die Konfiguration des Editors erfolgt in einer Textdatei namens .vimrc, welche im $HOME-Verzeichnis des jeweiligen Nutzers liegen muss. Beginnen wir diese Datei mit nocompatible: denn ein compatible vim ist lediglich noch ein vi, sprich alle nützlichen Erweiterungen und Errungenschaften der letzten 20 Jahre würden abgeschaltet — und wer will das schon?

set nocompatible " Using vim settings and not vi

Widmen wir uns also einigen kleinen Kniffen, die mir für die tägliche Arbeit inzwischen unverzichtbar geworden sind: naturgemäß (und da ich gerade einen Haufen müffelnden Puppet-Codes in Richtung Ansible transportieren darf) editiere ich aktuell häufig an YAML-Dateien herum, und da ist das Thema „Einrückungen“ beispielsweise sehr relevant: YAML kennt, plump gesagt, keine Tabs, und so bewährt es sich sehr in der persönlichen .vimrc bereits festzuhalten, dass ein Tab beispielsweise durch zwei Leerzeichen ersetzt wird und Einrückungen ebenfalls zwei Leerzeichen betragen sollen. Protipp: Lasst außerdem über existierende Dateien ein :retab laufen, so dass alle eventuell vorhandenen Tabs gemäß eurer Konfiguration in Leerzeichen umgesetzt werden — die Einstellungen greifen nicht automatisch bei bereits bestehendem Text. Und: möchtet ihr YAML anders einrücken als beispielsweise C oder PHP, so beschäftigt euch mit den Möglichkeiten, die autocmd bietet!

set autoindent " Guess what?
filetype plugin indent on " Enable indenting for files
set backspace=indent,eol,start " Allow backspacing over indention/ line breaks/ insertion start
set softtabstop=2 " Indent 2 spaces when hitting TAB
set shiftwidth=2 " Indend 2 spaces when autoindent
set tabstop=2 " Show existing tab with 2 spaces width
set expandtab " Convert tabs into spaces

Gerade bei YAML hilft es mir häufig sehr wenn ich sehe, an welcher Stelle im Dokument ich mich gerade befinde; deshalb lasse ich mir die Zeilen durchnummerieren und mittels Unterstreichung die aktuelle Position anzeigen. Syntax Highlighting ist natürlich großartig, das will ich unbedingt, und durch eine einfache Anweisung sorgt zukünftig für die visuelle Hervorhebung zusammengehörender Klammern. Protipp: während number die Zeilen aufsteigend durchnummeriert, stellt relativenumber die Zeilennummern relativ zur aktuellen Position dar.

set number " Enable line numbers
syntax on " Set syntax highlighting
set showmatch " Show matching brackets
set cursorline " Highlight line under cursor
set cursorcolumn " Highlight column

Was bei der täglichen Arbeit hilft: eine Statuszeile, die mit genau jenen Informationen aufwartet, die persönlich hilfreich sind. In meinem Fall sind das Angaben wie Dateiname, beispielsweise, Dateityp oder an welcher Stelle — prozentual gesehen — ich mich innerhalb meiner Datei gerade befinde. Für euch sind hier vielleicht ganz andere Informationen wichtig, weshalb ich euch die Lektüre der entsprechenden Dokumentation ans Herz legen möchte.

set laststatus=2 " Show status line
set statusline=%t " tail of filename
set statusline+=\ %{&ff} " File format
set statusline+=\ %y " Filetype
set statusline+=\ %c, " Cursor column
set statusline+=%l/%L " Cursor line/ total lines
set statusline+=\ %P " Percent through file

Was ich wirklich zu lieben lernte: undo und redo. Die Basics kennen noch die meisten: u macht die letzte Änderung rückgängig, uuu die letzten drei und 5u die letzten fünf. Wirklich interessant wird das allerdings, wenn man es mit Zeiträumen verbindet: so macht earlier 2m (alternativ: ea 2m) die Änderungen der letzten zwei Minuten rückgängig, wohingegen later 5m (alternativ: lat 5m) alle Änderungen der letzten fünf Minuten wiederherstellt. Die Sache hat nur einen Haken: wie fast überall sind diese Statements nur innerhalb der laufenden Sitzung möglich; wird der Editor beendet und die gleiche Datei später erneut editiert, ist keine History der bisherigen Änderungen verfügbar.
Wenig überraschend lässt sich auch das anpassen: über set undofile weisen wir vim an, die Änderungen jeder Datei zu persistieren; vim tut das dann jeweils in Form eines hidden file an gleicher Stelle, was auf Dauer etwas unübersichtlich werden könnte. Erstellen wir mittels mkdir ~/.vim/undo ein eigenes Verzeichnis für Dateien dieser Art, können wir vim aber auch instruieren all diese Änderunsdateien dort vorzuhalten. Das erlaubt dann auch umfangreiche Zeitsprünge: ea 3d wird die Änderungen der letzten drei Tage rückgängig machen.

set undofile " Undo history even between sessions
set undodir=~/.vim/undo " All undo files in one directory

Zuguterletzt verpassen wir unserem vim ein hübsches colorscheme — eine Auswahl solch vordefinierter Farbschemata findet sich, in Abhängigkeit verwendeter Version und Distribution, üblicherweise in /usr/share/vim/vim$VERSION/colors/ in Form von .txt-Dateien. Ich entscheide mich für desert, ihr könnt euch aussuchen was euch am besten gefällt und versiertere Nutzer erstellen sich ihre colorschemes später dann ohnehin selber… Und wenn wir ohnehin gerade mit Farbgebungen spielen lassen wir uns die Zeilennummer spaßeshalber rot hinterlegen, während die Hervorhebung der Spalte in einem aufdringlichen hellen Magenta erfolgen soll. Einschub: eine Liste verfügbarer Farben lässt sich aus vim heraus unkompliziert mit dem Kommando :h cterm-color abrufen.

colorscheme desert " Setting nice colors
highlight CursorLineNR ctermbg=red
highlight CursorColumn ctermbg=LightMagenta

Es gäbe noch So! Viel! Mehr! Belassen wir es für heute mal dabei. Eine einsatzbereite exemplarische vimrc-demo findet ihr auf GitHub; sie ist nicht als „finale Fassung“ zu verstehen sondern vielmehr als Ausgangspunkt für die Erarbeitung einer persönlichen und über die Zeit immer perfekteren Version. Und vielleicht wollt ihr über die Kommentare verraten, ob Artikel dieser Art hilfreich für euch sind — und welche Einstellung, welches Plugin, welcher Kniff für euch unverzichtbar ist?

Trainings

Web Services

Events