5分钟内给你的关键系统添加监控

🧩 引言：那个谁也不敢动的“老系统”

在每家企业里，总有那么一个“遗留系统”： 运行了十几年，从 COBOL 到 Java，不停地打补丁，但从没人敢改。

它也许是银行的账本引擎、工厂的工序调度程序、物流中心的路径算法模块…… 稳定，但封闭；可用，但不可见。

问题是，当它出问题时，你什么都看不见： 系统是否卡死？哪一段代码最耗时？有没有内存泄漏？

完全不可观测，就像在黑暗中驾驶。

而今天我们要做的，是用 OpenTelemetry（简称 OTel）， 仅需几条命令，不改一行代码， 就让这个“黑盒子”发光 🔦。

💡什么是 opentelemetry-javaagent？

如果你想让一个旧系统具备“可观测性”，但又不能修改源代码， 那么 OpenTelemetry Java Agent（otel-javaagent） 就是你的秘密武器 🧠。

它是一个 自动探针（Auto Instrumentation Agent）， 以 .jar 文件形式存在，比如：

opentelemetry-javaagent.jar

当你启动 Java 程序时，只要加上一句参数：

-javaagent:./opentelemetry-javaagent.jar

它就会在程序运行过程中自动注入监控逻辑， 捕获 性能指标、链路追踪、异常信息 等关键信息， 并将这些数据上报给 OpenTelemetry Collector。

📊 无需修改源代码，你就能立刻看到：

• 程序健康指标（CPU、内存、GC）
• 请求链路与耗时
• 方法级性能瓶颈
• 错误与异常统计

为什么它特别适合遗留系统？

因为：

• 不用重编译；
• 不影响业务逻辑；
• 可随时开关；
• 对性能影响微乎其微（通常 <3%）。

对那些“没人敢动”的旧系统来说，这几乎是唯一的安全选项。

🛠️ 阶段 1：基础健康监控 — 系统还能活得下去吗？

✅ 目标

在完全不改动源代码的前提下，快速了解系统的运行健康状况。

⚙️ 环境配置

我们利用 opentelemetry-javaagent 给 JVM 加上监控功能，只需设置环境变量：

# — 基础系统健康配置 —
export OTEL_SERVICE_NAME=legacy-part-processor
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4317
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_INSTRUMENTATION_RUNTIME_TELEMETRY_JAVA8_ENABLED=true

# 将 agent 附加到 JVM 启动参数里
export _JAVA_OPTIONS="-javaagent:./opentelemetry-javaagent.jar"

完成后，直接运行你的旧程序：

./legacy_app

你仍能看到原来的日志输出，例如：

[C Wrapper] Reading new Part ID: 3035  
[Java Processor] Received Part ID 3035.  
[Java Processor] Part ID 3035 processed successfully.  

说明应用依旧正常运行。 此时，OTel Agent 正在后台收集数据。

📈 数据流向

OpenTelemetry Agent → Collector → Prometheus → Grafana

你可以在 Grafana 中创建基础监控面板（Dashboard），包含：

• 平均 CPU 使用率
• 内存占用
• JVM GC 停顿时间

这样，你就能回答关键问题：

• 是否存在内存泄漏？
• CPU 负载是否异常？
• GC 频率是否导致响应延迟？

到这里，黑盒系统至少有了“生命体征”。

⚡ 阶段 2：性能监控 — 它到底能跑多快？

仅有健康指标还不够，我们还要知道： 业务处理性能到底怎样？是否存在瓶颈？

假设核心逻辑在 processData() 方法里， 我们希望测量它的耗时、调用频率与错误率。

在环境变量中加入：

export OTEL_TRACES_EXPORTER=otlp
export OTEL_INSTRUMENTATION_METHODS_INCLUDE="LegacyJavaProcessor[processData]"

这表示： 👉 自动为 LegacyJavaProcessor 类中的 processData() 方法创建追踪片段（span）。

重启应用后，追踪数据会进入 Collector， 并通过 spanmetrics 转化为指标，最后在 Grafana 中展示：

• 吞吐量（Calls per Minute）
• 延迟（Processing Time）
• 错误率（Errors per Minute） 一目了然 👀。

🧭 最后总结：让“黑盒子”变透明的第一步

哪怕只有一点点可见性，也比彻底的盲区强得多。

通过简单地引入 opentelemetry-javaagent， 你就能做到：

✅ 零代码改动 ✅ 快速可视化系统健康状况 ✅ 自动追踪性能瓶颈 ✅ 降低运维风险，为未来重构积累数据

也许你的系统很老，但这不代表它永远是黑盒。 只要你迈出这一步，就能一点点点亮它 🌟。

💬 写在最后

OpenTelemetry 不是只有“云原生”才能用。 它也能帮我们一点点地理解、修复、改进那些看似不可触碰的旧系统。（这也是为什么现在单体应用又有取代微服务的趋势的原因之一）

让可观测性从“新系统标配”， 变成“遗留系统的救命稻草”。

原文作者Lukasz Ciukaj (Splunk) | Thursday, September 04 2025https://opentelemetry.io/blog/2025/opentelemetry-for-legacy-app/