【直播回看】IT系统为什么需要可观测性

1月19日我们进行了“原力释放 云原生可观测性分享会”第一期直播,收到来自各位朋友的热烈响应,在这儿感谢大家一直以来的支持与陪伴,非常荣幸能够通过直播的方式与大家面对面的进行交流。

“云原生可观测性分享会”第一期内容《IT系统为什么需要可观测性》由云杉网络CEO亓亚烜演讲,内容包括可观测性的五个方面:1、从为什么需要可观测性?2、如何理解可观测性?3、如何评估可观测性?4、如何构建可观测性?5、如何使用可观测性?来进行阐述。

同时分享了10个行业案例,帮助大家进一步的了解可观测性。当然,也总结了许多可观测性的技术价值和应用实践,希望能够帮助大家可以合理的去选择可观测性技术。【点击链接】可前往直播回看地址。下文为直播实录,接下来请大家开启沉浸式阅读模式吧。        

大家好,我叫亓亚烜,云杉网络创始人和CEO,非常荣幸能够参与云杉的首次直播活动,跟大家分享自己对可观测性的一些认知。
可观测性是监控领域非常火的技术,尤其是面对云原生场景,可观测性几乎成了IT系统必备的能力。我的很多朋友、客户、合作伙伴、投资人,当然也包括诸位,都对可观测性的发展充满了好奇与期待。今晚,我分享的主题是“IT系统为什么需要可观测性?”,我希望自己能够从价值、技术等多个层面,回答好这个问题,阐明自己的独立思考。当然更希望与诸位听众能一起互动交流,共同探讨可观测性的发展趋势。

我分享的议题包括可观测性的五个方面。我会直入主题,先把结论告诉大家。

首先,为什么需要可观测性?答案是”赋能“。可观测性的根本价值,是给IT人员赋能。让工程师、架构师、乃至CTO、CIO能够随技术进步而进步。关于如何理解可观测性,我总结了几位业界大神的定义,他们的观点非常有参考价值。同时我也根据自己的分析和理解,提出了独立的见解,可观测性即白盒监控。如果不能评估他,你就不能改进他。可观测性的评估至为重要,基于白盒监控的理解,我给出了三类可观测性评估判据,以此帮助大家选择合理的可观测性技术。关于如何构建可观测性,无外乎三种方式:SaaS服务、开源开发、集成产品,这三种方式对大多数企业都非常重要,SaaS满足快速体验,开源满足业务需求,集成满足行业合规。最后,关于如何使用可观测性,我会分享多个行业的十多个实战用例。着重讲智能汽车和股份制银行两个用例,并简要分享十个其他行业案例,以此增强大家对可观测性的认知。

01 | 为什么需要可观测性?

May the force be with you. 云杉内部的研发团队经常引用“the force”,即原力,来描述可观测性的作用。可观测性无论对工程师、架构师还是技术主管都是一种赋能。
01
对工程师而言,可观测性能够让大家抓住技术趋势,深入理解云原生技术和分布式系统。让开发工程师理解基础设施,让系统和网络工程师理解应用。云原生时代,全栈能力是一个工程师自我修养的重要部分,当然也是大家未来职业道路中升职加薪的保证。对于架构师而言,通常面临的挑战是如何让IT系统能够支撑业务量以十倍速增长。这样的增速,不采用云原生等新技术是无法实现的。然而,技术创新的背后是巨大的风险,可观测性为新技术的采用奠定了坚实基础。一方面通过监控自服务,大大加快新业务的开发测试速度,另一方面通过全栈链路追踪,保障业务上生产之后的稳定运行。
对于CTO等技术领袖而言,组织能力的提高极为重要。公司数字化业务虽在快速增长,但IT团队组织架构,人力资源等却难有大的变化。因此,需要借助可观测性建立“数据即事实”的团队协作原则,以此消除部门之间的协作壁垒,有效提升组织的协同作战能力。
说到这里,解释下可观测性为何可以比做“原力”。
可观测性的数据,本就存在,只是散布在各个部门。而可观测性平台的建立,就是数据的汇聚,可以认为是从各个部门收集到了原力。可观测性服务,则是通过汇聚的数据去反哺各个部门,即形成能够控制的“原力”,成为yoda老师那样的绝地武士。

 02 | 如何理解可观测性?

