istio-opentracing链路追踪方案

istio-opentracing链路追踪方案

istio-opentracing链路追踪主要是由sidecar(envoy)支持的,istio只是在上层进行配置的修改。

envoy链路追踪

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 上。

初始化追踪

有多种途劲初始化追踪

跟踪上下文信息

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

  • 如果使用了 LightStep 跟踪器,在发送 HTTP 请求到其他服务,Envoy 依赖这个服务来传播 x-ot-span-context Header。
  • 如果使用的是 Zipkin,Envoy 要传播的是 B3 Header.(x-b3-traceid, x-b3-spanid, x-b3-parentspanid, x-b3-sampled,以及 x-b3-flags)也可以由外部客户端提出,用来启用或者禁用某个服务的跟踪请求。

istio链路追踪

链路追踪参数

istio链路追踪提供了全局配置zipkinAddress。istio的sidecar流量拦截后上报到链路系统,envoy的上报地址通过proxy_init的--zipkinAddress参数传入。由上面可知envoy的链路追踪主要的原生支持是jaeger。

istio的链路追踪并不能在sidecar中全部处理,是有侵入性的。业务需要存储几个特殊字段,在要调用下个服务时,把这几个字段带上。这样才能把整条链路串起来。具体可看上面的跟踪上下文信息,istio链路追踪例子。

mix模块中的telemetry和policy这两个的链路追踪是通过参数--trace_zipkin_url=http://zipkin:9411/api/v1/spans 来配置的。

采样率

链路的采样率istio中只提供了一个全局的配置,通过配置pilot的参数PILOT_TRACE_SAMPLING来控制,其范围是0.0-100.0,最小可配参数0.01,默认100。

修改方式:

  • helm安装时参数选项:pilot.traceSampling
  • 生成的yaml文件中修改PILOT_TRACE_SAMPLING变量,重新apply。
  • 通过kubectl -n Istio-system edit deploy Istio-pilot修改PILOT_TRACE_SAMPLING变量。

jaeger

istio的tracing默认使用jaeger来实现日志追踪的发送,存储,查询。
先来看jaeger的架构图:

jaeger主要由以下几部分组成

  • jaeger-client为不同语言实现的OpenTracing标准的SDK.应用程序通过API写入数据,然后按照指定策略把trace传递给jaeger-agent.
  • agent是一个UDP中转服务,它将数据批量发送给collector.它是一个基础组件,布在所有机器上.
  • collector接收agent发送来的数据,然后将数据写入后端.collector是一个无状态组件,可以建任意数量.
  • data-store后端存储被设计成一个可插拔的组件.支持CassandraElasticSearch
  • query从存储中提取数据并通过UI展示.

istio中jaeger现状

istio目前官方自带的是all-in-one的镜像,所有的组件都包含在一个镜像中.数据的存储是存在内存中,pod删除或重启,所有的数据就全没有了.这没法线上使用.

为此,我们需要考虑将数据存储为指定的存储服务,采用官方自带的肯定不行,需要自己重新部署一套jaeger。

jaeger持久化存储

k8s部署jaeger

根据官方文档部署基于k8s的Jaeger的生产环境下的容器,这个要采用Production这个生成的部署方式。

这种方式的部署比较麻烦,需要对jaeger有一定的理解,对存储服务如ES都需要有一定的研究。因此这种试不推荐。

接入自己的ES服务

istio的链路追踪通过zipkin直接传输到jaeger-collector,jaeger-collector将数据发送到自己现有的ES集群进行存储,jaeger-query直接去现有ES集群查询。

链路追踪发送到jaeger-collector

如果不在同个namespace下,需要修改zipkin地址为jaeger的zipkin收集地址。envoy这个proxy会默认使用环境变量来设置zipkinAddress地址,默认地址是zipkin.istio-system:9411。可在yaml下查找zipkinAddress来修改,然后更新就可以。如果后继有helm update更新,需要去修改charts,在install/kubernetes/helm/istio//templates/configmap.yamlinstall/kubernetes/helm/istio//charts/mixer/templates 这两个下面的zipkin地址。 mix相关的trace_zipkin_url的zipkin也要改成对应的地址。

  • 修改istio的zipkin地址需要重新启动pod。
  • jaeger-agent这个服务,因为我们是直接配置到jaeger-collector因些不需要。
jaeger-collector到ES集群

这个官方的jaeger是支持发送到kafka,但由于jaeger会生成3个index(jaeger-span,jaeger-service,jager-dependencies),而kafka发送到ES时,要区分有点麻烦。暂时先直接发送到ES。

jaeger-query

这个配置只需将查询地址改为ES的地址。

jaeger-query的dependencies服务生成图需要自己配置spark-dependencies

线上例子

jaeger-collector的ES配置参数可通过下面来查看,jaeger-query的参数也是一样的

docker run \
  -e SPAN_STORAGE_TYPE=elasticsearch \
  jaegertracing/jaeger-collector:1.8 \
  --help

