随着云原生技术栈的迅速发展，系统复杂性逐渐下沉到服务网格、网关、通用 sidecar、serverless 运行时、内核等基础设施层面，给可观测性带来了巨大的挑战。本文结合真实的排障案例，介绍了火山引擎云原生团队在容器全栈观测方面的技术实践。
来源 | 火山引擎云原生团队
一、容器观测的挑战
近年来，伴随云原生技术栈的迅速发展，越来越多工程师开始借助容器、Kubernetes、服务网格等基础设施快速搭建云原生应用架构，将系统架构的复杂性封装至 Kubernetes 基础设施，从而让自身能更加聚焦业务逻辑本身，极大满足业务敏捷迭代、高效运维、极致弹性的诉求。
伴随云原生应用架构基础设施透明化、架构组件逐渐增多、组件依赖愈发复杂，Kubernetes 面向终态的声明式服务定义对系统的可观测性和稳定性保障造成了严峻挑战。针对上述现象，我们对线上排障问题工单进行了分析，并对技术服务支持团队做了一些内部调研，得出了以下观察：
仅有 35% 的问题工单有关联的告警事件，多数用户未开启相应组件指标监控及告警策略配置，导致故障感知滞后 。根据受访者反馈，很多工单是由于用户不熟悉 Kubernetes 全栈的技术组件导致的，用户无法将故障场景和采集指标及告警事件进行关联，不了解各观测组件指标用途，所以需要技术服务团队提供引导支持。
70% 疑难工单集中在容器网络，且 95% 以上耗时超 30 分钟 。技术服务团队在进行容器网络排障时，往往需要结合自身经验判定故障边界，然后借助抓包工具进行根因分析，这通常会涉及到对网络连通性检查、路由策略配置、DNS/Ingress 组件资源监控、应用服务进程等多个故障点的多类型数据（指标、日志、事件、flow ）进行关联分析，对于工程师的综合技术能力要求极高。
10% 的受访者担心侵入式观测能力对业务性能和稳定性的影响，广告和游戏业务尤为凸显 。广告和游戏业务通常对业务的高并发、低时延有明确要求，用户担忧基于 SDK 或类 Java agent 字节码增强的侵入式观测增强技术与业务代码冲突，从而引发线上故障或过高的性能损耗。
二、容器全栈观测建设路径
面对上述容器观测挑战，火山引擎云原生团队把自身在排障过程中的专家经验融入容器全栈观测产品的落地实践中，依据全栈观测对象的故障频次和影响范围，将建设路径分为： 基础监控覆盖、网络观测增强、观测数据融合、智能观测探索四个阶段。
基础监控覆盖：注重分层观测对象监控指标的完善，构建分级的指标管理策略 。在实际的排障定位流程中，工程师接收观测对象的告警事件，并分析其在故障时间段内相关指标的波动变化，这仍是最基础且最有效的观测方式。同时，鉴于容器全栈观测对象的复杂多元性，不同观测对象的指标定义、采集规则以及视图看板需依据用户的业务场景和管理需求进行个性化配置。持续完善和维护分层领域观测对象的监控指标以及配置管理，是建设容器全栈观测套件首先需要解决的问题。因此，在产品实践中我们针对云原生分层领域对象制定了分级指标管理规则，允许用户通过观测组件自行配置观测组件采集的指标范围、告警策略，并提供一键默认规则配置，这有效地提高了用户指标接入的效率，降低了其维护成本。
网络观测增强：借助 eBPF 包过滤技术增强网络观测能力构建因果观测视图 。在云原生应用架构下，业务请求所涉及的分层架构组件和服务间的访问依赖关系错综复杂。我们可以从业务运行时的实际流量着手，凭借 eBPF 深入系统内核采集的 L4/L7 Flow 数据，构建自顶向下分层架构组件的纵向空间依赖视图以及相同领域分层不同资源对象访问关系视图。与此同时，以时间为锚点追溯任意时间范围的动态架构，达成故障现场历史回溯，辅助用户构建清晰的因果排障路径。此外，工程师通过因果观测视图确定故障边界后，能够借助 VKO 分布式网络抓包能力获取该故障节点指定时间范围内的网络堆栈明细，进一步展开故障根因分析，提高容器复杂网络环境的排障效率。
观测数据融合：优先在采集端完成业务语义注入建立多模观测数据映射关系 。针对不同对象的多模观测数据（指标、日志、链路、事件等）可借助云资源标签、Kubernetes 资源对象标签、应用进程标签、自定义业务标签等业务语义前置完成数据的关联设计来丰富观测数据，并结合时间维度构建数据的联动关系。观测数据全生命周期分为数据埋点、数据采集、存储写入、视图渲染 4 个阶段，考虑到性能和维护成本，我们将产品定义的业务语义沉淀到接入产品的不同观测采集插件中，优先在数据埋点、数据采集阶段进行业务语义注入，避免后置元数据映射造成的资源消耗、延迟过高、数据关联不准等问题。
智能观测探索：借助业务语义关联和 LLM 强大推理能力助力 AIOps 场景落地 。在观测数据协议标准化、多模观测数据联动的基础上，我们借助沉淀的专家领域知识和历史故障库，结合 LLM 强大的自然语言处理和涌现的推理能力，已在字节跳动内部实践了专家知识问答、故障根因分析等经典的 Copilot 智能助手推动 AIOps 场景落地，即将对外开放供用户使用。产品的核心期望并非依赖 Copilot 完全自主找到问题根因，而是专注于在排障过程中为工程师提供有价值的信息增益，最大程度缩短事故定位—止血的时间。
三、VKO 容器全栈观测产品实践
Kubernetes 观测 VKO （全称 Volcengine Kubernetes Observability）是火山引擎云原生团队结合字节跳动在 eBPF 可观测性技术方面的沉淀和容器管理运维实践推出的一站式容器全栈观测套件，它通过深入内核采集运行时、存储层、网络层、应用层等观测数据，将可观测数据自动与 Kubernetes 元数据进行关联，以标准化语义打通流量与资源之间的串联关系，实现自顶向下的容器全栈观测场景覆盖。致力于帮助用户闭环云原生应用架构下的一站式观测能力，辅助用户事前快速感知问题、事中高效定位问题、事后问题根因分析。
3.1 产品核心特点
All in one 容器全栈观测生态体系 ： VKO 在传统容器基础观测能力之上拓展 Kubernetes 生态组件、容器网络和应用层观测场景，构建 All in one 的泛容器域全栈观测生态体系。 支持操作系统内核、容器网络性能、Kubernetes 集群组件、AI Infra 、业务应用等容器分层资源对象的全栈观测场景。
基于 eBPF 实现高性能、无侵入的网络&应用性能观测 ：相较于常规应用层基于 SDK 手动观测埋点或基于 Java agent 自动观测埋点方式存在对业务代码/框架侵入性强、性能损耗高、维护成本高等问题， 我们选型 eBPF 技术落地云原生应用架构的网络与应用流量拓扑、自动业务语义注入及 CPU Profiler 性能分析等深度观测能力。产品通过 DaemonSet 方式在节点部署 eBPF Agent 即可在系统内核完成 FLow 数据采集，实现从流量入口到系统内核的全栈观测能力，达成无关开发语言及框架、无需修改业务代码、无需重启应用的设计目标并在真实线上业务测试中对 TPS 几乎无影响，真正满足用户零侵入、低损耗、清晰定界的观测诉求。
基于拓扑串联打通可观测性数据孤岛 ：VKO 提供以拓扑为核心的因果观测排障视图纵向以 Kubernetes 原生资源为索引下钻串联 Metrics、Logs、Events、Tracing、Profiling 等观测数据，横向通过流量（Flow）、Trace 串联打通各个可观测性数据孤岛，帮助用户构建清晰排障路径，有效提升故障定界效率。
3.2 产品核心能力
◇
丰富分层观测 对象接入构建容器全栈指标体系
VKO 面向容器全栈资源对象提供丰富观测组件，用户可结合自身业务场景和管理需求对指标范围、告警策略、采集资源规格等进行个性化配置。目前产品已开放观测组件 12 个，开放观测指标 2000+，覆盖容器基础资源监控、控制面组件监控、网络流量监控、应用性能监控、AI 资源监控、多云观测等 90% 以上容器排障定位场景。此外，为简化用户配置产品提供清晰接入引导支持核心观测组件自动开启和默认指标范围一键配置，有效降低用户维护管理成本。
◇
资源多维视图聚合及高效检索提升排障效率
VKO 将 Kubernetes 原生工作负载、容器组（Pod）、服务、Ingress 等核心资源对象的基础资源观测、应用性能观测、网络性能观测视图以单个资源维度进行聚合，实现多模观测数据：指标、链路、日志 & 事件（整合中）有机融合，并提供按资源标签的快速检索能力满足用户对已识别的单个异常资源对象进行深度分析，有效提升单个资源排障效率。
◇
构建准实时动态拓扑辅助用户有效故障定界
VKO 凭借 eBPF 的无侵入 L4/L7 层流量解析能力，自动发现 Kubernetes 特定命名空间范围内核心资源的访问拓扑，允许用户自定义错误率、延迟、QPS 指标阈值呈现拓扑图节点或连线的健康变化情况。此外，产品支持用户指定故障时间范围可进行故障现场的历史回溯，辅助用户高效地识别故障边界并分析系统性能瓶颈。
◇
L4/L7 链路分析精准识别单请求故障及性能盲点
相较于传统应用协议观测使用有代码侵入性的 SDK 或者有特定语言的采集 Agent （典型如 Java Agent），VKO 针对 L4 网络层（TCP、UDP 等）、 L7 应用层（HTTP、DNS、gRPC 等）流量的请求链路追踪能力。用户可在节点上开启链路跟踪配置按固定比例采样节点与外界的网络通信，截取其收发信息，分析其发送、接收等耗时。考虑到观测质量和观测成本的平衡，目前产品仅支持单笔请求收发客户端和服务端的链路关联，暂未支持单笔请求全链路调用链追踪能力。结合实际排障经验动态访问拓扑关系比单笔链路明细的价值更高且拓扑构建无需依赖链路明细，用户可优先通过动态拓扑识别故障边界后锁定存在故障或性能瓶颈的一对收发节点（即拓扑连线）分析该收发节点的链路明细分析请求链路的故障根因。
四、实际场景排障案例
4.1 入口流量偶发异常分析
Ingress 作为服务流量入口，一旦出现异常将引发请求方大面积故障，同时也是我们进行故障定位的首站。 相较于传统 APM 仅限于应用层的观测数据采集，VKO 借助 eBPF 可全面覆盖了 Ingress 观测场景，支持 Ingress 组件的基础资源监控、网络和应用层性能监控，可针对 Ingress 代理的后端服务进行深度分析，并结合 Span 链路明细进行根因定位。
故障现象 ：在实际故障案例中，用户使用 ingress-nginx 作为 Ingress 组件代理后端 HTTP 服务提供集群外部流量接入，在指定时段客户端访问 Ingress 组件偶发的 499 报错现象，怀疑 ingress 组件异常造成业务受损。
排障路径 ：借助 VKO 的 ingress 观测和操作系统深度观测发现 ingress 资源消耗和网络指标均正常，但是后端请求响应时间 P90 出现了波动，进一步使用 VKO HTTP 链路请求追踪功能发现是由于部分请求的响应处理较慢，最终定位到后端响应数据过大，触发分片过多导致处理时长超过客户端的超时配置，引发客户端超时。经过对 ingress 和后端服务的参数调优后，最终将出现 499 的频率下降到 0.01% 。
4.2 DNS 服务请求故障分析
DNS 故障问题在日常排障中极易忽略，其故障表现通常不是表现为直接报错更多是以服务请求延迟增加现象呈现。一般情况下，遇到服务请求延迟增加，工程师极易关联到应用程序自身问题或依赖其服务提供方的接口访问延迟，导致难以有效进行故障定位及时进行故障恢复。VKO 不仅支持常见的 HTTP/HTTPs、gRPC 等应用层协议，额外支持 DNS 协议分析能力，对于工作负载、容器组等观测对象给出了 DNS 观测视图，方便用户快速定位分析 DNS 解析异常问题。
故障现象 ：某广告业务客户部署其实时广告投放业务，对业务延迟非常敏感。业务使用火山引擎弹性容器引擎（VCI）作为底座，在某天的业务切换扩容过程中，收到网关侧连接数接近上限的告警，借助 VKO 观测发现部分业务并发连接数的突增，并且伴随出现拒绝连接日志报错。
排障路径 ：用户找到根据告警事件找到报障容器组 Pod，通过 VKO 资源检索找到该资源对象进入观测详情，查看应用性能监控选择以客户端视角分析该 Pod 请求服务提供方 RED 指标状态发现请求均存在延迟过高的情况，因此初步推断为单个服务或单个接口问题，随后查看 DNS 指标观测视图发现请求延迟明显，并找到相关保障 Pod 均发现相似问题初步判断 DNS 导致服务异常。随后，通过组件关联跳转至依赖的 coreDNS 组件，进一步查看 DNS 资源水位在故障时间范围内，CPU、内存均出现突升并在高水位持续运行，最终通过扩容 DNS 副本数资源水位恢复正常，服务 DNS 请求时延恢复到正常水平，业务随即恢复。
五、未来规划
VKO 容器全栈观测套件产品定位支持用户闭环 cloud native/AI native 应用构建端到端观测能力，未来规划聚焦于 APM 应用层观测生态打通和 AI infra 观测能力持续完善。
VKO 在采用 eBPF 技术实践容器全栈观测的过程中，也意识到其在应用层链路观测的局限性，仅借助 eBPF 技术难以实现单进程内跨线程切换过程中精准的链路串联，无法做到精准关联对排障工作可能存在误导，因此我们计划与云上 APM 应用观测生态打通，通过采集的兼容 OT 开发数据协议的链路数据解决进程内跨线程链路串联问题构建完整的应用层链路追踪能力。
此外，随着 LLM 应用的高速发展，VKO 针对大模型应用在训练、推理过程中存在资源利用率低、性能与稳定性挑战、模型效果不佳等诸多问题，从资源、网络、应用层逐步完善泛容器域 AI infra 观测能力，帮助用户构建 LLM 应用全栈观测能力，优化 LLM 资源使用提升排障效率。
欢迎感兴趣的用户咨询：
相关链接
[1] Kubernetes 观测：基于 eBPF 的云原生深度可观测性实践
[ 2] 弹性容器实例：敏捷和安全的双赢，我们是怎么帮助客户实现的？
[4] 火山引擎: www.volcengine.com