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

云原生应用可观测性实践——云杉网络 研发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核心网运维的最大问题在于网络可观测的数据缺失，只有解决了这个基础问题，才能谈论算法和算力的问题。

---

高清云网可观测之全链路追踪实战——云杉网络 高级产品经理 李倩｜第七期

问答整理

Q：1. 与各种抓包工具比，DeepFlow全链路追踪的优势是什么？
A：云网的流量会通过各种隧道协议来传输，又要穿越各种虚拟交换机和NFV网关，NAT也是常态，如果靠人工抓包，抓包点多、流量大、各个抓包点的包关联困难，DeepFlow全链路追踪能力可以完成自动的隧道拆解，智能化的NAT流量追踪，全栈网络路径关联，结合指标可以加速定位问题的时效。

---

Q：2. 针对前端是HTTPS业务，DeepFlow如何追踪，与HTTP业务有哪些区别？
A：DeepFlow支持通过eBPF采集HTTPS流量，后续关于应用调用链追踪的直播会详细分享。

---

Q：3. 平台如何跟踪TCP层的故障问题？
A：使用DeepFlow全链路追踪能力。

---

Q：4. 如何实现通过TraceID将各段的span 连起来，而不是一个个孤立的span，也就是说是由谁在哪个阶段都过什么方式打的TraceID？
A：本次分享主要聚焦在网络追踪，给定两个服务追踪中间的网络路径、NAT转换、逐条流日志、逐个网包。您指的应该是应用调用链追踪，这方面DeepFlow是通过eBPF能自动计算出一个TraceID，并结合OTel注入的TraceID实现无缝链路追踪。

---

Q：5. 容器化场景Agent存在模式只在宿主机部署？容器镜像是否需要特殊设置？
A：DeepFlow的Agent提供非常多的部署版本，可兼容多种操作系统，支持部署在宿主机、虚拟机、容器节点上，其中在容器节点上以Daemonset的形式部署。

---

Q：6. DeepFlow全链路追踪所需要的数据全部是由Agent采集的吗? 还是由多个组件整合而来？
A：全部由Agent采集。

---

Q：7. 网络追踪如何与APM的Tracing联系起来？
A：通过TraceID和SpanID关联。

---

Q：8. DeepFlow是否能梳理服务依赖以及怎么判定依赖的合理性？
A：DeepFlow可通过全景流量拓扑以业务零侵扰的方式自动的梳理服务的依赖，基于流量的依赖展现是真实通信场景的反映。

---

Q：9. 目前云杉网络在可观测性对三大支柱数据如何做融合？实现了哪些场景？
A：三大支柱数据在DeepFlow产品分为应用和网络两个方向来融合，其中网络全链路追踪方面就是融合指标、NAT追踪、流日志、TCP时序图、PCAP数据的一个场景。

---

DeepFlow —— 开启高度自动化的可观测性新时代——云杉网络 研发VP 向阳｜第八期

问答整理

Q：1. DeepFlow和Weave Scope的区别是什么？
A：DeepFlow的优势在于：DeepFlow在实现AutoTagging的同时基于SmartEncoding机制将资源消耗降低了一个数量级，未见Weave Scope有此种程度的优化；DeepFlow拥有全栈指标能力，能够快速精细的定位Pod间、Pod内的故障或瓶颈点，未见Weave Scope有此精细的观测能力；DeepFlow拥有自动化、无盲点的分布式追踪能力，这是独创能力；DeepFlow拥抱开源社区，信仰可观测性应该对数据能采则采，拥有强大的数据集成能力；DeepFlow支持非容器场景的监控、支持云资源的标签注入，Weave Scope仅聚焦容器。

---

Q：2. 为什么DeepFlow不考虑造个轮子，做个all-in-one的agent？
A：DeepFlow拥抱开源社区，Prometheus、Telegraf已经积累了成败上千个组件的数据采集能力，不必要重复造个轮子。

---

Q：3. 为什么prometheus-server需要将数据发送给deepflow-agent，而不是deepflow-server？
A：deepflow-agent支持由deepflow-server控制实现负载均摊和故障切换，在多K8s集群场景下无需任何外部组件依赖。prometheus-server发送给deepflow-agent将会天然具备这样的能力。

---

