Spring Cloud 参考文档（Spring Cloud Sleuth特性）

2024年1月10日 359次阅读 来源: 博弈

Spring Cloud Sleuth特性

  • 将trace和span ID添加到Slf4J MDC，因此你可以在日志聚合器中从给定的trace或span提取所有日志，如以下示例日志中所示：

    2016-02-02 15:30:57.902  INFO [bar,6bfd228dc00d216b,6bfd228dc00d216b,false] 
23030 --- [nio-8081-exec-3] ...
2016-02-02 15:30:58.372 ERROR [bar,6bfd228dc00d216b,6bfd228dc00d216b,false] 
23030 --- [nio-8081-exec-3] ...
2016-02-02 15:31:01.936  INFO [bar,46ab0d418373cbc9,46ab0d418373cbc9,false] 
23030 --- [nio-8081-exec-4] ...

    请注意MDC中的[appname,traceId,spanId,exportable]条目：

    • spanId：发生的特定操作的ID。
    • appname：记录span的应用程序的名称。
    • traceId：包含span的延迟图的ID。
    • exportable：是否应将日志导出到Zipkin，你希望什么时候span不能导出？如果要在Span中包装某些操作并将其写入日志中。
  • 提供对常见分布式追踪数据模型的抽象：trace、span（形成DAG）、annotation和键值annotation，Spring Cloud Sleuth基于HTrace，但与Zipkin（Dapper）兼容。
  • Sleuth记录时间信息以帮助进行延迟分析，通过使用sleuth，你可以查明应用程序中的延迟原因。

  • Sleuth不进行过多的日志记录，并且不会导致生产应用程序崩溃，为此，Sleuth：

    • 在带内传播有关你的调用图的结构数据，在带外休息。
    • 包括层的自定义插装，比如HTTP。
    • 包括用于管理卷的采样策略。
    • 可以向Zipkin系统报告用于查询和可视化。
  • 仪器从Spring应用程序中常见的入口和出口点（servlet过滤器、异步端点、rest模板，调度操作，消息通道，Zuul过滤器和Feign客户端）。
  • Sleuth包含默认逻辑，用于跨HTTP或消息传递边界连接trace，例如，HTTP传播适用于与Zipkin兼容的请求headers。
  • Sleuth可以在进程之间传播上下文（也称为baggage），因此，如果你在Span上设置baggage元素，则会通过HTTP或消息传递向下发送到其他进程。
  • 提供创建或继续span以及通过annotations添加标记和日志的方法。

  • 如果spring-cloud-sleuth-zipkin位于类路径上，则应用程序会生成并收集与Zipkin兼容的trace，默认情况下，它通过HTTP将它们发送到localhost上的Zipkin服务器（端口9411），你可以通过设置spring.zipkin.baseUrl来配置服务的位置。

    • 如果你依赖spring-rabbit，你的应用程序会将trace发送到RabbitMQ代理而不是HTTP。

    • 如果你依赖spring-kafka，并设置spring.zipkin.sender.type:kafka，你的应用程序会将trace发送到Kafka代理而不是HTTP。

      spring-cloud-sleuth-stream已弃用，不应再使用。

  • Spring Cloud Sleuth兼容OpenTracing。

    如果使用Zipkin，请通过设置
    spring.sleuth.sampler.probability来配置导出的span概率（默认值：0.1，即10％），否则，你可能会认为Sleuth没有工作，因为它忽略了一些span。

    始终设置SLF4J MDC，并且logback用户可以根据前面显示的示例立即在日志中看到trace和span ID，其他日志记录系统必须配置自己的格式化程序才能获得相同的结果，默认值如下：
    logging.pattern.level设置为
    %5p [${spring.zipkin.service.name:${spring.application.name:-}},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-},%X{X-Span-Export:-}](这是Logback用户的Spring Boot特性)，如果你不使用SLF4J，则不会自动应用此模式。

Brave介绍

从版本2.0.0开始，Spring Cloud Sleuth使用
Brave作为追踪库，为方便起见，在此处嵌入了Brave的部分文档。

在绝大多数情况下，你只需使用Sleuth提供的Brave中的
Tracer或
SpanCustomizer bean，下面的文档概述了Brave是什么以及它是如何工作的。

Brave是一个用于捕获和报告关于分布式操作的延迟信息到Zipkin的库，大多数用户不直接使用Brave，他们使用库或框架，而不是代表他们使用Brave。

此模块包含一个追踪器，用于创建和连接span，对潜在分布式工作的延迟进行建模，它还包括通过网络边界传播trace上下文的库（例如，使用HTTP头）。

追踪

最重要的是，你需要一个brave.Tracer，配置为向Zipkin报告。

以下示例设置通过HTTP（而不是Kafka）将trace数据（spans）发送到Zipkin：

class MyClass {

    private final Tracer tracer;

    // Tracer will be autowired
    MyClass(Tracer tracer) {
        this.tracer = tracer;
    }

    void doSth() {
        Span span = tracer.newTrace().name("encode").start();
        // ...
    }
}

如果你的span包含一个名称长度超过50个字符，则该名称将被截断为50个字符，你的名称必须明确而具体，大名称会导致延迟问题，有时甚至会引发异常。

