pixel
Select Page

NETWAYS Blog

Neues von den Influxdays EMEA 2021

Auf den influxdays kündigt Paul Dix, CTO von InfluxData, einen neuen Core names iOx für influxDB an. Dieser Schritt löst spontan Unsicherheit aus. Hier ein paar Fakten um die Gemüter zu beruhigen:

InfluxDB 2.x Open Source wird, so wie es jetzt existiert, parallel mit regelmäßigen Point-Releases weiterentwickelt.
InfluxDB IOx wird SQL, InfluxQL und Flux unterstützen.
InfluxDB IOx wird in einem zukünftigen Release ein optionales Speicher-Backend für InfluxDB werden.
Die Implementierung durch Rust und Apache Arrow soll eine höhere Sicherheit erreichen. Auf Grund verschiedener Optimierungen am Speicherverhalten soll die Datenmenge verringert und gleichzeitig die Abfragegeschwindigkeit erhöht werden.
InfluxDB Enterprise-Kunden werden in der zweiten Hälfte des Jahres 2021 über eine kommerziell unterstützte Version von InfluxDB IOx und InfluxDB Enterprise verfügen.

Das war nicht das einzige Thema auf der online abgehaltenen Konferenz.
In dem ausgewogenen Programm konnte man sich anschauen, wie man mittels Telegraf Daten in Richtung influxDB schreibt. In einem anderen Vortrag ging es um Dashboards, Alerts und Tasks.

Ein Highlight war für mich der Talk von Aengus Rooney, der zwar trotz des Titels “What’s New with Grafana and InfluxDB” erstaunlich wenig Neuerungen gezeigt hat, jedoch mit einem längeren Hands-On die Möglichkeiten von Grafana anhand eines selbst erstellten Handels Terminals für Kraken/Bitcoin demonstriert hat.

Alle Aufzeichnungen der Konferenz werden ab 31. Mai veröffentlicht. Man findet sie, wie auch die Videos vergangener Konferenzen, auf den Seiten der influxdays und auf youtube.

Wer mehr über influx und die Möglichkeiten erfahren möchte kann sich auch bei NETWAYS im Rahmen eines zweitägigen Trainings informieren.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Warum wir in den NETWAYS-PostgreSQL-Trainings eigentlich nur “psql” nutzen

Wieder einmal PostgreSQL Schlung (Fundamentals und Advanced) durchgeführt.
Wieder einmal wurde nach GUIs gefragt.
Wieder einmal haben wir uns dann letztlich doch fast auf psql beschränkt.

Warum ist das so?

 

GUI vs. TUI – the eternal battle

GUIs werden i. A. als “benutzerfreundlicher” dargestellt.

Ich persönlich wiederum finde es ganz schrecklich, dauernd zur Maus greifen zu müssen, um irgendeine Aktion auszulösen, für die die Entwickler keinen oder einen grauenhaften Shortcut konfiguriert haben… für mich sind GUIs also eher weniger benutzerfreundlich.

Mir ist auch klar, dass es beileibe nicht jedem Menschen so geht, und die Gewöhnung spielt dabei sicher auch eine enorme Rolle.

“The usual suspects”: die üblicherweise genannten Gründe pro GUI/TUI

GUI:

  • intuitiver zu bedienen
  • “gewohnte” Optik
  • bessere Übersicht über Ergebnisse von Queries

TUI:

  • steht vom Funktionsumfang dem GUI kaum nach
  • funktioniert auch bei langsamer Verbindung (“Zug”)
  • kann gescriptet werden

Es gibt aber einige durchaus schwerwiegende Gründe, warum ich bei Trainings so einen großen Wert auf psql lege.

“The killer arguments”: warum psql elementar ist

Die Lernschwelle ist bei GUIs unnötig hoch

  • Jedes GUI sieht letztlich (ein wenig) anders aus und es gibt einfach zu viele
  • Um eine erste Verbindung herzustellen, muss im GUI erst ein Server definiert werden, mit jeder Menge Parametern, u.a. einer Netzwerkverbindung
    • dafür muss aber erst ein Konfigurationsparameter (listen_addresses=) gesetzt werden, was wiederum erst deutlich nach dem ersten “Reinschnuppern” behandelt wird…
    • Im Terminal hingegen (wo ich ja gerade den DB-Server installiert habe) komme ich per psql direkt an die DB (wenn ich der OS-User postgres bin…)
  • Objekte anschauen (“Erste Schritte”):
    • TUI: nach Eingabe von psql kann ich einfach z.B. \dt eingeben und bekomme alle Tabellen gelistet, \d nachnamen zeigt mir instant die Tabellenstruktur, dazu Indexe, Primär-/Fremdschlüssel etc. an
    • in allen GUIs muss ich dafür erst durch einen Baum klicken, in pgAdmin4 z.B. Servergruppe -> Server -> Datenbank -> Schemas -> ‘public’ -> Tabellen

