Istio可观测性(监控)
现代化常用的 Metrics 系统
Metrics 主要是用时序性数据库记录每个时间点的监控数据，通过主动拉取或者程序上报的方式记录，然后实时计算一段时间的数据，并通过图形界面的方式展现出来。它的特点是实时性强、可观测指标丰富，适合查看一段时间内的指标趋势。
StatsD+Graphite
StatsD 是 Node.js 编写的一个Metrics 指标采集系统，通过 UDP 协议将信息传输到后端程序，聚合后存储到 Graphite。
StatsD 包含三个组成部分，分别是：
Client，各种语言使用的 SDK，用于将 Metrics 信息通过 UDP 的方式传送到 Server。
Server，收集客户端传输的 Metrics 信息，聚合后发送到 Backend，也就是 Graphite。
Backend，也就是上面提到的 Graphite，Graphite 是一个时序数据库，负责存储 Metrics 信息。
InfluxDB+Telegraf
InfluxDB 是一个时序数据库，负责 Metrics 信息的存储；Telegraf 是一套 Metrics 收集系统，默认自带非常丰富的插件，用于采集系统级别的信息，如果要采集应用维度的信息，则需要编写插件。
Prometheus
Prometheus 是 Cloud Native Computing Foundation（简称：CNCF）生态圈的一员，也是整个 Kubernetes 生态中重要的一环，现已经广泛用于 Kubernetes 集群监控中。Prometheus 与上面的两个 Metrics 系统最大的不同，是提供了一整套完整的监控告警解决方案，包含了数据采集、数据存储和告警。
另外还有两个非常重要的特性，也是现代化监控系统的必要标志：
采用了 pull 拉取的模型采集数据，简化了客户端的代码编写成本，并且 HTTP 协议非常利于调试。
支持服务发现，默认支持了 Consul 和 Kubernetes 原生发现系统，避免了繁杂的机器信息配置。
至此，我们介绍了常见的 Metrics 指标监控系统，下面针对现在最流行的 Prometheus 展开做详细的讲解。
Prometheus 组成和架构
Prometheus 架构由以下模块构成。
Prometheus Server：用于收集和存储 Metrics 数据。
Service Disvovery：用于服务发现，获取服务对应的 EndPoint 用于数据采集，默认支持 DNS、Consul、Kubernestes 等多种发现方案。
PushGateway：提供推送的方式采集数据，主要用于 Job 类，Job 类程序可能存活时间比较短，不适合采用拉取的方式。另外一些非常驻进程的脚本语言，比如 PHP，也需要使用此种方式。
Exporters：用于一些第三方服务，通过转换提供符合 Prometheus 规范的 Metrics 信息，比如 Node Exporter 提供节点相关的信息。BlackBox 方便用户使用 HTTP、TCP 等方式对应用进程探活，以监控应用状态。
Client Library：为各种语言提供的客户端库，提供 HTTP 服务的 Metrics 接口，当 Prometheus Server 拉取时，提供实时的 Metrics 数据。
Alertmanager：告警管理器，接收 Prometheus Server 发来的告警信息，去除重复信息，分组后发送给相应的人员。通知方式支持 Email 和 WebHook 自定义等，一般会通过 WebHook 接入钉钉或者企业微信以达到实时报警的目的。
Prometheus 数据模型
下面，通过一条简单的 Metrics 数据，来了解它由哪些模块组成：
negri_http_request_total{client="serviceA",code="200",exported_service="serviceB",path="/ping"}
Metrics 名字：首先是 Metrics 的名称，Metrics 的名称表明了这条数据的用途，比如上面这个数据是 Negri Sidecar 统计的总的请求数量。
Label 标签：这条数据中的 client、code、exported_service 和 path 都是标签，通过标签可以组成不同的查询语句，从不同维度获取数据。
Prometheus 的 Metrics 类型
Prometheus 由四种不同的 Metrics 类型组成，这些 Metrics 类型适用于不同的应用场景。
Counter
累加值，非常适合统计 QPS。这个数据从服务开始就不停地累加，比如上面提到的 negri_http_request_total 就是一种 Counter 类型。它统计了服务启动至目前所有请求的数据，通过 rate 或者 irate 就可以计算出一段时间内的 QPS。Counter 类型是 Prometheus Server 端计算的，相对于下面讲到的 Gauge，占用服务自身更少，建议高性能的微服务首选此种类型。
Gauge
适合记录瞬时值，比如统计一些突发事件，例如是否产生了熔断、限流等事件。因为是客户端 SDK 计算的，不太适合一些经常变化的数据。如果数据是一直增加的，建议使用 Counter；当然如果数据有增有减，也比较适合，因为监控中很少遇到增减比较频繁的数据。
degrade_events{event="eventBreakerOpenStatus",service="serviceB"}
Histogram
柱状图，适合统计服务的 99 延时等信息，比如下面的例子就是用于统计服务的延时状况：
negri_http_response_time_us_bucket{client="serviceA",exported_service="serviceB",le="0.5",path="/ping"}
如上述内容，可以通过查询语句绘制出 90 延时、95 延时、99 延时等指标， Histogram 和 Counter 类型一样，都是 Prometheus Server 端计算的，所以非常适合高性能的场景使用，相对于下面讲解的 Summary 有更小的损耗。
Summary
类似于 Histogram，适合统计服务的 99 延时信息。Summary 和 Gauge 类型一样，都是在程序内计算的，所以并不能像 Histogram 一样，在绘制图形的时候灵活的设置百分位，但相对来说，Summary 的数据也更加精准。
这里讲完了 Metrics 的常用数据结构，下面我们来看一下如果利用 Grafana 展示收集的 Metrics 信息。
Grafana 图形化展示
Grafana 是一套可视化监控指标工具，主要用于时序数据的展示，包括 Graphite、Elasticsearch、InfluxDB、Prometheus、CloudWatch、MySQL 和 OpenTSDB。其中最常见的就是 Prometheus+Grafana 的组合。
在页面的最上方，有几个选项，可以选择需要的参数。
Service：服务名，这里的服务名就是在 Kubernetes 中要访问的服务名，比如 details.default.svc.cluster.local。Bookinfo 这个项目所包含的几个微服务，都可以在这里选择。
Client Workload Namespace（Or Service Workload Namespace）：这里指的是 Kubernetes 的 namespace 命名空间，也就是服务创建在了哪个命名空间。这里应用类型的服务都创建在了 default 的命名空间，只有 istio-ingressgateway 创建了 istio-system 的命名空间。
Client Workload：可以理解为当前 Service 的 upstream，也就是 Client 调用端。默认选中了 details.default.svc.cluster.local 这个服务，查看 Client Workload 的下拉框可以看到 productpage-v1 的选项，这说明 details.default.svc.cluster.local 这个服务的流量来源是 productpage 的 v1 版本。如果这里有多个选项，也可以选中其中一个进行查看，通过观察不同的流量来源，在出现问题的时候可以很好地区分到底是哪个流量来源的问题，便于排查问题的根因。
这也是 Istio 这样的 Service Mesh 解决方案，对比传统微服务解决方案一个很大的优势点。传统的微服务 SDK 在落地的过程中，很难将调用方的服务名注入进去，即便是通过规范约束调用方 Client 也必须注入客户端服务名。这个注入也非常容易出问题，比如写入错误的服务名或者其他服务的服务名，这种问题在 Trace 的落地实践中很常见。
Istio 这样的 Service Mesh 解决方案则没有这样的困扰，可以直接通过控制面下发当前服务的服务名，让 Sidecar 在 Metrics 中自动注入，不允许业务代码编写人员修改这个服务名，从而在根本上杜绝了调用方服务名出错的问题。
Service Workload：这里选中 reviews.default.svc.cluster.local，然后查看 Service Workload 的下拉框，可以看到三个选项 review-v1、reviews-v2、reviews-v3。这里其实就是 reviews 这个服务的三个不同版本，可以分别选择这三个版本中的任意一个或者多个查看相应的监控信息。
接下来展示了 SERVICE: reviews.default.svc.cluster.local 的一些常见信息，比如客户端/服务端请求的 QPS、成功率、延时等。这里所有的指标都有两个维度，一个是服务端自身的，一个是Client 端的，相对来说 Client 端的统计更接近服务本身的耗时，因为服务自身的统计无法把网络消耗统计在内。很多时候我们经常过度关注服务自身的各种指标，反而忽略了网络层面的一些消耗。
再下面的面板是 Client Workloads，可以看到不同版本的调用端服务、请求的黄金指标，包括 QPS、延时、响应大小等。
最后的面板是 Service Workloads，也就是当前服务的不同版本的统计信息，同样包含了 QPS、延时、响应大小，以及 TCP 连接等信息。
相对于 istio-services-dashboard，这个页面最大的优势，是可以看到 inbound（入流量）和 outbound（出流量）两个流量方向的监控信息，比如这里选中 reviews-v3 这个 Workload，可以看到它的 inbound 的信息，也就是 productpage-v1 这个调用端访问过来的流量；也可以看到 review-v3 访问出去的流量，流量路由到的服务是 ratings.default.svc.cluster.local。
以客户端的视角，查看服务的出流量在很多场景下也是非常重要的，很多时候不仅要关注其他服务调用我们服务的健康情况，也要关注我们访问其他服务的健康状况，在一些情况下二者是息息相关的。
和上面讲解 Services 的 dashboard 一样，这里也简单介绍一下 Workload dashboard 的参数。
Namespace：这里和上面 Services dashboard 提到的 namespace 是同一个概念。
Workload：指的是服务的不同版本。比如 reviews 这个服务就可以选择 v1、v2、v3 三个版本。
Inbound Workload：指的是不同版本的调用方服务，比如 review-v3 这个服务，就可以看到 productpage-v1 这个调用方。
Destination Service：指的是当前版本的服务调用了哪些服务，比如 review-v3 这个服务，就可以看到 ratings.default.svc.cluster.local 这个被调方服务。
接下来来看几个面板展示的信息。
WORKLOAD: reviews-v3.default：这里包含了 review-v3 这个 workload 的一些基础信息，包含QPS、错误统计、延时等信息。
INBOUND WORKLOAD：展示了不同的调用方的 workload 维度的基础信息。
OUTBOUND SERVICES：展示了当前服务访问其他服务的监控信息。
