From Monitoring to Observability: Distributed Tracing with Jaeger

From Monitoring to Observability: Distributed Tracing with Jaeger

Modern cloud environments and microservice architectures need a changed mindset when it comes to monitoring. Classic host/service object relations are not always applicable, containers run in Kubernetes are short lived, and application performance within distributed networks is hard to monitor. Especially with applications running millions of operations, where to start the root cause analysis for slow client responses in your web shop? Is it just slow connections to MySQL, or does the application’s debug log slow down the entire fleet?

This is where observability with tracing comes into play. In the cloud native space, OpenTracing evolved as vendor neutral standardized API including client instrumentation. Famous tools are Zipkin and Jaeger which was contributed from Uber to the CNCF.

Let’s have a look into Jaeger today.

 

Getting Started

The easiest way to try Jaeger is with using the Docker container explained in the documentation.

docker run -d --name jaeger \
  -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14268:14268 \
  -p 9411:9411 \
  jaegertracing/all-in-one:1.16

Navigate to http://localhost:16686 to get greeted by Jaeger.

 

Try it

A sample application is available as container. I’m using a modified port mapping with 8081-8084 here since port 8080 is already assigned.

docker run --rm -it \
  --link jaeger \
  -p8081-8084:8080-8083 \
  -e JAEGER_AGENT_HOST="jaeger" \
  jaegertracing/example-hotrod:1.16 \
  all

Navigate to http://localhost:8081 and click the buttons to order some cars.

Within Jaeger itself, start analyzing the traces and for example learn that Redis runs into timeouts quite often delaying the HTTP responses to the clients.

 

Traces for applications

Jaeger provides officially supported client libraries for Go, Java, Python, NodeJS, C/C++, C#/.NET, others are in the making. Let’s see if we can add it into Icinga 2 and do some tracing here.

First off, clone the repository, build and install the client libraries. You’ll need CMake, a C++ compiler, etc. – basically everything which is required for Icinga 2 too and documented here. In this example, I’m compiling on my Macbook. There are additional libraries and headers required. Hint: Boost 1.72 has a bug which needs a patch.

brew install yaml-cpp thrift 
git clone https://github.com/opentracing/opentracing-cpp && cd opentracing-cpp
# 1.6.0 doesn't work atm
git checkout v1.5.1
mkdir -p build && cd build
cmake ..
make && make install
cd ..

Then clone, cmake, make, install.

git clone https://github.com/jaegertracing/jaeger-client-cpp && cd jaeger-client-cpp
git checkout v0.5.0
# regenerate thrift headers for 0.11.0
find idl/thrift/ -type f -name \*.thrift -exec thrift -gen cpp -out src/jaegertracing/thrift-gen {} \;
mkdir -p build && cd build
cmake ..
make && make install
cd ..

In order to add Jaeger into Icinga 2, there are the following steps necessary:

  • Add CMake functions to lookup yaml-cpp, opentracing, jaeger headers and libraries
  • Optionally enable Jaeger tracing code, link the icinga2 binary against it
  • Add a new tracer into the Config Compiler CLI command to measure the timing points

The majority of development time today was to resolve compile and linking issues, adding spans and traces is really simple. You can follow my progress in this Icinga PR – developers, get started wtih the client libraries and help your colleagues with enhanced observability!

 

Conclusion

Tracing application performance, cluster messages, end2end tests and any sort of event span provides valuable insights for both, devs and ops. With the new cloud native landscape evolving fast, we have additional possibilities to analyze our environments. Next to the now standardized tools for parsing and ingesting logs with Elastic Stack or Graylog, tracing has found its place in the observability stack.

Jaeger Tracing also is part of the GitLab observability suite which will be moved to the free core edition in 2020. Metrics, logging, alerts and tracing are key elements in modern cloud environments. Prometheus monitors everything from classic load checks to Kubernetes containers, Jaeger provides application performance insights and on top of that, Grafana combines the view on problems and trends. You can learn more about GitLab’s vision here.

Exploring these cool new features in GitLab are our mission in future trainings and workshops, watch this space in 2020!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Text-Utils unter Linux – Wer kennt sie?

