问答合集|“原力释放 云原生可观测性分享会”

云原生应用可观测性实践——云杉网络 研发VP 向阳预热期

问答整理

Q:1.中小企业没有那么大的开发能力,应该如何将这些数据打通?
A:开源可考虑比如 Grafana 和 Tempo、Loki,比如 OpenTelemetry,这些能力社区已经在做了。推荐 DeepFlow,无论是公有云还是私有云,不用再去构建一套观测基础设施,不用耗费时间维护。


Q:2.请问这个 ClickHouse 性能(300x)是怎么做到的?
A:最早我们用 ES,后来改到 InfluxDB 发现指标数据性能 3x,主要得益于它在时间维度(TSM)的优化。后来遇到读写瓶颈和高基问题后我们在 InfluxDB 上做了二次开发,相比开源 InfluxDB 有 10x 提升,主要得益于我们深入到 Golang 语言级别的各种苛刻优化,比如对 Golang 原生的 map 性能优化 10x、原生的 pool 性能优化 10x。再到后来我们发现基于 InfluxDB 做 “优化” 不能根本上解决高基问题,切换到 ClickHouse 后我们发现性能有有了至少 10x 提升(总共 3x10x10x=300x)。稍微总结下主要得益于 CK 的稀疏索引和数据压缩。俄罗斯人优化能力强。


Q:3.eBPF 对 cpu 的开销如何?
A:BPF 生产数据较多,5% 上下的影响。eBPF 目前没有较多的生产数据,但实验数据表明也是 5% 上下。作为一个对比,我们从侧面了解到 APM(Java Agent)有时候可能达到 20% 左右(没有实测过)。


Q:4.若使用 eBPF 采集,因为比较底层,采集的数据量级会很大,全量采集吗?还是指定特征?怎么对数据作压缩?对宿主机的性能影响如何?占用多少 CPU?
A:eBPF 采集有两种模式,一种是可以把每一个 API 的请求头和响应头都拿出来,就像 HTTP 请求的 header 和响应的 header,但不要 body,这个量级比较大,需要比较大的管道(perf event)传送出来。另一种是 Map 的方式,在内核里已经算好了,算好的这个数据再吐上来,数据量会非常小。我们两种都有。可观测性的基础是数据勿采样,可参考《可观测性宣言》


Q:5.采集的数据如何与 tracing/metrics/logging 关联起来呢?
A:主要用 Tag。虽然 OT 社区用一些 exemplars 等方法,但并不直接,最主要其实还是用 Tag,比如说我们通过 Tag 过滤以后,假如发现告警,我们能精确到一分钟或者一秒,再去看 Tracing 和 Logging 时,我们用 Tag 筛选出来的实际上已经很精确了。


Q:6.公有云的 VM,如何在宿主机上部署?
A:私有云在宿主机上部署,公有云直接在虚拟机上部署。


Q:7.有了 DeepFlow 还需要类似 skywalking、prometheus 吗?
A:目前 DeepFlow 没有覆盖 Prometheus 的资源监控能力,也没有覆盖 Skywalking 的插码 Tracing 能力。DeepFlow 可以与 Prometheus 结合形成全栈指标监控能力共同展示于 Grafana Dashboard 中,可以与 Skywalking 结合形成全栈链路追踪能力共同展示于 Skywalking GUI 中。


Q:8.TraceID 是如何打的?是用 ebpf 吗?
A:TraceID 是 APM 打的,DeepFlow 只做关联。另外我们在做用 eBPF 做调用链追踪,且不用打 TraceID,完全无侵入。


Q:9.引入类似 deepflow 的可观察性整体平台方案如何与企业已经存在的运维系统相结合使用?譬如运维自动化系统、CMDB 等等。
A:这个是更大的一个范畴,我今天分享的主要是数据的采集、存储和检索。这更大的一个范畴,我们下次有机会再进行讨论。


IT系统为什么需要可观测性——云杉网络 创始人&CEO 亓亚烜第一期

问答整理

