Linux性能优化实战学习笔记：第五十三讲

1、上节回顾

在前面的内容中，我为你介绍了不少性能分析的原理、思路以及相关的工具。不过，在实际的性能分析中，一个很常见的现象是，明明发生了性能瓶颈，但当你登陆到服务器中想要排查的时
候，却发现瓶颈已经消失了。或者说，性能问题老是时不时地发生，但却很难找出发生规律，也很难重现。

当面对这样的场景时，你可能会发现，咱们前面介绍的各类工具、方法都“失效“了。为何呢？由于它们都须要在性能问题发生的时刻才有效，而在这些过后分析的场景中，咱们就很难发
挥它们的威力了。

那该怎么办呢？置之不理吗？其实以往，不少应用都是等到用户抱怨响应慢了，或者系统崩溃了后，才发现系统或者应用程序的性能出现了问题。虽然最终也能发现问题，但显然，这种方法是
不可取的，由于严重影响了用户的体验。

而要解决这个问题，就要搭建监控系统，把系统和应用程序的运行情况监控起来，并定义一系列的策略，在发生问题时第一时间告警通知。一个好的监控系统，不只能够实时暴露系统的各类问
题，更能够根据这些监控到的状态，自动分析和定位大体的瓶颈来源，从而更精确地把问题汇报给相关团队处理。

要作好监控，最核心的就是全面的、可量化的指标，这包括系统和应用两个方面。

从系统来讲，监控系统要涵盖系统的总体资源使用状况，好比咱们前面讲过的 CPU、内存、磁盘和文件系统、网络等各类系统资源。

而从应用程序来讲，监控系统要涵盖应用程序内部的运行状态，这既包括进程的 CPU、磁盘 I/O等总体运行情况，更须要包括诸如接口调用耗时、执行过程当中的错误、内部对象的内存使用等应
用程序内部的运行情况。

今天，我就带你一块儿来看看，如何对 Linux 系统进行监控。而在下一节，我将继续为你讲解应用程序监控的思路。

2、USE 法

在开始监控系统以前，你确定最想知道，怎么才能用简洁的方法，来描述系统资源的使用状况。你固然可使用专栏中学到的各类性能工具，来分别收集各类资源的使用状况。不过不要忘记，
每种资源的性能指标可都有不少，使用过多指标自己耗时耗力不说，也不容易为你创建起系统总体的运行情况。

在这里，我为你介绍一种专门用于性能监控的 USE（Utilization Saturation and Errors）法。USE 法把系统资源的性能指标，简化成了三个类别，即便用率、饱和度以及错误数。

1. 使用率，表示资源用于服务的时间或容量百分比。100% 的使用率，表示容量已经用尽或者所有时间都用于服务。
2. 饱和度，表示资源的繁忙程度，一般与等待队列的长度相关。100% 的饱和度，表示资源没法接受更多的请求。
3. 错误数表示发生错误的事件个数。错误数越多，代表系统的问题越严重。

这三个类别的指标，涵盖了系统资源的常见性能瓶颈，因此常被用来快速定位系统资源的性能瓶颈。这样，不管是对 CPU、内存、磁盘和文件系统、网络等硬件资源，仍是对文件描述符数、连
接数、链接跟踪数等软件资源，USE 方法均可以帮你快速定位出，是哪种系统资源出现了性能瓶颈。

那么，对于每一种系统资源，又有哪些常见的性能指标呢？回忆一下咱们讲过的各类系统资源原理，并不难想到相关的性能指标。这里，我把常见的性能指标画了一张表格，

方便你在须要时查看。

不过，须要注意的是，USE 方法只关注能体现系统资源性能瓶颈的核心指标，但这并非说其余指标不重要。诸如系统日志、进程资源使用量、缓存使用量等其余各种指标，也都须要咱们监控
起来。只不过，它们一般用做辅助性能分析，而 USE 方法的指标，则直接代表了系统的资源瓶颈。

3、监控系统

掌握 USE 方法以及须要监控的性能指标后，接下来要作的，就是创建监控系统，把这些指标保存下来；而后，根据这些监控到的状态，自动分析和定位大体的瓶颈来源；最后，再经过告警系
统，把问题及时汇报给相关团队处理。