Bei aller Automatisierung, Systemmanagement oder Cloud und Log-Management  ist oben genannte Frage berechtigt.
Ich persönlich, stelle als Support-Engineer immer wieder fest, wie wichtig das eine oder andere Text-Util von Linux auf der Kommandozeile ist, deswegen möchte ich hier mal ein paar  Text-Utils und Anwendung vorstellen:

cat & split
Erklärung: Hier wird eine 100MB große Datei angelegt, die in 14MB große einzelne Dateien zerlegt wird und danach wieder zusammengefügt wird.
dd if=/dev/urandom of=test1.big count=100 bs=1M
split -b14m test1.big
cat x?? > test2.big
md5sum test.big test2.big

tac
Erklärung: Hier wird einen Liste der letzten installierten Pakete ausgeben und anschließend herumgedreht, damit das letzte installierte Paket unten in der Liste steht.
rpm -qa --last | tac

cut
Erklärung: Hier werden die ersten 25 Bytes aus Logfile messages vom Seiten-Anfang herausgeschnitten, setzt man das Minus vor die Zahl wird alles nach den 25 Byte herausgeschnitten
cut -b25- /var/log/messages | sort

cut & paste
Erklärung: Ausschneiden von Textausschnitte aus einer Datei, in einzelne Dateien kopiert und dann wieder zusammen in eine Datei zusammengeführt.
cut -d: -f1-3 /etc/passwd > spalte1-3
cut -d: -f4- /etc/passwd > spalte4-7

Wieder  zusammensetzen
paste -d: spalte1-3 spalte4-7

sort mit du
Erklärung: Hier wird mit du (disk usage) die Größe der Verzeichnisse ausgegeben und sortiert
du -mx / | sort -n
Hier ist der Beitrag Disk Usage (du) von mir, wenn jemand das Tool noch nicht kennen sollte.
Noch ein Beispiel:
sort -t : -k 3n /etc/passwd
Erklärung: Hier werden die User in der passwd nach der id sortiert aufsteigend sortiert, Trenner ist der Doppelpunkt.

column
Erklärung: Hier werden die IP-Routen schön in Spalten angezeigt um die Lesbarkeit zu verbessern.
ip r s | column -t

pr
Erklärung: Hier wird die Ausgabe des Textes zur besseren Lesbarkeit oder zum Ausdrucken aufbereitet und mit Seitenzahl angezeigt
wget -q -O - www.gnu.org/licenses/gpl-3.0.txt | pr | less

Alle Text-Utils können noch mehr, dazu bitte die Man-Pages zu Gemüte ziehen, oder vielleicht unsere Linux-Schulung im Bereich Trainings buchen.

In diesem Sinne Viel Spaß beim ausprobieren!

Johannes Carraro
Johannes Carraro
Support Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Introduction to SVG: The Basics

This entry is part 1 of 1 in the series Introduction to SVG

Lately I’ve been spending a some time building SVGs.
When I told my colleagues about what I was doing they asked me to write a short guide about what exactly that is and what you can do with it.
Since I got those questions, i thought that might be interesting for others out there, so here goes nothing:

First of all: what is SVG?

Just like JPEG or PNG, SVG is an image format, which lets us display images or graphics on the web.
SVG stands for ‘Scalable Vector Graphics’ – You might have heard about vectors in a different context already, like maths class or physics maybe?
The concept is the same: there is a direction and a force which helps to describe a path.
This means, that those graphics do not consist of fixed pixel values, but instead they’re a set of directions for whoever renders it (usually the user agent / browser) to follow.

SVG is written in a format that resembles XML, which means you have your image in a human readable plaintext file!

Why does that make it special?

The fact, that the graphics are made up with vectors comes with a bunch of useful qualities:

  • Scalability: It doesn’t matter, if you make the image 30x30px or 3000x3000px, it will stay sharp
  • Responsiveness: Because of its’ scalability you can have it take up whatever space you need it to
  • Programmable: Since your image is basically a text file, you can modify it programmatically as well, which gives it a flexibility unmatched by other common options.
  • Performance: Since we’re not sending out a binary blob of pixels but a text file, there is next to no loading time for the images.

The most common use cases are logos, icons and icon fonts, animations and diagrams.

What does it look like?

This is a simple svg, which we will be building together over the course of this blogpost:

