deagreez - stock.adobe.com
Fünf Tools für das verteilte Tracing von Microservices
DevOps- und IT-Teams nutzen verteiltes Tracing, um Microservices zu überwachen. Wir stellen fünf Tools vor, die Ihnen helfen, Systemprobleme zu erkennen und schneller zu beheben.
Verteiltes Tracing ist eine Methode für IT- und DevOps-Teams, um Anwendungen zu überwachen und Fehler in einem System aufzuspüren. Es hilft bei der Wartung von verteilten Anwendungen und Microservicearchitekturen und stellt sicher, dass alles so reibungslos wie möglich abläuft.
Verteiltes Tracing erfordert Unterstützung auf Codeebene, da es Anfragedaten sammelt, die sich zwischen Diensten bewegen. Entwickler müssen den Code einer Anwendung instrumentieren, damit Administratoren Zugriff auf Informationen haben, die für die Analyse der Anwendungsleistung und die Fehlerbehebung erforderlich sind.
Wie verteiltes Tracing funktioniert
Verteiltes Tracing arbeitet mit Traces und Spans. Trace bezeichnet den kompletten Anfrageprozess, der sich in mehrere Spans gliedert. Eine Span ist ein markiertes Zeitintervall und umfasst die Aktivität innerhalb der einzelnen Komponenten oder des Dienste eines Systems. IT-Administratoren können die Ursache eines Problems ermitteln, indem sie die einzelnen Spans prüfen.
Wenn Anwendungen mit neuen Technologien wie Containern, Cloud und Serverless immer größer werden, entstehen neue Fehlerquellen, was den Druck auf IT-Administratoren erhöht, Probleme so schnell wie möglich zu lösen.
Darüber hinaus bringen Microservices zwar Vorteile für DevOps-Teams, aber sie verringern die Systemtransparenz. Über Microservices, Teams und Funktionen hinweg verlieren Sie schnell den Überblick. Oft werden Sie Stunden damit zubringen, Probleme an der falschen Stelle zu suchen.
Verteiltes Tracing bietet einen umfassenden Überblick über das System einer Anwendung und zeigt genau auf, wo bei der Microservice-Kommunikation Fehler auftreten. Es verfolgt und protokolliert jede Anfrage, während sie die Dienste einer IT-Infrastruktur durchläuft. Mit verteiltem Tracing virtualisieren Systemarchitekten zum Beispiel die Leistung jeder Funktionsiteration. Auf diese Weise wissen IT-Teams genau, welche Funktionsinstanz die Latenz verursacht, und können eingreifen.
Verteilte Tracing-Tools
Unternehmen setzen verteilte Tracing-Tools ein, weil sie dabei helfen, Probleme präzise zu identifizieren und Serviceabhängigkeiten aufzudecken. Jaeger, Prometheus, VictoriaMetrics, Cortex und Zipkin sind allesamt verteilte Tracing-Tools, die von einzelnen Anwendungen erfasste Daten darstellen.
Cortex
Cortex bietet Unternehmen Einblick in den Status und die Qualität ihrer Microservices. Der Service unterstützt DevOps-Teams beim Erstellen von Software im großen Maßstab und stellt sicher, dass Site Reliability Engineers, Software Engineers und Entwickler mit einheitlichen Datensätzen im Bilde sind. Außerdem reduziert das zentrale Dashboard die Unübersichtlichkeit in verteilten Anwendungen.
Cortex bietet eine breite Palette von Integrationsoptionen, wie AWS, Azure DevOps, Datadog, Kubernetes und New Relic. Cortex verwendet Jaeger für verteiltes Tracing. IT-Teams müssen eine Jaeger-Bereitstellung einrichten, um Traces mit Cortex zu nutzen.
Cortex bietet außerdem Servicevorlagen, die Sie beim Implementieren von Microservices im gesamten Unternehmen unterstützen, und Administratoren das Erstellen anpassbarer Kataloge ermöglicht.
Cortex kann als einzelne Binärdatei zur einfacheren Bereitstellung oder als mehrere unabhängige Microservices für den Produktionseinsatz ausgeführt werden. Es enthält neben dem Servicekatalog auch die Cortex Query Language (CQL), mit der Sie Antworten auf den Status eines Service automatisieren und eine genaue Dokumentation führen. Cortex CQL und Integrationen fügen die gesammelten Daten zusammen, so dass IT-Teams finden können, was sie brauchen.
Cortex gibt Preise nur auf Anfrage heraus.
Jaeger
Jaeger ist ein Open-Source-System, das die Überwachung und Fehlerbehebung in microservicebasierten verteilten Systemen übernimmt. Jaeger umfasst Funktionen für die Überwachung verteilter Transaktionen, Leistungs- und Latenzoptimierung, Ursachenanalyse, Analyse von Dienstabhängigkeiten und verteilte Kontextübertragung.
Inspiriert von Dapper und OpenZipkin, bietet das Projekt ein Datenmodell im Stil von OpenTracing, adaptives Sampling, Systemtopologiegraphen und Leistungsüberwachung von Diensten. OpenTracing ist eine Methode zum Verfolgen von Transaktionen mit herstellerneutralen APIs und Instrumentierung. Dadurch stellen Sie sicher, dass alle Tracer innerhalb eines Systems nebeneinander bestehen können.
Das Backend von Jaeger, die Web-UI und die Instrumentierungsbibliotheken verwenden OpenTracing-Standards. Darüber hinaus kann Jaeger Version 1.35 Daten von OpenTelemetry SDKs (Software Development Kit) in deren nativem OpenTelemetry-Protokoll empfangen – die interne Datendarstellung und die Benutzeroberfläche folgen jedoch dem OpenTracing-Spezifikationsmodell.
Die Backend-Komponenten von Jaeger setzen standardmäßig Prometheus-Metriken zur Beobachtung ein. Sie alle sind in Go geschrieben. Jaeger unterstützt jedoch nur C#, Java, Node.js, Python und Go.
Zum Speichern bietet Jaeger standardmäßig mehrere Backends, darunter Cassandra, Elasticsearch und In-Memory-Speicher. Es lässt sich aber auch an Datenbanken anbinden. Zum Zeitpunkt der Veröffentlichung dieses Artikels plant Jaeger, in einem zukünftigen Versionsupdate eine Pipeline zur Datenverarbeitung nach der Erfassung einzubinden.
Jaeger ist als kostenloser Download erhältlich.
Prometheus
Prometheus ist ein Open-Source-Dienst, der Metriken als Zeitseriendaten sammelt und speichert. Er ruft die Daten über die HTTP-Pull-Methode in einer Zeitreihendatenbank ab. Er ist nicht auf einen verteilten Speicher angewiesen, und alle einzelnen Serverknoten sind autonom. Prometheus findet Ziele über Service Discovery oder anhand einer statischen Konfiguration.
Jeder Prometheus-Server steht für sich allein. Er ist nicht auf Netzwerkspeicher oder andere Remote-Dienste angewiesen und arbeitet daher im Falle eines Ausfalls weiter.
Prometheus kann numerische Zeitreihendaten aufzeichnen und unterstützt die plattformübergreifende Datenerfassung und -abfrage. Darüber hinaus ist es kompatibel mit mehr als 150 Systemen von Drittanbietern, wie Splunk, Kafka, Thanos, Gnocchi und Wavefront.
Prometheus ist ein Überwachungstool und eignet sich nicht zum Sammeln und Analysieren von Informationen wie Rechnungsdaten. Der Grund dafür ist, dass die gesammelten Daten nicht detailliert genug sind und keine 100 prozentige Genauigkeit bieten. Darüber hinaus hat der lokale Speicher eine Aufbewahrungsfrist von 15 Tagen, so dass für eine langfristige Speicherung externe Plattformen oder Dienste erforderlich sind.
Prometheus lässt sich kostenlos herunterladen.
VictoriaMetrics
VictoriaMetrics verarbeitet große Datenmengen und unterstützt langfristige Datenspeicher. Mit VictoriaMetrics bauen IT-Teams Überwachungsplattformen auf, ohne sich Gedanken über Skalierbarkeit oder operative Belastungen machen zu müssen. Darüber hinaus bietet VictoriaMetrics Grafana-Dashboards sowie eine einzelne Binärdatei und einen Kubernetes-Operator für die geclusterte Version.
IT-Teams führen VictoriaMetrics entweder in Docker, Kubernetes oder Bare Metal aus. Es akzeptiert Metriken in den Protokollen InfluxDB, Graphite, OpenTSDB und CSV.
VictoriaMetrics umfasst vier Produkte: VictoriaMetrics, VictoriaMetrics Enterprise, Managed VictoriaMetrics und Monitoring of Monitoring (MoM).
Die Enterprise-Version verfügt über mehr Sicherheitsoptionen und schränkt den Zugriff über Identitäten ein. Dazu gibt es Support, Downsampling, um Speicherplatz zu sparen, und mandantenfähige Statistiken, um die übermäßige Nutzung zu begrenzen und eine Überlastung des Systems zu vermeiden. Managed VictoriaMetrics läuft auf AWS und der Anbieter übernimmt für den Kunden Aufgaben wie Konfiguration, Updates oder Backups. Unternehmen können MoM und VictoriaMetrics auch nutzen, um Systemprobleme zu überwachen und Benachrichtigungen zu senden, wenn etwas schiefläuft.
VictoriaMetrics ist kostenlos. Für den Managed VictoriaMetrics-Service beträgt der Preis für Solid-State-Drive-Speicher 0,002 US-Dollar pro Einheit pro 10-GB-Stunde, für Recheneinheiten 0,25 US-Dollar pro Einheit pro vCPU-Stunde und für nach außen fließende Daten 0,09 US-Dollar pro Einheit pro GB übertragener Daten. Für die Unternehmensversion und MoM bietet VictoriaMetrics Preise auf Anfrage an.
Zipkin
Zipkin ist ein Open-Source-Projekt, das auf dem Dapper-Tool von Google basiert und bei der Erfassung von Zeitdaten zur Behebung von Latenzproblemen in verteilten Systemen hilft. Das System ist in Java implementiert und verfügt über eine OpenTracing-kompatible API. Mit Zipkin senden, empfangen, speichern und visualisieren Sie Traces sowohl innerhalb als auch zwischen Diensten.
Die Architektur von Zipkin umfasst einen Collector, der Funktionen auf Trace-Daten prüft, und einen Reporter, der Spans und Trace-Daten von Tracer-Bibliotheken zurück zu Zipkin transportiert. Es verfügt über eine Web-UI zur Anzeige von Traces und eine API für Abfragen und Extraktion von Traces. Zipkin verfügt außerdem über Trace-IDs, die jeder Anfrage zugeordnet werden und die Anfragen serviceübergreifend identifizieren. Darüber hinaus vergleicht Zipkin Traces, um festzustellen, welche Dienste oder Operationen langsamer arbeiten, als andere.
Die integrierte Benutzeroberfläche von Zipkin ist eine begrenzte und in sich geschlossene Webanwendung. Die Benutzeroberfläche bietet Abhängigkeitsdiagramme, die anzeigen, wie viele Trace-Anfragen die einzelnen Anwendungen durchlaufen haben, um den genauen Fehler zu finden.
Um Trace-Daten an Zipkin zu melden, instrumntieren IT-Administratoren Anwendungen entweder mit HTTP, Apache Kafka, Apache ActiveMQ oder gRPC. Als skalierbare Backend-Speicher unterstützt Zipkin Cassandra und Elasticsearch.
Um eine Zipkin-Instanz zu erstellen und zu betreiben, verwenden Sie Java oder Docker oder starten vom Quellcode aus.
