-概念-
可观测性（Observability），可理解为监测、审计、遥测、测仪，本质与监控系统相通，便是度量基础设施、平台、应用程序以了解运行状态。
即是描述系统可以根据外部输出推断内部运行状况的过程。如果所有内部状态都可以输出到信号，则此系统具有可观测性。
可观测性通过测量阶段闭合反馈回路，允许团队对应用程序进行快速更改并适应用户基础和环境，而不会产生不必要的意外。
正如现代管理学之父Peter Drucker曾经说过：“如果你不能测量它，你就无法管理它。”
-监控-
对于Kubernetes应用来讲，Prometheus就可以开箱即用实行监控，状态是能被监控的，透过监控系统知道某个时刻it works。
但这个应用是可观测的吗？当然不是，因为一旦出现问题，通过监控系统可能无法判断在哪个函数中crash了。
如果要知道哪里出了问题，那么就需要在应用内部实现可见性，埋点或字节码注入的方式让应用暴露业务、性能指标。
比如函数的时延、调用次数、调用错误这些参数，借此再结合旁路分析系统就能很清晰展现出应用的全貌，这才算属于可观测性。
-意义-
随着云原生技术逐渐普及，PaaS化、SaaS化不断深化，传统监控系统正朝可观测性系统演进。
可观测性不仅包括用于监控告警的系统指标，还从中增加了对系统内部运行行为的记录。
传统监控的数据说明系统是否发生异常并最多反馈出异常模块，而基于可观测性相关数据就能快速定位问题发生模块与根因。
整个技术架构的可观测性及时定位故障并做到快速恢复，无疑是对开发和运维人员更加友好，最大化解放IT生产力以实现技术价值。
可观测性的存在也能提供业务属性数据，支撑业务健康稳定发展，也是IT赋能业务的必要保障。
并且伴随微服务迅猛发展，一个线上应用可能包含100个以上的微服务，数量众多的微服务的治理也是比较明显的问题。
面对规模日益壮大的系统，人工真的无法完整全面去了解系统每一个组件并及时解决故障，可观测系统相比以往任何时候都显得不可或缺，高可观测性可将“凌晨被唤醒”转换为“日常检查”。
-三板斧-
Logging（日志）、Trace（跟踪）、Metrics（指标）是实现可观测性的三板斧，每一个都有很多的解决方案可选，通过工具收集的数据统称为遥测数据。
# Logging
比较典型的应用工具是EFK、Loki。
记录离散事件，以此分析出程序的行为，应用程序调试或错误消息转换文件描述，通过Syslog发送到Elasticsearch。
# Tracing
比较典型的应用工具是Jaeger、Tempo。
处理请求范围内的信息，以此排查故障。在系统中执行的单个事务对象生命周期里所绑定的数据或元数据。
例如RPC远程服务调用的持续时间、请求到数据库的实际SQL查询语句、HTTP请求入站的关联ID。
# Metrics
比较典型的应用工具是Prometheus、Netdata。
例如队列的当前长度可以被建模为一个量规，HTTP请求的数量可以建模为一个计数器，更新后通过简单的加法聚合计算。
并且可将观察到的请求持续时间建模为直方图，更新汇总到某个时间段中并建立统计摘要。
-OpenTelemetry-
OpenCensus除了Tracing外还定义了Metrics，OpenTracing和OpenCensus在云原生CNCF的大旗下最终合并成OpenTelemetry，并成为当今可观测性的准标准协议。
OpenTelemetry带来Logging、Tracing、Metric的统一标准，三者都有相同的元数据结构，可以轻松实现互相关联。
# 核心工作
制定规范和统一协议，规范制度包含数据传输、API，标准协议包含HTTP W3C支持、GRPC框架。
集成多语言SDK，用户可用SDK进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack）进行集成支持。
OpenTelemetry自身定位很明确：数据采集和标准规范的统一，对于数据的使用、存储、展示、告警，官方是不涉及的。
# 统一SDK
为每个常见语言都实现对应SDK，未来系统只需一个SDK就可以记录三种可观测性数据。
# 自动代码注入技术
提供可以自动代码注入的实现，目前已经支持Java各类主流框架的自动注入。
# 厂商无关性
提供Collector用于收集各个SDK发送的数据并支持对接到各种后端存储系统。
# 云原生
设计之初就已经考虑到云原生的特性，并且还提供K8s Operator用于快速部署使用。
# 各类数据存储方式
OpenTelemetry只做了数据统一生产的部分，后面数据的存储方式并没有明确的定义，暴露的问题也是比较突出。
Metrics可存在Prometheus、InfluxDB或各类时序数据库，Tracing可对接Jaeger、OpenCensus、Zipkin，实际选择并运维这些后端比较困难。
# 数据分析
对于采集到的数据进行统一分析比较难以实现，要在不同的软件面向不同的数据单独去做，可能还需额外一个数据库去存储分析的中间结果，然后再对中间结果继续处理。
# 可视化与关联
可视化、交互至关重要，想要在一个平台显示Logging、Tracing、Metrics，并能实现三者关联跳转，需匹配很多定制化的开发工作。
# 异常检测与诊断
对系统进行更加有效的异常检测和根因诊断属于很大的难题，需把OpenTelemetry的数据融入到AIOps的相关技术中。
-面临挑战-
# 数据孤立
传统的监控工具专门收集应用程序和基础架构级别的指标。考虑到云本机应用程序的高度动态、分布式、短暂性，这种度量收集方式会在仓库中创建数据。
这些数据需要在服务中缝合在一起，以便让DevOps和SRE能调试服务问题（例如响应时间慢、停机）。
此外如果DevOps工程师或服务所有者添加新的观测指标，数据孤立仓库可能会导致交叉引用中断和数据误解，从而导致数据错位、通信速度减慢、分析错误。
# 数据卷和细粒度组件
K8s部署由多个组件构成，比如Pod、容器、微服务，都运行在分布式的基础设施上。
由每个层面产生的海量的各种粒度的数据，例如告警、日志、跟踪信息，这些数据随着服务扩展而增加。
数据越多就越难梳理出模式和调试问题，数据增长也让观察和故障排除会变得举步维艰。
# K8s抽象
让大家难以理解在动态、短时、分布式的基础设施底层发生的事情。
