Blog

Sascha Kranz ist Softwareentwickler bei EsPresto

Beim Betrieb von Webanwendungen fallen zahlreiche Daten an, wie zum Beispiel Performancewerte der Server, Daten zur Anwendungsgesundheit und BI-Kennzahlen. Mit den richtigen Tools können Sie diese erfassen und auswerten, um qualifizierte Entscheidungen zur Optimierung Ihrer Infrastruktur und Webanwendung zu treffen, um zum Beispiel die Performance zu verbessern und die Verfügbarkeit zu erhöhen.

 

 

Mit Hilfe dieser Daten können Antworten auf verschiedenste Fragen geliefert werden, wie zum Beispiel:

  • Wie ist die Last der Server?
  • Welcher Prozess belegt gerade so massiv die CPU-Kerne?
  • Wie ist die mittlere Antwortzeit meiner Anwendung?
  • Wie verhält sich meine Serverlandschaft bei hohem Usertraffic?
  • Wie viele fatale Fehler treten auf?
  • Wie oft antwortet die Anwendung mit 404?
  • Wie viele Bestellungen werden pro Minute abgesendet? 
  • Wie viele KundInnen nutzen das neue Feature?
  • Wann wurde auf welchen Server welche Anwendung deployed oder zurückgerollt?

 

Die anfallenden Metriken zu erfassen und mit Hilfe geeigneter Tools auszuwerten, kann in vielen Situationen hilfreich sein. Sie können die Planung zum Beispiel in Hinblick auf Serverdimensionierung auf Grund vorliegender Fakten vereinfachen. Weiterhin unterstützen Sie die Suche nach grundsätzlichen, aber auch akuten Problemen in der Anwendung oder dem Zusammenspiel zwischen Anwendung und Infrastruktur. Viele Zusammenhänge sind erst durch eine gute Visualisierung über die Zeit erkenn- und begreifbar, so dass Sie mit den geeigneten Tools Vermutungen in Wissen verwandeln können.

Dieser Beitrag ist als eine Art Metriken-Stack Durchstich zu verstehen. D.h. ich habe viele Details bewusst weggelassen, aber am Ende steht nichts desto trotz ein einsatzfähiges System zur Erfassung und Visualisierung der Metriken. Dieses kann als Basis für die schrittweise Anpassung und Erweiterung zu konkreten Anforderungen sowohl hinsichtlich Funktionalität als auch Sicherheit genutzt werden. So gelangt man schrittweise zu einem System, dass mit geeigneten Dashboards schnell und übersichtlich wichtige Informationen präsentiert und bei der Beantwortung einer Vielzahl an Fragen helfen kann.

 

 

 

Ein solcher „Stack“ besteht normalerweise mindestens aus den folgenden Bausteinen:

  • Kollektoren, zum Ermitteln und Weiterleiten von Metriken
  • einer timeseries Database, zur Speicherung der angefallenen Metriken
  • einer Visualisierung der Metriken, z.B. in Form von Graphen

 

Zusätzlich können hier nun die Grenzen zum Monitoring verwischen, indem auch noch Alerting als weitere Komponente hinzugenommen wird.

Der Metrik-Stack, den ich in diesem und den folgenden Beiträgen beschreiben möchte, basiert auf den Komponenten Graphite (Datenbank), Grafana (Visualisierung) und Collectd (Kollektor). Diese Kombination hat sich für uns mittlerweile in verschiedenen Kundenprojekten bewährt.

Das Ganze ist technisch derzeit für Debian 8 ausgelegt. Ich habe mich hier für Komponenten entschieden, die ich zum einen für relativ einfach aufsetzbar und zum anderen für alltagstauglich in vielen kleinen bis mittleren Szenarien halte.

Nun aber genug der Vorrede und rein ins Vergnügen. 

 

Graphite

Als Datenbank setzen wir hier, trotz ihres Alters, Graphite ein.


Betrachtet man alternative Lösungen, ist eine naheliegende Frage an dieser Stelle: „Warum Graphite und nicht influxdb?“. Hierbei bin ich ganz pragmatisch: Graphite tut noch immer gut, was es schon lange gut kann: timeseries data performant speichern und abfragen. Es bringt viele für das hier angestrebte Einsatzgebiet vorgesehene Funktionen mit und ist in dem hier vorgeschlagenen Setup sogar sehr einfach aufzusetzen.

Jemand, für den zum Beispiel Metriken-Metadaten einen großen Wert darstellen, sollte möglicherweise doch nochmal genauer Richtung influxdb schauen. Meine letzten Erfahrungen mit influxdb liegen nun auch schon wieder einige Monate zurück. Zu diesem Zeitpunkt war influx für mein Empfinden noch nicht ernsthaft bei halbwegs komplexen Anforderungen einsetzbar, allerdings hat sich in der Zwischenzeit aufgrund sehr aktiver Entwicklung einiges getan.


Doch nun zu Graphite:

Graphite ist ein ziemlich altes Projekt, welches aus einigen Komponenten zusammengesetzt ist und daher auch einige nicht ganz angenehme Abhängigkeiten hat.

