gydtep

整体上看，云厂商的可信度建议大家上云时，从两个方向去看，
第一，是看云厂商本身有没有足够多的第三方可信度认证。
第二，是否有很多比较大的行业企业已经选择这家云厂商，作为上面的基石标准。如果满足这两条，是可以放心上云的。

gydtep

自动驾驶：上述这些功能最终还是要人去参与，而自动驾驶可以完全不需要人的参与，直接是可观察性系统+控制系统就可以让汽车自动运行起来。

gydtep

丰富的数据源：汽车外围遍布多个激光/图像雷达，能够实现高帧率、360°实时观测周围的物体及其状态；内部则能够实时知道当前的车速、车轮角度、胎压等信息，做到知彼知己。

gydtep

强大算力：集中化的数据也意味着数据量的急剧膨胀，无论哪家自动驾驶背后都有强大的芯片支撑，只有足够的算力才能保证在最短的时间内可以进行足够的计算。

gydtep

伴随着几十年的发展，IT系统中的监控、问题排查也逐渐抽象为可观察性工程。在当时，最主流的方式还是使用Metrics、Logging、Tracing的组合。

gydtep

上面这幅图详细大家非常熟悉，这是Peter Bourgon在参加完2017 Distributed Tracing Summit后发表的一篇博文，简洁扼要地介绍了Metrics、Tracing、Logging三者的定义和关系。这三种数据在可观察性中都有各自的发挥空间，每种数据都没办法完全被其他数据代替。

gydtep

以Grafana Loki中介绍中的一个典型问题排查过程来看：

1. 最开始我们通过各式各样的预设报警发现异常（通常是Metrics/Logging）
2. 发现异常后，打开监控大盘查找异常的曲线，并通过各种查询/统计找到异常的模块（Metrics）
3. 对这个模块以及关联的日志进行查询/统计分析，找到核心的报错信息（Logging）
4. 最后通过详细的调用链数据定位到引起问题的代码（Tracing）

gydtep

上述例子介绍了如何使用Metric、Tracing、Logging去联合排查问题，当然根据不同的场景可以有不同的结合方案，例如简单的系统可以直接通过日志的错误信息去告警并直接定位问题，也可以根据调用链提取的基础指标（Latency、ErrorCode）触发告警。但整体而言，一个具有良好可观察性的系统必须具备上述三种数据。

gydtep

目前的话还没有一个厂商能够非常好的支持OpenTelemetry的统一后端，现在还是需要自己去使用各个厂商的产品来实现。而这个带来的另一个问题是各个数据的关联会更加复杂，还需要去解决每个厂商之间的数据关联性问题。当然这个问题相信在1-2年肯定会解决掉，现在有众多厂商开始在努力实现OpenTelemetry所有类型数据的统一方案。

gydtep

我们团队从刚开始09年做飞天5K项目起，就一直在负责监控、日志、分布式链路追踪等可观察性相关的工作，中间经历过小型机到分布式系统再到微服务、云化的一些架构变更，相关的可观察性方案也经历了很多演变。我们觉得整体上可观察性相关的发展和自动驾驶等级的设定非常吻合。