Die (online-)Trainings-VMs sind nur per ssh und Webinterface erreichbar

  • um da per GUI dranzukommen, müssten also die Teilnehmer erstmal Software auf ihren (privaten oder dienstlichen) PCs installieren…

Viel entscheidender ist aber m.E.:

psql ist für den PostgreSQL-DBA, was vi für den U\*\*X-Admin ist:

  • auf jeder PostgreSQL-Maschine verfügbar
  • minimalistisch, aber gleichzeitig unglaublich leistungsfähig
  • ich muss das sowieso zu nennenswerten Teilen beherrschen, z.B.
    • für den Fall, dass mir die Firewall einen Streich spielt
    • wenn ich mal als Superuser in die DB will/muss (max_connections= ausgeschöpft)
    • um Dinge zu scripten

Wenn mir jemand erzählt, er oder sie sei UNIX-Admin, dann aber einen nano benutzt, bin ich sofort (zurückhaltend ausgedrückt) skeptisch.

Ähnlich ist es mit psql. Ich muss (als DBA) sowieso wissen, wie ich damit z.B. Objekte anzeigen, DDL einspielen, ggfs. mal eine Stored procedure umschreiben etc. pp. kann. Wenn ich die Software also sowieso (halbwegs) beherrschen muss, kann ich sie doch auch gleich benutzen? Ich sehe nur wenige Szenarien, in denen ein(e) DBA von einem GUI profitieren würde.

Ein(e) AnalystIn hingegen wird die DB wahrscheinlich eher direkt an ein Reporting-Tool oder M$ Excel anbinden wollen.

Bleibt der/die (SQL-) EntwicklerIn. Ja, fair enough, da sehe auch ich gewissen Charme (üblicherweise F5 drücken, um das SQL im Fenster (erneut) laufen zu lassen). Auf der anderen Seite ist derselbe Effekt in psql durch Eingabe von \e zu erreichen, und da kommt ein vi. Der ist ja bekanntlich minimalistisch, aber… 😉

Und ob man DDL jetzt per GUI erzeugen sollte, darüber scheiden sich ja auch die Geister… IMHO eher nicht.

Fazit:

“I never leave the house without it!”

psql ist der vi(m) der PostgreSQL-Welt. Unfassbar flexibel und leistungsfähig, immer verfügbar und dadurch absolutes “Pflichtprogramm”.

P.S.

Ich habe mal jemanden kennengelernt, der eine U\*\*X-Consulting-Firma betrieb und lt. eigener Aussage nur Menschen anstellte, die den ed beherrschen. So weit würde ich dann auch nicht gehen… 😉

P.P.S.

Vielleicht hat die Abneigung gegen TUIs was mit Oracles SQL*Plus (TM) zu tun? Wäre absolut nachvollziehbar, das fasse ich auch nur mit der Kneifzange an…

 

Über den Author:

Gunnar “Nick” Bluth hat seine Liebe zu relationalen Datenbanken Ende des letzten Jahrtausends entdeckt. Über MS Access und MySQL 3.x landete er sehr schnell bei PostgreSQL und hat nie zurückgeschaut, zumindest nie ohne Schmerzen. Er verdient seine Brötchen seit beinahe 20 Jahren mit FOSS (Administration, Schulungen, Linux, PostgreSQL). Gelegentlich taucht er auch tiefer in die Programmierung ein, so als SQL-Programmierer bei der Commerzbank oder in App-Nebenprojekten.
Philipp Dorschner
Philipp Dorschner
Developer

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kolleg:innen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Entwicklerazubis: Jahr 1, das Projekt

Man bekommt nicht immer das, was man will… außer, man ist bei NETWAYS Azubi!

 

