深度解读:基于kiali和jaeger实现服务网格的可观测性

服务网格可观测整体架构

深度解读:基于kiali和jaeger实现服务网格的可观测性

   服务网格可观测架构


Envoy组件作为sidecar,和业务容器在同一个pod内,通过对业务流量的劫持,生成业务请求统计的metric和调用跟踪数据span,CIE管理面接收到metric和span后保存到数据库,用户在console查询时从数据库获取metric和span,提供业务的可观测功能。


Istio配置启用metric和span


1

服务metric配置


深度解读:基于kiali和jaeger实现服务网格的可观测性

istio监控指标的配置是通过CRD实现的,我们可以通过修改istiooperators.install.istio.io启用监控指标。


还可以通过envoyfilters.networking.istio.io修改产生的指标的labels,比如添加一些pod信息和网格信息等。配置示例如下:

深度解读:基于kiali和jaeger实现服务网格的可观测性


Envoy产生的metric无需主动上报,Prometheus通过服务发现方式从pod主动拉取。拉取指标的url为“http://{podip}:{port}/stats/prometheus”,端口号根据pod资源里面一个叫做“http-envoy-prom”的Ports配置项获取,该配置由istio注入,业务不感知。Pod配置参数如下:


主要的业务指标包含以下几个:


2

调用链span配置


Istio支持输出调用链数据,相关配置也是由CRD来管理的。通过修改istiooperators.install.istio.io可以进行相关配置。配置示例如下:


支持自定义tag、数据上报安全选项和数据上报地址等配置。最新版本的istio已经默认支持zipkin-v2的调用链数据格式了。Zipkin-v2格式示例如下:


服务拓扑和调用链实现原理


1

服务拓扑实现原理


服务拓扑可以展示服务之间的调用关系,由“点”和“边”构成。“点”即服务实体,“边”就是服务之间的调用关系,是有向的,没有和其他服务有调用关系的点就成为一个孤点。典型的服务拓扑如下图所示:

服务拓扑图


Envoy在有业务请求时,会统计2个服务之间的调用指标,指标名称是以istio_开头的形式,通常包含source和destination这2组标签信息,例如下图这个指标:

表明这个指标统计的是productpage(source)请求details (destination)的次数。有了这些的基础指标数据,kiali就可以将符合条件的指标全部提取出来,组合为点和边的集合,还可以计算每条边上的统计值,例如请求次数、请求的平均时延、请求错误率等关键指标。整个拓扑的实现流程如下图示:

拓扑提取过程


对于服务SLI的度量采用RED方法(RED方法是Weave Cloud在基于Google的“4个黄金指标”的原则下结合Prometheus以及Kubernetes容器实践,细化和总结的方法论,特别适合于云原生应用以及微服务架构应用的监控和度量)。主要关注以下三种关键指标:

  • (请求)速率:服务每秒接收的请求数。

  • (请求)错误:每秒失败的请求数。

  • (请求)耗时:每个请求的耗时。

RED方法可以有效的帮助用户衡量云原生以及微服务应用下的用户体验问题。


2

调用链实现原理


在微服务场景下,一个业务操作经常由多个微服务协作完成,调用跟踪就是用来追踪一个业务请求的全部链路信息的方法。当有外部请求访问服务时,首先会被envoy拦截,解析其中的请求信息,例如url、method、目的端口和服务等,记录这些关键请求信息之后,将生成一个新的traceID和spanID,并将该信息通过httpHeader的方式append到原始请求,并随着网络传递给下一个服务。


请求到达目标服务后,从httpHeader里面解析出这些上下文信息,并记录新的调用信息,如果还需要调用其他服务,则同样将traceID和spanID传递下去,这样在这次请求链中所有服务拿到的traceID都是一样的,数据汇聚到一起后可以根据这个traceID过滤出所有的span,再根据span的父子关系绘制业务的调用链。原理如下图所示:

调用链原理


每一个Envoy都会产生一些span数据,根据配置的后端endpoint,将这些span数据发送给CIE的trace-receiver服务,经过数据计算和整理后写入对应的搜索引擎。用户在界面上根据查询的条件可以获取对应的span数据,然后对某一个调用过程进行可视化展示,可以快速定界性能问题和调用错误的问题。


如下图就是一个典型的性能问题,整体调用93ms,ratings服务的处理耗时66ms,这样就能发现是ratings服务导致整个请求时延较大,ratings服务可能发生了故障。

深度解读:基于kiali和jaeger实现服务网格的可观测性

调用链耗时分析


从span数据到调用树的转换过程如下图示:

深度解读:基于kiali和jaeger实现服务网格的可观测性

调用链可视化过程


CIE当前的能力展示


CIE 在管理侧集成了kiali和jeager,兼容开源的span格式和编码,结合自研的服务,在console提供了服务拓扑、服务SLI和调用链3个主要的功能。


1

服务拓扑

当前借助kiali的页面设计,可以展示服务的调用链关系和关键指标,支持异常指标染色,服务节点支持跳转调用链功能。

深度解读:基于kiali和jaeger实现服务网格的可观测性

服务拓扑全景展示


2

服务SLI

支持查询单个Service的工作负载基础指标和服务整体的SLI指标。页面中部可同时关联显示Service对应的工作负载的资源指标,通过业务指标和资源指标的对比就可以快速定位资源不足导致的业务指标劣化问题。例如服务的请求时延指标突增,同时工作负载CPU使用量也有明显上涨,就可以快速定位是因为cpu资源不足导致请求变慢。

深度解读:基于kiali和jaeger实现服务网格的可观测性

服务SLI详情


同时也支持查询服务下的某一个操作(操作定义为一个method+http.url)的SLI指标查看。

深度解读:基于kiali和jaeger实现服务网格的可观测性

操作SLI详情


通过查看服务的 R(request请求次数)E(error错误率)D(duration时延)指标,可以了解服务的工作状态是否正常。请求次数的突然增大和减少(排除业务随时间波动较大的情况),错误率的突然升高,时延和历史均值差异较大等都是服务出现了故障,需要结合调用链和日志等信息进一步分析原因。操作列表也支持跳转调用链分析,可以查询到该操作的历史span数据,根据调用结果和耗时等筛选出异常调用进行分析。


3

调用链


CIE console提供调用链的搜索和详情展示功能,用户可以通过指定的条件过滤span,点击span对应的traceID,即可查看本次调用的详细情况。调用树可以直观展示每个调用的耗时和结果信息,如果出现调用错误,自动染色,可以快速找出故障点。

深度解读:基于kiali和jaeger实现服务网格的可观测性

调用链span搜索


深度解读:基于kiali和jaeger实现服务网格的可观测性

调用链详情


对于单个span的耗时较长的情况,右侧边栏可以关联显示当前调用的历史耗时趋势图,如果当前耗时远大于历史均值,则认为是异常的调用,需要进一步分析原因。


上一篇:老生常谈系列之Aop--AspectJ


下一篇:SylixOS文件状态获取