追踪

概览

在较大的面向服务的架构中,分布式跟踪系统让开发者能够得到可视化的调用流程展示。在了解序列化、并行情况以及延迟分析的时候,这个功能至关重要。Envoy 用三个功能来支撑系统范围内的跟踪:

  • 生成 Request ID:Envoy 会在需要的时候生成 UUID,并操作名为 [x-request-id] 的 HTTP Header。应用可以转发这个 Header 用于统一的记录和跟踪。
  • 集成外部跟踪服务:Envoy 支持可插接的外部跟踪可视化服务。目前支持有 LightStepZipkin 或者 Zipkin 兼容的后端(比如说 Jaeger)。另外要添加其他的跟踪服务也并非难事。
  • 客户端跟踪 ID 连接x-client-trace-id Header 可以用来把不信任的请求 ID 连接到受信的 x-request-id Header 上。

如何初始化追踪

处理请求的 HTTP 连接管理器必须设置跟踪对象。有多种途径可以初始化跟踪:

路由过滤器可以使用 start_child_span 来为 egress 调用创建下级 Span。

跟踪上下文信息的传播

Envoy 提供了报告网格内服务间通信跟踪信息的能力。然而一个调用流中,会有多个代理服务器生成的跟踪信息碎片,跟踪服务必须在出入站的请求中传播上下文信息,才能拼出完整的跟踪信息。

不管使用的是哪个跟踪服务,都应该传播 x-request-id,这样在被调用服务中启动相关性的记录。

为了理解 Span(本地的作业单元)之间的父子关系,跟踪服务自身也需要更多的上下文信息。这种需要可以通过在跟踪服务自身中直接使用 LightStep(OpenTracing API)或者 Zipkin 跟踪器来完成,从而在入站请求中提取跟踪上下文,然后把上下文信息注入到后续的出站请求中。这种方法还可以让服务能够创建附加的 Span,用来描述服务内部完成的工作。这对端到端跟踪的检查是很有帮助的。

另外跟踪上下文也可以被服务手工进行传播:

每条追踪中包含哪些数据

端到端的跟踪会包含亦或者多个 Span。一个 Span 就是一个逻辑上的工作单元,具有一个启动时间和时长,其中还会包含特定的 Metadata,Envoy 生成的 Span 包含如下信息:

Span 中还要包括一个名字(或者操作名),这一信息通常是由服务所属主机定义的。也可以在路由上使用 Decorator 来进行自定义。还可以使用 x-envoy-decorator-operation Header 来设置名称。

Envoy 自动把 Span 发送给跟踪信息采集器。跟踪服务会使用其中的上下文信息来对多个 Span 进行拼装。例如x-request-id (LightStep) 或者 Zipkin 中的 trace ID 配置。

要获取更多 Envoy 跟踪设置方面的信息,可以阅读如下链接:

Copyright © ServiceMesher 2018 all right reserved,powered by Gitbook 最后更新于 2018-09-10 20:10:30

results matching ""

    No results matching ""