原文链接:​​​​​​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形成互补、共同构成可观测整体方案。

Logo

更多推荐