Provide starters for micrometer-tracing

[mhalbritter]

Getting all the dependencies right for various tracing options is no easy task. We should provide starters to make that easier for users.

For example, using Brave + Zipkin, we need:

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
	<groupId>io.micrometer</groupId>
	<artifactId>micrometer-tracing</artifactId>
</dependency>
<dependency>
	<groupId>io.micrometer</groupId>
	<artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<dependency>
	<groupId>io.zipkin.reporter2</groupId>
	<artifactId>zipkin-reporter-brave</artifactId>
</dependency>

and, if there's no RestTemplate or WebClient, we additionally need:

<dependency>
	<groupId>io.zipkin.reporter2</groupId>
	<artifactId>zipkin-sender-urlconnection</artifactId>
</dependency>

[wilkinsona]

io.micrometer:micrometer-tracing-bridge-brave depends on io.micrometer:micrometer-tracing so a dependency on the latter shouldn't be needed.

The Brave bridge excludes everything in the io.zipkin.reporter2 group. It seems a little strange that we then have to reinstate a dependency in that group. I wonder if this can be improved on the Micrometer side?

[mhalbritter]

Hey @marcingrzejszczak, what's the reason to exclude the reporter2 group?

[mhalbritter]

So, after a quick chat with Marcin:

The exclusion is there because io.micrometer:micrometer-tracing-bridge-brave sets up the base infrastructure for Brave and micrometer-tracing. Brave itself supports more than just the Zipkin tracer, for example the Wavefront one is built on top of Brave. If the exclusions wouldn't be in place, every user which uses io.micrometer:micrometer-tracing-bridge-brave would automatically get Zipkin, too, which may not be desired. There could even be the case that a user want tracing to get the log correlation feature, but doesn't want to export the spans to a tracing backend.

We are currently supporting 4 different setups of tracing:

• brave and zipkin
• brave and wavefront
• otel and zipkin
• otel and wavefront

We have to decide which are "starter-worthy" and how to name the starters.

[goafabric]

@mhalbritter trying to get jaeger working, like it worked in 2.x with sleuth i stumbled upon this issue

the state of documentation for 3.x is currently confusing what this issue is implictly also stating

i have all the deps from above and also the following props .. partly via "reverse engineering"

management.tracing.enabled: "true" management.zipkin.tracing.endpoint: "http://localhost:9411/api/v2/spans"

i still cannot get things working like in 2.x

Also the Configuration Changelog https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0.0-M3-Configuration-Changelog

pointed out here https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0.0-M3-Release-Notes

yields to nothing .. i guess the page does either not exist or is "hidden"

=> can you tell me what I am missing here ? thx

@goafabric : remind me

[marcingrzejszczak]

@goafabric do you have an example of what you were trying to do?

[goafabric]

@marcingrzejszczak basically just connecting to a local jaeger instance .. as it worked before with spring-sleuth doing an http request -> jaeger recognizes it doing an http resttemplate call -> the same

with 3.0 i cannot get this working .. even if i put an intentional wrong endpoint there no exception is raised

already debugged inside the auto configuration which kicks in ... but still i guess, that the span creation never gets called

...

more precisely ..

• with the deps listed above
• the config options of: management.tracing.enabled: "true" management.zipkin.tracing.endpoint: "http://localhost:9411/api/v2/spans"
• and the jaeger command below docker run -d --rm --name jaeger -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 -p 16686:16686 -p 14268:14268 -p 9411:9411 jaegertracing/all-in-one:1.36.0

=> i would expect doing an http request is caught by jaeger ... as with sleuth in 2.x .. but its not working

[marcingrzejszczak]

Not all instrumentations are there (e.g. there's no Boot web instrumentation). As a workaround, what you can do is set the following dependencies

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-actuator'

    implementation 'io.micrometer:micrometer-registry-prometheus'
    implementation 'io.micrometer:micrometer-tracing-bridge-brave'
    implementation 'io.zipkin.reporter2:zipkin-reporter-brave'
}

and register the Observability Web Filter

@Bean
	FilterRegistrationBean traceWebFilter(ObservationRegistry observationRegistry) {
		FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean(new HttpRequestsObservationFilter(observationRegistry));
		filterRegistrationBean.setDispatcherTypes(DispatcherType.ASYNC, DispatcherType.ERROR, DispatcherType.FORWARD,
				DispatcherType.INCLUDE, DispatcherType.REQUEST);
		filterRegistrationBean.setOrder(Ordered.LOWEST_PRECEDENCE);
		return filterRegistrationBean;
	}

Then you will be producing metrics and traces when a request is being processed.

[goafabric]

@marcingrzejszczak ok thank you very much, at least the bean was missing

[artemptushkin]

@marcingrzejszczak I'm trying to migrate right now from SB 2.7.* to 3.0.0-M5 and it doesn't work, please provide us with a migration example at least

[marcingrzejszczak]

Sure, I'm working on some samples over here https://github.com/micrometer-metrics/micrometer-samples/tree/migrate-sleuth-samples . You can check e.g. mvc and resttemplate to see web related examples (not all of them are already prepared)

[mhalbritter]

We decided against providing starters for tracing. start.spring.io will put in the needed dependencies when users select the tracing entries without relying on starters.

[wilkinsona]

To help us in the future when we're trying to remember why we reached the decision, here's a brief summary of what we considered.

The combinations that can be used are listed in the documentation:

• OpenTelemetry With Zipkin
  • io.micrometer:micrometer-tracing-bridge-otel
  • io.opentelemetry:opentelemetry-exporter-zipkin
• OpenTelemetry With Wavefront
  • io.micrometer:micrometer-tracing-bridge-otel
  • io.micrometer:micrometer-tracing-reporter-wavefront
• OpenZipkin Brave With Zipkin
  • io.micrometer:micrometer-tracing-bridge-brave
  • io.zipkin.reporter2:zipkin-reporter-brave
• OpenZipkin Brave With Wavefront
  • io.micrometer:micrometer-tracing-bridge-brave
  • io.micrometer:micrometer-tracing-reporter-wavefront

Starters are intended to help people to get started but we have four different combinations here. We considered offering a starter for each combination but concluded that offering four starters would be counter productive.

We considered a more opinionated arrangement that would have been somewhat like spring-boot-starter-web and it using spring-boot-starter-tomcat by default. The goal would have been to have a Zipkin or Wavefront starter that uses, say, OpenTelemetry by default and to be able to exclude the OpenTelemetry starter in favour of a Brave starter. Unfortunately, this doesn't work as the Zipkin dependencies different depending upon whether you're using OpenTelemetry or Brave.

In the end, given that each combination is only two dependencies, we concluded that it's easiest to declare those dependencies directly. This isn't that different to the existing arrangement for metrics where a dependency on the appropriate registry implementation (Prometheus, Datadog, Wavefront, and so on) has to be declared. We can revisit this decision in the future if the code and module structure of the dependencies changes.