logo
logo
DeepFlow 全栈可观测平台赋能企业 OA 系统服务质量提升
本文深入探讨了 DeepFlow全栈可观测性平台在企业核心OA系统中的实战应用。针对某大型客户OA系统长期存在的响应迟缓、偶发故障等顽疾,DeepFlow 通过零侵扰数据采集技术,构建了从网关到应用、数据库的全景拓扑与实时告警体系。在一次典型的工单审批功能卡顿事件中,运维团队利用“全景拓扑——>应用调用回溯——>代码剖析——>大模型诊断”的闭环能力,在 3 分钟内精准锁定了Java程序GC异常的根因。该实践不仅大幅提升了IT运维效率,更有效保障了关键用户的办公体验,为企业数字化转型的服务质量优化提供了专业技术标杆。
慢调用排查实录:高效定界服务网格 Sidecar 性能瓶颈
某车企在测试新业务时,发现某测试集群(A-Test-Cluster)的请求响应时间异常,而业务 POD 内部响应正常,初步排除业务逻辑问题后,故障被定位为网络层面性能瓶颈。本次案例揭示了复杂异构测试环境中的两大挑战:底层架构的“黑盒化”导致根因难以识别,以及架构的多样性(如服务网格和定制化代理)加剧了问题排查的复杂性。通过引入 DeepFlow 的全栈可观测性能力,利用 eBPF 技术追踪请求全生命周期,结合拓扑分析、调用日志和持续剖析,精准定位问题源头为 Sidecar 代理在处理 304 响应时的阻塞缺陷。经过研发团队修复,问题得以解决。本案例展示了 DeepFlow 在复杂环境中快速定界故障的强大能力,其中立、全面的观测数据和跨层级的追踪能力显著提升了性能问题的定位与解决效率,为异构架构下的故障排查提供了可靠支持。
深度解析 DeepFlow 如何采集大模型服务的业务指标
为高质量支撑 2024 年客服大模型商用,中国移动构建了客服大模型“混合云”生产环境,确保大模型应用安全稳定运行、智算资源高效利用。面对当前跨云调用拓扑的复杂性,以及运维保障与业务运营中服务质量观测指标的缺失问题,多团队共同合作基于 eBPF 与 Wasm 技术构建客服大模型生产运行态可观测能力。
3 分钟诊断 Tomcat TCP 超时参数配置错误引发的概率性交易失败
某银行分布式核心交易系统运行过程中,遇到了偶发性、无规律的交易失败,由于交易请求海量、通信关系复杂、App 实例动态等系统特点,传统监控工具的诊断能力受限,此类故障诊断极其困难。但在本篇案例中,您将看到 DeepFlow 可观测平台提供的 Full Stack(全栈)、End to End(全链路)、Any Request(每一次应用调用)观测能力,精细化分析每一次失败交易的端到端过程,用 3 分钟时间、5 步操作,通过可观测性数据客观诊断出故障根因。
eBPF 可观测性技术 3 分钟锁定银行信创云垃圾文件罪魁祸首
在某国有银行的信创云日常运维中,发现大量未知的垃圾文件,存在严重的系统运行隐患,其承载的分布式核心交易系统的运行稳定性随时可能受到影响,运维人员尝试寻找产生垃圾文件的源程序,但却发现传统监控工具对未知程序在未知时间、未知节点、未知路径,写入未知文件的故障诊断并不是一件容易的事情,而 DeepFlow 使用 eBPF 技术实现的可观测性可以为运维人员提供纤毫毕现的文件读写观测能力,让此类问题的诊断定位变得极其轻松。
故障诊断 3 分钟锁定分布式核心数据库,加速金融科技信创开发、测试、迁移
金融行业信创迁移过程中,故障定界困难、定位周期长、开发测试速度缓慢、生产运行风险高等因素正在不断地拖慢相关工作的效率和速度。如何让金融科技部门的业务信创迁移更快、更高效、更平滑?DeepFlow 通过 eBPF 带来的零侵扰、全栈、全链路可观测性技术,可以大幅度提升信创全系统的可观测性,从根本上扫除信创道路的技术阻碍。通过本篇案例您将了解到,某股份制银行在分布式核心交易业务向信创平台迁移的开发测试过程中,如何通过 DeepFlow 平台仅用 3 分钟时间将问题根因锁定到分布式核心数据库,快速消除不同运维技术栈之间的定位分歧,快速解决故障,加速开发测试速度。
金山办公基于 DeepFlow 的零侵扰可观测性实践
金山私有化项目在可观测性建设中,面临数据孤岛和缺乏全局视图的挑战,影响了问题排查效率。为此,引入 DeepFlow 和 eBPF 技术,打通了指标、追踪和日志数据的联动,提供了全局微服务调用关系。通过分阶段建设,已完成第一期目标,实现了从被动排障到主动观测的转变,提升了系统稳定性和运维效率。
eBPF 零侵扰分布式追踪 3 分钟锁定 Java 程序 I/O 线程阻塞
I/O 线程阻塞是Java 程序经常出现的问题之一,此类故障发生时 Java 程序的请求、响应在 I/O 线程向操作系统 Socket Buffer 读/写过程中发生阻塞,由于在业务代码插桩无法观测到 I/O 线程的工作情况和性能表现,因而导致故障非常隐蔽和难以诊断定位。通过本篇案例您将了解到,某银行的开发工程师如何使用 eBPF 技术带来的零侵扰追踪能力,在某次分布式核心交易系统上线信创平台的非功能测试(性能压测)故障诊断中,用 3 分钟时间锁定 Java 程序 I/O 线程阻塞。
从部署到优化:富途证券的 DeepFlow 探索之旅
本文分享了富途证券引入基于 eBPF 的可观测性方案 DeepFlow,以应对传统 APM 所面临的诸如代码侵入性强和覆盖不全面等挑战的过程。在 TKE 超级节点等复杂场景的落地过程中,我们与社区密切合作,解决了多项兼容性和性能问题。通过 DeepFlow,我们快速定位了一个 DNS 解析引起的 MySQL 超时故障,验证了该方案的价值。未来,我们计划将内部观测平台和 DeepFlow 相结合,以持续拓展其应用场景并优化现有监控路径。
DeepFlow 大模型智能体 3 分钟定位 Java 程序 Hang 故障
Java 程序 Hang 是应用运维中经常遇到的故障类型,由于此类故障与操作系统调度、应用代码逻辑等均有复杂的相互催化关系,故障触发条件极难确定,因此也是故障诊断中最难啃的骨头之一。在此篇案例中您将看到,某银行在分布式核心系统“认证网关 Hang” 故障的诊断过程中,如何使用 DeepFlow 大模型智能体快速分析 Java 程序 CPU 持续剖析数据,在故障发生后 3 分钟内迅速定位出 Hang 的原因。
DeepFlow 最佳实践 —— NVIDIA GPU 指标数据集成及统一观测
在本篇实践案例中,将向您介绍如何在 DeepFlow 可观测性平台快速集成 NVIDIA GPU 指标数据,补充、丰富可观测性数据湖的信号种类,面向 AI 智算场景提供 GPU 指标与主机指标、应用调用指标的统一观测能力,提升 AI 智算应用的质量监控、故障诊断能力。
DeepFlow 最佳实践 —— 主机指标数据集成及统一观测
在本篇实践案例中,将向您介绍如何在 DeepFlow 可观测性平台快速集成主机指标数据,补充、丰富可观测性数据湖的信号种类,在业务异常的诊断过程中,对应用指标监测、分析的同时,快速调阅主机指标数据,快速分析业务异常与主机指标的关联关系,增强 IT 系统监控、诊断的全面性和工作效率。
DeepFlow 最佳实践 —— Blackbox 拨测能力集成及统一观测
在本篇实践案例中,将向您介绍如何在 DeepFlow 可观测性平台快速集成 Prometheus Blackbox 拨测能力,补充、丰富可观测性数据湖的信号种类,一方面通过 HTTP/HTTPS/TCP/ICMP 等协议拨测快速发现业务异常,另一方面在业务异常的诊断过程中,对平台侧应用指标分析的同时,快速调阅拨测的指标数据,增强 IT 系统监控、诊断的全面性和工作效率。
某金融科技公司 x DeepFlow:如何实现 SRE 99.9% 服务级别目标 (SLO)
某金融科技公司是一家位于新加坡全球领先的金融交易科技提供商,目前主要面临的挑战是确保交易系统的高可用性(99.9%)和低延迟(50ms)。为此,某金融科技公司引入了 DeepFlow 可观测性平台,实现零侵扰的全栈监控,快速定位和解决问题,显著提升了运维效率。通过构建 SRE 黄金指标视图,团队能够实时监控和分析服务运行状态,确保系统的高性能和可靠性。
企迈科技 x DeepFlow:爆发式增长业务背后的可观测性平台实践
企迈科技是数字化门店 SaaS 服务的领先者,通过全渠道连接门店与顾客,提升经营效率和竞争力。近几年业务规模迅速扩大,技术架构面临性能和稳定性挑战,促使企迈引入 DeepFlow 作为可观测性平台,通过 eBPF 技术实现零侵扰的数据采集和分析。DeepFlow 帮助企迈优化性能、快速定位问题,并通过全栈调用链追踪和持续性能剖析提升服务质量。未来,企迈计划进一步融合 eBPF 数据与其他监控数据,构建全栈一体化平台,并加强与 DeepFlow 社区合作,推动可观测性技术进步。
使用 DeepFlow 消除 APISIX 故障诊断中的“南辕北辙”
APISIX 被越来越多的用户选择作为 IT 应用系统的入口,由于故障定界能力的缺失,在 IT 业务故障诊断过程中,APISIX 经常成为重点“怀疑对象”,一方面“劳师动众”投入大量运维人力定位,另一方面诊断方向“南辕北辙”,因而业务故障“久拖不决”。通过本篇文章复盘重现某全球领先的智能终端提供商近期对核心业务响应时延劣化故障的处理过程,您将直观了解到“南辕北辙”现象对诊断效率的决定性影响,以及 DeepFlow 可观测性平台如何用数分钟时间、几步简单操作,消除 APISIX 故障诊断中的“南辕北辙”,解决长达两个月悬而未决的问题,为故障处置效率带来飞跃提升。
腾讯云某业务基于 DeepFlow 的可观测性实践
本文分享了腾讯云某业务基于 DeepFlow 的可观测性实践。面对复杂的业务服务(800+)和多样的编程语言,腾讯云某业务团队选择了 DeepFlow 作为跨语言、无侵入的可观测技术。与其他技术(如 Hubble 和 Pixie)相比,DeepFlow 在数据指标、协议支持和扩展能力等方面表现优异,成为最佳选择。引入 DeepFlow 后,腾讯云通过与现有系统的集成,实现了统一的服务性能监控和高效的故障排查能力,显著提升了运维效率,甚至能主动发现业务隐藏的 Bug,防范于未然。
可观测性实战:快速定位 Redis 应用高时延问题
应用连接 Redis 的最佳实践是使用连接池,然而连接池通常会引入很多繁杂的配置。不合理的配置往往会造成性能隐患,并进而导致生产故障。当应用缺乏可观测性时,无法在故障发生前发现隐患,也难以在故障发生时快速定位。本文从一个普通的应用高时延入手,讲述如何使用 DeepFlow 快速定位问题根因。
可观测性实战:快速定位 K8s CNI 端口冲突问题
某车企的车控业务访问账户系统时无规律偶发连接超时(connection timeout),本案例分享利用 DeepFlow 深度剖析如何分钟级定位 K8s CNI 的 SNAT (Source Network Address Translation) 触发 Node 节点源端口冲突,导致连接服务端异常。
可观测性实战:快速定位云服务时延瓶颈
本次案例为某智能汽车公司,业务监控告警发现某充电核心服务 SQL 查询时间偶现超过 200ms,对前方用户影响明显。此问题涉及多团队,仅问题定位就持续了将近 1 个星期未有结论,通过 DeepFlow 的调用日志及分布式调用链追踪的能力,快速定位瓶颈点为云网络抖动导致的,进而直接向云厂商提交工单并附带令人信服的证据。
可观测性实战:快速定位 K8s 应用的时延瓶颈
本次案例为某物流公司在今年 4 月份左右,SRE 通过监控 Nginx 日志,发现一个域名在每天晚上 12 点后存在大量持续 1s 的超时情况,这个问题困扰了用户近一个月。通过查看 DeepFlow 的调用日志,立即排除了业务响应慢的可能性,最终发现问题是 Nginx 自身配置问题导致的。这个案例展示了如何快速的定位 7 层网关时延瓶颈点。
使用全景拓扑持续跟踪云原生应用的压测性能瓶颈
测试小姐姐正在对云原生的电商应用进行压测,但是如何对压测结果进行持续的观测呢?这一直是比较头痛的事情,本文将介绍如何利用 DeepFlow 的全景拓扑帮助小姐姐快速找到瓶颈点。DeepFlow 全景拓扑无需业务修改代码、配置或者重启服务,利用 BPF/eBPF 技术通过对业务零侵扰的方式构建而来,这是一种很便捷且低成本的方式来观测全链路压测的结果。
应用响应时延背后深藏的网络时延
应用异常时,基本可以分为服务访问不通和服务响应慢两个大类。其中服务响应慢的问题定位非常棘手,很多无头案。应用团队有日志和追踪,对于自认为的不可能不合理的事情都会甩给基础设施团队,又由于基础设施团队现有的监控数据缺乏应用的观测视角,通常成为一切「不是我的问题」超自然现象的终极背锅侠,其中以网络团队尤为严重。
可观测性实战:快速定位 K8s 应用故障
故障发生在2023春节前两天,DeepFlow 团队内部访问工单系统出现问题,影响了所有北京区的同事,这篇文章将详细记录如何利用 DeepFlow 定位到对这次问题根因(网关 MSS 误变更导致报文大于 MTU,大数据报文被丢弃)。
K8s 服务异常排障过程全解密
K8s 让应用发布更加快速安全,让应用部署也更加灵活,但在带来这些便利性的同时,也给应用排障增加了 K8s 平台层面的复杂度,本篇文章将以常见的服务异常入手,来详细拆解 K8s 服务访问方式,以及如何利用现有的可观测体系来对 k8s 平台和应用服务进行快速排障。
使用 DeepFlow 开启 DNS 可观测性
我们基于 DeepFlow 构建了对一个高效、可配置、无侵入、面向应用的 DNS 监控面板,可监控 DNS 服务的网络异常、吞吐、时延,以及访问日志,以快速定位性能瓶颈和排查故障原因