“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

2022,我们该如何理解可观测技术

  • 2022-05-30
  • 本文字数:3569 字

    阅读完需:约 12 分钟

2022,我们该如何理解可观测技术

本文受访嘉宾:蒋志伟,爱好技术的架构师,先后就职于阿里、Qunar、美团,前 pmcaff CTO,目前 OpenTelemetry 中国社区发起人,https://github.com/open-telemetry/docs-cn 主要维护者。

 

有心人可能已经发现,可观测问题正在悄然成为 IT 行业的热门话题。尤其是从 2021 下半年到今日的一年间,对可观测问题的讨论,不断见诸技术圈内,大有愈演愈烈之势。

 

从技术的角度看,这是因为微服务架构逐渐普及,导致可观测问题变得十分复杂。

 

差不多在五年前,分布式系统也已成熟,微服务架构尚未普及,可观测问题就已经在桎梏技术团队的工作效率。一个 To C 的软件使用问题可能由客服发起,整条支撑链路的所有技术部门,都要逐一排查接口和日志,流程非常原始,也非常低效。如果业务到达一个量级,支撑系统变多,两名研发查上两三个星期也是常事。

 

微服务架构普及后,问题变得更加严峻。一个服务被拆分成数个黑盒的、虚拟的微服务,故障排除彻底成为一种折磨。

 

从行业的角度看,则是因为 Datadog 在美上市,两年间市值翻了三倍多(截止到 5 月 30 日,市值为308亿美金),让从业者看到:可观测不但是个未被妥善解决的疑难老病,也有十分广大的市场空间。巨大的需求背后,必然是急速扩张中的市场。

 

这一切都使可观测成为 2022 年技术人必须关注的话题。

 

当我们谈论可观测,究竟是在谈论什么?

 

2016 年,一本名叫《Site Reliability Engineering - How Google Runs Production Systems》出版,谷歌的工程师在书中描绘了故障生命周期的五个阶段:故障预防、故障发现、故障定位、故障恢复、故障改进。而对 IT 系统故障的发现和定位,正是可观测问题的另一种诠释,某种程度上也最接近可观测问题本质的定义。



在此基础上,我们可以将可观测问题大致分为四类:

 

  • 分布式链路追踪技术:可观测的基石

  • APM:Application Performance Monitoring ,应用性能监控

  • NPM:Network Performance Monitoring ,网络性能监控

  • RUM:Real User Monitoring,真实用户监控

 

其中,分布式链路追踪技术的核心思想是:在用户一次请求服务的调⽤过程中,无论请求被分发到多少个子系统,子系统又调用了多少其他子系统,我们都要把系统信息和系统间调用关系都追踪记录下来,最终把数据集中起来做可视化展示。(引用自《怎么理解分布式链路追踪技术》,作者:蒋志伟,该文章会在专题的后续更新中放出)

 

APM 主要是为了对企业核心业务系统进行性能的故障定位和处理,帮助优化性能,提高业务系统的可靠性和用户体验,更多偏向产品维度,其底层虽依赖分布式链路追踪技术,但不能直接用来解决分布式链路追踪的问题 —— 这是此前很多工程师容易混淆的问题。(《在生产环境如何选择靠谱的 APM 系统》,作者:蒋志伟,该文章会在专题的后续更新中放出)

 

NPM ,顾名思义,其关键在于实现全网流量的可视化,对数据包、网络接口、流数据进行监控和分析。

 

RUM 的关键在于端到端反应用户的真实体验,捕捉用户和页面的每一个交互并分析其性能,是种高度实用主义的监控设计。

 

同时,可观测存在三个主要的数据源:

 

  • 指标(metrics)

  • 链路(trace)

  • 日志(log)

 

其中指标告诉我们是否有故障,链路告诉我们故障在哪里,日志则告诉我们故障的原因。

 


这三类可观测问题加上三种监控类型,共同构成了可观测问题的主要内容。

 

不同企业如何建设可观测体系

 

不过对于一个企业来说,想构建可观测体系,并不意味着要直接复刻上述所有目标维度。不同的企业类型,以及不同的行业背景,都有不同的侧重点和建设方式。我们可以简单将建设方式分为三种情况:

 

  1. 自研;

  2. 采用开源作品;

  3. 购买 SaaS 服务;

 

再来看看,如何应用其中 1 - 3 条方式完成企业的可观测体系建设。

 

首先,从团队规模来说,可分为几种不同的情况。

 

第一类:企业是互联网大厂,整体业务并发量非常大,稳定性要求很高。那么开源产品基本很难满足需求,只能依赖自研。因为达到一定规模的并发量与可靠性要求,在业内永远是少数派,开源产品很难遵循这样的演进路线。

 

