Istio可观测性(监控)

传统监控系统

监控系统通常由指标采集子系统和数据处理子系统组成。指标采集子系统主要负责信息采集、过滤、汇总和存储；数据处理子系统主要负责数据分析、展现、预警和告警等。传统的监控系统一般有ELK 和 Nagios & Zabbix。

ELK

ELK 是 Elastic 公司推出的监控系统，包含了 Elasticsearch、Logstash 和 Kibana，分别作为存储引擎、日志收集和前端展示系统。其中Elasticsearch 是核心，其他两个都可以替换，较常见的替换方案是

其中Filebeat 是由 Go 语言编写的轻量级日志收集工具。日志可以直接传输到 Elasticsearch 中，可以传输到 Logstash 进行一些数据处理。而Graylog 是一套代替 ELK 的日志收集分析系统，其中保留了

总体来说，ELK 是一套传统的可观测性系统，主要利用之前提到的可观测性组件之一——日志来提供监控功能，优点是数据准确性高，但由于日志需要存储和建立索引，成本会比较高。这套系统在互联网的中期使用非常多，因为对原有系统没有任何侵入性，也非常容易接入。

Nagios & Zabbix

Nagios 和 Zabbix 都是传统的运维监控工具，主要监控主机、网络，以及业务进程端口的信息和状态。主要以插件的方式进行扩展，通过插件扩展可以检测主机的

随着微服务架构和云原生系统的发展，大家对应用程序内的可观测性提出了更高的要求，不仅仅是系统级别的监控，包括应用自身的黄金指标（延时、通信量、饱和度、错误率）和一些业务级别的指标都需要实时的可观测。

现代化常用的

Metrics 主要是用时序性数据库记录每个时间点的监控数据，通过主动拉取或者程序上报的方式记录，然后实时计算一段时间的数据，并通过图形界面的方式展现出来。它的特点是实时性强、可观测指标丰富，适合查看一段时间内的指标趋势。

StatsD+Graphite

StatsD 是 Node.js 编写的一个Metrics 指标采集系统，通过

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 系统最大的不同，是提供了一整套完整的监控告警解决方案，包含了数据采集、数据存储和告警。

另外还有两个非常重要的特性，也是现代化监控系统的必要标志：

采用了

支持服务发现，默认支持了

至此，我们介绍了常见的

Prometheus 组成和架构

Prometheus 架构由以下模块构成。

Prometheus Server：用于收集和存储

Service Disvovery：用于服务发现，获取服务对应的

PushGateway：提供推送的方式采集数据，主要用于

Exporters：用于一些第三方服务，通过转换提供符合

Client Library：为各种语言提供的客户端库，提供

Alertmanager：告警管理器，接收

Prometheus 数据模型

下面，通过一条简单的

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 类型。它统计了服务启动至目前所有请求的数据，通过。Counter 类型是 Prometheus Server 端计算的，相对于下面讲到的 Gauge，占用服务自身更少，建议高性能的微服务首选此种类型。

Gauge

适合记录瞬时值，比如统计一些突发事件，例如是否产生了熔断、限流等事件。因为是客户端 SDK 计算的，不太适合一些经常变化的数据。如果数据是一直增加的，建议使用；当然如果数据有增有减，也比较适合，因为监控中很少遇到增减比较频繁的数据。

degrade_events{event="eventBreakerOpenStatus",service="serviceB"}

Histogram

柱状图，适合统计服务的

negri_http_response_time_us_bucket{client="serviceA",exported_service="serviceB",le="0.5",path="/ping"}

如上述内容，可以通过查询语句绘制出 90 延时、95 延时、99 延时等指标， Histogram 和 Counter 类型一样，都是 Prometheus Server 端计算的，所以非常适合高性能的场景使用，相对于下面讲解的

Summary

类似于 Histogram，适合统计服务的 99 延时信息。Summary 和 Gauge 类型一样，都是在程序内计算的，所以并不能像 Histogram 一样，在绘制图形的时候灵活的设置百分位，但相对来说，Summary 的数据也更加精准。

这里讲完了

Grafana 图形化展示

Grafana 是一套可视化监控指标工具，主要用于时序数据的展示，包括 Graphite、Elasticsearch、InfluxDB、Prometheus、CloudWatch、MySQL 和 OpenTSDB。其中最常见的就是 Prometheus+Grafana 的组合。

在页面的最上方，有几个选项，可以选择需要的参数。

Service：服务名，这里的服务名就是在

Client Workload Namespace（Or Service Workload Namespace）：这里指的是

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 也必须注入客户端服务名。这个注入也非常容易出问题，比如写入错误的服务名或者其他服务的服务名，这种问题在

Istio 这样的 Service Mesh 解决方案则没有这样的困扰，可以直接通过控制面下发当前服务的服务名，让，不允许业务代码编写人员修改这个服务名，从而在根本上杜绝了调用方服务名出错的问题。

Service Workload：这里选中

接下来展示了 SERVICE: reviews.default.svc.cluster.local 的一些常见信息，比如客户端/服务端请求的 QPS、成功率、延时等。这里所有的指标都有两个维度，一个是服务端自身的，一个是Client 端的，相对来说

再下面的面板是

最后的面板是

相对于 istio-services-dashboard，这个页面最大的优势，是可以看到，比如这里选中

以客户端的视角，查看服务的出流量在很多场景下也是非常重要的，很多时候不仅要关注其他服务调用我们服务的健康情况，也要关注我们访问其他服务的健康状况，在一些情况下二者是息息相关的。

和上面讲解

Namespace：这里和上面

Workload：指的是服务的不同版本。比如

Inbound Workload：指的是不同版本的调用方服务，比如

Destination Service：指的是当前版本的服务调用了哪些服务，比如

接下来来看几个面板展示的信息。

WORKLOAD: reviews-v3.default：这里包含了

INBOUND WORKLOAD：展示了不同的调用方的

OUTBOUND SERVICES：展示了当前服务访问其他服务的监控信息。

常见问题

Prometheus 适合什么样的监控场景？

Metrics 数据监控，并不适合要求数据 100% 准确的场景，更多的是反映一段时间内某个数据指标的趋势和大概值。采集数据是存在间隔的，计算数据也是有时间区间的，所以很难反映某一时刻的准确值，比如 CPU 的峰值，大概率会被平均掉。如果要查看精准数据，最好通过日志的方式收集后检索查看。

单个服务节点

Prometheus 虽然性能强大，但如果无规范的使用，随着采集数据节点增多，依然难以保证其稳定性。比如一些 RESTful 规范的 path（比如 /test/123，其中 123 为变量），如果不采取一些措施聚合，会造成 Metrics 爆炸。Metrics 的爆炸不仅会导致服务 OOM，也会导致 Prometheus 的内存使用量增大和检索变慢。

另外过多的标签变量、过多的 Histogram bucket，都会导致 Metrics 数量的增加。比如不合理地记录了调用端的来源。这些不合理的指标不光会影响服务自身，也会影响

RESTful path 如何处理？

无论是在

如果说在 Web 客户端使用还有因可循，但在微服务架构的内网使用就完全不可理解了，毕竟内网无法被搜索引擎搜索到。所以在微服务架构中，如果使用。

当然对于残留的一些服务，我们也使用