可观测性有很多种不同的定义,最广为流传的是三大支柱说。三大支柱即metrics、tracing、logging。三大支柱说广为流传的原因,在于他最容易被工程师理解并接受。然而,三大支柱的提出者,Peter Bourgon的原意恐怕不是所有人都真正理解。
Peter Bourgon非常务实的指出,讨论可观测性,需要明确讨论对象,对不同的数据类型应该有不同的优化处理方法。注意,Peter Bourgon原意并不是说可观测性就是三大支柱,而是让大家具体问题具体分析。即便是Metrics,在不同场景下也有不同的含义和处理方法。Google Dapper(谷歌的分布式追踪系统)作者Ben Sigelman更是直言,metrics、tracing、logging只是三种数据类型。言外之意,还是具体问题要具体分析。Google Dapper的论文,大家多少应该去了解一下。看看google是如何通过零侵扰、轻量级的追踪技术,帮助团队调试和诊断分布式应用的。
因此,三大支柱说的合理解读,应当是可观测性需要多类数据类型,每类数据也要在不同场景下选择不同的处理方法。希望大家能够记住这点。如果将来看到把可观测性等同于三类数据结构的兄弟,最好建议他去读读Peter Bourgon的Blog原文。

Charity Majors是我非常尊重的一位创始人,她是连续创业者,也在Facebook工作过,近几年创立了Honeycomb公司,专注可观测性。她提出了一个非常独到的看法,即可观测性是用来解释“unknown-unknown“问题的,这个说法听起来似乎有点儿玄而又玄的感觉。

我跟大家解读下:unknown-unknown可以简单理解为探索未知问题。

软件工程中,有一套完整的debug工具,帮助开发人员发现软件中的未知问题。分布式系统监控中,可观测性扮演了类似debug工具的角色,通过交互式的追踪,定位未知问题。这里请大家注意,探索未知的说法,其实是Charity Majors借用了软件工程的理论来做可观测性。这样的思路,跟Google SRE的思路完全一致。在Google SRE book的第十二章中,明确说到了,可观测性的目的就是:快速排障。由此可见,软件工程是可观测性绕不过去的门槛。要想唤醒大家对软件工程的记忆,不妨重读下《人月神话》,必然会有新的体会。

比起这位老哥(鲁道夫卡尔曼),Peter、Ben、Charity再牛,也只能算是三体文明,而这位是真正的神级文明,因为他发明定律。鲁道夫卡尔曼,现代控制理论之父,他提出了系统的可观测性理论,并且基于这个理论,把人类送上了月球。那么,在神级文明的定义下,可观测性是什么呢?以下定义均来自维基百科。首先,控制理论中的可观测性是指:系统可以由其外部输出推断其内部状态的程度。其次,一系统具有可观测性当且仅当:针对所有的状态向量及控制向量,都可以在有限时间内,只根据输出信号来识别目前的状态。这样定义非常抽象,但我可以帮大家划重点:首先是外部输出,其次是内部状态,最后是有限时间。

比如新冠核酸检测:外部输出是被棉签捅着的东西。,内部状态是肺部是否被冠状病毒感染,有限时间是3~8个小时。如果不是外部输出,那就意味着需要抽血或者开刀;如果不是内部状态,那就无法进行分诊治疗;如果不是有限时间,那要么疫情泛滥,要么没法出行。

理解了这三个重点在防疫中的含义,下面就可以讲讲他们在IT系统中的解读。

现代控制理论,用状态空间来描述系统,通过可观测性和可控性解决复杂系统的控制问题。借用控制理论中可观测性理论,引出我对IT系统可观测性的认知。首先,状态空间代表白盒监控,即对系统内部状态要有清晰的理解,否则难以实现复杂应用的诊断。其次,外部输出意味着对系统应是零侵扰的,尤其是对业务是零侵扰的,否则干扰系统运行,无法实现控制目的。再次,内部状态一定是多维度的,对IT系统而言,就是我们常说的全栈,包括应用、系统、网络及各类中间件。最后,有限时间意味着实时性,从开发测试角度而言,调试速度应该是分钟级的,从生产保障而言,故障响应速度至少也是分钟级的。因此,要支持分钟级的工作流,可观测性平台的响应速度必须是秒级的。

