Worum geht es hier eigentlich?

• Egal wo wir arbeiten, wir leben von Daten
• Daten über unsere Nutzer, Daten über unsere Produkte, Daten über Verarbeitung, persönliche Daten und öffentliche Daten
• Diese Daten werden meist durch Fremdfirmen erhoben, zumindest im großen Stil:
  • Google Analytics
  • Unzählige Trackingprovider, SEO Analytics, Crash-Reporting Tools (Airbrake, Crashlytics)
  • DevOps/SysOps monitoring
    • Wichtig!
• Es gibt eine ganze Industrie, die von unserem Datenhunger lebt

Was machen wir mit all dem Zeug?

• Wohin mit all diesen Daten? Was machen wir damit?
• Beispiele:
  • Produktoptimierung
  • Frontendanpassungen wie z.B. Checkout-/Funneloptimierung
  • Debugging
  • Business-Vorhersagen
  • Date-Warehousing/BI
  • Div. andere Metriken

Zu was sollte uns das idealerweise führen?

• Entscheidungen, die nicht auf Bauchgefühlen basieren
  • Bauchgefühle sind wichtig und richtig, gerade am Anfang
  • Bauchgefühle sind zuverlässig, wenn man Erfahrung hat
  • Bauchgefühle können aber nicht komplexe Systeme durchdringen!
• Irgendwann muss man seine Entscheidungen, zum wohle der Firma und auch seiner Angestellten, auf Fakten basieren
• Und das mündet idealerweise in ...

Data Driven Products!

• Entwicklung einer Firma basierend auf deterministischen Fakten und überprüfbaren Daten und nicht auf Bauchgefühl oder Ego
  • Bauchgefühl ist immer noch wichtig, aber nur als Entscheidung in kritischen Bereichen, in denen Daten nicht nach beiden Seiten ausschlagen
• Management Buy-Ins werden leichter
  • Niemand kann so einfach gegen Zahlen und Fakten argumentieren
• Zielgerichte Entwicklung, sowohl von Software als auch der Business-Seite, spart Zeit und damit Geld, außerdem Nerven, Lebensjahre und hilft durch klare Ziele Angestellte, und vor allem Entwickler, glücklich zu machen
• Vor allem weg von der Idee, dass Logfiles das richtige Medium sind
  • EVENTS sind der bestimmende Faktor!
  • Events sind das, was wir haben wollen, weil wir darauf reagieren und mit ihnen interagieren (sie verbinden und auswerten) können
    • Nicht mehr "Uhu, da gibt es irgendwo ein Logfile für, das ist aber zu groß geworden, deswegen haben wir es gelöscht"
    • Nie wieder Daten verlieren, sondern permanent erhalten; wenn nicht auf dem eigenen Server, dann vielleicht woanders

Einfacher gesagt als getan

• Daten müssen gesammelt, ausgewertet und anschließend präsentiert werden
• Verbindungen müssen transparent sein
  • Einzelne Datenpakete für sich gesehen machen kein Modell aus, an dem man seine Entscheidungen ausrichten kann
• Man kann nicht auf alles eine Antwort geben, aber zumindest auf ein paar der Anforderungen will ich heute eine Antwort geben
  • Besonders in Richtung Daten sammeln, zusammenführen und visualisieren

Was ist fluentd?

• Was genau ist also fluentd und wie kann es uns dabei helfen Data Driven Products zu entwickeln?

• Schamlos kopiert von fluentd.org, danke!
• Im Endeffekt: Daten zusammentragen und aggregieren um sie anschließend besser verstehen zu können
• Ein Dienst, der es einfach macht verteilte Daten und Events zu sammeln und anschließend weiter zu verarbeiten
• Ist in Ruby geschrieben, nutzt MessagePack im Hintergrund für den Datenaustausch

Moooment, das kenne ich irgendwo her

• Yes! Es gibt bereits ein etabliertes Tool dafür, was ebenfalls aus der Logging-Ecke kommt

Elasticsearch Logstash Kibana

• Das ist es, wenn Leute vom ELK Stack sprechen
  • Logs werden entweder direkt oder als Files von Logstash eingelesen
  • In Elasticsearch indiziert und gespeichert
  • Und anschließend über Kibana abgefragt
• Alle Komponenten sind entweder Teil oder werden stark geförtert durch das Elasticsearch Projekt
• Sämtliche Komponenten in Java geschrieben, einzelne Teile, vor allem in Richtung Logstash können auch mit alternativen Sprachen abgebildet werden

