SpringCloud/spring-cloud-sleuth
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Restores special case that ignores sampling properties (#1619)

Browse Source 
Sleuth is unlike most tracing configuration libraries, as it has a
legacy from 1.x as being primarily log correlation. In short, when
Zipkin is not installed, it ignored the sampling properties. This
behavior was managed implicitly through an untested combination of
configuration conventions between the core and zipkin modules.

16fb8e3 broke this and this change puts it back, in a way not tightly
coupled to Zipkin and neither requires the more simple, but confusing
"import SamplerAutoConfiguration" approach. It also backfills tests
that should have broken earlier.

In practice, a site that only uses logging is likely uniform in that, so
whether or not the sampled bit is set is of no consequence. However,
there's a chance that someone might rely on this historical behavior.

We should follow-up on 3.0 and remove this as it is very unintuitive to
intentionally ignore sampling properties. For now, this restores the old
behavior based on heuristics of bean definitions.
This commit is contained in:
Adrian Cole
2020-04-23 13:09:28 +08:00
committed by GitHub
parent 16fb8e3ac6
commit eac2733c8c
5 changed files with 307 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/src/main/asciidoc/spring-cloud-sleuth.adoc
View File

@@ -305,15 +305,15 @@ Span nextSpan(final Request input) {
=== Sampling in Spring Cloud Sleuth
By default Spring Cloud Sleuth sets all spans to non-exportable.
That means that traces appear in logs but not in any remote store.
For testing the default is often enough, and it probably is all you need if you use only the logs (for example, with an ELK aggregator).
If you export span data to Zipkin, there is also an `Sampler.ALWAYS_SAMPLE` setting that exports everything, `RateLimitingSampler` setting that samples X transactions per second (defaults to `1000`) or `ProbabilityBasedSampler` setting that samples a fixed fraction of spans.
Sampling only applies to tracing backends, such as Zipkin. Trace IDs appear in logs regardless of
sample rate. Sampling is a way to prevent overloading the system, by consistently tracing some, but
not all requests.
NOTE: The `RateLimitingSampler` is the default if you use `spring-cloud-sleuth-zipkin`.
You can configure the rate limit by setting `spring.sleuth.sampler.rate`.
The default rate of 10 traces per second is controlled by the `spring.sleuth.sampler.rate`
property and applies when we know Sleuth is used for reasons besides logging. Use a rate above 100
traces per second with extreme caution as it can overload your tracing system.
A sampler can be installed by creating a bean definition, as shown in the following example:
The sampler can be set by Java Config also, as shown in the following example:
[source,java]
----
@@ -321,9 +321,7 @@ include::{project-root}/spring-cloud-sleuth-core/src/test/java/org/springframewo
----
TIP: You can set the HTTP header `X-B3-Flags` to `1`, or, when doing messaging, you can set the `spanFlags` header to `1`.
Doing so forces the current span to be exportable regardless of the sampling decision.
In order to use the rate-limited sampler set the `spring.sleuth.sampler.rate` property to choose an amount of traces to accept on a per-second interval. The minimum number is 0 and the max is 2,147,483,647 (max int).
Doing so forces the corresponding trace to be sampled regardless of the sampling configuration.
== Propagation