NETWAYS Blog

Graphite Reporting mit der Render-API

von Daniel Neuberger | Jun 16, 2017 | Graphite & Grafana

Vor kurzem durfte ich mich damit beschäftigen, wie man schnell und halbwegs vernünftig eine Art Reporting für Performance-Daten für Icinga 2 umsetzen kann. Um solche Daten entsprechend aufzubereiten bedarf es weiterer Open-Source-Software. Meiner Meinung nach eignet sich Graphite hierzu am besten. Ich möchte heute einen kurzen Einblick in die Möglichkeiten geben.
Graphite ist ein Werkzeug, welches aus drei Komponenten besteht: Carbon-Cache als Datensammler, Whisper als Storage-Backend und Graphite-Web um die Graphen visuell und als API bereitzustellen. Icinga 2 schreibt die Performance-Daten mit dem „graphite“-Feature direkt an den Carbon-Cache-TCP-Socket. Welche Möglichkeiten habe ich als Anwender nun, diese historischen Daten für meine Zwecke in Reporting zu verwenden?
Eigentlich ganz einfach: Graphite liefert eine eigene Render-API. Diese bietet die Möglichkeit, die Daten als Graph, csv , json, pdf und einige weitere Formate zu generieren. Der Anwender kann diese Daten als REST-API Aufruf im Browser oder beispielsweise curl in der Shell abholen. Dabei können verschieden Metriken und Aggregationen auf Graphen angewandt und unterschiedliche Werte gebündelt abgerufen werden.

Wie fange ich an?

Generell wird die URL wie folgt aufgebaut:
target=icinga2..services.*.*.perfdata.*.value
Im gezeigten Beispiel kann man für die „target“-Metriken auch Wildcards verwenden, um etwa mehrere Services gleichzeitig abzufragen. Dies entspricht dem Dateipfad im Whisper-Backend. Man kann allerdings auch Listen oder Arrays angeben, um gezielt bestimmte Werte abzufragen.
Es gibt unterschiedliche Möglichkeiten, die Daten für die entsprechenden Ausgaben weiterzuverarbeiten. Die wohl wichtigsten sind &from für die Zeit und &format für die Formatierung der Daten.

Metrik „Baum“

Um die Werte für die CPU-Load abzufragen, muss der entsprechende Service in Icinga 2 definiert sein und Performance-Daten nach Graphite schreiben. Im Screenshot sieht man im Baum „services“ – „load“, letzterer stellt den Service-Namen dar. Der Sub-Knoten „load“ liefert die Information, dass hier das „load“ CheckCommand verwendet wurde. Tip an dieser Stelle: Lässt sich etwa für Dashboard-Templates als eindeutiger Schlüssel verwenden in Grafana.

Performance-Daten liefern zum einen „perfdata“, worin einzelne Metriken mit ihrem Namen abgelegt werden, etwa „load1“ und darunter „value“ als Wert und Thresholds, etwa „crit“ und „warn“, sofern definiert. Zusätzlich können auch Metadaten von Icinga 2 geschrieben werden, die man aber explizit in der Konfiguration einschalten muss („metadata“).

Einzelne Metrik abfragen

Im folgenden interessiert uns aber lediglich der Wert der Metrik „load1“ als einzelner Wert. Um eine ordentliche Ausgangsbasis zu erhalten, wählen wir den Zeitraum der letzten 3 Stunden. Tip: Es sind relative und absolute Zeitangaben möglich.
http://192.168.100.101/render?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load1.value&height=800&width=600&from=-3hours

Mehrere Metriken zusammenfassen

Man kann diese Abfrage auch erweitern, indem man mehrere Werte gleichzeitig abfrägt:
http://192.168.100.101/render?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.{load1,load15,load5}.value&height=800&width=600&from=-3hours

Mehrere Hosts mit der gleichen Metrik abfragen

Eine Abfrage mit verschiedenen Servern für „load15“ als Metrik könnte so aussehen:
http://192.168.100.101/render?target=icinga2.icinga*op_foreman_local.services.load.load.perfdata.load15.value&height=800&width=600&from=-3hours

Formatierung

Die Darstellung der Daten setzt immer eine &height und eine &width als Parameter voraus. Es ist auch möglich hier Tortendiagramme mit verschiedenen Funktionen für Mittelwerte und Summen aufzurufen.
Man kann die erhaltenen Daten auch als CSV-Werte formatieren und dann beispielsweise mit curl abspeichern. Alternativ kann man sich diese Werte auch direkt im Browser anzeigen lassen.

