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)