Q:1.  现在IT系统运维中AIOps的概念也很火热,那么可观测性和AIOps之间的关系是什么呢?
A:首先,我觉得这个问题非常好,AIOps是要解决问题的,而可观测性是要收集数据。所以可观测性是基础,AIOps应该架构在可观测性之上。


Q:2.  如何把tracing、metrics、logging打通?
A:这块我觉得最好的答案在Peter Bourgon的blog里边,这个blog并不长,我建议大家可以去仔细阅读一下。这个不仅仅是把这三个数据打通的问题,这三种数据在不同的场景下使用,每一种数据还会有不同的处理方法。所以,其实对于不同的数据结构要采用实时数仓来做,那么实时数仓对不同的数据就会用不同的处理方式,最终的效果就是不管在什么场景、存储什么样的数据、有什么目的,都能实时的读、存、写下去。


Q:3.  中小企业没有那么大的开发能力,如何搭建自己的可观测设施?
A:我觉得如果是中小企业没有开发能力的话, 那么最直接的就是用SaaS平台,这是没有错的。但是只用SaaS平台也存在一些问题,就像刚才所说的,它其实没法推动飞轮的转动。所以用SaaS用到一定到程度以后,大家熟悉了可观测性之后,中小企业也会发展,那么在持续的发展中,应该可以找到更强的开发能力,这里是指演进出更强的开发能力。自然也就可以用起开源,那么当开源用到一定程度的时候,中小企业也就更理解了原理、更理解了自身需求,那么自然也就可以上升到集成。为什么这么说呢,因为未来中小企业想要长期的发展,开发能力是必须具备的。所以,回到开头所说的,不能仅依赖SaaS,而是做到SaaS-开源-集成,形成一个飞轮效应。


Q:4.  高质量、细粒度的可观测性数据量级会很大,计算和存储相关的成本也会很高,如何解决?
A:这个在直播中也提到了,类似云可观测中的摩尔定律吧。这个摩尔定律就是说底层的数据能力每18个月要提升10倍,来满足这样的需求(低成本)。如果没有这样的10倍提升,那么我们不可能解决这个问题。所以作为一个做可观测性底层技术的公司,我们在这里,最首要满足的就是这样的发展速度,来解决诸如这样需求(低成本)的问题。


开启愉悦时刻!DeepFlow可观测性方案实践及开放合作——云杉网络 联合创始人&COO 来源第二期

问答整理

Q:1.  云杉产品部署要求及支持系统中间件等列表?
A:控制器:8核64G内存,600G存储空间,支持虚拟机部署;数据节点:8核64G内存,1T存储空间,支持虚拟机部署;采集器:可配置,1核CPU,1G内存,100M存储空间;可采集器系统:操作系统服务商或社区对外提供服务期限内的各类操作系统。


Q:2.  云杉产品有哪些服务模式?怎么销售?
A:主要分为公有云和私有云,包括软件授权以及订阅模式两种方式。


Q:3.  云杉产品监控的原理是什么?
A:如可观测理论所陈述,通过系统外部输出判断内部状态。观测数据包括网络、系统、应用等多维度观测数据,关联平台信息、事件。通过平台交互,有效判断系统整体(应用、系统、Infra)状态,解决运维排障、性能分析、容量评估以及调用追踪等问题。


Q:4.  零侵入是怎么做到的?
A:零侵入有几个方面,不侵入业务系统获取网络观测数据、不侵入应用代码获取应用观测数据,不侵入云平台获取云、容器平台信息。


Q:5.  采集器对部署环境 比如操作系统版本有什么要求?
A:采集器对系统资源的最低要求是1核CPU,1G内存,100M存储空间,关于操作系统版本,只要该系统版本还在服务商或社区对外提供服务的期限内,我们均兼容。


Q:6.  基于网络的无侵入式追踪是如何实现的?是否要对协议进行逐一解析?
A:如直播中所陈述,可以通过TraceID、SpanID、URL等进行追踪,在步明确的情况下,可以通过多维数据的关联进行推导,包括网络流,应用协议日志,采集器位置信息等。


