Noch mehr Inhalte für unser Graphing Training

Nachdem wir in den ersten Monaten des Jahres mit unseren Trainings etwas zurückhaltend waren, geht’s nun wieder voll los. Neben vielen anderen Schulungen, startet

in knapp zwei Wochen auch das Graphite + Grafana Training in die neue Saison. Gerade in dem Bereich gibt es allerlei Neuigkeiten und so war es für uns natürlich klar diesen Fortschritt auch in die Schulungsunterlagen einfließen zu lassen.

Zuerst stand natürlich Versionspflege an: Die Graphite Version in Folien und Trainingsumgebung wurde auf 1.1.2 angehoben, die große Änderung seit 1.1.x ist der sog. Tag Support.

Die wohl größte Aufmerksamkeit gilt aber Grafana in der neuen Version 5. Dashboards, Erscheinungsbild, Einstellungen und Themes wurden komplett überarbeitet. Außerdem können Dashboards zu Verzeichnissen zusammengefasst werden, was große Vorteile und Erleichterungen bei der Vergabe von Berechtigungen bringt. In dem Zuge besteht nun auch die Möglichkeit Benutzer in Teams zu strukturieren.

Grafana v5

Das InfluxDB-Kapitel wurde auf die aktuelle Version 1.5 angehoben. Neben InfluxDB werfen wir in der Schulung auch einen kurzen Blick auf die anderen Komponenten des TICK-Stacks bestehend aus Telegraf, Chronograf und Kapacitor.

Auch die Integrationen haben wir gehörig überarbeitet: Der eingesetzte Icinga 2 Core und Icinga Web 2 wurden jeweils auf die aktuellen Versionen angehoben. Neben dem Grafana-Modul kann nun auch das kürzlich releaste Graphite-Modul für Icinga Web 2 behandelt werden. Der Logstash-Teil ist einer Kombination aus Icingabeat und Elasticsearch gewichen, sodass eine anschauliche Übung für Annotations in Grafana Platz findet.

Zusätzliche Slides stellen mögliche Alternativen zu den Standard Carbon-Komponenten vor und erklären dessen Vor- und Nachteile. Weiterhin geben wir Performancetipps und Hinweise auf mögliche Optimierungen der Graphite-Umgebung. In diesem Zusammenhang gehen wir insbesondere auf Bottlenecks und entsprechende Admin- und Benchmarktools ein.

Um die Darstellung der Folien und v.a. der Handouts zu verbessern, setzen wir auf eine neue Showoff-Version (0.19). Dazu wurde das CSS-Layout einer kompletten Überarbeitung unterzogen. Die eingesetzten VirtualBox-Images werden nun von Grund auf mit Vagrant provisioniert, wohingegen die Installation und Konfiguration der Notebooks nach wie vor mit Foreman und Puppet stattfindet.

Der Umfang des Trainings ist mit zwei Tagen gleich geblieben. Die neuen Inhalte werden in wenigen Tagen ebenso wie die Vagrantfiles auch auf dem GitHub-Repository zur Schulung verfügbar sein. Und auch danach geben wir uns größte Mühe mit unseren Trainings so nah wie möglich am “Puls der Zeit” zu sein.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

NETWAYS’ upcoming Trainings, Spring 2018

The NETWAYS trainings are proof of our love for Open Source.  And as we always want to share our knowledge, we are happy to present our spring trainings:

 

1. Fundamentals for Puppet: 3 days training | 17.04.2018 to 19.04.2018

Learn the basic functionality behind the Puppet abstraction layer, how to build Puppet modules, and how to develop them from the local prototype to deployment on the Puppet master.


2. Ansible: 2 days training | 17.04.2018 to 18.04.2018
Learn to install and use Ansible. The training will focus on the configuration of Linux / Unix systems, the use of playbooks, and roles, as well as providing instructions for creating your own modules.

3. Ansible AWX: 1-day training | 19.04.2018 and 20.04.2018
Quick overview of the capabilities of Ansible AWX and working with AWX.

 
4. Graphite + Grafana: 2 days training | 24.04.2018 to 25.04.2018
Learn everything you need for running bigger, but also complex, environments.

5. Graylog:2 days training | 24.04.2018 to 25.04.2018
Learn installation and configuration of all platform components for collecting and processing log data, as well as their scaling. The goal of the training is to provide you with the knowledge you need to start your own Graylog installation.

We prefer a limited number of participants, to achieve a goal-oriented and efficient course of our training. We also provide hands on material.

Interested? Register now, more information on Trainings at NETWAYS watch this space.

Stay Updated!

Keya Kher

Autor: Keya Kher

Keya hat im Oktober ihr Praktikum im Marketing bei NETWAYS gestartet. Letzten Dezember startete Sie gemeinsam mit Ihrem Mann das “Abenteuer Deutschland”. Seitdem lernt Sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat schon viele Erfahrungen im Social Media Marketing und ist gerade dabei auch im Grafikdesign ein Profi zu werden. Wenn sie nicht gerade dabei ist, sich kreativ auszuleben, entdeckt sie die Stadt und schmökert gerne im ein oder anderen Büchlein. Ihr Favorit ist hierbei “The Shiva Trilogy”.

