金融信创是金融机构重点投入以及技术迭代的方向，经过多年阶段迭代，进入难度更大的核心系统、关键业务系统的更替阶段。DeepFlow解决行业中普遍存在的分布式交易系统保障难、平台双轨多芯调优难、云上资源把控难、分布式数据库追踪难等挑战。
Read More用户：某省级电网企业 挑战 定界困难：当发生故障，业务部门和网络部门互相推诿，而不是解决问题； 监控颗粒度不足：运维难以深入到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 […]
Read More北京云杉世纪网络科技有限公司(以下简称：云杉网络)的云原生可观测性产品 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 […]
Read MoreDeepFlow 开源以来，社区反馈活跃，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 工具（这可能也需要升级内核） […]
Read More近日，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 […]
Read More在专家讲座环节，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 能力，如何在主机业务混布场景下零插桩计算服务拓扑，如何处理 […]
Read More基于 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 数据结合后的一个效果。 我们以一个自有的应用服务来进行演示，当前页面上的展示了 […]
Read More基于 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 是以 […]
Read More接下来讲一下我们大致在小米中的部署框架，大家使用 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，还有一个是 […]
Read More前面我们就说了，现在工作重点是推 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，你可以看到它的整个流程是比较复杂的，首先要代码改造，业务方代码改造后他们一定不会全量上线的，可能要灰度验证一段时间，最后到上线需要至少一周。第二就是改造成本过高，业务方研发会降低优先级，前面也说了，小米内部有一些盈利的业务，他们可能不会优先考虑到接探针，他们先要完成他们的活动任务，这就会降低优先级，我们推得就比较困难。第三就是很多业务研发对指标链路上报的原理不太熟悉，特别 […]
Read More
Air
2024年5月24日
云杉动态, 产品资讯, 新闻精选, 最新内容