[root@icinga1op ~]# curl 'http://192.168.100.101/render/?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value&from=-3hours&format=csv'
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:30:00,0.24
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:31:00,0.21
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:32:00,0.17
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:33:00,0.15
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:34:00,0.16
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:35:00,0.13
icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value,2017-06-16 06:36:00,0.12
....

Wie bereits erwähnt lassen sich die Daten auch im JSON-Format anzeigen. Dies kann wieder über den Browser oder mittels curl erfolgen.
Das folgende Beispiel rendert alle erhaltenen Datenpunkte als JSON-Format:

[root@icinga1op ~]# curl 'http://192.168.100.101/render/?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value&from=-3hours&format=json'
[{"target": "icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value", "datapoints": [[0.13, 1497595140], [0.11, 1497595200], [0.15, 1497595260], [0.13, 1497595320], [0.1, 1497595380], [0.08, 1497595440], [0.07, 1497595500], [0.06, 1497595560], [0.06, 1497595620], [0.05, 1497595680], [0.04, 1497595740], [0.07, 1497595800], [0.05, 1497595860], [0.04, 1497595920], [0.05, 1497595980], [0.04, 1497596040], [0.08, 1497596100], [0.06, 1497596160], [0.07, 1497596220], [0.06, 1497596280], [0.06, 1497596340], [0.05, 1497596400], [0.04, 1497596460], [0.04, 1497596520], [0.03, 1497596580], [0.05, 1497596640], [0.04, 1497596700], [0.05, 1497596760], [0.04, 1497596820], [0.09, 1497596880], [0.07, 1497596940], [0.06, 1497597000], [0.06, 1497597060], [0.05, 1497597120], [0.04, 1497597180], [0.04, 1497597240], [0.03, 1497597300], [0.02, 1497597360], [0.02, 1497597420], [0.01, 1497597480], [0.01, 1497597540], [0.01, 1497597600], [0.01, 1497597660], [0.01, 1497597720], [0.01, 1497597780], [0.07, 1497597840], [0.06, 1497597900], [0.07, 1497597960], [0.08, 1497598020], [0.07, 1497598080], [0.06, 1497598140], [0.04, 1497598200], [0.04, 1497598260], [0.03, 1497598320], [0.14, 1497598380], [0.14, 1497598440], [0.13, 1497598500], [0.12, 1497598560], [0.1, 1497598620], [0.09, 1497598680], [0.09, 1497598740], [0.07, 1497598800], [0.06, 1497598860], [0.07, 1497598920], [0.1, 1497598980], [0.1, 1497599040], [0.08, 1497599100], [0.06, 1497599160], [0.05, 1497599220], [0.04, 1497599280], [0.04, 1497599340], [0.03, 1497599400], [0.02, 1497599460], [0.05, 1497599520], [0.04, 1497599580], [0.03, 1497599640], [0.03, 1497599700], [0.04, 1497599760], [0.05, 1497599820], [0.04, 1497599880], [0.04, 1497599940], [0.04, 1497600000], [0.04, 1497600060], [0.03, 1497600120], [0.03, 1497600180], [0.02, 1497600240], [0.01, 1497600300], [0.01, 1497600360], [0.01, 1497600420], [0.04, 1497600480], [0.04, 1497600540], [0.03, 1497600600], [0.03, 1497600660], [0.02, 1497600720], [0.04, 1497600780], [0.04, 1497600840], [0.03, 1497600900], [0.03, 1497600960], [0.02, 1497601020], [0.01, 1497601080], [0.01, 1497601140], [0.01, 1497601200], [0.01, 1497601260], [0.01, 1497601320], [0.01, 1497601380], [0.01, 1497601440], [0.01, 1497601500], [0.01, 1497601560], [0.01, 1497601620], [0.63, 1497601680], [1.29, 1497601740], [1.87, 1497601800], [2.4, 1497601860], [2.74, 1497601920], [2.36, 1497601980], [1.93, 1497602040], [1.58, 1497602100], [1.29, 1497602160], [1.7, 1497602220], [2.26, 1497602280], [2.77, 1497602340], [3.1, 1497602400], [3.37, 1497602460], [3.09, 1497602520], [2.56, 1497602580], [2.09, 1497602640], [1.71, 1497602700], [1.4, 1497602760], [1.16, 1497602820], [0.95, 1497602880], [0.78, 1497602940], [0.63, 1497603000], [0.52, 1497603060], [0.42, 1497603120], [0.35, 1497603180], [0.28, 1497603240], [0.23, 1497603300], [0.19, 1497603360], [0.16, 1497603420], [0.13, 1497603480], [0.12, 1497603540], [0.1, 1497603600], [0.08, 1497603660], [0.07, 1497603720], [0.05, 1497603780], [0.07, 1497603840], [0.06, 1497603900], [0.05, 1497603960], [0.04, 1497604020], [0.03, 1497604080], [0.03, 1497604140], [0.02, 1497604200], [0.02, 1497604260], [0.01, 1497604320], [0.01, 1497604380], [0.01, 1497604440], [0.01, 1497604500], [0.01, 1497604560], [0.01, 1497604620], [0.01, 1497604680], [0.01, 1497604740], [0.01, 1497604800], [0.01, 1497604860], [0.04, 1497604920], [0.05, 1497604980], [0.06, 1497605040], [0.08, 1497605100], [0.06, 1497605160], [0.07, 1497605220], [0.06, 1497605280], [0.04, 1497605340], [0.05, 1497605400], [0.04, 1497605460], [0.03, 1497605520], [0.03, 1497605580], [0.02, 1497605640], [0.02, 1497605700], [0.01, 1497605760], [0.01, 149760

Um die Daten leserlich in der Konsole aufzubereiten, empfiehlt es sich „python -m json.tool“ als Formatierungshilfe zu verwenden.

curl 'http://192.168.100.101/render/?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value&from=-3hours&format=json' | python -m json.tool

Um die JSON-Daten in der Console zu visualisieren kann man Zach Holman’s Spark verwenden:

[root@graphite ~]# curl 'http://192.168.100.101/render/?target=icinga2.icinga3op_foreman_local.services.load.load.perfdata.load5.value&from=-3hours&format=json' | python -mjson.tool | grep ',' | grep -v '\]' | spark
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3695 0 3695 0 0 230k 0 --:--:-- --:--:-- --:--:-- 240k
▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃▃▅▅▅▃▃▃▃▅▅███▅▅▃▃▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁

Conclusio

Das war nur ein kleiner und rudimentärer Überblick was über die Render-API möglich ist. Jedoch bietet sie genügend Anregung um mehr mit Graphite, Icinga 2 und Metriken zu machen. Die Render-APi bietet zudem die Möglichkeit, programmatisch in Scripts darauf zuzugreifen. Mir hat es zumindest Lust auf mehr gemacht und ich denke, dass ich noch weitere Blogposts zu diesem Thema schreiben werde 🙂
Falls ihr nicht warten könnt, hier nochmal der Link zur Doku. Oder ihr schaut einfach mal bei uns in der Graphite-Schulung vorbei und lernt die Render-API am praktischen Beispiel kennen.

Daniel Neuberger

Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Lies mehr von Daniel und triff unser Team

Graphite entlasten mit Carbon Relay (NG)

von Thomas Widhalm | Mai 19, 2017 | Graphite & Grafana

Graphite ist eine der beiden häufig genutzten Lösungen zum Erstellen von Graphen durch (nicht nur) Icinga 2. Im Gegensatz zu PNP4Nagios, das zusätzliche Software braucht, bringt Graphite mit dem Carbon Cache schon von Haus aus eine Lösung mit, die Daten zwischenspeichern kann, bevor sie auf Platte geschrieben werden. Während eine einzelne Graphite Installation so etliche Datenpunkte in kurzer Zeit „verdauen“ kann, so stösst auch Graphite irgendwann an seine Grenzen.
Eine Lösung, die sich bei einigen Setups bewährt hat, ist ein Carbon Relay. Eigentlich dafür gedacht, Daten auf mehrere Carbon Cache Instanzen aufzuteilen, bietet ein solches Relay auch die Möglichkeit, eine weitere Pufferinstanz einzuführen und so noch besser Lastspitzen abzufangen. Sollte das Relay nicht als Pufferinstanz ausreichen, ist damit schon die Grundlage gelegt, Graphite in der Breite zu skalieren.
Zur Auswahl stehen zwei Implementierungen des Carbon Relay, wobei der neuere, Carbon Relay NG genannte, Rewrite in „Go“ bisher deutlich bessere Ergebnisse gebracht hat. Zur Installation werden Pakete angeboten, die auch über Repositories zu beziehen sind. Leider stehen keine einfachen Repo-Files, die die Repositories in den Package Manager konfigurieren, zur Verfügung. Statt dessen wird man gezwungen, ein Script auszuführen, das erst Abhängigkeiten installiert und dann ein passendes Repofile zusammenbaut und ablegt. Da ich nicht gern einfach irgendwelche Scripts auf meinen Hosts laufen lassen, habe ich die Anleitung auf einer Wegwerf-VM befolgt, die Schritte auf den eigentlichen Hosts nachempfunden und das Repofile kopiert. Danach reicht auf CentOS 7 ein yum install carbon-relay-ng um das Relay zu installieren.
Leider scheint das Paket noch nicht ausreichend für CentOS 7 angepasst zu sein, weshalb ein paar Nacharbeiten nötig sind: Die beiden Verzeichnisse /var/spool/carbon-relay-ng und /var/run/carbon-relay-ng müssen angelegt werden. Ausserdem braucht die Konfigurationsdatei /etc/carbon-relay-ng/carbon-relay-ng.conf noch ein paar kleinere Anpassungen. Sehr wichtig dabei ist, zwei Leerzeichen in der addRoute Zeile vor dem Empfänger zu verwenden.

instance = "default"
max_procs = 2
listen_addr = "0.0.0.0:2003"
pickle_addr = "0.0.0.0:2013"
admin_addr = "0.0.0.0:2004"
http_addr = "0.0.0.0:8081"
spool_dir = "/var/spool/carbon-relay-ng"
pid_file = "/var/run/carbon-relay-ng.pid"
log_level = "notice"
bad_metrics_max_age = "24h"
validation_level_legacy = "medium"
validation_level_m20 = "medium"
validate_order = false
init = [
     'addRoute sendAllMatch carbon-default  192.168.5.20:2003 spool=true pickle=false',
]
[instrumentation]
graphite_addr = "localhost:2003"
graphite_interval = 1000  # in ms

Dabei ist natürlich 192.168.5.20 durch die IP der Carbon Cache Instanz zu ersetzen.
Leider ist die Dokumentation des carbon-relay-ng aktuell noch etwas dürftig, weshalb einiges an Probiererei gefragt ist, wenn man die Funktionen ausreizen möchte. Zum Probieren und Testen habe ich Vagrant Boxen gebaut, die aktuell nicht viel mehr sind als Prototypen. Wer Erfahrung mit Vagrant und Puppet hat, kann die aber ganz gut als Ausgangsposition nehmen. Wenn sie mal ein bissl ausgereifter sind, wandern die auch aus meinem privaten Github Account in einen „offizielleren“.
Ein grosser Vorteil des Carbon Relay NG ist, dass es nicht nur puffern, sondern die Daten auch sehr einfach auf mehrere Carbon Cache Instanzen verteilen kann. Dazu ändert man einfach den init Teil der Konfigurationsdatei auf folgende Version (auch hier wieder zwei Leerzeichen vor jedem Ziel):

init = [
        'addRoute consistentHashing carbon-default  192.168.5.20:2003 spool=true pickle=false  192.168.5.30:2003 spool=true pickle=false',
]

Dabei wird der cosistentHashing Algorithmus von Graphite verwendet, der Metriken anhand ihres Namens auf verschiedene Instanzen verteilt. Somit kann man ganz einfach die Schreiblast auf beliebig viele Carbon Caches verteilen und stellt sicher, dass die Metriken immer am gleichen Cache ankommen. Am besten funktioniert das, wenn man die Verteilung konfiguriert, bevor zum ersten mal Daten in die Carbon Caches geschrieben werden. Sollte man eine bestehende Installation umziehen wollen, muss man alle bereits angelegten Whisper Files auf alle Carbon Caches verteilen. Also eigentlich nicht alle, da es aber nicht einfach nachvollziehbar ist, welche Metriken der Hashing-Algorithmus wo hin schreibt, ist es sicherer, alle zu kopieren und nach einiger Zeit mit find diejenigen zu suchen und zu löschen, in die schon länger nicht mehr geschrieben wurde. Das sollte man ohnehin regelmässig machen, da Whisper Files von Hosts und Services, die man in Icinga 2 umbenennt oder entfernt, liegen bleiben.
Hat man mehrere Carbon Cache Instanzen als Ziel konfiguriert, muss man sie auch für Graphite-Web nutzbar machen. Viele Addons wie Grafana nutzen die API von Graphite-Web, um auf die in Graphite gespeicherten Daten zuzugreifen, weshalb es naheliegend ist, sämtliche Datenquellen dort zu hinterlegen. Graphite-Web lässt in seiner Konfiguration mehrere Datenquellen zu, wobei 3 davon für uns relevant sind:

lokale Whisper Files
Andere Graphite-Web APIs
Andere Carbon Caches (hier sollten nur die angegeben werden, die auf dem selben Host liegen, wie Graphite-Web, sonst lieber den Umweg über Lösung 2)

Da Graphite-Web üblicherweise so konfiguriert ist, dass es die lokalen Whisper Files verwendet, muss in local_settings.py nur mehr die zusätzliche Graphite Instanz auf dem hinzugekommenen Host konfiguriert werden. (Port 8003 ist hier aus den oben genannten Vagrant Boxen entnommen. Natürlich muss hier konfiguriert werden, wie das andere Graphite Web erreicht werden kann)

CLUSTER_SERVERS = ["192.168.5.30:8003"]

So erreicht man zwar keine Hochverfügbarkeit, aber das liesse sich relativ einfach erreichen, in dem man mehrere Graphite Webs anlegt, die jeweils ihre lokalen Whisper Files und die APIs aller anderen Instanzen konfiguriert haben. Davor einen Loadbalancer, fertig. Auf jeden Fall hat man auf diese Weise aber Carbon Cache in die Breite skaliert, was für grosse Installationen, die vielleicht nicht nur aus Icinga 2, sondern auch aus dem Elastic Stack und collectd Daten erhalten, einige Probleme lösen kann.
Wer jetzt Lust bekommen hat, mehr über Graphite zu erfahren, der sollte sich mal unser Schulungsangebot dazu ansehen.

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...

Lies mehr von Thomas und triff unser Team

Was macht eigentlich . . .

von Christoph Niemann | Sep 2, 2016 | Icinga, Serien, Linux, Windows

. . . NSClient++ ? Länger haben wir hier im Blog nichts mehr zum Thema NSClient geschrieben. Grund genug um mal wieder den aktuellen Entwicklungsstand zu überprüfen.
Aktuell wird der Monitoring Agent in 2 Strängen weiterentwickelt. Die Version 0.4.4 ist als stable markiert und bekommt nur noch bugfixes und kleinere Erweiterungen. In Version 0.5.0 wurden einzelne Module komplett neu geschrieben. Mit der aktuellen 0.5.0.59 wurde weiter an der Stabilität und einzelnen Checks gearbeitet.
Besonders hervorzuheben sind im 0.5er Release der Webserver, der ssl gesichert und REST-apifiziert Kommandos entgegen nimmt und Informationen zurückliefert, Auch ist es in der aktuellen Version möglich Performancedaten direkt an graphite zu schreiben, was besonders in Großen Umgebungen zu einer starken Entlastung des monitoring servers (egal ob icinga 1 oder 2) führen kann. Um den überwachten Server besser zu schützen beendet NSClient jetzt alle von ihm angestoßenen Skripte wenn es selbst beendet wird, damit keine Langläufer mehr verloren gehen.
Bei allen Verbesserungen in 0.5 sollte man aber nicht vergessen, dass diese Version noch beta ist und nur mit der nötigen Vorsicht verwendet werden sollte.

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.

Lies mehr von Christoph und triff unser Team

Monthly Snap May: Docker, Graphite, Opennebula and Beijing

von Vanessa Erk | Jun 1, 2016 | Graphite & Grafana, Container, Icinga, Team, OpenNebula

May started with Simons blog post on monitoring custom applications.
Blerim gave us an insight into Graphite – the history of a data point. Kai, one of our trainees explained what he learned at NETWAYS.
weekly snap
Tobias explained Debugging with Docker and Michael told us something about Docker on OSX.
Kay explained on how to get started with the Opennebula API.
Finally, Christoph told us about his Consulting journey to Beijing.

Vanessa Erk

Head of Finance & Administration

Vanessa ist unsere Leiterin des Finanzbereichs. Zusammen mit ihrem Team verantwortet sie das Controlling, den Cashflow sowie die Personalangelegenheiten in der Unternehmensgruppe. Abseits des Büros taucht sie leidenschaftlich gerne in die Welt des Yogas ein – vor allem im Bereich Frauen und Kinder. Durch zahlreiche Weiterbildungen hat sie ihr Fachwissen dazu vertieft und ist Expertin in ihrem Gebiet. Als Mutter von 2 Kindern kümmert sie sich liebevoll um ihre Tochter und ihren Sohn. In ihrer Freizeit liebt sie es, mit ihrer Familie zu reisen und neue Orte zu erkunden. Dabei genießt sie besonders die Zeit in der Natur und unternimmt...

Lies mehr von Vanessa und triff unser Team