新闻中心

金融信创是金融机构重点投入以及技术迭代的方向，经过多年阶段迭代，进入难度更大的核心系统、关键业务系统的更替阶段。DeepFlow解决行业中普遍存在的分布式交易系统保障难、平台双轨多芯调优难、云上资源把控难、分布式数据库追踪难等挑战。

用户：某省级电网企业 挑战 定界困难：当发生故障，业务部门和网络部门互相推诿，而不是解决问题； 监控颗粒度不足：运维难以深入到POD维度，大量微服务的业务交互在虚拟机内已经完成业务交互； 全栈链路追踪难：电网要求运维能力覆盖整个业务链条，在微服务架构下，难以看到完整跨容器节点的全链条追踪数据； 定位方法单一：大部分运维工具功能单一，比如日志只可以查询日志，没办法进行指标，追踪、日志等联动定位。 用户期望 期望1分钟发现问题、15分钟研判问题、1小时内解决问题； 监控体系完成业务全覆盖、系统全覆盖； 全业务链条可追踪、可溯源。 这里交代了背景 经济发展，电力先行。作为国家电网旗下最年轻的某省级电网企业，链接东北和华北电网，承担着京津冀北区域电力供应的重要使命。于2012年2月9日正式成立，2017年实施了全业务数据中心的建设，并陆续完成四大数据中心的建设，实现了统一的数据共享与业务融合。 随着信息技术在电力行业经营管理中的广泛应用，越来越多的业务系统从传统的物理环境迁移上云，导致诸多电力业务系统如：营销系统、BPM、PMS2.0、各类6000系统，成分布式微服务化部署，系统环境也多为异构场景，混合云和云上云下的场景尤为凸显。网络分层导致电力行业的业务系统很难用传统的运维手段探测到全局的网络，网络故障发生时很难快速做到端到端的定位等等。 事件起因从这里开始 我（作为现场支撑人员也是小编本身）和电网企业的故事要从一次联合故障定位开始，在往常巡检的过程发现其中一个业务系统，内部微服务（POD）间有大量的建连失败，在 DeepFlow 中输入更多关于建连失败的指标量，如建连客户端 SYN 结束、建连服务端 SYN 结束、建连服务端直接重置等，下钻到流日志后发现了主要建连失败的原因：即客户端 SYN 结束表现形式为客户端多次尝试建连，但是服务端无回应，于是服务端口未放行或者服务端口失效。 为了验证是否下沉到业务侧，与南瑞 I6000 运维同事进行联合定位，在交流过程中用户并没有发现有任何问题，用户随即手动输入 POD 健康检查的命令发现没有响应，与我判断一致，表面上看所有业务都在正常 running，但是 POD 实际没有启动好，监控端口已经失联。为了缓解尴尬的场景用户调侃道“假 running，真故障”。 接着与用户进一步讨论时，发现使用的是 Livceness，可以制定检测规则，如果检测失败就会重启 POD ，全部是以 K8s 被动触发，手动检测会变的很复杂，甚至会出现一种假活现象。根据这次联合定位，我和用户运维部门做了一次深入的沟通，同时也从内心深刻的体会到：一个运维人员面对微服务场景下缺失可观测性能力的无力感。 首先 K8s 的产生是面向业务的，最大限度的保证服务的高可用，但是很多流量都是瞬发的，微服务（POD）在不停的自动化运转，根据工作负载，随时可能发生业务 POD 剔除或者重建的情况，导致微服务场景的监控变得非常复杂。 还有就是以目前的运维手段用户更在乎业务的可读性，也就是电力行业常说的小绿泡，绿色代表正常，红色代表异常，但这远远不能达到实际的运维要求。在和用户深入沟通的同时，我也根据产品能力，建立较为完善的应对措施，帮助用户提升整体运维能力。 首先需要站在用户实际的业务角度出发，完成个性化的运维场景定制。 通过 DeepFlow 丰富的监控指标，可以全面覆盖网络和应用层的R（吞吐）E（异常）D（时延）的场景况，结合目前较为先进的 SRE 方法论，优化故障发现到故障解决的时间，使得整体业务水平在一个良好的 slo（服务等级目标)；并针对重要业务中发现过的故障进行重点监控和故障场景复现进行针对性优化，改变过去发现业务问题再做问题定位的被动情景，转变为主动检测、主动监控、主动告警的监控闭环。 接下来为了解用户实际的业务场景和容忍度，和运维部门针对运维指标开设了讨论会，建立丰富、贴合用户使用要求和习惯的 SLI 指标和基线，通过主动监测和建立健康度管理模型的方式，帮助用户发现潜在故障。并且当发现了某些指标不合格，快速进行告警推送到指定责任人手里，再联合 DeepFlow […]

