全方位解析应用性能监控：衡量标准、监控方法、问题与展望

引言

可观测性的本质是度量基础设施、平台和应用程序，以了解它是如何运行的。与传统监控运维相比，目前主流的监控更加注重发现与预警问题，而可观测性的终极目标是为一个复杂分布式系统所发生的一切给出合理解释。监控更注重软件的交付过程中以及交付后的服务状态，而可观测性则要为全研发与运维的生命周期负责。

日志、基础架构指标以及APM应用程序性能监测构成了可观测性的三要素。其中，APM弥补了指标和日志之间的差距。虽然日志和指标往往更具交叉性，涉及基础架构和组件，但APM更侧重于应用程序，允许IT和开发人员监测其堆栈的应用层，包括最终的用户体验。

应用性能监控

什么是应用性能管理

APM (Application Performance Management) 监控是一种管理软件应用程序性能的技术，可以帮助识别并解决应用程序中的性能问题。APM 监控的目的是提高应用程序的可用性，提高用户体验，并减少因性能问题导致的故障时间。

APM 监控通常通过代码级别、应用程序级别和服务器级别进行监控，以收集关于应用程序性能的数据和信息。这些数据可以帮助诊断问题，例如：

• 哪些部分的代码导致了应用程序延迟；
• 哪些网络请求或数据库查询导致了应用程序的性能下降；
• 哪些服务器或资源是性能瓶颈；

使用 APM 监控工具也可以在运行时监测应用程序的健康状况，并在检测到故障时发出警报。这样，就可以尽早识别问题并解决它们，从而避免长期的性能问题对业务造成影响。

应用性能管理的重要性

应用程序性能监控是保证应用程序性能的关键因素。APM 监控可以帮助开发人员和运维人员了解应用程序的性能，以便对其进行优化。

• 缩短故障恢复时间：我们可以通过对应用性能指标的实时监控，当发现性能问题时可以及时发现并修复故障，这有助于缩短故障恢复时间，提高应用程序的可用性。
• 提高应用性能：我们可以通过收集到得应用性能数据进行分析来诊断性能问题，这有助于改进应用程序的性能，让我们了解哪些部分需要优化。
• 提高用户满意度：我们可以通过对应用性能进行优化，来提升应用的流畅度，从而提高用户的满意度。
• 节省开发资源：我们可以通过对应用进行监控来发现和修复性能问题，从而减少开发人员的调试和修复时间。这有助于节省开发资源，并让开发人员可以更专注于新功能的开发。

应用健康的衡量标准

四个黄金指标

Four Golden Signals是Google针对大量分布式监控的经验总结，4个黄金指标可以在服务级别帮助衡量终端用户体验、服务中断、业务影响等层面的问题。主要关注与以下四种类型的指标：延迟，通讯量，错误以及饱和度：

• 延迟：服务请求所需时间。

记录用户所有请求所需的时间，重点是要区分成功请求的延迟时间和失败请求的延迟时间。 例如在数据库或者其他关键祸端服务异常触发HTTP 500的情况下，用户也可能会很快得到请求失败的响应内容，如果不加区分计算这些请求的延迟，可能导致计算结果与实际结果产生巨大的差异。除此以外，在微服务中通常提倡“快速失败”，开发人员需要特别注意这些延迟较大的错误，因为这些缓慢的错误会明显影响系统的性能，因此追踪这些错误的延迟也是非常重要的。

• 通讯量：监控当前系统的流量，用于衡量服务的容量需求。

流量对于不同类型的系统而言可能代表不同的含义。例如，在HTTP REST API中, 流量通常是每秒HTTP请求数；

• 错误：监控当前系统所有发生的错误请求，衡量当前系统错误发生的速率。

对于失败而言有些是显式的(比如, HTTP 500错误)，而有些是隐式(比如，HTTP响应200，但实际业务流程依然是失败的)。

对于一些显式的错误如HTTP 500可以通过在负载均衡器(如Nginx)上进行捕获，而对于一些系统内部的异常，则可能需要直接从服务中添加钩子统计并进行获取。

• 饱和度：衡量当前服务的饱和度。

主要强调最能影响服务状态的受限制的资源。 例如，如果系统主要受内存影响，那就主要关注系统的内存状态，如果系统主要受限与磁盘I/O，那就主要观测磁盘I/O的状态。因为通常情况下，当这些资源达到饱和后，服务的性能会明显下降。同时还可以利用饱和度对系统做出预测，比如，“磁盘是否可能在4个小时候就满了”。

RED 方法论