Kibana

• http://www.elasticsearch.org/blog/kibana-4-beta-1-released/
• Aus dem offiziellen Elasticsearch Blog
• Graphen, Pie-Charts, Korrelationen, Alarme .. es ist möglich so ziemlich sämtliche Daten zu visualisieren und zusammenzutragen
• Kibana spiel aber deswegen auch eine Rolle, weil es ein fester Bestandteil des Stacks sein kann, wenn man fluentd einsetzt!

fluentd ♡ Elasticsearch + Kibana

• fluentd kann direkt im Logstash Format des Indexers schreiben, den auch Logstash verwendet!
• Ganz wichtig ist: Es geht hier nicht um schwarz und weiß, auch wenn die Präsentation das vermutet lässt, sondern um Alternativen

Direkte Integration!

<match your_app.**>
  type elasticsearch
  logstash_format true
<match>

https://github.com/uken/fluent-plugin-elasticsearch

http://docs.fluentd.org/articles/free-alternative-to-splunk-by-fluentd

• Ausschnitt aus der Konfigurationsdatei von fluentd
• Beispiel nimmt Elasticsearch Server auf localhost, Port 9200, mit Index fluentd
  • your_app.** nimmt den Tag your_app mit allen "Topics" (könnte auch your_app.important sein)
  • Unterstützt auch mehrere Elasticsearch-Server, es gibt auch ein Plugin für Cluster
• Mit Hilfe von der skalierbaren Infrastruktur von fluentd einfach und schnell nach Elasticsearch schreiben, ohne Umwege
• Mit bestehenden Systemen vereinbar
• Man kann sofort alle Vorteile von Kibana und Elasticsearch nutzen
• Aber es gibt eine große Anzahl von Input/Output Plugins, und dazwischen Filter und Buffer
• Ein paar davon möchte ich jetzt gerne vorstellen, aber es ist unmöglich alle durchzugehen, da insgesamt über 300+ vorhanden
• Wenn es eine gängige Lösung für Datenaggregation, Verarbeitung und Visualisierung gibt, fluentd hat ein Plugin dafür
• Alles andere geht über TCP/UDP/HTTP und JSON; fluentd spricht eine Menge Protokolle und am Ende JSON bzw. MessagePack

Input Plugins für

• Ruby, Rust, Go, Nodejs, PHP, Scala/Java (Agents)
• SQS, Cloudwatch
• Twitter, Flume, Scribe
• .NET, Windows System Log
• Unix Sockets, TCP, UDP, Syslog .. etc.

http://www.fluentd.org/datasources

• Ist nur eine kleine Auswahl, gibt noch viele mehr
• Schreiben von eigenen Plugins, z.B. basierend auf Regexp, sind sehr einfach und schnell erledigt
• Viele Sprachen haben direkt implementierte Agents, die man sofort verwenden kann
• fluentd läuft sogar auf Windows, wenn auch experimentell, gibt einen Branch
• Für den Rest gibt es die Möglichkeit andere Plugins zu nutzen
• Irgendwo muss man die Daten auch hintun bzw. hinschreiben

Output Plugins für

• MySQL, MongoDB, Redis, PostgreSQL
• DynamoDB, Kinesis, Redshift, SNS uvm.
• RabbitMQ, Email, Hipchat, IRC

• Es gibt eine sehr große Anzahl an Möglichkeiten, z.B. auch Elasticsearch etc.
• Der Fantasie sind keine Grenzen gesetzt
• Notifications, Monitoring, Persistenz
• Wichtiger Faktor: Die Kombination von Output-Plugins! Ein Stream aus Daten, mehrere Outputs
  • z.B. Performancedaten aus der Applikation, weitergeleitet an einen externen Service per REST, gleichzeitig persistiert in S3 oder in einer Datenbank
  • Oder kritische Loggingdaten an die Visualisierung weitergeleitet (Munin, Graphite) und gleichzeitig anhand von Triggern eine Notification (SNS, Pagerduty, Email etc.) losgetreten
  • Rohdaten persistieren, während Daten verarbeitet/gefltert und anschließend weitergeschickt werden
• Das bringt uns zu einem weiteren, wichtigen Bestandteil ...

Buffer/Parser/Filter