北京云杉世纪网络科技有限公司(以下简称：云杉网络)的云原生可观测性产品 DeepFlow 与 OpenCloudOS 完成相互兼容认证，测试期间，整体运行稳定，在功能、性能及兼容性各个方面都表现良好。 本次兼容性认证测试包括且不限于验证 DeepFlow 在 OpenCloudOS 上安装部署、数据采集、数据解析、数据存储、数据展示、网络拓扑、应用拓扑、流日志、应用调用日志、网络性能指标、应用性能指标、分布式追踪、服务列表等功能测试，经验证后全部通过测试认证。 在测试期间各功能运行稳定，所有用例、场景均符合测试通过标准，没有出现任何异常。经过以上多项测试表明，云杉网络的云原生可观测性产品 DeepFlow 与 OpenCloudOS 操作系统完全适配，双方完全满足产品兼容认证要求。 DeepFlow 简介 DeepFlow 是一款为云原生开发者实现可观测性而量身打造的全栈、全链路、高性能数据引擎。帮助解决云及云原生应用诊断难的核心痛点，通过细粒度、多维度的可观测性数据打通各部门之间的协作壁垒，为企业数字化、智能化转型提供高度自动化的可观测数据底座。 DeepFlow基于eBPF、WebAssembly、OpenTelemetry 等领先技术，在此基础上创新的实现了 AutoTracing 和 AutoTagging 两大核心机制，实现对网络、系统、应用全栈指标自动采集和全链路自动追踪，并结合云资源知识图谱实现100+维度指标数据的动态标注，提升了DevOps自动化水平，并降低了可观测性平台的运维复杂度。利用精细到微服务 API 粒度的全栈指标数据，帮助技术运营制定并观测更细致的业务性能指标（SLI），不断提升业务稳定性。同时，DeepFlow 的可编程能力和开放接口，使开发者可以快速将其融入到自己的可观测性技术栈中。 OpenCloudOS 简介 作为国产开源操作系统社区，OpenCloudOS 沉淀了腾讯及多家厂商在软件和开源生态的优势，在云原生、稳定性、性能、硬件支持等方面均有坚实支撑，可以平等全面地支持所有硬件平台。目前，OpenCloudOS 已支持 X86_64、ARM64、RISC-V 架构，适配 飞腾、海光、兆芯、鲲鹏等芯片。同时提供支持全栈国密和机密计算，另有 300 余家企业产品与 OpenCloudOS 操作系统完成适配。 深厚的技术积累与不断创新，让 OpenCloudOS 在社交、游戏、金融支付、AI、安全、大数据等真实业务场景中，经历了千万级节点的长时间验证，可用性高达 99.999%。相比 CentOS 7 和其他开源社区版本，OpenCloudOS 故障率降低 70% 以上，且在典型业务场景中性能提升超 50%。 云原生时代，云杉网络 DeepFlow 重视云生态领域的合作与建设，致力于打造云原生可观测性生态， OpenCloudOS […]

DeepFlow 开源以来，社区反馈活跃，eBPF 相关问题主要集中于安全、性能影响、内核适配等方面。本次议题分享 DeepFlow 在落地 eBPF 过程中遇到的问题和解决办法；介绍 DeepFlow 针对 eBPF性能开销问题的持续测试机制、测试数据、以及所做的优化；并分享 DeepFlow 落地 eBPF 过程中踩过的一些坑。 CORE – 浅析 BPF 程序的可移植性问题及解决方案 BPF 程序的可移植性意味着什么？什么是 BPF CO-RE ？我们将了解编写可以跨多个内核版本工作的 BPF 程序的挑战是什么，以及 BPF CO-RE 如何帮助解决这个问题。通过一组实例，我们将看到如何在真实世界中解决 BPF 程序的可移植性问题。 QA环节 Q1｜针对 3.10 内核，CentOS 7 系统，eBPF 有没有比较好的解决方法？ A：CentOS 7 是非常老的系统了，如果可能，建议迁移到 OpenCloudOS 8/9，社区可以提供技术支持，参考 https://mp.weixin.qq.com/s/mOS0XBWxtNhuVJ35qg_M_Q 在比较老的系统上，可观测性问题可以考虑使用 Kprobe，推荐使用工具 https://github.com/OpenCloudOS/perf-prof 我本人并没有 CentOS 7 的实践经验，在 BCC 社区，部分用户反馈过可以使用 BCC 工具（这可能也需要升级内核） […]

近日，SIGCOMM 2023 论文录取结果公布，由清华大学计算机科学与技术系尹霞教授团队与云杉网络 DeepFlow 团队共同发表的论文《Network-Centric Distributed Tracing with DeepFlow: Troubleshooting Your Microservices in Zero Code》被大会正式录用为 Main Session 文章。 SIGCOMM（Special Interest Group on Data Communication）是美国计算机协会 ACM 组织的旗舰型会议，也是国际上计算机网络领域的顶尖会议，拥有广泛的影响力和声誉。SIGCOMM 对论文的质量要求极高，要求录用工作有颠覆性创新、基础性贡献以及坚实的工程实践，2023 年从全世界顶尖科研机构投稿的 323 篇论文中仅录用了 71 篇，录用率 21%。SIGCOMM 录用的论文通常都会被广泛引用，在学术界和工业界均具有非常重大的影响力。 2010 年，Google 发表的《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》开启了分布式追踪（Distributed Tracing）的先河 [1]，它被认为是与 Borg、Spanner 并驾齐驱的 “改变企业数字化基础设施的三驾马车” [2]。在此之后分布式追踪技术沿着 Dapper 的核心理念蓬勃发展，并奠定了应用可观测性的基石。然而，绕不开的应用程序插桩难题使得它的落地异常艰辛，在云原生时代更是暴露出了基础设施及第三方服务无法插桩的严重问题。 经过近十年潜心研发，由中国本土团队发布的 DeepFlow 对可观测性领域中最核心的分布式追踪技术进行了颠覆性创新，并得到了 SIGCOMM […]