Q:7.  中间件如mysql的metric、trace、logs如何采集,在deepflow中如何做关联的?所有中间的可观测性数据都存在一个数据库吗?
A:通过BPF采集流量中的MySQL报文,提取Metrics和Log;通过eBPF采集MySQL请求的系统调用,提取并关联Trace,观测数据存在ClickHouse中。


Q:8.  需要在车端安装采集agent吗?
A:如果覆盖云-边-(车)端,是需要在车载主机上部署采集器。


Q:9.  NPB方案是如何保障流量质量的?比如去重、减少丢包。
A:主要是有控制器全局控制来保证。


Q:10.  采集的数据是否遵循open telemetry协议,如果使用Prometheus export采集如何做到遵循open telemetry协议要求带着span id这些字段?
A:DeepFlow核心引擎即将开源,将会借助社区力量适配OTLP协议,并广泛支持Prometheus Exporter、StatsD等数据获取方式。通过BPF/eBPF可以将Metrics与SpanID关联。


Q:11.  从云杉产品根本上能够解决哪些行业的哪些问题?
A:面向各行业,只要是采用云化建设、对东西向流量、微服务应用有可观测行要求的用户都是云杉产品应对场景。通过“黑盒”可视化,可以为用户提供包括黄金指标展示、流量分析、全链路追踪、历史回溯、快速定位故障点和定界定则等,帮助用户解决网络、应用监控盲区所带来的一系列问题,尤其是性能问题。


Q:12.  云杉产品相比于其他产品来讲有何优势?
A:最大的优势就是面向云及微服务应用来解决问题。


构建统一的云原生应用可观测性数据平台——云杉网络 研发VP 向阳第三期

问答整理

Q:1. 对于云原生应用的监控,最大的痛点一般是什么?
A:1)数据孤岛:不同数据源的数据之间无法关联,难以使用;2)数据低维:由于标签维度少,无法进行细粒度的分组和下钻,可观测性低;3)数据猖獗:大量数据难以存储,开发者通常要面临采样的选择,也时长会遇到高基标签困扰。


Q:2. 是否会形成通用的标签框架,方便第三方进行使用适配呢?
A:DeepFlow内核即将开源,包含AutoTagging、MultistageCodec以及基于eBPF的AutoTracing能力,但目前没有计划将标签体系独立。我们也希望发掘标签体系的更多用途,若能用于更多场景,我们会推进这部分组件的独立,成为一个通用解决方案。


Q:3. 监控数据注入标签是侵入式的吗? 怎么保证不影响原有业务?
A:非侵入。DeepFlow自身从BPF/eBPF获取数据,然后向数据中插入标签。另外通过接收Telegraf、SkyWalking数据,也可根据IP/进程名/主机名像数据中追加标签。不管哪种方式都是零侵扰的,目的是消除开发者手动注入标签的负担。


Q:4. 反映应用健康度的指标有哪些?
A:我们常说的RED(Request、Error、Delay)是经典的指标,除此之外还有例如Apdex是从时延视角的健康度评估。


Q:5. 云原生监控在微服务治理中的作用?
A:微服务拆分后最大的挑战是分布式链路追踪,其次是微服务运行环境中追踪、指标、日志数据的关联。提升应用的可观测性是治理微服务的必要措施。


Q:6. 传统apm和k8s监控如何衔接?
A:我们几乎可将K8s等同于云原生应用环境,云原生的必要条件之一是可观测性建设,APM因作为可观测性建设的一部分,通过数据汇总关联,形成统一的可观测性数据平台。


Q:7. 过nat场景中,如何识别变换后的前后ip,如何绘制过nat的端到端的路径?
A:DeepFlow支持追踪SNAT、DNAT、FULLNAT等场景,关联NAT前后的应用请求,这个能力也将会在我们即将开源的内核组件中,对追踪机制的介绍我们在五月份的Qcon北京有一个专题分享,欢迎关注。


