Update docs to mention brave and slf4j earlier #1466
Comments
|
Also everywhere on the website is stated that Sleuth is a distributed tracing solution for Spring Cloud, but this solution is only for Brave users. |
|
Most users are not even aware of Brave. That is a good thing. Users dont
configure brave, for example.
While we can promote the brave library I dont think it is required to or is
even the right abstraction in an initial sentence.
|
|
Yes, but user MUST use brave in their app if they want to have other Spans added. So it is a Brave implementation. |
|
But this project can use any description they decide to sounds better for marketing. I am saying that I get questions why my application instrumented with other library does not work with Slueth. Because Slueth works only with "Brave". |
|
the readme says later that starting in 2.0 it works in brave. some of the
readme is out of date so needs to be cleaned up as we no longer support the
1.x series. when that is done the section saying brave will be at the top.
the first goal is to auto configure tracing and correlation for spring
cloud components. I am sorry you disagree with the order of the goals but
frankly that is the first goal. we can then say how we do that (ex with
brave and slf4j etc).
|
|
A cleanup and even later mentioning the clear compatibilities is still a good step forward because I can point to that section when I get asked about other projects working with Sleuth. Also some advance section where you mention the incoming context format that you support would be good. |
spencergibb
changed the title
|
@marcingrzejszczak I think in general this is a part of overdue cleanup as we still talk about "sr" "ss" etc. I may be wrong where I thought we don't support 1.x anymore, but I thought it isn't? Anyway :) Ideally most of this is deletion in nature, but we may want a larger issue and link this to it. @bogdandrutu In questions about trace format support, this is likely another issue if we think about how the pull request could be addressed. We already have content in our docs about how to change the implementation.. this is used by spring-cloud-gcp for example to switch to google's headers, and we also have in zipkin-aws amazon's format. Probably it could be good in a separate pull request to clarify that sleuth supports out-of-box b3 and b3 single, and also link to other formats like what's in spring-cloud-gcp My guess is that your questions are not about that, rather about the (what seems to be) stabilizing tracecontext format. As you probably know I did the first impl of that spec, as far as I know anywhere on gitub, back when I paired with @tylerbenson last year. It is important to not promote things until they are both relevant (end users asking for it, which hasn't happened yet) and until it is stable (maybe it is getting stable now). Anyway we can organize the propagation content to be more obvious that there are a few choices of trace formats today and what is out-of-box etc. For things about tracecontext in particular, we don't even have a single end user thumbsupping the change in brave, yet, or asking for it at all. I'm still cool to revise the impl but would appreciate a rewind of what changed in the last 1.5 years, and how to test if it is compatible. If you don't mind taking w3c off to this issue it would be less distracting to this repo. openzipkin/brave#693 When this becomes relevant, released, etc, of course we can link here |
While some overview is important, the direct implementation details of tracing not only drifted since Sleuth 1.x, but also caused a complaint #1466 This deletes most documentation that applies to an abstraction lower than sleuth and reworks existing docs to focus on features it enables. By doing so, we have less to maintain and users will have a clearer idea about the relationship between Sleuth, Zipkin and Brave. Also important is this uses updated screen shots and is in general less cluttered than before. Note: the relationship between Sleuth and Brave was already redone in #1603 Note: this also removes the pws app which is usually broken or out of date. Fixes #1466
While some overview is important, the direct implementation details of tracing not only drifted since Sleuth 1.x, but also caused a complaint #1466 This deletes most documentation that applies to an abstraction lower than sleuth and reworks existing docs to focus on features it enables. By doing so, we have less to maintain and users will have a clearer idea about the relationship between Sleuth, Zipkin and Brave. Also important is this uses updated screen shots and is in general less cluttered than before. Note: the relationship between Sleuth and Brave was already redone in #1603 Note: this also removes the pws app which is usually broken or out of date. Fixes #1466
In the first sentence of this project description https://github.com/spring-cloud/spring-cloud-sleuth#spring-cloud-sleuth is a bit of a "lie".
Spring cloud sleuth is only available for "Brave" client users so that needs to be corrected and a proper description that states exactly that should be used:
The text was updated successfully, but these errors were encountered: