可观测性:运维风向标!

EASYOPS_youwei · · 551 次点击 · · 开始浏览    

近年云原生如火如荼

可观测性从中脱颖而出

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

前沿认知引导行业走向

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

可观测性真有这么厉害?

和监控又有啥区别啊?

(“技术”人才,人称“懂王”)小编表示

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

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

这就安排上秒懂介绍

干货!干就完了!

概念

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

打造团队敏捷特性

解决故障隐患

保障业务健康

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

节省投资虽是诱人

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

所谓的节省  必定迅速消失

可以清晰预见

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

企业纷纷涉足从中获益

其中也是技术追求所在

逐步实现乃必然趋势

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


有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:701969077

551 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传