基于上述分析,我也提出自己对可观测性的理解。简单而言,可观测性就是为复杂IT系统寻求白盒监控能力。IT系统的可观测性应具备零侵扰、多维度、实时性等关键特性。以上便是我对可观测性的理解。如有不准确的地方,希望与大家讨论学习。

要做真正的技术创新,必须有独立的观点。舶来品虽好,但难得其真谛。我希望国内做可观测性的朋友们,能够多多交流,迸发出更多更深入的理解。后面,我将基于上述理解,进一步阐明可观测性的技术和价值。

03 | 如何评估可观测性?

去年12月跟某保险公司的IT架构部门交流,谈到传统APM要给应用插码,腾讯会议对面的一个小姑娘突然跳出来说:“你们咋打桩?”。当时我就非常吃惊,原来插码这种工作,已经上升到了“打桩”的难度。但“打桩”,为何要小姑娘来做?另一个真实的case,去年10月给某股份制银行做POC汇报,观测到对方普罗米修斯服务响应时间超过30s,客户说,“这个正常”。让985毕业的小姑娘去打桩?让每一次检索数据消耗写一行新代码的时间?这不是新一代IT人该有的样子,残酷的现状需要改变。

可观测性,必须要解决以下问题:

  1. 在数百个服务中发现瓶颈:提供非采样,秒级精度,提供HTTP/DNS/GRPC等性能指标数据
  2. 在数千个访问中追踪应用:提供应用层Trace追踪数据,网络层Flow追踪数据
  3. 在数万个容器中定位根因:提供全栈(API、主机、基础设施)端到端指标数据、日志数据
注意,解决上述问题,还需要零侵扰和实时性。

关于零侵扰判据:

传统APM/NPM等工具,要么需要应用程序中打桩插码,要么需要基础设施中分光镜像,均会对IT系统进行侵扰。可观测性要求使用外部数据做分析,因此需要采用零侵扰的方式获取监控数据。不需要打桩插码、分光镜像,而是通过开放系统架构直接获取监控数据。零侵扰的另一方面是要求低功耗,不能因为采集数据而影响应用或基础设施性能,例如,通常采集点功耗不能超过业务功耗的1%。

关于多维度判据:

要保障云原生应用稳定运行,可观测性必须包含多维度数据分析能力。具体来说,要将应用的API、容器、主机、网络等监控数据进行全栈关联分析。传统的APM工具,可以定位代码层问题,却无法追踪容器或主机网络服务引起的故障。而传统的NPM工具,又不能关联应用的TraceID从而追踪穿越NAT、LB等网元的流量。因此,多维度的全栈数据分析,是可观测性的第二个需求。

关于实时性判据:

自动控制中,过大的传感器反馈时延,会导致系统震荡而不可控。与之类似,云原生应用的动态性要求可观测性平台必须具备实时性。如果应用的升级/扩容在分钟级完成,那么监控系统就必须提供秒级的反馈能力。注意,这里的反馈需要对海量指标/追踪/日志数据进行查找分析,因此对可观测性平台的海量数据实时处理能力提出了极高要求。

再回到原力的类比,如果没有零侵扰,可观测性平台,也就是原力收集平台,无法被大家接受。如果没有多维度,原力无法关联,自然失去了其意义。如果没有实时性,原力无法有效释放,被大家掌控。人的感知时间是秒级别的,因此实时性必须做到秒级。

有了上述判据,就可以定量评估可观测性技术了。

为了说明可观测性的技术评估,我这里依据自家产品,聚焦到两个核心技术趋势之上:eBPF和OLAPeBPF解决了零侵扰,以及部分多维度问题。

02

如上图所示,左图中是一个接近全栈的多维度监控对象,其实就是一台服务器。可以看出,自下而上有,主机HOST系统,HOST的网络协议栈,虚机VM系统,虚机网络协议栈,容器POD,进程容器、Sidecar容器、应用进程等等。