追踪器创建并连接span，对潜在分布式工作的延迟进行建模，它可以采用抽样来减少进程中的开销，减少发送到Zipkin的数据量，或两者兼而有之。

追踪器返回的span在完成后向Zipkin报告数据，如果未采样则不执行任何操作，启动span后，你可以批注感兴趣的事件或添加包含详细信息或查找键的标记。

Spans具有一个上下文，其中包含trace标识符，该标识符将span放置在表示分布式操作的树中的正确位置。

本地追踪

当追踪代码不离开你的进程，在范围span内运行它。

@Autowired Tracer tracer;

// Start a new trace or a span within an existing trace representing an operation
ScopedSpan span = tracer.startScopedSpan("encode");
try {
  // The span is in "scope" meaning downstream code such as loggers can see trace IDs
  return encoder.encode();
} catch (RuntimeException | Error e) {
  span.error(e); // Unless you handle exceptions, you might not know the operation failed!
  throw e;
} finally {
  span.finish(); // always finish the span
}

当你需要更多功能或更精细的控制时，请使用Span类型：

@Autowired Tracer tracer;

// Start a new trace or a span within an existing trace representing an operation
Span span = tracer.nextSpan().name("encode").start();
// Put the span in "scope" so that downstream code such as loggers can see trace IDs
try (SpanInScope ws = tracer.withSpanInScope(span)) {
  return encoder.encode();
} catch (RuntimeException | Error e) {
  span.error(e); // Unless you handle exceptions, you might not know the operation failed!
  throw e;
} finally {
  span.finish(); // note the scope is independent of the span. Always finish a span.
}

上面的两个例子在完成时报告的span完全相同！

在上面的示例中，span将是新的根span或现有trace中的下一个子span。

自定义span

拥有span后，你可以为其添加标记，标签可用作查找键或详细信息，例如，你可以使用运行时版本添加标记，如以下示例所示：

span.tag("clnt/finagle.version", "6.36.0");

当暴露自定义span到第三方的能力时，使用brave.SpanCustomizer而不是brave.Span，前者更易于理解和测试，并且不会使用span生命周期钩子诱惑用户。

interface MyTraceCallback {
  void request(Request request, SpanCustomizer customizer);
}

由于brave.Span实现了brave.SpanCustomizer，你可以将其传递给用户，如以下示例所示：

for (MyTraceCallback callback : userCallbacks) {
  callback.request(request, span);
}

隐式查看当前span

有时，你不知道trace是否正在进行，并且您不希望用户执行null检查，brave.CurrentSpanCustomizer通过向正在进行或丢弃的任何span添加数据来处理此问题，如以下示例所示：

// The user code can then inject this without a chance of it being null.
@Autowired SpanCustomizer span;

void userCode() {
  span.annotate("tx.started");
  ...
}

RPC追踪

在滚动自己的RPC仪器之前，请检查
此处编写的仪器和
Zipkin的列表。

RPC追踪通常由拦截器自动完成，在幕后，他们添加与他们在RPC操作中的角色相关的标签和事件。

以下示例显示如何添加客户端span：

@Autowired Tracing tracing;
@Autowired Tracer tracer;

// before you send a request, add metadata that describes the operation
span = tracer.nextSpan().name(service + "/" + method).kind(CLIENT);
span.tag("myrpc.version", "1.0.0");
span.remoteServiceName("backend");
span.remoteIpAndPort("172.3.4.1", 8108);

// Add the trace context to the request, so it can be propagated in-band
tracing.propagation().injector(Request::addHeader)
                     .inject(span.context(), request);

// when the request is scheduled, start the span
span.start();

// if there is an error, tag the span
span.tag("error", error.getCode());
// or if there is an exception
span.error(exception);

// when the response is complete, finish the span
span.finish();

单向追踪

有时，你需要在有请求但没有响应的情况下建模异步操作，在正常的RPC追踪中，你使用span.finish()来指示已收到响应，在单向追踪中，你使用span.flush()代替，因为不不期望响应。

以下示例显示了客户端如何为单向操作建模：

@Autowired Tracing tracing;
@Autowired Tracer tracer;

// start a new span representing a client request
oneWaySend = tracer.nextSpan().name(service + "/" + method).kind(CLIENT);

// Add the trace context to the request, so it can be propagated in-band
tracing.propagation().injector(Request::addHeader)
                     .inject(oneWaySend.context(), request);

// fire off the request asynchronously, totally dropping any response
request.execute();

// start the client side and flush instead of finish
oneWaySend.start().flush();

以下示例显示了服务器如何处理单向操作：

@Autowired Tracing tracing;
@Autowired Tracer tracer;

// pull the context out of the incoming request
extractor = tracing.propagation().extractor(Request::getHeader);

// convert that context to a span which you can name and add tags to
oneWayReceive = nextSpan(tracer, extractor.extract(request))
    .name("process-request")
    .kind(SERVER)
    ... add tags etc.

// start the server side and flush instead of finish
oneWayReceive.start().flush();

// you should not modify this span anymore as it is complete. However,
// you can create children to represent follow-up work.
next = tracer.newSpan(oneWayReceive.context()).name("step2").start();
    原文作者：博弈
    原文地址: https://segmentfault.com/a/1190000019017973
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