传统监控厂商正把可观测性引入万劫不复之地

可观测性是当前讨论非常多的话题，这个理念由来已久，却在最近开始流行。

在20世纪60年代，该理念首次由Rudolf E. Kalman在其论文中提出，论文题目是《on a general theory of control system》。作者对可观测性的定义非常简洁:

由系统输出推断系统当前状态。

理解可观测性至关重要，尤其是当前一些传统的监控厂商，在云原生萌芽的阶段，打着可观测性的名号，然而卖的仍然是老掉牙的应用监控。

结果是什么呢？反而有了各种各样的可观测性的定义，众说纷纭，理解存在不一致的情况，这让“可观测性”的水，越来越浑浊。

今天，就让我们针对这些误区，来一一解答。

拨开混沌

如果对可观测性理解不足，或者对可观测性的能力不够了解，则大概率采用的方案也不会完备，其业务可能依旧会暴露在极大的风险之下。当然，采用的方案大概率也昂贵且非常过时，根本达不到效果。所以，当考虑到可观测性时，最佳策略首先是要理解其可观测性的产出。

系统可观测性到底为了什么？仅仅只是为了快速告警？难道不想提高用户体验？甚至不想看到对营收效果的明显收益？

让我们再次重新看一下可观测性的定义，以便做最有效的投资获取最大的价值，而不是简单的告警来了干巴巴掉链子。

基础知识: 可观测性 VS 监控

监控仅仅只是捕捉和展示系统数据，可观测性则截然不同：可观测性立足于分析输入和输出。

举个例子，观察某一个指标是否变化，如果变化则说明系统有可能出了问题，这是监控的做法。然而，通过获取系统数据来了解系统，理解问题根因，这才是可观测性的做法。

为了良好的可观测性，团队就需要全面引入可观测性，这里的全面包含从基础设施、应用、数据库等的每一层。

历经三代：从监控到可观测性

可观测性时代如何到来的？

目前看监控经历了三次蜕变：私有云、云、云原生。

第一代：私有云或者叫做数据中心

在20世纪90年代，IT系统管理基本被四大厂商主导： Hewlett Packard (HP), IBM Tivoli, BMC, and Computer Associates (CA)。

这四大公司也将监控作为IT项目管理的重要组成部分。当时的监控包括在服务器上安装SNMP traps 和探针，用来展示服务器、存储或者网络的红、黄、绿的状态。

早期的应用管理厂商比如后来被CA收购的Wily以及公司BMC占据了单体应用性能监控的市场，这些厂商在虚拟化乃至云计算到来之前，一直支配着市场，也正是如此让这些厂商在新技术面前也非常脆弱。

第二代云时代

apm 厂商为了搅局，号称自家工具是为了云服务而生。

从2000年开始，已经有非常多的企业开始在各大数据中心的各个机房使用虚拟机。

截止到2011年，很多公司开始通过注入亚马逊、微软、谷歌等来部署公有云服务。

这里面的APM厂商就包括New Relic,Dynatrace以及Datadog，他们完全打破了第一代apm厂商管理方式，提供apm工作台保证对数以千计的虚拟机的性能和可用性的可视化。

早期为了监控云上的情况，仅仅需要获取简单的性能和可用性的数据就足够了。这些平台虽然割裂，有一定的消极作用，但也没有影响对应用或基础设施的健康有大的副作用。

然而之后，很多公司不断扩展云的足迹，采用云原生架构，拥抱DevOps理念。越来越多的公司已经发现，APM工具已经无法为快速交付云应用来提供可扩展性、可靠性、数据洞察。APM厂商也开始面临第一代监控工具的处境，也真切的感受到了来自市场的威胁。

第三代：云原生和可观测性萌芽

第三代方案的产生源于对云原生应用和基础设施的量体裁衣，也正是这点对第二代监控工具产生了很大的威胁。

云和云原生架构的区别在于，云原生应用在云上使用容器和微服务架构进行开发和部署，而云应用仅仅是相当于把巨石应用搬到了云上而已，完全没有充分利用云环境带来的优势。大约在2018年开始，很多团队就开始快速转向了云原生。

云原生应用的优势与复杂度

容器化和微服务架构让开发者提速，增加灵活性和扩展性。其特性让大公司的开发者能够每天部署数以百计的软件更新，更快的应对客户需求和市场，让商业策略也更加灵活。

快速和扩展性带来的好处是无疑的，但同样也把人带入了更高复杂性的时代。虽然再也不是数以千计的虚拟机和应用服务，但应用和运维团队必须要应对数以百万计的容器和数以千计的微服务，而且其中有的生命周期仅有几分钟。

此外，在云原生和devops的时代，开发者同样也要对应用的运维负责，再也不是简单的扔给运维上线就完了。