RED (Request rate, Error rate, and Duration) 方法论是一种监控微服务性能的方法，特别适合于云原生应用以及微服务架构应用的监控和度量，主要通过监控三个关键指标来评估系统性能：

• 请求速率 (Request rate)：请求速率是指在给定时间内，系统所处理的请求数量。高请求速率可能表示系统面临着巨大的压力，因此需要进一步评估是否需要扩展系统的资源。
• 错误率 (Error rate)：错误率指的是在给定时间内系统请求失败的比率。高错误率可能表示系统出现了问题，因此需要进一步评估系统是否存在故障。
• 请求持续时间 (Duration)：请求持续时间是指请求的处理时间。高请求持续时间可能表示系统处理请求的速度较慢，因此需要进一步评估系统是否需要提高处理效率。

在“4大黄金信号”的原则下，RED方法可以有效的帮助用户衡量云原生以及微服务应用下的用户体验问题。

USE 方法

USE (Utilization, Saturation, and Error) 方法论主要用于分析系统性能问题，可以指导用户快速识别资源瓶颈以及错误的方法。正如USE方法的名字所表示的含义，USE方法通过监控三个关键指标来确定系统的性能状况：

• 利用率 (Utilization)：利用率指的是系统的资源利用情况，是衡量系统性能的一个重要指标。利用率过高可能导致系统资源紧张，从而导致系统的性能下降。
• 饱和度 (Saturation)：饱和度指的是系统在特定时间内的资源使用情况，如果系统饱和，即使系统利用率很低，性能也可能下降。
• 错误率 (Error)：错误率是指系统中请求失败的数量。错误率是反映系统是否可靠的一个重要指标，高错误率可能表明系统存在问题，因此需要进行更深入的评估。

使用 USE 方法论，可以监控系统资源的使用情况，以确保系统在正常运行。通过对资源以上指标持续观察，通过以下流程可以知道用户识别资源瓶颈：

通常，使用监控工具，如Prometheus、Datadog、Guance等来实现 USE 方法论的监控。

应用性能监控方法

应用性能监控的常用工具包括：New Relic、AppDynamics、DataDog、Dynatrace、Guance 等。使用这种监控方法的流程通常包括以下步骤：

1. 安装 APM 库或框架：在应用程序的代码中安装适当的 APM 库或框架，以开始监控。
2. 配置 APM 库：配置 APM 库，以收集和监控需要监控的数据。
3. 插入代码：在代码中插入特定的代码段，以监控代码的执行情况。
4. 部署应用程序：部署应用程序，以开始监控。
5. 查看数据：查看监控到的数据，以诊断问题和提高应用程序的性能。

从服务级监控应用性能

从服务级来监控应用性能我们主要关注的是服务器硬件和操作系统的性能。服务器级应用性能监控的目的是识别和解决服务器资源的使用情况。

主要监控的指标包括：

• CPU 使用率：监控 CPU 的使用情况，包括核心数量、核心利用率等。
• 内存使用情况：监控内存的使用情况，包括可用内存、已用内存、缓存、交换区等。
• 网络带宽：监控网络带宽的使用情况，包括入带宽、出带宽、总带宽等。
• 磁盘使用情况：监控磁盘的使用情况，包括可用空间、已用空间、磁盘读写速度等。
• 进程监控：监控系统中运行的进程，包括进程数量、进程内存使用情况等。

通过服务器级 APM 监控，开发人员可以识别和解决服务器资源的使用情况，从而提高系统的性能。

从应用级监控应用性能

应用级应用性能监控与代码级应用性能监控相比，更加关注于整体应用程序的性能，这是该监控方法的一个优点。例如，它可以诊断哪些操作影响了应用程序的性能，这对于开发人员来说是非常有用的信息。因此应用级应用性能监控是一种在应用程序级别监控性能的方法。这种监控通过收集和分析来自应用程序的数据来评估应用程序的性能。应用级应用性能监控常常是使用代码级应用性能监控的一个补充，它更注重于监控整个应用程序的性能，而不是仅仅监控代码的性能，因此应用级 APM 监控还可以涵盖以下内容：

• 内存使用情况：监控应用程序的内存使用情况，包括内存泄漏和内存溢出等。
• 网络请求监控：监控应用程序与后端服务的网络请求，包括请求的大小、响应时间、网络错误等。
• 数据库性能监控：监控数据库的性能，包括数据库的连接数、查询时间、缓存命中率等。
• 异常处理：监控应用程序的异常处理，包括未处理的异常、异常堆栈等。

通过这些监控，开发人员可以更快地定位问题，并进行解决。此外，应用级 APM 监控还可以通过对资源使用情况的监控，帮助开发人员评估应用系统的瓶颈，并进行优化。

