云原生时代的 APM

APM 的全称是 Application Performance Management（应用性能管理），早在 90 年代中期就有厂商提出性能管理的概念，到现在 APM 领域已经发展了近 25 年。

通常而言，APM 的技术已经发展了 3 个阶段，在这里我们可以通过前蓝海讯通（OneAPM）创始人何晓阳在 2014 年分享的《APM 应用性能管理的过去二十年》来回顾一下 APM 的发展历史。

1995 年到 2000 年，正是第一代互联网浪潮兴起的年代。当时，雅虎作为互联网公司的代表，引领一代潮流，美国人忙着铺光纤架网线，一个一个的站点被建立了起来。如果说网站的响应速度决定了用户体验的话，那么当时的网速就决定了网站的响应速度，因此，APM 1.0 时代的软件功能就是这么简单：管理网络系统的性能。

时间发展到 2000 年，看过《浪潮之巅》这本书的读者应该会对那个时代有一些印象，当时的 SUN 正处于巅峰时期，市值接近 2000 亿美元，这些公司当时正在疯狂的建设数据中心，购买各种各样的硬件和软件。在这里，我们用一个专业名词来称呼他们，叫做基础组件（Infrastructure）。那么，当时的 APM 系统已经到了第二代，作用是监控和管理各种基础组件的性能。

2005 年以后，随着 Facebook，Twitter 这些应用提供商的兴起，越来越多的 APP 被用来服务全球客户；对于用户来说，他们访问的应用服务可能分布式的部署在全球的多个数据中心上，尤其是 2010 年以后，新的移动访问方式的兴起，让每一个人的生活方式更加紧密的依赖于各种 Application。在这个时候，应用本身的性能越来越成为制约用户体验提升的瓶颈。这就是第三代 APM 软件的用武之地：第一是管理真实用户的体验，第二是进行端到端的业务交易性能分析。

可以看到，在过去很长一段时间，APM 的重心一直在关注用户体验性能和应用程序性能，随着近年来云计算的兴起，和云原生所倡导的新范式，给传统的研发和运维模式带来了新的挑战：微服务、DevOps 等理念让研发变得更高效，但带来的却是海量微服务的问题排查、故障定位的难度变得更大；容器化、Kubernetes 等容器编排技术的逐渐成熟让规模化软件交付变得容易，但带来的挑战是如何更精准地评估容量、调度资源，确保成本与稳定性的最好平衡。

监控到可观察性

Apple 的工程师 Cindy Sridharan 的博文“监控与观察”（Monitoring and Oberservability）首次将 Oberservability 一词带入开发者的视野。然而，在谷歌，其著名的 SRE 体系在此之前就已经奠定了可观察性的理论基础，也就是说在微服务、可观测性等概念或者出现以前，前辈们将这套理论称为监控，其中 Google SRE 特别强调白盒监控的重要性，而将当时技术圈常用的黑盒监控放在了相对次要的位置。而白盒监控正是应和了可观察性中“主动”的概念。

这里引用一下 Baron SchSchwarz 大咖的一个定义：“监控告诉我们系统的哪些部分是不工作的。可观察性告诉我们那里为什么不工作了。”

由此可见，可观察性是云原生系统中提供稳定性和性能监控、诊断分析的一套理念。和监控相比，可观察性从单一的度量扩展为 Metrics、Tracing、Logging 三大支柱：

![03.png](https://img-blog.csdnimg.cn/img_convert/447ceedce3e91a6579c837b0155c2264.png#height=284&id=ZnTiP&margin=[object Object]&name=03.png&originHeight=400&originWidth=676&originalType=binary&ratio=1&size=87606&status=done&style=none&width=480)

Logging，展现的是应用运行而产生的事件或者程序在执行的过程中间产生的一些日志，可以详细解释系统的运行状态，但是存储和查询需要消耗大量的资源。所以往往使用过滤器减少数据量。
Metrics，是一种聚合数值，存储空间很小，可以观察系统的状态和趋势，但对于问题定位缺乏细节展示。这个时候使用等高线指标等多维数据结构来增强对于细节的表现力。例如统计一个服务的 TBS 的正确率、成功率、流量等，这是常见的针对单个指标或者某一个数据库的。
Tracing，面向的是请求，可以轻松分析出请求中异常点，但与 logging 有相同的问题就是资源消耗较大。通常也需要通过采样的方式减少数据量。比如一次请求的范围，也就是从浏览器或者手机端发起的任何一次调用，一个流程化的东西，我们需要轨迹去追踪。

Erda 微服务观测平台

在上文中我们提到，可观察性提供了一套理念来监控、诊断云原生应用系统。因此，CNCF 发起了 OpenTelemetry 项目，希望借此统一可观察性三种数据的标准规范和统一的采集实现。但在现实世界中，我们更关心的是采集的数据如何被存储和使用。由此，Erda MSP（MicroService Platform）中的应用监控子系统也在逐渐演进为以“可观察性分析诊断_”_为核心的微服务观测平台。

![可观测性分析平台.jpg](https://img-blog.csdnimg.cn/img_convert/b97667afd520ed5757557b118da91f18.png#height=418&id=zzJDf&margin=[object Object]&name=可观测性分析平台.jpg&originHeight=795&originWidth=912&originalType=binary&ratio=1&size=51638&status=done&style=none&width=480)

观测：观察服务自身的运行状态和监控指标。
分析：对观察数据进行关联、统计、加工等。
诊断：基于观察数据的分析结果，描述出系统异常的直接原因。

Erda MSP 当前覆盖从基础设施、业务系统、到端应用的数百种指标和状态采集：

![image.png](https://img-blog.csdnimg.cn/img_convert/9af157759a461cbaca9ca74c65eaecf2.png#height=423&id=QVNj7&margin=[object Object]&name=image.png&originHeight=846&originWidth=1784&originalType=binary&ratio=1&size=580655&status=done&style=none&width=892)

内置观测视图

我们也根据监控运维常见的场景和指标，在 Erda 中提供了默认的观测视图：

多云集群状态和资源使用率观测

集群节点指标观测

服务请求和延迟观测

慢/错误事务分析

针对于业务系统的慢请求和错误请求，我们集成了 log、trace 和 metric 的关联，让用户可以在很容易的定位到请求的异常上下文信息：

错误请求检索

错误请求和慢请求 Top

慢请求和错误请求下钻分析

exception 分析

exception 下钻关联到 trace 和 log

自定义分析

Erda MSP 支持使用自定义 Dashboard 定制用户自己的分析场景，Dashboard 详细使用参考：《上手后才知道，这套仪表盘系统用起来是真的爽！》。

日志分析

对日志数据的处理，Erda 支持全文检索和结构化标签检索两种方式，并且实现一键关联日志和调用链路的分析能力。

日志关联链路追踪分析

写在最后

Erda 作为开源的一站式云原生 PaaS 平台，具备 DevOps、微服务观测治理、多云管理以及快数据治理等平台级能力。点击下方链接即可参与开源，和众多开发者一起探讨、交流，共建开源社区。欢迎大家关注、贡献代码和 Star！

Erda Github 地址：https://github.com/erda-project/erda
Erda Cloud 官网：https://www.erda.cloud/

参考资料