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.

NETWAYS Web Services: Web Accelerator

NETWAYS Web AcceleratorBeim Onlinehandel zählt jede Sekunde (eigentlich sogar jede Hundertstelsekunde) – die Ladezeiten wirken sich 1:1 auf Ihren Umsatz aus. Daher sind moderne Cachingtechnologien für den Umsatzerfolg unabdingbar, allerdings hat nicht jeder Shopbetreiber kompletten Zugriff auf seine Infrastruktur oder möchte sich nicht mit den technischen Details auseinander setzen. Hier haben wir eine passende Lösung in unseren NETWAYS Web Services:
Der NWS Web Accelerator bietet einen schnellen Cache für die statischen Inhalte Ihrer Website, um die Ladezeit zu beschleunigen. NWS WebAccelerator reduziert die Ladezeit Ihrer Website um ein Vielfaches. Eine schnellere Ladezeit ermöglicht es Ihnen, Ihre -Absprungraten zu reduzieren und führt damit zu einer besseren Conversion Rate.

Das Setup ist in wenigen Minuten erledigt – alles, was man braucht, ist ein gültiges SSL-Zertifikat für Ihre Webseite und einen Redirect Ihrer Webseite. Darüber hinaus kann man eine eigene Wartungsseite hinterlegen, wenn z.B. Wartungsarbeiten an Ihrem Backend durchgeführt werden.
Wichtiger Hinweis: Alle Angebote bei den NETWAYS Web Services können Sie 30 Tage kostenfrei testen!

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Graphite mit Icingadaten füttern

Sgraphite_ping4-rtaeit Icinga 2 wird Graphite über ein eigenes Feature, also direkt, unterstützt. Muss man bei Icinga 1 noch den Umweg über zusätzliche Tools, wie z.B. Graphios gehen, fällt das nun weg. Standardmäßig erwartet Icinga 2 den Carbon Cache Daemon auf dem selben System (localhost) an Port 2003, also über das Plaintext Protokoll. Davon abweichende Einstellungen können in der Konfigurationsdatei “/etc/icinga2/features-available/graphite.conf” vorgenommen werden.
Zunächst zieht der Carbon Cache Daemon die Datei “storage-schemas.conf” zur Speicherung bzw. Aggregation der Metriken heran, die Icinga 2 Dokumentation gibt hier für den Graphite Carbon Cache Writer bereits ein allgemein gültiges Schema vor:

[icinga_internals]
pattern = ^icinga\..*\.(max_check_attempts|reachable|current_attempt|execution_time|latency|state|state_type)
retentions = 5m:7d
[icinga_default]
pattern = ^icinga\.
retentions = 1m:2d,5m:10d,30m:90d,360m:4y

Damit die Verdichtung der Daten korrekt funktioniert, ist es wichtig das die angegebenen Werte mit den wirklichen Host- bzw. Servicecheckintervallen (check_interval) überstimmen. In diesem Beispiel müsste also das Intervall für Host- und Servicechecks auf eine Minute gesetzt sein. Gibt es Abweichungen davon, müssen hier entsprechend Einträge hinzugefügt bzw. abgeändert werden.
Ob die Einstellungen passen, lässt sich nach den ersten Prüfungen mit den mitgelieferten Whisper Scripts anhand der abgelegten Metriken relativ leicht überprüfen. Zuerst kontrollieren wir mit whisper-info ob die angegeben Werte korrekt übernommen wurden:

# whisper-info rta.wsp
maxRetention: 126144000
xFilesFactor: 0.5
aggregationMethod: average
fileSize: 191104
Archive 0
retention: 172800
secondsPerPoint: 60
points: 2880
size: 34560
offset: 64
Archive 1
retention: 864000
secondsPerPoint: 300
points: 2880
size: 34560
offset: 34624
Archive 2
retention: 7776000
secondsPerPoint: 1800
points: 4320
size: 51840
offset: 69184
Archive 3
retention: 126144000
secondsPerPoint: 21600
points: 5840
size: 70080
offset: 121024

