В нашем приложении Spring Boot (2.0.4.RELEASE) мы используем Zipkin для интеграции распределенной трассировки.
При создании интеграции вручную с частотой дискретизации 10%, что означает @Configuration, например:
@Configuration
public class ZipkinConfiguration {
@Value("${grpc.zipkin.endpoint:}")
private String zipkinEndpoint;
@Bean
public SpanCustomizer currentSpanCustomizer(Tracing tracing) {
return CurrentSpanCustomizer.create(tracing);
}
@Bean
public Tracing tracing(@Value("${spring.application.name}") String serviceName) {
return Tracing.newBuilder().localServiceName(serviceName).spanReporter(spanReporter()).build();
}
private Reporter<Span> spanReporter() {
return AsyncReporter.create(sender());
}
private Sender sender() {
return OkHttpSender.create(zipkinEndpoint);
}
}
наше приложение имеет производительность 50 процентилей около 19 мс и 99,9 процентиля около 90 мс при скорости около 10 запросов в секунду.
При интеграции Sleuth 2.0.2.RELEASE вместо этого, как это в gradle:
compile "org.springframework.cloud:spring-cloud-starter-sleuth:2.0.2.RELEASE"
compile "org.springframework.cloud:spring-cloud-sleuth-zipkin:2.0.2.RELEASE"
производительность резко падает до p50 49 мс и p999 120 мс.
Я пытался отключить различные части интеграции Sleuth (spring.sleuth.async.enabled, spring.sleuth.reactor.enabled и т. Д.).
Отключение всех этих интеграций повышает производительность до p50: 25 мс, p999: 103 мс. Сатут добавляет примерно 15-25% накладных расходов.
Оказывается, единственное, что оказывает значительное влияние, - это установка spring.sleuth.log.slf4j.enabled в false. Если все остальные интеграции включены, но это отключено, производительность остается в пределах указанных выше служебных данных Sleuth, хотя ничего не регистрируется.
Итак, мой вопрос:
Есть ли способ избежать издержек от Sleuth (по сравнению с «ручной» трассировкой) и особенно от интеграции SLF4J?