Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Warum brauchen wir Observability?

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.

Alexander Schwartz

August 12, 2019
Tweet

More Decks by Alexander Schwartz

Other Decks in Technology

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
    [email protected]
    @ahus1de
    msg systems ag (Headquarters)
    Robert-Buerkle-Str. 1, 85737 Ismaning
    Germany
    www.msg.group

    View Slide