Verwendung von Zipkin und Jaeger zur Implementierung verteilter Ablaufverfolgung in Beego
Mit der Verbreitung von Microservices ist die Entwicklung verteilter Systeme immer häufiger geworden. Allerdings bringen verteilte Systeme auch neue Herausforderungen mit sich, etwa wie man den Anfragefluss zwischen verschiedenen Diensten verfolgen kann, wie man die Leistung von Diensten analysieren und optimieren kann usw. In dieser Hinsicht sind verteilte Tracing-Lösungen zu einem immer wichtigeren Bestandteil geworden. In diesem Artikel wird erläutert, wie Sie mit Zipkin und Jaeger die verteilte Ablaufverfolgung in Beego implementieren.
Die Anforderungsverfolgung über mehrere Dienste hinweg ist das Hauptziel der verteilten Ablaufverfolgung. Zentralisierte Protokoll- oder Metrik-Streams können dieses Problem nicht lösen, da diese Streams keine Korrelation zwischen Diensten bereitstellen können. Eine Anfrage erfordert möglicherweise die Zusammenarbeit mehrerer Dienste, und diese Dienste müssen die Antwortzeiten und das Verhalten anderer Dienste kennen. Der traditionelle Ansatz besteht darin, verschiedene Metriken zu protokollieren und dann die Schwellenwerte zu lockern, um Blockierungen beim Empfang von Anfragen zu vermeiden. Dieser Ansatz kann jedoch Probleme wie Störungen und Leistungsprobleme verbergen. Die verteilte Ablaufverfolgung ist eine Lösung für die dienstübergreifende Anforderungsverfolgung. Bei diesem Ansatz generiert jeder Dienst beim Fluss einer Anforderung zwischen Diensten eine Reihe von IDs, die die gesamte Anforderung verfolgen.
Sehen wir uns an, wie Sie verteiltes Tracing in Beego implementieren.
Zipkin und Jaeger sind derzeit die beliebtesten verteilten Tracing-Lösungen. Beide Tools unterstützen die OpenTracing-API und ermöglichen es Entwicklern, Anfragen dienstübergreifend konsistent zu protokollieren und zu verfolgen.
Zuerst müssen wir Zipkin oder Jaeger installieren und starten und dann die verteilte Ablaufverfolgung in der Beego-Anwendung konfigurieren. In diesem Artikel verwenden wir Zipkin.
Zipkin installieren:
curl -sSL https://zipkin.io/quickstart.sh | bash -s java -jar zipkin.jar
Sobald Zipkin gestartet ist, können Sie über http://localhost:9411 auf die Web-Benutzeroberfläche zugreifen.
Als nächstes müssen wir Unterstützung für die OpenTracing-API in Beego hinzufügen. Wir können das Paket opentracing-go verwenden und über die bereitgestellte API dienstübergreifende Anfragen und andere Ereignisse protokollieren. Ein Beispiel für einen Tracking-Code lautet wie folgt:
import ( "github.com/opentracing/opentracing-go" ) func main() { // Initialize the tracer tracer, closer := initTracer() defer closer.Close() // Start a new span span := tracer.StartSpan("example-span") // Record some events span.SetTag("example-tag", "example-value") span.LogKV("example-key", "example-value") // Finish the span span.Finish() } func initTracer() (opentracing.Tracer, io.Closer) { // Initialize the tracer tracer, closer := zipkin.NewTracer( zipkin.NewReporter(httpTransport.NewReporter("http://localhost:9411/api/v2/spans")), zipkin.WithLocalEndpoint(zipkin.NewEndpoint("example-service", "localhost:80")), zipkin.WithTraceID128Bit(true), ) // Set the tracer as the global tracer opentracing.SetGlobalTracer(tracer) return tracer, closer }
Im obigen Beispiel initialisieren wir zunächst den Zipkin-Tracker und verwenden ihn dann zum Protokollieren einiger Ereignisse. Wir können Tags und Schlüssel-Wert-Paare hinzufügen und den Span beenden, indem wir span.Finish() aufrufen.
Jetzt fügen wir unserer Beego-Anwendung verteiltes Tracing hinzu.
Zunächst fügen wir die Abhängigkeiten opentracing-go und zipkin-go-opentracing hinzu. Wir können dies mit Go Mod oder der manuellen Installation von Paketen tun.
go get github.com/opentracing/opentracing-go go get github.com/openzipkin/zipkin-go-opentracing
Dann müssen wir den Zipkin-Tracker und die Beego-Tracker-Middleware in der Beego-Anwendung initialisieren. Das Folgende ist ein Beispielcode für die Beego-Tracer-Middleware:
import ( "net/http" "github.com/astaxie/beego" opentracing "github.com/opentracing/opentracing-go" "github.com/openzipkin/zipkin-go-opentracing" ) func TraceMiddleware() func(http.ResponseWriter, *http.Request, http.HandlerFunc) { return func(w http.ResponseWriter, r *http.Request, next http.HandlerFunc) { // Initialize the tracer tracer, closer := initTracer() defer closer.Close() // Extract the span context from the HTTP headers spanCtx, err := tracer.Extract(opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(r.Header)) if err != nil && err != opentracing.ErrSpanContextNotFound { beego.Error("failed to extract span context:", err) } // Start a new span span := tracer.StartSpan(r.URL.Path, ext.RPCServerOption(spanCtx)) // Set some tags span.SetTag("http.method", r.Method) span.SetTag("http.url", r.URL.String()) // Inject the span context into the HTTP headers carrier := opentracing.HTTPHeadersCarrier(r.Header) if err := tracer.Inject(span.Context(), opentracing.HTTPHeaders, carrier); err != nil { beego.Error("failed to inject span context:", err) } // Set the span as a variable in the request context r = r.WithContext(opentracing.ContextWithSpan(r.Context(), span)) // Call the next middleware/handler next(w, r) // Finish the span span.Finish() } } func initTracer() (opentracing.Tracer, io.Closer) { // Initialize the Zipkin tracer report := zipkinhttp.NewReporter("http://localhost:9411/api/v2/spans") defer report.Close() endpoint, err := zipkin.NewEndpoint("example-service", "localhost:80") if err != nil { beego.Error("failed to create Zipkin endpoint:", err) } nativeTracer, err := zipkin.NewTracer( report, zipkin.WithLocalEndpoint(endpoint), zipkin.WithTraceID128Bit(true)) if err != nil { beego.Error("failed to create Zipkin tracer:", err) } // Initialize the OpenTracing API tracer tracer := zipkinopentracing.Wrap(nativeTracer) // Set the tracer as the global tracer opentracing.SetGlobalTracer(tracer) return tracer, report }
Im obigen Beispielcode definieren wir eine Middleware namens TraceMiddleware. Diese Middleware extrahiert den vorhandenen Tracking-Kontext aus dem HTTP-Header (falls vorhanden) und verwendet ihn, um einen neuen Tracker für die Anfrage zu erstellen. Wir legen die Spanne auch im Anforderungskontext fest, damit alle anderen Middleware und Handler darauf zugreifen können. Nachdem die Ausführung des Handlers beendet ist, rufen wir schließlich die Methode „finish()“ für den Span auf, damit Zipkin die Abhängigkeitsverfolgung über alle angeforderten Dienste hinweg aufzeichnen kann.
Wir müssen diese Middleware auch an unseren Beego-Router anschließen. Wir können dies mithilfe des folgenden Codes im Router-Initialisierungscode tun:
beego.InsertFilter("*", beego.BeforeRouter, TraceMiddleware())
Starten Sie nun Ihre Beego-Anwendung und besuchen Sie http://localhost:9411, um die Zipkin-Benutzeroberfläche zu öffnen und die Tracking-Daten anzuzeigen.
Die Implementierung verteilter Ablaufverfolgung in Beego-Anwendungen mag kompliziert erscheinen, aber durch die Verwendung der Bibliotheken opentracing-go und zipkin-go-opentracing können wir diese Funktionalität problemlos hinzufügen. Dies wird immer wichtiger, da wir die Anzahl und Komplexität unserer Dienste weiter erhöhen. Dadurch können wir verstehen, wie unsere Dienste zusammenarbeiten, und sicherstellen, dass sie während des gesamten Anfragebearbeitungsprozesses eine gute Leistung erbringen.
Das obige ist der detaillierte Inhalt vonVerwendung von Zipkin und Jaeger zur Implementierung der verteilten Ablaufverfolgung in Beego. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!