---

近年云原生如火如荼

可观测性从中脱颖而出

理论的价值呈现吸引大波关注

前沿认知引导行业走向

这里可能会有看官姥爷要问了

可观测性真有这么厉害？

和监控又有啥区别啊？

（“技术”人才，人称“懂王”）小编表示

缺乏可观测性就如闭眼开车！

为了规避业务风险！必须引起重视！

这就安排上秒懂介绍

干货！干就完了！

概念

可观测性（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节点、网络、进程级别、有时甚至要深入到套接字和网络数据包级别，通过逐层分析才能理解这些底层的问题。

打造团队敏捷特性

解决故障隐患

保障业务健康

一定要在可观测性上有所投资

节省投资虽是诱人

但在下一次缓慢修复事件中

所谓的节省  必定迅速消失

可以清晰预见

可观测性已成大热  逐渐普及

企业纷纷涉足从中获益

其中也是技术追求所在

逐步实现乃必然趋势

但最终实现也是任重而道远~

---