Q:8. 这里讲的统一可观测性平台,能否整合其他开源工具数据?
A:实际上整合数据是可观测性建设的必要条件。我们的产品也在逐步迭代支持中。任何孤立工作的数据源组件、或者号称以采集“所有”数据为目的重新造轮子的项目都是不切实际的。数据已经存在,缺乏的是关联和打通。


Q:9. 标签编码能否针对数据模型进行进一步优化?
A:实际上DeepFlow对K8s自定义标签的处理就是一个优化,这部分标签并没有随监控数据存储到ClickHouse中,而是基于一个贪心策略的编码,在查询策略生效,成倍的降低了存储开销。另外我们也可通过精心选择CK中标签字段的类型和压缩方法来进一步优化。


Q:10. 可观测性:已有monitoring,tracing,logging 三套系统如何打通?有没有多合一的?
A:为不同数据源的数据自动插入统一的资源和服务标签。


Q:11. 多系统之间链路跟踪如何实现?
A:基础设施服务(例如K8s、APIGW、DB等)利用eBPF实现全局的自动追踪能力,不同的业务系统由各自的研发团队决定使用应用代码内的链路追踪方案,最后再由可观测性平台将自动追踪数据和应用代码的追踪数据融合。


Q:12. 一体化监控如何做到数据统一集成和展示?
A:采集侧适配通用的数据采集协议,例如StatsD、OpenTelemetry等;存储侧做好数据关联。

上能够解决哪些行业的哪些问题?
A:面向各行业,只要是采用云化建设、对东西向流量、微服务应用有可观测行要求的用户都是云杉产品应对场景。通过“黑盒”可视化,可以为用户提供包括黄金指标展示、流量分析、全链路追踪、历史回溯、快速定位故障点和定界定则等,帮助用户解决网络、应用监控盲区所带来的一系列问题,尤其是性能问题。


Q:12.  云杉产品相比于其他产品来讲有何优势?
A:最大的优势就是面向云及微服务应用来解决问题。


星火燎原-DeepFlow漫谈之技术、场景、方案——云杉网络 售前经理 冀佳鹏第四期

问答整理

Q:1. 怎么衡量云原生可观测性?有哪些指标?
A:可观测的指标只要分成三大类:metrics、tracing、logging,构建一个云原生可观测性系统,三个模块是缺一不可的,另外更需要关注的是三类数据之间的关联和追踪。


Q:2. 云原生可观测性如何运用到传统行业中?
A:传统行业也是需要可观测性技术的,具体的实现方案应该从自身的基础设施架构出发,比如包含哪些云资源池,包括哪些IT架构上的关键要素,结合实际给出具体的方案建议,如果需要更加详细的方案建议,请咨询云杉技术服务热线~400-9696-121#2


Q:3. 云原生可观测可以用于哪些场景?
A:云原生可观测性可以应用于众多行业的场景中,比如:金融行业的云数据中心、运营商的IT云、边缘云以及4G、5G核心网的场景中、还可以应用在公有云的业务保障,也可以向车联网(云、网、边、端)的场景以及其他的IOT、工业互联网的场景中去推广。


Q:4. 采集数据对网络带宽的消耗如何把控?
A:在宿主机、容器环境中采集到的流量数据包、通过采集器计算成指标数据、流量日志数据,追踪数据,再发送到后端,再加上eBPF这部分数据源,整体对于带宽的消耗大概是业务带宽的千分之一到百分之一的消耗。


Q:5. k8s流量采集如何做流量控制?
A:在k8s环境中,流量采集器作为daemonSet类型的POD运行在每一个容器Node节点上,不需要进行Sidecar,不需要去做流量的控制和路径的改变。


Q:6. 传统监控与可观测性是什么关系?又有什么区别?
A:传统监控可以认为是可观测性整个技术图谱中的重要组成,他们在不同的位置上解决着不同的可观测性需求,但是要建设一个完整的可观测性系统,需要不同工具、产品之间的开放,兼容和关联。


Q:7. 云杉产品会不会对客户业务系统有影响,怎么规避风险?
A:云杉的采集器是运行于资源池内的无侵扰的技术体现,对于客户业务系统本身没有任何的影响。


