Seite wählen

NETWAYS Blog

Graphite entlasten mit Carbon Relay (NG)

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:

  1. lokale Whisper Files
  2. Andere Graphite-Web APIs
  3. 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
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...

Vive la Puppet!

Nächste Woche ist es soweit: Während der ersten UEFA EM-Woche in Frankreich starten auch wir mit unserer neuen Fundamentals for Puppet Schulung über drei Tage. Beim Auftakt lernen die Teilnehmer die grundsätzliche Funktionsweise von Puppet kennen und werden Stück für Stück an die Modulentwicklung und natürlich auch -benutzung herangeführt. Aufgrund der besseren Platzverhältnisse findet das allerdings hier in Deutschland, genauer gesagt in Nürnberg, statt.
EM-PokalWer sich durch den Besuch des Fundamentals for Puppet Trainings qualifiziert, dem sei als logischer zweiter Schritt ein Besuch von Advanced Puppet nahegelegt. Dieser Kurs befasst sich mit erweitertem Moduldesign und geht auf die bestehenden Validierungs- und Testmöglichkeiten ein. Weiterhin werden in dem ebenfalls 3tägigen Training optionale Komponenten wie eigene Facts und Funktionen behandelt. Auch Datenseparierung mit Hiera und die Benutzung von Git als Versions Control System sind Thema.
Die nächste Advanced Puppet Schulung ist für Mitte Juli (11.07.-13.07.2016) angesetzt. Fussballinteressierten ist nun bestimmt aufgefallen das dies einem Tag nach dem EM-Finale in Paris startet, aber davon lassen wir uns nicht abschrecken. Wer’s doch nicht ganz schaffen sollte hat dann auch nochmal im November die Gelegenheit daran teilzunehmen.
In die Verlängerung geht es dann mit Scaling Puppet. Wie der Name schon sagt dreht sich hier alles um Hochverfügbarkeit und Lastverteilung der einzelnen Puppet Komponenten. Besonders große und verteilte Systeme erfordern tiefergehendes Wissen und ein paar Tipps und Tricks auf die während des 2tägigen Trainings eingegangen wird.
Auch bei uns haben sich ein paar Regeln geändert: Alle Puppet Trainings werden nun ausschließlich auf Basis der Open Source Variante durchgeführt! Natürlich gehen wir aber trotzdem noch auf die Unterschiede im Gegensatz zur Enterprise Variante ein. Außerdem sind die Schulungen auf die neue Major Version von Puppet – Puppet 4.x, fokussiert.
Ich freue mich über alle die in die nähere Auswahl für die Open Source Puppet Trainings kommen und wünsche den Fußball Begeisterten unter euch viel Spaß bei der Europameisterschaft in Frankreich, mit einem hoffentlich zufrieden stellenden Ausgang…

Markus Waldmüller
Markus Waldmüller
Head of Strategic Projects

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 Senior Manager Services gelandet. Seit September 2023 kümmert er sich bei der NETWAYS Gruppe um strategische Projekte. Wenn er nicht gerade die Welt bereist, ist der sportbegeisterte Neumarkter mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Mountainbike oder am Baggersee zu finden.

OSMC 2014: Der Countdown läuft – nur noch 1 Tag

Nur noch ein Mal nicht schlafen, dann ist endlich wieder OSMC! Fernando Hönig läutet die schönste Zeit des Konferenzjahres mit Distributed Monitoring and Cloud Scaling for Web Apps ein.

OSMC? Was soll das denn sein und wer sind die netten Menschen in diesen Videos?Die Open Source Monitoring Conference (kurz: OSMC) ist die internationale Plattform für alle an Open Source Monitoring Lösungen Interessierten, speziell Nagios und Icinga. Jedes Jahr gibt es hier die Möglichkeit sein Wissen über freie Monitoringsysteme zu erweitern und sich mit anderen Anwendern auszutauschen. Die Konferenz richtet sich besonders an IT-Verantwortliche aus den Bereichen System- und Netzwerkadministration, Entwicklung und IT-Management. Und die netten Menschen, die Ihr in unseren Videos zur OSMC seht, gehören dazu. 2014 wird die OSMC zum 9. Mal in Nürnberg stattfinden.

OSDC-Ticker: Scaling und Virtualisierung

Auch der zweite Tage der OSDC bietet den Teilnehmern ein abwechslungsreiches Programm.
Am Morgen startete Jens Mücke von Xing und mit einem guten Überblick der vorhandenen Herausforderungen und Problemlösungen in den letzten Jahren. Als größte Social Business Plattform Europas schenkt Xing neben Verfügbarkeit vor allem Performance und deren Messbarkeit viel Beachtung. Gerade das Monitoring der Public-Twitter-Timeline zur Identifizierung externer Fehlerbilder ist besonders spannend und wird bei Xing in einem RRD-Tool gegraphed. Die Geschwindigkeit von Twitter ist so selbst als Ergänzung zum Monitoring ungeschlagen.
Ralph Dehner von B1-Systems brachte in einem sehr anschaulichen Vortrag die Zuhörer auf den aktuellen Stand zum Thema KVM und Pacemaker. Unter Verwendung dieser Komponenten lassen sich hochverfügbare Virtualisierungscluster aufbauen und steuern um einen reibungslosen Ablauf in kritischen Umgebungen sicherzustellen.
Virtualisierung und Hochverfügbarkeit sind wie immer ein großer Magnet bei Open Source Konferenzen und werden auch bei unser Konferenz mit Themen wie openQRM und OpenVZ-Containervirtualisierung abgerundet.
Am Nachmittag warten noch einige spannende Vorträge auf uns bevor die Teilnehmer am Abend die Heimreise antreten.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.