您的关键遗留应用程序是黑盒子？让我们在 5 分钟内改变它！
几乎所有成熟的企业中，都有 THAT 一个系统。它在角落里运行，多年来执行着关键功能。它可靠，但它也是一个完全的黑盒子。没有人想触碰它，害怕弄坏它，而且原始开发者早已离职。它可能是 90 年代的核心银行账本、仓库中的物流路由引擎，或者是工厂车间的数据聚合器。你知道它能工作，因为，嗯，它还没有出过故障……到目前为止。
最终目标很明确：我们需要重写或迁移此应用程序到一个现代、可扩展且可维护的平台。但这样的项目需要数月甚至数年。在此期间我们该怎么办？我们不能在黑暗中操作。
虽然 OpenTelemetry 因其在现代云原生架构中的作用而受到赞誉，但其价值不止于此。事实上，它为那些并非云原生的系统提供了一种强大但常常被忽视的解决方案。它充当了现代化的桥梁。通过今天让我们对遗留应用程序有一定程度的可见性，我们可以降低其运行风险，为其更换做计划，并为其未来建立数据驱动的业务案例。让我们一步步看看如何用一个模拟的遗留应用程序来实现这一点，而且无需更改其代码的一行。
OpenTelemetry：现代可观测性，适用于遗留代码
为了模拟一种常见的遗留模式，我们构建了一个简单的应用程序。一个用 C 编写的核心可执行文件（模拟系统级进程）启动一个 Java 虚拟机 (JVM) 来处理特定任务，例如处理事务或记录。
流程如下：
C Application (legacy_app) -> starts JVM -> calls a Java method to process a task
当我们运行 ./legacy_app 时，它可以工作。但我们无法回答关键问题：它能否跟上业务需求？它是否会在日终处理过程中耗尽内存并崩溃？上周的客户投诉是否由这个应用程序的缓慢引起？
让我们找出答案。
第一阶段：基本健康监控（系统是否稳定？）
我们的第一个目标是监控应用程序的关键指标。我们需要查看其 CPU 和内存使用情况，以确保它不会即将发生故障。我们可以通过 OpenTelemetry Java 代理来实现这一点，只需通过 JVM 启动参数中的 ` -javaagent` 标志将其附加到应用程序。在我们的示例中，我们可以使用 `_JAVA_OPTIONS` 环境变量来实现。
第一步：设置环境
在我们的终端中，我们将配置代理，而无需更改应用程序本身。
# --- Part 1: Basic System Health Configuration ---
# 1. Give our service a descriptive name
export OTEL_SERVICE_NAME=legacy-part-processor
# 2. Enable ONLY the metrics exporter
export OTEL_METRICS_EXPORTER=otlp
# 3. Point the agent to the collector's gRPC endpoint
export OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4317
# 4. Specify OTLP protocol
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
# 5. Enable runtime metrics for Java 8
export OTEL_INSTRUMENTATION_RUNTIME_TELEMETRY_JAVA8_ENABLED=true
# 6. Attach the OpenTelemetry Java agent
export _JAVA_OPTIONS="-javaagent:./opentelemetry-javaagent.jar"
第二步：运行未修改的应用程序并确认其正常工作
./legacy_app
首先，让我们验证我们的遗留应用程序是否正在运行。快速查看终端日志，可以看到一条持续的消息流，确认我们的进程运行正常。
[C Wrapper] Reading new Part ID from assembly line: 3035
[Java Processor] Received Part ID 3035. Fetching processing parameters...
[Java Processor] Part ID 3035 processed successfully.
[C Wrapper] Processing request for Part ID 3035 completed successfully.
[C Wrapper] Reading new Part ID from assembly line: 3036
[Java Processor] Received Part ID 3036. Fetching processing parameters...
[Java Processor] Part ID 3036 processed successfully.
[C Wrapper] Processing request for Part ID 3036 completed successfully.
[C Wrapper] Reading new Part ID from assembly line: 3037
[Java Processor] Received Part ID 3037. Fetching processing parameters...
[Java Processor] Part ID 3037 processed successfully.
[C Wrapper] Processing request for Part ID 3037 completed successfully.
来自我们应用程序的数据遵循标准路径：OTel 代理将指标发送到 OpenTelemetry Collector，然后 Prometheus 抓取这些指标进行存储。然后，我们使用 Grafana 连接到 Prometheus 并可视化数据。由于这是一个常见且文档完善的设置，我们将跳过具体的配置文件，直接介绍这种可见性允许我们看到的内容。
第三步：构建基本的监控仪表板
这是所有工作汇集在一起的时刻。现在我们可以进入 Grafana，只需三个简单的查询，即可立即构建我们的第一个仪表板。就这样，我们为应用程序获得了基本监控，涵盖了平均 CPU 利用率、平均内存消耗以及垃圾回收所花费的时间。
结果：为我们的遗留应用程序提供基础健康指标！
通过这一个更改，我们建立了一个基础的可观测性层。关键的 JVM 指标立即开始流向我们的后端，提供回答关键运营问题所需的数据。
- 内存使用：我们的应用程序是否在泄漏内存？它会在业务高峰时崩溃吗？
- CPU 负载：在高峰期，进程是否落后了？
- 垃圾回收：应用程序频繁的“暂停”是否会导致其他服务级联超时？
我们已经从一个完全的黑盒子转变为拥有一个实时健康仪表板。
第二阶段：性能指标（系统是否高效？）
健康是一回事，性能是另一回事。在审查代码后，我们可以看到我们应用程序的核心逻辑位于 `processTransaction()` 方法中。但是，静态代码无法回答动态问题。在实际负载下执行此操作需要多长时间？它是否是瓶颈？
第一步：更新环境
我们添加了几个环境变量来告诉代理专门测量该方法。对于无法修改应用程序源代码的情况，OpenTelemetry 的 Java 代理提供了一个强大的解决方案：otel.instrumentation.methods.include。此设置允许您指示代理自动创建围绕特定方法的跨度。
# --- Part 2: Application Performance Configuration ---
# 1. Enable traces exporters
export OTEL_TRACES_EXPORTER=otlp
# 2. Tell the agent which method to instrument
export OTEL_INSTRUMENTATION_METHODS_INCLUDE="LegacyJavaProcessor[processData]"
第二步：运行应用程序并修改现有仪表板
我们现在收集的跟踪跨度是更丰富的仪表板的原始材料。我们的 OTel Collector 配置为分析这些跨度并生成应用程序监控的“黄金信号”。让我们回到 Grafana，并添加三个核心指标的图表：每分钟调用次数、平均响应时间和每分钟错误次数。
结果：为我们的遗留应用程序提供核心业务 KPI！
OpenTelemetry 代理现在测量每一次事务。使用带有 spanmetrics 连接器的 OTel Collector，我们可以获得关键的性能指标。
延迟（处理时间）：我们终于知道处理一个事务需要多长时间。它足够快吗？我们达到了我们的 SLO 吗？
吞吐量（每分钟调用次数）：我们可以看到每分钟处理多少事务。我们的系统能否跟上需求？它能否处理峰值负载？
错误率（工作质量）：我们现在可以跟踪我们业务逻辑本身的健康状况。我们的失败率是多少？我们能否在问题升级之前发现它们？
总结与行动号召
有时，即使是有限的可见性也远胜于完全盲目飞行。通过仅用几个环境变量和 OpenTelemetry 代理来检测您的遗留黑盒子，您无需进行有风险的代码更改或昂贵的改造，就能获得可操作的见解。这不仅仅是技术上的胜利，它是一项战略性的进步。有了真实的数据，您就可以做出更明智的决策，主动解决潜在问题，并在规划未来时建立信心。
即使您的第一反应是您的应用程序太老旧而无法从 OpenTelemetry 中受益，但仍然值得验证您的技术栈。大多数情况下，都有办法进行检测——即使无需修改代码。生态系统在不断发展，许多框架和平台现在支持代理式或 sidecar 式检测，使得提取甚至最旧系统的有价值遥测数据比以往任何时候都更容易。
请记住：今天获得的每一份可见性，都在为您争取时间、增强弹性，并为您提供安心，直到您的现代化之旅完成。