Q:8. DeepFlow采集器输出的telemetry数据,这些数据怎么能让其他的数据处理系统进行消费呢?
A:DeepFlow采集器采集输出的telemetry数据支持对其他工具或平台的消费使用,主要包括两个方面:1、原始数据包,采集器具备流量数据包分发能力,支持按照流量消费端的需求将捕获的原始数据包进行一系列的过滤、去重、压缩、截断、标记等预处理后发送到其他平台;2、指标数据,DeepFlow平台支持API或者消息队列的方式,可由其他工具来DeepFlow的实时数仓调取指标监控数据。


Q:9. 云杉的这种算子前置的模式和其他一些探针只采集再通过中间层做数据处理的方案有什么优势或劣势?
A:DeepFLow采集器的指标计算能力,使得传输带宽有一个极低的消耗,这是能去广泛的部署在云资源池的基本条件。在云内的特殊的通信场景和复杂的链路,比如云资源池内部有不同的租户、不同的VPC,不同VPC里面的数据通信VPC网关,不同区域的资源互访也需要经过不同的网关,也就是说流量采集探针如果只做一个引流动作的话,那么位于不同位置、不同区域的采集器把流量牵引出来,会导致所有的虚拟网关的流量压力至少增长一倍。


Q:10. 云杉在采集端就进行指标计算处理的这种工作模式对资源的消耗如何?
A:以KVM环境为例,单个宿主机中部署一个流量采集器软件,需要的资源上限是1vC\1G内存,可以处理10Gbps大小的流量数据。


Q:11. DeepFlow可以私有化部署吗?安防场景适用吗?
A:DeepFlow支持私有化部署,在安防场景中可以考虑中心云安防应用的监控分析——边缘云节点的性能分析——安防端点上的性能分析,对于视频质量、传输性能、中心应用等方面进行监控。


MetaFlow:开源的高度自动化可观测性平台——云杉网络 研发VP 向阳第五期

问答整理

Q:1. MetaFlow是什么系统?只用在AI框架的Tracing上吗?考虑转型较通用的数据存储和处理的系统吗?
A:MetaFlow是通用的高度自动化的可观测性平台,通过eBPF/BPF采集Request-scoped Trace/Metrics/Log数据,并能集成其他开源Trace/Metrics/Log数据源。


Q:2. MetaFlow对不同操作系统的支持程度如何,比如对Linux内核版本是否有要求? Windows 是否支持?低版本的内核不支持eBPF,或者对eBPF支持不好,对数据采集多大影响?
A:eBPF AutoTracing支持Linux 4.14+,BPF AutoMetrics支持Linux 2.6+、Windows 2008+。低版本内核下缺乏eBPF的AutoTracing能力,但支持集成OpenTelemetry的Tracing数据。


Q:3. MetaFlow与OpenTelemetry 的追踪有什么差异?
A:MetaFlow通过eBPF提供应用代码、系统函数调用、数据库、消息队列、L4/L7网关、网卡流量的全链路追踪能力,OpenTelemetry聚焦于提供应用代码内部的追踪能力。MetaFlow通过自动关联eBPF和OTel数据能实现无盲点的全链路追踪。


Q:4. 我们的业务一条链路下来大概有几十个服务,各种语言都有,可以无侵入的对这些服务做追踪吗?
A:MetaFlow AutoTracing目前能自动追踪多线程并发编程下的同步调用,同时也在积极探索协程、异步调用场景下的自动追踪能力。除此之外也能自动关联OTel Span、HTTP Header中的X-Request-ID等。欢迎届时试用。


Q:5. 三合一的数据是统一存储的吗?
A:默认提供ClickHouse统一存储,可以扩展存储数据库使得不同数据存不同库,向上统一提供SQL查询能力。