第二类:中型企业,位于行业腰部,没有特别高的性能要求,同时有一定的自研能力。该类企业在可观测体系的建设上可以有三种思路:

 

  1. 如果目前技术栈内全部是主流框架、组件和编程语言,可以尝试直接采用开源产品,或是基于开源产品做定制化改造。当然,要注意反哺社区,有出有进;

  2. 如果包含一部分非主流框架或编程语言,比如 .net ,可以尝试单独购买第三方 SaaS 服务;

  3. 如果包含一部分非主流框架或编程语言,且对自研能力非常有信心,可以围绕这部分进行自研;

 

第三类:创业公司。创业公司的业务、方向都可能出现较大变化,数据体系也不一定非常健全,所以创业公司可以暂缓建设可观测体系。

 

第四类:非 IT 技术驱动的传统企业,如律师事务所、报社等,只要能保证服务高可用(相对于当下业务的忍耐度),可以不购买或自研建设可观测体系。可观测体系是为了解决 IT 故障,不是为了显示技术团队很牛。如果需要的话,可以直接购买第三方服务。

 

企业在不同生命周期的方案不同,因为所处行业不同,对可观测体系的需求也会有较大差异。

 

蒋志伟为 InfoQ 记者举了个例子:“比如说,电商行业可能对链路和日志监控的联动要求很高,但物联网系统可能很多不需要链路监控。银行系统业务迭代不频繁,看重故障系统化改进, 更关心压测系统。”

 

因行业背景而产生巨大差异的案例还有很多,像 IoT 因为行业特性,也基本没有链路追踪诉求。凡此种种,难以尽述,更为行之有效的办法,是找一找该行业内的标杆企业,观察一下他们可观测体系是如何建设的。

国内外可观测行业与技术发展现状

 

行业和技术的发展情况,则是我们应当关注的,最后、最重要的一个维度。

 

首先是行业层面。目前国内的行业发展和创新,仍然有些“硅谷追随者”的感觉,Datadog 的市值翻倍,给了大家信心,这让国内可观测产品的孵化速度正在加快。

 

在美国,Datadog 是该领域绝对的“当红炸子鸡”。蒋志伟对 InfoQ 记者说:

 

“Datadog 的获客成本非常低,销售占公司人员比例很少,大部分都是研发——他们的市场扩展,依赖的就是口碑和社区。Datadog 的 Slack 群聊中,居然有五万多名商业客户,这些客户每天都在抛出自己的需求和问题。而 Datadog 也以惊人的速度更新版本,满足这些客户的诉求。双向打磨下来,这些客户其实已经无法离开 Datadog —— 只有 Datadog 才能满足他们的需求。这是开源软件相对难以实现的商业闭环。”

 

阿尔法公社一篇 2020 年的采访显示:Datadog 上市后的年利润增长率达到了 82%,Rule of 40(SaaS 行业关键指标:增长率+利润率不低于 40%)高达 93%,净收入留存率 > 145%,三者皆是行业领先水平,是 SaaS 行业绝对的“头部玩家”。

 

事实上,Datadog 的成功只是 APM 行业在美高速发展的一个象征。如 DataTraceSplunk 等企业不但通过高客单价保证了营收,也合力使 APM SaaS 产品覆盖了超过 50% 的美国市场。

 

相比较之下,国内的可观测产品还处于发展期,但也有 Skywalking 这样的开源作品,以及阿里云 ARMS、Prometheus 这样的商业产品,提供了比较好的使用体验。

 

但 ARMS 也暴露出一个可观测的关键技术障碍 —— 数据孤岛问题。如果要在企业内建设完善的可观测体系,很可能会形成链路监控、日志监控、指标监控等多套不同的监控系统,要打通是相当困难的。不同的业务线间,日志规则不互通,要完全互通也很困难。系统一旦过多,相关维护以及故障排除的时间成本就会大幅增加。

 

针对数据孤岛问题,目前行业内的一大趋势是:拥抱 OpenTelemetry。OpenTelemetry 是由一组 API 和库构成的标准,由 OpenTracing 和 OpenCensus 项目的合并而来,服务于可观测技术的底层数据采集,最早由微软和 Google 发起,当下已经成为美国可观测行业研发的事实标准 —— 微软、Google、Datadog、Splunk 等企业全部采用 OpenTelemetry 完成底层的数据采集,而 OpenTelemetry 的主要贡献者也来自这些公司。

 

