作者：蒋烁淼 观测未来创始人兼CEO
一直以来，开发工程师的目标是希望新的功能代码能够尽快上线，而运维工程师的目标是保证整个系统的稳定性。因此，两者之间必然存在冲突。
随着云计算的发展，系统变得越来越复杂，从infrastructure到platform再到application，出现了无数种技术栈、无数种能力、各种各样的端，系统变得越来越复杂。
开发工程师希望更快上线，而运维工程师担心上线以后的故障引发问题，会阻碍开发工程师的系统上线，因此往往会进入非常糟糕的循环。过程中缺乏可观测性，导致开发工程师与运维工程师陷入无穷无尽的拔河。
那么，如何提升研运协同？答案是：可观测性。
某种程度上可以将可观测性看作一个数据中台，用数据的方式将开发、运维甚至测试工程师连接在一起。
可观测性（Observability)是近年来的火热话题，Gartner在2023年预测里也将可观测性的应用作为重要趋势。
很多人认为，可观测性就是将Metrics、Logs和Trace合并起来，但这其实是一种较为狭隘的观点，可观性的数据并不只包含上述三类，该种描述只是站在传统角度以及数据角度，并没有站在业务的应用角度。
右边两个图才是我们认为的可观测性。它不只是解决Metrics、Logs和Trace的收集问题，更重要的是，它解决了将测试、开发、预发甚至生产环境通过数据驱动的方式实现一致性管理的问题。由此也可以引申出：可观测性是连接开发、测试、运维的数据平台，是一个数据驱动的平台。因此，某种意义上可观测性是监控的左移。从另外的角度来看，也可以理解为将开发、测试右移，使整个开发过程与生产环境都能够一致性地使用数据来描述。
因此，可观测性最重要的功能并不是收集三类数据，而是能够使开发、测试运维在数据的指导下完成整体的协同。
可观测性与传统监控存在诸多差异。
首先，可观测性系统是一个主动系统，它本质上是一个数据分析平台，驱动了测试、运维、研发人员主动浏览分析系统的能力。某种意义上，它类似于一个面向开发、测试、运维的BI。而传统的监控通常是被动系统，很少会在告警出现之前主动监控系统。监控系统往往服务于运维，而可观测性能够帮助研发、测试、运维形成一起协作的平台。
其次，传统监控面向运维，因此往往在生产环境中上线，而可观测性平台面向整个软件生命周期，软件研发型企业也适用。当可观测性覆盖到研发测试过程中，比如压测、功能性测试、回归性测试，能够反映出的数据效果也非常有价值。它消灭了复现，使得所有问题的发现都有记录。
另外，传统监控仅仅面向故障预警，而可观测性除了故障预警以外，很重要的能力是帮助研发修复bug，以及发现性能和架构上的缺点，能够提升整个系统的可靠性，而不仅是在运维层面上处理异常问题。
最后，传统监控主要面向单点事件告警，存在告警降噪的问题，但如果能够提供故障事件的完整上下文，则完全不需要降噪，因为所有数据都被以上下文context的方式传递出来，我们可以明确地知道出故障接口当时的CPU状态、中间件状态、MySQL的连接数、云厂商的网络情况等，完全无需对每一层设置告警，只需要在关键的位置设置告警。当关键位置出现故障或出现异常时，其他组件对应的状态自然而然会传递下来。
因此，可观测性与传统监控虽然看起来都是收集数据以及对数据的处理告警，但可观测性的能力远远超越了传统监控所能覆盖的能力，同时又包含了传统监控本身的能力。严格意义上来说，可观测性不是监控2.0，而是一种新的收集机器数据、分析机器数据以及利用数据进行软件研发协同的方法论。
建立可观测性与建立监控系统的目标不一样，监控系统的目标在于保障整个系统，出现故障时有能力发现故障；而可观测性的目标是建立全面基于数据的debug能力，使最终的开发测试运维人员有能力去定位问题，问题不仅是故障，也包含bug。
观测云提供的能力不仅包含传统的监控仪表盘、日志告警，也包含几大新能力：
- 持续分析：可以追踪代码执行的堆栈信息，获取执行过程中的IO、耗时最长的函数、占用内存最多的对象以及IO性能等；
- session replay：能够记录最终用户真实操作的过程界面，定位问题时可以方便地知道用户如何一步一步点到问题；
- 链路火焰图：在传统的trace、log基础上，提供可视化可分析的模式，能够快速看清代码调用逻辑，包含同步调用、异步调用以及包含关系、执行情况；
- 基础设施洞察：不只做主机的监控，也能够提供各种高度的可观测视图帮助理解容器，包括pod、service、deployment等K8S云原生的组件在整个集群中的状态与位置。
- CI可观测：能够实现对CI过程的全面观测,可以与CI的自动化测试、CI自动发布建立联系，包括AB Test、金丝雀发布也能与CI可观测形成互动。
- 前端页面调试：我们希望将Chrome的inspect能力带到每一个访问用户的分析上。
因此，可观测能力已经超越了传统意义上的Metrics、Logs和Trace，它是真正基于数据建立的完整的debug能力，这也是一般的开源系统无法企及的高度。
构建业务的全面可观测性，要面对非常复杂的过程，整个系统中有云或基础设施、操作系统、中间件、服务应用、前端客户端还有业务系统。因此，对于构建可观测性，观测云要将所有的云平台，包括公有云、私有云、系统平台，包括Linux、Windows、service、Kubernetes等操作系统，以及各种各样的中间件、数据库、消息队列等，也包括服务端用户使用各种不同语言编写的代码，包括H5、APP的代码以及最终的业务数据全面收集关联起来，这是非常高成本的工作，但是可以非常低成本地使企业拥有该能力。
那么，为什要我们会选择使用阿里云的Elasticsearch服务？
上图为观测云的整体架构，分为客户端与服务端。
客户端有一个很重要的开源组件DataKit，提供了统一采集与集成数据的能力，可以将前文提到的各式各样的数据统一进行收集。同时，它兼容所有开源方案，可以将Skyworking、OpenTelemetry、Prometheus等能力集成进来。这也意味着，即使客户持续使用开源方案，也依然可以与我们的产品进行集成。
除此之外，开源的function平台可以将业务数据（无论是在数据库里，还在接口或第三方）以Python动态编程的方式通过DataKit整合进来。最后集成的数据在经过SLB负载均衡后，会被收集到中心服务。
中心服务最重要的能力是DQL（Debug Query Language）统一查询引擎，可以实现对所有数据的统一查询。而在DQL之下，提供了基于阿里云Elasticsearch与Openstore的数据存储层，我们将数据从存储中捞到的部分计算，通过DQL查询引擎最终统一展示在客户场景中。
观测云不仅要为客户提供高级的功能，还要提供比客户现有开源自建更有性价比优势的产品。这意味着可观测性要收集海量的数据，但既要保证数据能够分析，又要保证它能够以相对低的成本提供给客户。否则虽然很强大，但是要花费巨大的费用，对客户也是一个巨大的阻碍。因此，我们需要成本可控且高性能的数据存储方案。
阿里云Elasticsearch服务具有四大优势：
- 稳定可靠
- 成本可控
- 强大的分析能力
- 运维成本低
另外，Elasticsearch的下列3个能力也为我们提供了极大的帮助。
第一，Openstore功能。在基础的ES多层结构里，将暖数据与冷数据通过Openstore功能保存到对象存储，以降低大量存储成本。因此在使用Openstore的功能时，最终客户所支付的成本可能远远低于开源自建的Elasticsearch，因为95%的热数据存到了高性能存储中，但是存储量更大的数据存到基于Openstore的对象存储中，使得存储费用大幅降低。同时，备份冷存储直接写入对象存储，且该部分完全按照存储量计费，费用远远低于直接用SSD做备份的成本。另外，也方便了做容量管理，存多少付多少，无需预留容量。
第二，Indexing Service。它是所有付费客户都会开启的功能，目标是实现读写分离，避免海量查询影响数据写入的实时性。作为观测平台，如果数据写入的实时性有延迟，则对于客户数据的实时监控和报警都会造成影响。而Indexing Service服务帮助我们实现了很好的用户体验。
第三，aliyun-code插件。最重要的是它的zstd算法，相对于开源版本，可以在原有的压缩基础上对存储数据再进行1/3-2/3存储的压缩，带来了成本优势。存到对象存储的数据仍然可以进行在线分析，数据量减少也意味着从对象存储里捞数据所需要的带宽也会减少，同时使得冷存中的查询速度也变得可接受。
除此之外，Elasticsearch作为一个服务，也具备服务的优势：
第一，平滑升级。不管是Elasticsearch官方的升级、阿里云的内核升级或是平时的其他大量升级，升级过程对用户无感，也不会影响客户的读写。
第二，良好的技术支持。使用Elasticsearch服务遇到问题故障时，能够得到快速响应。
第三，可以实现非常灵活的动态扩容，无论是计算节点的扩容还是存储量的扩容，无需预留容量，非常弹性，整体运维成本大幅下降。
同时，我们内部不需要非常专业的运维工程师，且阿里云技术团队也在持续不断增强新的ES内核能力，并酌情将增强内核能力应用到产品中，得以提供比开源Elasticshirsearch更强大的能力。
除此之外，基于阿里云即将发布的Serverless模式，观测云也会推出一种新的模式，支持将数据存储到用户自己阿里云账号下的Elasticsearch的Serverless服务上，不再需要观测云托管管理数据，数据的所有权完完全全在用户自己身上，保证每一个用户基于阿里云的Elasticsearch Serverless集群，实现半私有化的扩容、缩容与弹性，数据进一步得到隔离。
因此，serverless模式推出以后，我们也会推出一个与阿里云Elasticsearch Serverless合作的版本，对于查询性能、数据独立性与性能有更高需求，能接受更高价格的客户尽请关注。
我们期待将整体的Serverless能力带给观测云的用户，同时也期望Elasticsearch的Serverless能力能够帮助观测云的用户提供多一种选择。