Q:6. 为什么选择Rust来开发Agent? 该开发语言的选择对维持开源生态有什么影响?
A:不同于Telegraf/Prometheus只会定时拉取聚合数据,MetaFlow无采样的采集每一个应用请求和网络通信,Rust能提供更为优秀的采集性能。MetaFlow目前已支持运行在智能汽车操作系统中,未来还会逐步支持运行在Serverless Pod、IoT设备等资源敏感的环境中,Rust的低内存消耗也是一大优势。此外Rust的绝对内存安全性对于采集软件来讲同样非常重要。


Q:7. MetaFlow对私有云数据中心环境部署有什么要求?如何突破虚拟化的性能瓶颈的?或者性能瓶颈的数据展示?
A:MetaFlow Agent支持运行于K8s Node、虚拟机、物理机内,Linux 2.6+或Windows 2008+,MetaFlow Server支持运行于K8s中。Agent使用Rust实现,性能开销约为1%~5%;Server使用Golang实现,结合SmartEncoding特性,资源消耗不到业务的1%。


Q:8. MetaFlow是否能绘制函数调用关系图、或者抓取各个对象的内存占用?MetaFlow是不是更像是适用于全语言的Profile工具?是不是类似于春哥的XRay工具?
A:Continue Profile在MetaFlow的特性规划中。但MetaFlow不是一个Profile工具,它是面向云原生分布式业务系统的可观测性平台,提供全栈、全链路的AutoMetrics、AutoTracing能力。


Q:9. MetaFlow解决什么问题?将来的发展方向是什么?
A:MetaFlow解决云原生应用的可观测性问题,MetaFlow的愿景是成为世界级的可观测性平台,成为云原生应用开发者的首选。


Q:10. 怎么加入MetaFlow开源阵营?对于企业或个人开发者加入并贡献开源,有什么建议?
A:MetaFlow使用Apache 2.0 License,代码托管在Github上 https://github.com/metaflowys/ ,欢迎贡献。


Q:11. MetaFlow跟DeepFlow有哪些区别?有什么功能是DeepFlow支持但是MetaFlow不支持的?
A:MetaFlow面向开发者,构建业务团队自己的可观测性平台,聚焦应用性能监控。DeepFlow面向企业IT团队,具备企业级的稳定性和高可用性,提供多租户、多厂商设备等额外的管理功能,并提供云杉的专业技术服务支持。


Q:12. MetaFlow和现有的可观测性方案相比有什么优势或特点?
A:全栈、全链路、高性能是MetaFlow的关键特性,高度自动化是MetaFlow的主要特定。我们希望让观测更自动,使命是让开发者更自由,自由选择开发语言和框架,而不用受到可观测性建设的束缚。


Q:13. MetaFlow支持iOS、Android、Web监控数据关联吗,真正做到端到端关联?
A:支持Andriod、集成Sentry支持Web监控都在MetaFlow的特性规划中。


Q:14. 如果是一个封装后的私有协议,是否能够追踪到基于私有协议的链路?
A:MetaFlow将会开发基于WASM的可编程能力,用于私有协议解析。


Q:15. 目前.NET Core 是否支持呢?
A:支持。


Q:16. MetaFlow是否可以对接 SkyWalking 、Grafana等其他开源工具?
A:MetaFlow首个版本即支持Grafana,并在规划对接SkyWalking数据。


Q:17. MetaFlow与Istio服务网格定位有什么区别吗?
A:MetaFlow是通用的可观测性平台,Istio是服务网格平台。


5GC与电信云构建云网络可观测性平台的必要性——云杉网络 解决方案专家 李飞第六期

问答整理

Q:1. DeepFlow的云网络可观测性与运营商现在的DPI分析有什么关联关系?
A:在运营商的5G核心网系统中有用户面DPI分析UPF用户面流量,有5G信令面DPI分析核心网信令面流量。用户面DPI解决面向5G用户业务质量的网络可观测性;而5G信令面DPI实现的是VNF网元间SBI口的网络可观测性、应用可观测性。SBI口的流量可能只占1%,支撑VNF网元运行的是VNF内部的大量微服务的互访流量,可能是整个5G核心网VNF流量的99%,所以势必要构建对VNF内部复杂云网络的可观测性,才能保障VNF的可靠运行。


