Observability für verteilte und dynamische Microservice-Umgebungen

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

View Slide

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

Ü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
1
2
3
4
5
Das Zusammenspiel
6

View Slide

1. https://de.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
Verteilte und dynamische Umgebungen
• 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

Überblick Observability
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

Einbinden in das Monitoring
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
1
2
3
4
5
Das Zusammenspiel
6

View Slide

Health- und andere Status-Informationen
Warum Status-Informationen notwendig sind
• 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

Spring Boot Health Informationen
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

Kubernetes Liveness- und Readiness-Probe
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

Best Practices für Status-Indikatoren
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
1
2
3
4
5
Das Zusammenspiel
6

View Slide

Micrometer
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

Micrometer API
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

Micrometer API
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

Richtung des Pfeils: Datenfluss
Micrometer Architektur
Metrik
Backend
Meter
Registry
Micrometer
Core
3rd Party
Libraries
Adapter
Eigener Code
Anwendung

View Slide

Richtung des Pfeils: Datenfluss
Beispiel Infrastruktur
Grafana Prometheus Anwendung
Alert Manager
Metrik Backend
Anwendung
Anwendung

View Slide

Prometheus in verteilten Umgebungen
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

Metriken für Monitoring und Alarmierung nutzen
• 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

Best Practices für Metriken
• 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

29
1
2
3
4
5
Das Zusammenspiel
6

View Slide

Ursachen für Fehler und Latenzen finden
Der Server
antwortet nicht!
Manchmal ist es
so langsam!

View Slide

1. https://twitter.com/rakyll/status/1045075510538035200
A better way to explain why tail latency matters
Jaana B. Dogan (@rakyll)

View Slide

Konzept Dapper in der Umsetzung von Zipkin
Trace-ID und zusätzlich eine
Span-ID mitgeben
Trace-ID vergeben

View Slide

Zipkin Server empfängt Informationen und bietet eine Web-Oberfläche an
Zu jeder Trace-/Span-ID:
• Start-/Endzeit Client
• Start-/Endzeit Server
• Tags und Logs

View Slide

Web-Oberfläche Zipkin

View Slide

Sampling von Traces
• 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

Zipkin Browser-Plugin für Chrome
Vorgabe der Trace-ID
in HTTP Headern
Direkte Anzeige des
Traces in einem neuen Tab

View Slide

Best Practices für Tracing
• 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

39
1
2
3
4
5
Das Zusammenspiel
6

View Slide

Willkommen in der Logging-Hölle!
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

Logging mit Kontextinformationen
for (Invoice i : respository.findAll()) {
ThreadContext.put(INVOICE_ID, Long.toString(i.getId()));
try {
i.calculateTotal();
} finally {
ThreadContext.remove(INVOICE_ID);
}
}

View Slide

Pattern der Log-Ausgaben anpassen
Konfiguration:
Logausgabe:

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

View Slide

Log-Ausgabe für Webanwendungen
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

Correlation IDs zu Log-Einträgen hinzufügen
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

Per-Request-Debugging-Logging
• 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

Logs zentral und durchsuchbar ablegen
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

Best Practices für Logging
• Kontextinformationen verwenden
• Logs zentral ablegen
• JSON als Log-Format verwenden
• Log-Level auf Request-Ebene zur Laufzeit festlegen

View Slide

51
1
2
3
4
5
Das Zusammenspiel
6

View Slide

Das Zusammenspiel
Status Information
• 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

Das Zusammenspiel
Metrics
• 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

Das Zusammenspiel
Tracing
• 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

Das Zusammenspiel
Logging
• 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

Das Zusammenspiel
Dinge, die sich in verteilten und dynamischen Umgebungen ändern
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

Das Zusammenspiel
Korrelation von
Events
weitergegeben
Logs Log-Dateien und manuell
konfigurierte Log-Level
Zentraler Log-Server mit durchsuchbaren Logs,
dynamische Log-Level

View Slide

Das Zusammenspiel
Korrelation von
Events
weitergegeben
Metriken und
Monitoring
Manuelle konfiguriertes
Monitoring durch Operations
Einbindung in Service Discovery, Metriken durch
Teams autonom hinzugefügt

View Slide

Das Zusammenspiel
Korrelation von
Events
weitergegeben
Metriken und
Monitoring
Status Information Preflight-Check, wenn die
Anwendung startet
Verwendet für automatische Restarts, Skalierung,
Konfiguration Loadbalancers, Remote Checks

View Slide

Das Zusammenspiel
Korrelation von
Events
weitergegeben
Metriken und
Monitoring
Anwendung startet
Tracing Fehlerursache meist im Edge-
Node
Ursache für Latenz oder Fehler meist nicht im
Edge-Node, Tracing weist den Weg

View Slide

Das Zusammenspiel
Korrelation von
Events
weitergegeben
Metriken und
Monitoring
Anwendung startet
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

Links
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

.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

Observability für verteilte und dynamische Microservice-Umgebungen

Observability für verteilte und dynamische Microservice-Umgebungen

Alexander Schwartz

More Decks by Alexander Schwartz

Featured

Transcript