传统APM,通过“打桩”,也就是插码,或者java agent的方式,能够对应用进程进行监控,即使扩展,也只能监控到部分sidecar。传统NPM,通过对设备的分光镜像流量,可以监控主机出入的流量,扩展后可以监控主机上虚拟交换机流量。

云杉DeepFlow v5.0 产品,在NPM基础上,利用classic BPF技术,通过host的用户态(零侵扰)监控到主机及虚机的系统和网卡流量。DeepFlow v6.0 产品,利用eBPF技术,进一步在零侵扰的前提下获取了应用和sidecar的信息,扩展了多维度的能力。做分析,离不开OLAP。可观测性的工程师,自然就是数据分析的工程师,OLAP能力不可缺失。过去三年时间,云杉DeepFlow产品中的关键数据组件,经历了两次重要的升级。2018年使用ES作为主要引擎,读写速度无法满足实时性要求,只能为数百台规模的业务集群实施可观测性。2020年初,DeepFlow v5.5发布,融入了深度优化的InfluxDB作为Metrics引擎,使平台性能提升10倍,可以解决数千台服务器集群的可观测性。2021年12月,DeepFlow v6.0的第一个版本发布,进一步融入了深度优化的ClickHouse作为观测数据的OLAP,读写性能再提升10倍,满足金融及互联网客户的数万规模的集群部署。

如果说摩尔定律是芯片演进的金科玉律,每18个月芯片效能增长2x。那么云时代的可观测性也不难预测:即每18个月观测数据读写速率增长10x。关于可观测性的概念和技术,讨论到此为止。

然而,纸上得来终觉浅。可观测性实战要真正落地,大家又面临哪些问题呢?既然可观测性是一种原力,而原力的掌控能力是一种增长的过程,那么我这里就借亚马逊的飞轮模型,来说明如何增长可观测性。

增长的第一步是理解和体验,体验可观测性的最佳方式当属各类SaaS服务,这些可观测性的SaaS服务可以让大家快速理解可观测性的价值。

增长的第二步是加速业务创新,也就是要满足业务部门的快速发展需求。开源是技术团队应对快速创新的最佳路径。因此,如何用开源技术构建可观测性平台是增长飞轮的第二步。

增长的第三步是满足生产需求,创新一旦完成,就要面临合规性、稳定性、安全性等一系列挑战,集成能力之于可观测性,就是赋能本身,让业务团队、基础设施团队、安全团队都能有效运转起来。

由于技术的不断进步,可观测性的飞轮将往复运行。K8S的体验之后,是Serverless,Prometheus之后是Skywalking,APM的作战半径不到20%,全链路成为永远的梦想?可观测性的增长飞轮,将引领大家解决上述问题。

04 | 如何构建可观测性?

构建可观测性的第一种方法,也是最快捷高效的方法,就是使用SaaS服务。目前,云厂商独立第三方企业均提供可观测性的SaaS服务。云厂商,比如阿里云,提供了ARMS应用实时监控服务,近期推出的K8S监控服务大家可以去体验一下,代表了可观测性的发展趋势。阿里云上还有一个更基础的可观测性服务,就是SLS日志服务,用户可以将自己采集的观测数据存入SLS服务中,并按需使用。

相比而言,ARMS提供的是一站式服务,而SLS则给予了更多的自由度。国内的腾讯云、华为云等,也都提供了可观测性服务。如果是AWS、Azure的客户,那么可以直接使用Datadog,这个500亿美金市值的公司,可以看做是可观测性的领军企业,而且主要以提供SaaS服务为主。

国内的第三方提供商,目前看到的有观测云、乘云等,云杉也提供名为DeepFlow Cloud的SaaS产品,方便大家体验。

SaaS服务的主要问题,是用户的应用大概率需要跑在公有云上,并且观测数据要由第三方管理。此外,SaaS的计费模式相当复杂,有按主机规模计算的部分,也有按数据量计算的部分,总之很难准确规划这方面的预算。因此,对于中小企业SaaS是首选,但对于中大型客户,尤其是采用混合云架构,合规性要求高,项目预算制的大型行业客户来说,很难仅仅依赖SaaS提供可观测性服务。因此,才有了飞轮中的另外两种构建模式,开源和集成。

