在专家讲座环节,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大家好,我是来自小米的谭槊,今天非常高兴来参加 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 […]
Read More本次活动的主题为《基于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 的零侵扰性消除了追踪盲点、打通了孤岛数据。 最后,本次圆桌讨论环节深化了与会者对于可观测性当前挑战和未来趋势的理解。 […]
Read More政采云可观测平台背景与规划 首先第一个就是我们构建平台的一个背景。 我们之前是为了去观测业务的运行状态,或者说帮助我们去做故障排查的时候,其实是引入了三个工具的,比如 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 的话讲就是你的观测存在盲区,所以我们尽可能的就是想我们对于观测的对象做到全面的覆盖,也就是全栈追踪。 这里引用一个经典的老图,大家如果参加可观测性的会的话,基本上都可以看到这个图。这里想提的一点是什么呢?就是我们首先关注的是业务,然后关注业务,关注承载业务的应用,但是想要让这个应用正常稳定的运行的话,其实它有一些底层的一些依赖,比如说它依赖的上下游,以及上下游之间的网络通信、数据库中间件等等之类的。这些也都是我们可观测性需要覆盖的维度。 另外一个其实是针对我们我们公司的一个场景专门去弄的,因为在我们的场景里面其实是有很多个环境,我们有一个云端的环境,以及我们在各个省份,比如说有江西环境、上海环境、山西环境等等之类的。我们之前碰到的一个问题是什么呢?就是我们想要去找数据,还需要先确定它在哪个环境,以及每个环境可能因为人的原因,它配置的采集规则不一样,告警规则不一样,分析规则也不一样。所以我们在构建可观测性平台的时候,第一个就是我们要做一个统一的入口,所有的观测行为、观测操作、观测分析都可以通过一个入口来去解决。 […]
Read More作为中国移动智慧中台的统一技术底座,磐基 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 平台的可观测能力,因而在能力建设上的投入往往落后于实际生产需要。 […]
Read More
云杉 世纪
2024年2月28日
产品资讯