Systemd-Unitfiles und Multi-Instanz-Setups

Tux

Vor einer Weile hab ich bereits eine kurze Erklärung zu Systemd-Unitfiles geschrieben, diesmal will ich auf das Multi-Instanz-Feature von Systemd eingehen, da auch dieses anscheinend nicht jedem bekannt ist.

Als Beispiel soll mir diesmal Graphite bzw. genauer gesagt die Python-Implementierung carbon-cache dienen. Diese skaliert nicht automatisch, sondern erfordert, dass man weitere Instanzen des Dienstes auf anderen Ports startet. Die Konfiguration auf Seiten des carbon-cache ist hierbei recht simpel, denn es wird in einer Ini-Datei nur eine neue Sektion mit den zu überschreibenden Werten geschrieben. Der Sektions-Name gibt hierbei der Instanz den Namen vor. Das ganze sieht dann beispielsweise für Instanz b so aus.

[cache:b]
LINE_RECEIVER_PORT = 2013
UDP_RECEIVER_PORT = 2013
PICKLE_RECEIVER_PORT = 2014
LINE_RECEIVER_PORT = 7102

Mit SystemV hätte man nun das Startskript für jede Instanz kopieren und anpassen müssen, da das mitgelieferte Unitfile leider das Multi-Instanz-Feature nicht nutzt muss ich dies zwar auch einmal tun, aber immerhin nur einmal. Hierbei ist es sinnvoll den Namen zu verändern, um nicht mit dem bestehen in Konflikt zu kommen, wenn man möchte kann man es aber auch durch Verwendung des gleichen Namens “überschreiben”. Für das Multi-Instanz-Feature muss nur ein @ an das Ende des Namens. Baut man nun an entsprechenden Stellen den Platzhalter %i ist auch schon das Multi-Instanz-Setup fertig und man kann einen Dienst mit name@instanz.service starten. In meinem Beispiel wäre dies carbon-cache-instance@b.service mit folgendem Unitfile unter /etc/systemd/system/carbon-cache-instance@.service.

[Unit]
Description=Graphite Carbon Cache Instance %i
After=network.target
 
[Service]
Type=forking
StandardOutput=syslog
StandardError=syslog
ExecStart=/usr/bin/carbon-cache --config=/etc/carbon/carbon.conf --pidfile=/var/run/carbon-cache-%i.pid --logdir=/var/log/carbon/ --instance=%i start
ExecReload=/bin/kill -USR1 $MAINPID
PIDFile=/var/run/carbon-cache-%i.pid
 
[Install]
WantedBy=multi-user.target

Ich hoffe diese kurze Erklärung hilft dem ein oder anderen und ich würde mich freuen zukünftig mehr Dienste, die auf Instanzierung ausgelegt sind, bereits mit einem entsprechenden Unitfile ausgeliefert zu sehen.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

Graphite vs. IOPS – experience exchange

Last year, Blerim told us how to benchmark a Graphite and now we want to share some experience on how to handle the emerging IOPS with its pro and contra. It is important to know that Graphite can store its metrics in 3 different ways (CACHE_WRITE_STRATEGY). Each one of them influences another system resource like CPU, RAM or IO. Let us start with an overview about each option and its function.

max

The cache will keep almost all the metrics in memory and only writes the one with the most datapoints. Sounds nice and helps a lot to reduce the general and random io. But this option should never be used without the WHISPER_AUTOFLUSH flag, because most of your metrics are only available in memory. Otherwise you have a high risk of losing your metrics in cases of unclean shutdown or system breaks.

The disadvantage here is that you need a strong CPU, because the cache must sort all the metrics. The required CPU usage increases with the amount of cached metrics and it is important to keep an eye on enough free capacity. Otherwise it will slow down the processing time for new metrics and dramatically reduce the rendering performance of the graphite-web app.

naive

This is the counterpart to the max option and writes the metrics randomly to the disk. It can be used if you need to save CPU power or have fast storage like solid state disk, but be aware that it generates a large amount of IOPS !

sorted

With this option the cache will sort all metrics according to the number of datapoints and write the list to the disk. It works similar to max, but writes all metrics, so the cache will not get to big. This helps to keep the CPU usage low while getting the benefit of caching the metrics in RAM.

All the mentioned options can be controlled with the MAX_UPDATES_PER_SECOND, but each one will be affected in its own way.

Summary

At the end, we made use of the sorted option and spread the workload to multiple cache instances. With this we reduced the amount of different metrics each cache has to process (consistent-hashing relay) and find the best solution in the mix of MAX_UPDATES_PER_SECOND per instance to the related IOPS and CPU/RAM usage. It may sound really low, but currently we are running 15 updates per second for each instance and could increase the in-memory-cache with a low CPU impact. So we have enough resources for fast rendering within graphite-web.

