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.

Transcript

1. .consulting .solutions .partnership Observability für Microservice-Umgebungen Alexander Schwartz, Principal IT Consultant Continuous Lifecycle Mannheim 2018-11-15
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
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
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
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
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
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 +
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
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
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.
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.
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.
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
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
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();
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!
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
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
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
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
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.
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
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!
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)
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
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
27. Fehlerursachen und Latenzen durch Tracing finden Web-Oberfläche Zipkin © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 34
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.)
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
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
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
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
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); } }
34. Logs als Stream von Events Pattern der Log-Ausgaben anpassen © msg | November 2018 | Observability für Microservice-Umgebungen | Alexander Schwartz 42 Konfiguration: Logausgabe: <PatternLayout pattern="%d{HH:mm:ss.SSS} %X %-5level ..."/> 08:39:42.969 {invoiceId=1} ... - can't load purchase ID 4711
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)
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:
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. <DynamicThresholdFilter key="X-B3-Flags-debug" onMatch="ACCEPT" defaultThreshold="warn" onMismatch="NEUTRAL"> <KeyValuePair key="true" value="trace"/> </DynamicThresholdFilter>
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)
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
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
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.
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.
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.
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.
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
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
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
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
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
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.
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
52. .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