Auswertung von Graphite-Statistiken mit Graphiti

Beispiel einer Grafik aus GraphitiIm ersten Beitrag dieser Serie ging es darum mit StatsD und Graphite Daten zu sammeln. Doch was stellen wir nun damit an? In diesem Beitrag zeige ich euch ein paar Beispiele wie man mit dem Graphite Frontend Graphiti aussagekräftige Grafiken darstellen kann.

Wir nutzen Graphiti weil es gegenüber dem Graphite Frontend den deutlichen Vorteil hat, dass man Grafiken in Dashboards Kategorisieren kann, die Grafiken besser (wenn auch auch nicht wunderschön) aussehen und allen voran, weil man die URL API von Graphite mit Hilfe eines JSON-Objekts ansprechen kann. Das ist deutlich lesbarer als eine Kilometer lange URL. In den Beispielen gehe ich auf verschiedene Methoden der API Dokumentation ein, welche für Graphiti und Graphite gleichermassen anwendbar sind.

Die “hitcount” und “summarize” Methoden

Wir unterscheiden bei unseren Requests zwischen verschiedenen Typen. Wir zählen zum Beispiel Requests welche komplett aus dem HTML-Cache kommen und damit kaum CPU Zeit benötigen und Requests, welche nicht gecached sind. Nun wollen wir eine Grafik, welche uns die gesammelten Daten der letzten sechs Stunden anzeigt. Und zwar wollen wir einen Datenpunkt pro Minute zusammenfassen. Wie können wir das erreichen? 

Wir haben dazu die “hitcount” Methode verwendet. Der Code dazu:

hitcount-example

Die “options” definieren das grundlegende Aussehen der Grafik, etwa Breite, Höhe, Titel, Farben. Wichtig ist der Parameter “from“. Bei Statistiken in Echtzeit wünscht man sich ja oft die Daten, welche in den letzten X Minuten oder Stunden aufgenommen wurde. Daher kann man diesem Parameter auch ganz einfach “-6h” angeben um die Daten der letzten sechs Stunden anzuzeigen. Optional gibt es auch den “to” Parameter um Zeitfenster in der Vergangenheit auszuwerten.

Das “targets” Array definiert eine Liste von Graphen, die dargestellt werden sollen. In unserem Fall haben wir zwei Zähler, request.stats.cached und -uncached. Der “hitcount” Methode übergeben wir den Namen des Zählers und als zweiten Parameter definieren wir mit “60s” dass jeweils 60 Sekunden als ein darstellbarer Datenpunkt zurück gegeben wird. Damit haben wir zwei Graphen, welche über sechs Stunden anzeigen wie viele Seiten gecached oder ungecached während jeweils einer Minute aufgerufen wurden.

Der wichtige Unterschied zur Methode summarize: Hitcount nimmt die Daten ab genau dem Zeitpunkt an dem die Grafik generiert wird: Wird die Grafik 16:05:35 generiert, werden die Daten von 16:05:35 – 16:04:36, 16:04:35 – 16:04:36 etc. zusammengefasst. Summarize hingegen aggregiert die Daten immer auf den angegebenen Zeitraum: Gibt man eine Minute an und lädt die Grafik wiederum 16:05:35 werden die Datenpunkte 16:05:35 – 16:05:00, 16:04:59 – 16:04:00 etc. zusammengefasst. Die Summarize Methode ist also zur Zusammenfassung von ganzen Tagen beispielsweise die bessere Lösung. Nachteil: Summarize ist deutlich langsamer und funktioniert nicht bei grossen Datenmengen. Wenn man wie wir alle Daten sekundengenau aufzeichnet, kann ein ganzer Tag mit summarize gar nicht zusammengefasst werden. Die 4 GB RAM auf unserem Graphite Server reichen dafür nicht aus. Die meisten unserer Statistiken sind jedoch mit hitcount aussagekräftig genug.

Daten zusammenfassen und subtrahieren

Einen etwas komplexeren Fall haben wir mit unseren Blogs neuerdings.com, netzwertig.com, imgriff.com, fokussiert.com und startwerk.ch. Da diese öfters von schwächeren DDoS und Spam-Bots geplagt sind wollen wir eine Statistik, welche die Requests aller Publikationen im Verhältnis zur Gesamtbelastung der Social Media Kit Server anzeigt. Dafür müssen wir mehrere Messwerte kombinieren und subtrahieren:

