USE法把系统资源的性能指标,简化成了三个类别,即使用率、饱和度以及错误数。
下面这张,就是一个Kibana仪表板的示例,它直观展示了Apache的访问概况。
最后总结
Push模式,则是由各个采集目标主动向PushGateway推送指标,再由服务器端从Gateway中拉取过去。
第二个,是应用程序之间调用情况,比如调用频率、错误数、延时等。由于应用程序并不是孤立的,如果其依赖的其他应用出现了性能问题,应用自身性能也会受到影响。
性能指标
全链路监控
Pull模式,由服务器端的采集模块来触发采集。只要采集目标提供了HTTP接口,就可以自由接入。
在开始监控系统之前,你肯定最想知道,怎么才能用简洁的方法,来描述系统资源的使用情况。你当然可以使用专栏中学到的各种性能工具,来分别收集各种资源的使用情况。不过不要忘记,每种资源的性能指标可都有很多,使用过多指标本身耗时耗力不说,也不容易为你建立起系统整体的运行状况。
这三个类别的指标,涵盖了系统资源的常见性能瓶颈,所以常被用来快速定位系统资源的性能瓶颈。这样,无论是对CPU、内存、磁盘和文件系统、网络等硬件资源,还是对文件描述符数、连接数、连接跟踪数等软件资源,USE方法都可以帮你快速定位出,是哪一种系统资源出现了性能瓶颈。
对于每一种系统资源,又有哪些常见的性能指标呢?回忆一下我们讲过的各种系统资源原理,并不难想到相关的性能指标。这里,我把常见的性能指标画了一张表格,方便你在需要时查看。
一个好的监控系统,不仅可以实时暴露系统的各种问题,更可以根据这些监控到的状态,自动分析和定位大致的瓶颈来源,从而更精确地把问题汇报给相关团队处理。要做好监控,最核心的就是全面的、可量化的指标,这包括系统和应用两个方面。
第一个,是应用进程的资源使用情况,比如进程占用的CPU、内存、磁盘I/O、网络等。使用过多的系统资源,导致应用程序响应缓慢或者错误数升高,是一个最常见的性能问题。
对比来看,指标是特定时间段的数值型测量数据,通常以时间序列的方式处理,适合于实时监控。
值得注意的是,ELK技术栈中的Logstash资源消耗比较大。在资源紧张的环境中,我们往往使用资源消耗更低的Fluentd,来替代Logstash。
第四个是告警模块。右上角的AlertManager提供了告警的功能,包括基于PromQL语言的触发条件、告警规则的配置管理以及告警的发送等。虽然告警是必要的,但过于频繁的告警显然也不可取。AlertManager还支持通过分组、抑制或者静默等多种方式来聚合同类告警,并减少告警数量。
全链路跟踪除了可以帮你快速定位跨应用的性能问题外,还可以帮你生成线上系统的调用拓扑。这些直观的拓扑,在分析复杂系统时尤其有效。
掌握USE方法以及需要监控的性能指标后,接下来要做的,就是建立监控系统,把这些指标保存下来;然后,根据这些监控到的状态,自动分析和定位大致的瓶颈来源;再通过告警系统,把问题及时汇报给相关团队处理。
最后总结
第三个,是应用程序内部核心逻辑的运行情况,比如关键环节的耗时以及执行过程中的错误等。由于这是应用程序内部的状态,从外部通常无法直接获取到详细的性能数据。应用程序在设计和开发时,就应该把这些指标提供出来,以便监控系统可以了解其内部运行状态。
系统监控
跟系统监控一样,在构建应用程序的监控系统之前,首先也需要确定,到底需要监控哪些指标。特别是要清楚,有哪些指标可以用来快速确认应用程序的性能问题。
对日志监控来说,最经典的方法,就是使用ELK技术栈,即使用Elasticsearch、Logstash和Kibana这三个组件的组合。
应用程序的核心指标,不再是资源的使用情况,而是请求数、错误率和响应时间。
应用监控
全链路跟踪可以帮你迅速定位出,在一个请求处理过程中,哪个环节才是问题根源。比如,从上中,你就可以很容易看到,这是Redis超时导致的问题。
USE法把系统资源的性能指标,简化为了三个类别:使用率、饱和度以及错误数。当这三者之中任一类别的指标过高时,都代表相对应的系统资源可能存在性能瓶颈。
起始
基于这些思路,我相信你就可以构建出,描述应用程序运行状态的性能指标。再将这些指标纳入我们上一期提到的监控系统中,就可以跟系统监控一样,一方面通过告警系统,把问题及时汇报给相关团队处理;另一方面,通过直观的形界面,动态展示应用程序的整体性能。
Elasticsearch负责对日志进行索引,并提供了一个完整的全文搜索引擎,这样就可以方便你从日志中检索需要的数据。
业务系统通常会涉及到一连串的多个服务,形成一个复杂的分布式调用链。为了迅速定位这类跨应用的性能瓶颈,你还可以使用Zipkin、Jaeger、Pinpoint等各类开源工具,来构建全链路跟踪系统。比如,下就是一个Jaeger调用链跟踪的示例。
Logstash负责对从各个日志源采集日志,然后进行预处理,最后再把初步处理过的日志,发送给Elasticsearch进行索引。
可以看出,一个完整的监控系统通常由数据采集、数据存储、数据查询和处理、告警以及可视化展示等多个模块组成。要从头搭建一个监控系统,其实也是一个很大的系统工程。
性能指标的监控,可以让你迅速定位发生瓶颈的位置,不过只有指标的话往往还不够。比如,同样的一个接口,当请求传入的参数不就可能会导致完全不同的性能问题。除了指标外,我们还需要对这些指标的上下文信息进行监控,而日志正是这些上下文的最佳来源。
系统监控的核心是资源的使用情况,这既包括CPU、内存、磁盘、文件系统、网络等硬件资源,也包括文件描述符数、连接数、连接跟踪数等软件资源。而要描述这些资源瓶颈,最简单有效的方法就是USE法。
幸运的是,现在已经有很多开源的监控工具可以直接使用,比如最常见的Zabbix、Nagios、Prometheus等等。
应用程序的监控,可以分为指标监控和日志监控两大部分:
而有了应用程序内部核心逻辑的运行性能,你就可以更进一步,直接进入应用程序的内部,定位到底是哪个处理环节的函数导致了性能问题。
从系统来说,监控系统要涵盖系统的整体资源使用情况,比如我们前面讲过的CPU、内存、磁盘和文件系统、网络等各种系统资源。
监控系统
有了应用程序之间的调用指标,你可以迅速分析出一个请求处理的调用链中,到底哪个组件才是导致性能问题的罪魁祸首;
第三个是数据查询和处理模块。刚才提到的TSDB,在存储数据的其实还提供了数据查询和基本的数据处理功能,而这也就是PromQL语言。PromQL提供了简洁的查询、过滤功能,并且支持基本的数据处理方法,是告警系统和可视化展示的基础。
指标监控主要是对一定时间段内性能指标进行测量,然后再通过时间序列的方式,进行处理、存储和告警。
日志监控
Kibana则负责对日志进行可视化分析,包括日志搜索、处理以及绚丽的仪表板展示等。
基于USE法建立性能指标后,我们还需要通过一套完整的监控系统,把这些指标从采集、存储、查询、处理,再到告警和可视化展示等贯穿起来。这样,不仅可以将系统资源的瓶颈快速暴露出来,还可以借助监控的历史数据,来追踪定位性能问题的根源。
有了应用进程的资源使用指标,你就可以把系统资源的瓶颈跟应用程序关联起来,从而迅速定位因系统资源不足而导致的性能问题;
第二个是数据存储模块。为了保持监控数据的持久化,中的TSDB模块,负责将采集到的数据持久化到SSD等磁盘设备中。TSDB是专门为时间序列数据设计的一种数据库,特点是以时间为索引、数据量大并且以追加的方式写入。
先看数据采集模块。最左边的Prometheustargets就是数据采集的对象,而Retrieval则负责采集这些数据。从中你也可以看到,Prometheus同时支持Push和Pull两种数据采集模式。
如下所示,就是一个经典的ELK架构:
USE法
而日志则完全不同,日志都是某个时间点的字符串消息,通常需要对搜索引擎进行索引后,才能进行查询和汇总分析。
应用监控指标
在跨多个不同应用的复杂业务场景中,你还可以构建全链路跟踪系统。这样可以动态跟踪调用链中各个组件的性能,生成整个流程的调用拓扑,从而加快定位复杂应用的性能问题。
使用率,表示资源用于服务的时间或容量百分比。100%的使用率,表示容量已经用尽或者全部时间都用于服务。饱和度,表示资源的繁忙程度,通常与等待队列的长度相关。100%的饱和度,表示资源无法接受更多的请求。错误数表示发生错误的事件个数。错误数越多,表明系统的问题越严重。
而从应用程序来说,监控系统要涵盖应用程序内部的运行状态,这既包括进程的CPU、磁盘I/O等整体运行状况,更需要包括诸如接口调用耗时、执行过程中的错误、内部对象的内存使用等应用程序内部的运行状况。
文章为作者独立观点,不代表股票交易接口观点