Mein erstes Jahr bei NETWAYS ist fast vorüber, und meine jugendlichen Ambitionen haben den Wunsch in mir erweckt, mit den beiden anderen Dev-Azubis meines Jahres, Loei und Niko, ein eigenes Projekt zu übernehmen, um unsere erlernten Fertigkeiten zu prüfen, eine Übersicht davon zu bekommen, auf welchem Stand wir alle sind, den ein oder anderen Trick voneinander aufzuschnappen und eigenverantwortlich und kooperativ ein Projekt zu vervollständigen. Und alles, was es gebraucht hat, um diesen Wunsch zu erfüllen, war diese Idee zu pitchen und klar und deutlich zu vermitteln, warum dieses Interesse besteht, und was wir uns davon erhoffen. Meine Vorgesetzten scheinen von der Idee zumindest angetan genug gewesen zu sein, dass wir drei Wochen eingeräumt bekommen haben, um uns um dieses Projekt zu kümmern. Danke, NETWAYS!

Die Aufgabe klingt einfach, hat es aber doch durchaus in sich – aus Berichten in Icinga sollen PDFs generiert werden. Die Funktionalität ist schon vorhanden – unsere Aufgabe ist es, den Benutzern mehr Features zur Verfügung zu stellen, damit man eigene Anpassungen an dem Aussehen der PDFs vornehmen kann. Das Schöne an dieser Aufgabe ist die Breite der Elemente und Bereiche, welche eine Rolle dabei spielen. Icingaweb, PHP, HTML, CSS, Google Chrome… es ist in gewisser Art und Weise eine große Reise in das Unbekannte, und natürlich können wir alle drei uns nicht sicher sein, welche Probleme und Hürden sich uns in den Weg stellen werden, und wie die zündenen Ideen kommen, die uns helfen, diese Hürden zu überwinden.

 

Boo

Much better

Und zündende Ideen gab’ es bereits! Ein Beispiel: Google Chrome baut sich aus HTML-Code die PDFs zusammen, lässt sich es aber nicht nehmen, automatisch generierte Header und Footer anzufügen, mit Seitenzahl und Datum. Das ist natürlich ein Element, welches wir gerne unter Kontrolle hätten! Der erste Hack, mit dem ich mich über diese Hürde bewegt habe, ist ein CSS-Styleelement an den übergeben HTML-Code anzufügen. Das ist in seinem momentanen Zustand natürlich noch etwas unschön gelöst, wenn einfach nur der HTML-Code um ein fest eingebautes Codeelement erweitert wird, aber wir haben einen Einstiegspunkt, einen Ansatz, mit der wir weiterbauen und -basteln können.

 

Scheue Dich vor Fragen nicht!

Auch wenn der Kerngedanke dieses Projekts natürlich daraus besteht, dass wir uns selbst beweisen, spricht natürlich Nichts dagegen, bei Fragen, die aufkommen, einen der zahlreichen Experten die NETWAYS hat zu involvieren. Was Benutzeroberflächen angeht, ist bei uns UX-Designer Florian der Ansprechpartner Nummer 1. Wir haben uns zusammengesetzt und konnten ihm live beim Bauen eines Mockups in Sketch zusehen. Eine Gelegenheit, durch die großen Augen, die wir gemacht haben, auch etwas über grundlegende Designansätze in Icingaweb zu lernen, und Grundsätze bezüglich Design. Mit diesem Wissen können wir erstmal diesen Pfad weiter selbst beschreiten, aber natürlich werden wir viel Rücksprache führen. Nur weil man bisher nicht dazu kam, sich extensive Kenntnisse in einem Bereich selbst anzueignen, heißt das nicht, dass man dieses Wissen, wenn es einem zur Verfügung steht, nicht nutzen kann. Und immer schön dran denken, selbst den Fundus an Talenten zu erweitern.

A mockup of things to come…

 

Kooperatives Kodieren

Einer der in meiner Einleitung angesprochenen Tricks, den ich einfach für neat halte, und sehr dem Spirit dieses Projektes entspricht, ist die Möglichkeit in git Co-Authoren einzutragen. Dafür muss man in der commit message einfach

 Co-authored-by: Name <e-mail>

angeben, und git verlinkt automatisch zwei Autoren für diesen commit. In diesem Fall meine beiden Kollegen bei diesem Projekt. Gute Arbeit, Jungs!

Da kann man ruhig mal klatschen! ?

 

Willst Du uns vielleicht nächstes Jahr bei dem nächsten Entwicklungsprojekt behilflich sein? Dann raus mit Deiner Bewerbung an NETWAYS! Wir freuen uns schon auf dich!

Henrik Triem
Henrik Triem
Developer