从代码级监控应用性能

代码级应用性能监控是最细粒度的应用性能监控方法，通常需要在应用程序的代码中插入特定的代码段，以监控应用程序的性能指标。代码级应用性能监控是通过使用应用性能库或框架来实现的，这些库或框架可以监控代码执行的性能指标，例如方法的执行时间、数据库调用次数、HTTP 请求数量等。代码级应用性能监控的优点：

• 提供详细的信息：代码级应用性能监控提供了对代码执行过程中的详细信息，从而更好地了解代码中的问题。
• 快速诊断：通过监控代码的执行情况，可以快速诊断问题所在的位置。
• 减少错误：代码级应用性能监控可以帮助提前发现代码中的错误，从而减少应用程序在生产环境中的故障。

应用性能监控的问题与挑战

应用性能监控的问题

随着互联网技术的发展，软件系统的复杂度也在不断增加，软件系统结构更加复杂，需要处理的数据量更大。同时，用户对于软件系统的性能和可用性的要求也越来越高。应用性能监控主要通过收集应用程序的性能指标，分析数据，诊断问题，以及在发生故障时及时采取措施来保证软件系统的性能和可用性。

当企业内部应用过于复杂时，当多个服务和资源相互依赖时，如果其中一个服务出现故障，很难确定是哪个服务导致了故障。

比如这样一条的链路情况，我们在配置链路告警的时候会遇到一些问题：

• 选择基于资源粒度（resource）来进行告警，在发生告警时我们怎么确定该问题 resource 是不是真正的根因而不是被动的出现问题，比如当  kodo-inner 这个服务出现问题时  urlib3 、 py-inner  都会出现问题那么  urlib3 、 py-inner  所告警的异常真的时根因异常吗，而不是告警风暴带来的干扰项。
• 选择基于服务粒度（service）来进行告警，当服务的四大黄金指标出现问题时进行告警，那么我们是否应该考虑当前环境中我们的应用都是十分复杂的，我们很难针对于同一应用不同的服务做出一样阈值的告警，那么针对于业务的变动以及不同的服务我们该如何做出有针对的告警来快速定位问题呢。
• 当我们针对于某个服务或者资源做了定向的告警配置后，当发现问题时我们可能无法确定在问题时刻是具体那条 trace 引发的异常，还是需要我们经验丰富的运维工程师来根据告警时刻的阈值以及对应的链路调用关系以及应用所处服务器状态等信息来逐一的排查问题。

当然在我们想对这个问题采取解决办法时也会遇到棘手的问题，比如我们一起来看一条链路数据：

{
    __namespace:tracing,
    create_time:2023/02/12 21:30:03,
    date_ns:435123,
    duration:328,
    host:cn-zhangjiakou.192.168.62.119,
    host_ip:192.168.62.119,
    http_method:POST,
    http_url:http://kodo-inner.forethought-kodo:9527http://kodo-inner.forethought-kodo:9527/v1/query,
    operation:http.client.request,
    parent_id:11822516092705076395,
    project:dataflux,
    resource:http.client.request,
    service:urllib3,
    source:ddtrace,
    source_type:web,
    span_id:397734753770788277,
    span_type:exit,
    start:2023/02/12 21:30:01.175,
    status:ok,
    time:2023/02/12 21:30:01,
    trace_id:16686794005857536471,
    message:{
    service:urllib3,
    name:http.client.request,
    resource:http.client.request,
    trace_id:16686794005857536471,
    span_id:397734753770788277,
    parent_id:11822516092705076395,
    start:2023/02/12 21:30:01.175,
    duration:328198,
    error:0,
    meta:{
    http.method:POST,
    http.url:http://kodo-inner.forethought-kodo:9527http://kodo-inner.forethought-kodo:9527/v1/query,
    project:dataflux
    },
    metrics:null,
    type:http
    }
}

针对于这样的数据我们想解决上面所遇到的问题那么我们又面临着几个新的问题：

1. 如何针对于这样的链路数据进行预处理获取我们需要的信息
2. 如何做到针对于不同的服务不同资源做到无阈值告警
3. 如何获取链路中 end resource 从而定位最终问题
4. 如何针对于异常的链路数据关联到需要参考的主机数据、日志数据以及可能的中间件数据

那么针对于以上的问题我们该采用怎么样的思路来解决问题最终达成我们针对于应用可以做到无阈值告警呢？

如何对应用性能做到无阈值预警

收集应用的统计信息

首先第一步我们要计算出我们应用不同服务和资源的请求数量、请求耗时、失败数量来为我们针对不同服务不同资源需要做的无阈值告警做准备：

