prometheus原理简介
Prometheus
一、Prometheus简介
- Prometheus 是一款时序（time series）数据库，但它的功能却并非止步于 TSDB，而是一款设计用于进行目标（Target）监控的关键组件；
- Prometheus是一个开源的系统监控和报警系统，现在已经加入到CNCF基金会，成为继k8s之后第二个在CNCF托管的项目，在kubernetes容器管理系统中，通常会搭配prometheus进行监控，同时也支持多种exporter采集数据，还支持pushgateway进行数据上报，Prometheus性能足够支撑上万台规模的集群；
- Prometheus基本原理是通过 HTTP 协议周期性抓取(pull) 被监控组件的状态，这样做的好处是任意组件只要提供HTTP接口就可以接入监控系统，不需要任何SDK或者其他的集成过程。
官方文档： https://prometheus.io/docs/
推荐阅读文章：https://www.prometheus.wang/quickstart/why-monitor.html
1.1 基本原理
服务发现：Prometheus周期性得以pull的形式对target进行指标采集，而监控目标集合是通过配置文件中所定义的服务发现机制来动态生成的。也可以静态配置；
relabel：当服务发现得到所有target后，Prometheus会根据job中的relabel_configs配置对target进行relabel操作，得到target最终的label集合。
采集：进行完上述操作后，Prometheus为这些target创建采集循环，按配置文件里配置的采集间隔进行周期性拉取，采集到的数据根据Job中的metrics_relabel_configs进行relabel，然后再加入上边得到的target最终label集合，综合后得到最终的数据。
存储：Prometheus不会将采集到的数据直接落盘，而是会将近2小时的series缓存在内存中，2小时后，Prometheus会进行一次数据压缩，将内存中的数据落盘。
流程：服务发现 ==> targets ==> relabel ==> 抓取 ==> metrics_relabel ==> 缓存 ==> 2小时落盘
二、Prometheus 优点及局限性
2.1 Prometheus优点
- 监控数据基于时间序列存储数据库内便于对数据聚合；
- 各个组件有成熟的高可用方案没有单点故障；
- 适合对云环境监控对kubernetes很好的支持；
- 不依赖分布式存储，单个服务器节点可直接工作；
- 使用的是PromSQL：一种灵活的查询语言，可以利用多维数据完成复杂的查询；
- 支持多种多样的图表和界面展示，一般和grafana配合使用
2.2 Prometheus局限性 - 它的数据是存在内存中的，重启之后和之前的统计全部清零；
- 每个程序只统计自己的请求次数，如果部署了多个点，则请求得到的统计数据只是单个点的数据，没有做汇总，数据不准确；
- Prometheus 是基于 指标（Metric）的监控，不适用于日志（Logs）、事件（Event）、调用链（Tracing）；它更多地展示的是趋势性监控，而非精准数据；
- Prometheus 认为只有最近的监控数据才有查询的需要，其本地存储的设计初衷只是保存短期（例如一个月）的数据，因而不支持针对大量的历史数据进行存储，若需要存储长期的历史数据，建议基于远端存储机制将数据保存于 InfluxDB 或 OpenTSDB等系统中
- Prometheus 的集群机制成熟度不高
三、Prometheus 组件介绍
3.1 Prometheus Server - Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储及查询；
- Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据；
- Prometheus Sever需要对采集到的数据进行存储，Prometheus Server本身就是一个实时数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中；
- Prometheus Server对外提供了自定义的PromQL，实现对数据的查询以及分析；
- Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据。
3.2 Client Library
客户端库，检测应用程序代码，目的在于为那些期望原生提供 Instrumentation 功能的应用程序提供便捷的开发途径。当Prometheus抓取实例的HTTP端点时，客户端库会将所有跟踪的metrics指标的当前状态发送到prometheus server端。
3.3 Exporters
Prometheus的数据采集组件，负责收集目标对象（host, container…）的性能数据，并通过HTTP接口提供给Prometheus Server。支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等。
3.4 Alertmanager
从 Prometheus server 端接收到 “告警通知” 后，会进行去重，分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件，微信，短信等。
3.5 Pushgateway
接收那些通常由短期作业生成的指标数据的网关，各个目标主机可上报数据到 Pushgateway，然后Prometheus Server统一从 Pushgateway 进行指标拉取操作，但某些现有系统是通过Push方式实现的，为了接入这些系统，Prometheus提供了对PushGateway的支持，这些系统主动推送metrics到PushGateway，而Prometheus只是定时去Gateway上抓取数据
3.6 Service Discovery
动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境尤为有用，该组件目前由 Prometheus Server 内建支持。用户提供的静态资源列表，基于文件的发现，例如，使用配置管理工具生成在Prometheus中自动更新的资源列表，自动发现
四、Prometheus 模型介绍
4.1 数据模型
Prometheus 仅用于以 “键值”形式存储时序式的聚合数据，它并不支持存储文本信息
- 其中的键称为指标（Metric），它通常意味着 CPU 速率、内存使用率或分区空闲比例等
同一指标可能会适配多个目标或设备，因此它使用标签作为元数据，从而Metric 添加更多的信息描述维度 - 这些标签还可以作为过滤器进行指标过滤及聚合运算
时序样本：
在时间序列中的每个点，称为一个样本（sample）,样本由以下三部分组成：
指标：指标名称和描述当前样本
时间戳：一个精确到毫秒的时间戳;
样本值：一个float64的浮点型数据表示当前样本的值。
4.2 指标类型
Prometheus使用 4 种方法来描述监视的指标： Counter, Gauge, Summary，Histogram
Counter：计算器
用于保存单调递增性的数据，例如站点访问次数等，不能为负值，也不支持减少，但可以重置回 0 ，计数器统计的数据是递增的，不能使用计数器来统计可能减小的指标，计数器统计的指标是累计增加的，如http请求的总数，出现的错误总数，总的处理时间（如cpu累计使用时间），api请求总数，已完成的任务数等
Gauge：仪表盘
用于存储有着起伏特征的指标数据， 例如用于统计cpu使用率，内存使用率，磁盘使用率，温度等指标，还可统计上升和下降的计数，如并发请求数等，Gauge 是 Counter 的超集，但存在指标数据丢失的可能性时，Counter 能让用户确切了解指标随时间的变化状态，而 Gauge 则可能随时间流逝而精准度越来越低
Histogram：直方图
它会在一段内对数据进行采样，并将其计入可配置的 bucket 之中；Histogram能够存储更多的信息，包括样本值分布在每个 bucket（bucket自身的可配置）中的数量、所有样本值之和以及总的样本数量，从而 Prometheus 能够使用内置的函数进行如下操作。 - 计算样本平均值：以值的总和除以值的数量；
- 计算样本分位值：分位值有助于了解符合特定标准的数据个数，例如评估响应时长超过 1 秒钟的请求比例，若超过20%即发送报警等；
Summary：摘要
Histogram的扩展类型，但它是直接由被监控端自行聚合计算出分位数，并将结果响应给 Prometheus Server 的样本采集请求，因而其分位数是由监控端完成。主要用于表示一段时间内数据采样结果
4.3 安全模型
普罗米修斯可以通过多种方式进行配置和部署。它对信任做了两个宽泛的假设: - 不受信任的用户将能够访问普罗米修斯服务器的HTTP API，从而访问数据库中的所有数据；
- 只有受信任的用户才能访问Prometheus及其组件的命令行、配置文件、规则文件和运行时配置；
因此，Prometheus及其组件不提供任何服务器端身份验证、授权或加密。如果你在一个需要更加安全的环境中工作，则需要自己实施安全控制 - 例如，通过反向代理访问Prometheus服务器或者正向代理exporter。由于不同版本的配置潜在地会发生较大变化，本书没有记录如何执行这些操作。
五、Promethus 工作流程
5.1 Prometheus Server 可定期从活跃的目标主机上（target）拉取监控指标数据，目标主机的监控数据可以通过配置静态job或者服务发现的方式被Prometheus server采集到，这种方式默认是pull方式拉取指标；也可以通过pushgateway把采集的数据上报到Prometheus server中；还可以通过一些组件自带的exporter采集相应组件的数据；
5.2 Prometheus server的时间序列把采集到的监控指标数据整合并保存到本地的磁盘或者数据库中；
5.3 Prometheus采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到Alertmanager；
5.4 Alertmanager 通过配置报警接受方，发送报警到邮件，微信等；
5.5 Prometheus 自带的web ui界面提供PromQL查询语言，可查询监控数据；
5.6 Grafana 可接入Prometheus数据源，把监控数据以图形化展示出；
六、Prometheus的存储
6.1存储原理
-
prometheus 提供了本地存储（TSDB）时序型数据库的存储方式，在2.0版本之后，压缩数据的能力得到了大大的提升，单节点情况下可以满足大部分用户的需求，但本地存储阻碍了prometheus集群化的实现，因此在集群中应当采用 其他时序性数据来替代，比如influxdb。
-
prometheus按照block块的方式来存储数据，每2小时为一个时间单位，首先会存储到内存中，当到达2小时后，会自动写入磁盘中。
-
为防止程序异常而导致数据丢失，采用了WAL机制，即2小时内记录的数据存储在内存中的同时，还会记录一份日志，存储在block下的wal目录中。当程序再次启动时，会将wal目录中的数据写入对应的block中，从而达到恢复数据的效果。
6.1 本地存储
会直接保留到本地磁盘，性能上建议使用SSD且不要保存超过一个月的数据。记住，任何版本的Prometheus都不支持NFS。一些实际生产案例告诉我们，Prometheus存储文件如果使用NFS，则有损坏或丢失历史数据的可能。
6.2 远程存储
适用于存储大量的监控数据。Prometheus支持的远程存储包括OpenTSDB、InfluxDB、Elasticsearch、Kakfa、PostgreSQL等。远程存储需要配合中间层的适配器进行转换，主要涉及Prometheus中的remote_write和remote_read接口。在实际生产中，远程存储会出现各种各样的问题，需要不断地进行优化、压测、架构改造甚至重写上传数据逻辑的模块等工作。
七、Prometheus基础资源监控
7.1 网络监控
网络性能监控：主要涉及网络监测，网络实时流量监控（网络延迟、访问量、成功率）和历史数据统计、汇总和历史数据分析等功能。
网络***检测：主要针对内网或者外网的网络***。如DDoS***的。通过分析异常流量来确定网络***行为。
设备监控：主要针对数据中心内的多种网络设备进行监控。包括路由器，防火墙和交换机等硬件设备，可以通过snmp等协议收集数据。
7.2 存储监控
存储性能监控方面：存储通常监控块的读写速率，IOPS。读写延迟，磁盘用量等；文件存储通常监控文件系统inode。读写速度、目录权限等。
存储系统监控方面：不同的存储系统有不同的指标，例如，对于ceph存储需要监控OSD, MON的运行状态，各种状态pg的数量以及集群IOPS等信息。
存储设备监控方面：对于构建在x86服务器上的存储设备，设备监控通过每个存储节点上的采集器统一收集磁盘、SSD、网卡等设备信息；存储厂商以黑盒方式提供商业存储设备，通常自带监控功能，可监控设备的运行状态，性能和容量的。
7.3 服务器监控
CPU：涉及整个 CPU 的使用量、用户态百分比、内核态百分比，每个 CPU 的使用量、等待队列长度、I/O 等待百分比、CPU 消耗最多的进程、上下文切换次数、缓存命中率等。
内存：涉及内存的使用量、剩余量、内存占用最高的进程、交换分区大小、缺页异常等。
网络 I/O：涉及每个网卡的上行流量、下行流量、网络延迟、丢包率等。
磁盘 I/O：涉及硬盘的读写速率、IOPS、磁盘用量、读写延迟等。
7.4 中间件监控
消息中间件： RabbitMQ Exporter、Kafka Exporter
Web 服务中间件：Apache Exporter、Nginx Exporter
数据库中间件：MySQL Exporter、PostgreSQL Exporter、Redis Exporter
八、Prometheus告警处理
8.1 Prometheus告警简介
告警能力在Prometheus的架构中被划分成两个独立的部分。如下所示，通过在Prometheus中定义AlertRule（告警规则），Prometheus会周期性的对告警规则进行计算，如果满足告警触发条件就会向Alertmanager发送告警信息。
在Prometheus中一条告警规则主要由以下几部分组成：
- 告警名称：用户需要为告警规则命名，当然对于命名而言，需要能够直接表达出该告警的主要内容
- 告警规则：告警规则实际上主要由PromQL进行定义，其实际意义是当表达式（PromQL）查询结果持续多长时间（During）后出发告警
在Prometheus中，还可以通过Group（告警组）对一组相关的告警进行统一定义。当然这些定义都是通过YAML文件来统一管理的。
Alertmanager作为一个独立的组件，负责接收并处理来自Prometheus Server(也可以是其它的客户端程序)的告警信息。Alertmanager可以对这些告警信息进行进一步的处理，比如当接收到大量重复告警时能够消除重复的告警信息，同时对告警信息进行分组并且路由到正确的通知方，Prometheus内置了对邮件，Slack等多种通知方式的支持，同时还支持与Webhook的集成，以支持更多定制化的场景。例如，目前Alertmanager还不支持钉钉，那用户完全可以通过Webhook与钉钉机器人进行集成，从而通过钉钉接收告警信息。同时AlertManager还提供了静默和告警抑制机制来对告警通知行为进行优化。
8.1 Alertmanager特性
Alertmanager除了提供基本的告警通知能力以外，还主要提供了如：分组、抑制以及静默等告警特性：
分组：
分组机制可以将详细的告警信息合并成一个通知。在某些情况下，比如由于系统宕机导致大量的告警被同时触发，在这种情况下分组机制可以将这些被触发的告警合并为一个告警通知，避免一次性接受大量的告警通知，而无法对问题进行快速定位。
例如，当集群中有数百个正在运行的服务实例，并且为每一个实例设置了告警规则。假如此时发生了网络故障，可能导致大量的服务实例无法连接到数据库，结果就会有数百个告警被发送到Alertmanager。
而作为用户，可能只希望能够在一个通知中中就能查看哪些服务实例收到影响。这时可以按照服务所在集群或者告警名称对告警进行分组，而将这些告警内聚在一起成为一个通知。
告警分组，告警时间，以及告警的接受方式可以通过Alertmanager的配置文件进行配置。
抑制：
抑制是指当某一告警发出后，可以停止重复发送由此告警引发的其它告警的机制。
例如，当集群不可访问时触发了一次告警，通过配置Alertmanager可以忽略与该集群有关的其它所有告警。这样可以避免接收到大量与实际问题无关的告警通知。
抑制机制同样通过Alertmanager的配置文件进行设置。
静默：
静默提供了一个简单的机制可以快速根据标签对告警进行静默处理。如果接收到的告警符合静默的配置，Alertmanager则不会发送告警通知。
静默设置需要在Alertmanager的Werb页面上进行设置。
九、Prometheus集群高可用
9.1 高可用模式
基本HA模式只能确保Prometheus服务的可用性问题，但是不解决Prometheus Server之间的数据一致性问题，以及持久化问题（数据丢失后无法恢复），也无法进行动态的扩展。因此这种部署方式适合监控规模不大，Prometheus Server也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。
9.2 高可用+远程存储方案
在解决了Prometheus服务的可用性的基础上，同时确保了数据的持久化，当Prometheus Server 发生宕机或者数据丢失的情况下，可以快速的恢复。同时Prometheus Server可能很好的进行迁移。因此该方案适用于用户监控规模不大，但是希望能够将监控数据持久化，同时能确保Prometheus Server的可迁移的场景。
9.3 高可用 + 远程存储 +联邦集群方案
Prometheus的性能瓶颈主要在于大量的采集任务，因此用户需要利用Prometheus联邦集群的特性，将不同类型的采集任务划分到不同的Prometheus子服务中，从而实现功能分区，比如一个Prometheus负责采集节点的指标数据，另一个Prometheus负责采集应用业务的监控指标数据，最后在上层通过Prometheus对数据进行汇总。
9.4 Alertmanager高可用
为了提升Promthues的服务可用性，通常用户会部署两个或者两个以上的Promthus Server，它们具有完全相同的配置包括Job配置，以及告警配置等。当某一个Prometheus Server发生故障后可以确保Promthues持续可用。
同时基于Alertmanager的告警分组机制即使不同的Prometheus Sever分别发送相同的告警给Alertmanager，Alertmanager也可以自动将这些告警合并为一个通知向receiver发送。
虽然Alertmanager能够同时处理多个相同的Prometheus Server所产生的告警。但是由于单个Alertmanager的存在，当前的部署结构存在明显的单点故障风险，当Alertmanager单点失效后，告警的后续所有业务全部失效。
如下所示，最直接的方式，就是尝试部署多套Alertmanager。但是由于Alertmanager之间不存在并不了解彼此的存在，因此则会出现告警通知被不同的Alertmanager重复发送多次的问题。
为了解决这一问题，如下所示。Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。确保及时在多个Alertmanager分别接收到相同告警信息的情况下，也只有一个告警通知被发送给Receiver。
9.5 Gossip协议
Gossip是分布式系统中被广泛使用的协议，用于实现分布式节点之间的信息交换和状态同步。Gossip协议同步状态类似于流言或者病毒的传播，如下所示：
一般来说Gossip有两种实现方式分别为Push-based和Pull-based。在Push-based当集群中某一节点A完成一个工作后，随机的从其它节点B并向其发送相应的消息，节点B接收到消息后在重复完成相同的工作，直到传播到集群中的所有节点。而Pull-based的实现中节点A会随机的向节点B发起询问是否有新的状态需要同步，如果有则返回。
在简单了解了Gossip协议之后，我们来看Alertmanager是如何基于Gossip协议实现集群高可用的。如下所示，当Alertmanager接收到来自Prometheus的告警消息后，会按照以下流程对告警进行处理：
1.在第一个阶段Silence中，Alertmanager会判断当前通知是否匹配到任何的静默规则，如果没有则进入下一个阶段，否则则中断流水线不发送通知。
2. 在第二个阶段Wait中，Alertmanager会根据当前Alertmanager在集群中所在的顺序(index)等待index * 5s的时间。
3. 当前Alertmanager等待阶段结束后，Dedup阶段则会判断当前Alertmanager数据库中该通知是否已经发送，如果已经发送则中断流水线，不发送告警，否则则进入下一阶段Send对外发送告警通知。
4. 告警发送完成后该Alertmanager进入最后一个阶段Gossip，Gossip会通知其他Alertmanager实例当前告警已经发送。其他实例接收到Gossip消息后，则会在自己的数据库中保存该通知已发送的记录。
因此如下所示，Gossip机制的关键在于两点：
-
Silence设置同步：Alertmanager启动阶段基于Pull-based从集群其它节点同步Silence状态，当有新的Silence产生时使用Push-based方式在集群中传播Gossip信息。
-
通知发送状态同步：告警通知发送完成后，基于Push-based同步告警发送状态。Wait阶段可以确保集群状态一致。
Alertmanager基于Gossip实现的集群机制虽然不能保证所有实例上的数据时刻保持一致，但是实现了CAP理论中的AP系统，即可用性和分区容错性。同时对于Prometheus Server而言保持了配置了简单性，Promthues Server之间不需要任何的状态同步。
十、Exporter常见工具
10.1 Exporter介绍
Exporter是Prometheus监控中重要的组成部分，负责数据指标的采集。数据采集插件。官方给出的插件有node_exporter、blackbox_exporter、mysqld_exporter、snmp_exporter等，官方和一些社区提供好多exproter, 我们可以直接拿过来采集我们的数据。
10.2 Exporter的分类 -
社区提供的：
Prometheus社区提供了丰富的Exporter实现，涵盖了从基础设施，中间件以及网络等各个方面的监控功能。这些Exporter可以实现大部分通用的监控需求。下表列举一些社区中常用的Exporter：
官方的exporter下载地址：https://prometheus.io/docs/instrumenting/exporters/
-
用户自定义的
除了直接使用社区提供的Exporter程序以外，用户还可以基于Prometheus提供的Client Library创建自己的Exporter程序，目前Promthues社区官方提供了对以下编程语言的支持：Go、Java/Scala、Python、Ruby。同时还有第三方实现的如：Bash、C++、Common Lisp、Erlang,、Haskeel、Lua、Node.js、PHP、Rust等。
10.3 Exporter的运行方式
从Exporter的运行方式上来讲，又可以分为： -
独立使用的
以Node Exporter为例（如下图所示），由于操作系统本身并不直接支持Prometheus，同时用户也无法通过直接从操作系统层面上提供对Prometheus的支持。因此，用户只能通过独立运行一个程序的方式，通过操作系统提供的相关接口，将系统的运行状态数据转换为可供Prometheus读取的监控数据。 除了Node Exporter以外，比如MySQL Exporter、Redis Exporter等都是通过这种方式实现的。 这些Exporter程序扮演了一个中间代理人的角色。 -
集成到应用中的
为了能够更好的监控系统的内部运行状态，有些开源项目如Kubernetes，ETCD等直接在代码中使用了Prometheus的Client Library，提供了对Prometheus的直接支持。这种方式打破的监控的界限，让应用程序可以直接将内部的运行状态暴露给Prometheus，适合于一些需要更多自定义监控指标需求的项目。
可以看到当前Node Exporter获取到的当前主机的所有监控数据
十一、最佳实栈
11.1 监控所有
| 级别 | 监控什么 | Exporter |
| 网络 | 网络协议：http、dns、tcp、icmp；网络硬件：路由器，交换机等 | BlockBox Exporter;SNMP Exporter |
| 主机 | 资源用量 | node exporter |
| 容器 | 资源用量 | cAdvisor |
| 应用(包括Library) | 延迟，错误，QPS，内部状态等 | 代码中集成Prmometheus Client |
| 中间件状态 | 资源用量，以及服务状态 | 代码中集成Prmometheus Client |
| 编排工具 | 集群资源用量，调度等 | Kubernetes Components |
对于传统监控解决方案而言，用户看到的依然是一个黑盒，用户无法真正了解系统的真正的运行状态。因此Prometheus鼓励用户监控所有的东西。下面列举一些常用的监控维度。
级别 监控什么 Exporter
网络 网络协议：http、dns、tcp、icmp；网络硬件：路由器，交换机等 BlockBox Exporter;SNMP Exporter
主机 资源用量 node exporter
容器 资源用量 cAdvisor
应用(包括Library) 延迟，错误，QPS，内部状态等 代码中集成Prmometheus Client
中间件状态 资源用量，以及服务状态 代码中集成Prmometheus Client
编排工具 集群资源用量，调度等 Kubernetes Components
11.2 四个黄金指标
4个黄金指标可以在服务级别帮助衡量终端用户体验、服务中断、业务影响等层面的问题。主要关注与以下四种类型的指标：延迟，通讯量，错误以及饱和度：
- 延迟：服务请求所需时间。
记录用户所有请求所需的时间，重点是要区分成功请求的延迟时间和失败请求的延迟时间。 例如在数据库或者其他关键祸端服务异常触发HTTP 500的情况下，用户也可能会很快得到请求失败的响应内容，如果不加区分计算这些请求的延迟，可能导致计算结果与实际结果产生巨大的差异。除此以外，在微服务中通常提倡“快速失败”，开发人员需要特别注意这些延迟较大的错误，因为这些缓慢的错误会明显影响系统的性能，因此追踪这些错误的延迟也是非常重要的。 - 通讯量：监控当前系统的流量，用于衡量服务的容量需求。
流量对于不同类型的系统而言可能代表不同的含义。例如，在HTTP REST API中, 流量通常是每秒HTTP请求数； - 错误：监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率。
对于失败而言有些是显式的(比如, HTTP 500错误)，而有些是隐式(比如，HTTP响应200，但实际业务流程依然是失败的)。
对于一些显式的错误如HTTP 500可以通过在负载均衡器(如Nginx)上进行捕获，而对于一些系统内部的异常，则可能需要直接从服务中添加钩子统计并进行获取。 - 饱和度：衡量当前服务的饱和度。
主要强调最能影响服务状态的受限制的资源。 例如，如果系统主要受内存影响，那就主要关注系统的内存状态，如果系统主要受限与磁盘I/O，那就主要观测磁盘I/O的状态。因为通常情况下，当这些资源达到饱和后，服务的性能会明显下降。同时还可以利用饱和度对系统做出预测，比如，“磁盘是否可能在4个小时候就满了”。