I hope this post can help you in understanding how the cache works and generates the IOPS and system requirements.

Ronny Biering

Autor: Ronny Biering

Vor NETWAYS arbeitete Ronny bei einem der großen deutschen Internet- und Hosting Provider. Hier betreut er zusammen mit seinen Kollegen aus dem Bereich Managed Services die Plattformen unserer Kunden. Im Gegensatz zu dem üblichen Admin-Cliche, gehört Fitness zu einer seiner Lieblingsfreizeitbeschäftigung.

Annotations in Grafana

Im Zuge der diesjährigen Open Source Monitoring Conference durfte ich mit Timeseries & Analysis with Graphite and Grafana einen der Workshops am Vortag der eigentlichen Konferenz halten. Wie man dem Titel unschwer entnehmen kann spielte dabei auch Grafana eine besondere Rolle. Grafana ist vielen als schöneres Dashboard für Graphite bekannt und unterstützt mit Elasticsearch, CloudWatch, InfluxDB, OpenTSDB, Prometheus, MySQL als auch Postgres in der aktuellen Version 4.6.2 allerdings noch eine ganze Reihe weiterer Datensourcen nativ. Zusätzlich können diese herkömmlichen Datensourcen auch noch durch Community Plugins ergänzt werden.

Ganz besonders hilfreich ist es wenn man die Informationen aus verschiedenen Datensourcen miteinander vereint. So lassen sich beispielsweise Zusammenhänge besser erkennen und Rückschlüsse auf bestimmte Ereignisse ziehen, die ansonsten vielleicht unentdeckt blieben. Metriken, die z.B. aus Graphite stammen, können bei Grafana nun durch sogenannte Annotations um zusätzliche Informationen angereichert werden. Neben Annotations aus den unterstützten Datensourcen können solche Events seit v4.6 übrigens auch direkt in der eigenen Grafana-Datenbank gespeichert werden, ob man das wiederum möchte ist allerdings eine ganz andere Frage…

Als Praxisbeispiel habe ich für meinen Workshop im Rahmen der OSMC überraschenderweise Icinga gewählt. Hier ist es möglich über die Icinga 2 API verschiedene Daten wie Checkergebnisse, Statusänderungen, Benachrichtigungen, Bestätigungen, Kommentare oder auch Downtimes mit dem Icingabeat direkt an Elasticsearch oder wenn man möchte alternativ auch an Logstash zu senden. Über das Annotation-Feature von Grafana lassen sich so die Benachrichtigungen aus Icinga über die Elasticsearch Datasource passend zu den jeweiligen Statusänderungen der Host- oder Serivcechecks einblenden:

Wer dazu mehr erfahren möchte dem kann ich unsere Graphite + Grafana Schulung ans Herz legen, neben vielen anderen Themen werden dort auch Grafana und Annotations in aller Ausführlichkeit behandelt. Und wer’s nicht schafft, für den findet sich vielleicht der ein oder andere passende Workshop im Rahmen unserer Konferenzen.

Markus Waldmüller

Autor: Markus Waldmüller

Markus war bereits mehrere Jahre als Sysadmin in Neumarkt i.d.OPf. und Regensburg tätig. Nach Technikerschule und Selbständigkeit ist er nun Anfang 2013 bei NETWAYS als Lead Senior Consultant gelandet. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

Monthly Snap September > SensorProbe 2+, Icinga Director, OSBConf 2017, DevOpsDays, Benchmarking Graphite, OSMC

In September, Isabel started with introducing Intelligente Überwachung mit der AKCP sensorProbe 2+ while Eric shared his tips on Hidden pearls in Icinga Web 2. Nicole shared important information on NETWAYS Web Services on Request Tracker.

Marius told us how VM volumes live works using blkdeviotune and Shopware Update, Julia announced for new upcoming Advanced Puppet training and 7 reasons for join OSBConf. Markus shared Trick 17 with the Icinga Director while Tobias shared Trick 42 with the Icinga Director – Job in order.

Julia Announced OSMC in Hackathon, DevOpsDays in Berlin and continued with reasons for OSBConf 2017,she also  said thank to sponsors of OSBConf.

Blerim told us about Benchmarking Graphite, Nicole reviewed Managed Services team event 2017, And Dirk again shared his insights in The Consultant and The dear Certifications II.

Keya Kher

Autor: Keya Kher

Keya hat im Oktober ihr Praktikum im Marketing bei NETWAYS gestartet. Letzten Dezember startete Sie gemeinsam mit Ihrem Mann das “Abenteuer Deutschland”. Seitdem lernt Sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat schon viele Erfahrungen im Social Media Marketing und ist gerade dabei auch im Grafikdesign ein Profi zu werden. Wenn sie nicht gerade dabei ist, sich kreativ auszuleben, entdeckt sie die Stadt und schmökert gerne im ein oder anderen Büchlein. Ihr Favorit ist hierbei “The Shiva Trilogy”.