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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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();
    

    View Slide

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!
    

    View Slide

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
    

    View Slide

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
    

    View Slide

14. © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 14
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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
    

    View Slide

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
    

    View Slide

19. © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz
    Source: https://github.com/ExpediaDotCom/haystack-ui
    19
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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);
    }
    }
    

    View Slide

23. Logs als Eventstrom mit Kontext
    Logging-Layout konfigurieren
    © msg | August 2019 | Warum brauchen wir Observability? | Alexander Schwartz 23
    Konfiguration:
    Logausgabe:
    
    08:39:42.969 {invoiceId=1} ... - can't load purchase ID 4711
    

    View Slide

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
    

    View Slide

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:
    

    View Slide

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
    defaultThreshold="warn" onMismatch="NEUTRAL">
    
    
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide