Istio四之故障注入和链路追踪

前面介绍了如何通过配置VirtualService等完成流量管理，此篇博客将介绍Istio的另外一个能力故障注入和超时配置等，这些配置也是再VirtualService中完成。

下面的VirtualService中通过fault字段注入了故障，同时在VirtualService中配置如何上游服务返回5xx错误码，那么会retry 3次。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:name: canary
spec:hosts:- canaryhttp:- match:- headers:user:exact: jesseroute:- destination:host: canarysubset: v2### retry if upstream server send 5xxretries:attempts: 3perTryTimeout: 2s- route:- destination:host: canarysubset: v1### send 500 to client in 80%fault:abort:httpStatus: 500percentage:value: 80

另外还可以配置超时时间，也是在VeritualService中配置。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:name: canary
spec:hosts:- canaryhttp:- match:- headers:user:exact: jesseroute:- destination:host: canarysubset: v2### if upstream server response delay is greater than 1s, send timeout error to clienttimeout: 1s- route:- destination:host: canarysubset: v1

除了故障注入和超时设置等，VertualService中还可以配置流量镜像等，用于A/B测试，被引入的镜像流量因为返回的Response header中添加了Shadow字段，故也不会真正发送给用户。这样在不影响用户的情况下，完成对新版本的测试。

对于VirtualService中的规则，需要注意一点：当对同一个目标配置多条规则时，会按照在VirtualService中的顺序执行，也就是说规则中的第一条规则优先级最高。所以在VirtualService时如果发现配置的规则没有生效，可以查看下VirtualService中配置的所有规则，看看是否被前面的规则覆盖了。

上面介绍了VertualService中的各种路由规则配置，接下来看看Istio如何与Jaeger结合完成链路追踪。Jaeger是分布式链路追踪系统，在架构的设计上沿用了Zipkin的架构风格，两者具备很多类似的特性，除了开发语言不同而已。作为后起之秀，基于Go 的强大特性，使得Jaeger在基于云原生生态领域中能够如鱼得水，具备强大的号召力，甚至在一些新技术框架领域中，作为默认首选的分布式链路追踪系统，落地于各种不同的业务场景。其支持跨平台、多样性的组件追踪，例如：分布式边缘路由组件 Traefik、Istio等。下图展示了Jaeger所涉及的主要组件。

客户端库（Client libraries）
Jaeger客户端是OpenTracing API的特定于语言的实现，它们可用于手动或与已有的OpenTracing开源框架集成（例如 Flask，Dropwizard，gRPC 等）一起为分布式跟踪应用程序进行检测。检测服务在接收新请求时创建 Span，并将上下文信息（Trace id，Span id和Baggage）附加到传出请求。只有id和baggage 随请求一起传播；所有其他概要分析数据（如操作名称，时间，tag 和 log）都不会传播，它在后台异步地传输到 Jaeger后端。为了最大程度地减少开销，Jaeger客户端采用了各种采样策略。例如：对跟踪进行采样时，将捕获的分析范围数据传输到 Jaeger后端。当不进行跟踪采样时，不会收集任何性能分析数据，且对OpenTracing API的调用会被短路，以最小化性能开销。默认情况下，Jaeger 客户端对 0.1％的Traces进行采样（即每1000条中的1条）
代理（Agent）
Jaeger代理是一个网络守护程序，它侦听通过UDP发送的Span，然后将其分批发送给收集器，它旨在作为基础组件部署到所有主机。该代理为客户端抽象了收集器的路由和发现。
收集器（Collector）
Jaeger收集器从Jaeger代理接收跟踪，并通过处理管道运行它们。管道会验证跟踪，为其建立索引，执行转换并最终存储它们。
Jaeger存储（Storage）
Jaeger的存储是一个可插拔组件，目前支持 Cassandra，Elasticsearch 和 Kafka。
查询（Query）
查询是一项从存储中检索跟踪并托管UI来显示跟踪的服务。
Ingester
Ingester是一项从Kafka Topic读取并写入另一个存储后端（Cassandra，Elasticsearch）的服务。

上面介绍了Jaeger的基础组件，接下来通过实际例子演示如何完成对服务的链路追踪。首先是在集群上安装Jaeger，这里通过拉取docker image的方式来启动Jaeger的pod，然后定义了监听不同端口的Service。

apiVersion: apps/v1
kind: Deployment
metadata:name: jaegernamespace: istio-systemlabels:app: jaeger
spec:selector:matchLabels:app: jaegertemplate:metadata:labels:app: jaegerannotations:sidecar.istio.io/inject: "false"prometheus.io/scrape: "true"prometheus.io/port: "14269"spec:containers:- name: jaegerimage: "docker.io/jaegertracing/all-in-one:1.23"env:- name: BADGER_EPHEMERALvalue: "false"- name: SPAN_STORAGE_TYPEvalue: "badger"- name: BADGER_DIRECTORY_VALUEvalue: "/badger/data"- name: BADGER_DIRECTORY_KEYvalue: "/badger/key"- name: COLLECTOR_ZIPKIN_HOST_PORTvalue: ":9411"- name: MEMORY_MAX_TRACESvalue: "50000"- name: QUERY_BASE_PATHvalue: /jaegerlivenessProbe:httpGet:path: /port: 14269readinessProbe:httpGet:path: /port: 14269volumeMounts:- name: datamountPath: /badgerresources:requests:cpu: 10mvolumes:- name: dataemptyDir: {}
---
apiVersion: v1
kind: Service
metadata:name: tracingnamespace: istio-systemlabels:app: jaeger
spec:type: ClusterIPports:- name: http-queryport: 80protocol: TCPtargetPort: 16686# Note: Change port name if you add '--query.grpc.tls.enabled=true'- name: grpc-queryport: 16685protocol: TCPtargetPort: 16685selector:app: jaeger
---
# Jaeger implements the Zipkin API. To support swapping out the tracing backend, we use a Service named Zipkin.
apiVersion: v1
kind: Service
metadata:labels:name: zipkinname: zipkinnamespace: istio-system
spec:ports:- port: 9411targetPort: 9411name: http-queryselector:app: jaeger
---
apiVersion: v1
kind: Service
metadata:name: jaeger-collectornamespace: istio-systemlabels:app: jaeger
spec:type: ClusterIPports:- name: jaeger-collector-httpport: 14268targetPort: 14268protocol: TCP- name: jaeger-collector-grpcport: 14250targetPort: 14250protocol: TCP- port: 9411targetPort: 9411name: http-zipkinselector:app: jaeger

接着是被监听服务代码编写，这里有个被测的demo程序，demo里面有三个服务service0，service1，service2.请求发送到service0后，会传递到service1，service1转发给service2.service2再返回请求响应。为了进行链路追踪，还需要对被测应用进行埋点。那如何进行埋点呢？

Istio代理能够自动发送Span信息，所以在埋点是只需要一些辅助手段把整个跟踪过程统一起来即可。即应用程序自行传播跟跟踪相关的HTTP Header，这样代理在发送Span信息时，就能正确的把一个跟踪统一起来。查看demo程序，可以看到service0和service1中的将上一个服务的请求header信息发送到了下一个服务。例如service1中的代码如下所示：将request中的header信息加入到新建的NewRequest中，即访问service2的请求，这样就把header中的信息传递到了下一个服务。

被测应用程序已经通过Dockerfile生成镜像，push到镜像仓库，所以这里要部署三个部署采用yaml文件即可完成部署，下面是service0的文件，service1和service2的yaml文件只需要将service0进行替换即可。

apiVersion: apps/v1
kind: Deployment
metadata:name: service0
spec:replicas: 1selector:matchLabels:app: service0template:metadata:labels:app: service0spec:containers:- name: service0imagePullPolicy: Alwaysimage: cncamp/service0:v1.0ports:- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: service0
spec:ports:- name: http-service0port: 80protocol: TCPtargetPort: 80selector:app: service0

除了service的yaml文件，还有istio的VirtualService和Gateway的配置文件信息，从配置可以看到访问的入口是service0，具体内容如下所示

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:name: service0
spec:gateways:- service0hosts:- '*'http:- match:- uri:exact: /service0route:- destination:host: service0port:number: 80
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:name: service0
spec:selector:istio: ingressgatewayservers:- hosts:- '*'port:name: http-service0number: 80protocol: HTTP

最后通过命令启动上面的对象，且访问应用，在jaeger上查看链路追踪信息。

### update tracing sampling
```sh
kubectl apply -f jaeger.yaml
kubectl edit configmap istio -n istio-system
set tracing.sampling=100
```
### Deploy tracing
```sh
kubectl create ns tracing
kubectl label ns tracing istio-injection=enabled
kubectl -n tracing apply -f service0.yaml
kubectl -n tracing apply -f service1.yaml
kubectl -n tracing apply -f service2.yaml
kubectl apply -f istio-specs.yaml -n tracing
```
### Check ingress ip
```sh
kubectl get svc -n istio-system
istio-ingressgateway   LoadBalancer   $INGRESS_IP
```
### Access the tracing via ingress for 100 times(sampling rate is 1%)
```sh
curl $INGRESS_IP/service0
```
### Check tracing dashboard
```sh
istioctl dashboard jaeger
```

在Jaeger上获取到的信息如下所示，说明被测服务的链路情况被正确的进行了收集和展示。

上面例子只是对Jaeger进行了简单的介绍和使用，更多Jaeger的信息请查看官网信息。

Istio四之故障注入和链路追踪相关推荐

istio多集群链路追踪，附实操视频
理论篇什么是可观测性这里的可观察性主要指服务网格的可观察性,也就是需要观测服务网格中运行的微服务.为什么可观察性很重要,因为随着微服务架构的流行,一个系统可能运行成百上千微服务,如果系统出现故障, ...
《深入理解 Spring Cloud 与微服务构建》第十四章服务链路追踪 Spring Cloud Sleuth
<深入理解 Spring Cloud 与微服务构建>第十四章服务链路追踪 Spring Cloud Sleuth 文章目录 <深入理解 Spring Cloud 与微服务构建> ...
SpringCloud链路追踪SkyWalking-第四章-自定义链路追踪
目录引入依赖 @Trace将方法加入追踪链路加入@Tags或@Tag 示例 java代码如果我们希望对项目中的业务方法,实现链路追踪,方便我们排查问题,可以使用如下的代码引入依赖引入依赖 & ...
链路追踪技术的应用及实践
分布式架构的兴起推动了一些新技术的发展.其中链路追踪技术以其在APM领域的优异表现,成为了分布式架构中不可或缺的一部分.在本文中,我们将谈谈它的一些经典应用场景,以及笔者所在的团队如何利用链路追踪技术 ...
SpringCloud微服务-----skywalking链路追踪
微服务架构已经是一个很通用的系统架构,常见的技术栈如下图所示,这张架构图基本涵括了当前微服务体系下的各种技术栈,可能不同的技术栈有不同的开源实现. 链路追踪介绍对于一个大型的几十个,几百个微服务构成 ...
如何理解分布式链路追踪技术
什么是链路追踪?微服务引发了怎样的问题? 在深入了解分布式链路追踪技术之前,我们需要先理解这项技术产生的背景,以及它能够帮我们解决哪些棘手的问题. 提到分布式链路追踪,我们要先提到微服务.相信很多人都 ...
原来10张图就可以搞懂分布式链路追踪系统原理
分布式系统为什么需要链路追踪? 随着互联网业务快速扩展,软件架构也日益变得复杂,为了适应海量用户高并发请求,系统中越来越多的组件开始走向分布式化,如单体架构拆分为微服务.服务内缓存变为分布式缓存.服务 ...
springcloud上传文件_Spring Cloud实战：服务链路追踪Spring Cloud Sleuth
推荐阅读: Spring全家桶笔记:Spring+Spring Boot+Spring Cloud+Spring MVC 一个SpringBoot问题就干趴下了?我却凭着这份PDF文档吊打面试官. 前 ...
技术分析：搞懂链路追踪
背景介绍在微服务横行的时代,服务化思维逐渐成为了程序员的基本思维模式,但是,由于绝大部分项目只是一味地增加服务,并没有对其妥善管理,当接口出现问题时,很难从错综复杂的服务调用网络中找到问题根源,从而 ...

Istio四之故障注入和链路追踪

Istio四之故障注入和链路追踪相关推荐

最新文章

热门文章