在专家讲座环节，4位业内专家就可观测性的不同方面进行了深入浅出的讲解，让参与者们了解了该领域的最新技术和极具代表性的实践经验。 第一位分享嘉宾是来自云杉网络的 DeepFlow 研发VP 向阳，分享了《DeepFlow 社区进展及新特性介绍》主题，现场对 DeepFlow v6.2 进行了详实的讲解，重点解说了已落地实践的一些重大新特性，例如：零插桩分布式追踪支持 Golang 应用及关联 IO 事件；全景服务拓扑精细至进程粒度；基于 Wasm 的插件机制为 eBPF 赋予了感知具体业务场景的能力等。畅谈了 DeepFlow 社区的发展、用户案例、和未来迭代计划。 以及首次向大众揭晓了中国原创可观测平台DeepFlow 入选 SIGCOMM 2023的《Network-Centric Distributed Tracing with DeepFlow: Troubleshooting Your Microservices in Zero Code》论文细节，提前预告一个消息，SIGCOMM 于美国纽约召开，届时来自清华大学和云杉网络的作者们将向全世界介绍中国原创的 “Zero Code 零插桩” 可观测性平台 DeepFlow。 第二位出席的分享嘉宾，来自腾讯IEG的高级研发工程师刘文平，以《蓝鲸在实战中的 DeepFlow 社区版应用》为主题，详细阐述了蓝鲸可观测性平台如何有效地融合了 OpenTelemetry 的标准化数据接入能力及 DeepFlow 的无插桩、全面覆盖的数据收集能力，进而解决游戏业务在观测数据采集、数据孤岛、以及云原生基础设施观测等领域所面临的难题。并展望了通过 DeepFlow ， 构建适合腾讯游戏的专属观测场景。 第三位分享嘉宾是来自小米的监控系统高级工程师谭槊，分享了《DeepFlow 在⼩⽶落地现状以及挑战》主题，介绍了如何将 DeepFlow 融入到小米现有可观测性体系中的经验。他详细解读了在落地过程中，如何在低版本内核下充分利用 cBPF 能力，如何在主机业务混布场景下零插桩计算服务拓扑，如何处理 […]

基于 eBPF 的可观测性实践 那么怎么去解决这些问题呢？前面讲了这么多，现在终于到今天的重点了：eBPF。 eBPF（Extended Berkeley Packet Filter）是最近一两年兴起的技术，我们一直在关注这个领域。简单地说，eBPF 是对内核能力的扩展，它可以将用户的代码加载到内核中运行，这样我们就可以 hook 所有系统函数调用，捕获所有的系统请求和网络请求，然后分析用户程序的行为和网络数据的行为。 目前，eBPF 的应用场景主要集中在网络、安全、和可观测性这三个领域。 许多大公司已经在使用这项技术，这是从 ebpf.io 官网上截取的一张图片，上面列出了所有使用 eBPF 技术的优秀公司及产品。从这些公司中，我们可以大致了解到这些大牛公司的技术发展方向。我挑选出了所有应用了可观测性领域的公司，基本上有以下几家： Cillium 是基于 eBPF 的一层封装，提供了基础的数据抓取能力。它旗下两个产品，Hubble 和 Tetragon，分别专注于网络的可观测性以及安全可观测性。SysmonForLinux 是由微软开发的一个 Linux 命令行工具，可以监控和记录系统活动，包括进程生命周期、网络连接、文件系统写入等等。Pixie 是一款专注于应用可观测的产品，已经被 New Relic 收购，主要面向 K8s，但提供的工具不多，更多地提供一种脚本化操作能力。 最后就是 DeepFlow，这是一个高度自动化的可观测性平台。在可观测性领域，DeepFlow 创新地实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等领先的技术，目前来看， 应该是该领域最为前沿的产品。 上图是 DeepFlow 在 GitHub 上的一个架构图，比较简单。由 Agent 和 Server 两个组件组成，Agent 负责采集，Server 负责管理 Agent、标签注入、数据的写入和查询。 让我们先来感受一下，eBPF 和 OTel 数据结合后的一个效果。 我们以一个自有的应用服务来进行演示，当前页面上的展示了 […]