• 请求数量： 在该链路数据中，每条记录都代表一次请求，所以通过统计该链路数据中的记录数量，可以得出该应用和资源的请求数量。
• 请求耗时： 请求耗时可以通过 "start" 和 "duration" 字段来计算，其中 "start" 表示请求开始时间， "duration" 表示请求持续的时间。
• 失败数量： 在该链路数据中， "status" 字段表示请求的状态，如果 "status" 的值为 "ok"，则说明请求成功；如果 "status" 的值不为 "ok"，则说明请求失败。通过统计该链路数据中 "status" 字段不为 "ok" 的记录数量，可以得出失败数量。

针对应用状态做出诊断

我们可以根据处理好的统计信息来分场景对应用的状态做出诊断：

• 当服务出现错误时：当我们发现应用的某个服务出现错误时，我们可以通过对该服务的资源进行检索来寻找发生错误的具体资源，在查找到对应的资源后我们还需要锁定最终有问题的根因来避免告警风暴的发生
• 当服务 P99 响应时间过高时：当我们发现应用某个服务的 P99 响应时间过高时，我们可以通过对该服务的资源进行检索来寻找发生 P99 响应时间过高资源是那个，然后我们可以根据该资源的 Trace 情况来排查每条 span 的执行时间从而定位最终的问题
• 当服务请求数出现波动时：当我们通过时序算法发现应用某个服务的请求数严重偏离预期时，我们可以通过对该服务的资源进行检索来寻找请求数严重偏离预期时资源是那个给出预警。

针对链路信息做出根因分析

下图是展示自动分析给定问题的所有垂直和水平拓扑依赖关系。在示例中，当应用程序服务的观测指标出现异常时，该服务的底层水平堆栈未显示任何异常事件。我们可以通过对收集好的链路数据、主机数据、中间件数据、日志数据等分析该服务的上下游信息来为该应用来确定根因异常。如 APP service 出现异常但是在该服务的底层信息没有发现异常，但是检测到其对service 1 的依赖，且service 1 也表现出异常行为，但是service 1 的底层也没有发现异常，同理发现服务 1 对service 3 的依赖，检测到 Service 3 的所有依赖项都表现出异常行为，并且是整个问题的根本原因，那么这个时候我们就定位了问题的根因是 service 3 引起的，于此同时我们可以基于关联的主机数据、中间件数据、日志数据等得到更多有意义的线索。

通过有价值的事件报告快速排查问题

我们可以把所收集到的异常服务、异常资源等根因信息，以及对应根因链路的采样信息等制作成事件报告，这样便于我们对异常进行复盘交流，以及跟开发对接快速对应用性能进行调优等。

常用应用性能监控工具介绍

观测云介绍： 观测云，新一代云原生全链路数据可观测平台，国内首批获得中国信通院颁发的「可观测性平台技术能力」先进级认证，实现统一采集、统一标签、统一存储和统一界面，带来全功能的一体化可观测体验。观测云能全环境高基数采集数据，支持多维度信息智能检索分析，及提供强大的自定义可编程能力，使系统运行状态尽在掌控，故障根因无所遁形。

Datadog介绍： Datadog 是用于大规模应用程序的监视和分析平台。 它包括基础结构监视、应用程序性能监视、日志管理和用户体验监视。 Datadog 通过 400 多项集成来聚合整个堆栈中的数据，以便进行故障排除、发出警报和图形处理。 可以将其用作单个源，以便进行故障排除、优化性能和跨团队协作。

应用性能监控展望

应用性能监控是保证软件应用稳定运行的重要手段，在当前的软件开发和运维环境中具有越来越重要的地位。近年来，随着微服务架构、云计算和大数据技术的普及，应用性能监控领域也发生了很大的变革。目前 APM 监控已经从单纯的性能监控转变为包含了数据挖掘、异常检测、故障定位、性能优化等功能的全面应用性能管理解决方案。

对于未来 APM 监控的展望，预应用性能监控是软件开发、部署和运维的重要组成部分。在当今的 IT 环境中，越来越多的公司将应用性能监控作为企业级 IT 系统的核心部分，以提高应用的性能、可靠性和安全性。就未来而言，APM 监控将继续发展，更加全面地覆盖各种应用程序和技术。 APM 监控的目标是实现真正的全方位监控，从而更好地支持业务结果。未来 APM 监控将加强与更多类型的数据源的集成，并利用机器学习、大数据分析等先进技术实现更加智能化的监控。

总的来说，APM 监控是一项非常有价值的技术，它可以提高应用的稳定性和性能，并降低团队的故障处理时间，为业务的高效运营提供强有力的保障。