Q：4. 指标数量很大，Prometheus性能是否存在瓶颈，有没有其他可替代品？
A：社区有很多Prometheus的Remote Storage解决方案，DeepFlow也希望做为Prometheus的Remote Storage，除了SmartEncoding的高性能以外，还会带来独一无二的AutoTagging能力，告别数据孤岛。

---

Q：5. 针对Service Mesh 架构的流量采集有什么难点，与K8s采集上有什么区别？
A：Service Mesh架构下流量路径更为复杂，可观测性需要具备全栈、全链路、无盲点的采集和关联能力。

---

Q：6. 使用MySQL做分析数据的存储库，会有容量限制吗，历史数据最多可以保存多久？
A：MySQL不适合实时分析场景。DeepFlow默认使用ClickHouse。

---

Q：7. DeepFlow对于KVM\vSphere\容器等平台，哪种更有优势？
A：DeepFlow企业版支持宿主机流量采集，能与云服务器、K8s上采集到的数据自动关联，将全栈、全景、全链路发挥到极致。

---

Q：8. DeepFlow和联邦式的Prometheus怎么结合？
A：DeepFlow作为Prometheus的Remote Storage，不改变Prometheus现有使用方式。

---

Q：9. DeepFlow的数据怎么与prometheus的数据关联起来的？
A：通过AutoTagging自动注入数据标签进行关联。

---

DeepFlow AutoLogging：自动采集应用调用日志和流日志——云杉网络 产品专家 李倩｜第九期

问答整理

Q：1. DeepFlow的调用日志和应用自身的日志有什么区别？
A：调用日志为各种协议请求的详情，例如Nginx的access Log，MySQL的general log/error log这些都是调用日志的范畴，DeepFlow的应用调用日志是给Dev团队建设的一个站在应用视角快速查看所有的调用日志的一个能力。

---

Q：2. DeepFlow自动采集怎么样定义的？
A：无需应用增加代码，也无需去协调集中接入各个组件的调用日志，DeepFlow基于BPF/eBPF自动完成调用日志和流日志的采集。

---

Q：3. 对采集的日志，DeepFlow 有提供什么聚合分析能力吗？
A：有，调用日志进行统一抽象处理后，则拥有了聚合分析的能力，比如查看微服务的调用关系，比如对请求资源分组查看RED指标量等等。

---

Q：4. 请问DeepFlow这些slowlog持久化是如何设计的？看图像是grafana直接从数据库读取的？
A：数据存储在ClickHouse上。

---

Q：5. 大量生产环境，且非容器化云原生场景，如物理机或虚拟机，是如何支持的？
A：DeepFlow的agent可以支持跑在物理机或虚拟机。

---

Q：6. DeepFlow应用调用日志和流日志如何自动关联，是否有内置的排障场景？比如某些故障可以快速给出根因结果？
A：应用调用日志与流日志通过FlowID进行关联，目前没有内置的排障场景。

---

Q：7. 内核版本不够的场景下，如受限于eBPF等的支持情况，DeepFlow是如何实现的？
A：● 网络流日志的采集，目前是通过BPF来实现的，因此不支持eBPF内核版本功能是不受影响的；
● 应用调用日志，数据来源包含网络层面的应用协议，系统层面的应用协议，分布式链路追踪的Tracing数据，其中仅系统层面的应用协议依赖eBPF，因此在不支持eBPF的内核版本里面，仅是少了系统层面的调用日志。

---

Q：8. 是否可以提供一个应用调用日志的协议扩展的详细用户指南，方便开发人员贡献协议插件？
A：会尽快给社区提供一个用户贡献指南。

---

Q：9. uprobe 采集会有性能问题，同时针对于类似低延时redis 的数据采集也有性能问题，这块有评估？
A：● DeepFlow使用tracepoints来采集Redis的调用日志和追踪数据，不需要使用uprobe
● 性能这部分，后续会将自动化测试的代码推到GitHub上，周期性来跑性能测试，欢迎持续关注

---

DeepFlow 在 Kube-OVN 环境的可观测实践——宋建昌 云杉网络 云原生工程师｜第十期

问答整理

Q：1. DeepFlow Sever 是否考虑支持传统 Host 部署？

