Zipkin hat vielen Teams geholfen, ihre ersten Schritte in die verteilte Verfolgung zu machen. Es ist einfach, quelloffen und erfüllt die Grundlagen gut. Aber wenn die Systeme komplexer werden, kann sich diese Einfachheit einschränkend anfühlen. Mehr Dienste, mehr Umgebungen, mehr Störungen - und plötzlich geht es beim Tracing nicht mehr nur darum, den Pfad einer Anfrage zu sehen.
Viele Teams wünschen sich heute ein Tracing, das sich ganz natürlich in die Erstellung und Bereitstellung von Software einfügt. Weniger manuelle Einstellungen, weniger bewegliche Teile, die gewartet werden müssen, und ein besserer Kontext über Protokolle, Metriken und Infrastruktur. Hier kommen die Alternativen von Zipkin ins Spiel. Einige konzentrieren sich auf eine tiefere Beobachtbarkeit, andere auf Benutzerfreundlichkeit oder eine engere Cloud-Integration. Die richtige Wahl hängt in der Regel davon ab, wie schnell sich Ihr Team bewegt und wie viel Aufwand Sie bereit sind zu betreiben, nur um zu sehen, was in Ihrem System passiert.
1. AppFirst
AppFirst geht das Thema Rückverfolgung aus einem ungewöhnlichen Blickwinkel an. Sie versuchen nicht, Zipkin Funktion für Funktion zu ersetzen. Stattdessen behandeln sie die Beobachtbarkeit als etwas, das bereits vorhanden sein sollte, wenn eine Anwendung ausgeführt wird, und nicht als etwas, das Teams später anbringen. Tracing, Logs und Metriken sind Teil eines umfassenderen Konzepts, bei dem die Entwickler definieren, was ihre Anwendung benötigt, und die Plattform die Infrastruktur dahinter verwaltet. In der Praxis bedeutet das, dass Tracing-Daten als Teil des Anwendungslebenszyklus auftauchen und nicht als ein separates System, das jemand zusammenbasteln muss.
Was auffällt, ist, wie AppFirst die Verantwortung verlagert. Die Entwickler behalten die Verantwortung für die End-to-End-App, aber sie werden nicht in Terraform-Dateien, Cloud-Richtlinien oder Infra-Pull-Requests gezogen, nur um Sichtbarkeit zu erhalten. Für Teams, die daran gewöhnt sind, dass Zipkin als ein weiterer zu wartender Dienst läuft, kann sich dies wie ein Neustart anfühlen. Bei der Nachverfolgung geht es weniger um die Verwaltung von Kollektoren und Speicherplatz als vielmehr darum, das Verhalten im Kontext zu sehen - welcher Service, welche Umgebung und welche Kosten für den Betrieb. Es handelt sich nicht um ein reines Tracing-Tool, aber für manche Teams ist genau das der Punkt.
Wichtigste Highlights:
- Anwendungsorientierter Ansatz für Beobachtbarkeit und Infrastruktur
- Integrierte Verfolgung sowie Protokollierung und Überwachung
- Zentralisierte Prüfpfade für Infrastrukturänderungen
- Kostentransparenz in Verbindung mit Anwendungen und Umgebungen
- Funktioniert über AWS, Azure und GCP
- SaaS- und selbst gehostete Bereitstellungsoptionen
Für wen es am besten geeignet ist:
- Produktteams, die keine Rückverfolgungsinfrastruktur verwalten wollen
- Schnell liefernde Teams mit begrenzter DevOps-Bandbreite
- Unternehmen standardisieren die Bereitstellung und Überwachung von Anwendungen
- Entwickler, die eine Ablaufverfolgung wünschen, ohne Cloud-Tools zu erlernen
Kontaktinformationen:
- Website: www.appfirst.dev
2. Jaeger
Jaeger ist oft die erste ernstzunehmende Zipkin-Alternative, mit der sich Teams befassen, vor allem, wenn verteilte Systeme anfangen, unübersichtlich zu werden. Sie konzentrieren sich ganz auf die Nachverfolgung: Verfolgen von Anfragen über Dienste hinweg, Verstehen von Latenzzeiten und Erkennen, wo Dinge langsamer werden oder fehlschlagen. Jaeger bietet in der Regel mehr Kontrolle, mehr Konfigurationsoptionen und einen besseren Einblick in komplexe Dienstgraphen.
Es gibt auch einen starken Gemeinschaftsaspekt. Jaeger ist Open Source, wird offen verwaltet und ist eng mit OpenTelemetry verbunden. Das ist wichtig für Teams, die sich nicht binden oder sich auf weithin akzeptierte Standards verlassen wollen. Der Kompromiss ist der Aufwand. Um Jaeger gut zu betreiben, muss man sich Gedanken über Speicherung, Sampling und Skalierung machen. Es passt zu Teams, die sich diese Komplexität zu eigen machen und sie im Laufe der Zeit anpassen wollen, anstatt zu erwarten, dass Tracing einfach standardmäßig erscheint.
Wichtigste Highlights:
- Open-Source-Plattform zur verteilten Rückverfolgung
- Entwickelt für Microservices und komplexe Arbeitsabläufe
- Tiefe Integration mit OpenTelemetry
- Analyse der Dienstabhängigkeit und der Latenzzeit
- Aktive Gemeinschaft und langfristige Projektlaufzeit
Für wen es am besten geeignet ist:
- Ingenieurteams, die bereits Microservices in großem Umfang betreiben
- Organisationen, die sich für Open-Source-Werkzeuge einsetzen
- Teams, die eine fein abgestufte Kontrolle über das Verfolgungsverhalten wünschen
Kontaktinformationen:
- Website: www.jaegertracing.io
- Twitter: x.com/JaegerTracing
3. Grafana Tempo
Grafana Tempo geht einen anderen Weg als klassische Systeme im Zipkin-Stil. Anstatt jeden Trace zu indizieren, konzentriert man sich darauf, große Mengen an Trace-Daten kostengünstig zu speichern und sie bei Bedarf mit Metriken und Protokollen zu verknüpfen. Für Teams, die mit Zipkin an ihre Skalierungsgrenzen stoßen, kann dieser Ansatz praktischer sein, insbesondere wenn das Tracing-Volumen schneller wächst als erwartet.
Tempo wird in der Regel zusammen mit anderen Grafana-Tools verwendet, was die Art und Weise, wie Teams damit arbeiten, beeinflusst. Traces sind nicht immer das erste, was Sie allein abfragen. Stattdessen springen Ingenieure von einem metrischen Spike oder einer Protokolllinie direkt in einen Trace. Durch diesen Workflow geht es bei Tempo weniger um das Durchsuchen von Traces als vielmehr um das Verbinden von Signalen. Das funktioniert gut, wenn Sie bereits mit Grafana-Dashboards arbeiten, aber es kann sich ungewohnt anfühlen, wenn Sie erwarten, dass Tracing eine eigenständige Erfahrung ist.
Wichtigste Highlights:
- Großes Tracing-Backend für die Objektspeicherung
- Unterstützt Zipkin-, Jaeger- und OpenTelemetry-Protokolle
- Enge Integration mit Grafana, Loki und Prometheus
- Entwickelt für die Verarbeitung sehr großer Spurenmengen
- Open Source mit Selbstverwaltungs- und Cloud-Optionen
Für wen es am besten geeignet ist:
- Systeme, die große Mengen an Trace-Daten erzeugen
- Organisationen, die sich auf kosteneffiziente Langzeitspeicherung konzentrieren
- Ingenieure, die Spuren mit Protokollen und Metriken korrelieren, anstatt nur Spuren zu durchsuchen
Kontaktinformationen:
- Website: grafana.com
- Facebook: www.facebook.com/grafana
- Twitter: x.com/grafana
- LinkedIn: www.linkedin.com/company/grafana-labs
4. SigNoz
SigNoz wird gemeinhin als Alternative zum unabhängigen Betrieb von Zipkin angesehen. Es behandelt das Tracing als Teil eines größeren Beobachtungsansatzes und integriert es mit Protokollen und Metriken, anstatt es separat zu halten. Für Teams, die ursprünglich Zipkin verwendet und später andere Tools integriert haben, wird SigNoz oft relevant, wenn sich ihr Toolset unzusammenhängend anfühlt. Sein Design dreht sich von Anfang an um OpenTelemetry und beeinflusst die Datenerfassung und die verschiedenen Signale beim Debugging.
Die Teams erkennen schnell die Vorteile des Workflows. Anstatt zwischen verschiedenen Tracing-, Logging- und Metrics-Tools zu wechseln, hält SigNoz diese Ansichten integriert. Ein langsamer Endpunkt kann direkt zu einem Trace und dann zu den zugehörigen Protokollen führen, ohne dass der Kontext verloren geht. Es ist nicht so leichtgewichtig wie Zipkin, was ein Kompromiss ist. Sie erhalten mehr Kontext, haben aber auch ein größeres System zu bedienen. Einige Teams finden dies akzeptabel, da ihre Systeme über die grundlegenden Anforderungen an die Ablaufverfolgung hinausgehen.
Wichtigste Highlights:
- OpenTelemetry-natives Design für Traces, Protokolle und Metriken
- Verwendet eine spaltenförmige Datenbank für die Verarbeitung von Beobachtbarkeitsdaten
- Kann selbst gehostet oder als verwalteter Dienst genutzt werden
- Schwerpunkt auf der Korrelation von Signalen während der Fehlersuche
Für wen es am besten geeignet ist:
- Teams, die OpenTelemetry bereits dienstübergreifend nutzen
- Ingenieure, die es leid sind, mehrere Beobachtungstools miteinander zu verknüpfen
- Teams, die mit einem breiteren Observability-Stack zurechtkommen
Kontaktinformationen:
- Website: signoz.io
- Twitter: x.com/SigNozHQ
- LinkedIn: www.linkedin.com/company/signozio
5. OpenTelemetry
OpenTelemetry ist kein einzelnes Tool, das man einsetzt, sondern bietet eine gemeinsame Sprache für die Erstellung und Weitergabe von Traces, Metriken und Protokollen. Viele Teams ersetzen Zipkin durch die Standardisierung auf OpenTelemetry für die Instrumentierung und wählen dann später ein Backend.
Dieser Ansatz verändert die Art und Weise, wie Entscheidungen zur Rückverfolgung getroffen werden. Anstatt sich frühzeitig auf ein System festzulegen, instrumentieren die Teams einmal und halten sich ihre Optionen offen. Ein Dienst kann damit beginnen, Traces an ein einfaches Backend zu senden und später zu einem fortschrittlicheren System wechseln, ohne den Anwendungscode zu berühren. Diese Flexibilität ist verlockend, aber sie ist auch mit Verantwortung verbunden. Jemand muss immer noch entscheiden, wohin die Daten gehen und wie sie gespeichert werden. OpenTelemetry nimmt diese Arbeit nicht ab, es vermeidet nur harte Abhängigkeiten.
Wichtigste Highlights:
- Herstellerunabhängige APIs und SDKs für Verfolgung, Protokolle und Metriken
- Unterstützt viele Sprachen und Frameworks von Haus aus
- Entwickelt, um mit mehreren Backends zu arbeiten, nicht um sie zu ersetzen
- Offener Quellcode mit gemeinschaftsgesteuerter Entwicklung
Für wen es am besten geeignet ist:
- Teams, die eine Abkehr von Zipkin ohne Backend-Bindung planen
- Organisationen, die ihre Instrumentierung dienstübergreifend standardisieren
- Ingenieurgruppen, die Flexibilität bei der Entwicklung von Beobachtungsinstrumenten wünschen
Kontaktinformationen:
- Website: opentelemetry.io
6. Uptrace
Uptrace wird in der Regel in Betracht gezogen, wenn Teams mehr als Zipkin wollen, aber nicht selbst einen vollständigen Observability-Stack zusammenstellen wollen. Sie konzentrieren sich stark auf verteiltes Tracing, halten aber Metriken und Protokolle nahe genug, dass das Debugging praktisch bleibt. Traces werden auf eine Art und Weise gespeichert und abgefragt, die auch dann gut funktioniert, wenn einzelne Anfragen groß werden, was von Bedeutung ist, wenn Dienste beginnen, sich über viele Abhängigkeiten zu verteilen.
Eine Sache, die hervorsticht, ist, wie Uptrace Kontrolle und Bequemlichkeit ausbalanciert. Teams können es selbst betreiben oder ein verwaltetes Setup verwenden, aber die Erfahrung bleibt ziemlich ähnlich. Ingenieure beschreiben den Wechsel von Zipkin oft als weniger schmerzhaft als erwartet, vor allem weil OpenTelemetry die Instrumentierung übernimmt und Uptrace sich auf das konzentriert, was nach dem Eintreffen der Daten passiert. Uptrace fühlt sich eher wie ein Tracing-First-System als eine All-in-One-Plattform an, was einige Teams bevorzugen.
Wichtigste Highlights:
- Verteiltes Tracing auf Basis von OpenTelemetry
- Unterstützt große Spuren mit vielen Spannweiten
- Funktioniert sowohl als selbstgehostete als auch als verwaltete Option
- Traces, Metriken und Protokolle an einem Ort verfügbar
Für wen es am besten geeignet ist:
- Systeme mit komplexen Anforderungspfaden und großen Spuren
- Ingenieure, die OpenTelemetry wünschen, ohne alles selbst zu entwickeln
Kontaktinformationen:
- Website: uptrace.dev
- E-Mail: support@uptrace.dev
7. Apache SkyWalking
Apache SkyWalking wird in der Regel in Betracht gezogen, wenn Zipkin für die täglichen Anforderungen von Teams zu eng wird. Sie behandeln Tracing als Teil eines umfassenderen Bildes der Anwendungsleistung, insbesondere für Microservices und Kubernetes-basierte Systeme. Anstatt sich nur auf die Anforderungspfade zu konzentrieren, befasst sich SkyWalking mit der Topologie der Dienste, den Abhängigkeitsansichten und dem Verhalten der Dienste als Ganzes. In der Praxis nutzen Teams diese Funktion häufig, um Fragen zu beantworten, z. B. warum ein Dienst alles andere verlangsamt, und nicht nur, wo ein einzelner Trace fehlgeschlagen ist.
Das Besondere an SkyWalking ist, dass es versucht, so viel wie möglich an einem Ort abzudecken. Traces, Metriken und Logs können alle durch dasselbe System fließen, auch wenn sie aus verschiedenen Quellen wie Zipkin oder OpenTelemetry stammen. Diese Breite kann nützlich sein, aber sie bedeutet auch, dass SkyWalking am besten funktioniert, wenn jemand die Verantwortung dafür übernimmt.
Wichtigste Highlights:
- Verteilte Rückverfolgung mit Ansichten der Diensttopologie
- Entwickelt für Microservices und containerlastige Umgebungen
- Unterstützt mehrere Telemetrieformate einschließlich Zipkin und OpenTelemetry
- Agenten für eine breite Palette von Sprachen verfügbar
- Integrierte Alarmierungs- und Telemetrie-Pipelines
- Native Beobachtbarkeitsdatenbank-Option
Für wen es am besten geeignet ist:
- Teams, die komplexe Microservice-Architekturen betreiben
- Umgebungen, in denen Dienstleistungsverhältnisse ebenso wichtig sind wie individuelle Spuren
- Organisationen, die Rückverfolgung und APM in einem System wünschen
- Ingenieurteams, die mit der Verwaltung einer größeren Observabilitätsplattform vertraut sind
Kontaktinformationen:
- Website: skywalking.apache.org
- Twitter: x.com/asfskywalking
- Anschrift: 1000 N West Street, Suite 1200 Wilmington, DE 19801 USA
8. Datadog
Datadog betrachtet die Zipkin-Alternativen aus dem Blickwinkel einer Plattform. Verteiltes Tracing steht neben Logs, Metriken, Profiling und einer langen Liste anderer Signale. Teams kommen in der Regel zu Datadog, wenn Zipkin zwar einige Fragen beantwortet, aber zu viele Lücken in Bezug auf den Kontext hinterlässt, insbesondere wenn Systeme mehrere Clouds oder Teams umfassen.
In der Praxis zeigt sich das Datadog-Tracing oft bei der Überprüfung von Vorfällen. Jemand beginnt mit einer langsamen Benutzeraktion, folgt dem Trace und springt dann zu Protokollen oder Infrastrukturmetriken, ohne das Tool zu wechseln. Diese Bequemlichkeit kommt daher, dass alles eng integriert ist, aber es bedeutet auch, dass Datadog weniger modular ist als Open Source Tracing Tools. Sie übernehmen Tracing als Teil eines breiteren Ökosystems, nicht als eigenständigen Service.
Wichtigste Highlights:
- Verteiltes Tracing mit integrierten Protokollen und Metriken
- Unterstützung von Auto-Instrumenten für viele Sprachen
- Visuelle Trace-Exploration mit Service- und Abhängigkeitsansichten
- Korrelation zwischen Anwendungs- und Infrastrukturdaten
Für wen es am besten geeignet ist:
- Teams, die eine enge Verknüpfung der Rückverfolgung mit anderen Beobachtungsdaten wünschen
- Organisationen, die große oder gemischte Cloud-Umgebungen verwalten
- Ingenieurgruppen, die eine einzige Plattform gegenüber mehreren Tools bevorzugen
Kontaktinformationen:
- Website: www.datadoghq.com
- E-Mail: info@datadoghq.com
- Twitter: x.com/datadoghq
- LinkedIn: www.linkedin.com/company/datadog
- Instagram: www.instagram.com/datadoghq
- Anschrift: 620 8th Ave 45th Floor New York, NY 10018 USA
- Telefon: 866 329 4466
9. Wabe
Honeycomb konzentriert sich stark auf Daten mit hoher Kardinalität und darauf, dass die Ingenieure im Nachhinein Fragen stellen und nicht nur vordefinierte Dashboards anzeigen können. Die Ablaufverfolgung in Honeycomb ist tendenziell explorativ. Man klickt sich in einen Trace ein, unterteilt ihn nach benutzerdefinierten Feldern und folgt eher Mustern als einzelnen Fehlern.
Die Erfahrung ist eher investigativ als operativ. Teams beschreiben Honeycomb manchmal als etwas, das sie öffnen, wenn sich ein Problem seltsam anfühlt oder schwer zu reproduzieren ist. Das macht es zu einer guten Lösung für die Fehlersuche bei unbekanntem Verhalten, aber es kann sich anders anfühlen als herkömmliche Überwachungstools. Man sieht nicht nur zu, wie die Spuren vorbeiziehen. Man geht ihnen auf den Grund.
Wichtigste Highlights:
- Verteiltes Tracing auf der Grundlage von Daten mit hoher Kardinalität
- Starker Fokus auf explorative Debugging-Workflows
- Enge Integration mit OpenTelemetry-Instrumenten
- Trace-Ansichten für die teamweite Untersuchung
Für wen es am besten geeignet ist:
- Teams, die komplexes oder unvorhersehbares Systemverhalten debuggen
- Ingenieurskulturen, die tiefgreifende Untersuchungen den Dashboards vorziehen
Kontaktinformationen:
- Website: www.honeycomb.io
- LinkedIn: www.linkedin.com/company/honeycomb.io
10. Wache
Sentry betrachtet die Diskussion um den Zipkin-Ersatz eher aus dem Blickwinkel der Fehlersuche. Sie konzentrieren sich darauf, Traces mit realen Anwendungsproblemen wie langsamen Endpunkten, fehlgeschlagenen Hintergrundjobs oder Abstürzen zu verbinden, auf die Benutzer tatsächlich stoßen. Tracing wird nicht als eigenständige Karte von Diensten behandelt, sondern als Kontext zu Fehlern und Leistungsproblemen. Ein Entwickler, der z. B. einen langsamen Checkout-Flow verfolgt, kann von einer Frontend-Aktion in Backend-Spans springen und sehen, wo die Zeit verschwindet.
Was Sentry von anderen unterscheidet, ist die Meinungsbildung im Workflow. Anstatt Traces um ihrer selbst willen zu durchsuchen, landen Teams in der Regel durch Probleme, Warnungen oder Regressionen nach einem Deployment auf Traces. Das kann für produktorientierte Teams erfrischend sein, ist aber weniger attraktiv, wenn Sie Tracing als neutrale Infrastrukturansicht nutzen möchten. Sentry funktioniert am besten, wenn Tracing Teil des täglichen Debugging ist und nicht etwas, das nur SREs öffnen.
Wichtigste Highlights:
- Verteiltes Tracing in enger Verbindung mit Fehlern und Leistungsproblemen
- End-to-End-Kontext von Frontend-Aktionen zu Backend-Diensten
- Metriken auf Spannebene für Latenz und Fehlerverfolgung
- Mit Deployments und Codeänderungen verbundene Traces
Für wen es am besten geeignet ist:
- Produktteams bei der Behebung echter Benutzerprobleme
- Entwickler, die eine direkt mit Fehlern verbundene Rückverfolgung wünschen
- Teams, die sich mehr um die Behebung von Problemen kümmern als um die Erforschung von Servicekarten
Kontaktinformationen:
- Website: sentry.io
- Twitter: x.com/sentry
- LinkedIn: www.linkedin.com/company/getsentry
- Instagram: www.instagram.com/getsentry
11. Bindestrich0
Dash0 positioniert Tracing als etwas, das schnell nutzbar sein sollte, und nicht als etwas, das man wochenlang pflegt. Sie bauen alles auf OpenTelemetry auf und gehen davon aus, dass die Teams bereits eine Standardinstrumentierung anstelle von herstellerspezifischen Agenten wünschen. Traces, Logs und Metriken werden gemeinsam präsentiert, aber Tracing fungiert oft als das Rückgrat, das alles andere miteinander verbindet. Die Ingenieure beginnen in der Regel mit einer verdächtigen Anfrage und weiten sich von dort aus.
Die Erfahrung ist absichtlich rationalisiert. Das Filtern von Traces nach Attributen ähnelt eher der Suche nach Code als der Konfiguration von Dashboards, und die Konfiguration als Code wird früh im Arbeitsablauf angezeigt. Bei Dash0 geht es weniger um langfristige historische Analysen als vielmehr um schnelle Antworten während der Entwicklung und bei Zwischenfällen. Das macht es für Teams interessant, die herkömmliche Observability-Tools als schwerfällig oder langsam in der Navigation empfinden.
Wichtigste Highlights:
- OpenTelemetry - nativ für Traces, Protokolle und Metriken
- Filterung von Spuren mit hoher Kardinalität und schnelle Suche
- Configuration-as-code-Unterstützung für Dashboards und Warnmeldungen
- Enge Korrelation zwischen Signalen ohne manuelle Verdrahtung
Für wen es am besten geeignet ist:
- Teams, die bereits auf OpenTelemetry standardisiert sind
- Ingenieure, die schnelle Untersuchungen komplexen Dashboards vorziehen
- Plattformteams, die wollen, dass Beobachtbarkeit wie Code behandelt wird
Kontaktinformationen:
- Website: www.dash0.com
- E-Mail: hi@dash0.com
- Twitter: x.com/dash0hq
- LinkedIn: www.linkedin.com/company/dash0hq
- Anschrift: 169 Madison Ave STE 38218 New York, NY 10016 Vereinigte Staaten
12. Elastisches APM
Elastic APM ersetzt oft Zipkin, wenn die Rückverfolgung neben der Suche, den Protokollen und weiteren Systemdaten stattfinden soll. Sie behandeln verteiltes Tracing als ein Signal in einem größeren Observability-Setup, das auf dem Datenmodell von Elastic aufbaut. Traces können über Dienste hinweg verfolgt und dann mit Protokollen, Metriken oder sogar benutzerdefinierten Feldern korreliert werden, die Teams bereits in Elastic speichern.
Was hervorsticht, ist die Flexibilität. Elastic APM funktioniert gut in gemischten Umgebungen, in denen einige Dienste modern sind und andere nicht. Tracing zwingt nicht zu einem "clean-slate"-Ansatz. Teams können schrittweise instrumentieren, OpenTelemetry-Daten einbringen und alles über eine vertraute Schnittstelle analysieren. Es ist nicht minimal, aber es skaliert natürlich für Organisationen, die Elastic bereits aus anderen Gründen nutzen.
Wichtigste Highlights:
- Verteiltes Tracing mit integrierten Protokollen und Suche
- Unterstützung von OpenTelemetry-basierter Instrumentierung
- Analyse der Dienstabhängigkeit und der Latenzzeit
- Funktioniert mit modernen und älteren Anwendungen
Für wen es am besten geeignet ist:
- Organisationen mit unterschiedlichen oder schwerfälligen Altsystemen
- Ingenieure, die eine mit der Suche und den Protokollen verbundene Rückverfolgung wünschen
Kontaktinformationen:
- Website: www.elastic.co
- E-Mail: info@elastic.co
- Facebook: www.facebook.com/elastic.co
- Twitter: x.com/elastic
- LinkedIn: www.linkedin.com/company/elastic-co
- Anschrift: 5 Southampton Street London WC2E 7HA
13. Kamon
Kamon konzentriert sich darauf, Entwicklern zu helfen, Latenzzeiten und Ausfälle zu verstehen, ohne dass sie dafür tiefgreifende Überwachungskenntnisse benötigen. Tracing wird mit Metriken und Protokollen kombiniert, aber die Benutzeroberfläche lenkt die Aufmerksamkeit der Benutzer auf praktische Fragen, z. B. welcher Endpunkt langsamer geworden ist oder welcher Datenbankaufruf nach einer Bereitstellung einen Spitzenwert verursacht hat.
Es gibt auch einen starken Fokus auf spezifische Ökosysteme. Kamon passt natürlich in Stacks, die mit Akka, Play oder JVM-basierten Diensten aufgebaut sind, wo die automatische Instrumentierung die Reibung bei der Einrichtung reduziert. Im Vergleich zu breiteren Plattformen fühlt sich Kamon schmaler an, aber das kann ein Vorteil sein. Teams nehmen es oft an, weil es ihre täglichen Fragen beantwortet, ohne dass sie ihren Überwachungsansatz neu gestalten müssen.
Wichtigste Highlights:
- Verteiltes Tracing mit Schwerpunkt auf Backend-Diensten
- Starke Unterstützung für JVM- und Scala-basierte Stacks
- Korrelierte Metriken und Traces für die Latenzanalyse
- Minimaler Aufwand für Infrastruktur und Einrichtung
Für wen es am besten geeignet ist:
- Backend-lastige Entwicklungsteams
- JVM- und Akka-basierte Systeme
- Entwickler, die einfaches, praktisches Tracing ohne komplexe Tools wünschen
Kontaktinformationen:
- Website: kamon.io
- Twitter: x.com/kamonteam
Schlussfolgerung
Zusammenfassend lässt sich sagen, dass es bei der Umstellung auf Zipkin weniger darum geht, Funktionen zu finden, sondern vielmehr darum, zu entscheiden, wie die Ablaufverfolgung in die tägliche Arbeit integriert werden soll. Einige Teams möchten Traces eng mit Fehlern und Deploys verknüpfen, damit die Fehlersuche nah am Code bleibt. Anderen ist es wichtiger zu sehen, wie Dienste im großen Maßstab interagieren, oder Traces mit Logs und Metriken zu vereinen, ohne mit verschiedenen Tools zu jonglieren.
Was bei diesen Alternativen auffällt, ist, dass es keinen einzigen Upgrade-Pfad gibt, der für alle geeignet ist. Die richtige Wahl hängt in der Regel davon ab, wie ein Team Software entwickelt, ausliefert und korrigiert, und nicht davon, wie beeindruckend eine Tracing-Oberfläche aussieht.