第二代apm工具，正举步维艰的追赶云原生时代对扩展性和能力的要求。

比如，第二代监控工具会从各个独立的应用和基础设施中收集预先定好的数据，用来监控性能或者可用性。

收集哪些数据完全由APM厂商决定，APM厂商完全控制数据的产生，数据格式专一，而且工程师想要看到可视化的数据的方式更是受限于apm工具特定的查询语言和仪表板。

就好比隐秘花园，数据被锁在了厂商的固定格式中，数据的价值完全依靠厂商特定工具使用特定方式才能进行分析，而这些在云原生世界有着非常多的局限性。

传统监控早已无法满足

如果想要达到业务领先的目标，光具备监控已知问题的能力已经远远不够了。云原生架构规模更大、分布式更广、其中又各自独立。开发者需要能自主地去选择、控制和可视化开发者想要收集和分析的数据。

此外，云原生应用产生的数据基数更高，传统APM工具已经无力收集和分析众多的数据。公司更需要能够自己选择和控制收集和分析的数据以保证应用和基础设施按期望运行。

什么是数据基数?

基数指的是一组或一类数据中的元素的数量。举个具体的例子来说：

追踪在高速路口通过的轿车数量，如果只记录数量，就是低基数，因为只有一个维度，但是如果要同时记录车的颜色，这就会让数据增加一个新的维度。比如再增加车上是否有宠物？这就又会增加一个维度。虽然只是加了这几个维度，数据量已经非常巨大。所以，虽然高基数有用，但数据量也会极大地增长。

可观测性：新时代的运营范式

正是因为这些以及种种原因，可观测性正成为市场和工业头部企业的运行新范式。可观测性方案开始接管系统的输出（log、trace、metrics以及事件）。可观测性让团队得以横跨整栈（基础设施、应用和业务）来探测和解决问题。

可观测性同样带来的还有数据的上下文（这点与监控不同），同时允许业务决定收集那些数据。开发者可以收集更个性化、特定的数据，也可以更高效的管理高基数的数据，更好的应对云原生带来的扩展性和复杂度。

据此，在第三代可观测性已经从厂商掌控到了客户指定的形式，将由客户自己决定收集哪些数据。

尽管apm方法能够在出现问题时给公司发出告警，但却只有可观测性方案才能给出详细的上下文，定位根因并协助解决。与监控不同的是，可观测性提供的所有数据都有正确的上下文，能帮助快速定位和解决问题。

可观测性能快速提高工程中指标，比如MTTR和MTTD，不仅如此，还能提供实时洞见，帮助业务关键性指标，比如支付失败率、订单提交或处理、应用的延迟，这些都可能影响用户体验。

总结来说，apm看的是各家厂商的本领，而可观测性则提供的是有竞争力的优势。APM为云而生，可观测性为云原生而生，随着越来越多的人拥抱云原生，可观测性注定会超过apm成为更为主导的方案。

APM厂商跟不上形势、势要搅浑市场的四大原因

尽管广告叫嚣的凶狠，声称具备对云原生的可观测性的能力，然而撕开这层遮羞布，传统apm厂商方案骨子里的不足暴露无遗，这里面有四大原因：

1. 数据体量大

每个容器提供的数据量等同于虚拟机，所以从数以千计的虚拟机过渡到数以千计、百万计的容器，将会导致可观测性数据以量级增长。

2. 生命周期短

不论创建了多少容器，其生命周期都非常短，也就是说容器存活的时间很短，有的可能只有几分钟，这点与虚拟机的生命周期是完全不同的（几个月甚至几年）。在第二代时Devops团队需要重新评估和了解这种非常快速动态环境中数据的价值。APM工具设计简陋，无法给团队带来足够的可视化，更没法完成上面的评估和了解。所以，即便APM厂商声称具备可观测性，但也正是因为缺少足够的灵活性，不能灵活获取、查看、控制不论是短期还是长期的数据，所以其实还是给业务埋了雷。

3. 各自独立

对于单体架构中的应用和虚拟机，应用以及基础设施等之间的关系是非常容易预测的。然而，在云原生时代，微服务和容器大多更复杂且变化更快。数据基数更大，将应用与基础设施联系起来，以及与业务指标联系起来非常困难，第二代的监控工具的设计初衷是监控虚拟机上应用，但应用和基础设施再也不是静态已知的，这让APM工具在容器和微服务架构下已经非常艰难。

4. 特定的数据格式

传统APM厂商使用其专有的探针收集和存储数据，等同于将数据锁在了特定的数据格式中。很多企业越来越想要开源标准，同时也想拥有这些数据，因为这些数据通过在部门间分享，能帮助更好的协作、发现和解决问题，然而这一切，当使用了传统APM厂商后，数据都被雪藏，发现和解决问题无疑也会需要更多的成本。

当心“可观测性化”

