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

Observability für verteilte und dynamische Microservice-Umgebungen

Alexander Schwartz
November 15, 2018
120

Observability für verteilte und dynamische Microservice-Umgebungen

Anwendungen müssen Status- und Laufzeitinformationen bereitstellen, damit Fehler erkannt und analysiert werden können. Verteilte und dynamische Microservices-Umgebungen müssen dies standardisiert umsetzen, damit ein effizienter Betrieb möglich ist.

Dieser Vortrag stellt die vier Bereiche vor, die zur Beobachtbarkeit (Observability) dazugehören: Statusinformationen, Logs, Metriken und Traces. Technologiebeispiele zu Spring Boot Actuator, Log4j, Micrometer und Prometheus zeigen, wie die Konzepte praktisch umgesetzt werden können.

Alexander Schwartz

November 15, 2018
Tweet

Transcript

  1. .consulting .solutions .partnership
    Observability für Microservice-Umgebungen
    Alexander Schwartz, Principal IT Consultant
    Continuous Lifecycle Mannheim 2018-11-15

    View Slide

  2. Observability für Microservice-Umgebungen
    2
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz
    Aspekte von Observability
    1
    Health- und Status-Informationen
    2
    Analysen und Alarme mit Metriken
    3
    Fehlerursachen und Latenzen durch Tracing finden
    4
    Logs als Stream von Events
    5
    Das Zusammenspiel
    6

    View Slide

  3. Über mich – Principal IT Consultant @ msg Travel & Logistics
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 3
    15+ Jahre Java
    7 Jahre PL/SQL 7 Jahre
    Absatzfinanzierung
    3,5 Jahre Online-Banking
    7 Jahre IT-Consulting
    600+
    Geocaches
    @ahus1de

    View Slide

  4. Observability für Microservice-Umgebungen
    4
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz
    Aspekte von Observability
    1
    Health- und Status-Informationen
    2
    Analysen und Alarme mit Metriken
    3
    Fehlerursachen und Latenzen durch Tracing finden
    4
    Logs als Stream von Events
    5
    Das Zusammenspiel
    6

    View Slide

  5. Aspekte von Observability
    1. https://de.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
    Verteilte und dynamische Umgebungen
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 5
    • Services starten und stoppen um die benötigte
    Kapazität bereitzustellen
    • Netzwerke sind unerwartet nicht verfügbar und
    manchmal langsam
    • Netzwerkstrukturen verändern sich und
    Services starten auf anderen Knoten neu
    • Verschiedene Administratoren für verschiedene
    Services und Netzwerkelemente

    View Slide

  6. Aspekte von Observability
    Überblick Observability
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 6
    Known
    Knowns
    Known
    Unknowns
    Unknown
    Unknowns
    Monitoring sagt mir, dass etwas kaputt ist (Symptom). Es ist Basis für eine Alarmierung,
    wenn es eine sofortige manuelle Reaktion erfordert.
    Observability ist der ganze Rest den ich brauche um herauszufinden, warum etwas nicht funktioniert.
    Fehlersituation zum
    Entwicklungs-
    zeitpunkt bekannt
    Mögliche
    Fehlersituation,
    Schwellwerte unklar
    Unbekannte Fehlersituation,
    Informationen bei Bedarf
    Unknown
    Knowns
    Fehlersituationen,
    die in 3rd-Party-
    Entwicklern bekannt
    waren

    View Slide

  7. Aspekte von Observability
    Einbinden in das Monitoring
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 7
    Known
    Knowns
    Known
    Unknowns
    Unknown
    Unknowns
    Status
    Informationen
    (Health Check)
    Logs (Events)
    der Kategorie
    ERROR/WARN
    Tracing
    (Abhängigkeiten,
    Fehlerquellen,
    Latenzen)
    Metriken
    (Zähler, Füllstände,
    Fehlerraten,
    Ausführungszeiten)
    Logs (Events)
    der Kategorie
    INFO/DEBUG
    Monitoring & Alerting
    ?
    Analyse von Ursachen
    Unknown
    Knowns
    +

    View Slide

  8. Observability für Microservice-Umgebungen
    8
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz
    Aspekte von Observability
    1
    Health- und Status-Informationen
    2
    Analysen und Alarme mit Metriken
    3
    Fehlerursachen und Latenzen durch Tracing finden
    4
    Logs als Stream von Events
    5
    Das Zusammenspiel
    6

    View Slide

  9. Health- und andere Status-Informationen
    Warum Status-Informationen notwendig sind
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 9
    • Löst Aktionen beim Empfänger aus („Actionable“).
    • Situation kann vom Service selbst nicht verändert werden.
    • Kategorie „known knowns“ (wenn implementiert durch das Team oder von einer bekannten
    Fremdbibliothek) oder „unknown knowns“ (wenn es eine noch unbekannte Funktion in einer
    Fremdbibliothek ist).
    • Liefert Informationen schon bevor die eigentliche Verarbeitung von Anfragen startet
    (um Misskonfigurationen früh zu erkennen).
    Beispiele:
    Status check Aktion zur Behebung
    Erreichbarkeit Datenbank Prüfe Datenbank, Anwendungskonfiguration, Netzwerk
    Verbindungsprüfung Prüfe Anwendungskonfiguration, Netzwerk inklusive Firewall
    Circuit Breaker offen Prüfe Netzwerk, Antwortzeit des entfernten Service, Anzahl der Anfragen des
    eigenen Service und anderer Services

    View Slide

  10. Health- und andere Status-Informationen
    Spring Boot Health Informationen
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 10
    Typ Genutzt für Aktion
    Endpunkt liefert
    Zustandsinformationen
    Ist die Anwendung in
    einem Fehlerzustand
    oder eingeschränkt
    nutzbar?
    Abhängig vom betroffenen Subsystem ist eine
    entsprechende Aktion erforderlich.
    Beobachtung:
    • Zustand hängt von externen Services ab, die gerade starten oder wiedergestellt werden.
    • Ein Neustart des Services hilft nicht, die Situation zu verbessern.
    • Auch wenn die Anwendung eingeschränkt nutzbar ist, so kann sie Fallbacks haben.
    • Einige Spring Boot Health Checks rufen entfernte Services auf. Dies kann zu lange dauern, wenn
    Netzwerkprobleme auftreten.

    View Slide

  11. Health- und andere Status-Informationen
    Kubernetes Liveness- und Readiness-Probe
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 11
    Beobachtung 1: Die gleichen Anfragen für verschiedene Aktionen in unterschiedlichen Situationen zu
    verwenden ist eine schlechte idee.
    Beobachtung 2: Spring Boot Health passt nicht zum Kubernetes Readiness-/Liveness-Konzept,
    daher werden zusätzliche Endpunkte benötigt, die die passenden Antworten zu den von Kubernetes
    gestellten Fragen liefern.
    Typ Genutzt für Aktion
    Readiness Probe
    (beim Start)
    Konnte der Pod
    erfolgreich gestartet
    werden?
    Nach einem Timeout wird ein Pod gekillt und neu
    gestartet. Wenn er bereit ist, wird er in den
    Loadbalancer eingehängt.
    Readiness Probe
    (nach dem Start)
    Soll der Pod Anfragen
    beantworten?
    Ein- und Aushängen des Pods im Loadbalancer
    Liveness Probe Ist der Pod in einem
    definierten Zustand?
    Neustart des Pods, wenn der Zustand anhält.

    View Slide

  12. Health- und andere Status-Informationen
    Best Practices für Status-Indikatoren
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 12
    Beim Bereitstellen von Status-Indikatoren:
    • Implementiere Health-Indikatoren für alle Remote-Systeme und Konfigurationen.
    • Health-Indikatoren müssen in einer vordefinierten Zeit eine Antwort liefern (kurze Timeouts).
    • Status-Indikator für jedes Subsystem im Metrik/Monitoring-System archivieren.
    Beim Auslösen von automatischen Aktionen:
    • Spezifische Fragen stellen.
    • Passende Antworten als eine Aggregation von ggf. mehreren Indikatoren bereitstellen.

    View Slide

  13. Observability für Microservice-Umgebungen
    13
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz
    Aspekte von Observability
    1
    Health- und Status-Informationen
    2
    Analysen und Alarme mit Metriken
    3
    Fehlerursachen und Latenzen durch Tracing finden
    4
    Logs als Stream von Events
    5
    Das Zusammenspiel
    6

    View Slide

  14. Analysen und Alarme mit Metriken
    Micrometer
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 14
    Micrometer [maɪˈkrɒm.ɪ.tər] ist einer Fassade (API), mit dem in JVM-Anwendungen herstellerunabhängig
    Metriken gesammelt werden können („SLF4J, but for metrics“).
    • Multidimensionale Metriken
    • Bestehende Integrationen für Bibliotheken und Backends
    (z. B. Prometheus Datadog, Ganglia, Graphite, JMX, New Relic)
    • Fertig integriert in Spring Boot 1.x und 2.x
    • Kann unabhängig von anderen Frameworks verwendet werden
    • Version 1.0 gleichzeitig mit Spring Boot 2.0 erschienen
    • Version 1.1 gleichzeitig mit Spring Boot 2.1 erschienen
    Homepage: https://micrometer.io/
    Lizenz: Apache 2.0

    View Slide

  15. Analysen und Alarme mit Metriken
    Micrometer API
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 15
    Basis für alle Metriken: Name, optional: Tags und Beschreibung
    Ausgewählte 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

  16. Analysen und Alarme mit Metriken
    Micrometer API
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 16
    Abgeleitete Metriken:
    • Rate: z. B. Aufrufe pro Sekunde
    • Percentile: z. B. 90% aller Aufrufe sind schneller als X ms
    • Histogram: z. B. X Aufrufe im Intervall von 50 bis 100 ms
    Histogramme können über mehrere Instanzen aggregiert werden, Perzentile nicht!

    View Slide

  17. Analysen und Alarme mit Metriken
    Richtung des Pfeils: Datenfluss
    Micrometer Architektur
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 17
    Metrik
    Backend
    Meter
    Registry
    Micrometer
    Core
    3rd Party
    Libraries
    Adapter
    Eigener Code
    Anwendung

    View Slide

  18. Analysen und Alarme mit Metriken
    Richtung des Pfeils: Datenfluss
    Beispiel Infrastruktur
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 19
    Grafana Prometheus Anwendung
    Alert Manager
    Metrik Backend
    Anwendung
    Anwendung

    View Slide

  19. Analysen und Alarme mit Metriken
    Prometheus in verteilten Umgebungen
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 20
    Aufgaben:
    • Sammeln und Speichern von Metriken
    • Anfragen für Dashboards beantworten
    • Alarme und Trendberechnungen
    Gut geeignet für:
    • Auffinden von Services über Service Discovery in dynamischen Umgebungen
    • Metadaten zu gesammelten Metriken hinzufügen
    (Stage, Data Center, Cluster, Node)
    • Infrastruktur- und Applikationsmetriken zusammenbringen
    Homepage: https://prometheus.io
    License: Apache 2.0

    View Slide

  20. Analysen und Alarme mit Metriken
    Metriken für Monitoring und Alarmierung nutzen
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 24
    • Metriken direkt anzeigen
    http_server_requests_seconds_count
    • Filtern nach einem Label
    http_server_requests_seconds_count{status!='200'}
    • Aufrufrate ermitteln im 5-Minuten-Intervall
    rate (http_server_requests_seconds_count{status!='200'} [5m])
    • Verhältnis der Fehler ermitteln als gleitender Durchschnitt
    sum by (uri) (rate (http_server_requests_seconds_count {status!='200'} [5m]))
    /
    sum by (uri) (rate (http_server_requests_seconds_count [5m]))
    > 0.01

    View Slide

  21. Analysen und Alarme mit Metriken
    Best Practices für Metriken
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 28
    • Nutze die Metriken, die dein Framework anbietet.
    • Nutze Metriken bereits in den Entwicklungs- und Teststufen.
    • Wenn etwas geloggt ist, dann ist es meist eine gute Idee, auch eine Metrik dazu anzulegen.
    • Metriken sind zur Laufzeit viel effizienter als ein Log zu schreiben.

    View Slide

  22. Observability für Microservice-Umgebungen
    29
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz
    Aspekte von Observability
    1
    Health- und Status-Informationen
    2
    Analysen und Alarme mit Metriken
    3
    Fehlerursachen und Latenzen durch Tracing finden
    4
    Logs als Stream von Events
    5
    Das Zusammenspiel
    6

    View Slide

  23. Fehlerursachen und Latenzen durch Tracing finden
    Ursachen für Fehler und Latenzen finden
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 30
    Der Server
    antwortet nicht!
    Manchmal ist es
    so langsam!

    View Slide

  24. Fehlerursachen und Latenzen durch Tracing finden
    1. https://twitter.com/rakyll/status/1045075510538035200
    A better way to explain why tail latency matters
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 31
    Jaana B. Dogan (@rakyll)

    View Slide

  25. Fehlerursachen und Latenzen durch Tracing finden
    Konzept Dapper in der Umsetzung von Zipkin
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 32
    Trace-ID und zusätzlich eine
    Span-ID mitgeben
    Trace-ID vergeben

    View Slide

  26. Fehlerursachen und Latenzen durch Tracing finden
    Zipkin Server empfängt Informationen und bietet eine Web-Oberfläche an
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 33
    Zu jeder Trace-/Span-ID:
    • Start-/Endzeit Client
    • Start-/Endzeit Server
    • Tags und Logs

    View Slide

  27. Fehlerursachen und Latenzen durch Tracing finden
    Web-Oberfläche Zipkin
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 34

    View Slide

  28. Fehlerursachen und Latenzen durch Tracing finden
    Sampling von Traces
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 36
    • In Produktion sollte nur ein kleiner Prozentsatz gesammelt werden, um die Datenmenge zu reduzieren
    und die Performance nicht zu beeinträchtigen.
    Dies reicht aus, um Fehler und Latenzen zu finden.
    • Der erste Knoten entscheidet, welche Aufrufe getraced werden.
    • Tracing kann z. B. über einen HTTP-Header für einen bestimmten Aufruf aktiviert werden.
    (Dieser darf nicht über das Internet gesetzt werden, da ansonsten eine DoS-Attacke möglich wäre.)

    View Slide

  29. Fehlerursachen und Latenzen durch Tracing finden
    Zipkin Browser-Plugin für Chrome
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 37
    Vorgabe der Trace-ID
    in HTTP Headern
    Direkte Anzeige des
    Traces in einem neuen Tab

    View Slide

  30. Fehlerursachen und Latenzen durch Tracing finden
    Best Practices für Tracing
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 38
    • In Entwicklung und Test alles tracen
    • In Produktion nur einen kleinen Prozentsatz oder on-demand tracen
    • Tracing bei Incidents nutzen, um den entsprechenden Service zu identifizieren (“unknown unknowns”)
    • Generierten Abhängigkeitsbaum nutzen, um Abhängigkeiten zu finden und zu optimieren

    View Slide

  31. Observability für Microservice-Umgebungen
    39
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz
    Aspekte von Observability
    1
    Health- und Status-Informationen
    2
    Analysen und Alarme mit Metriken
    3
    Fehlerursachen und Latenzen durch Tracing finden
    4
    Logs als Stream von Events
    5
    Das Zusammenspiel
    6

    View Slide

  32. Logs als Stream von Events
    Willkommen in der Logging-Hölle!
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 40
    Log:
    Code:
    for (Invoice i : invoiceRespository.findAll()) {
    i.calculateTotal();
    }
    07:26:00.595 d.a.t.d.Invoice ERROR - can't load purchase ID 4711

    View Slide

  33. Logs als Stream von Events
    Logging mit Kontextinformationen
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 41
    for (Invoice i : respository.findAll()) {
    ThreadContext.put(INVOICE_ID, Long.toString(i.getId()));
    try {
    i.calculateTotal();
    } finally {
    ThreadContext.remove(INVOICE_ID);
    }
    }

    View Slide

  34. Logs als Stream von Events
    Pattern der Log-Ausgaben anpassen
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 42
    Konfiguration:
    Logausgabe:

    08:39:42.969 {invoiceId=1} ... - can't load purchase ID 4711

    View Slide

  35. Logs als Stream von Events
    Log-Ausgabe für Webanwendungen
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 46
    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
    Zusätzlich möglich (bei Microservices aber weniger relevant):
    • Client-IP-Adresse
    • Teil der Session-ID
    • Browser-Kennung (User Agent)

    View Slide

  36. Logs als Stream von Events
    Correlation IDs zu Log-Einträgen hinzufügen
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 47
    Zusätzliche 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
    Zusätzliche Informationen im Log:

    View Slide

  37. Logs als Stream von Events
    Per-Request-Debugging-Logging
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 48
    • Zipkin und Sleuth geben den Header X-B3-Flags weiter, der zusätzliche Informationen enthalten kann.
    • Zipkin-Chrome-Plugin gibt den Wert „1“ weiter (debug=true).
    • Ein Servlet-Filter kann den Wert entgegennehmen und in den MDC schreiben
    (zum Beispiel X-B3-Flags-debug mit dem Wert true).
    • Die folgende log4j2-Konfiguration aktiviert das TRACE-Level für alle Requests, die „true“ in diesem
    MDC-Schlüssel hinterlegt haben.
    defaultThreshold="warn" onMismatch="NEUTRAL">


    View Slide

  38. Logs als Stream von Events
    Logs zentral und durchsuchbar ablegen
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 49
    Zentrale duchsuchbare Logs
    (rotiert nach fester Datenmenge).
    JSON Format ist das einfachste
    Format, das geparst und indexiert
    werden kann.
    Alle Knoten schicken ihre Logs
    zum zentralen Server
    (asynchron)

    View Slide

  39. Logs als Stream von Events
    Best Practices für Logging
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 50
    • Kontextinformationen verwenden
    • Logs zentral ablegen
    • JSON als Log-Format verwenden
    • Log-Level auf Request-Ebene zur Laufzeit festlegen

    View Slide

  40. Observability für Microservice-Umgebungen
    51
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz
    Aspekte von Observability
    1
    Health- und Status-Informationen
    2
    Analysen und Alarme mit Metriken
    3
    Fehlerursachen und Latenzen durch Tracing finden
    4
    Logs als Stream von Events
    5
    Das Zusammenspiel
    6

    View Slide

  41. Das Zusammenspiel
    Status Information
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 52
    • Liefern Information zur Entstörung („actionable“), auch wenn keine Anfragen verarbeitet werden.
    • Notwendig für „known knowns“ Probleme bevor Nutzer Probleme melden.
    • Health-Indikatoren für alle Remote-Systeme und Konfigurationen implementieren.
    • Spezifische Fragen für automatische Aktionen formulieren.

    View Slide

  42. Das Zusammenspiel
    Metrics
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 53
    • Prüfe Antwortzeit-Perzentile und Fehlerraten, um Probleme aufzuspüren.
    • Notwendig, um „known kowns“ Probleme vor den Nutzer zu finden.
    • Frameworks haben bereits Standard-Metriken.
    • Zusätzliche fachliche Metriken benötigen manchmal nur eine einzige Zeile Code.
    • Fasse Metriken über Knotengrenzen und Umgebungen zusammen und berechne Trends.
    • Nutze die Metadaten der Service-Discovery um Metriken zu annotieren.
    • Nutze die Metrik- und Alarmierungs-Pipeline, um auch die Status-Informationen zu verarbeiten.

    View Slide

  43. Das Zusammenspiel
    Tracing
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 54
    • Nutze es, um die Quellen für Latenzen und Fehler zu finden.
    • Notwendig, um „unknown unknowns“ während eines Incidents zu finden.
    • Kann automatisch Aufrufbäume ermitteln.
    • Bietet kostenlose Correlation-IDs für die Logs.
    • Basis für Per-Request-Tracing und Per-Request-Debug-Logs.

    View Slide

  44. Das Zusammenspiel
    Logging
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 55
    • Nutze Log-Level Error/Warning, um Probleme zu signalisieren („known knowns“, „unknown knowns“).
    • Nutze Log-Level Info/Debug, um Incidents zu analysieren.
    • Konfiguriere Log-Level zur Laufzeit, inklusive Per-Request-Debugging.
    • Annotieren der Logs mit Kontext-Informationen, angefangen mit der Correlation-ID und Request-Meta-
    Daten.
    • Mache sie durchsuchbar unter Verwendung des JSON-Formats und einem zentralen Log-Store
    (Graylog oder Kibana).
    • Schreibe die Correlation-IDs in die Fehlermeldungen für User, so dass damit die passenden Log-
    Einträge direkt auffindbar sind.

    View Slide

  45. Das Zusammenspiel
    Dinge, die sich in verteilten und dynamischen Umgebungen ändern
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 56
    Typ Statische Nodes Dynamische, verteilte Multi-Nodes
    Korrelation von
    Events
    Session-ID oder Thread-ID Correlation-ID wird zwischen Prozessen und Hosts
    weitergegeben

    View Slide

  46. Das Zusammenspiel
    Dinge, die sich in verteilten und dynamischen Umgebungen ändern
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 57
    Typ Statische Nodes Dynamische, verteilte Multi-Nodes
    Korrelation von
    Events
    Session-ID oder Thread-ID Correlation-ID wird zwischen Prozessen und Hosts
    weitergegeben
    Logs Log-Dateien und manuell
    konfigurierte Log-Level
    Zentraler Log-Server mit durchsuchbaren Logs,
    dynamische Log-Level

    View Slide

  47. Das Zusammenspiel
    Dinge, die sich in verteilten und dynamischen Umgebungen ändern
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 58
    Typ Statische Nodes Dynamische, verteilte Multi-Nodes
    Korrelation von
    Events
    Session-ID oder Thread-ID Correlation-ID wird zwischen Prozessen und Hosts
    weitergegeben
    Logs Log-Dateien und manuell
    konfigurierte Log-Level
    Zentraler Log-Server mit durchsuchbaren Logs,
    dynamische Log-Level
    Metriken und
    Monitoring
    Manuelle konfiguriertes
    Monitoring durch Operations
    Einbindung in Service Discovery, Metriken durch
    Teams autonom hinzugefügt

    View Slide

  48. Das Zusammenspiel
    Dinge, die sich in verteilten und dynamischen Umgebungen ändern
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 59
    Typ Statische Nodes Dynamische, verteilte Multi-Nodes
    Korrelation von
    Events
    Session-ID oder Thread-ID Correlation-ID wird zwischen Prozessen und Hosts
    weitergegeben
    Logs Log-Dateien und manuell
    konfigurierte Log-Level
    Zentraler Log-Server mit durchsuchbaren Logs,
    dynamische Log-Level
    Metriken und
    Monitoring
    Manuelle konfiguriertes
    Monitoring durch Operations
    Einbindung in Service Discovery, Metriken durch
    Teams autonom hinzugefügt
    Status Information Preflight-Check, wenn die
    Anwendung startet
    Verwendet für automatische Restarts, Skalierung,
    Konfiguration Loadbalancers, Remote Checks

    View Slide

  49. Das Zusammenspiel
    Dinge, die sich in verteilten und dynamischen Umgebungen ändern
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 60
    Typ Statische Nodes Dynamische, verteilte Multi-Nodes
    Korrelation von
    Events
    Session-ID oder Thread-ID Correlation-ID wird zwischen Prozessen und Hosts
    weitergegeben
    Logs Log-Dateien und manuell
    konfigurierte Log-Level
    Zentraler Log-Server mit durchsuchbaren Logs,
    dynamische Log-Level
    Metriken und
    Monitoring
    Manuelle konfiguriertes
    Monitoring durch Operations
    Einbindung in Service Discovery, Metriken durch
    Teams autonom hinzugefügt
    Status Information Preflight-Check, wenn die
    Anwendung startet
    Verwendet für automatische Restarts, Skalierung,
    Konfiguration Loadbalancers, Remote Checks
    Tracing Fehlerursache meist im Edge-
    Node
    Ursache für Latenz oder Fehler meist nicht im
    Edge-Node, Tracing weist den Weg

    View Slide

  50. Das Zusammenspiel
    Dinge, die sich in verteilten und dynamischen Umgebungen ändern
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 61
    Typ Statische Nodes Dynamische, verteilte Multi-Nodes
    Korrelation von
    Events
    Session-ID oder Thread-ID Correlation-ID wird zwischen Prozessen und Hosts
    weitergegeben
    Logs Log-Dateien und manuell
    konfigurierte Log-Level
    Zentraler Log-Server mit durchsuchbaren Logs,
    dynamische Log-Level
    Metriken und
    Monitoring
    Manuelle konfiguriertes
    Monitoring durch Operations
    Einbindung in Service Discovery, Metriken durch
    Teams autonom hinzugefügt
    Status Information Preflight-Check, wenn die
    Anwendung startet
    Verwendet für automatische Restarts, Skalierung,
    Konfiguration Loadbalancers, Remote Checks
    Tracing Fehlerursache meist im Edge-
    Node
    Ursache für Latenz oder Fehler meist nicht im
    Edge-Node, Tracing weist den Weg
    Frühere Best Practices sind in verteilten Umgebungen notwendige Praktiken geworden.

    View Slide

  51. Links
    © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 62
    Micrometer.io
    https://micrometer.io
    Prometheus:
    https://prometheus.io
    Grafana
    https://grafana.com
    Log4j
    https://logging.apache.org/log4j
    Graylog
    https://www.graylog.org/ @ahus1de
    Zipkin, Brave
    https://github.com/openzipkin
    Google SRE Book (Chapter “Monitoring Distributed Systems”)
    https://landing.google.com/sre/
    Zusätzliche Folien
    https://www.ahus1.de/post/micrometer
    https://www.ahus1.de/post/logging-and-tracing
    https://www.ahus1.de/post/prometheus-and-grafana

    View Slide

  52. .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