传统监控系统
监控系统通常由指标采集子系统和数据处理子系统组成。指标采集子系统主要负责信息采集、过滤、汇总和存储；数据处理子系统主要负责数据分析、展现、预警和告警等。传统的监控系统一般有ELK 和 Nagios & Zabbix。
ELK
ELK 是 Elastic 公司推出的监控系统，包含了 Elasticsearch、Logstash 和 Kibana，分别作为存储引擎、日志收集和前端展示系统。其中Elasticsearch 是核心，其他两个都可以替换，较常见的替换方案是 Filebeat 和 Graylog。
其中Filebeat 是由 Go 语言编写的轻量级日志收集工具。日志可以直接传输到 Elasticsearch 中，可以传输到 Logstash 进行一些数据处理。而Graylog 是一套代替 ELK 的日志收集分析系统，其中保留了 Elasticsearch 的存储部分，提供了 collector-sidecar 用于日志收集，并继承了 Web 图形界面，用于搜索和图形化展示。
总体来说，ELK 是一套传统的可观测性系统，主要利用之前提到的可观测性组件之一——日志来提供监控功能，优点是数据准确性高，但由于日志需要存储和建立索引，成本会比较高。这套系统在互联网的中期使用非常多，因为对原有系统没有任何侵入性，也非常容易接入。
Nagios & Zabbix
Nagios 和 Zabbix 都是传统的运维监控工具，主要监控主机、网络，以及业务进程端口的信息和状态。主要以插件的方式进行扩展，通过插件扩展可以检测主机的 CPU、内存、硬盘等信息，也可以检测各种不同的网络协议，但对于检测微服务应用程序内的信息几乎是无能为力的。
随着微服务架构和云原生系统的发展，大家对应用程序内的可观测性提出了更高的要求，不仅仅是系统级别的监控，包括应用自身的黄金指标（延时、通信量、饱和度、错误率）和一些业务级别的指标都需要实时的可观测。
现代化常用的 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：展示了当前服务访问其他服务的监控信息。
常见问题
Prometheus 适合什么样的监控场景？
Metrics 数据监控，并不适合要求数据 100% 准确的场景，更多的是反映一段时间内某个数据指标的趋势和大概值。采集数据是存在间隔的，计算数据也是有时间区间的，所以很难反映某一时刻的准确值，比如 CPU 的峰值，大概率会被平均掉。如果要查看精准数据，最好通过日志的方式收集后检索查看。
单个服务节点 Metrics 数量限制
Prometheus 虽然性能强大，但如果无规范的使用，随着采集数据节点增多，依然难以保证其稳定性。比如一些 RESTful 规范的 path（比如 /test/123，其中 123 为变量），如果不采取一些措施聚合，会造成 Metrics 爆炸。Metrics 的爆炸不仅会导致服务 OOM，也会导致 Prometheus 的内存使用量增大和检索变慢。
另外过多的标签变量、过多的 Histogram bucket，都会导致 Metrics 数量的增加。比如不合理地记录了调用端的来源 IP，同时也记录了服务自身的 IP，两者的 Metrics 数量就会变成乘积关系。这些不合理的指标不光会影响服务自身，也会影响 Prometheus 的稳定性，所以在输出 Metrics 信息的时候一定要注意，应该限制程序 Metrics 数量，加一个默认的上限条件。
RESTful path 如何处理？
无论是在 Metrics 系统中，还是 Trace 系统中，都会遇到此类问题。RESTful 格式的 path 在某一阶段非常流行，特别是在 PC 互联网时代非常适合搜索引擎的 SEO，而且看起来美观，所以被广泛使用。
如果说在 Web 客户端使用还有因可循，但在微服务架构的内网使用就完全不可理解了，毕竟内网无法被搜索引擎搜索到。所以在微服务架构中，如果使用 HTTP 协议作为通信协议，建议抛弃 RESTful 的做法。
当然对于残留的一些服务，我们也使用 Trie Tree 的方式做了数据聚合，当某一层 path 大于一定阈值的时候，就抛弃之前的记录，合并为一个节点存储。这其实是 HTTP Server 中路由组件的一种逆向操作，在路由组件中一般会采用 Trie Tree 做路由匹配。
标签：服务,Istio,信息,观测,Metrics,Prometheus,监控,数据 From： https://www.cnblogs.com/muzinan110/p/17061189.html