这个时代,整个IT系统都是构建在开源之上的,可观测性也不例外。依托开源技术构建可观测性平台,是快速技术创新的必由之路。

03

如图所示,自底向上构建基于开源的可观测性平台,可供选择的开源组件非常丰富。采集层,要实现零侵扰采集,可以采用K8S的daemonset采集器,java agent,普罗米修斯的部分exporter等等。

采集层要注意的是,云原生体系下,监控数据要遵循开放标准,这样整套系统框架才能不断演进,扩展。采集层的开放标准主要是statsd和opentelemetry,尤其是opentelemetry,大有一统江湖的趋势。采集层之上是数据层,之所以是数据而不是存储层,是因为要满足实时性要求,读存写必须分离。本质上数据层就是一个实时数仓,要针对应用场景,进行深度的读存写优化。实时数仓方面对技术要求较高,可以跟有经验的团队或厂商一起开发。数据层之上,是展示层。指标、追踪、日志、告警,分别由grafana、skywalking、kibana、prometheus等常用组件支持。让这些开源项目支持更多种类的数据展示,同时为不同部门提供不同场景的APP、WEB、CLI、API,是可观测性平台团队的主要工作。

下面我们来看一个我们的客户,是如何改造Grafana,为微服务提供可观测性的。

客户的开发团队,要求对每一个微服务提供精细的指标监控,包括HTTP、DNS的RED指标,即用量、错误、时延指标,也同时要求TCP和网络层的各类指标,形成全栈链路监控能力。客户的业务团队还要求把每个微服务的全局调用关系实时展示出来,这些工作都是客户的平台团队基于Grafana二次开发完成的。

04

如图所示,虽然每一个展示的子视图,大多是Grafana自带的,但视图中的数据,都不是开源的telegraph可以直接获取到的。

事实上,客户在数据层与采集层与云杉团队合作,解决了上述数据的零侵扰采集和实时读存写问题,客户团队更多专注于Grafana的二次开发,快速满足业务需求。由此可见,开源项目并不是拿来就能用的,而是需要依据业务需求进行快速开发。如果把时间花在改进开源项目的性能上,那应该由专业团队来做,并依据开源协议为社区做出贡献。

第三种构建可观测性的方式就是集成,integration。集成听起来没有SaaS和开源性感,但我认为,集成的难度最大,因为集成的约束条件太多。这些约束条件包括,理解业务需求,提出合理预算,满足行业合规,推动部门合作等等。每一个地方出现问题,都会造成集成项目无法落地,或者无法创造价值,最终导致项目失败或难以持续发展。集成的问题非常复杂,我这里提出两种解决思路。

第一个思路是”数据即事实“,部门之间的协作应该建立在数据事实的基础之上,而不是个人主观的描述,避免责任推诿,促进团队协作。

第二个思路是”业务为中心“,无论开发、测试、系统、网络、安全等团队,均需要深入理解业务,从对代码、系统、设备的负责,变为对业务上线速度、交易量、健康度的负责。

思路好理解,但落地仍然不明确,下面我们举一个栗子来进一步说明集成的复杂性。这是某大行网络工程师给我们的发展规划。诸位听众中如果有网络工程师,可以对比下是否有这样的先进思路?

首先,集成的第一步是全栈流量采集能力,而这里考虑最多的是零侵扰特性。零侵扰被进一步划分为:稳定性、可用性、资源耗损、通用性、存储消耗、网络消耗等问题。每一个问题都需要严格的长期测试才能验证。

第二步是建立分布式系统的诊断能力。这里面考虑最多的是多维度分析能力。协议栈设计到了物理机、虚拟机、容器、业务码等,并且要求提供全栈链路追踪。另外要求能够被大数据平台和其他监控平台通过API集成。

第三步是对外服务能力。也就是之前所说的原力释放阶段。这里考虑最多的是场景和自服务。场景包括了全网监控、应用监控、客户监控、安全监控等,自服务则要求主要功能均通过用户自行完成。由于不同场景需要不同的数据支持,背后技术涉及到了实时数仓的建立和集成。

