Seite wählen

NETWAYS Blog

Mermaid zum Visualisieren von Graphen

Gerade im Umfeld von Logstash-Pipelines steht man oft vor dem Problem, wie die einzelnen Code Teile zusammenhängen. Dafür hat sich für mich Mermaid bewährt.

Was mir an Mermaid besonders gefällt ist, dass man mit einer relativ einfachen Syntax Graphen definieren kann, die dann in verschiedenen Systemen gerendert werden können. Das kommt meiner Arbeitsweise beim Schreiben von Doku entgegen. Bietet aber auch die Möglichkeit, Konfiguration einfacher automatisch generieren zu lassen. Die Erstellung solcher Abhängigkeiten gestaltet sich damit einfacher als z.B. mit Graphviz. Klar sind die Möglichkeiten etwas eingeschränkt, aber wenn sie genau das bieten, was man braucht, dann stört das auch gar nicht.

Ich nutze den Mermaid Live Editor mittlerweile auch gern während unserer Elastic Stack Logmanagement Schulungen um interaktiv zu zeigen, wie sich eine Pipelinekonstruktion entwickeln kann. Natürlich kann man damit auch den Zusammenhang zwischen Komponenten eines Elastic Stack oder ähnliches wunderbar visualisieren.

Als einfaches Beispiel sei hier ein Setup gezeigt, das in einer Pipeline sowohl syslog als auch journald Events annimmt. Der Header und das Format unterscheiden sich, aber der eigentliche Inhalt ist gleich. Ausserdem sind hier noch zwei Pipelines, die Secure-Log und Cron Lognachrichten weiter zerlegen. Alle anderen Nachrichten werden nur vom Header befreit und gehen vorerst direkt weiter an Elasticsearch.

graph TD
    A[shipper] -->|syslog| B[syslog]
    A --> C[journald]
    B --> D[secure]
    C --> D 
    D --> E[forwarder]
    A --> E
    B --> E
    C --> E
    B --> F[Cron]
    C --> F
    F --> E

Direkt gerendert sieht das dann so aus:

Für die ganz Neugierigen sei noch gesagt, dass die Pfeile hier jeweils eine Übergabe per Redis-Key symbolisieren sollen. Der Übersicht halber wurde hier nur der syslog Key beschriftet. Man kann sich aber vorstellen, dass das entsprechend einfach auch mit den anderen funktionieren würde. Mermaid kümmert sich dann dabei darum, dass der Graph immer wieder so umgebogen wird, dass alles schön lesbar ist.

Die Namen der einzelnen Pipelines, bzw. deren Beschriftung, muss nur einmal angegeben werden. Der Mermaid-interne Name, hier immer nur ein Buchstabe, kann dann immer wieder verwendet werden, ohne den Namen jedesmal wieder anzugeben. Natürlich kann man sich auch die Zeit nehmen, die internen Namen sprechender zu gestalten, was durchaus für Übersicht sorgt.

Mermaid ist ein JS Projekt, das sich auch in andere Tools wie Wikisoftware integrieren lässt.

Und, Spoiler Alert!, Pipelines, die hier dargestellt werden, befinden sich auch recht aktiv in Entwicklung und sind für die Veröffentlichung geplant. Es gibt jetzt mit dem Elastic Common Schema endlich eine Nomenklatur für Felder, die es erlaubt, wiederverwendbare Pipelines zu bauen. Bei früheren Versionen war ja immer das das große Problem. Wenn jedes Setup ein Feld für den selben Inhalt beliebig benennen kann, wird’s schwierig mit dem wiederverwenden von Code. Das ist jetzt vorbei und wir versuchen, entsprechend Code zu produzieren.

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Input/Output Muster visualisieren

In modernen Storage-Systemen wie Ceph hat man in der Regel verschiedene Arten und Möglichkeiten Caching zu realisieren. Bei einem einfachem Ceph Setup ist für gewöhnlich ein Schreib-Cache vorhanden der aus SSDs besteht. Verwendet man Ceph in Kombination mit QEMU/KVM so kann zusätzlich noch der sogenannte RBD-Cache aktiviert werden welcher bereits aus den Virtualisierungshosts Daten puffert.
Natürlich wird durch das Puffern der Daten das Lese- und Schreibmuster auf den endgültigem persistentem Datenträger (meist SAS- bzw. SATA-Platten) immer undurchsichtiger.
Mit Hilfe von blktrace kann man die Lese- und Schreibzugriffe auf dem Datenträger lokalisieren und seekwatcher erstellt einem ohne großen Aufwand auch noch ein Video davon.

# yum/apt-get install blktrace seekwatcher mencoder
# blktrace -d /dev/sda -o find
# seekwatcher -t find.blktrace.* -m -o find.mpg

Der erste Befehl schreibt alle aktuellen Aktivitäten von sda nach find.blktrace.x Dateien. seekwatcher erstellt anschließend ein Video.
Das erste Video zeigt ein `vagrant up` einer icinga2-Box. Die Box wird langsam heruntergeladen, das Image nochmals kopiert und dann geht es los mit der Installation. Das zweite Video zeigt ein `find /`. Jedes Quadrat zeigt einen Sector an und wird farbig sobald IO auf diesem stattfindet. Dieser blendet sich anschließend langsam wieder aus. Ich finde in diesen beiden Fällen kann man die IO-Muster schön interpretieren.


Für einen besseren Vergleich kann man sich die beiden Fälle auch in einer Grafik anzeigen lassen. Hat man noch Datenträger die sich drehen ist hier unter anderem der Seek Count interessant, aber seht selbst.
IO-Vergleich find / vs vagrant up

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.