能够看出，一个完整的监控系统一般由数据采集、数据存储、数据查询和处理、告警以及可视化展现等多个模块组成。因此，要从头搭建一个监控系统，其实也是一个很大的系统工程

不过，幸运的是，如今已经有不少开源的监控工具能够直接使用，好比最多见的 Zabbix、Nagios、Prometheus 等等。

下面，我就以 Prometheus 为例，为你介绍这几个组件的基本原理。以下图所示，就是Prometheus 的基本架构：

先看数据采集模块。最左边的 Prometheus targets 就是数据采集的对象，而 Retrieval 则负责采集这些数据。从图中你也能够看到，Prometheus 同时支持 Push 和 Pull 两种数据采集模式。

1. Pull 模式，由服务器端的采集模块来触发采集。只要采集目标提供了 HTTP 接口，就能够自由接入（这也是最经常使用的采集模式）。
2. Push 模式，则是由各个采集目标主动向 Push Gateway（用于防止数据丢失）推送指标，再由服务器端从 Gateway 中拉取过去（这是移动应用中最经常使用的采集模式）。

因为须要监控的对象一般都是动态变化的，Prometheus 还提供了服务发现的机制，能够自动根据预配置的规则，动态发现须要监控的对象。这在 Kubernetes 等容器平台中很是有效。

第二个是数据存储模块。为了保持监控数据的持久化，图中的 TSDB（Time series database）模块，负责将采集到的数据持久化到 SSD 等磁盘设备中。TSDB 是专门为时间序列数据设计的一
种数据库，特色是以时间为索引、数据量大而且以追加的方式写入。

第三个是数据查询和处理模块。刚才提到的 TSDB，在存储数据的同时，其实还提供了数据查询和基本的数据处理功能，而这也就是 PromQL 语言。PromQL 提供了简洁的查询、过滤功能，
而且支持基本的数据处理方法，是告警系统和可视化展现的基础。

第四个是告警模块。右上角的 AlertManager 提供了告警的功能，包括基于 PromQL 语言的触发条件、告警规则的配置管理以及告警的发送等。不过，虽然告警是必要的，但过于频繁的告警
显然也不可取。因此，AlertManager 还支持经过分组、抑制或者静默等多种方式来聚合同类告警，并减小告警数量。

最后一个是可视化展现模块。Prometheus 的 web UI 提供了简单的可视化界面，用于执行PromQL 查询语句，但结果的展现比较单调。不过，一旦配合 Grafana，就能够构建很是强大的
图形界面了。

介绍完了这些组件，想必你对每一个模块都有了比较清晰的认识。接下来，咱们再来继续深刻了解这些组件结合起来的总体功能。

好比，以刚才提到的 USE 方法为例，我使用 Prometheus，能够收集 Linux 服务器的 CPU、内存、磁盘、网络等各种资源的使用率、饱和度和错误数指标。而后，经过 Grafana 以及
PromQL 查询语句，就能够把它们以图形界面的方式直观展现出来。

 

 

4、小结

今天，我带你一块儿梳理了系统监控的基本思路。

系统监控的核心是资源的使用状况，包括 CPU、内存、磁盘和文件系统、网络等硬件资源，以及文件描述符数、链接数、链接跟踪数等软件资源。而这些资源，均可以经过 USE 法来创建核心性
能指标。

USE 法把系统资源的性能指标，简化成了三个类别，即便用率、饱和度以及错误数。 这三者任一类别太高时，都表明相对应的系统资源有可能存在性能瓶颈。

基于 USE 法创建性能指标后，还须要经过一套完整的监控系统，把这些指标从采集、存储、查询、处理，再到告警和可视化展现等串联起来。你能够基于 Zabbix、Prometheus 等各类开源
的监控产品，构建这套监控系统。这样，不只能够将系统资源的瓶颈快速暴露出来，还能够借助监控的历史，过后追查定位问题。

固然，除了系统监控以外，应用程序的监控也是必不可少的，我将在下一节课继续为你拆解。