A：不支持传统 Host，在部署 DeepFlow 的这个场景中，使用 K8s 部署可以屏蔽掉很多底层环境的差异等问题，以及 K8s 的横行扩容等优势都是传统 Host 方案没有的，我们DeepFlow 目前也在积极的推进外部 clickhouse、deepflow-app 合入 deepflow-server、deepflow-server 演变为 deployment 等，以及已经支持的外部 MySQL、自建 Grafana 等让 DeepFlow 的部署越来越轻量、简单，在传统 host 上可以通过 sealos 等工具快速拉起来一个或多个节点的 K8s 集群来部署 DeepFlow。

---

Q：2. DeepFlow 都支持解析协议，关于协议解析上未来有什么计划？
A：DeepFlow目前支持解析的应用层协议：HTTP 1/2/S、Dubbo、MySQL、Redis、Kafka、DNS、MQTT。正在做协议解析相关逻辑抽象和协议贡献文档，有协议解析需求的可以通过 PR、issue 的方式参与进来。

---

Q：3. DeepFlow支持国产化架构吗？比如飞腾+银河麒麟系统？
A：目前我们的 deepflow-agent 正在做 eBPF 的 arm64 适配工作，除 deepflow-agent 外其他组件可以随时打出 arm64 架构的镜像，预计最近一两个版本就会支持。

关于操作系统方面，DeepFlow 通过 K8s 进行部署，不关心底层操作系统，K8s 在国产系统的适配工具可以交给 sealos 等 K8s 部署工具来支持

---

Q：4. DeepFlow 目前适配哪些 CNI ？
A：下面是我们默认适配的CNI：Flannel、Calico、Cilium、Multus、Open vSwitch、Weave、IPVlan、TKE GlobalRouter、TKE VPC-CNI、ACK Terway、QKE HostNIC、kube-OVN。一般的 CNI 都可以通过修改 agent 的 tap_interface_regex 配置项将容器节点的物理网卡及容器内 eth0 网卡在节点的 veth-peer 网卡名称覆盖即可，有其他 CNI 也可通过提交 issues 来进行参与。

---

Q：5. Prometheus、Istio 的 Jaeger 也有网络指标，DeepFlow 和 Prometheus Istio 的有什么不同吗？
A：Prometheus的网络指标非常基础，Istio的网络指标相比于DeepFlow也很粗糙，以及DeepFlow 的数据有大量的标准化 Tag，对 Prometheus、Istio 的网络指标有很大的增强。

这里可以查看所有 DeepFlow 支持的网络性能指标：https://github.com/deepflowys/deepflow/blob/main/server/querier/db_descriptions/clickhouse/metrics/flow_metrics/vtap_flow_port

以及所有支持的应用性能指标：https://github.com/deepflowys/deepflow/blob/main/server/querier/db_descriptions/clickhouse/metrics/flow_metrics/vtap_app_port

---

Q：6. 云原生网络的可观测性和微服务的调用链有什么区别？他们的实现方式有什么区别？
A：网络的调用链是基于 DeepFlow 采集到的 4 层流量画出来的，描述的是一段时间（可细至 1s）的所有调用的聚合情况。微服务的调用链是根据 7 层应用调用出来的。拓扑的指标量也不同，网络拓扑有吞吐、时延、重连等指标，而应用拓扑的指标量是请求次数、错误率、延迟等指标。

---

Q：7. DeepFlow 是基于 eBPF 实现的吗？如何解决对内核版本的要求？
A：DeepFlow Agent 做了大量的内核适配工作，在内核高于 4.14+ 版本时会自动开启 eBPF 功能，即拥有调用链追踪能力、HTTPS 性能采集能力。在内核不满足 4.14+ 时也有除此之外的其他能力，比如网络/应用拓扑、流日志、应用请求日志等。

---

Q：8. DeepFlow 的 agent 是开源项目吗？
A：DeepFlow 的 server、agent 全部在 GitHub 开源，都在下面这个 Repo：https://github.com/deepflowys/deepflow

---

Q：9. 网络连接经过NAT后，怎么跟踪整个链路？
A：经过 NAT 后并不影调用链追踪能力，通过流量中的 TCP SEQ 等信息 DeepFlow 能自动追踪整个链路。

---