新一代的网络工程师,借助可观测性,实现了自我价值,并提升了团队间的协作能力。与之类似,系统团队、开发团队、SRE团队等,均可以通过集成方法构建可观测性平台,以提升团队的自身价值和协作能力。

 05 | 如何使用可观测性?

前面分享了可观测性的三种构建方式,下面我们来看看可观测性如何在实战中发挥价值。这里我会较详细讲述两个典型用例,同时也会快速介绍其他10个用例,以此打开大家的思路,体会可观测性的不同用途。第一个用例来自某智能车企,其业务变化非常快,公司采用公有云+容器化部署核心业务,并通过整合各类开源监控软件,构建“统一业务监控平台”。公司业务迭代速度非常快,但微服务观测不全一直是困扰着业务快速上线的一大问题。业务上线后遇到故障只能靠猜、靠逐段抓包诊断故障原因,费时费力。近期在生产环境中,nginx-control上线过程中出现了某API(xxx-api)调用某服务(xxx-service.prod.k8s.xxx.com)超时的情况。虽然现有系统能定位到工作负载和服务域名(即源和目的),但其间经过多个微服务和网络服务,到底是谁引发了访问中断却不得而知。

由于客户端、服务端均没有(或无法)部署Skywalking监控、没有采集日志,开发人员不知道超时原因。这个问题经过一整天排查未有结论,严重影响业务上线进度。借助可观测性的全栈能力,SRE团队在15分钟内定位到了根因,即问题出自一个特定的Ingress Control的容器POD。反馈到开发人员后通过修复Nginx快速恢复了故障。

第二个用例来自某股份制银行,该行在国内外的100多个城市设立了服务网点。很多业务部署在云平台的容器上。该行私有云平台上运行着10万多个微服务,数十万个POD支撑业务,每分钟业务产生的访问数亿次。该行业务运维人员经常遇到关键资源访问量徒增问题,尤其是云上云下互访时,“谁动了我的数据库!”是常见抱怨。要追查出到底是谁动了关键资源,难点重重。

难点之一是可疑分子太多,可疑分子隐藏在8万多个POD,8千多个Node、1千多VM、1千多Host之中。难点之二是每个可疑分子到关键资源之间,至少经过两次地址转换,且POD、Node、VM、Host、PIP、GW的访问路径非常复杂。难点之三是业务POD上不允许抓包,网关GW上也难以抓包(网关抓包丢包率高达40%)。

上述问题通过可观测性就得到了良好解决。首先,可观测性平台提供POD、Node、VM、Host、GW资源上全量网络流量采集,解决了POD、MUX上流量采集难的问题其次,可观测性平台同步了云平台NAT、LB等转换规则,通过服务端源IP地址、目的IP地址,分钟级在海量数据中,找到对应的POD、Node、VM、Host;最后,可观测性平台为业务部门梳理出来常见的全栈链路观测模板,助力业务部门分钟级定位业务性能峰值问题。

05

如图所示,根据业务场景,访问路径非常复杂,需要层层梳理。否则不可能解决”谁动了我的数据库!“问题。

第一个用例,是某银行在开发测试中遇到业务周期性抖动,持续一周无法上线。最终通过可观测性发现了底层路由器环路导致。

第二个用例,某地产商的电子流应用,上云后每周都出现问题。最终通过可观测性发现了服务商DNS不稳定、开发团队违规升级代码、依赖第三方服务异常等一系列问题。
第三个用例,某大型金融企业,电商业务运行的容器平台,每扩展一个POD竞耗时超过1小时,而且要反复不停重试。后根据可观测性分析,逐步定位到某物理网卡对ARP请求产生了内部回路,更换机器后恢复正常。

第四个用例,某运营商省公司在集团对应用的可用性考核中,年年全省垫底。最终通过可观测性,发现了LVS、nginx和某物理交换机之间的链路有丢包,彻底排除了困扰已久的问题。

第五个用例,某大型私有云客户,发现其关键业务中的SQL集群频繁主备切换,虽然业务没有中断,但风险极高。后经可观测性平台分析,发现是SQL切换仲裁在并发并不高的情况下就停止了服务,最终导致了不必要的切换。

