Warum brauchen wir Observability?

Anwendungen müssen Status- und Laufzeitinformationen bereitstellen, damit Fehler erkannt und analysiert werden können. Verteilte und dynamische Microservice Umgebungen müssen dies standardisiert umsetzen, damit ein effizienter Betrieb möglich ist.
Dieser Vortrag stellt die vier Bereiche vor, die zur Beobachtbarkeit (engl. Observability) dazugehören: Status-Informationen, Logs, Metriken und Traces. Technologie-Beispiele zu Spring Boot Actuator, Log4j, Micrometer und Prometheus zeigen, wie die Konzepte praktisch umgesetzt werden können.

Transcript

1. .consulting .solutions .partnership Warum brauchen wir Observability? Alexander Schwartz, Principal IT Consultant Talks4Nerds, 2019-08-12
2. Warum brauchen wir Observability? © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 2 Was Observablity ist 1 Überblick mit Status Informationen 2 Einblicke und Alarmierungen mit Metriken 3 Suche nach Ursachen mit Traces 4 Logs als Eventstrom mit Kontext 5 Observability als First Class Citizen 6
3. Was Observability ist 1. https://de.wikipedia.org/wiki/Fallacies_of_Distributed_Computing Verteilte und dynamische Umgebungen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 3 • Services skalieren mit dem Bedarf • Netzwerkverbindungen unzuverlässig und manchmal langsam • Netzwerkstrukturen ändern sich • Verschiedene Administratoren für Teile der Infrastruktur • Verschiedene Entwicklungsteams für unterschiedliche Services
4. Was Observability ist Monitoring vs. Observability © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 4 Monitoring zeigt eine Abweichung (Symptom). Es kann eine Alarmierung auslösen, wenn eine sofortige Aktion durch einen Menschen erforderlich ist. Observability ist zusätzlich der ganze Rest, der notwendig ist, die Ursache für die Abweichung zu finden. Observability Monitoring
5. Was Observability ist Informationen für Monitoring und Ursachenforschung © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 5 Status Informationen (Health Check) Logs (Events) Kategorie ERROR/WARN Tracing (Abhängigkeiten, Fehlerquellen, Latenzen) Metriken (Zähler, Fehlerraten, Ausführungszeiten) Logs (Events) Kategorie INFO/DEBUG Monitoring & Alerting ? Ursachenforschung & Analysen Situation war zum Entwicklungszeitpunkt bekannt Potentielle Problemstelle, Grenzwerte unklar Situation war Drittanbieter bekannt Unerwartete Situation, zusätzliche Daten für Analyse notwendig
6. Warum brauchen wir Observability? © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 6 Was Observablity ist 1 Überblick mit Status Informationen 2 Einblicke und Alarmierungen mit Metriken 3 Suche nach Ursachen mit Traces 4 Logs als Eventstrom mit Kontext 5 Observability als First Class Citizen 6
7. Überblick mit Status Informationen Gründe für Status Informationen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 7 • Liefert Daten über das System bevor der erste Aufruf durchgeführt wird (z. B. um Fehlkonfigurationen in verteilten Systemen zu finden) • Erfordert konkrete Aktion beim Empfänger (“actionable information”) • Situation kann nicht durch den Service selbst gelöst werden Beispiele: Status check Empfänger Reaktion Abhängiger Service erreichbar? Mensch Prüfe Servicekonfiguration und Netzwerk Stammdaten nicht geladen oder zu alt? Mensch Prüfe Datensynchronisation Service bereit Antworten zu liefern? Loadbalancer Lastverteilung aktualisieren
8. Warum brauchen wir Observability? © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 8 Was Observablity ist 1 Überblick mit Status Informationen 2 Einblicke und Alarmierungen mit Metriken 3 Suche nach Ursachen mit Traces 4 Logs als Eventstrom mit Kontext 5 Observability als First Class Citizen 6
9. Einblicke und Alarmierungen mit Metriken Micrometer © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 9 Micrometer [maɪˈkrɒm.ɪ.tər] ist eine Fassade (API), um in Anwendungen Metriken unabhängig vom dahinterliegenden Backend zum Speichern von Metriken zu sammeln („wie SLF4J, aber für Metriken“). • Multidimensionale Metriken • Integration mit Bibliotheken und Backend (Prometheus, Datadog, Ganglia, Graphite, JMX, New Relic, Instana, …) • Einsetzbar für jede Java-Anwendung • Sehr gut integriert in Spring Boot 1.x und 2.x Homepage: https://micrometer.io/ Lizenz: Apache 2.0
10. Einblicke und Alarmierungen mit Metriken Micrometer API © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 10 Alle Metriken haben einen Namen, optional Tags und eine Beschreibung. Metrik Typen: • Counter: Zähler, z. B. Anzahl von erfolgreichen und nicht erfolgreichen Aufrufen • Gauge: Messwert, z. B. Anzahl der aktiven Datenbank-Verbindungen • Timer: Stoppuhr, z. B. Dauer von Aufrufen Counter myOperationSuccess = Counter .builder("myOperation") .description("a description for humans") .tags("result", "success") .register(registry); myOperationSuccess.increment();
11. Einblicke und Alarmierungen mit Metriken Micrometer API © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 11 Abgeleitete Metriken: • Rate: z. B. Aufrufe pro Sekunde • Percentile: z. B. 90% aller Aufrufe sind schneller als X ms • Histogramm: z. B. X Aufrufe im Intervall von 50 bis 100 ms Histogramme können über mehrere Instanzen aggregiert werden, Perzentile nicht!
12. Einblicke und Alarmierungen mit Metriken 1. https://twitter.com/rakyll/status/1045075510538035200 A better way to explain why tail latency matters © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 12 Jaana B. Dogan (@rakyll) number of requests
13. Einblicke und Alarmierungen mit Metriken Richtung des Pfeils: Datenfluss Micrometer Architektur © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 13 Metrics Backend Meter Registry Micrometer Core 3rd Party Libraries Adapter Eigener Code Applikation
14. © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 14
15. Warum brauchen wir Observability? © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 15 Was Observablity ist 1 Überblick mit Status Informationen 2 Einblicke und Alarmierungen mit Metriken 3 Suche nach Ursachen mit Traces 4 Logs als Eventstrom mit Kontext 5 Observability als First Class Citizen 6
16. Suche nach Ursachen mit Traces Fehler und Latenzen analysieren © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 16 Der Server antwortet nicht! Manchmal ist es so langsam!
17. Suche nach Ursachen mit Traces 1. https://ai.google/research/pubs/pub36356 Konzept von Google Dapper © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 17 Trace-ID und zusätzlich Span-ID weitergeben Trace-ID vergeben
18. Suche nach Ursachen mit Traces Zentrales System sammelt und bietet eine Weboberfläche © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 18 Für jede Trace-/Span-ID: • Start-/End-Zeit Client • Start-/End-Zeit Server • Tags und Logs
19. © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz Source: https://github.com/ExpediaDotCom/haystack-ui 19
20. Warum brauchen wir Observability? © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 20 Was Observablity ist 1 Überblick mit Status Informationen 2 Einblicke und Alarmierungen mit Metriken 3 Suche nach Ursachen mit Traces 4 Logs als Eventstrom mit Kontext 5 Observability als First Class Citizen 6
21. Logs als Eventstrom mit Kontext Willkommen in der Logging-Hölle! © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 21 Log: Code: for (Invoice i : invoiceRespository.findAll()) { i.calculateTotal(); } 07:26:00.595 d.a.t.d.Invoice ERROR - can't load item ID 4711
22. Logs als Eventstrom mit Kontext Logs mit Kontextinformationen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 22 for (Invoice i : respository.findAll()) { ThreadContext.put(INVOICE_ID, Long.toString(i.getId())); try { i.calculateTotal(); } finally { ThreadContext.remove(INVOICE_ID); } }
23. Logs als Eventstrom mit Kontext Logging-Layout konfigurieren © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 23 Konfiguration: Logausgabe: <PatternLayout pattern="%d{HH:mm:ss.SSS} %X %-5level ..."/> 08:39:42.969 {invoiceId=1} ... - can't load purchase ID 4711
24. Logs als Eventstrom mit Kontext Logging-Kontext für Web-Anwendungen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 24 08:52:54.276 {http.method=GET, http.url=http://localhost:8080/api/startBillingRun, invoiceId=1, user=Theo Tester} ERROR d.a.t.d.Invoice - can't load purchase ID 4711
25. Logs als Eventstrom mit Kontext Correlation-IDs in Log-Einträgen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 25 Tracing HTTP Header: GET /api/callback HTTP/1.1 Host: localhost:8080 ... X-B3-SpanId: 34e628fc44c0cff1 X-B3-TraceId: a72f03509a36daae ... 09:20:05.840 { X-B3-SpanId=34e628fc44c0cff1, X-B3-TraceId=a72f03509a36daae, ..., invoiceId=1} ERROR d.a.t.d.Invoice - can't load purchase ID 4711 Übernahme der Information in das Log:
26. Logs als Eventstrom mit Kontext Per-Request-Debugging-Logging © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 26 1. Markiere den Trace auf Basis von Nutzer- oder HTTP-Request-Informationen 2. Nutze das Tracing-Framework, um die Markierung an nachgelagerte Knoten weiterzugeben 3. Konfiguriere das Logging-Framework Debug-Informationen für alle Requests auszugeben, die zu diesem Trace gehören <DynamicThresholdFilter key="X-B3-Flags-debug" onMatch="ACCEPT" defaultThreshold="warn" onMismatch="NEUTRAL"> <KeyValuePair key="true" value="debug"/> </DynamicThresholdFilter>
27. Logs als Eventstrom mit Kontext Logs im zentralen, durchsuchbaren Speicher © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 27 Zentraler, durchsuchbare Speicher fester Größe. Logformat vorzugsweise JSON. Alle Knoten schicken ihre Logs asynchron zu einem zentralen Speicher.
28. Warum brauchen wir Observability? © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 28 Was Observablity ist 1 Überblick mit Status Informationen 2 Einblicke und Alarmierungen mit Metriken 3 Suche nach Ursachen mit Traces 4 Logs als Eventstrom mit Kontext 5 Observability als First Class Citizen 6
29. Observability als First Class Citizen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 29 Type Statischer Knoten Dynamische und verteilte Knoten Korrelation von Events Session ID oder Thread ID Correlation ID wird zwischen Prozessen und Knoten weitergegeben
30. Observability als First Class Citizen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 30 Type Statischer Knoten Dynamische und verteilte Knoten Korrelation von Events Session ID oder Thread ID Correlation ID wird zwischen Prozessen und Knoten weitergegeben Suchen in Logs Log-Dateien und manuell konfigurierte Log-Level Zentraler Log-Server mit durchsuchbaren Logs, dynamische Log-Level und Kontext
31. Observability als First Class Citizen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 31 Type Statischer Knoten Dynamische und verteilte Knoten Korrelation von Events Session ID oder Thread ID Correlation ID wird zwischen Prozessen und Knoten weitergegeben Suchen in Logs Log-Dateien und manuell konfigurierte Log-Level Zentraler Log-Server mit durchsuchbaren Logs, dynamische Log-Level und Kontext Metriken und Monitoring Operations konfiguriert Monitoring manuell Verknüpft mit Service Discovery, Metriken werden von Anwendungsteams selbstständig hinzugefügt
32. Observability als First Class Citizen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 32 Type Statischer Knoten Dynamische und verteilte Knoten Korrelation von Events Session ID oder Thread ID Correlation ID wird zwischen Prozessen und Knoten weitergegeben Suchen in Logs Log-Dateien und manuell konfigurierte Log-Level Zentraler Log-Server mit durchsuchbaren Logs, dynamische Log-Level und Kontext Metriken und Monitoring Operations konfiguriert Monitoring manuell Verknüpft mit Service Discovery, Metriken werden von Anwendungsteams selbstständig hinzugefügt Status Informationen Einmalige Prüfung beim Start der Anwendung Verwendung für automatische Neustarts und Skalierung, Loadbalancer und Verbindungsprüfung
33. Observability als First Class Citizen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 33 Type Statischer Knoten Dynamische und verteilte Knoten Korrelation von Events Session ID oder Thread ID Correlation ID wird zwischen Prozessen und Knoten weitergegeben Suchen in Logs Log-Dateien und manuell konfigurierte Log-Level Zentraler Log-Server mit durchsuchbaren Logs, dynamische Log-Level und Kontext Metriken und Monitoring Operations konfiguriert Monitoring manuell Verknüpft mit Service Discovery, Metriken werden von Anwendungsteams selbstständig hinzugefügt Status Informationen Einmalige Prüfung beim Start der Anwendung Verwendung für automatische Neustarts und Skalierung, Loadbalancer und Verbindungsprüfung Tracing Ursache meist innerhalb des ersten Edge-Knotens Ursache für Latenz oder Fehler meist in nachgelagerten Systemen, Tracing zeigt den Weg
34. Observability als First Class Citizen © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 34 Type Statischer Knoten Dynamische und verteilte Knoten Korrelation von Events Session ID oder Thread ID Correlation ID wird zwischen Prozessen und Knoten weitergegeben Suchen in Logs Log-Dateien und manuell konfigurierte Log-Level Zentraler Log-Server mit durchsuchbaren Logs, dynamische Log-Level und Kontext Metriken und Monitoring Operations konfiguriert Monitoring manuell Verknüpft mit Service Discovery, Metriken werden von Anwendungsteams selbstständig hinzugefügt Status Informationen Einmalige Prüfung beim Start der Anwendung Verwendung für automatische Neustarts und Skalierung, Loadbalancer und Verbindungsprüfung Tracing Ursache meist innerhalb des ersten Edge-Knotens Ursache für Latenz oder Fehler meist in nachgelagerten Systemen, Tracing zeigt den Weg In dynamischen und verteilten Umgebungen werden frühere Best Practices zu neuen Essential Practices.
35. Links © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 35 Micrometer.io https://micrometer.io Prometheus https://prometheus.io Log4j https://logging.apache.org/log4j @ahus1de Google SRE Book (Kapitel „Monitoring Distributed Systems“) https://landing.google.com/sre/ Zusätzliche Folien und Videos https://www.ahus1.de/post/micrometer https://www.ahus1.de/post/logging-and-tracing https://www.ahus1.de/post/prometheus-and-grafana
36. .consulting .solutions .partnership Alexander Schwartz Principal IT Consultant +49 171 5625767 alexander.schwartz@msg.group @ahus1de msg systems ag (Headquarters) Robert-Buerkle-Str. 1, 85737 Ismaning Germany www.msg.group