基于 OTel 的实践与挑战 OTel 可能已为熟悉可观测性平台的朋友所熟知。在 OTel 诞生之前，已有诸多分布式链路追踪相关的产品，如 Jaeger、Zipkin 等，蓝鲸观测平台也有自己的实现方案。然而，由于各种实现方案层出不穷，这对使用者来说意味着每换一个平台就需要重新检测代码、配置新的 SDK，甚至还需要关心新平台的数据协议，导致接入成本很高。 OTel 的出现便是为解决这个问题，它统一了 Trace、Metric、Log 这三种数据协议，用户只需要加载一套 SDK，更改上报地址即可体验不同平台的功能。同时，数据标准化后不仅降低了用户维护 SDK 的负担，也提高了数据的可移植性。 2021 年，蓝鲸观测平台也拥抱开源，我们将自己的实现方案统一转换成了 OTel 协议格式。下面，我将展示基于 OTel 的一些特性，帮助用户快速定位问题。 首先，当用户有了一个具体问题后，这个时候往往用户已经有了一个明确的 traceid，或者说他已经有了明确的一个时间段，需要去定位具体是哪个服务出错了，是哪一个接口出错了，具体的这个出错内容是什么？那么可以带着 traceid 去到我们平台的检索页面，把这个 traceid 带入进去，直接快速的找到本次 trace 请求所经过的所有链路服务。 如果更关心于这种服务与服务之间，或者说接口与接口之间的调用关系的话，那么可以切换到这个拓扑的视角； 如果更关心于这种时间上的调用关系，想知道这些接口有没有按时间顺序去调的话，那么也可以切换到这种时序图的这种视角去从时序上看这个调用的关系； 如果更喜欢用以往的这种火焰图的形式，更关心耗时分布，也可以切换到火焰图的视角，然后通过这种火焰图的形式去找到这个耗时最大的一个 span 是什么。 其次，如果用户没有具体的问题，我们也会帮助他们挖掘更深层次的未知问题。 为此我们提供了业务的全景视角，用户通过这个拓扑图，然后往下钻，通过观察这个拓扑图上的具体一个服务，然后下钻到里面可以看到每一个服务它的一些黄金指标，像请求数、错误数或者说请求耗时以及底下的这些像这种 Top 视角，包括耗时 Top 或者错误 Top。 也可以切换接口的统计视角，这种视角去看到每一个接口的这种整体的一个情况。或者以错误统计的这种视角去查看错误次数最高是什么？然后我们也可以在右边的这个视图里面，直接展开看到它的这个错误的一些更详细的错误信息，堆栈信息。 此外，我们还提供了其他视角，如主机视角、日志视角和实例视角，用户可以在这些关联视角中观测到更多的对象，以帮助他们更快地发现架构中更深层次的问题。 在前两种情况中，用户会主动查看平台，通过平台发现问题。然而，即使用户没有查看平台，我们也会从 Trace 数据中提取出一些基础的黄金指标，并提供给用户配置告警，同时也提供了用户自定义的维度，以满足用户个性化的需求。将用户关心的关键指标通过告警的形式及时送达给用户。 上图就是数据的联动。这里介绍关键的三个数据 Metric、Log、Trace 之间的关联关系，从任意一个数据视角都可以关联跳转到其他两个数据的视角，帮忙用户快速的发现定位问题。 Trace 关联 Log 是以 […]

接下来讲一下我们大致在小米中的部署框架，大家使用 DeepFlow 产品的时候知道， DeepFlow 的 Agent 采集器部署是分两种方式去部署的，一个是云原生部署，一个是传统主机部署，就是云主机或者物理主机的方式。小米内部我们前面也说了，有两套平台，一个是主机应用平台，一个是容器应用平台。所以说我们部署方式也分了两套。 首先是传统主机的部署架构，我们做了一个比较巧妙的设计，我们之前也说到有个 Falcon，即 SREOps 的产品，我们的采集器其实已经覆盖集团所有主机了。这个时候我们要推 DeepFlow，如何把它也向全集团去推呢？其实我们可以搭我们的 Falcon Agent 的顺风车，我们把 Falcon 的 Agent 进行了改造，把 DeepFlow 的功能融合进去了。这边可以看到绿色的方框内是我们采集对象的主机，上面有 DeepFlow Agent，它对接的是 cBPF 和 eBPF 的探针，然后 Falcon Agent 采集的是主机的基础指标，包括 CPU、内存。最下面我们还有个插件，就是之前 DeepFlow 采集的 Flow Metrics 和 Flow Log 这些信息，它是没有应用信息的，我们通过这个插件跟我们的应用发布系统联动，用户发应用的时候会在主机上留应用元信息，包括应用的细节，比如进程也即 PID 的映射，然后这个插件就是把这个映射同步给 DeepFlow 的集群，这样就可以给 DeepFlow 的流打上我们的应用信息，也满足了 Hera 的以应用为核心的需求，最下面有一个 Super Agent，其实就是把三个 Agent 进行融合，进行统一化的部署。然后右边做一个简单的管控面，这个管控面是我们内部用的，我们可以看到有多少个机器覆盖了 DeepFlow 的 Agent，有多少个开启采集配置，采集配置下发分两部分，一个是静态配置的下发，需要重启 Agent，还有一个是 […]

