此次的架构升级，是以开源为内核、以公共云为基础、以 OpenAPI 进行解偶扩展，在架构上，对开源、自研、商业化进行统一。通过采用和反哺开源、推动社区建设，通过阿里巴巴丰富的业务场景、打磨技术的性能和可用性，通过云上商业化服务更多企业、打造更好的用户体验，全方位锤炼云上产品的竞争力。
IT系统的可观测性实施起来其实和电气工程还是比较类似，核心还是观察我们各个系统、应用的输出，通过数据来判断整体的工作状态。通常我们会把这些输出进行分类，总结为Traces、Metrics、Logs。关于这三种数据的特点、应用场景以及关系等，我们会在后面进行详细展开。
回到可观测性方案落地上，我们现阶段可能无法做出一个适用于各个行业属性的可观测引擎，更多的还是专注于DevOps和通用的公司商业方面。这里面的两个核心工作是：
价值发掘：价值发掘过程主要通过可视化、告警、交互式分析等人机交互来实现，同时也提供了OpenAPI来对接外部系统或者供用户来实现一些自定义的功能。
Metrics：时序引擎我们在新版本设计之初就兼容了Prometheus，并且支持Telegraf、OpenFalcon、OpenTelemetry Metrics、Zabbix等数据接入。
Metrics：通常用于告警和图形化展示，一般直接获取或者辅以简单的计算，例如PromQL、TSQL等
Traces/Logs：最简单直接的方式是关键词的查询，包括TraceID查询也只是关键词查询的特例
目前我们这套平台上已经积累了10万级的内外部用户，每天写入的数据40PB+，非常多的团队在基于我们的引擎在构建自己公司/部门的可观测平台，进行全栈的可观测和业务创新。下面将介绍一些常见的使用我们引擎的场景：
面的示例是我们阿里云上一家客户的监控系统架构，系统除了负责IT基础设施和业务的监控外，还会负责分析和优化整个公司的IT成本，主要收集的数据有：
告警相关：通常基于服务/接口的黄金指标设置监控和告警，也可以只关心整体服务入口的告警（一般对父Span为空的Span认为是服务入口调用）。
该方法在诸多Research及Industry领域的工作中都被借鉴并使用，并日益成为分布式数据领域一体化HTAP的事实标准方案。但是应用这个方案的前提是用户需要迁移到对应的NewSQL数据库系统，而这往往带来各种兼容性适配问题。
