Spring Sleuth - Tracing Failures

Question

In einer Microservice-Umgebung sehe ich zwei Hauptvorteile durch die Verfolgung von Anfragen durch alle Microservice-Instanzen über einen gesamten Geschäftsprozess.

1. Finding Latenz Lücken zwischen oder in Dienstinstanzen
2. Finding Wurzeln von Fehlern, ob technischer oder in Bezug auf das Business Case

Mit Zipkin gibt es ein Werkzeug, das das erste Problem behebt. Aber wie kann das Tracing genutzt werden, um Fehler in Ihrer Microservice-Landschaft aufzudecken? Ich möchte definitiv alle fehlerbehafteten Spannen verfolgen, aber nicht jede Anfrage, bei der nichts schief gelaufen ist. Wie erwähnt here könnte ein benutzerdefinierter Sampler verwendet werden.

Alternativ können Sie Ihre eigene Sampler-Bean-Definition registrieren und programmatisch die Entscheidung treffen, die Anfragen abgetastet werden soll. Sie können intelligentere Entscheidungen treffen, welche Dinge zu verfolgen sind, zum Beispiel, indem Sie erfolgreiche Anfragen ignorieren, vielleicht prüfen, ob sich eine Komponente in einem Fehlerzustand befindet, oder wirklich irgendetwas anderes.

Also habe ich versucht, das zu implementieren, aber es funktioniert nicht oder ich habe es falsch verwendet. So , wie die Blog-Post vorgeschlagen registrierte ich meine eigenen Sampler:

@Bean 
    Sampler customSampler() { 
    return new Sampler() { 
     @Override 
     public boolean isSampled(Span span) { 

      boolean isErrorSpan = false; 
      for(String tagKey : span.tags().keySet()){ 
       if(tagKey.startsWith("error_")){ 
        isErrorSpan = true; 
       } 
      } 
      return isErrorSpan ; 
     } 
    }; 
} 

Und in meinem Controller erstelle ich einen neuen Span, der als Fehler markiert wird, wenn eine Ausnahme wirft

private final Tracer tracer; 

@Autowired 
public DemoController(Tracer tracer) { 
    this.tracer = tracer; 
} 

@RequestMapping(value = "/calc/{i}") 
public String calc(@PathVariable String i){ 
    Span span = null; 
    try { 
     span = this.tracer.createSpan("my_business_logic"); 
     return "1/" + i + " = " + new Float(1.0/Integer.parseInt(i)).toString(); 
    }catch(Exception ex){ 
     log.error(ex.getMessage(), ex); 

     span.logEvent("ERROR: " + ex.getMessage()); 
     this.tracer.addTag("error_" + ex.hashCode(), ex.getMessage()); 
     throw ex; 
    } 
    finally{ 
     this.tracer.close(span); 
    } 
} 

Jetzt , das funktioniert nicht. Wenn ich/calc/a anfordere, wird die Methode Sampler.isSampled (Span) aufgerufen, bevor die Controller-Methode eine NumberFormatException auslöst. Das bedeutet, wenn isSampled() den Span überprüft, hat es noch keine Tags. Und die Sampler-Methode wird später im Prozess nicht erneut aufgerufen. Nur wenn ich den Sampler öffne und erlaube, dass jeder Bereich abgetastet wird, sehe ich später meine getaggte Fehlerspanne in Zipkin. In diesem Fall wurde Sampler.isSampled (Span) nur einmal aufgerufen, aber HttpZipkinSpanReporter.report (Span) wurde dreimal ausgeführt.

Wie also würde der Anwendungsfall aussehen, nur Traces zu übertragen, die Fehlerspannen haben? Ist dies sogar eine korrekte Methode, um einen Bereich mit einem beliebigen "error_" -Tag zu versehen?

Answer 1

Die Stichprobenentscheidungsentscheidung wird für eine Ablaufverfolgung getroffen. Das heißt, wenn die erste Anfrage eingeht und die Spanne erstellt wird, müssen Sie eine Entscheidung treffen. Sie haben zu diesem Zeitpunkt keine Tags/Gepäckstücke, daher sollten Sie sich nicht auf den Inhalt der Tags verlassen, um diese Entscheidung treffen zu können. Das ist ein falscher Ansatz.

Sie nehmen einen sehr kundenspezifischen Ansatz. Wenn Sie diesen Weg gehen möchten (was nicht empfohlen wird), können Sie eine benutzerdefinierte Implementierung eines SpanReporter - https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/SpanReporter.java#L30 erstellen. SpanReporter ist derjenige, der Spannweiten an Zipkin sendet. Sie können eine Implementierung erstellen, die eine vorhandene SpanReporter Implementierung umschließt und die Ausführung nur dann an sie delegiert, wenn einige Werte von Tags übereinstimmen. Aber aus meiner Sicht klingt das nicht richtig.