前面我们就说了，现在工作重点是推 Hera，然后实现 DevOps。那现在就说为什么我们要引入 DeepFlow？ 在推 Hera 的过程中，我们会发现有几个问题，首先最大的痛点是 Hera 探针接入成本比较高，覆盖的应用不全，如果我们要向全集团全部的业务去推进 Hera 的话，那它必须要形成完整的覆盖度。但我们在推的时候有一些很难推，有些业务可能有需求排期或者需求倒排之类的（编者按：探针的插码可能被业务团队放到业务需求之后），接入成本高。那如果在我们的 Hera 探针接入后，我们是不是就不需要 DeepFlow 的自动化采集？其实并不是，我们在接入 Hera 探针后， DeepFlow 还是可以对我们 Hera 的探针进行功能上的补全的。后面我也会详细说一下，目前主要是这两个痛点。 首先是 Hera，我们采取的是 OTel 探针，OTel 探针做可观测性的话会比较了解，我们是基于社区版本做了一个简单的改造，对小米内部的一些功能做了适配。我们可以看到有两种接入方式，一个是 Golang 的应用，一个是 Java 的应用，其实它们两个接入方式是不一样的。 如果是 Go 应用的话，我们内部的话可能会有一个微服务框架，可以通过中间件的方式，把 OTel SDK 给加进去，这样它会在一些核心的地方，比如说网络请求加入一些自动上报的逻辑。但有的没有用框架，那就得手动地写代码了，你得在网络调用地方手动地去写上报逻辑。 然后下面是 Java 应用， Java 应用比较简单点，它可以通过 Agent 的字节码注入技术，自动地把 OTel 探针注入到 Java 应用中去。然后接入成本就是可能要改启动命令，虽然成本比较低，但也涉及到业务的发版。 这边大致是 Hera 如果不用 DeepFlow，而用探针的接入方式来做接入。Java 的我们加一个命令行加入 Agent，这样启动的时候就可以自动地实现探针的功能了。 然后这是 Go，你可以看到它的整个流程是比较复杂的，首先要代码改造，业务方代码改造后他们一定不会全量上线的，可能要灰度验证一段时间，最后到上线需要至少一周。第二就是改造成本过高，业务方研发会降低优先级，前面也说了，小米内部有一些盈利的业务，他们可能不会优先考虑到接探针，他们先要完成他们的活动任务，这就会降低优先级，我们推得就比较困难。第三就是很多业务研发对指标链路上报的原理不太熟悉，特别 […]

大家好，我是来自小米的谭槊，今天非常高兴来参加 DeepFlow X 蓝鲸的线下 Meetup。我先做一下自我介绍，我是目前在小米监控系统组的高级工程师， 21 年加入小米。今天来这边分享的目的是简短地介绍一下目前 DeepFlow 在小米在业务中的切入点。因为我是一线研发，所以我大致讲一下在落地的过程中遇到了哪些挑战，以及遇到这些挑战后，我们和社区是如何努力去解决这些问题的。最后我讲一下在小米内部落地的一些业务。 我今天的分享分五部分展开：第一章会说一下小米可观测性的现状和规划，这一部分大致介绍一下我们的团队，以及我们是干什么的。我们团队在项目中会有一个主线作为年度目标，以及大致讲一下团队项目的全景图。第二章是为什么我们要引入 DeepFlow，在我们团队已经有一个很明确的主线的情况下，引入 DeepFlow 的动机和动力是什么？第三章 DeepFlow 在小米内部的部署架构介绍，我这边是从研发角度上而不是从产品角度上（来介绍部署架构），研发层面上我们是通过技术上部署（和架构调整），来介绍如何把 DeepFlow 从架构上和我们小米内部已有的一套可观测性架构进行融合。第四章讲我们已经把 DeepFlow 部署起来了，在推广它的时候遇到了一些挑战，过程不是一帆风顺的，我们针对遇到的挑战有技术上的一些解法，最后会给大家看一下，目前给我们的用户，也就是给业务方带来的可观测产品，目前产品不是很多，会有一个长期的如何跟 DeepFlow 展开深入合作的规划路线图。 我还补充一下，目前小米和 DeepFlow 合作的方式是以社区共建的形式合作的，我们这边也投入人力，然后在社区中走的都是社区的正规流程，提 FR、PR，然后我本人也提供过多个 FR 和多个 PR。 小米可观测性的现状与规划 第一章介绍我们团队，我们组为小米集团提供日志、指标、链路等可观测性的数据，这是可观测性数据的三个维度，通过平台将这些数据结合，帮助业务发现、定位和解决问题。先介绍一下我们的历史成果，以往我们主要面向的用户群体是 SRE，我们的第一阶段叫 SREOps，这个是我们提供的覆盖全集团的主机基础指标监控能力。这里面主要就是技术（编者按：基础设施）的指标，包括 CPU，内存，这块我们已经把它做完了，全集团已经铺开了，所有的机器都装了我们的采集器。这是第一阶段。 第二阶段主要是做可观测性，集中突破 DevOps，我们的目标用户从 SRE，也就是专业的运维同学，变成一线业务研发同学，这个阶段是当前的重点阶段，也是我们现在做的一块。目前这个平台已经差不多做完了，但是还没有向集团全部推出去，这是我们目前的目标。然后未来愿景，也是我们今年的具有挑战性的下一个目标，就是在全集团实现 DevOps 能力，覆盖任何应用，覆盖任何链路。 首先讲下 Falcon，如果是做可观测性的话，应该对 Falcon 这个产品比较了解。这是小米内部孵化的，也是我们团队目前在维护的一块，它重点面向的核心用户群体是我们的 SRE 。Falcon 提供的都是主机粒度的一些指标，比如 CPU、内存，磁盘、网络 IO 之类。目前部署范围是全部的主机，包括国内、欧洲、新加坡、印度、美国等多个机房，超过上万台主机。目前这个产品功能已经非常完善了，我们就不在上面继续进行深入迭代了。 除了我们自己做的 Falcon 之外，还有一些基于开源的知名项目（作为）我们的核心项目，我们做了一些日志链路和指标的一些单品，所谓单品即它们是各自为一个平台，没有一个统一的平台，相当于我们给业务方提供的散点指标数据，但是并没有提供一套完整的平台帮业务解决、发现问题或者定位问题。 日志相关的组件就是 Loki 和 ES，Loki […]