Q:2. 在网络云中部署软探针,是否会影响5GC软件的运行稳定性?5GC厂商是否会排斥?
A:软探针是以独立的采集进程运行在Hypervisor操作系统中,以独立DaemonSet POD运行在容器Node内,不侵入业务VM、业务POD,与5GC软件天然的隔离,因此不会影响5GC软件运行。从技术角度分析,对于有高可靠性要求的云、云原生大型业务系统,可观测性技术一定是业务保障的一个关键环节,随着CT与IT技术的不断深入融合,我们相信5GC的CT厂商未来一定是会拥抱、接受可观测性。


Q:3. 5G核心网和4G核心网对于可观测性的监控重点有什么区别?
A:对应4G核心网来说,已经实现了虚拟化,但还没有容器化,现阶段通过传统的网元网管能力还是基本可以保障运行可靠性,但5G核心网的容器化导致运维的跨层定界定位、团队协作等矛盾开始突出,所以对云网络的可观测性的需求更加迫切。


Q:4. 云网络可观测性平台与其他云原生应用的可观测性平台有什么区别?从云平台角度是否可以构建统一可观测性平台?
A:DeepFlow实现的是网络+应用的全栈、端到端可观测,常见的云原生应用可观测性平台更多的是面向于应用,对于5G核心网运维中遇到的跨层定界/定位问题、云网络中的丢包/时延问题,以应用的可观测性是无法解决的。关于是否通过云平台来构建统一的可观测性在云和运维的产业界已得到了结论,如果希望通过云平台来实现一个大而全的能力平台,就会发现云平台功能需求越来越多,平台负担越来越重,最后什么都在做什么都做不好。


Q:5. BOM三域有融合的趋势,该公司的产品主要是网络流量侧的监控能力,而针对具体系统业务的运维粒度能达到什么程度?
A:DeepFlow的可观测性数据获取能力不仅仅包括网络流量,还包括进程函数调用、系统函数调用等应用数据,而且这种采集粒度是细微到任意一次应用请求,已经实现全面的网络可观测性、应用可观测性。


Q:6. DeepFlow部署是天然适配不同的云厂商吗?
A:DeepFlow的可观测性数据获取能力不依赖开发语言,不依赖厂商,更多的是通过操作系统的通用能力来采集获取数据,所以对云厂商天然适配。当然DeepFlow还是需要与云平台的API通过兼容性对接动态获取感知云网络资源、网络实时变化情况。


Q:7. DeepFlow的云网络可观测性与智能运维、网络自动驾驶有什么关联关系?
A:自动化与可观测性是一种相辅相生的对偶关系,没有网络的可观测性就没有网络自动驾驶。对于智能运维来说,核心概念是AI,而AI的三要素包括数据、算法、算力,商业宣传上大家都在谈论的是算法,而实际上数据是AI的基础,没有全面、高质量、海量的数据,AI就变成了无根之木,而经过我们分析和技术解读可以看到现阶段5G核心网运维的最大问题在于网络可观测的数据缺失,只有解决了这个基础问题,才能谈论算法和算力的问题。


……持续更新中……

“云原生可观测性分享会”将持续为大家呈现精彩(每月不定期开播)。您可以通过扫描下方二维码加入直播群(添加时请备注011),了解更多详情。

%e7%9b%b4%e6%92%ad%e7%b3%bb%e5%88%97-%e5%85%a5%e7%be%a4-%e6%88%91%e7%9a%84%e4%bc%81%e4%b8%9a%e5%be%ae%e4%bf%a1%e4%ba%8c%e7%bb%b4%e7%a0%81

Related Posts

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

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

Read More

直播回看|开启愉悦时刻!DeepFlow可观测性方案实践及开放合作

“云原生可观测性分享会”第二期《DeepFlow可观测性方案实践及开放合作》由云杉网络COO来源演讲,分享了云原生、车联网、容器化微服务3个实战用例,以及客户同学的愉悦时刻。以此帮助大家进一步的了解可观测性,以及可观测性可以解决的实际问题。

Read More