First we define a simple 20×20 “coordinate system”, where 0,0 is in the top left corner.
In the viewBox we define what part of the SVG we will see when it is rendered. Positive x values move to the right and positive y values move downwards.
<svg viewBox="0 0 20 20"></svg> For a better understanding of the slightly mind-fucky topic of the viewBox property, check this out.

 

To start of with we want to draw the head:
For that we just use a <rect> element to draw a rectangle that fills the entire space.
<rect class="body" width="20" height="20"></rect>

 

The eyes consist of two <circle> elements that we position with cx and cy and give them a radius r of 1 unit.
<circle class="eye" cx="5" cy="15" r="1"></circle>
<circle class="eye" cx="15" cy="15" r="1"></circle>

 

When you put everything together the code for it looks something like this:

<svg viewBox="0 0 20 20">
  <rect class="body" width="20" height="20"></rect>
  <circle class="eye" cx="5" cy="15" r="1"></circle>
  <circle class="eye" cx="15" cy="15" r="1"></circle>
</svg>

So far we’d only have a black box, but as you might have noticed, I also added the class attribute into the elements.
This is for styling the SVG via CSS.
It is also possible to style the elements within their tags, but using CSS is usually preferred, since it makes it possible to style images with user themes as well!
This is the CSS:

.eye {
fill: #444;
}

.body {
stroke-width: 2;
stroke: #444;
fill: #f15a22;
}

 

The drawn lines can be edited with stroke  and if the fill attribute changes the colour that fills up the shape:

You can find the pen here.

Drawing our own images

Combining shapes is all nice and cool, but there are a lot more you can do with SVGs – for example create your own shapes.
We can do this with the path element. For it to know what to draw it needs the d attribute in which we can describe the path of the element.

<path d="M1,2 l4,4 h10 l4,-4 v17 h-18 Z"></path>

 

The d attribute has a syntax consisting of a few letters and a lot of numbers, that can look quite scary and unreadable at first, but when we break it down, it should look a lot clearer:
The letters are the commands and the numbers are their passing values.

 

M is the first command used. It’s the move command – so what it does is move the cursor to the position indicated by the numbers and is the starting point for our path.
M1,2 means it starts one unit to the right and two down.

 

The letters for the commands can either be uppercase to indicate absolute values or lowercase to indicate values that are relative to the last point we drew.
While m4,0 means “Move the cursor 4 units to the right”, M4,0 means move it to the position 4,0.

Basic commands for drawing lines

The next commands we want to look at describe straight lines:
L: any direction
H: horizontal
V: vertical
Z: last element for closing path

 

<path d="M1,2 L5,6 H15 L19,2 V19 H1 Z"></path>
We’re starting at M1,2.
First line is to position 5,6, so 4 to the right and 4 down with L5,6.
Then a horizontal line to H15.
Another line that goes up and to the right with L19,2.
Down to y value 19 with V19.
All the way left to x position 1 with H1
Finally, we close the path with the Z command.

 

It’s entirely up to you if you want to draw with relative or absolute values, in a 20×20 grid those two would draw the same image:

<path d="M1,2 l4,4 h10 l4,-4 v17 h-18 Z"></path>
<path d="M1,2 L5,6 H15 L19,2 V19 H1 Z"></path>

Adding the path together with the circles from our first head and applying the CSS again the image looks like this:

You can find the pen here.

Getting those round corners

The little fox looks a little square still, so we want to edit it to give it some round cheeks.

For this we use the q command, which stands for ‘quadratic curve’.

The q command requires two points, the one around which the curve should be and the point to which the line will go.

We draw the ears like we have before but instead of going down to the 19,19 corner, we stop 2 units further up.

From the point 19,17 we use the command Q19,19 17,19.
This indicates, that we want to wrap around the 19,19 and end at the 17,19 point.

The d value for this fox looks like this:

d="M1,2 L5,6 H15 L19,2 V17 Q19,19 17,19 H3 Q1,19 1,17 Z"

You can find the pen here.

 

Next in the series is going to be a bit more in depth about the more advanced commands and we will extend on the foxes head to make it look like this:
So stay tuned!

If you thought this was fun, maybe you want join our development team, to learn more about the SVGs and the like?

Feu Mourek
Feu Mourek
Developer