本次活动的主题为《基于eBPF的可观测性实践》，演讲者和与会者共同探讨了如何提高系统、应用和服务的可观测性。具备可观测性可以帮助企业更快地发现和解决问题，保障系统的可靠和稳定。 专家解读：基于 eBPF 的可观测性实践 在专家讲座环节，6位业内专家就可观测性的不同方面进行了深入浅出的讲解，并分享了生动的实践案例，展示了可观测性如何在实际工作中发挥作用，让与会者了解到该领域的最新技术和极具代表性的实践经验。 首先，主持人引出 “落地可观测性的主要痛点和挑战有哪些”？ 引发了嘉宾们纷纷阐述了自己的观点，如随着分布式系统日益复杂，海量集群、多中心观测、工具联动弱等对可观测性的实施都提出了更高的要求。 方海涛认为，对于 Sealos 来说零侵扰的可观测性可快速高效地解决在构建云服务中对云资源消耗（特别是网络带宽消耗）的计量计费需求，同时也能实现对云自身的安全可观测性。在此过程中尝试过诸多方式，增加用户态的Proxy，增加 K8s CNI 能力等等方式来暴露指标数据，最终发现 eBPF 的形式对性能消耗是最低的。 冯富秋谈到在阿里云业务高敏感情况下，监控工具再多也难以做到高效响应，有时反而迷失在工具中，最后依然只能依靠专家经验来定位问题。他认为可观测性是一个很有前景的方向，但仍然还处于起步阶段，例如缺乏标准的 Trace 点、仅能关注业务层面的问题定位，深入分析系统和网络层很不足。未来也在计划由龙蜥社区牵头组建运维联盟，联合可观测性领域的企业来共同研讨这些问题。 穆景远强调了可观测性落地过程中的分歧点，第一由于业务分布式部署，单节点逐步升级可能导致数据孤岛与全量节点升级带来用户习惯改变及现网风险的分歧；第二为投入与收益的反差，厂商做了大量投入但业务方感知甚微的分歧。 其次，主持人向嘉宾提出 “ eBPF 技术对这些痛点有什么帮助“？ 嘉宾们表示：eBPF可以提供更高效和准确的系统观测能力。在Linux内核中，eBPF消除了更改内核源代码或添加内核模块的需要。这意味着，通过使用eBPF，我们能够零侵扰地监控系统的各种活动和状态，包括调用关系、应用性能、分布式链路、函数性能剖析、内核性能剖析等等。 向阳提到，一方面 eBPF 确实依赖较高的内核版本，期望用户能尽快推进内核升级，期望操作系统供应商能将更多能力移植到低版本内核中，同时 DeepFlow 也利用 cBPF 的能力在低版本内核中实现了大量零侵扰的可观测性功能。另一方面，eBPF离实现业务的可观测性有一些距离，以往都是通过业务开发插桩来实现，可以通过结合 eBPF 和 Wasm 技术来实现对业务语义的感知和注入。 穆景远认为 eBPF 可以用零侵扰、业务解耦的方式来解决实际可观测性落地过程中前面提到的两个分歧，可以将厂商的投入和风险降低，业务方的收益显著增加，对客户来说推动力也很足。对于 eBPF 的门槛，认为业界现在已经形成了天然的分工，政采云提供用户场景，操作系统厂商提供对应的工具链，专业的厂商提供整套解决方案，这种组合也会大大降低 eBPF 的门槛，最终都以解决用户需求为推动。 接着上一个问题，主持人与嘉宾探讨了 “ eBPF 技术的推广、落地、接受目前存在哪些问题”。 穆景远总结：技术选型一定要结合团队目前的实际情况，政采云通过融合 DeepFlow 和 Pinpoint 有效的避免了对业务团队使用习惯的改变，避免了对插桩探针的替换，同时利用 eBPF 的零侵扰性消除了追踪盲点、打通了孤岛数据。 最后，本次圆桌讨论环节深化了与会者对于可观测性当前挑战和未来趋势的理解。 […]