k8s jaeger的configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: jaeger-configuration
  namespace: istio-system
  labels:
    app: jaeger
    jaeger-infra: configuration
data:
  span-storage-type: elasticsearch
  collector: |
    es:
      server-urls: http://example1.com:9200,http://example2.com:9200
      index-prefix: online-opentracing 
    collector:
      zipkin:
        http-port: 9411
  query: |
    es:
      server-urls: http://example1.com:9200,http://example2.com:9200
      index-prefix: online-opentracing

k8s jaeger-collector和jaeger-query

apiVersion: v1
kind: List
items:
- apiVersion: extensions/v1beta1
  kind: Deployment
  metadata:
    name: jaeger-collector
    namespace: istio-system
    labels:
      app: jaeger
      jaeger-infra: collector-deployment
  spec:
    replicas: 3
    strategy:
      type: Recreate
    template:
      metadata:
        labels:
          app: jaeger
          jaeger-infra: collector-pod
        annotations:
          prometheus.io/scrape: "true"
          prometheus.io/port: "14268"
      spec:
        containers:
        - image: jaegertracing/jaeger-collector:1.8.2
          name: jaeger-collector
          args: ["--config-file=/conf/collector.yaml"]
          ports:
          - containerPort: 14267
            protocol: TCP
          - containerPort: 14268
            protocol: TCP
          - containerPort: 9411
            protocol: TCP
          readinessProbe:
            httpGet:
              path: "/"
              port: 14269
          volumeMounts:
          - name: jaeger-configuration-volume
            mountPath: /conf
          env:
          - name: SPAN_STORAGE_TYPE
            valueFrom:
              configMapKeyRef:
                name: jaeger-configuration
                key: span-storage-type
        volumes:
          - configMap:
              name: jaeger-configuration
              items:
                - key: collector
                  path: collector.yaml
            name: jaeger-configuration-volume
- apiVersion: v1
  kind: Service
  metadata:
    name: jaeger-collector
    namespace: istio-system
    labels:
      app: jaeger
      jaeger-infra: collector-service
  spec:
    ports:
    - name: jaeger-collector-tchannel
      port: 14267
      protocol: TCP
      targetPort: 14267
    - name: jaeger-collector-http
      port: 14268
      protocol: TCP
      targetPort: 14268
    - name: jaeger-collector-zipkin
      port: 9411
      protocol: TCP
      targetPort: 9411
    selector:
      jaeger-infra: collector-pod
    type: ClusterIP
- apiVersion: v1
  kind: Service
  metadata:
    name: zipkin
    namespace: istio-system
    labels:
      app: jaeger
      jaeger-infra: zipkin-service
  spec:
    ports:
    - name: jaeger-collector-zipkin
      port: 9411
      protocol: TCP
      targetPort: 9411
    selector:
      jaeger-infra: collector-pod
    type: ClusterIP
- apiVersion: extensions/v1beta1
  kind: Deployment
  metadata:
    name: jaeger-query
    namespace: istio-system
    labels:
      app: jaeger
      jaeger-infra: query-deployment
  spec:
    replicas: 1
    strategy:
      type: Recreate
    template:
      metadata:
        labels:
          app: jaeger
          jaeger-infra: query-pod
        annotations:
          prometheus.io/scrape: "true"
          prometheus.io/port: "16686"
      spec:
        containers:
        - image: jaegertracing/jaeger-query:1.8.2
          name: jaeger-query
          args: ["--config-file=/conf/query.yaml"]
          ports:
          - containerPort: 16686
            protocol: TCP
          readinessProbe:
            httpGet:
              path: "/"
              port: 16687
          volumeMounts:
          - name: jaeger-configuration-volume
            mountPath: /conf
          env:
          - name: SPAN_STORAGE_TYPE
            valueFrom:
              configMapKeyRef:
                name: jaeger-configuration
                key: span-storage-type
        volumes:
          - configMap:
              name: jaeger-configuration
              items:
                - key: query
                  path: query.yaml
            name: jaeger-configuration-volume
- apiVersion: v1
  kind: Service
  metadata:
    name: jaeger-query
    namespace: istio-system
    labels:
      app: jaeger
      jaeger-infra: query-service
  spec:
    type: NodePort
    ports:
    - name: jaeger-query
      port: 80
      protocol: TCP
      targetPort: 16686
      nodePort: 32686
    selector:
      jaeger-infra: query-pod

参考文档:

原文地址:https://www.cnblogs.com/mathli/p/10262553.html

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


