原文链接：https://databuff.com/resourceDetail/blog107

前言

笔者最近跑了一些客户，发现虽然云化趋势明显，但很多客户依然存在着大量的“古早应用”在线运行（很早期开发的应用系统），比如银行的老核心、证券业的交易系统、制造业的生产系统等等，他们大多为 C、C++甚至汇编语言编写、大量 JDK 老版本。

这些系统相对封闭，不适合采用当下流行的字节码增强技术，想要对他们上点监控，动作要求相当苛刻。

图：“古早"应用示意图

图：“古早"应用示意图

面对这些特殊场景，笔者公司专门开发了一套基于 eBPF 技术的监控方案，可以用来给这些古早应用做一场 “无创手术”，以补充通用 APM 技术在特殊性场景的短板。我们将这种技术形象的称之为“LightAPM”。

顾名思义“轻量级 APM”，实施上轻量、功能上轻量，既有优点、也有缺点。今天就先带大家看一看，它是如何解决 JDK 老版本的应用监控问题哈。

01 实验场景

我们先来构建一套实验场景，在环境里搭建包含 JDK6、JDK8、JDK11 的混合运行环境：

JDK 8:

JDK 11:

JDK 6:

然后在主机上部署几个服务实例，各服务的运行关系如下所示：

图：各服务之间的调用关系

02 监控实施

笔者公司在产品设计时，已经将 LightAPM 的采集能力封装在了 OneAgent 内部，因此用户不需要单独部署独立的 eBPF 代理，只需要安装一个 OneAgent 就够了。

在 databuff 平台上复制安装命令并在服务器上执行，即可完成 OneAgent 安装（OneAgent 默认开启 LightAPM 的采数功能），整个过程无需修改配置或重启应用进程。

图：复制 OneAgent 安装命令

图：在主机上执行安装 OneAgent 命令

LightAPM 的部署方式真正实现了开箱即用的监控体验，为大规模分布式系统的可观测性建设提供了极致简化的解决方案。

03 监控效果

3.1 服务拓扑自动绘制

OneAgent 部署完成后，LightAPM 会自动绘制出 服务拓扑图，直观呈现各服务之间的调用关系，且各服务是以 servicename 的形式展现在画布上，如下图所示。

图：服务调用拓扑图

在拓扑图上：

• 节点颜色， 表示服务健康状态；

• 点击节点， 可查看性能指标；

• 左侧布局， 展示节点所属的 Pod、进程及所在主机或 Node；

• 右侧面板， 展示告警、请求数、错误率、响应时间等关键指标。

点击拓扑图上的节点，弹出的右侧抽屉会展示该节点的相关信息：属性、告警、KPI 指标曲线。

图：空间拓扑及节点指标监控

说明：想象一下，任何一套黑盒的老旧系统，我们在主机上安装 OneAgent 之后，服务资产及调用架构就全部自动完成了。

3.2 服务自动发现

部署完成后，LightAPM 会将采集到的数据上报到 应用性能监控模块，平台会自动生成服务并展示在服务列表中。（LightAPM 会直接使用通用 APM 模块的功能界面）我们打开服务列表可以看到如下的数据：

图：服务列表

请求耗时：提供 P95、P99 延迟趋势；

调用次数：各节点 QPS 波动情况；

错误监控：错误率及详细错误信息；

系统指标：CPU 使用率、内核态/用户态耗时、网络重传情况等。

点击其中一个服务，进入 服务详情页，可以看到：

图：服务详情页

• 服务的上下游调用关系；

• 各类基础指标（可按实例维度下钻）；

• 服务告警与网络数据；

• 与主机、进程、Pod 的关联信息。

让人惊喜的是，除应用性能指标外，服务相关的基础设施层指标（CPU、内存、流量等） 也能同步获取，自动的实现了应用与基础设施的关联观测。

3.3 服务监控指标

除了拓扑可视化，LightAPM 还提供强大的告警配置和根因定位功能。当触发预设检测规则时，平台通过智能收敛算法聚合告警信息。

Databuff 的 因果 AI 同样适用于 LightAPM 采上来的数据分析，可以输出自动化的问题根因、提供精准的处置建议，如图所示：

图：LightAPM 的指标告警详情

图：LightAPM 的根因分析详情

04 结尾

今天的分享就到这里，我们可以看到过去一直让通用 APM、日志监控方案束手无策的“古早应用”的监控难题，LightAPM 可以帮助解决。

后续，笔者会准备系列文章，一步步的带大家认识 LightAPM 的能力，它是如何与通用 APM 形成互补、共同构成可观测整体方案。