Es lässt sich grob in etwa diese Teile zerlegen:

  1. Carbon + Whisper: die eigentliche Datenhaltung und Verwaltung in vielen Files auf der Platte
  2. Graphite HTTP API: die Schnittstelle zum Abfragen von Metriken
  3. Graphite UI: das UI zum Anzeigen von Graphen

Da wir Graphite nicht dazu nutzen wollen, Metriken anzuzeigen, sondern nur, um diese zu speichern und abzufragen, versuchen wir nur das Nötigste zu installieren, in diesem Fall also carbon + whisper und zusätzlich die HTTP API. 

 

Carbon + Whisper

Diese Komponente ist im Standard Debian Repo vorhanden und kann ganz einfach installiert werden:

apt-get install graphite-carbon

 

Nun müssen wir Carbon noch mitteilen, dass es doch bitte auch zum Bootzeitpunkt starten soll: 

# /etc/default/graphite-carbon
CARBON_CACHE_ENABLED=true
 

Abschließend empfehle ich, die Default Retention Policies anzupassen. Hier wird festgelegt, wie Carbon intern mit den angefallen Daten über die Zeit umgeht. Da wir nicht unbegrenzt Plattenplatz haben, eine Abfrage im Sekundenbereich in Daten von vor 12 Monaten nicht wichtig genug ist und die Abfrage von großen Zeiträumen in einer zu geringen Auflösung nicht performt, schlage ich folgende Default Policy vor:

# /etc/carbon/storage-schemas.conf
[default]
pattern = .*
retentions = 10s:1d,1m:7d,10m:70d,30m:180d,1h:5y

 

Dies ist nun wie folgt zu verstehen:

  • speichere die Daten des letzten Tages in einer Auflösung von 10 Sekunden
  • speichere die Daten der letzten 7 Tage in einer Auflösung von 1 Minute
  • usw.

 

Diese ersetzt nun die bestehende [default_…] Policy, so dass die jetzt getrost entfernt werden kann.

Es gibt noch eine weitere Policy „carbon“; diese ist für die interne Carbon Statistik und kann erstmal unangepasst gelassen werden.

Leider ist die Anpassung der Policies und eine entsprechende Umwandlung bereits vorhandener Daten nicht ganz trivial. Genaueres dazu findet sich unter https://z900collector.wordpress.com/2014/07/21/resizing-a-whisper-database/ . Darüber hinaus sind noch viele andere Dinge anpassbar, für den Anfang reicht dies aber bereits. Weiterführendes dazu findet sich unter http://graphite.readthedocs.io/en/latest/config-carbon.html .

 

Graphite-API

Leider können wir den API-Teil von Graphite nicht so ohne weiteres als default debian Paket installieren. Allerdings haben wir dank Bruno Renié die Möglichkeit, eine Anwendung zu installieren, die nur den HTTP API-Teil der originalen Graphite-API implementiert: https://github.com/brutasse/graphite-api . Dass das Ganze auch noch als .deb Paket vorliegt, macht es um so schöner:

# maybe you have to "apt-get install libcairo2" first
# check out the newest release: https://github.com/brutasse/graphite-api/releases and install it:
cd /tmp
wget https://github.com/brutasse/graphite-api/releases/download/1.1.2/graphite-api_1.1.2-1447943655-debian8_amd64.deb
dpkg -i graphite-api_1.1.2-1447943655-debian8_amd64.deb

 

Jetzt müssen in der Graphite-API config nur noch die Pfade angepasst werden:

# /etc/graphite-api.yaml
search_index: /var/lib/graphite/index
finders:
  - graphite_api.finders.whisper.WhisperFinder
functions:
  - graphite_api.functions.SeriesFunctions
  - graphite_api.functions.PieFunctions
whisper:
  directories:
    - /var/lib/graphite/whisper
time_zone: UTC

 

Nun noch den Suchindex anlegen: 

touch /var/lib/graphite/index
chown graphite /var/lib/graphite/index

 

Zu beachten ist hier, dass das originale Graphite durch einen Hack und das Hinzufügen einer zusätzlichen relationalen DB irgendwann dazu gebracht wurde, zu den eigentlichen Metriken auch Metadaten zu speichern. Da dies nicht Teil von Carbon + Whisper ist, steht diese Funktionalität unter Verwendung von Graphite-API im Tausch für ein deutlich leichtgewichtigeres Setup nicht zur Verfügung.

Mehr Infos zu Graphite-API findet sich unter http://graphite-api.readthedocs.io/en/latest/.

Jetzt den ganzen Zoo einmal starten:

# enable services so they start on boot
systemctl enable carbon-cache.service && systemctl enable graphite-api.service
systemctl start carbon-cache.service && systemctl start graphite-api.service
 

Damit ist der erste Teil des Metrik-Stacks abgeschlossen und wir haben die Basis für die Datenhaltung zu sammelnder Metriken geschaffen.

 

Im nächsten Blogbeitrag gehe ich auf die nächste Komponente ein - Grafana zur Visualisierung gesammelter Metriken.

Tags:
Kommentar erstellen
CAPTCHA
Bitte beantworten Sie folgende Frage:
Bild-CAPTCHA
Geben Sie die Zeichen ein, die im Bild gezeigt werden.