Q：10. 这么具体的数据，日志容量会很大吧？
A：DeepFlow 的 SmartEncoding 技术可以极大的降低存储成本：Agent 通过信息同步获取到字符串格式的标签，汇总到 Server 上。Server 通过对所有的标签进行编码，为所有的数据统一注入 Int 类型的标签并存储到数据库中，与此同时 Grafana 可以直接以字符串格式的标签进行过滤和分组查询。这一编码机制可将标签写入的性能提升 10 倍，极大的降低了数据存储的资源开销。除此之外，Server 还会将 K8s 标签以元数据的方式与观测数据分离存储，无需在每一行观测数据中都存储所有的标签，进一步将资源消耗降低一半。最后，这样的编码机制也能减少数据查询时的磁盘扫描量，提升搜索性能。

同时，我们也支持设置数据的保存时长，支持冷数据（直接或通过JuiceFS）存储至对象存储中，这些都是 ClickHouse 的能力，而 ClickHouse 本身在数据压缩及写入性能方面的表现也已经非常优异了，SmartEncoding 能在此基础上再获得 10x 性能提升。

---

Q：11. Prometheus 的采集数据存储在 TSDB，对告警数据存储有什么方案吗？需要通过alertmanager 添加 webhook吗？

A：对，告警数据一般都是给 alertmanager 添加 webhook，比如有开源的alertmanager-es 的小工具，可以把告警数据推送给 ES 等。

---

论元数据在可观测性中的重要性——陈晨 云杉网络 产品架构师｜第十一期

问答整理

Q：1. 这里的元数据平台和一般企业内运维侧的元数据平台有什么区别吗？

A：内容不同，这里的元数据平台包含了运维侧里的元数据。运维侧元数据重资产，这里的元数据从三个维度去区分和划分了所有的元数据。

---

Q：2. 可观测性的中 profiles 目前成熟吗？

A：有一个网站，我分享给大家，是目前市面上比较齐全的一个列表。https://profilerpedia.markhansen.co.nz/uis/profiling-viewer/

---

Q：3. DeepFlow 产品中有维护这样的元数据吗？

A：有，我们产品的 AutoTagging 数据来源就是这样的元数据。欢迎大家关注我们的产品，访问我们的 Github 仓库和公众号。

https://github.com/deepflowys/deepflow

---

Q：4. 对于非ebpf场景，如何做到数据指标采集?资源消耗控制？

A：数据指标采集的话，Open Metrics 和 Prometheus 是这方面的专家，当然国内也有一些专业的厂商在做指标采集的工作。

资源消耗控制的话，我们以开源 Prometheus 生态来举例。主要分为三部分：Exporter 端，Prometheus Server 端，存储端。

Exporter 端：采集端一般资源消耗很少，因为只涉及到内存的数据转换和暴露。

Server 端：Server 端的话，如果要控制资源消耗，尽量不要在 Server 端进行逻辑操作，比如之前有过几次生产事故的直接原因就是在 Prometheus Server 端进行了大量的告警逻辑操作，导致内存暴涨。

存储端：存储端的话，其实我们没有更好的方式，数据量过大要选取性能较为强悍的存储。

在这之外，我们可以控制指标产生的频率、指标产生的量、预聚合一些指标出来等。

---

Q：5. 如何直观的理解智能驾驶？可观测性的智能化是怎么样进行的？

A：从张诚老师之前的分享内容和查阅资料来看，智能驾驶的发展一直都在朝无感知、无意识、全自动、智能化的方向前进，当然我们不是这方面的专家，可能这个问题需要请教相关专家了。

可观测性的智能化其实是参考智能驾驶的发展，从基础的我们手工排查问题，到后面的自动问题分析、错误预警、错误恢复以及变更恢复等能力就可以看到，也是在朝着 全自动、非人工的方式方向去发展的。

---

Q：6. 好用的可观测性工具有哪些标准？

A：其实这个问题已经回答了最重要的一点，是标准化。我个人的理解是，在此之外还应该有 生态完整性以及可落地性。

标准化：只有标准化的数据才会被更多生态接纳，标准化的数据和管道流才会更好的发展。

生态完整性：最好的解释就是 Prometheus 的流行。

可落地性：有人回答 K8s 带火了 Prometheus 的发展，我个人理解的是为什么 K8s 没有带火其他的指标产品发展呢，更重要的是 Prometheus 的可落地性和简单化才使得它如此流行，当然这些只是我个人的理解。