Die angegebene retention im Archive 0 von 172800 Sekunden stimmt mit dem angegebenen Speicherintervall überein (2*24*60*60 für 2 Tage) und auch die secondsPerPoint wurden mit 60 (also 1m) richtig übernommen. Eine stichpunktartige Kontrolle der retention von Archive 2 für 90 Tage (also 90*24*60*60) zeigt, das auch hier die Werte stimmen.
So weit gut so gut, allerdings sollte man um wirklich sicher zu gehen auch noch einen Blick auf die gespeicherten Datenpunkte werfen. Das geschieht mit whisper-fetch, der Parameter pretty zeigt dabei menschenlesbare Zeitstempel an:

# whisper-fetch --pretty rta.wsp
...
Tue Jul 21 09:05:00 2015	0.000083
Tue Jul 21 09:06:00 2015	0.000072
Tue Jul 21 09:07:00 2015	0.000137
Tue Jul 21 09:08:00 2015	0.000093
Tue Jul 21 09:09:00 2015	0.000102

Wenn die Einstellungen korrekt sind, sollten hier wie im gezeigten Beispiel nach Möglichkeit keine leeren Datenpunkte (Eintrag: None) vorkommen, andernfalls muss hier nochmal nachgefasst werden.

Markus Waldmüller
Markus Waldmüller
Lead Senior Consultant

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.

Graphing mit Graphite: NETWAYS Webinar

Graphite ist eine Open Source Graphing Lösung, welche sich aufgrund der Flexibilität und Skalierbarkeit auf Augenhöhe mit vergleichbaren Enterprise Lösungen befindet.
Morgen, den 06. November 2013 um 14:00 Uhr, werden wir diese in unserem Webinar vorstellen.
Hier werden wir unter anderem auf das Webinterface, die Handhabung sowie die Architektur eingehen. Die Registrierung erfolgt wie immer über unser Webinar-Center.
Anschließend findet sich in unserem Webinar-Archiv sowie auf unserem YouTube-Channel das Webinar-Video sowie die Präsentationsfolien.
Übrigens: Bereits nächste Woche, am 13. November um 14:00 Uhr, findet unser erstes Webinar zu Icinga 2 statt. Also jetzt jetzt noch schnell registrieren!
Wir freuen uns auf eine rege Teilnahme!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

File Caching mit Nginx


Nginx ist ein leistungsfähiger Webserver und Reverse-Proxy, der ursprünglich für eine russische Website entwickelt wurde. In den letzten Monaten erfreut sich die unter BSD-Lizenz verfügbare Software einer immer größer werdenden Beliebtheit.
Besonders spannend finde ich die Möglichkeit diverse Remote-Services als Caching Instanz zusammenzufügen und den entsprechenden Filesysteminhalt auf dem Server abzulegen. So ist der Inhalt anschließend dann nicht in einem Cache-File oder einer Cache-Struktur, ähnlich Squid abgelegt, sondern in einer realen Schattenkopie.
Nachfolgender Code-Snip zeigt kurz den entsprechenden Abschnitt der Konfiguration:

http {
	server {
		listen       8888;
		server_name  proxy.server.org;
		# root url - don't cache here
		location /  {
			proxy_pass      http://upstream.server.org;
		}
		# here is static caching
		location ~* ^/Content.+\.(cab|exe|psf|CAB|EXE|PSF)$ {
			root                 cache/wsus;
			error_page       404 = @fetch;
		}
		location @fetch {
			internal;
			proxy_pass      http://upstream.server.org;
			proxy_store     on;
			root                 cache/wsus;
		}
	}
}

Das Wiki von Nginx bietet darüber hinaus ausführliche Hilfestellung und zeigt viele Ideen auf, die durch den Einsatz möglich werden.

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 startet er das wöchentliche Lexware-Backup und investiert 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 seinem Sohn.