作者 | 刘浩杨
起源|尔达 Erda 公众号
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 三大支柱：
- Logging，展示的是利用运行而产生的事件或者程序在执行的过程两头产生的一些日志，能够具体解释零碎的运行状态，然而存储和查问须要耗费大量的资源。所以往往应用过滤器缩小数据量。
- Metrics，是一种聚合数值，存储空间很小，能够察看零碎的状态和趋势，但对于问题定位不足细节展现。这个时候应用等高线指标等多维数据结构来加强对于细节的表现力。例如统计一个服务的 TBS 的正确率、成功率、流量等，这是常见的针对单个指标或者某一个数据库的。
- Tracing，面向的是申请，能够轻松剖析出申请中异样点，但与 logging 有雷同的问题就是资源耗费较大。通常也须要通过采样的形式缩小数据量。比方一次申请的范畴，也就是从浏览器或者手机端发动的任何一次调用，一个流程化的货色，咱们须要轨迹去追踪。
Erda 微服务观测平台
在上文中咱们提到，可察看性提供了一套理念来监控、诊断云原生利用零碎。因而，CNCF 发动了 OpenTelemetry 我的项目，心愿借此对立可察看性三种数据的标准规范和对立的采集实现。但在事实世界中，咱们更关怀的是采集的数据如何被存储和应用。由此，Erda MSP（MicroService Platform）中的利用监控子系统也在逐步演进为以“可察看性剖析诊断_”_为外围的微服务观测平台。
- 观测：察看服务本身的运行状态和监控指标。
- 剖析：对察看数据进行关联、统计、加工等。
- 诊断：基于察看数据的剖析后果，形容出零碎异样的间接起因。
Erda MSP 以后笼罩从基础设施、业务零碎、到端利用的数百种指标和状态采集：
内置观测视图
咱们也依据监控运维常见的场景和指标，在 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/
参考资料
- 《察看之道：带你走进可察看性》
- 《万字破解云原生可观测性》