OpenTelemetry 的特点在于制定统一的协议数据格式,并提供底层数据采集器。蒋志伟提到,OpenTelemetry 的数据采集器,目标是兼容所有的语言、所有的系统。

 

而与 OpenTelemetry 打配合的各大厂,要负责提供兼容该采集器的插件系统,是数据能够同步到这些企业的平台。

 

这使得 OpenTelemetry 既不会因动了“数据的蛋糕”,引起生态抵制,也极大保存了精力,得以专注于数据采集器,努力去兼容“所有的语言、所有的系统”。可以说,OpenTelemetry 试图从开源数据采集器的层面,解决可观测数据孤岛的问题,并且取得了开创性的成果和进展,值得特别关注。

 

关于 OpenTelemetry 发展的下一阶段,蒋志伟认为,AIOps 可能是一个重点。可观测的最终目的在于解决故障,如果能通过 AI 的手段,更高效的、自动化的排除故障,无疑又会开辟一个非常有想象力的技术应用领域。

 

参考链接:

https://finance.sina.com.cn/tech/2020-10-24/doc-iiznctkc7346044.shtml

2022-05-30 18:226776

评论 2 条评论

发布
用户头像
“当我们谈论可观测,究竟是在谈论什么?”一节里的第一张图,observability 写错了 ;)
2022-09-14 20:55 · 湖北
回复
感谢提醒🌹,已修正
2022-09-16 12:41 · 北京
回复
没有更多了
发现更多内容

TCP协议和UDP协议详细介绍

阿柠xn

TCP 计算机网络 协议族 UDP协议 9月月更

深度剖析Istio共享代理新模式Ambient Mesh

华为云开发者联盟

云计算 云原生 后端 企业号九月金秋榜

我也不想学之PHP系列(1)

吉师职业混子

9月月更

Web3.0 杂谈 -#003(49/100)

hackstoic

Web3.0

[Spring Framework]AOP经典案例、AOP总结

十八岁讨厌编程

Java 后端开发 9月月更

速刷html一周目(下)

吉师职业混子

9月月更

JavaWeb核心之ServletContext

楠羽

Servlet 笔记 9月月更

前端面试经常被问的题目,自己总结了一下

loveX001

JavaScript 前端

js高频手写题总结

helloworld1024fd

JavaScript 前端

每日算法刷题Day16-和为S的两个数字、数字排列、二进制中1的个数

timerring

算法题 9月月更

培养技能、增强信心、 获得亚马逊云科技认证

亚马逊云科技 (Amazon Web Services)

培训与认证

INFINI 产品更新啦 20220923

极限实验室

elasticsearch console Gateway infini 极限实验室

数据库系统是什么?它由哪几部分组成?

乌龟哥哥

9月月更

react20道高频面试题答案总结

beifeng1996

前端 React

这些react面试题你会吗,反正我回答的不好

beifeng1996

前端 React

[Spring Framework]AOP初识

十八岁讨厌编程

aop 后端开发 9月月更

跟着卷卷龙一起学Camera--LTM

卷卷龙

ISP 9月月更

速刷html一周目(上)

吉师职业混子

9月月更

Docker多阶段构建实战(multi-stage builds)

程序员欣宸

Docker 9月月更

19道高频vue面试题,顺便写一下自己的答案

bb_xiaxia1998

Vue 前端

开发者有话说|在内卷中不断成长

timerring

9月月更 开发者有话说

【Jvm】Jvm类加载机制

石臻臻的杂货铺

JVM 9月月更

VUE v-bind 数据绑定

HoneyMoose

峰会倒计时1天!九位行业大咖邀您共启极速统一的数据分析新范式

StarRocks

[Javaweb]JSON

十八岁讨厌编程

json 后端开发 9月月更

Struts实现登录

Struts2 9月月更

【云原生 | 从零开始学Kubernetes】五、Kubernetes核心技术Pod

泡泡

Docker 云计算 云原生 k8s 9月月更

自动化测试神器playwright的安装及常见问题解决

迷彩

playwright 学习记录 9月月更

js常见手写题总结

helloworld1024fd

JavaScript 前端

2022-09-23:整数数组 stations 表示 水平数轴 上各个加油站的位置。给你一个整数 k 。 请你在数轴上增设 k 个加油站, 新增加油站可以位于 水平数轴 上的任意位置,而不必放在整数

福大大架构师每日一题

算法 rust 福大大

【云原生 | 从零开始学Kubernetes】六、Pod的镜像拉取策略与各种机制

泡泡

Docker 云计算 云原生 k8s 9月月更

2022,我们该如何理解可观测技术_云原生_王一鹏_InfoQ精选文章