diffseries-example

Erst zum unteren Target: Es fasst alle Publikationen zusammen. Wir verwenden Summarize zur Zusammenfassung der Werte auf Blöcke von einer Minute. Nebst Berechnungsfunktionen gibt es auch Funktionen, welche Serien verändern. Die Resultate dieser verändernden Funktionen können den Berechnungsfunktionen jeweils übergeben werden. Eine solche Methode ist “sumSeries“. Man kann beliebige Messpunkte übergeben und bekommt einen neuen, zusammengerechneten Messpunkt zurück. Damit Messen wir also Requests pro Minute für alle unsere Publikationen.

Das obere Target funktioniert nach dem gleichen Prinzip. Jedoch verwenden wir dort die Methode “diffSeries“. Als ersten Parameter übergeben wir mit request.site.* alle Requests die auf der Social Media Kit Infrastruktur abgearbeitet werden. Jeder weitere Parameter (In diesem Fall alle Pubilkationen) werden vom ersten Messpunkt abgezogen. Damit erhalten wir die Anzahl Requests pro Minute auf die gesamte Infrastruktur abzüglich der Requests auf unsere Publikationen.

Top 10 Sites als Kuchendiagramm

Auch immer gut zu wissen: Die Top 10. In unserem Falle die 10 Webseiten mit dem höchsten Traffic. Obwohl unsere Infrastruktur automatisch skaliert, müssen wir wissen, wenn eine Seite unnatürlich viele Requests aufweist. Den z.B. bei einer sich anbahnenden (ernsthaften) DDoS Attacke ist man auch mit 20, 30 oder 100 Servern im Loadbalancer möglicherweise hilflos. Da wir aber durch ein Kuchendiagramm eine solche Seite sofort erkennen, können wir deren Traffic innert weniger Sekunden (OK, im Stress werden’s dann vielleicht Minuten) woanders hin leiten. Hierbei kann man pragmatisch vorgehen:

piechart-example

Um ein Kuchendiagramm zu bekommen, muss man im options Objekt lediglich “graphType” auf “pie” stellen. Optional kann man mit valueLabels zwischen Prozent (percent) und absoluten Zahlen (number) wählen. Als Target wenden wir die Methode highestMax auf alle Messpunkte an. Der zweite Parameter gibt an, dass wir die 10 höchsten Messpunkte anzeigen wollen. highestMax bezieht sich hierbei auf den gesamten Zeitbereich der mit “from” und “to” angegeben wurde, zum Beispiel der letzten fünf Minuten.

Beispiele von Grafiken

Mit den erwähnten Methoden haben wir uns ein Set an einfachen Grafiken innert weniger Stunden zusammengestellt. Die API bietet natürlich noch viel mehr Möglichkeiten als das, was ich euch hier aufgezeigt habe. Mit diesen Basics kann man sich jedoch schon eine ziemlich gute Übersicht über eine Infrastruktur verschaffen.

Michael Sebel

Michael Sebel ist Software-Entwickler bei Blogwerk AG.

 

In dieser Serie

graphiti

Echtzeit-Statistiken für Webserver mit StatsD und Graphite

12.12.2012 – Vor nicht allzu langer Zeit haben wir über unsere Server-Infrastruktur berichtet. Seither können wir bis zu einem gewissen Punkt unsere Webserver in beliebiger Anzahl skalieren. Mit dem verteilten System bemerkten wir allerdings, dass Probleme und erhöhte Auslastung nur schwer nachvollziehbar sind.  Wir zeigen euch, wie wir dieses Problem mit Statistiken in Echtzeit lösen. » weiterlesen

Schreiben Sie einen Kommentar

Wir sind sehr an einer offenen Diskussion interessiert, behalten uns aber vor, beleidigende Kommentare sowie solche, die offensichtlich zwecks Suchmaschinenoptimierung abgegeben werden, zu editieren oder zu löschen. Mehr dazu in unseren Kommentarregeln.

Pflichtfelder
OK
Bitte geben Sie Ihren Namen ein.
OK
Bitte geben Sie Ihre E-Mail-Adresse ein.
OK
Bitte geben Sie einen korrekte Website ein.
OK
Bitte geben Sie einen Kommentar ein.