政采云可观测平台背景与规划 首先第一个就是我们构建平台的一个背景。 我们之前是为了去观测业务的运行状态，或者说帮助我们去做故障排查的时候，其实是引入了三个工具的，比如 Prometheus 帮助我们去告诉我们有没有出现问题， Pinpoint 是做链路追踪的，他就是去告诉我们问题在哪。日志的 ELK SLS 是我们直接去定位问题是什么，但是有一个问题是什么呢？这三个工具对于我们去观测业务状态，或者说故障排查的话越来越吃力了。那为什么说越来越吃力了？这个其实基本上也是我们传统监控方案去往可观测去转的时候，基本上都会面临的一些问题。 比如说我们非常依赖人力去关联数据，因为我们这些工具引入的时候其实是垂直引入的。怎么理解垂直引入呢？也就是说我用什么工具，我就看什么数据，这些数据之间没有关联，那怎么去做关联？这个时候就依赖人去把数据给关联起来了。那比如说我们如果说出现了故障的话，我们能够给到使用者的东西，就是我所有的环境所能提供各个维度的数据都在这里了，你去查一下。 这个对人的负担其实挺大的，因为我这么多数据我要从何去查起？另外一个就是依赖经验去分析原因，这个怎么理解呢？就是我们目前能够给到用户的能力，都是我们之前故障处理的沉淀的经验。事实上我们针对于这些数据没有任何的处理，只是数据的堆彻，所以这个时候我们越来越觉得我们传统的观测方式或者说监控方式已经不足以帮助我们去更好地观察业务的运行状态了，这也是基本上各家公司去往可观测性去转的话，都会都想解决的一个痛点。 那另外一个问题是什么呢？还是人的问题，我们的业务越来越复杂，比如说某一个链路的话，它可能涉及到应用特别的多。当我们有一个业务故障的时候，谁能够告诉我这个业务故障影响的范围？在我们场景下观测到的一个现象，比如说我们出了一个故障，我们一般会拉一个群，然后看到的这个现象就是这个群的人数会越来越多，直到这个故障解决。 本质上的原因是什么呢？就是我们为了去降低我们个故障的排查时间，就只能去靠人海战术了。这样的话我们付出的成本其实就是比较大的。所以我们在这个背景下，我们在想我们之前的观测方式是不是有问题了？或者说基本上是没有办法产生更大的价值了？ 建设符合 OpenTelemetry 标准的可观测平台 在这个背景下我们想着是时候拿出一套完整的解决方案了。主要的短期目标就是这五点。首先我们要去构建一个标准化的数据，另外一个就是关联可以关联的数据，还有一点就是我们的数据的覆盖面一定要全，在这个基础之上我们去做统一观测和多维度分析。 是标准化，目前可观测性存在的标准其实挺多的，比如说有的用 Skywalking、 Zipkin 之类的。在我们去调研的时候，我们应该去选怎样的标准呢？我们选择了 OpenTelemetry，为什么选择这个标准（OpenTelemetry）呢？主要原因是我们去调研的时候发现在可观测性生态里面，大家都支持将 OTEL 的数据导入进来，或者说导出或者说处理，那这样的话我们就能够享受可观测性生态的便捷，就比如说我们已经享受到了 DeepFlow 给我们带来的便捷。另外一点就是 OTEL 在我们的场景里面它可以支持多个语言的SDK，同时而且是同一套 OTEL 的 API 标准，所以我们选择了OpenTelemetry。 另外一个就是数据可关联，这个可能有一点奇怪的是什么呢？我们如果说我们遵守可观测性的标准的话，数据其实已经关联上了，那为什么还要强调一下数据可关联呢？因为其实我们在去排查故障的时候，如果说纯靠 Trace Metrics Log 的话，其实还不一定能够找到问题，我们可以关联一些更多的数据，比如说我们可以关联我们 Paas 平台的数据，当前这个链路关联的应用近期有没有做过发布？ 因为 80% 的故障基本上都是业务变更导致的嘛，然后还有一点就是我们可以去关联一下指标相关的数据，因为我们如果纯粹通过 TraceID 去找指标数据的话，其实是不太全的。比如说某一个链路慢的话，我们可能要关注某个节点、某个环境、某个应用的线程池的负载情况。总之一点就是我们关联一切可以关联的数据，然后目的的话就是方便我们顺藤摸瓜找根因。 然后还有一个就是数据覆盖全，其实刚一开始我是没想过覆盖全这个问题的，是接触到 DeepFlow 以后，我们才发现我们的观测好像有盲区，然后这个时候我又打开了 OTEL 的官网，我发现它喊出的口号是高质量无处不在的便携式遥测技术。我这里提的一个关键字就是无处不在。为什么要强调一下无处不在呢？ 因为事实上如果说你的观测没有覆盖全的话，用 DeepFlow 的话讲就是你的观测存在盲区，所以我们尽可能的就是想我们对于观测的对象做到全面的覆盖，也就是全栈追踪。 这里引用一个经典的老图，大家如果参加可观测性的会的话，基本上都可以看到这个图。这里想提的一点是什么呢？就是我们首先关注的是业务，然后关注业务，关注承载业务的应用，但是想要让这个应用正常稳定的运行的话，其实它有一些底层的一些依赖，比如说它依赖的上下游，以及上下游之间的网络通信、数据库中间件等等之类的。这些也都是我们可观测性需要覆盖的维度。 另外一个其实是针对我们我们公司的一个场景专门去弄的，因为在我们的场景里面其实是有很多个环境，我们有一个云端的环境，以及我们在各个省份，比如说有江西环境、上海环境、山西环境等等之类的。我们之前碰到的一个问题是什么呢？就是我们想要去找数据，还需要先确定它在哪个环境，以及每个环境可能因为人的原因，它配置的采集规则不一样，告警规则不一样，分析规则也不一样。所以我们在构建可观测性平台的时候，第一个就是我们要做一个统一的入口，所有的观测行为、观测操作、观测分析都可以通过一个入口来去解决。 […]

