近年云原生如火如荼
可观测性从中脱颖而出
理论的价值呈现吸引大波关注
前沿认知引导行业走向
这里可能会有看官姥爷要问了
可观测性真有这么厉害？
和监控又有啥区别啊？
（“技术”人才，人称“懂王”）小编表示
缺乏可观测性就如闭眼开车！
为了规避业务风险！必须引起重视！
这就安排上秒懂介绍
干货！干就完了！
概念
可观测性（Observability），可理解为监测、审计、遥测、测仪，本质与监控系统相通，便是度量基础设施、平台、应用程序以了解运行状态。
即是描述系统可以根据外部输出推断内部运行状况的过程。如果所有内部状态都可以输出到信号，则此系统具有可观测性。
可观测性通过测量阶段闭合反馈回路，允许团队对应用程序进行快速更改并适应用户基础和环境，而不会产生不必要的意外。
正如现代管理学之父Peter Drucker曾经说过：“如果你不能测量它，你就无法管理它。”
监控
对于Kubernetes应用来讲，Prometheus就可以开箱即用实行监控，状态是能被监控的，透过监控系统知道某个时刻it works。
但这个应用是可观测的吗？当然不是，因为一旦出现问题，通过监控系统可能无法判断在哪个函数中crash了。
如果要知道哪里出了问题，那么就需要在应用内部实现可见性，埋点或字节码注入的方式让应用暴露业务、性能指标。
比如函数的时延、调用次数、调用错误这些参数，借此再结合旁路分析系统就能很清晰展现出应用的全貌，这才算属于可观测性。
意义
随着云原生技术逐渐普及，PaaS化、SaaS化不断深化，传统监控系统正朝可观测性系统演进。
可观测性不仅包括用于监控告警的系统指标，还从中增加了对系统内部运行行为的记录。
传统监控的数据说明系统是否发生异常并最多反馈出异常模块，而基于可观测性相关数据就能快速定位问题发生模块与根因。
整个技术架构的可观测性及时定位故障并做到快速恢复，无疑是对开发和运维人员更加友好，最大化解放IT生产力以实现技术价值。
可观测性的存在也能提供业务属性数据，支撑业务健康稳定发展，也是IT赋能业务的必要保障。
并且伴随微服务迅猛发展，一个线上应用可能包含100个以上的微服务，数量众多的微服务的治理也是比较明显的问题。
面对规模日益壮大的系统，人工真的无法完整全面去了解系统每一个组件并及时解决故障，可观测系统相比以往任何时候都显得不可或缺，高可观测性可将“凌晨被唤醒”转换为“日常检查”。
三板斧
Logging（日志）、Trace（跟踪）、Metrics（指标）是实现可观测性的三板斧，每一个都有很多的解决方案可选，通过工具收集的数据统称为遥测数据。
# Logging
比较典型的应用工具是EFK、Loki。
记录离散事件，以此分析出程序的行为，应用程序调试或错误消息转换文件描述，通过Syslog发送到Elasticsearch。
审计跟踪事件通过Kafka推送到BigTable数据存储，或从服务调用中提取并发送到错误跟踪服务（例如NewRelic）的特定于请求的元数据。
# 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）进行集成支持。
实现数据收集系统，当前是基于OpenCensus Service的收集系统，包括Agent和Collector。
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抽象
让大家难以理解在动态、短时、分布式的基础设施底层发生的事情。
容器、Node节点、网络、进程级别、有时甚至要深入到套接字和网络数据包级别，通过逐层分析才能理解这些底层的问题。
打造团队敏捷特性
解决故障隐患
保障业务健康
一定要在可观测性上有所投资
节省投资虽是诱人
但在下一次缓慢修复事件中
所谓的节省 必定迅速消失
可以清晰预见
可观测性已成大热 逐渐普及
企业纷纷涉足从中获益
其中也是技术追求所在
逐步实现乃必然趋势
但最终实现也是任重而道远~
有疑问加站长微信联系（非本文作者）