istio的授权功能,也称为基于角色的访问控制(RBAC),它为istio服务网格中的服务提供命名空间级别、服务级别和方法级别的访问控制。基于角色的访问控制具有简单易用、灵活和高性能等特性。本文介绍如何在服务网格中为服务进行授权控制。·前置条件·•安装istio的k8s集群,启用认证功能、
Errorfromserver(Forbidden):errorwhencreating"oot/istio.yaml":configmaps"istio-galley-configuration"isforbidden:unabletocreatenewcontentinnamespaceistio-systembecauseitisbeingterminatedErrorfromserver(Forbid
3.1Istio的核心组件及其功能Istio总体分两部分:控制面和数据面。数据面(sidecar):sidecar通过注入的方式和业务容器共存于一个pod,会劫持业务容器的流量,并接受控制面组件的控制,同时会向控制面输出日志、跟踪以及监控数据。控制面:Istio的核心,管理Istio的所有功能。
在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统。本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS。使用场景 在部署了Istio的集群中,使用人员
在之前的最佳实践中,已经带大家通过一系列的实践任务领略了Istio的无穷魅力。今天,将向大家介绍如何用Istio实现流量熔断。熔断机制是创建弹性微服务应用程序的重要模式。熔断可以帮助您自由控制故障影响的范围、网络延迟的峰值以及抵御其他一些来自外部的恶意***等场景。在接下来
流量镜像流量镜像,也称为影子流量,流量镜像提供一种尽可能低的风险为生产带来变化的强大功能。镜像会将实时流量的副本发送到镜像服务。镜像流量发生在主服务的关键请求路径之外。在非生产或者测试环境中,尝试访问一个服务所有可能的测试用例组合是个非常不现实的任务。在某些情况下
一、负载均衡算法原理与实战负载均衡算法(loadbalancingalgorithm),定义了几种基本的流量分发方式,在Istio中一共有4种标准负载均衡算法。•Round_Robin:轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求。•Random:随机算法,将所有的请求随机分发给健康的实例•
本文整理自华为CloudBU技术专家在K8S技术社上关于Istio调用链的分享。前言大家好,我是idouba,来自华为CloudBU,当前在做Istio服务网格在华为云容器服务的产品化工作。今天跟大家分享的主题是Istio调用链相关内容。通过剖析Istio的架构机制与Istio中调用链的工作原理来解答一个大
今天,我们就来谈谈Istio主打功能---保护服务。那么,便引出3个问题:Istio凭什么保护服务?Istio具体如何保护服务?如何告诉Istio发挥保护能力?Istio凭什么保护服务?将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性、可伸缩性和可复用性
istio-opentracing链路追踪方案istio-opentracing链路追踪主要是由sidecar(envoy)支持的,istio只是在上层进行配置的修改。envoy链路追踪envoy主要用三个功能来支撑系统范围内的跟踪生成RequestID:envoy会在需要的时候生成UUID,并操作名为[x-request-id]的HTTPHeader。应用可
在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移。这两个方面的功能都是Istio流量治理的一部分。今天将继续带大家了解Istio的另一项功能,关于请求超时的管理。首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理。看过ido
调用链原理和场景正如ServiceMesh的诞生是为了解决大规模分布式服务访问的治理问题,调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器,可能还会跨多个物理机房。无论是服务自身问题还是网络环境的问题导致调用
在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统。本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS。使用场景在部署了Istio的集群中,使用人员刚
前言在Istio的世界里,如果想把外部的请求流量引入网格,你需要认识并会学会配置IstioIngressGateway什么是IngressGateway由于KubernetesIngressAPI只能支持最基本的HTTP路由,使用KubernetesIngress资源来配置外部流量的方式不能满足需求。因此Istiov1alpha3routingAPI引
Istio是什么?使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给DevOps团队带来压力。开发人员必须使用微服务已满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上,Istio有助于降低这些
Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness:liveness探针用来侦测什么时候需要重启容器。比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用。readiness探针用来使容器准备好接收流量。
摘要使用Istio可以很方便地实现微服务间的访问控制。本文演示了使用Denier适配器实现拒绝访问,和Listchecker适配器实现黑白名单两种方法。使用场景有时需要对微服务间的相互访问进行控制,比如使满足某些条件(比如版本)的微服务能够(或不能)调用特定的微服务。访问控制属于策略
导读目前以Kubernetes为基础构建的容器生态逐渐完善,这其中Kubernetes、Istio、Knative三个独立项目被越来越多的人提及,并且已经开始尝试大规模落地实践,它们恰好构成了容器云的未来拼图。今天与大家一起分享下,这三个项目究竟解决了什么问题,为什么它们能够一鸣惊人。随着微服务理念
注:以下讲述的按理环境场景是基于Kubernetes环境基础上部署的Istio环境。涉及到Envoy概念介绍请参考深度解析Istio系列之流量控制篇。本文重点针对Envoy初始化场景进行拆解。Istio-proxy(Envoy)作为Istio数据平面的重要组件,基于sidecar方式与业务应用混合部署到同一pod,为应用提
使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给DevOps团队带来压力。开发人员必须使用微服务以满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio允许您连接、保护、控制和观测服务。在较高的层次上,Istio有助于降低这些部署的复杂性,