• Es gibt hier unzählige Möglichkeiten, um schnell und effizient eine Processing Infrastruktur aufzubauen, die fehlertolerant und agnostisch arbeitet
• Hier sind nur ein paar Beispiele
• FRAGMENT
• Fassen wir es kurz zusammen:
  • Lässt sich leicht in bestehende Infrastruktur integrieren
  • Kann mit einer großen Anzahl an Services sprechen und sie sich zu nutze machen
  • Kann effizient und schnell Daten verarbeiten
  • Wie geht's weiter?

Cool, wie fange ich an?!

Ruby und Rubygems

• fluentd selbst zu installieren, den Server, der die Daten empfängt und eventuell weiterverarbeitet oder weiterleitet (oder persistiert) ist sehr einfach, wenn man bereits mit Ruby vertraut ist
• FRAGMENT
• Selbst ohne Vorkenntnisse braucht es nur einen Ruby Interpreter und Rubygems (standardmäßig mit installiert)

Installation

$ gem install fluentd

That's it!

• Das ist es. Der Server ist installiert.
• Fluentd kennt ein interessantes Kommando, um quasi ein Demo-Setup zu erzeugen, von dem aus man dann weitergehen kann

Erstes Setup

$ fluentd --setup pfad/zu/verzeichnis

Erstellt komplette Erstkonfiguration in Verzeichnis

• Schauen wir uns diese Konfiguration mal an ..

Live Demo

• Terminal öffnen
• fluentd --setup verzeichnis ausführen
• vim fluentd.conf
• Einzelne Punkte erklären
  • Unterschied zwischen source und match erklären
  • fluentd starten und einfaches cat Beispiel zeigen
• fluentd liest und schreibt von Haus aus JSON
• Kann aber auch viele andere Formate lesen schon schreiben
• Schön und gut, aber ich will was zum Anfassen haben! ;-) ..

Direkte Daten aus Applikationen

• Als Beispiel ein App, die in Ruby geschrieben ist
  • Sehr klein und dumm, bitte nicht als Maßstab nehmen
• Könnte genau so gut in Go, PHP oder Java geschrieben, ich mag nur Ruby sehr gerne :)
• Raus zur App!

Sehr viele Möglichkeiten

• Usertracking, Movement-Protokolle
• Funnelbestimmung und Optimierung
• A/B Testing
• Fehlerkorrelation mit Deployments
• Datenanreicherung (geoip etc.)
• Es hilft von der ersten Sekunde an, wenn man Echtzeitdaten aus einer Applikation ohne Umwege auswerten kann
  • Deshalb gerade für Startups interessant..

Beispiel:

Error reporting

• Fehler in de Anwendung
  • Logging unübersichtlich
  • Events direkt über fluentd, bei wichtigen Events sofort eine Meldung
  • Alle Meldungen sortierbar und quantifizierbar in Elasticsearch
  • Vorteile: -Schnellere Responsezeit
    • Mehr Übersicht
    • Weniger Rauschen
    • Klarere Prioritäten

Beispiel:

Data Warehouse

• Keine redundanten Datenstrukturen bei mehreren Providern, die wieder zusammengeführt werden müssen
• Und wenn doch, dann direkt eine Toolchain, die das erledigen kann
• Sehr feine Auflösung in wichtigen Prozessen und Datenknoten
• Aufbereitung von Daten in Echtzeit!
  • Berechnen des Data Warehouse ist kein nächtlicher Prozess mehr, der nur ab und an klappt (über Erfahrung berichten)
  • Nichts ist so wertvoll wie tages- oder sogar stundenaktuelle Daten über Kundenverhalten und die Auswirkungen
  • Und das alles inklusive eines "Papertrail", also "wo kommen die Daten her, wann, wie usw."

Okay, aber was ist wenn das alles explodiert? ..

• Haben viel über Processing, Plugins und Effizienz gesprochen
• Was aber passiert, wenn das System mal nicht so funktioniert, wie es sollte?

OMG Enterprise features!

• ZOMG ENTERPRISE FEATURES
• Jedes mal, wenn ich "Enterprise Level Support" oder "Enterprise Level Features" höre, dann muss ich an das denken

• Vielen Dank nochmal an den Magento Entwickler, dem ich seit Jahren diese Folie raube, ohne ihn dafür zu erwähnen
• Falls sich jemand wiederfindet bitte dringend bei mir melden. Ich schulde dir mindestens ein Bier! :)

High availability

