idou老师教你学Istio 08: 调用链埋点是否真的“零修改”?
本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式。并基于Istio中埋点的原理解释来说明:为了输出一个质量良好的调用链,业务程序需根据自身特点做适当的修改,即并非官方一直在说的完全无侵入的做各种治理。另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式。
Istio一直强调其无侵入的服务治理,服务运行可观察性。即用户完全无需修改代码,就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集。原文是这样描述的:
Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality。
调用链的埋点是一个比起来记录日志,报个metric或者告警要复杂的多,根本原因是要能将在多个点上收集的关于一次调用的多个中间请求过程关联起来形成一个链。Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的机制,还是挺复杂的。也有很多实现,用的比较多的如zipkin,和已经在CNCF基金会的用的越来越多的Jaeger,满足Opentracing语义标准的就有这么多。
在Istio中大段的埋点逻辑在Sidecar中已经提供,业务代码不用调用以上这些埋点方式来创建trace,维护span等这些复杂逻辑,但是为了能真正连接成一个完整的链路,业务代码还是需要做适当修改。我们来分析下细节为什么号称不用修改代码就能搞定治理、监控等高级功能的Sidecar为什么在调用链埋点的时候需要改应用代码。
调用详细
服务调用关系
简单期间,我们以Istio最经典的Bookinfo为例来说明。Bookinfo的4个为服务的调用关系是这样:
调用链输出
从前端入口gateway那个envoy上进行一次调用,到四个不同语言开发的服务间完成调用,一次调用输出的调用链是这样:
简单看下bookinfo 中的代码,能看到并没有任何创建维护span这种埋点的逻辑,想也是,对于python、java、ruby、nodejs四种不同的语言采用不同的埋点的库在来实现类似的埋点逻辑也是非常头痛的一件事情。那我们看到这个调用链信息是怎么输出的?答案当然是应用边上的sidecar Envoy,Envoy对于调用链相关设计参照这里。sidecar拦截应用程序所有的进和出的网络流量,跟踪到所有的网络请求,像Service mesh的设计理念中其他的路由策略、负载均衡等治理一样,只要拦截到流量Sidecar也可以实现埋点的逻辑。
埋点逻辑
对于经过sidecar流入应用程序的流量,如例子中流入roductpage, details、reviews和ratings的流量,如果经过Sidecar时header中没有任何跟踪相关的信息,则会在创建一个span,Traceid就是这个spanId,然后在将请求传递给通pod的业务服务;如果请求中包含trace相关的信息,则sidecar从走回归提取trace的上下文信息并发给应用程序。
对于经过sidecar流出的流量,如例子中gateway调用productpage,或者productpage调用链details和reviews的请求。如果经过sidecar时header中没有任何跟踪相关的信息,则会创建根span,并将该跟span相关上下文信息放在请求头中传递给下一个调用的服务,当然调用前会被目标服务的sidecar拦截掉执行上面流入的逻辑;当存在trace信息时,sidecar从header中提取span相关信息,并基于这个span创建子span,并将新的span信息加在请求头中传递。
以上是bookinfo一个实际的调用中在proxy上生成的span主要信息。可以看到,对于每个app访问都经过Sidecar代理,inbound的流量和outbound的流量都通过Sidecar。图上为了清楚表达每个将对Sidecar的每个处理都分开表示,如productpage,接收外部请求是一个处理,给details发出请求是一个处理,给reviews发出请求是另外一个处理,因此围绕Productpage这个app有三个黑色的处理块,其实是一个Sidecar。为了不使的图上太凌乱,最终的Response都没有表示。其实图上每个请求的箭头都有一个反方向的response,在服务发起方的Sidecar会收到response时,会记录一个CR(client received)表示收到响应的时间并计算整个span的持续时间。
解析下具体数据,结合实际调用中生成的数据来看下前面proxy埋点的逻辑会更清楚些。
1.从gateway开始,gateway作为一个独立部署在一个pod中的envoy进程,当有请求过来时,它会将请求转给入口的微服务productpage。Gateway这个Envoy在发出请求时里面没有trace信息,会生成一个根span:spanid和traceid都是f79a31352fe7cae9,parentid为空,并记录CS时间,即Client Send;
2.请求从入口gateway这个envoy进入productpage前先讲过productpage pod内的envoy,envoy处理请求头中带着trace信息,则记录SR,Server received,并将请求发送给Productpage业务容器处理,productpage在处理请求的业务方法中需要接收这些header中的trace信息,然后再调用Details和Reviews的微服务。
Python写的 productpage在服务端处理请求时,先从request中提取接收到的header。然后再调用details获取details服务时,将header转发出去。
app.route('/productpage')
def front():
product_id = 0 # TODO: replacedefault value
headers = getForwardHeaders(request)
…
detailsStatus, details = getProductDetails(product_id, headers)
reviewsStatus, reviews = getProductReviews(product_id, headers)
return…
可以看到就是提取几个trace相关的header kv
def getForwardHeaders(request):
headers = {}
incoming_headers = [ 'x-request-id',
'x-b3-traceid',
'x-b3-spanid',
'x-b3-parentspanid',
'x-b3-sampled',
'x-b3-flags',
'x-ot-span-context'
] for ihdr in incoming_headers:
val = request.headers.get(ihdr)
if val is not None:
headers[ihdr] = val
return headers
其实就是重新构造一个请求发出去,可以看到请求中包含收到的header。
def getProductReviews(product_id, headers):
url = reviews['name'] + "/" + reviews['endpoint'] + "/" + str(product_id)
res = requests.get(url, headers=headers, timeout=3.0)
3.从ProductPage出的请求去请求Reviews服务前,又一次通过同Pod的envoy,envoy埋点逻辑检查header中包含了trace相关信息,在将请求发出前会做客户端的调用链埋点,即以当前span为parent span,生成一个子span:即traceid:保持一致9a31352fe7cae9, spanid重新生成cb4c86fb667f3114,parentid就是上个span: f79a31352fe7cae9。
4.请求在到达Review业务容器前,先经过Review的Envoy,从Header中解析出trace信息存在,则发送Trace信息给Reviews。Reviews处理请求的服务端代码中需要解析出这些包含trace的Header信息。
reviews服务中java的rest代码如下:
@GET
@Path("/reviews/{productId}")
public Response bookReviewsById(@PathParam("productId") int productId,
@HeaderParam("end-user") String user,
@HeaderParam("x-request-id") String xreq,
@HeaderParam("x-b3-traceid") String xtraceid,
@HeaderParam("x-b3-spanid") String xspanid,
@HeaderParam("x-b3-parentspanid") String xparentspanid,
@HeaderParam("x-b3-sampled") String xsampled,
@HeaderParam("x-b3-flags") String xflags,
@HeaderParam("x-ot-span-context") String xotspan)
即在服务端接收请求的时候也同样会提取header。调用Ratings服务时再传递下去。其他的productpage调用Details,Reviews调用Ratings逻辑类似。不再复述。
以一实际调用的例子了解以上调用过程的细节,可以看到Envoy在处理inbound和outbound时的埋点逻辑,更重要的是看到了在这个过程中应用程序需要配合做的事情。即需要接收trace相关的header并在请求时发送出去,这样在出流量的proxy向下一跳服务发起请求前才能判断并生成子span并和原span进行关联,进而形成一个完整的调用链。否则,如果在应用容器未处理Header中的trace,则Sidecar在处理outbound的请求时会创建根span,最终会形成若干个割裂的span,并不能被关联到一个trace上。
即虽然Istio一直是讲服务治理和服务的可观察性对业务代码0侵入。但是要获得一个质量良好的调用链,应用程序还是要配合做些事情。在官方的distributed-tracing 中这部分有描述:“尽管proxy可以自动生成span,但是应用程序需要在类似HTTP Header的地方传递这些span的信息,这样这些span才能被正确的链接成一个trace。因此要求应用程序必须要收集和传递这些trace相关的header并传递出去”
• x-request-id
• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• x-ot-span-context
调用链阶段span解析:
前端gateway访问productpage的proxy的这个span大致是这样:
"traceId": "f79a31352fe7cae9",
"id": "f79a31352fe7cae9",
"name": "productpage-route",
"timestamp": 1536132571838202,
"duration": 77474,
"annotations": [
{
"timestamp": 1536132571838202,
"value": "cs",
"endpoint": {
"serviceName": "istio-ingressgateway",
"ipv4": "172.16.0.28"
}
},
{
"timestamp": 1536132571839226,
"value": "sr",
"endpoint": {
"serviceName": "productpage",
"ipv4": "172.16.0.33"
}
},
{
"timestamp": 1536132571914652,
"value": "ss",
"endpoint": {
"serviceName": "productpage",
"ipv4": "172.16.0.33"
}
},
{
"timestamp": 1536132571915676,
"value": "cr",
"endpoint": {
"serviceName": "istio-ingressgateway",
"ipv4": "172.16.0.28"
}
}
],
gateway上报了个cs,cr, productpage的那个proxy上报了个ss,sr。
分别表示gateway作为client什么时候发出请求,什么时候最终受到请求,productpage的proxy什么时候收到了客户端的请求,什么时候发出了response。
Reviews的span如下:
"traceId": "f79a31352fe7cae9",
"id": "cb4c86fb667f3114",
"name": "reviews-route",
"parentId": "f79a31352fe7cae9",
"timestamp": 1536132571847838,
"duration": 64849,
Details的span如下:
"traceId": "f79a31352fe7cae9",
"id": "951a4487642c0966",
"name": "details-route",
"parentId": "f79a31352fe7cae9",
"timestamp": 1536132571842677,
"duration": 2944,
可以看到productpage这个微服务和detail和reviews这两个服务的调用。
一个细节就是traceid就是第一个productpage span的id,所以第一个span也称为根span,而后面两个review和details的span的parentid是前一个productpage的span的id。
Ratings 服务的span信息如下:可以看到traceid保持一样,parentid就是reviews的spanid。
"traceId": "f79a31352fe7cae9",
"id": "5aac176b61ec8d84",
"name": "ratings-route",
"parentId": "cb4c86fb667f3114",
"timestamp": 1536132571889086,
"duration": 1449,
当然在Jaeger里上报会是这个样子:
根据一个实际的例子理解原理后会发现,应用程序要修改代码根本原因就是调用发起方,在Isito里其实就是Sidecar在处理outbound的时生成span的逻辑,而这个埋点的代码和业务代码不在一个进程里,没法使用进程内的一些类似ThreadLocal的方式(threadlocal在golang中也已经不支持了,推荐显式的通过Context传递),只能显式的在进程间传递这些信息。这也能理解为什么Istio的官方文档中告诉我们为了能把每个阶段的调用,即span,串成一个串,即完整的调用链,你需要修你的代码来传递点东西。
当然实例中只是对代码侵入最少的方式,就是只在协议头上机械的forward这几个trace相关的header,如果需要更多的控制,如在在span上加特定的tag,或者在应用代码中代码中根据需要构造一个span,可以使用opentracing的StartSpanFromContext 或者SetTag等方法。
调用链数据上报
Envoy上报
一个完整的埋点过程,除了inject、extract这种处理span信息,创建span外,还要将span report到一个调用链的服务端,进行存储并支持检索。在Isito中这些都是在Envoy这个sidecar中处理,业务程序不用关心。在proxy自动注入到业务pod时,会自动刷这个后端地址。如:
即envoy会连接zipkin的服务端上报调用链数据,这些业务容器完全不用关心。当然这个调用链收集的后端地址配置成jaeger也是ok的,因为Jaeger在接收数据是兼容zipkin格式的。
Mixers上报
除了直接从Envoy上报调用链到zipkin后端外,和其他的Metric等遥测数据一样通过Mixer这个统一面板来收集也是可行的。
即如tracespan中描述,创建一个tracespan的模板,来描述从mixer的一次访问中提取哪些数据,可以看到trace相关的几个ID从请求的header中提取,而访问的很多元数据有些从访问中提取,有些根据需要从pod中提取(背后去访问了kubeapiserver的pod资源)
apiVersion: "config.istio.io/v1alpha2"
kind: tracespan
metadata:
name: default
namespace: istio-system
spec:
traceId: request.headers["x-b3-traceid"]
spanId: request.headers["x-b3-spanid"] | ""
parentSpanId: request.headers["x-b3-parentspanid"] | ""
spanName: request.path | "/"
startTime: request.time
endTime: response.time
clientSpan: (context.reporter.local | true) == false
rewriteClientSpanId: false
spanTags:
http.method: request.method | ""
http.status_code: response.code | 200
http.url: request.path | ""
request.size: request.size | 0
response.size: response.size | 0
source.ip: source.ip | ip("0.0.0.0")
source.service: source.service | ""
source.user: source.user | ""
source.version: source.labels["version"] | ""
最后
在这个文章发出前,一直在和社区沟通,督促在更明晰的位置告诉大家用Istio的调用链需要修改些代码,而不是只在一个旮旯的位置一小段描述。得到回应是1.1中社区首页第一页what-is-istio/已经修改了这部分说明,不再是1.0中说without any changes in service code,而是改为with few or no code changes in service code。提示大家在使用Isito进行调用链埋点时,应用程序需要进行适当的修改。当然了解了其中原理,做起来也不会太麻烦。
参照
https://thenewstack.io/distributed-tracing-istio-and-your-applications/
https://github.com/istio/old_mixer_repo/issues/797
http://www.idouba.net/opentracing-serverside-tracing/
idou老师教你学Istio 08: 调用链埋点是否真的“零修改”?的更多相关文章
- idou老师教你学Istio 22 : 如何用istio实现调用链跟踪
大家都知道istio可以帮助我们实现灰度发布.流量监控.流量治理等一些功能. 每一个功能都帮助我们在不同场景中实现不同的业务.那么其中比如流量监控这种复杂的功能Istio是如何让我们在不同的应用中实现 ...
- idou老师教你学Istio 07: 如何用istio实现请求超时管理
在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移.这两个方面的功能都是Istio流量治理的一部分.今天将继续带大家了解Istio的另一项功能,关于请求超时的管理. 首先我们可以通过一个简 ...
- idou老师教你学Istio 20 : Istio全景监控与拓扑
根据Istio官方报告,Observe(可观察性)为其重要特性.Istio提供非侵入式的自动监控,记录应用内所有的服务. 我们知道在Istio的架构中,Mixer是管理和收集遥测信息的组件.每一次当请 ...
- idou老师教你学Istio: 如何用Istio实现K8S Egress流量管理
本文主要介绍在使用Istio时如何访问集群外服务,即对出口流量的管理. 默认安装的Istio是不能直接对集群外部服务进行访问的,如果需要将外部服务暴露给 Istio 集群中的客户端,目前有两种方案: ...
- idou老师教你学Istio:如何用 Istio 实现速率限制
使用 Istio 可以很方便地实现速率限制.本文介绍了速率限制的使用场景,使用 memquota\redisquota adapter 实现速率限制的方法,通过配置 rule 实现有条件的速率限制,以 ...
- idou老师教你学Istio 28:istio-proxy check 的缓存
功能概述 istio-proxy主要的功能是连接istio的控制面组件和envoy之间的交互,其中check的功能是将envoy收集的attributes信息上报给mixer,在istio中有几十种a ...
- idou老师教你学Istio :5分钟简析Istio异常检测
异常检测 异常检测和踢出异常主机是一个动态检查上游主机是否正常工作,对不健康主机进行移除的过程.异常检测是一种被动健康检查,根据返回状态码来判断是否满足移除条件,最后将主机移除,首先我们来了解下驱逐算 ...
- idou老师教你学Istio 27:解读Mixer Report流程
1.概述 Mixer是Istio的核心组件,提供了遥测数据收集的功能,能够实时采集服务的请求状态等信息,以达到监控服务状态目的. 1.1 核心功能 •前置检查(Check):某服务接收并响应外部请求前 ...
- idou老师教你学Istio 24:如何在Istio使用Prometheus进行监控
使用Prometheus进行监控是Istio提供的监控能力之一.Istio提供丰富的监控能力,为网格中的服务收集遥测数据.Mixer是负责提供策略控制和遥测收集的Istio组件. Istio通过Mix ...
随机推荐
- 【VS2015软件报错】命名空间 system.windows 中不存在类型或命名空间名称 forms (是否缺少程序集引用 )错误
C#项目: 添加“using System.Windows.Forms;”之后提示“命名空间 system.windows 中不存在类型或命名空间名称 forms (是否缺少程序集引用 )”错误 详细 ...
- 【MM系列】在SAP里查看数据的方法
公众号:SAP Technical 本文作者:matinal 原文出处:http://www.cnblogs.com/SAPmatinal/ 原文链接:[MM系列]在SAP里查看数据的方法 前言部 ...
- rest_framework之ModelViewSet、路由控制、序列化组件快速搭建项目雏形
以UserInfo表登陆接口为例 ModelViewSet的用法十分简单,定义一个视图类,指定一个模型表,指定一个序列化类即可帮我们完成增删改查等功能 示例: # 视图层 from app01.MyS ...
- sql server 2008 数据库管理系统使用SQL语句创建登录用户步骤详解
介绍了sql server 2008 数据库管理系统使用SQL语句创建登录用户步骤详解 --服务器角色: --固定服务器角色具有一组固定的权限,并且适用于整个服务器范围. 它们专门用于管理 SQL S ...
- MySQL explain功能展示的各种信息的解释
1.id: MySQL Query Optimizer 选定的执行计划中查询的序列号. 2.select_type: 所使用的查询类型,主要有以下这几种查询类型. DEPENDENT SUBQUER ...
- 2019java学习路线图
学习路线图往往是学习一样技术的入门指南.网上搜到的Java学习路线图也是一抓一大把.但是很多学习路线图总结的云里雾里,也没有配套的视频,学习效果并不好. 分享一个完整的Java学习路线图给大家,也是贴 ...
- scratch少儿编程第一季——05、移动还可以这样动
各位小伙伴大家好: 上期我们学习了怎么控制方向和移动的程序块. 今天我们继续学习运动模块下的其他9个指令(程序块). 首先来看前面两个关于x坐标的程序块. 分别是将x坐标增加()单位,和将x坐标设定为 ...
- js:把字符串转为变量使用; js下将字符串当函数去执行的方法
1 把字符串当变量使用 通过计算 string 得到的值(如果有的话).该方法只接受原始字符串作为参数 demo: var type = "car"; var newStr = & ...
- java代码检出打包
这里先提下前提,就是有个维护的(可能有二期的一个项目),后端是Java,由于很久都不做Java,剩下的只是不多了.之前做的Java容器要么是tomcat,要么接触过新的spring cloud.从来没 ...
- [Vue]vue-router嵌套路由(子路由)
总共添加两个子路由,分别命名Collection.vue(我的收藏)和Trace.vue(我的足迹) 1.重构router/index.js的路由配置,需要使用children数组来定义子路由,具体如 ...