Henrik is Anwendungsentwickler in Ausbildung, verhindeter Rockstar, kaffeegetrieben und Open Source-begeistert. Zuhause lässt er es auch mal ruhiger mit Tee angehen, entspannt an Klavier oder Gitarre, erkundet neue Musik oder treibt sich mit seinen Freunden in Deutschland herum.

HAProxy und SQL Grants

In diesem kurzen Beitrag will ich auf einen Fallstrick im Bezug von HAProxy und SQL Backends wie MySQL oder MariaDB eingehen. Speziell geht es um Grants und die damit verbunden Quell Hosts. Diese werden bei einem Standard Setup mit HAProxy durch die IP des Proxys ersetzt. Solange man sich in dem selben Netz wie die DB Server und dem Proxy befindet und die Host-Beschränkungen nicht all zu streng sind, kann es gut sein, das man dieses Szenario nicht erreicht. Sobald die Verbindungen aber Netz übergreifend erfolgen und die Grants damit umso wichtiger sind, kommt das Detail zum Tragen und stellt einen vor neue Herausforderungen. Dafür gibt es an sich schon etwas länger das Proxy Protokoll, welches aber erst nach und nach in mögliche Backend Software implementiert wurde/wird. Bei MariaDB war es mit der 10.3.1 z.B. erst Ende letzten Jahres soweit.
Die Arbeitsweise des Protokolls beschreibt sich einfach gesagt so, dass mit dem Aufbau der Verbindung zuerst ein zus. Header geschickt wird, in dem die IP des Quell Hosts bekannt gegeben wird. Dazu muss das Backend jedoch von der IP des HAProxys das Proxy Protokoll erlauben. Das Ganze drum rum kann mit Seiten über weitere Details und Sicherheit befüllt werden. Damit verschone ich Euch aber und weise nur auf eine schlichte Zusammenfassung im Blog von HAProxy hin.

Gnocchi und Archiv Policies

Gnocchi ist eine time series database die aus dem OpenStack Projekt hervorgegangen ist. Da Gnocchi erst 2014 entstanden ist, wurde versucht die Schwächen vorhandener Lösungen zu umgehen. Im Vergleich fallen mir vor allem folgenden Features auf:

  • Mandantenfähigkeit
  • Skalierbarkeit
  • Hochverfügbarkeit
  • REST Interface (HTTP)
  • Unterstützung moderner Backends wie Ceph (librbd), Swift und S3
  • OpenSource

Ein weiters Feature ist die Unterstützung von archive policies. Diese legen fest wie lange und in welcher Granularität Metriken vorgehalten werden. Zusätzlich kann auch die Art der Aggregation definiert werden. Sendet man den unten stehenden json Text per HTTP an /v1/archive_policy wird z.B. eine Policy angelegt die Metriken mit einer Granularität von 5 Minuten für 62 Tage speichert und dafür 17856 Punkte benötigt (12 Metriken je Stunde * 24 Stunden * 62 Tage = 17856). Zusätzlich werden die Metriken in aggregierter From  für 365 und 3650 Tage gespeichert.
 

{
  "name": "router-metriken",
  "back_window" : 0,
  "definition" : [
    {
      "points" : 17856,
      "granularity" : "00:05:00",
      "timespan" : "62 days, 0:00:00"
    },
    {
      "points" : 8760,
      "granularity" : "1:00:00",
      "timespan" : "365 days, 0:00:00"
    },
    {
      "points" : 3650,
      "granularity" : "24:00:00",
      "timespan" : "3650 days, 0:00:00"
    }
  ],
  "aggregation_methods" : [
    "min",
    "max",
    "mean",
    "sum"
  ]
}

 
Welche archive policy für einzelne Metriken angewendet wird kann über rules bestimmt werden. Neue Metriken werden per Regex geprüft und ggf. einer Policy zugewiesen. Treffen mehrer Regeln greift der längste Regex. Mit der folgenden Regel werden alle Metriken die mit router beginnen zu der oben definierten Policy hinzugefügt.
 

{
  "archive_policy_name": "router-metriken",
  "metric_pattern": "router.*",
  "name": "router-metriken"
}

 
Mein erster Eindruck von Gnocchi ist durchaus positiv und mit den genannten Features kann sich die OpenStack Lösung von der Konkurrenz abheben. Aktuell ist Gnocchi wohl am besten für die Bedürfnisse von OpenStack ausgelegt. Es gibt aber auch Integrationen zu collectd, statsd, Icinga und Grafana.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.