Feu verbrachte seine Kindheit im schönen Steigerwald und kämpfte sich bis zum Abitur durch die Schule. Seit September 2016 unterstützt es die Development Abteilung bei NETWAYS als Developer und UX Designer und widmet sich dort dem Web Development. Seine Freizeit verbringt es hauptsächlich in den virtuellen Welten von 'Dota 2' und diversen anderen Games, an der Kletterwand in der Boulderhalle, oder damit, mit Freunden und Kollegen Brett- und Pen and Paper Rollenspiele zu spielen.
GitLab-CI / YAML – Write less with Anchors, Extends and Hidden Keys

GitLab-CI / YAML – Write less with Anchors, Extends and Hidden Keys

Have you ever wanted to execute a GitLab-CI job for multiple operating systems and just copied every line of YAML multiple times?
Anchors, extends and hidden keys are coming to rescue!

Let’s say you have two jobs and the only difference between them being a single environment variable:

stages:
  - echo

echo-hello:
  stage: echo
  script:
    - echo $ECHO_TEXT
  variables: 
    ECHO_TEXT: "Hello world!"

echo-bye:
  stage: echo
  script:
    - echo $ECHO_TEXT
  variables: 
    ECHO_TEXT: "Bye bye!"

Anchors and extends

Writing the same job two times can already get quite messy and hard to maintain. The more jobs you add, the worse it gets.
But don’t worry, YAML has got you covered. Anchors and extends let you reuse parts of your config and extend on them.

In this example, we create the echo-hello job and extend on it in the echo-bye task:

stages:
  - echo

echo-hello: &echo #create an anchor named "echo"
  stage: echo
  script:
    - echo $ECHO_TEXT
  variables: 
    ECHO_TEXT: "Hello world!"

echo-bye:
  <<: *echo #use the anchor created above and extend it by using "<<"
  variables: 
    ECHO_TEXT: "Bye bye!"

Templating with hidden keys

One thing you can do to further improve on that is, by using a separate task just for templating using hidden keys.
Hidden keys can be defined in YAML using a . in front of a keys name. This prevents GitLab-CI from executing a job and allows us to use it as a template.

In our last example, we create an echo template job containing our stage and script. The echo job is then extended on in echo-hello and echo-bye:

stages:
 - echo

.echo: &echo #keys (jobs in this case) with a dot in front are hidden keys and won't be executed by GitLab
  stage: echo 
  script: 
    - echo $ECHO_TEXT  

echo-hello: 
  <<: *echo 
  variables:  
    ECHO_TEXT: "Hello world!"  

echo-bye: 
  <<: *echo  
  variables: 
    ECHO_TEXT: "Bye bye!"

Some real world examples can be found in our public Icinga 2 packaging repositories: https://git.icinga.com/packaging/rpm-icinga2

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

Das neue User Interface von Icinga DB

Während mit Icinga DB sehr viel unter der Haube passiert ist, kommt mit dem Release auch ein rundum neu geschriebenes Monitoring Modul für Icinga Web 2. In diesem Zuge erhielt auch das User Interface ein ausführliches Redesign. In diesem Blogpost werden die wichtigsten Änderungen erklärt.

Listen

Wie im bewährten Monitoring Modul gibt es im Monitoring Modul für Icinga DB viele Listenansichten. Daher wurden diese komplett überarbeitet. Allen Listenelementen liegt eine grundlegende einheitliche Anatomie zugrunde.

ListItem Anatomy.jpg

Anatomie eines Listenelements

Visual

Für jedes Listenelement wird ein so genanntes Visual verwendet. Dieses dient dazu, in langen Listen bestimmte Elemente hervorzuheben bzw. einen intuitiven Überblick geben, welchen Zustand das zugrunde liegende Objekt hat. Bei Host- bzw. Servicelisten wird dadurch beispielsweise der State dargestellt. So wird in der Übersicht unmittelbar ersichtlich, bei welchen Objekten Probleme vorliegen.

Title

Der Titel beschreibt ergänzend kurz zusammengefasst den Zustand des Listenelements. So enthält er beispielsweise die Info, dass ein Host gerade Down ist. Während das Visual einen intuitiven Eindruck gibt, erklärt der Titel, was genau passiert ist.

Meta

