**摘要：**本文分享了金山办公在单元化架构转型背景下，基于DeepFlow可观测性平台在纯Docker环境中的全栈落地实践。面对从K8s微服务架构向单元化架构的演进，团队通过DeepFlow实现了从基础设施到应用层的统一数据采集、性能剖析与智能诊断。文中详细阐述了Docker模式下的部署架构设计、跨环境（IPv6/ARM）适配、性能瓶颈定位、数据联动分析等关键实践，并展望了与AIOps能力融合的统一观测平台建设路径，为企业在非K8s环境下构建高可用、可扩展的可观测体系提供了可复用的经验与方案。
**关键词：**DeepFlow；Docker可观测性；单元化架构；eBPF；全链路追踪；性能剖析；混沌工程；AIOps
本文内容来自金山办公的高级研发工程师肖圆，在 蓝鲸智云 和 DeepFlow 社区联合举办的《觉醒！当AI获得系统感知力》武汉Meetup上的主题分享。
一、可观测性建设背景与目标
随着金山办公应用架构从K8s微服务向单元化架构演进，可观测性已成为支撑架构平稳转型的核心能力。2024年，公司启动可观测性平台级项目，基于DeepFlow在纯Docker环境中构建新一代全栈可观测体系，旨在：
-
支撑架构演进：为单元化架构提供全景监控与性能保障；
-
数据基建先行：积累高质量可观测数据，为后续AI运维与故障自愈奠定基础；
-
实现统一观测：整合基础设施、中间件、应用链路与业务指标，打破数据孤岛。
二、可观测落地实践：Docker模式下的架构设计与调优
2.1 单元化部署架构
在单元化架构中，每个节点部署DeepFlow Agent进行数据采集，监控节点集中部署DeepFlow Server与相关组件；业务APM数据通过OpenTelemetry SDK推送至Otel Collector，并由Agent统一转发至Server端，形成"边缘采集-中心汇聚"的数据管道。
2.2 架构演进与性能瓶颈应对
当前架构中接入 OpenTelemetry 的服务较少，现有方案尚可支持。未来若需将所有服务通过 Otel SDK 接入 APM 数据，当前架构将面临性能瓶颈，需转向第二种部署方案。
该方案将在每个节点上部署一个 Otel Collector，用于采集本节点所有业务的链路追踪数据。本节点数据随后提交至同节点的 DeepFlow Agent，再由各 Agent 统一上报至 DeepFlow Server。由此，可解决 Otel Collector 的性能瓶颈问题。后续我们将对此架构进行调优，并通过性能测试验证其实际表现。
2.3 配置关键点与调优经验
2.3.1 配置关键点
- **部署方式：**采用纯 Docker 模式，所有组件均通过 Docker Compose 启动，并为每个组件设置了资源限制，以控制其运行时的资源消耗。
- **环境变量注入：**在 Server 端需进行全量环境变量注入，经验表明，若未进行注入，在某些场景下（尤其是 IPv6 环境）可能导致数据采集异常，即使服务注册成功，也无法正常采集数据。
- **Agent 配置：**DeepFlow 的 On-CPU 分析功能为我们提供了显著优势，能够以零代码侵入的方式采集业务函数级的性能剖析数据。系统默认仅采集自身数据，只需指定目标业务的进程名称即可启用该功能。同样，Agent 也设置了资源限制。
- **数据安全与协议控制：**对 MySQL、Redis 和 Kafka 的数据进行了脱敏处理。由于这些中间件数据可能包含敏感信息，脱敏既能保障数据安全，也有助于节约存储空间。此外，还明确了需启用的协议类型，目前重点关注其中六种协议。
2.3.2调优经验
- 解决IPV6环境部署适配性的问题
在 IPv6 环境部署适配过程中，曾出现 Agent 无法注册且 Server 端未能识别 Controller IP 的情况。经排查，发现 Server 配置文件中存在多处 IPv6 地址格式不一致的问题，导致配置难以统一使用。在与 DeepFlow 社区反馈并沟通后，确认该问题源于 IPv6 地址书写格式不统一。社区随后进行了相应优化。通过将所有 IPv6 地址统一配置为不带中括号的格式，该问题得以解决。
- 解决系统兼容性的问题
在ARM环境部署过程中，ClickHouse 在不同操作系统下的版本兼容性存在差异。经识别发现，UOS系统无法使用当前最新的ClickHouse 23.8版本，需降至23.5版本方可适配。麒麟系统同样存在适配问题，其Sword版本仅支持较低版本的ClickHouse进行部署。
针对该兼容性挑战，DeepFlow提供了两种解决方案：一是从对应社区获取专用镜像，例如通过鲲鹏官网查询并同步ARM架构的镜像版本；二是使用自建的ClickHouse环境或自行构建适用于ARM架构的定制镜像。
- 解决业务端口与 Server 端口冲突的问题
在部署 DeepFlow Server 时，发现其监听端口较多，其中包括 Data Source 所使用的 20106 端口。由于 A 产品在部署 Server 时已占用该端口，且 A 产品服务与当前服务未部署于同一环境，故未发现此问题。然而，当与 B 产品服务共同部署时，20106 端口被占用导致 B 业务启动失败，功能受到影响------原因在于 Server 先于 B 业务部署，占用了该端口。
向 DeepFlow 社区反馈后，社区迅速响应，将端口配置外部化。通过在 Server 配置中自定义对应模块的端口，并更新镜像，该问题得以快速解决。
三、可观测性实践阶段性成果
3.1 函数级链路数据
以下为可观测性建设的阶段性成果之一：基于函数级别的链路数据实现。通过业务中集成 Otel SDK 并注入 A 标签，系统可上报函数粒度的 Span 追踪数据。在完成联调验证后，该函数级链路数据被证实能够有效满足研发团队对代码层级可观测性的需求。因此，当前观测体系建设已侧重于依托 A 标签实现细粒度追踪与分析。
3.2 DeepFlow实践案例-微服务占用cpu不释放
以下是可观测性实践中的一个性能剖析案例。在对 DeepFlow 架构进行压测时，某服务在压测前占用 0.5 核 CPU，压测期间升高至 1.5 核，但压测结束后仍持续占用 1 核，未能恢复至初始状态。针对该现象，研发团队提出质疑，希望排查是否存在 CPU 资源未释放的问题。
此时借助 DeepFlow 零侵扰采集函数级别性能数据的能力，建议研发团队通过性能剖析图定位具体函数。在生成该服务的性能剖析图并进行分析后，成功定位到导致 CPU 占用持续偏高的函数瓶颈点。
为验证性能剖析图所定位的函数问题，研发团队从服务接口导出了 pprof 报告进行对比分析。结果确认该函数确实存在 CPU 占用异常，原因在于其内部设有定时任务入口，导致压测后 CPU 占用率无法回落。此次对比验证表明，DeepFlow 函数性能剖析图具备较高的准确性，能够为现场 CPU 性能分析提供有效支持。
在私有化项目场景中，环境通常处于内网隔离状态。传统采用 pprof 进行性能分析时，需通过平台生成报告文件并导出至本地，流程较为繁琐。若客户环境限制文件导出，则此方式难以实施。相比之下，DeepFlow 内置的性能剖析图功能可直接在环境中进行可视化分析，显著提升了该类场景下性能诊断的可行性与效率。
3.3 DeepFlow实践案例-MySQL访问延迟
在另一个案例中，本地 MySQL 所在节点负载升高并出现访问延迟。通过 DeepFlow 内置的 Grafana 看板，可观察到多个服务调用 MySQL 时产生大量 5xx 状态码。进一步查看链路详情，清晰显示服务报错源于连接 3306 端口超时。这一案例表明，DeepFlow 的全栈链路追踪功能能够直观呈现此类中间件相关的异常问题。该结果来自于联调环境中 MySQL 节点负载过高时的实际观测，证实了业务问题由数据库延迟引发。
3.4 DeepFlow实践案例-Redis访问延迟
在某故障模拟场景中，通过混沌工程对 Redis 访问延迟进行了主动限制。限制生效后，从全栈链路追踪看板中可清晰观察到因访问 Redis 导致的超时与延迟现象。DeepFlow 能够帮助运维人员快速定位此类中间件访问异常问题。
3.5 系统适配
在系统适配方面，常见的 centos、redhat、ubuntu、suse、uos、kylin 这 6 种操作系统，amd64 核 arm64 两种 cpu 架构，以及 IPV6、IPV4 的 IP 栈都完成了可观测服务的适配。
3.6 数据联动
在数据联动方面，目前已实现监控与可观测能力的整合。该体系以业务 SLO 指标为基础，当 SLO 发生下降时，系统自动关联至对应的服务拓扑视图。该视图以全局视角呈现各业务核心指标，可快速定位出现 SLO 下滑的具体服务及其接口，例如出现大量 5xx 错误或延迟升高的情况。
通过该视图可进一步下钻至指标详情、监控看板及告警事件，从而分析具体问题与接口。此外，服务拓扑视图还支持与日志查询关联，例如基于服务名称（service_name）与 URL（当接口延迟大于3秒时），可通过日志中的结构化字段检索相关接口日志。
通过日志联动可获得对应链路的请求 ID 或追踪 ID（trace ID），进而借助 trace ID 在链路追踪中关联核心调用链路。此时可查看性能剖析图、eBPF 采集的指标与日志数据，并结合函数级性能拓扑进行深度下钻，实现问题的精准定位与分析。
四、可观测建设后续规划
**第一，应用侧全链路接入：**为将APM数据全面集成至DeepFlow平台，需推动各业务线统一遵循OpenTelemetry SDK标准进行接入。计划于第三季度完成所有核心业务的服务链路接入工作。
**第二，统一观测平台的建设：**当前基于Grafana看板的观测方式在数据联动与使用体验上存在不足。为此，将着手开发新一代可观测分析平台，旨在实现指标、日志、链路、拓扑四维数据的深度融合与关联分析，构建体系化的多维度观测能力。
**第三，有效性验证体系：**计划基于混沌工程技术，针对从客户现场收集的典型故障场景进行模拟演练。通过模拟验证可观测体系的实际效能与价值，并据此输出标准化处置预案（SOP），使现场运维能够依据SOP快速定位与解决问题。
**第四，引入 AIOps 能力：**在完成可观测数据基础建设与积累后，将依托自有AI大模型能力，通过MCP Server等架构与大模型技术栈进行集成。目标实现智能巡检、异常模式识别、故障根因分析等智能化运维场景。后续将优先完成可观测平台建设，并逐步整合AI与自愈能力，最终形成闭环的智能可观测平台。