• Fluentd hat Hochverfügbarkeit "ab Werk"
• FRAGMENT
• Jede Node in einem Zweig von Instanzen kann auch jede Art von Kommunikation von anderen instanzen empfangen, zwischenspeichern, weiterleiten oder eben andere Dinge damit tun
• Fällt eine der Nodes aus, dann übernimmt die andere ohne Probleme die weitere Verarbeitung von ankommenden Paketen
• Fällt der lokale Prozess versucht das jeweilige Plugin solange weiterhin die lokale Instanz zu kontaktieren, bis eine Weiterleitung wieder möglich ist

One more thing...

• Neben all dieser Echtzeitverarbeitung gibt es natürlich auch noch eine sehr wichtige Grundfunktion ...

Logging!

• Fluentd kann eine Vielzahl an Loggingformaten lesen und schreiben, sowie per Regexp eigentlich jede Format filtern und entsprechend aufbereiten, um es zugänglich zu machen
• Entweder direkt per tail, per Syslog oder eben, wie schon vorher gesehen, direkt aus der App
• Keine Logs gehen mehr verloren, niemand muss mehr nach Zugang zu Production fragen:
  • Alle Informationen sind zugänglich!
• Habe das heute ein wenig zu kurz kommen lassen, weil das der gängiste Anwendungsfall ist und sehr gut überall beschrieben
  • Das Setup-Beispiel hat es bereits integriert gehabt für Syslog und Apache

TL;DR

• Was ist also die Quintessenz?

Technik für Tag 1

Flexibilität

Vielfältigkeit

Zuverlässigkeit

• FRAGMENT
• Sofort die richtigen Entscheidungen anhand von konkreten Daten treffen
• Es ist einfach zu installieren und zu integrieren
• Es erfordert keine tiefen Kenntnisse, um die ersten Schritte zu machen
• FRAGMENT
• Es gibt nicht länger EIN System, auf welches alles zugeschnitten ist, sondern eine flexiblen Layer, der die Integration und Anbindung einer großen Anzahl von Systemen möglich macht!
• Ob jetzt aus einem Logfile heraus, oder Daten direkt aus der Applikation streamen:
  • Anwedungsmöglichkeiten sind sehr vielfältig
• FRAGMENT
• Gleichzeitige Verarbeitung, synchrone Bearbeitungsprozesse (z.B. Persistenz und Processing)
• Einfaches und integriertes Processing, Splitting von Formaten bei gleichzeitigem Erhalt der Konsistenz
• Großartige Möglichkeiten der Visualisierung und Zusammenführung von korrelativen Daten (Kibana, Graphite, Dashing/Dashboards)
• Mehr Durchblick bei komplizierten Sachverhalten
• FRAGMENT
• Und das alles als zuverlässige Komponente in einem durchdachten System, in dem HA First Class Citizen ist
• Ausfälle sind nicht schlimm, weil sie leicht zu beheben sind
• Skalierbare Architektur:
  • Vom 1-Mann Startup hin zum kleinen und mittleren Unternehmen, oder sogar Großkonzern!
• Idealerweise führt genau diese Kombination schlussendlich zu dem Ziel, was für uns alle sehr wichtig ist

Event Focused, Data Driven Decisions!

• Der Kern der Entscheidungen ist auf Fakten begründet und führ in jeder Situation zu einem besseren Ende
• Events sind der treibende Faktor in der Analyse; das Ziel ist die Isolation und anschließende, strukturierte Zusammenführung von einzelnen Events

Die Prämisse ist wichtig

• ... nicht die Herangehensweise
• Fluentd ist nur eine Alternative, und skaliert nur bis zu einem bestimmten Punkt
  • Darüber hinaus bieten sich andere Alternativen an, auf die z.T. sogar während der Präsentation eingegangen wurde
• Weitere Alternativen wären Flume oder Splunk
• Hängt von Größe und Aufkommen der Daten ab
• Fluentd vor allem ein Produkt um früh zu starten (Startups, Freelancer), ohne große Hürden
  • Ist das Framework etabliert lässt es sich immer an die Bedürfnisse anpassen!

Dokumentation

fluentd.org / docs.fluentd.org

elasticsearch.org / logstash.org / Kibana

• Hier mehr zu den Technologien, die ich eben erwähnt habe
• Präsentation und Sample-App könnt ihr in meinem GitHub Account finden

Danke!

• github.com/moritzheiber
• @moritzheiber
• moritz.heiber@zenguard.org

• Vielen Dank für eure Zeit, ich hoffe es hat euch etwas gebracht
• Bin immer für Fragen und Anregungen offen