传统APM厂商不可能完全重构其方案来适应云原生环境，从技术上来说几乎不可能实现。但是，他们“重构”了市场策略，注意，这里的重构是带引号的。

可能有的人还能记得，为了应对云服务的增长，传统APM厂商曾“重构”他们的方案，通过把当时的老方案重新进行品牌包装成新方案，而且在新方案中加入“云”这个词，然而实际传统APM厂商做的只是欺世盗名，比如把单体应用安装到虚拟机中。

同样，第二代的监控厂商也正在“可观测性化”，他们开始增加对可观测性三大支柱的支持（日志、链路和指标），调整定价策略，提供多种定价包策略，不断将自身“塑造”成云平台可观测性平台。

三大支柱的完备是可观测性的要素，但也只是底层基础设施，无论怎么伪装，在本质上，他们并非真的云可观测方案，如果在云原生环境中使用，数据量无疑会压垮系统。

性能和运维的效率更受制于告警、仪表板，事故报告花费的时间甚至更长（如果能有事故报告的话），而且随着存储和分析的数据规模的增长，公司的成本也会爆炸似的增长。

日志、指标和分布式追踪

从传统厂商的角度看可观测性，基本还是从数据入手，也就是保证三大支柱可用：

• Log: 记录的详细事件的日志（带时间戳）

• Metric:包含信息的任何属性（名称、值、标签、时间戳）

与事件日志（记录事件）不一样的是，指标是通过分析系统性能计算出来的值。

• 分布式追踪: 剖析监控应用特别是微服务的方式。

分布式追踪帮助定位故障和性能低的根因。

应该更多的聚焦输出，而不是输入

当前时代，将万物都冠以可观测性的帽子着实让人生疑，要知道可观测性并非APM的进化，更是从架构层面来看，它和传统的apm厂商提供的工具是有冲突的。

可观测性工具需要从0开始设计和编码来满足云原生的要求，且最重要的是，可观测性讲的不仅仅是日志、链路和指标，可观测性最重要的是收益。

纳尼？什么是以收益为基础的可观测性？

在引入可观测性平台前，每个公司都应该认真思考以下三个关键问题：

了解：顾客或者用户体验不佳或者不满意前后，公司多久才能知道，公司是否收到通知发生了什么。
甄别：甄别问题及影响的速度和响应是否够快，是否轻松容易？
精通：该如何找出根因并修复问题？

号称可观测性的三大支柱：日志、链路和指标已经过时了，这三大支柱过分依赖于技术插桩和底层数据，对收益的关注度不够。

可观测性的场景化

只有正确打磨实施的可观测性，才能驱动先进的竞争优势，带来世界一流的用户体验和快速的创新，业务增长才能更快更高效，也能高效衡量问题对业务的影响。针对上面三个关键问题，始终伴随着如何探索和开辟工具的打磨，其中最容易被工程师、架构师、决策者忽略的，便是可观测性的场景化。其中利用场景仪表板，才有可能将数据凸显更大的价值，这里不仅仅是研发和运维方面，更多的是业务方面的价值。

可观测性的数字生产力

可观测性应该作为数字化生产力工具，基础定位应该是助力实现数据驱动的现代软件工程体系，改变软件全生命周期管理，先进级别的可观测性不仅完全简化和自动化，还要能够指导研发方向，卓越级别的可观测性要能够实现智能化决策。。。。

编者按，国内可观测性厂商大概盘点

国内常见产品分类

国内APM厂商能力相对分散又聚焦，基本能力囊括可视化、告警能力、日志、rum+apm、网络监控、基础监控，很少有把三大支柱串联起来的可观测性（APM）公司，由此可见，可观测性在国内确实市场潜力巨大。

鉴于盘点产品国能评测，非常容易招来非议（毒打），所以我打算直接从另一个角度来说，举个栗子说，某高手讲过，高级玩家都是喜欢自定义的，不想被简单甚至简陋的框架束缚，纵观国内APM厂商（非可观测性厂商），满足业务数据洞察的屈指可数，我们先从可扩展性来讲。

有关编程扩展性？

现在基于 OpenAI 的 Chat+ 应用井喷，但给开发者带来了两个难点：

一是因为 OpenAI 基于 tokens 的计费机制导致不容易规划消费；
另一是 OpenAI 提供的调用本身不稳定，很难分辨是传参错误或是访问失败。

这导致许多开发者，需要在调试时一边小心翼翼地时刻关注余额，又要担心服务质量抖动，挺让人糟心。但是使用观测云强大的可编程机制可以轻松实现 OpenAI 可观测，记录所有请求的输入输出内容、调用请求延迟、调用成功率、以及费用详情，而完成这些功能就是几分钟动动手的事情。观测云已预置了下文用到的所有数据采集与仪表板模板，略作配置即可使用。