第六个用例,某银行个人贷款业务突然访问变慢,在大家都怀疑是网关丢包的情况下,通过可观测性平台,定位到了DNS服务异常。而且,进一步发现不仅仅是该业务的可用区DNS异常,其他区域也有普遍现象,根本原因是DNS配置错误。

第七个用例,某BI业务,运行过程中出现性能抖动。业务侧看到的只是客户端到BI的访问路径,而可观测性平台看到的是业务端-NGINX-BI-RPC-MongoDB的整体依赖。后定位为RPC服务中有一个容器出现问题,排除此容器后业务恢复正常。

第八个用例,某省消防队,经常被省里通报,尤其是护网期间通报,必须排除通报的安全问题。由于全省消防内网复杂,而通报又只针对不到10个对外服务的IP,如何追查内部攻击源变得非常困难。通过可观测性平台,该省消防队实现了10分钟内应答通报的能力。

第九个用例,某大型容器云平台,按传统pcap分析方式运维,一次简单故障平均查找数千个数据包,耗费专家数小时的宝贵时间。通过可观测性平台,业务排障由抓包分析变为微服务RED指标监控和全栈链路追踪,排障效率从小时级变为分钟级。

第十个用例,某农商行,视频业务上云后访问量增长近10倍,经常出现业务访问慢问题,几次扩容都不能解决问题。后根据可观测性平台分析,发现是某个隐藏服务异常发送RST包导致,优化服务的队列和超时设置之后,业务恢复正常。

我这里先简单介绍10个用例,更多更精彩的用例分享,会由我们的同事、客户和合作伙伴在后面的直播中跟大家继续分享。

好了,总结一下今天介绍。

为什么需要可观测性,就是给大家”赋能“。让工程师、架构师、以及技术管理人员能够提升自我的认知能力、创新能力和组织能力。

如何理解可观测性,介绍了三种不同的视角:

  • 三大支柱说,也就是three pillars,来自Peter Bourgon,背后是数据结构理论。
  • 探索未知说,也就是unknown-unknown,来自Charity Majors,背后是软件工程理论。
  • 白盒监控说,也就是white-box monitoring,是我根据控制理论中可观测性的定义推导出来的。

如何评估可观测性,主要三个方面,零侵扰、多维度、实时性。之前的介绍中也给出了详细的判据和背后的技术趋势。

至于如何构建可观测性,介绍了三种方法,SaaS用于体验、开源用于创新、集成用于合规。

最后隆重介绍三位大神,yoda,向阳,来源。如果想体验可观测性原力,可以找yoda大神,下面的二维码是免费的DeepFlow Cloud SaaS服务。
 06
如果想学习开源可观测性,可以看看我们下一次直播,由云杉研发VP,向阳博士主讲。向阳头像下面的二维码是我们的直播通道。
如果想落地可观测性项目,找我们COO来源最合适,他会在春节后的直播中给大家带来详细的解决方案介绍。如果需要提前了解解决方案,可以扫描来源头像下的二维码,那是我们的官方微信公众号。
 
谢谢大家,今天分享就到这里,欢迎大家提问交流。
点击【此链接】即可看直播回放!!

Related Posts

「直播回看」MetaFlow:开源的高度自动化可观测性平台

今天非常高兴能给大家带来一个好消息,云杉网络正式宣布开源MetaFlow,一个高度自动化的可观测性平台。这是云杉网络从2016年以来,商业化产品DeepFlow从云网络发展到云原生应用持续积累的结果。MetaFlow包含了我们在可观测性建设中核心的关键技术,今天正式开源并共享给社区,为可观测性发展共同建设出一份力,同时也向世界领先的目标往前迈进一步。

Read More

MetaFlow即将开源!5月11日“让观测更自动,让开发者更自由”

基于在混合云环境下的多年耕耘,云杉网络自主研发的云监控服务平台DeepFlow已在金融、电信、能源等行业中的数十家世界五百强客户处得到了广泛的应用。我们宣布将DeepFlow核心的可观测性数据引擎MetaFlow正式开源(5月11日揭晓),我们希望将更好的可观测性能力、自动追踪和自动标签能力开放到整个行业,帮助企业客户改进云原生运维工作的运行效率、稳定性和计算成本。

Read More