Upgrade to Zipkin Reporter 3.4.0

[codefromthecrypt]

I'm only raising this manually for documentation:

Spring currently configures the Brave AsyncSpanHandler with default settings. These defaults included 3 thresholds to flush a backlog, whichever comes first.

The estimated size in bytes threshold (queuedMaxBytes=1pct memory) has been disabled by default and deprecated, due to appearing pinned when virtual threads are in use (-Djdk.tracePinnedThreads). This is effectively no impact due to the other two flush thresholds (queuedMaxSpans=10000,messageTimeout=1s), most importantly that in the default case (such as spring-boot not setting anything), you are much more likely to hit 1s timeout prior to 1pct of memory of 10k spans.

See https://github.com/openzipkin/zipkin-reporter-java/releases/tag/3.4.0 for more

Trivia time

OpenTelemetry's defaults are also in use in BatchSpanProcessorBuilder. There is no queuedMaxBytes analogue in their setup (in hindsight a good thing probably).

• otel maxQueueSize=2048 vs zipkin-reporter queuedMaxSpans=10000
• otel scheduleDelay=5s vs zipkin-reporter messageTimeout=1s

My unsolicited 2p is that the maxQueueSize=2048 while arbitrary is better than the queuedMaxSpans=10000 in zipkin-reporter.. I thought it was 10 year old from original brave, but that was 500 🤷. I raised this issue as 2048 is good, even if maybe smaller could be better.

scheduleDelay=5s might not be a great default though. I do remember changing zipkin-reporter to messageTimeout=1s, as beginning devs are impatient and wondered what was wrong prior to 5s :p

[wilkinsona]

This may have to wait for Boot 3.4 depending on whether the observability team want to upgrade to a new minor post RC1.

[codefromthecrypt]

hah maybe I over-explained and doomed it ;)

[wilkinsona]

The observability team have merged the upgrades on their side. We're good to go here.