Linux性能优化-总结
目录
系统监控的综合思路
USE方法
USE(Utilization Saturation and Errors)
USE法把系统资源的性能指标，简化成了三个类别，使用率，饱和度，错误数
- 使用率，表示资源用于服务的时间 或者容量的百分比，100%的使用率，笔试容器已经用尽或者全部时间都用于服务
- 饱和度，表示资源的繁忙程度，通常与等待队列的长度相关，100%的饱和度，表示资源无法接受更多的请求
- 错误数，表示发生错误的事件个数，错误数越多，表明系统的问题越严重
这三个类别的指标，涵盖了系统资源的常见性能瓶颈，所以常被用来快速定位系统资源的性能瓶颈，无论是对CPU，内存，
磁盘和文件系统，网络等硬件资源，还是对文件描述符，连接数，连接跟综数等软件资源，USE方法都可以快速定位，
是哪一种资源出现了性能瓶颈
下面是常见的性能指标
不过，需要注意的是，USE方法只关注能体现系统资源性能瓶颈的核心指标，但这并不是说其他指标不重要。诸如系统日志、进程资源使用量、缓存使用量等其他各类指标，也都需要我们监控起来。只不过，它们通常用作辅助性能分析，而 USE 方法的指标，则直接表明了系统的资源瓶颈。
监控系统
USE法之后，就是建立监控系统，把这些指标保存下来；然后，根据这些监控到的状态，自动分析和定位大致的瓶颈来源；最后，再通过告警系统，把问题及时汇报给相关团队处理。
可以看出，一个完整的监控系统通常由数据采集、数据存储、数据查询和处理、告警以及可视化展示等多个模块组成。所以，要从头搭建一个监控系统，其实也是一个很大的系统工程。
已经有大量现成的监工工具，最常见的 Zabbix、Nagios、Prometheus 等等。
如下图所示，就是 Prometheus 的基本架构：
第一个是数据采集模块。最左边的 Prometheus targets 就是数据采集的对象，而 Retrieval 则负责采集这些数据。Prometheus 同时支持 Push 和 Pull 两种数据采集模式。
- Pull 模式，由服务器端的采集模块来触发采集。只要采集目标提供了 HTTP 接口，就可以*接入（这也是最常用的采集模式）。
- Push 模式，则是由各个采集目标主动向 Push Gateway（用于防止数据丢失）推送指标，再由服务器端从 Gateway 中拉取过去（这是移动应用中最常用的采集模式）。
- 由于需要监控的对象通常都是动态变化的，Prometheus 还提供了服务发现的机制，可以自动根据预配置的规则，动态发现需要监控的对象。这在 Kubernetes 等容器平台中非常有效。
第二个是数据存储模块。为了保持监控数据的持久化，图中的 TSDB（Time series database）模块，负责将采集到的数据持久化到 SSD 等磁盘设备中。TSDB 是专门为时间序列数据设计的一种数据库，特点是以时间为索引、数据量大并且以追加的方式写入。
第三个是数据查询和处理模块。刚才提到的 TSDB，在存储数据的同时，其实还提供了数据查询和基本的数据处理功能，而这也就是 PromQL 语言。PromQL 提供了简洁的查询、过滤功能，并且支持基本的数据处理方法，是告警系统和可视化展示的基础。
第四个是告警模块。右上角的 AlertManager 提供了告警的功能，包括基于 PromQL 语言的触发条件、告警规则的配置管理以及告警的发送等。不过，虽然告警是必要的，但过于频繁的告警显然也不可取。所以，AlertManager 还支持通过分组、抑制或者静默等多种方式来聚合同类告警，并减少告警数量。
最后一个是可视化展示模块。Prometheus 的 web UI 提供了简单的可视化界面，用于执行 PromQL 查询语句，但结果的展示比较单调。不过，一旦配合 Grafana，就可以构建非常强大的图形界面了。
Prometheus的统计图
应用监控综合思路
对系统资源的监控，USE 法简单有效，却不代表其适合应用程序的监控。比如即使在 CPU 使用率很低的时候，也不能说明应用程序就没有性能瓶颈。因为应用程序可能会因为锁或者 RPC 调用等，导致响应缓慢。
所以，应用程序的核心指标，不再是资源的使用情况，而是
请求数、错误率和响应时间
这些指标不仅直接关系到用户的使用体验，还反映应用整体的可用性和可靠性。
- 是应用进程的资源使用情况，比如进程占用的 CPU、内存、磁盘 I/O、网络等。使用过多的系统资源，导致应用程序响应缓慢或者错误数升高，是一个最常见的性能问题。
- 是应用程序之间调用情况，比如调用频率、错误数、延时等。由于应用程序并不是孤立的，如果其依赖的其他应用出现了性能问题，应用自身性能也会受到影响。
- 是应用程序内部核心逻辑的运行情况，比如关键环节的耗时以及执行过程中的错误等。由于这是应用程序内部的状态，从外部通常无法直接获取到详细的性能数据。所以，应用程序在设计和开发时，就应该把这些指标提供出来，以便监控系统可以了解其内部运行状态。
有了应用进程的资源使用指标
- 可以把系统资源的瓶颈跟应用程序关联起来，从而迅速定位因系统资源不足而导致的性能问题
- 有了应用程序之间的调用指标，可以迅速分析出一个请求处理的调用链中，到底哪个组件才是导致性能问题的罪魁祸首；
- 有了应用程序内部核心逻辑的运行性能，可以更进一步，直接进入应用程序的内部，定位到底是哪个处理环节的函数导致了性能问题。
基于这些思路，将这些指标纳入监控系统（比如 Prometheus + Grafana）中，就可以跟系统监控一样，一方面通过告警系统，把问题及时汇报给相关团队处理；另一方面，通过直观的图形界面，动态展示应用程序的整体性能。
除此之外，由于业务系统通常会涉及到一连串的多个服务，形成一个复杂的分布式调用链。为了迅速定位这类跨应用的性能瓶颈，你还可以使用 Zipkin、Jaeger、Pinpoint 等各类开源工具，来构建全链路跟踪系统。
比如，下图就是一个 Jaeger 调用链跟踪的示例。
全链路跟踪可以迅速定位出，在一个请求处理过程中，哪个环节才是问题根源。比如，从上图中，可以很容易看到，这是 Redis 超时导致的问题。
还可以生成线上系统的调用拓扑图。这些直观的拓扑图，在分析复杂系统（比如微服务）时尤其有效。
日志监控
性能指标的监控，可以让你迅速定位发生瓶颈的位置，不过只有指标的话往往还不够。比如，同样的一个接口，当请求传入的参数不同时，就可能会导致完全不同的性能问题。所以，除了指标外，我们还需要对这些指标的上下文信息进行监控，而日志正是这些上下文的最佳来源。
- 指标是特定时间段的数值型测量数据，通常以时间序列的方式处理，适合于实时监控。
- 而日志则完全不同，日志都是某个时间点的字符串消息，通常需要对搜索引擎进行索引后，才能进行查询和汇总分析。
- 对日志监控来说，最经典的方法，就是使用 ELK 技术栈，即使用 Elasticsearch、Logstash 和 Kibana 这三个组件的组合。
这其中
- Logstash 负责对从各个日志源采集日志，然后进行预处理，最后再把初步处理过的日志，发送给 Elasticsearch 进行索引。
- Elasticsearch 负责对日志进行索引，并提供了一个完整的全文搜索引擎，这样就可以方便你从日志中检索需要的数据。
- Kibana 则负责对日志进行可视化分析，包括日志搜索、处理以及绚丽的仪表板展示等。
下面这张图，就是一个 Kibana 仪表板的示例，它直观展示了 Apache 的访问概况。
值得注意的是，ELK 技术栈中的 Logstash 资源消耗比较大。所以，在资源紧张的环境中，我们往往使用资源消耗更低的 Fluentd，来替代 Logstash（也就是所谓的 EFK 技术栈）。