Der Metabereich ist für zusätzliche Informationen vorgesehen. In der Regel werden hier Zeitangaben des Listenelements angezeigt. In Host und Servicelisten steht hier, wie lange sich das Objekt bereits im entsprechenden Zustand befindet.

Caption

Der Caption-Bereich enthält detaillierte Informationen zum Listenelement. Dies kann im Falle von Hosts und Services der Plugin Output sein. Bei Kommentaren und Downtimes werden hier die Kommentartexte des Users angezeigt. Um die Listendarstellung kompakt und einheitlich zu halten, werden lange Texte auf eine oder mehrere Zeilen gekürzt.

Klickbare Elemente

Viele der Listenelemente enthalten neben dem Hauptelement zwei oder mehrere klickbare Elemente. Alle Teile des Listenelements, die auf weitere Detailinformationen verweisen sind eindeutig hervorgehoben. Dadurch ist sofort erkennbar, hinter welchen Textteilen sich Zusatzinformationen befinden.

Overdue Checks in Host- und Service Listen

In Host und Servicelisten werden Overdue Checks nun besonders auffällig hervorgehoben. Dadurch ist auf den ersten Blick sofort ersichtlich, welche Objekte möglicherweise nicht mehr aktuell sind.

Artboard Copy.jpg

Das neue Icinga DB Design: Hostliste und Detailbereich

Detailgrad der Listenansichten wählen

Der Detailgrad der Host- und Servicelisten ist nun wählbar. Die Standardansicht zeigt den Titel und einen zweizeiligen Plugin Output. In der detaillierten Ansicht wird der gesamt Plugin Output angezeigt. Will man einen größeren Überblick bekommen gibt es außerdem die Minimalansicht. Hier wird in einer Zeile der Plugin Output angeschnitten, wenn genügend Platz vorhanden ist. Dafür sieht man auf einem Bildschirm wesentlich mehr Listenelemente als in den anderen Darstellungen.

State Change Visual in History- und Notification Elementen

In History und Notification Listen sind unter anderem Statewechsel-Elemente zu finden. Hier wird im Visual der Wechsel nun auf den ersten Blick deutlich gemacht. Neben dem aktuellen State wird gleichzeitig auch der vorherige State ersichtlich.

State Changes sind in den Notificationlisten nun besser ersichtlich.

Detailansichten

Optimierte Headerbereiche

Die Headerbereiche der einzelnen Objekttypen erhalten ein neues Design. Während die herkömmlichen Headerbereiche sehr viel Platz brauchten, sind die Informationen kompakter.

Graphen

Die Detailansichten der Elemente waren bisher sehr textlastig. Nach dem Redesign sind die Detailbereiche deutlich visueller angelegt. Nun werden anstatt der bloßen Auflistung Informationen kombiniert und Zusammenhänge dargestellt.

Modaldialoge für schnelle Aktionen

Wollte man bisher aus dem Detailbereich einen Kommentar anlegen oder eine Downtime setzen wurde der Dialog in einer weiteren Spalte angezeigt, so dass die Inhalte der linken Spalte verloren gingen. Im neuen Monitoring Modul gibt es nun ein Modal-Element für kurze Interaktionsdialoge. Für Aktionen im Detailbereich erscheint nun ein Modaldialog. Dadurch bleibt die linke Listenspalte und somit der Kontext besser erhalten.

 

Florian Strohmaier
Florian Strohmaier
UX Designer

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.

DevOpsDays Berlin: Last Tickets

On Nov 27 – 28 2019 the DevOpsDays Berlin are taking place!

Success factor open space

One of the success factors of previous DevOpsDays has been the open space format. It’s quick, it’s easy, it’s communicative. It fosters the sharing of ideas and insights in the good old fashion, in a non-technical way by just talking to each other. This doesn’t require any effort besides registering and showing up at the event.

Great international line-up

We have introduced the wonderful DevOpsDays line-up before, but let me drop some of these names again, because of the pleasant expectations they arise: Monica Sarbu (Elastic), Beth North, Daniel Löffelholz (ThoughtWorks), Leonardo di Donato (Sysdig), Jessica Anderson (Meltwater)… Or, put differently: Wrapped around the open spaces will be a great line-up of international speakers! Learn more about it here.

Register now, listen carefully and throw yourself into discussion!

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.