---

Q：7. 企业建设元数据的成本不小，元数据建设不好，监控数据无法串联，那么deepflow是否可以简化企业元数据建设？

A：DeepFlow 作为新时代的高度自动化可观测性产品，在设计初的目标就是来尽可能的解决目前可观测性领域遇到的这些问题，当然元数据丰富度对产品的影响也是一开始重点考虑的内容之一，我们收集并帮用户维护了来自各方面的元数据列表信息，让用户不必去建设复杂的元数据平台。同时也利用元数据丰富了可观测性内的多信号，让用户无感知的去高度关联多信号，从而构建更完整的产品。欢迎大家体验我们的产品，访问我们的 Github 和 公众号。

https://github.com/deepflowys/deepflow

---

证券行业云原生架构及可观测性探索之路——钱杰 云杉网络 解决方案专家｜第十二期

问答整理

Q：1. 采集器既要收集流量，又要进行数据处理，是不是需要消耗大量的计算资源？

A：关于采集器处理性能及资源开销这一块，DeepFlow已经做到很极致了，1C1G的计算资源开销，能够采集并且处理10Gbps/300Kpps的流量，当然这中间包含着很多云杉自研的高性能采集与流量处理的专利技术，这里就不展开阐述了。并且采集器也具备过载保护机制，用户可以根据流量规模调整采集器资源开销的上限，同时采集器自身也具备完善的监控告警机制，安全可靠。

---

Q：2. 业务流量访问拓扑支持哪些维度的展示方式？

A：业务流量访问拓扑默认是按照容器服务维度自动绘制，当然也可以手动切换展示的维度，支持按照资源池的角度，比如区域、可用区；计算资源维度，比如宿主机、虚拟机；网络资源维度，比如VPC、子网、IP地址；容器资源维度，比如NameSpace、Service、工作负载、容器POD等等。同时啊，也支持按照上述维度进行流量搜索，这样子也比较直接、高效。

---

Q：3. DeepFlow目前支持集成哪些其他工具的观测数据？

A：目前支持集成Prometheus、Skywalking、Telegraf、OpenTelemetry等工具的观测数据，同时DeepFlow也在以两周一个版本的速度快速迭代，正在继续扩充集成Fluentd、statsD、Filebit等观测数据，大家也可以尽情期待一下。

---

Q：4. 没有trace id，spanid deepflow能否实现无侵入的链路追踪？

A：可以。DeepFlow基于一系列自研的专利技术，创新性地实现Flow生成、Session关联，通过eBPF+BPF技术关联实现无侵入、全自动的分布式应用全链路追踪图，不需要修改业务代码，也无需插码注入TraceID或者SpanID。当然，如果业务调用中已存在TraceID或者SpanID的话，DeepFlow也支持TraceID/SpanID的提取，并将应用插码的Span、eBPF采集的系统Span以及通过BPF采集的网络Span进行关联，实现无盲点的分布式追踪。

---

DeepFlow Grafana 插件开发实践——周振宇 云杉网络 前端技术专家｜第十三期

问答整理

Q：1. 为什么不使用echarts的图来制作panel？

A：Echarts图可以用来制作panel。只有在Echarts目前提供的图无法满足准确体现产品意图情况下，我们才会考虑自己开发相关图表。

---

Q：2. 如果想把上面的DeepFlow的火焰图嵌入我们自己开发页面，可以嘛，怎么做？

A：可以。待DeepFlow-vis开源后，可以使用绘图组件自由搭配页面。

---

Q：3. 有计划支持其他可视化平台嘛，比如kibana或者chronograf？

A：暂时没有计划，相对来说kibana和chronograf更加针对自己的es和influxdb。

---

Q：4. 开发完页面性能上怎么保证呢？

A：数据层面通过从查询时限制查询的数据条数，优先使用对数据进行分组聚合来减少数据量。组件层面，需要从代码级别进行性能优化，避免多份数据拷贝或者视窗外的无效渲染。

---

Q：5. 公司有在使用Grafana，是否可以直接对接deepflow的数据，还需要额外开发吗？或者有什么特别要求？

A：安装DeepFlow社区版时自带打包好的Grafana。独立的Grafana可以通过安装插件，导入模板直接对接DeepFlow的数据。

……持续更新中……

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