您的位置:首页 > 其它

Service Mesh - Istio服务观测篇

2020-12-23 11:07 423 查看

洞察你的服务:使用Kiali观测你的微服务应用

微服务架构可视化的重要性:

  • 痛点: 服务间依赖关系错综复杂
  • 问题排查困难,扯皮甩锅时有发生
  • 可视化的优势:
      梳理服务的交互关系
    • 了解应用的行为与状态

    什么是 Kiali

    Kiali属于Istio的集成组件之一,是一个用于Istio的可观测性控制台,具有服务网格配置和验证功能。它通过监控网络流量来推断服务拓扑和报告错误,帮助你了解服务网格的结构和运行状况。Kiali提供了详细的度量和基本的Grafana集成,可用于高级查询。

    • 官方定义: Istio 的可观察性控制台
    • 通过服务拓扑帮助你理解服务网格的结构
    • 提供网格的健康状态视图
    • 具有服务网格配置功能
  • 名字含义:源自希腊语,意为望远镜
  • 依赖 Istio 作为宿主,为 Istio 开发有较强的绑定关系
  • Kiali 是 Istio 服务观测的一环
  • Kiali 的功能:

    Kiali 的架构:

    从上图可以看到 Kiali 是一个前后端分离的架构,我们可以使用官方提供的配置文件启动 Kiali 的后端组件:

    [root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/addons/kiali.yaml

    确认启动成功:

    [root@m1 ~]# kubectl get pods -n istio-system
    NAME                                    READY   STATUS    RESTARTS   AGE
    kiali-7476977cf9-nwnsg                  1/1     Running   1          33h
    ...

    然后使用如下命令启动 kiali 的前端:

    [root@m1 ~]# istioctl dashboard kiali --address 192.168.243.138
    http://localhost:20001/kiali
    • Tips:这里的 IP 是该虚拟机可被外部访问的 IP

    使用浏览器访问 192.168.243.138:20001 ,基本页面如下:

    在 “Application” 页面可以查看不同 Namespace 下所部署的应用:

    在 “Graph” 页面下可以查看服务之间的总体拓扑,并提供了多种页面操作:

    在 “Services” 页面可以查看指定 Namespace 下的服务信息:

    点击服务的名称可以进入该服务的详情页:

    在 “Workloads” 页面可以查看指定 Namespace 下的工作负载信息:

    点击工作负载的名称可以进入该工作负载的详情页:

    在 “Istio Config” 页面可以对 Istio 中的资源配置进行查看、编辑及验证:

    • 绿色代表没问题,黄色代表有警告,例如使用了过期的配置项,红色则代表配置有错误

    例如 detail 的配置有错误,我们可以点击进去查看出错的地方,并且根据提示进行修改,然后点击 “Save” 保存即可:

    在 “Istio Config” 页面还有个向导功能,可以让我们创建 Istio 的资源。如下:

    但目前只提供了少数的几个资源类型可以创建:

    指标:使用Prometheus收集指标

    Prometheus 是一个开源的监控系统和时间序列数据库。你可以使用 Prometheus 来记录跟踪 Istio 和服务网格内应用程序运行状况的指标。然后可以使用Grafana和Kiali等工具对监控指标进行可视化。

    Prometheus 的功能:

    Prometheus 的架构:

    Prometheus 与 Istio 的集成也比较简单,我们可以使用官方提供的配置文件启动 Prometheus Server:

    [root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/addons/prometheus.yaml

    确认启动成功:

    [root@m1 ~]# kubectl get pods -n istio-system
    NAME                                    READY   STATUS    RESTARTS   AGE
    prometheus-7bfddb8dbf-4mnzr             2/2     Running   2          33h
    ...

    然后使用如下命令启动 Prometheus 的 Web UI :

    [root@m1 ~]# istioctl dashboard prometheus --address 192.168.243.138
    http://localhost:9090

    使用浏览器访问 192.168.243.138:9090,页面如下:

    通过官方提供的配置文件启动 Prometheus Server 后,它就会自动收集 Istio 的监控指标了。此时我们就可以通过 Prometheus 收集指标并查看指标数据了,例如查看 Istio 的请求总数,该指标属于服务指标

    Envoy 代理指标则以 envoy 开头,可以输入前缀进行查询:

    除以上两类指标外还有控制平面指标,这类指标是 Istio 提供的一系列自我监控指标,这些指标用于监控 Istio 本身的行为。

    在 “Status -> Targets” 页面可以查看监控目标的状态:

    Istio 1.5 之后提供的遥测指标:

    • 请求总数(istio_requests_total)
    • 请求时长(istio_request_duration_milliseconds)
    • 请求大小(istio_request_bytes)
    • 响应大小(istio_response_bytes)
    • TCP 发送字节数(istio_tcp_sent_bytes_total)
    • TCP 接受字节数(istio_tcp_received_bytes_total)
    • TCP 连接打开数(istio_tcp_connections_opened_total)
    • TCP 连接关闭数(istio_tcp_connections_closed_total)

    Istio 1.5 之前是通过Mixer来进行指标收集的,如下图:

    • 首先Envoy需要调用Mixer来上报指标信息,Mixer则会提供一个 metrics 这样的接口给 Prometheus 去抓取指标数据。因为每次请求进入代理时都需要调用Mixer上报数据,导致了一些性能问题,例如额外的资源占用以及请求延迟这样的情况,所以1.5之后Mixer就被废弃了

    Istio 1.5 之后就直接是 Envoy 和 Prometheus 进行交互,如下图:

    • 无论是代理级别的指标还是服务级别的指标,都是通过 Envoy 直接去获取的,这就省去了一层与Mixer的交互。尽管更改后的版本在性能上有了大幅提升,但还是存在一些问题。首先因为取消了Mixer这样的中心化管理,所以导致 Envoy 代理需要自己去上传指标数据,不是很方便,扩展性变弱了。

    可同时解决性能与扩展性问题最可行的一个方法就是未来在 Envoy 上使用 WebAssembly 这样的技术。WebAssembly in Envoy:

    • 解决静态化编译(构建时)的弊端
    • 优势: 无需修改 Envoy
    • 避免远程调用
    • 隔离性/安全/多样性
    • 可移植/可维护

    关于收集、查询指标的更多方式可以参考官方文档:

    监控:使用Grafana查看系统的整体状态

    Grafana 的功能:

    • Grafana 只是一个功能强大的可视化分析平台,自身并不包含数据源,所以通常需要配合 Prometheus 等数据源使用。让 Grafana 从Prometheus 中读取数据进行各种可视化展示,可以弥补 Prometheus 自带的可视化界面的不足

    Istio 默认提供了一些 Grafana Dashboard:

    • Mesh Dashboard:查看应用(服务)数据 网格数据总览
    • 服务视图
    • 工作负载视图
  • Performance Dashboard:查看 Istio 自身(各组件)数据
      Istio 系统总览
    • 各组件负载情况

    关于 Grafana 与 Istio 的集成,官方也提供了相应的配置文件,使用如下命令就可以启动 Grafana :

    [root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/addons/grafana.yaml

    确认启动成功:

    [root@m1 ~]# kubectl get pods -n istio-system
    NAME                                    READY   STATUS    RESTARTS   AGE
    grafana-784c89f4cf-s26lp                1/1     Running   1          33h
    ...

    然后使用如下命令启动 Grafana 的 Web UI :

    [root@m1 ~]# istioctl dashboard grafana --address 192.168.243.138
    http://localhost:3000

    使用浏览器访问 192.168.243.138:3000 ,首页如下:

    现在我们就可以使用 Grafana 查看指标生成的 Istio Dashboard了,进入 “Home”,可以看到 Istio 提供的 Dashboard:

    打开 “Istio Mesh Dashboard” 查看网格数据总览,展示效果如下:

    点击下方的 Service 名称可以进入 “Istio Service Dashboard” 查看服务视图:

    “Istio Workload Dashboard” 查看工作负载视图:

    “Istio Performance Dashboard” 查看资源使用总览:

    日志:如何获取Envoy的日志并进行调试

    最简单的一种Istio日志记录是Envoy的访问日志记录。访问日志(Access logs)提供了一种从单个工作负载实例的角度监视和理解行为的方法,通过查看Envoy日志可以了解流量信息、定位问题。Envoy代理将访问信息打印到其标准输出。然后,使用

    kubectl logs
    命令可以打印Envoy容器的标准输出。

    这一小节将演示如何获取Envoy的访问日志。首先,确认 Envoy 日志配置已开启(默认是开启的),可使用如下命令开启:

    $ istioctl install <flags-you-used-to-install-Istio> --set meshConfig.accessLogFile=/dev/stdout

    还是以Bookinfo应用作为示例:

    [root@m1 ~]# kubectl get pods
    NAME                              READY   STATUS    RESTARTS   AGE
    details-v1-79c697d759-wpxlj       2/2     Running   2          9h
    productpage-v1-65576bb7bf-4bwwr   2/2     Running   2          9h
    ratings-v1-7d99676f7f-cfbw4       2/2     Running   2          9h
    reviews-v1-987d495c-8n5mv         2/2     Running   2          9h
    reviews-v2-6c5bf657cf-rzn4q       2/2     Running   2          9h
    reviews-v3-5f7b9f4f77-29454       2/2     Running   2          9h
    [root@m1 ~]#

    访问Bookinfo应用的服务后会产生流量输出,此时可以使用如下命令查看 Envoy(istio-proxy)的日志输出:

    [root@m1 ~]# kubectl logs -l app=productpage -c istio-proxy
    ...
    [2020-12-23T01:34:30.349Z] "GET /details/0 HTTP/1.1" 200 - "-" 0 178 15 14 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "1e449e4d-0f3f-928b-9add-8b8ace3f5feb" "details:9080" "172.22.152.212:9080" outbound|9080||details.default.svc.cluster.local 172.22.152.206:42074 10.104.2.32:9080 172.22.152.206:56744 - default
    [2020-12-23T01:34:30.376Z] "GET /reviews/0 HTTP/1.1" 200 - "-" 0 375 948 948 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "1e449e4d-0f3f-928b-9add-8b8ace3f5feb" "reviews:9080" "172.22.78.148:9080" outbound|9080||reviews.default.svc.cluster.local 172.22.152.206:52008 10.100.239.139:9080 172.22.152.206:55806 - default

    访问日志默认的格式是 TEXT 格式,不利于查看日志项的含义,我们可以将日志格式设置为JSON,这样可以比较方便观察其日志项,使用如下命令将accessLogEncoding设置为JSON:

    $ istioctl install <flags-you-used-to-install-Istio> --set meshConfig.accessLogEncoding=JSON

    将日志格式设置为JSON后,此时输出的日志内容如下:

    {"upstream_cluster":"outbound|9080||reviews.default.svc.cluster.local","downstream_remote_address":"172.22.152.206:32852","authority":"reviews:9080","path":"/reviews/0","protocol":"HTTP/1.1","upstream_service_time":"735","upstream_local_address":"172.22
    8000
    .152.206:53320","duration":735,"route_name":"default","downstream_local_address":"10.100.239.139:9080","upstream_transport_failure_reason":null,"user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36","response_code":200,"response_flags":"-","start_time":"2020-12-23T01:45:58.932Z","method":"GET","request_id":"12bc8456-65b1-9a34-96e6-0fa9f0525f23","upstream_host":"172.22.152.209:9080","x_forwarded_for":null,"requested_server_name":null,"bytes_received":0,"bytes_sent":379}

    将JSON格式化后,如下:

    日志信息中有五个重要的字段,也就是所谓的Envoy 流量五元组:

    • Envoy 流量五元组可以让你清晰地知道,流量是从哪里来,会到哪里去,所以五元组是 Envoy 日志中非常重要的概念

    调试关键字段:

    response_flags
    ,一些请求的错误标志会被赋值给该字段。常见错误标志有如下几种:

    • UH:upstream cluster 中没有健康的 host,503
    • UF:upstream 连接失败,503
    • UO:upstream overflow(熔断)
    • NR:没有路由配置,404
    • URX:请求被拒绝因为限流或最大连接次数
    • 更多信息可参考:官方文档

    Envoy 的一些日志配置项:

    分布式追踪:使用Jeager对应用进行分布式追踪

    分布式追踪概念

    • 分析和监控应用的监控方法
    • 查找故障点、分析性能问题
    • 起源于 Google 的 Dapper
    • 随着分布式追踪技术的发展,衍生出了OpenTracing:API 规范、框架、公共库的组合

    Istio支持通过 Envoy 代理进行分布式追踪。代理会代表其代理的应用程序自动生成跟踪范围,只需要应用程序转发适当的请求上下文。

    Istio支持许多跟踪后端,包括Zipkin、Jaeger、Lightstep和Datadog。本小节将介绍 Istio 集成 Jaeger 实现分布式追踪。

    什么是 Jaeger:

    • 开源、端到端的分布式追踪系统
    • 针对复杂的分布式系统,对业务链路进行监控和问题排查

    分布式追踪的两个重要术语:

    • Span: 逻辑单元
    • 有操作名、执行时间
    • 嵌套、有序、因果关系
  • Trace:
      数据/执行路径
    • Span 的组合

    Jaeger 的架构:

    核心组件:

    • Client libraries:客户端公共库,支持不同语言
    • Agent:用于从应用抓取Span,并发送给Collector
    • Collector:收集器,从应用层收集Span数据,并发送给存储系统(DB)
    • Query:相当于查询引擎,用于提供在页面上查询数据的能力
    • Ingester:与Kafka配合使用,相当于Kafka的一个Consumer,消费数据存储到DB中

    接下来我们把 Jaeger 集成到 Istio。首先,确认 Istio 开启了追踪选项,可以使用如下命令开启:

    $ istioctl install <flags-you-used-to-install-Istio> --set values.tracing.enabled=true

    我们可以使用官方提供的配置文件快速将 Jaeger 集成到 Istio 中:

    [root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/addons/jaeger.yaml

    确认 Jaeger 启动成功:

    [root@m1 ~]# kubectl get pods -n istio-system
    NAME                                    READY   STATUS    RESTARTS   AGE
    jaeger-7f78b6fb65-gchw2                 1/1     Running   2          46h
    ...

    然后使用如下命令启动 Jaeger 的Web UI:

    [root@m1 ~]# istioctl dashboard jaeger --address 192.168.243.138
    http://localhost:16686

    使用浏览器访问 Jaeger 的Web UI:

    然后访问 Bookinfo 应用页面生成一些 trace 数据后,到 Jaeger 查询 trace 数据:

    点击任意 Span 可以查看其详细 trace 数据:

  • 内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
    标签: