我们这边可能是 DeepFlow 社区版在真正的在 Docker 模式下的做了一个落地实践探索。然后可能中间有一些经验可以跟大家去做一些分享。今天从这三个方向，一是，可观测性建设现状；二是，可观测落地与实践，最后，是可观测后续规划。
去年金山办公主要是基于 K8S 微服务架构做了可观测建设的探索实践，今年，由于应用架构从 K8S 逐渐演变为单元化架构，我们的战略也做了调整，可观测作为核心能力模块成为公司级项目。所以今年主要的目标是为了配合架构演进需求，技术团队将基于 DeepFlow 可观测平台，在纯 Docker 环境中构建新一代的全栈可观测体系，为架构转型提供坚实的技术保障。另一方面，这些可观测数据也是为后续 AI 的接入和故障自愈的落地做一些数据的保障。
01｜可观测落地与实践
首先，看一下我们在 Docker 环境落地部署的单元化架构。单元化架构中的每个单元均包含完整的业务逻辑，可独立运行和扩展。在每个节点上都会有 DeepFlow Agent 来采集数据，这些数据会汇总到我们的一个监控节点上，也就是部署了可观测服务的这个节点上去。
在 DeepFlow 可采集到的数据基础上，我们也接入了业务的 APM 数据，每个节点的 APM 数据业务会通过 OTel SDK 去推送到我们的 Otel Collector 里面去。然后我们 Otel Collector 会再把 APM 数据集成到 DeepFlow Agent 里面。
目前这个架构下接入 Otel 的服务比较少，还是可以落地的。未来要实现所有服务接入 Otel SDK 来接入 APM 数据的话，从现在的这个架构来讲会存在两个瓶颈。第一个是 Otel Collector 的性能问题，现阶段是一个节点上取了一个容器，当所有业务的数据都往这一个容器上推送的话，一旦 Otel Collector 出现性能问题，就会导致我们的业务的 APM 数据会无法去聚合。
第二个是我们的 Agent，因为 Agent 自己有熔断策略，它基于部署节点的负载自己会识别熔断的阈值来做宕机的策略。这些节点上同时也部署了很多 DeepFlow server，它也是会有一些资源消耗的，一旦这个节点负载稍微上升那 Agent 就可能不工作了。这中情况也会导致 Otel SDK 的数据可能也过不来。以上是目前这个架构存在的两个性能瓶颈的地方，后面随着业务接入越来越多，我们会采取第二种架构。
那第二种架构就是在我们的每一个节点上面都会布一个 Otel Collector，来收集本节点上所有的业务 trace 数据。然后本节点数据会给到本节点的 Agent，然后每个节点的 Agent 会集中到 DeepFlow server 端，这样的话就解决了 Otel Collector 性能瓶颈问题。后续我们会针对这一架构做出调整，调整之后会去做一些性能测试，看这种新的架构的性能怎么样。这是部署架构这一块儿。
部署方式上我们用的是纯 Docker 模式，所以都是 Docker compose 起的，针对每一个组件都有一个资源的 limit。因为它有一些消耗所以要做一些资源 limit。
另外在 server 端这一块，我们在 docker 模式适配的下会发现有一些问题，图中标红的这块内容要去做全量的变量注入。我们之前发现如果不注入的话，可能在一些场景下特别是在 IPV6 场景下会有问题。虽然能注册成功，但是它可能采集不到数据。
后面就是 Agent 的一个全局配置。这里标红的地方是我们这边比较注重。在 On CPU 这块儿 DeepFlow 对于我们来讲其实是一个福利。就是我们可以去零代码来采集业务函数级的性能剖析图。DeepFlow 默认只采集自身的数据，我们只需要指定采集的业务的进程名称就可以了。然后 Agent 也是有一个资源的 limit。
右边这部分的内容，我们也做了 mysql redis 和 kafka 的数据脱敏限制。因为这样用我们这些中间的数据可能有一些敏感的信息，做脱敏能在一定程度上降低一些存储的空间。另外，我们也指定启用了一些我们所关注的协议，现在关注的就是这六种协议。
接下来分享我们在适配期间的一些经验。第一个就是适配 Docker 模式的情况下，因为以前在 K8S 的情况下链路这一块儿的客户端和服务端可能直接显示 pod 的名称，所以更容易去看问题，去绘制业务全景图。
但是在 Docker 模式下， DeepFlow v6.6 版本中暂未加入对 Docker 环境的适配，链路上都是以 IP 的形式显示，无法识别 Docker 容器的名称。我们现在的微服务也都是 docker-compose 起的，而且也是 host 网络。所以对于当前的版本对 Docker 来讲没法直接显示微服的容器名称。这样不能直观的看到底是哪个服务访问哪个服务，而且对于绘制拓扑图也有一定的影响。目前对于 Docker 容器的识别我们是通过 eBPF 采集到的进程名称（容器需使用宿主机网络）+IP+PORT 进行判断，来解决这一问题。
第二块就是 IPV6 环境部署适配性的问题。我们在适配的时候发现 Agent 注册不上，Server 端没有 Cont roller IP，经排查后发现 Server 配置文件中存在多处配置格式不统一不太易用，向 DeepFlow 社区反馈并沟通之后，发现是我们在做 IPV6 时地址格式不统一而导致的，同时社区也做了一些更新。我们把所有的 IPV6 的地址以不带中括号的形式去统一的配置更新后这一问题就得到了解决。
第三块是 ARM 环境部署时遇到的问题，我们用的 ClickHouse 也是 DeepFlow 官方，对于不同的操作系统 arm 环境来说 CK 的版本兼容性是不一样的。我们在做操作系统识别的时候，发现 UVS 系统是用不了现在 CK 最新的 23.8 这个版本，所以它只能降到 23.5 这个版本才能适配在 UVS 系统。还有麒麟系统也是适配的时候有一些问题，麒麟有两个版本其中 Sword 这个版本，它也只能用低版本的 CK 才能去部署。DeepFlow 官方给出了两种解决方式，一是去对应社区拉取景象，例如去鲲鹏的官网查询同步 ARM 的镜像版本；另一种是实用自建 CK 环境或自定义构建 ARM 版本镜像。
第四是业务端口与 Server 端口冲突的问题，在部署 DeepFlow server 的时候，发现它其实有很多监听端口，其中有一个 data source 的 20106 这个端口。我们的 A 产品在部署 server 的时候已经占用了这个端口，但因 A 产品的服务跟我们的服务不在一起，所以没发现这个端口的问题。但在跟 B 产品的服务布在一起的时候，就发现这个 20106 端口把业务端口给占用了，导致业务起不来功能受到影响，因为是先部署的 Server 后部署的 B 业务。当我们跟社区反馈沟通之后，社区很快速的就把这个端口给暴露出来。我们通过在 Server 配置中自定义模块所用的端口，并更新镜像之后很快就解决了这个问题。
下面是 DeepFlow 大版本升级的注意事项，像 DeepFlow V6.5～V6.7 这些大版本升级的话是不支持版本回退的。因为每个版本对参数和结构都有一些变化，所以只支持升级版本。目前金山办公用的是 V6.6 版本，马上要验证升到 V7。因为 DeepFlow V7 对一些资源的占用做了优化，这恰恰也是我们所重视的问题之一。
