可观测性（运维风向标！）

【可观测性（运维风向标！）】世事洞明皆学问，人情练达即文章。这篇文章主要讲述可观测性：运维风向标！相关的知识，希望能为你提供帮助。
近年云原生如火如荼
可观测性从中脱颖而出理论的价值呈现吸引大波关注前沿认知引导行业走向

文章图片

这里可能会有看官姥爷要问了可观测性真有这么厉害？和监控又有啥区别啊？（“技术”人才，人称“懂王”）小编表示缺乏可观测性就如闭眼开车！为了规避业务风险！必须引起重视！这就安排上秒懂介绍干货！干就完了！

文章图片

概念

文章图片

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