Java中的可观测性：面向专家的追踪、指标与日志

Java中的可观测性：从“为什么崩溃了？”到“我知道一分钟内会发生什么”

想象一下：你的Java应用正在生产环境中运行。一切都很完美。然后——砰！——用户抱怨页面加载需要10秒钟。你登录服务器，查看日志，看到一堆INFO，却没有一个ERROR。该怎么办？该看哪里？

在传统的监控中，你检查的是：服务器是否存活，内存占用了多少，进程是否崩溃。但这就像检查仪表盘上的灯是否亮着——有用，但远远不够。可观测性是下一个层次。它是一种通过系统外部输出数据（日志、指标和追踪）来理解系统内部状态的能力。

在本文中，我将通过实际示例展示如何在Java中实施可观测性。我们将使用OpenTelemetry、Micrometer、Spring Boot Actuator和经典的SLF4J。你将了解如何将日志、指标和追踪关联成一个统一的视图，而不仅仅是“把所有东西堆在一起”。

什么是可观测性，为什么它不仅仅是“收集日志”？

可观测性源自控制理论。如果一个系统可以通过其输出数据重建其内部状态，那么这个系统就是可观测的。在Java世界中，这包括三大支柱：

\n
• 日志——结构化的事件记录（发生了什么？）；
\n
• 指标——数值指标（多少？多久？）；
\n
• 追踪——调用链（请求经过了哪些路径？）。
\n

没有可观测性，你就是盲目的。你知道CPU负载达到95%，但不知道是哪个端点导致了负载。你在日志中看到错误，但不明白是哪个用户触发的，以及涉及了哪些服务。Java中的可观测性不仅仅是“安装一个库”，而是一种开发文化。

OpenTelemetry：可观测性的通用工具

过去是百花齐放：Zipkin用于追踪，Prometheus用于指标，ELK用于日志。每个都有自己的SDK。OpenTelemetry（OTel）的出现是为了统一它们。这是一个用于收集遥测数据的开源标准。它原生支持Java，并且可以轻松集成到Spring Boot、Micronaut、Quarkus中。

它是如何工作的？你将代理或SDK添加到你的Java应用中，OTel会自动拦截HTTP请求、数据库调用、消息队列。你不需要为每个工具单独编写代码。

示例：在Spring Boot中配置OpenTelemetry

在pom.xml中添加依赖：

<dependency>\n    <groupId>io.opentelemetry</groupId>\n    <artifactId>opentelemetry-api</artifactId>\n    <version>1.40.0</version>\n</dependency>\n<dependency>\n    <groupId>io.opentelemetry</groupId>\n    <artifactId>opentelemetry-sdk</artifactId>\n    <version>1.40.0</version>\n</dependency>\n<dependency>\n    <groupId>io.opentelemetry.instrumentation</groupId>\n    <artifactId>opentelemetry-spring-boot-starter</artifactId>\n    <version>2.6.0</version>\n</dependency>

现在，在配置文件中（application.yml）指定导出器，例如导出到Jaeger或OTLP收集器：

otel:\n  exporter:\n    otlp:\n      endpoint: http://localhost:4317\n  traces:\n    exporter: otlp\n  metrics:\n    exporter: otlp\n  logs:\n    exporter: otlp

瞧！现在，对你的控制器的每个HTTP请求都会自动创建一个追踪。你可以看到每次数据库调用、外部API调用或线程延迟花费了多少时间。

Java中的追踪：如何找到“瓶颈”

追踪可以说是可观测性中最强大的部分。当你的应用由数十个微服务组成时，追踪是理解为什么一个请求需要2秒钟的唯一方法，尽管每个服