1.1.概述
云原生（Cloud Native）由Pivotal公司Matt Stine 于2013年提出，它代表一种构建和运行应用程序的技术和方法论，其中“Cloud”表示的是应用运行在云环境之上；“Native”则强调的是应用从设计之初就基于云基础设施能力，借助云的优势实现更加高效强大的技术架构；
云原生是对传统云计算的拓展延伸，其核心价值不再是云计算技术本身，而是强调以业务应用为中心的理念，充分挖掘并释放云对业务应用的价值，即云是服务业务应用的基础设施，业务应用生于云、长于云，进而实现云业融合、云随业动、云驱业长的本质价值。云原生可观测性是从传统软件监控及数据分析可视化工具中，总结出在云原生领域中，从底层容器基础设施、通用技术组件到业务应用系统全链路监控运维、运营治理等产品化体系化的能力诉求。可观测性是云原生技术架构的重要特征，确切的体现了云原生的核心理念，自提出就被广泛的认可：2017年，Apple工程师Cindy Sridharan在9月发表的博文《Monitoring and Observabbility》中，谈到云原生监控与可观测性的关系；2017年10月份，Matt Stine在接受InfoQ采访时将云原生特征重新归纳为六大点，分别是Modularity(模块化)、Observability(可观测性)、Deployability(可部署性)、Testability(可测试性)、Disposability(可处理性)、Replaceability(可替换性)；其中就包含了Observability可观测性。
1.2.可观测性的定义
进入云原生时代，应用的构建部署与运行时基础设施都发生翻天覆地的变化，技术架构微服务化、运行时环境容器化、业务系统依赖关系复杂化，运行实例生命周期短，规模大；服务自动注册发现，监控也随着实时动态调整，传统预先配置再监控的方式已经无法满足云原生的场景。可观测性与监控是有本质区别的，监控更多的偏向自动化工具，可以替代人自动监控系统异常；而可观测性不仅包含传统监控的能力，更多的是面向业务，强调将业务全过程透明化的理念。CNCF 云原生生态也整合了可观测性体系，将可观测性的能力作为云原生底层基础设施能力，从根本上解决了平台与业务运维工具杂乱，能力层次不齐的问题。当前生态全景图中是按照 Monitoring监控、Logging日志 、Tracing调用链三个维度来分类：（一）Logging日志：结构化与非结构化的混合数据，应用运行过程会持续输出日志数据，这些日志数据是业务系统运行状态的各种事件及业务处理逻辑时输出的，如果业务日志比较完善，基本上可以还原业务流程处理的全过程。日志服务主要就是收集并长时间保存日志，如果出现事故或者其他审计需求，就可以借助日志服务随时间查阅日志信息。日志服务由来已久，主要难点是解决大规模日志数据采集，解析，存储，实时检索等问题，还有就是寻找低侵入的方式（Agent，Sidecar）来标准化输出日志，提高日志数据的质量，降低业务系统日志优化成本；目前业内常见的ELK Stack是日志服务的大成者。ELK Stack在云原生场景主要是解决日志采集适配，监听容器运行变化，灵活稳定有效地采集容器化应用的运行时日志即可。（二）Tracing调用链：结构化与非结构化的混合数据，尽大可能串联单个事务内全过程的日志数据，通过对请求打标、透传、串联，终可以还原出一次完整的请求，帮助工程师分析出请求中的各种异常点；调用链基本上是基于谷歌Dapper理论来实现的，但是对业务系统要求比较高，对业务性能是有一定的影响，在单个业务系统内比较容易实现，假如在异构应用间，尤其是串联共有云的服务组件与业务系统，业务系统前中后台的全流程，实现非常困难。（三）Monitoring监控：结构化数据，描述的是在给定时间点对系统的度量，基本上分为四大类型，分别是Sum、Count、Last value、Histograms，监控主要是底层基础资源运行状态的数据，通过多维度聚合、分析和可视化展示，帮助快速理解系统资源的运行状态。
1.3.可观测性的产品体系
在CNCF的产品能力全景图中，可观测性体系产品分为Monitoring监控，Tracing 调用链，Logging日志，Chaos Engineering混沌工程四大类，其中混沌工程更多的是一种可靠性工具，而不是可观测性，所以主要讨论前三大类产品体系：（一）Logging日志产品体系：在云原生环境中，日志收集工具与应用程序容器一起运行，并直接从应用程序收集消息，然后将消息转发到中央日志存储以进行汇总和分析，Fluentd 是该领域的 CNCF 项目，其它厂商也提供了相应的解决方案，例如elastic、splunk，国内厂商有专精于日志领域的日志易、袋鼠云，也有综合云平台的阿里云日志服务、腾讯云日志服务、七牛云日志服务(Pandora)等。（二）Monitoring监控产品体系：云原生环境中的监控和传统应用程序的监控类似，需要跟踪指标、日志和事件以便了解应用的运行状况，主要区别在于云原生环境中的某些托管对象是临时的（例如POD资源对象）。CNCF 中有许多监控工具，主要的是Prometheus，基本成为云原生监控体系通用的解决方案，配合Grafana进行可视化分析。（三）Tracing调用链产品体系：调用链是一种功能强大的追踪工具，可以对分布式应用程序的行为进行故障排除，实现成本较高，涉及应用代码适配调整。CNCF中主要的调用链工具是Jaeger。直接基于上述三个产品体系的产品及组合，可以快速的搭建可观测性系统，但在实际使用过程会遇到各种各样的问题，总结起来有如下几点：1.组件繁多: 针对Monitoring、Logging、Tracing三种场景，往往需要搭建三套独立的系统，涉及的组件多，维护成本高；2.数据不互通：同一个应用不同类型的数据被存储在相互独立的系统，数据不互通，难以发挥数据的大价值；3.云原生不友好：很多组件都成熟于云原生之前，部分组件社区发展缓慢，对于云原生的适配支持相对较弱，而且方案本身部署和使用代价都很高，不符合 “云原生” 这种一键部署、开箱即用的使用方式。当前在云原生环境中，大部分的事件处理还是依赖人工来串联Monitoring、Logging、Tracing三个产品能力，为了从根本上解决这个问题，CNCF孵化了OpenTelemetry开源项目。该项目雄心勃勃，旨在标准统一Monitoring、Logging、Tracing三种体系，实现可观测性大一统。
1.4.OpenTelemetry开源项目
OpenTelemetry是CNCF可观测性体系孵化项目，旨在提供可观测性领域的标准化方案，解决可观测性的数据模型、采集、处理、导出等的标准化问题，提供与第三方厂商无关的服务。是由OpenTracing(CNCF)和OpenCensus（谷歌和微软）两个项目合并而成，其核心工作主要集中在以下三个部分：1.规范的制定和协议的统一，规范包含数据传输、API的规范，协议的统一包含HTTP W3C的标准支持及GRPC等框架的协议标准2.多语言SDK的实现和集成，用户可以使用SDK进行代码自动注入和手动埋点，同时支持对接集成第三方（Log4j、LogBack等）；3.数据收集系统的实现，当前是基于OpenCensus Service的收集系统，包括Agent和Collector。OpenTelemetry核心功能是产生、收集可观测性数据，并支持传输到各种的分析软件中，整体的架构如下图，其中 Library 用于产生统一格式的可观测性数据；Collector 用来接收数据，并支持把数据传输到各种类型的后端系统。自OpenTelemetry推出以来，有越来越多的厂商开始关注和贡献，国内的几个公有云厂商可观察性产品也开始适配OpenTelemetry标准。对于开发者，基于OpenTelemetry可通过一套标准的方案进行 Metrics，Logging ，Tracing 的生成和导出，降低开发过程中对不同类型观测数据的使用成本，也降低对接不同后端服务的成本，如开源项目Prometheus或第三方云厂商的服务。对于SRE，基于OpenTelemetry可为观测数据提供一套标准的采集、处理、导出流程，并在处理环节根据团队需求规范化观测数据，便于后续采用标准化的方案使用观测数据，如监控、告警服务。同时，不论对于开发者还是 SRE，均可以通过社区的力量持续迭代对可观测性问题域的理解，吸收社区的技术红利，并将生产中产生的佳实践回馈社区，更好推动可观测性领域的发展。
1.5.总结
总的来说，云原生可观测性还处在发展起步阶段，各个领域都有极为成熟的大一统的产品，例如监控有Prometheus，日志有ELK或者EFK，调用链有Jaeger； 目前日志及监控产品已经趋于规范和稳定，但是产品由于发展时间长，导致目前规范体系很难统一；调用链还处在实验阶段，大的问题是在大规模分布式场景下业务全链路是跨客户端，网络，中后台服务，想要把真实业务全过程链路数据都收集串联起来，几乎不肯能实现，尤其是目前很多业务是跨云跨地域场景。另一个方面就是需要大一统的可落地产品，通过统一的标准汇聚三者的数据，挖掘交叉区域的价值。OpenTelemetry是云原生可观测性体系希望，尤其是协议及标准，发展中尚未大一统的领域都非常需要标准，有了标准之后就需要所有参与者放弃原有个性化的协议，遵守大一统的标准，分久必合合久必分，看似轻松实际非常艰巨事情；OpenTelemetry过于理想，演进完善还有很长的路，来日方长，未来可期。