作为中国移动智慧中台的统一技术底座，磐基 PaaS 平台提供了高效的集群管理和调度功能，满足多元化的业务场景需求。该平台携手 DeepFlow 借助 eBPF 技术，解决了 APM 落地困难和组件追踪断路中的挑战，实现了全栈且无侵扰的应用可观测性。磐基 PaaS 平台将 eBPF 数据与现有的可观测数据整合，提供了开箱即用的应用可观测性，全栈无盲点的调用链追踪等能力，大大提升了各业务系统云化的底气，并促进了平台本身的快速推广。未来，平台还针对运营商等特定行业场景，进一步深化可观测性数据的融合，并将创新性地拓展其 AI 能力，以增强市场竞争力。 中国移动磐基 PaaS 平台 磐基 PaaS 平台是中国移动智慧中台统一技术底座，为算力网络提供编排调度能力，提供分钟级的集群交付，实现 ARM/X86/混部架构集群统一管控，按需调度，支撑 B、O、M 三域用户交互、计算密集、数据密集、交易密集等多种类型的业务系统，具备万级 POD 承载能力，构建双栈网络，使在线业务稳定运行、平稳应对业务高峰。 磐基 PaaS 平台整合了磐基容器平台、磐舟 Devops、算力管控、磐维数据库、磐智 AI 平台及相关能力，以战略指导、统一规划、能力解耦、有机组装、需求驱动、场景匹配、敏捷迭代、低感升级为原则，全面布局云原生 PaaS 产品能力图谱，均衡发展。 磐基 PaaS 平台目前纳管700+集群，4万+节点，6千多套组件，支撑省分公司包括CRM核心系统、BOSS 计费系统，IT 公司、各专业公司IT系统包括 AI、大数据系统等600多个业务系统上云。 目前磐基 PaaS 平台基于可观测性三大基石（指标+追踪+日志）的指导思想，已经使用不同的组件构建完成，利用 Prometheus 获取了云原生基础设施资源（Docker、K8s 自身）、中间件（Redis、Nginx）等指标数据，利用自研的 APM 实现了微服务在代码级别的调用链追踪，利用自研日志平台收集主机、Kubernetes、组件、应用实例的日志数据。但是在业务真正落地过程中，还是存在以下一些问题： 推广支撑力度不够 信任度不足：传统APM探针技术主要采用字节码注入技术，该技术虽无需业务系统研发人员关注代码实现，但对业务系统仍有代码侵入特性，进而占用业务系统资源，或影响业务性能。高并发生产系统往往因探针可能产生的影响，而质疑其收益性。 语言依赖强：字节码注入技术依赖业务系统代码语言和代码框架，导致传统 APM 技术需提供各种语言和框架的探针，才能满足企业级 PaaS 平台的可观测能力，因而在能力建设上的投入往往落后于实际生产需要。 […]

DeepFlow 在银行数字化转型中的可观测性实践 案例介绍 01 金融行业用户 第一个案例是来自某银行，新业务上线前的压测打不上去，使用 DeepFlow 的调用拓扑快速定位到根因是后端某个服务导致的。 这个案例展示了如何快速的定位业务压测瓶颈。 02 金融行业用户 第二个案例是来自某银行，某业务从云下迁移到云上后的应用响应时延增大，使用 DeepFlow 的全路径追踪快速定位到 KVM 网络的原因导致应用响应时延大。 这个案例展示了如何快速的定位云上业务应用时延瓶颈。 03 金融行业用户 第三个案例是来自某银行，某业务在 F5 member 池中的节点发生了多次无规律不可用告警，使用 DeepFlow 的流日志功能快速定位到不可用原因是物理网络导致的。 这个案例展示了如何快速的定位云原生环境的网络故障。 QA环节 Q1｜案例1中，提到的AutoTagging可以展开介绍一下吗？ A：可参考 https://deepflow.io/docs/zh/features/auto-tagging/elimilate-data-silos/ Q2｜案例2中，如何获取到全栈链路的流量？ A：部署 Agent 后，默认即可获得全栈链路的流量。 Q3｜案例3中，如果是其他网络插件或模式时，我们应该如何来确认故障点呢？ A：不管是什么网络插件，对于我们的故障定位都是基本一样的。 Q4｜你们的 Agent 会占用多少资源？有没有侵略性操作？ A：通常 1C1G 就可以满足绝大多数场景的流量采集，特殊情况下需要 1C2G 或 2C2G 无依赖、不修改代码、不修改业务配置、不重启业务进程。 Q5｜你们所有的指标计算方式是根据什么来的？准确吗？ A：准确，可参考 https://deepflow.io/docs/zh/features/universal-map/metrics-and-operators/ Q6｜经过 F5 或者其他 NAT 转换后的流量可以在拓扑图上关联出来吗？ A：可以通过我们企业版的 […]