你的监控系统是不是经常这样服务器CPU飙升你收到告警登录机器一顿top、ps、vmstat操作半小时过去了你发现是某个服务的缓存穿透导致数据库压力过大。问题虽然解决了但整个过程就像在黑暗的房间里找开关——你知道灯坏了监控告警但不知道是灯泡、线路还是开关的问题只能凭经验一个个试。这就是传统监控的典型困境它告诉你系统“病”了但很少告诉你**“病因”是什么**更别提预测下一次“生病”会在何时。今天如果你还在只谈“监控”可能已经落后了半个身位。在云原生、微服务架构成为标配的今天一个更强大的理念正在成为运维和开发团队的必备武器可观测性。它不仅仅是监控的升级版而是一种从“被动救火”到“主动洞察”的范式转变。这篇文章我们不空谈概念。我会用一个真实的线上故障排查场景带你一步步看清“监控”与“可观测性”的核心区别。你将彻底理解为什么在复杂的分布式系统中仅有监控指标Metrics和日志Logs是远远不够的以及如何通过引入追踪Traces构建真正的可观测性体系从而在问题影响用户之前就将其扼杀在摇篮里。1. 监控 vs. 可观测性从“是什么”到“为什么”让我们先达成一个共识监控是可观测性的子集但不是全部。你可以把监控想象成汽车的仪表盘。它有车速表、转速表、油量表、水温报警灯。这些仪表和报警灯非常有用它们告诉你当前的车速、发动机是否过热、油箱是否见底。当水温报警灯亮起时你知道车有问题了。但这就是监控的边界——它告诉你“有异常”仅此而已。水温为什么高是散热风扇坏了还是冷却液泄漏或是节温器故障仪表盘不会告诉你。你需要打开引擎盖用更专业的工具比如故障诊断仪去读取更底层的数据流分析各个部件之间的联动关系才能定位根因。在软件系统中监控Monitoring就像是那个仪表盘。它基于预设的规则和阈值如CPU使用率80%告诉你系统是否健康。它的核心是已知的未知——你预先定义好要关注什么CPU、内存、磁盘然后等它报警。可观测性Observability则是你手上那个强大的故障诊断仪加上你对汽车整个动力总成的深刻理解。它允许你提出任意问题并能够通过系统外部输出的数据指标、日志、追踪来探索和回答这些问题。它的核心是未知的未知——你无需预先知道所有可能出错的地方当奇怪的问题发生时你依然有能力快速探究其内部状态。用一个表格来快速对比特性传统监控可观测性核心目标回答“系统是否在正常工作”回答“系统为什么没有正常工作”数据维度以**指标Metrics**为主辅以日志。**指标Metrics、日志Logs、追踪Traces**三位一体。工作模式被动式基于预设阈值告警。主动式基于探索和关联分析。适用场景相对稳定、架构简单的系统。动态、复杂、分布式的云原生系统。心智模型“我设置了警报等它响。”“无论发生什么我都能查明白。”2. 可观测性的三大支柱Metrics, Logs, Traces理解了区别我们深入看看构成可观测性的三大核心数据源它们通常被称为“三大支柱”。2.1 指标Metrics—— 系统的脉搏指标是随时间变化的数值度量通常是聚合过的。它是系统健康状况的量化体现。特点数值型、可聚合、低开销、适合长期存储和趋势分析。例子请求QPS、接口响应时间P99、错误率、容器内存使用率、数据库连接数。工具Prometheus, Grafana, Zabbix传统监控核心。关键作用用于告警和宏观态势感知。当你看到错误率曲线突然飙升时你知道“出事”了。2.2 日志Logs—— 系统的日记日志是系统在特定时间点发生的事件的文本记录通常由开发者植入。特点离散的、带时间戳的文本行、信息量大、格式多样。例子2023-10-27 14:32:01 INFO [UserService] - User login succeeded, userId12345 或一个Java异常堆栈。工具ELK Stack (Elasticsearch, Logstash, Kibana), Loki, Splunk。关键作用记录详细上下文用于事后根因分析。通过搜索特定错误信息或用户ID你能找到“案发现场”的详细记录。2.3 追踪Traces—— 请求的足迹这是可观测性区别于传统监控的最关键一环。追踪记录了一个请求例如一次用户点击在分布式系统中流经所有服务的完整路径、在每个服务中的处理时长以及服务间的调用关系。特点面向请求、有因果关系父子Span、可视化调用链。例子一个HTTP请求从前端-网关-用户服务-订单服务-数据库整个过程的耗时分解。工具Jaeger, Zipkin, SkyWalking。关键作用解决分布式系统排障的“最后一公里”问题。当请求变慢或失败时你能一眼看出是哪个服务、甚至是服务内部的哪个函数调用成了瓶颈而不是盲目地检查所有服务。3. 一个实战场景没有追踪故障排查有多难假设我们有一个简化的电商应用架构如下Nginx - 网关 - 用户服务 - 订单服务 - 数据库。故障现象监控大盘显示订单提交接口的P99响应时间从200ms陡增至2s错误率也有小幅上升。仅有监控和日志的排查流程传统方式告警收到 Grafana 上关于订单接口延迟的告警。看指标登录监控系统发现订单服务所在容器的CPU、内存正常但该服务的平均响应时间确实很高。查日志去 ELK 里搜索订单服务过去5分钟的ERROR和WARN日志。可能发现一些“数据库连接超时”或“远程调用失败”的零星错误但频率不高似乎不是主因。盲猜与验证怀疑数据库去查数据库监控发现负载并不高。怀疑网络在订单服务服务器上ping一下数据库延迟正常。怀疑下游服务订单服务还调用了库存服务和支付服务吗查一下它们的监控和日志...过程开始发散陷入僵局指标和日志没有给出明确指向。你可能会尝试重启订单服务“万能”重启或者增加实例数量。问题可能暂时缓解但根本原因未知很可能再次复发。这个过程耗时耗力严重依赖运维人员的经验和运气在微服务数量众多时几乎不可行。拥有可观测性引入追踪的排查流程告警同样收到延迟告警。一键下钻在 Jaeger 或 SkyWalking 的可视化界面上直接筛选“订单提交”这个接口查看最近慢的追踪Trace。可视化分析点开一条慢追踪你清晰地看到如下调用链总耗时: 2150ms ├── Nginx: 2ms ├── 网关: 5ms ├── 用户服务: 15ms └── 订单服务: 2128ms ├── 验证参数: 10ms ├── 检查库存: 1500ms -- 红色高亮瓶颈 │ └── 调用库存服务HTTP接口: 1500ms ├── 创建订单DB操作: 600ms └── 其他逻辑: 18ms秒级定位问题一目了然耗时主要卡在“检查库存”这一步具体是调用库存服务的HTTP接口慢了。根因分析现在你可以带着明确目标去调查是库存服务本身慢了吗查库存服务的指标和该接口的追踪。是网络问题吗查看这两个服务之间网络链路的监控。还是库存服务的数据库慢继续下钻。你从一个模糊的“订单慢”问题在几秒钟内精准定位到了“订单服务调用库存服务HTTP接口慢”这个具体问题。这就是可观测性的威力通过追踪将指标、日志串联起来提供了完整的上下文和因果关系。4. 如何从零开始构建可观测性体系理论说再多不如动手搭一套。下面我们以最流行的开源技术栈为例演示如何为一个Spring Boot微服务搭建可观测性体系。4.1 技术栈选型指标MetricsPrometheus采集与存储 Grafana可视化追踪TracesJaeger推荐 或 Zipkin日志LogsLoki轻量与Grafana集成好 Grafana可视化应用框架Spring Boot 2.x/3.x4.2 环境准备与依赖引入首先在你的Spring Boot项目的pom.xml中添加必要的依赖。!-- Micrometer - 指标门面对接Prometheus -- dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependency !-- Spring Boot Actuator - 提供监控端点 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency !-- Brave / OpenTelemetry for Tracing - 以Brave (Zipkin)为例 -- dependency groupIdio.zipkin.brave/groupId artifactIdbrave/artifactId version5.16.0/version !-- 请使用最新版本 -- /dependency dependency groupIdio.zipkin.reporter2/groupId artifactIdzipkin-reporter-brave/artifactId version2.16.3/version /dependency !-- 如果你使用Spring Cloud Sleuth (已整合Brave) -- dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-sleuth/artifactId /dependency4.3 配置详解在application.yml中配置server: port: 8080 spring: application: name: order-service # 服务名在追踪和指标中很重要 management: endpoints: web: exposure: include: health,info,prometheus # 暴露prometheus指标端点 metrics: tags: application: ${spring.application.name} # 为所有指标打上应用标签 tracing: sampling: probability: 1.0 # 采样率生产环境可调低如0.1 # 示例Zipkin (Jaeger兼容Zipkin格式) 配置 # 如果使用Spring Cloud Sleuth配置更简单 zipkin: base-url: http://localhost:9411/ # Zipkin/Jaeger收集器地址 sender: type: web logging: pattern: level: %5p [${spring.application.name},%X{traceId:-},%X{spanId:-}] # 日志中注入TraceID4.4 核心代码手动埋点与追踪大多数基础指标HTTP请求、JVM等和追踪HTTP调用会被自动收集。但对于关键业务逻辑手动埋点能提供更细粒度的洞察。import io.micrometer.core.annotation.Timed; import io.micrometer.core.instrument.MeterRegistry; import io.micrometer.core.instrument.Timer; import org.springframework.web.bind.annotation.*; import brave.Tracer; import brave.ScopedSpan; RestController RequestMapping(/api/orders) public class OrderController { private final OrderService orderService; private final Tracer tracer; // Brave Tracer 用于手动追踪 private final Timer orderCreationTimer; // Micrometer Timer 用于自定义指标 public OrderController(OrderService orderService, Tracer tracer, MeterRegistry registry) { this.orderService orderService; this.tracer tracer; // 注册一个自定义指标order.creation.duration this.orderCreationTimer Timer.builder(order.creation.duration) .description(订单创建耗时) .tags(service, order-service) .register(registry); } PostMapping Timed(value api.orders.create, description 创建订单API耗时) // 方法级别的自动计时 public ResponseEntityOrder createOrder(RequestBody OrderRequest request) { // 1. 手动创建一个追踪Span用于标记“业务校验”阶段 ScopedSpan validateSpan tracer.startScopedSpan(validate-order-request); try { // 业务校验逻辑... if (request.getAmount() 0) { throw new IllegalArgumentException(金额必须大于0); } } finally { validateSpan.finish(); // 必须结束Span } // 2. 使用Timer记录一段复杂逻辑的耗时 return orderCreationTimer.record(() - { // 模拟订单创建核心逻辑 Order order orderService.createOrder(request); // 3. 在日志中TraceID和SpanID会自动注入见上面logging.pattern配置 log.info(订单创建成功订单号{}, order.getOrderNo()); return ResponseEntity.ok(order); }); } }4.5 基础设施部署与集成1. 部署Prometheus创建prometheus.yml配置文件global: scrape_interval: 15s scrape_configs: - job_name: spring-boot-apps metrics_path: /actuator/prometheus static_configs: - targets: [host.docker.internal:8080] # 你的应用地址 labels: application: order-service使用Docker快速启动docker run -d -p 9090:9090 \ -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus2. 部署Grafanadocker run -d -p 3000:3000 grafana/grafana启动后访问http://localhost:3000默认账号密码admin/admin。添加Prometheus作为数据源然后就可以导入或创建仪表盘了。3. 部署Jaeger (All-in-One模式适合演示)docker run -d --name jaeger \ -e COLLECTOR_ZIPKIN_HOST_PORT:9411 \ -p 5775:5775/udp \ -p 6831:6831/udp \ -p 6832:6832/udp \ -p 5778:5778 \ -p 16686:16686 \ -p 14268:14268 \ -p 14250:14250 \ -p 9411:9411 \ jaegertracing/all-in-one:latest访问http://localhost:16686即可看到Jaeger UI。4. 部署Loki (日志聚合)# 启动Loki docker run -d -p 3100:3100 --nameloki grafana/loki:latest # 启动Promtail (日志收集代理需要配置) # 略... 请参考Loki官方文档配置Promtail指向你的应用日志文件。在Grafana中添加Loki数据源即可在Grafana中统一查询指标和日志。5. 运行验证与效果查看启动你的Spring Boot应用。发送一些请求使用curl或 Postman 调用你的API。curl -X POST http://localhost:8080/api/orders \ -H Content-Type: application/json \ -d {productId: 123, amount: 1}验证指标访问http://localhost:8080/actuator/prometheus应该能看到暴露的指标数据。在Grafana中查询http_server_requests_seconds_count{applicationorder-service}等指标并创建图表。验证追踪访问http://localhost:16686在Service下拉框中选择order-service点击Find Traces你应该能看到刚才请求的追踪详情包括我们手动创建的validate-order-requestSpan。验证日志关联在应用日志文件中你应该能看到每行日志都包含了[traceId, spanId]例如INFO [order-service,7e34f5b3d2a8c1b0,5a2f1c9e3b8d7f6a] 订单创建成功订单号ORD-20231027-001在Grafana的Explore界面选择Loki数据源你可以用这个traceId来搜索与该请求相关的所有日志真正实现了一次请求的完整复盘。6. 常见问题与排查思路问题现象可能原因排查方式解决方案Prometheus 抓取不到指标1. 应用/actuator/prometheus端点未暴露。2. 网络不通或端口错误。3. Prometheus配置中targets地址错误。1. 访问http://应用地址/actuator查看端点列表。2. 检查Prometheus Targets页面状态。1. 确认management.endpoints.web.exposure.include包含prometheus。2. 修正配置确保网络可达。Jaeger UI 中看不到追踪1. 应用未正确配置追踪导出器。2. 采样率设置为0。3. Jaeger收集器服务未运行。1. 检查应用日志是否有发送追踪的错误。2. 确认spring.sleuth.sampler.probability或management.tracing.sampling.probability大于0。3. 检查Jaeger容器是否运行。1. 检查Zipkin/Jaeger依赖和配置。2. 调整采样率。3. 重启Jaeger服务。日志中没有TraceID1. 日志模式Pattern未配置。2. 使用的日志框架如Logback配置覆盖了Spring默认。1. 检查application.yml中的logging.pattern.level配置。2. 检查是否有自定义的logback-spring.xml。1. 确保配置正确%X{traceId:-},%X{spanId:-}。2. 在自定义配置中集成%X{traceId}。自定义指标在Grafana中看不到1. 指标名称拼写错误。2. 指标没有被成功注册或记录。3. Prometheus抓取周期未到。1. 在Prometheus的Graph页面直接查询指标名。2. 检查代码中Timer或Counter的注册和调用逻辑。1. 使用/actuator/metrics端点查看所有已注册指标。2. 确保业务代码执行到了记录指标的部分。追踪数据量太大存储压力大生产环境全量采样probability1.0会导致数据爆炸。评估存储成本和排查需求。降低采样率如0.1或采用自适应采样、尾部采样等高级策略。7. 生产环境最佳实践与进阶建议构建可观测性体系不是一蹴而就的遵循以下实践可以让你走得更稳更远定义SLO并基于其告警不要只监控CPU/内存。定义服务的核心目标如“登录接口P99延迟500ms”并基于此创建告警。这是可观测性驱动运维的核心。统一的标签Tags/Labels体系在指标、日志、追踪中使用一致的标签如service、instance、envprod/staging、version。这是实现三者关联查询的基石。日志结构化输出JSON格式的日志便于解析和筛选。避免在日志中打印敏感信息密码、令牌。追踪采样策略生产环境务必使用采样。可以从低采样率开始对错误请求提高采样率如使用Jaeger的适应性采样。关注黄金信号Google SRE提出的四大黄金信号——延迟、流量、错误、饱和度是构建监控和可观测性仪表盘的核心维度。可观测性即代码使用Terraform、Helm等工具管理Prometheus、Grafana、Jaeger的部署和配置确保环境一致性。将可观测性融入开发流程让开发人员在本地就能查看追踪和指标鼓励他们在代码中添加有意义的埋点和日志将可观测性作为代码质量的一部分。考虑OpenTelemetry作为CNCF项目OpenTelemetry旨在提供与厂商无关的遥测数据采集标准。对于新项目强烈建议直接使用OpenTelemetry SDK和API它统一了Metrics、Traces、Logs的采集是未来的方向。8. 总结从成本中心到价值引擎回到最初的问题为什么只有监控还不够因为监控让你看见而可观测性让你看懂。在系统简单时“看见”可能就够了但当系统复杂到任何人无法完全掌握其内部状态时“看懂”的能力就成为了团队的核心竞争力。投入可观测性建设短期看是增加了工具链的复杂度但长期看它通过大幅降低故障平均恢复时间MTTR、提升研发排障效率、辅助进行性能优化将运维从被动的“救火队”转变为主动的“系统医生”最终成为保障业务稳定、驱动产品迭代的价值引擎。开始行动吧。从一个核心服务开始接入一个追踪工具将日志、指标、追踪串联起来。当你第一次通过一个TraceID在30秒内复现了一个线上用户投诉的完整请求路径时你就会明白这种掌控感是任何传统监控都无法给予的。 从监控到可观测性：构建分布式系统故障排查新范式
你的监控系统是不是经常这样服务器CPU飙升你收到告警登录机器一顿top、ps、vmstat操作半小时过去了你发现是某个服务的缓存穿透导致数据库压力过大。问题虽然解决了但整个过程就像在黑暗的房间里找开关——你知道灯坏了监控告警但不知道是灯泡、线路还是开关的问题只能凭经验一个个试。这就是传统监控的典型困境它告诉你系统“病”了但很少告诉你**“病因”是什么**更别提预测下一次“生病”会在何时。今天如果你还在只谈“监控”可能已经落后了半个身位。在云原生、微服务架构成为标配的今天一个更强大的理念正在成为运维和开发团队的必备武器可观测性。它不仅仅是监控的升级版而是一种从“被动救火”到“主动洞察”的范式转变。这篇文章我们不空谈概念。我会用一个真实的线上故障排查场景带你一步步看清“监控”与“可观测性”的核心区别。你将彻底理解为什么在复杂的分布式系统中仅有监控指标Metrics和日志Logs是远远不够的以及如何通过引入追踪Traces构建真正的可观测性体系从而在问题影响用户之前就将其扼杀在摇篮里。1. 监控 vs. 可观测性从“是什么”到“为什么”让我们先达成一个共识监控是可观测性的子集但不是全部。你可以把监控想象成汽车的仪表盘。它有车速表、转速表、油量表、水温报警灯。这些仪表和报警灯非常有用它们告诉你当前的车速、发动机是否过热、油箱是否见底。当水温报警灯亮起时你知道车有问题了。但这就是监控的边界——它告诉你“有异常”仅此而已。水温为什么高是散热风扇坏了还是冷却液泄漏或是节温器故障仪表盘不会告诉你。你需要打开引擎盖用更专业的工具比如故障诊断仪去读取更底层的数据流分析各个部件之间的联动关系才能定位根因。在软件系统中监控Monitoring就像是那个仪表盘。它基于预设的规则和阈值如CPU使用率80%告诉你系统是否健康。它的核心是已知的未知——你预先定义好要关注什么CPU、内存、磁盘然后等它报警。可观测性Observability则是你手上那个强大的故障诊断仪加上你对汽车整个动力总成的深刻理解。它允许你提出任意问题并能够通过系统外部输出的数据指标、日志、追踪来探索和回答这些问题。它的核心是未知的未知——你无需预先知道所有可能出错的地方当奇怪的问题发生时你依然有能力快速探究其内部状态。用一个表格来快速对比特性传统监控可观测性核心目标回答“系统是否在正常工作”回答“系统为什么没有正常工作”数据维度以**指标Metrics**为主辅以日志。**指标Metrics、日志Logs、追踪Traces**三位一体。工作模式被动式基于预设阈值告警。主动式基于探索和关联分析。适用场景相对稳定、架构简单的系统。动态、复杂、分布式的云原生系统。心智模型“我设置了警报等它响。”“无论发生什么我都能查明白。”2. 可观测性的三大支柱Metrics, Logs, Traces理解了区别我们深入看看构成可观测性的三大核心数据源它们通常被称为“三大支柱”。2.1 指标Metrics—— 系统的脉搏指标是随时间变化的数值度量通常是聚合过的。它是系统健康状况的量化体现。特点数值型、可聚合、低开销、适合长期存储和趋势分析。例子请求QPS、接口响应时间P99、错误率、容器内存使用率、数据库连接数。工具Prometheus, Grafana, Zabbix传统监控核心。关键作用用于告警和宏观态势感知。当你看到错误率曲线突然飙升时你知道“出事”了。2.2 日志Logs—— 系统的日记日志是系统在特定时间点发生的事件的文本记录通常由开发者植入。特点离散的、带时间戳的文本行、信息量大、格式多样。例子2023-10-27 14:32:01 INFO [UserService] - User login succeeded, userId12345 或一个Java异常堆栈。工具ELK Stack (Elasticsearch, Logstash, Kibana), Loki, Splunk。关键作用记录详细上下文用于事后根因分析。通过搜索特定错误信息或用户ID你能找到“案发现场”的详细记录。2.3 追踪Traces—— 请求的足迹这是可观测性区别于传统监控的最关键一环。追踪记录了一个请求例如一次用户点击在分布式系统中流经所有服务的完整路径、在每个服务中的处理时长以及服务间的调用关系。特点面向请求、有因果关系父子Span、可视化调用链。例子一个HTTP请求从前端-网关-用户服务-订单服务-数据库整个过程的耗时分解。工具Jaeger, Zipkin, SkyWalking。关键作用解决分布式系统排障的“最后一公里”问题。当请求变慢或失败时你能一眼看出是哪个服务、甚至是服务内部的哪个函数调用成了瓶颈而不是盲目地检查所有服务。3. 一个实战场景没有追踪故障排查有多难假设我们有一个简化的电商应用架构如下Nginx - 网关 - 用户服务 - 订单服务 - 数据库。故障现象监控大盘显示订单提交接口的P99响应时间从200ms陡增至2s错误率也有小幅上升。仅有监控和日志的排查流程传统方式告警收到 Grafana 上关于订单接口延迟的告警。看指标登录监控系统发现订单服务所在容器的CPU、内存正常但该服务的平均响应时间确实很高。查日志去 ELK 里搜索订单服务过去5分钟的ERROR和WARN日志。可能发现一些“数据库连接超时”或“远程调用失败”的零星错误但频率不高似乎不是主因。盲猜与验证怀疑数据库去查数据库监控发现负载并不高。怀疑网络在订单服务服务器上ping一下数据库延迟正常。怀疑下游服务订单服务还调用了库存服务和支付服务吗查一下它们的监控和日志...过程开始发散陷入僵局指标和日志没有给出明确指向。你可能会尝试重启订单服务“万能”重启或者增加实例数量。问题可能暂时缓解但根本原因未知很可能再次复发。这个过程耗时耗力严重依赖运维人员的经验和运气在微服务数量众多时几乎不可行。拥有可观测性引入追踪的排查流程告警同样收到延迟告警。一键下钻在 Jaeger 或 SkyWalking 的可视化界面上直接筛选“订单提交”这个接口查看最近慢的追踪Trace。可视化分析点开一条慢追踪你清晰地看到如下调用链总耗时: 2150ms ├── Nginx: 2ms ├── 网关: 5ms ├── 用户服务: 15ms └── 订单服务: 2128ms ├── 验证参数: 10ms ├── 检查库存: 1500ms -- 红色高亮瓶颈 │ └── 调用库存服务HTTP接口: 1500ms ├── 创建订单DB操作: 600ms └── 其他逻辑: 18ms秒级定位问题一目了然耗时主要卡在“检查库存”这一步具体是调用库存服务的HTTP接口慢了。根因分析现在你可以带着明确目标去调查是库存服务本身慢了吗查库存服务的指标和该接口的追踪。是网络问题吗查看这两个服务之间网络链路的监控。还是库存服务的数据库慢继续下钻。你从一个模糊的“订单慢”问题在几秒钟内精准定位到了“订单服务调用库存服务HTTP接口慢”这个具体问题。这就是可观测性的威力通过追踪将指标、日志串联起来提供了完整的上下文和因果关系。4. 如何从零开始构建可观测性体系理论说再多不如动手搭一套。下面我们以最流行的开源技术栈为例演示如何为一个Spring Boot微服务搭建可观测性体系。4.1 技术栈选型指标MetricsPrometheus采集与存储 Grafana可视化追踪TracesJaeger推荐 或 Zipkin日志LogsLoki轻量与Grafana集成好 Grafana可视化应用框架Spring Boot 2.x/3.x4.2 环境准备与依赖引入首先在你的Spring Boot项目的pom.xml中添加必要的依赖。!-- Micrometer - 指标门面对接Prometheus -- dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependency !-- Spring Boot Actuator - 提供监控端点 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency !-- Brave / OpenTelemetry for Tracing - 以Brave (Zipkin)为例 -- dependency groupIdio.zipkin.brave/groupId artifactIdbrave/artifactId version5.16.0/version !-- 请使用最新版本 -- /dependency dependency groupIdio.zipkin.reporter2/groupId artifactIdzipkin-reporter-brave/artifactId version2.16.3/version /dependency !-- 如果你使用Spring Cloud Sleuth (已整合Brave) -- dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-sleuth/artifactId /dependency4.3 配置详解在application.yml中配置server: port: 8080 spring: application: name: order-service # 服务名在追踪和指标中很重要 management: endpoints: web: exposure: include: health,info,prometheus # 暴露prometheus指标端点 metrics: tags: application: ${spring.application.name} # 为所有指标打上应用标签 tracing: sampling: probability: 1.0 # 采样率生产环境可调低如0.1 # 示例Zipkin (Jaeger兼容Zipkin格式) 配置 # 如果使用Spring Cloud Sleuth配置更简单 zipkin: base-url: http://localhost:9411/ # Zipkin/Jaeger收集器地址 sender: type: web logging: pattern: level: %5p [${spring.application.name},%X{traceId:-},%X{spanId:-}] # 日志中注入TraceID4.4 核心代码手动埋点与追踪大多数基础指标HTTP请求、JVM等和追踪HTTP调用会被自动收集。但对于关键业务逻辑手动埋点能提供更细粒度的洞察。import io.micrometer.core.annotation.Timed; import io.micrometer.core.instrument.MeterRegistry; import io.micrometer.core.instrument.Timer; import org.springframework.web.bind.annotation.*; import brave.Tracer; import brave.ScopedSpan; RestController RequestMapping(/api/orders) public class OrderController { private final OrderService orderService; private final Tracer tracer; // Brave Tracer 用于手动追踪 private final Timer orderCreationTimer; // Micrometer Timer 用于自定义指标 public OrderController(OrderService orderService, Tracer tracer, MeterRegistry registry) { this.orderService orderService; this.tracer tracer; // 注册一个自定义指标order.creation.duration this.orderCreationTimer Timer.builder(order.creation.duration) .description(订单创建耗时) .tags(service, order-service) .register(registry); } PostMapping Timed(value api.orders.create, description 创建订单API耗时) // 方法级别的自动计时 public ResponseEntityOrder createOrder(RequestBody OrderRequest request) { // 1. 手动创建一个追踪Span用于标记“业务校验”阶段 ScopedSpan validateSpan tracer.startScopedSpan(validate-order-request); try { // 业务校验逻辑... if (request.getAmount() 0) { throw new IllegalArgumentException(金额必须大于0); } } finally { validateSpan.finish(); // 必须结束Span } // 2. 使用Timer记录一段复杂逻辑的耗时 return orderCreationTimer.record(() - { // 模拟订单创建核心逻辑 Order order orderService.createOrder(request); // 3. 在日志中TraceID和SpanID会自动注入见上面logging.pattern配置 log.info(订单创建成功订单号{}, order.getOrderNo()); return ResponseEntity.ok(order); }); } }4.5 基础设施部署与集成1. 部署Prometheus创建prometheus.yml配置文件global: scrape_interval: 15s scrape_configs: - job_name: spring-boot-apps metrics_path: /actuator/prometheus static_configs: - targets: [host.docker.internal:8080] # 你的应用地址 labels: application: order-service使用Docker快速启动docker run -d -p 9090:9090 \ -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus2. 部署Grafanadocker run -d -p 3000:3000 grafana/grafana启动后访问http://localhost:3000默认账号密码admin/admin。添加Prometheus作为数据源然后就可以导入或创建仪表盘了。3. 部署Jaeger (All-in-One模式适合演示)docker run -d --name jaeger \ -e COLLECTOR_ZIPKIN_HOST_PORT:9411 \ -p 5775:5775/udp \ -p 6831:6831/udp \ -p 6832:6832/udp \ -p 5778:5778 \ -p 16686:16686 \ -p 14268:14268 \ -p 14250:14250 \ -p 9411:9411 \ jaegertracing/all-in-one:latest访问http://localhost:16686即可看到Jaeger UI。4. 部署Loki (日志聚合)# 启动Loki docker run -d -p 3100:3100 --nameloki grafana/loki:latest # 启动Promtail (日志收集代理需要配置) # 略... 请参考Loki官方文档配置Promtail指向你的应用日志文件。在Grafana中添加Loki数据源即可在Grafana中统一查询指标和日志。5. 运行验证与效果查看启动你的Spring Boot应用。发送一些请求使用curl或 Postman 调用你的API。curl -X POST http://localhost:8080/api/orders \ -H Content-Type: application/json \ -d {productId: 123, amount: 1}验证指标访问http://localhost:8080/actuator/prometheus应该能看到暴露的指标数据。在Grafana中查询http_server_requests_seconds_count{applicationorder-service}等指标并创建图表。验证追踪访问http://localhost:16686在Service下拉框中选择order-service点击Find Traces你应该能看到刚才请求的追踪详情包括我们手动创建的validate-order-requestSpan。验证日志关联在应用日志文件中你应该能看到每行日志都包含了[traceId, spanId]例如INFO [order-service,7e34f5b3d2a8c1b0,5a2f1c9e3b8d7f6a] 订单创建成功订单号ORD-20231027-001在Grafana的Explore界面选择Loki数据源你可以用这个traceId来搜索与该请求相关的所有日志真正实现了一次请求的完整复盘。6. 常见问题与排查思路问题现象可能原因排查方式解决方案Prometheus 抓取不到指标1. 应用/actuator/prometheus端点未暴露。2. 网络不通或端口错误。3. Prometheus配置中targets地址错误。1. 访问http://应用地址/actuator查看端点列表。2. 检查Prometheus Targets页面状态。1. 确认management.endpoints.web.exposure.include包含prometheus。2. 修正配置确保网络可达。Jaeger UI 中看不到追踪1. 应用未正确配置追踪导出器。2. 采样率设置为0。3. Jaeger收集器服务未运行。1. 检查应用日志是否有发送追踪的错误。2. 确认spring.sleuth.sampler.probability或management.tracing.sampling.probability大于0。3. 检查Jaeger容器是否运行。1. 检查Zipkin/Jaeger依赖和配置。2. 调整采样率。3. 重启Jaeger服务。日志中没有TraceID1. 日志模式Pattern未配置。2. 使用的日志框架如Logback配置覆盖了Spring默认。1. 检查application.yml中的logging.pattern.level配置。2. 检查是否有自定义的logback-spring.xml。1. 确保配置正确%X{traceId:-},%X{spanId:-}。2. 在自定义配置中集成%X{traceId}。自定义指标在Grafana中看不到1. 指标名称拼写错误。2. 指标没有被成功注册或记录。3. Prometheus抓取周期未到。1. 在Prometheus的Graph页面直接查询指标名。2. 检查代码中Timer或Counter的注册和调用逻辑。1. 使用/actuator/metrics端点查看所有已注册指标。2. 确保业务代码执行到了记录指标的部分。追踪数据量太大存储压力大生产环境全量采样probability1.0会导致数据爆炸。评估存储成本和排查需求。降低采样率如0.1或采用自适应采样、尾部采样等高级策略。7. 生产环境最佳实践与进阶建议构建可观测性体系不是一蹴而就的遵循以下实践可以让你走得更稳更远定义SLO并基于其告警不要只监控CPU/内存。定义服务的核心目标如“登录接口P99延迟500ms”并基于此创建告警。这是可观测性驱动运维的核心。统一的标签Tags/Labels体系在指标、日志、追踪中使用一致的标签如service、instance、envprod/staging、version。这是实现三者关联查询的基石。日志结构化输出JSON格式的日志便于解析和筛选。避免在日志中打印敏感信息密码、令牌。追踪采样策略生产环境务必使用采样。可以从低采样率开始对错误请求提高采样率如使用Jaeger的适应性采样。关注黄金信号Google SRE提出的四大黄金信号——延迟、流量、错误、饱和度是构建监控和可观测性仪表盘的核心维度。可观测性即代码使用Terraform、Helm等工具管理Prometheus、Grafana、Jaeger的部署和配置确保环境一致性。将可观测性融入开发流程让开发人员在本地就能查看追踪和指标鼓励他们在代码中添加有意义的埋点和日志将可观测性作为代码质量的一部分。考虑OpenTelemetry作为CNCF项目OpenTelemetry旨在提供与厂商无关的遥测数据采集标准。对于新项目强烈建议直接使用OpenTelemetry SDK和API它统一了Metrics、Traces、Logs的采集是未来的方向。8. 总结从成本中心到价值引擎回到最初的问题为什么只有监控还不够因为监控让你看见而可观测性让你看懂。在系统简单时“看见”可能就够了但当系统复杂到任何人无法完全掌握其内部状态时“看懂”的能力就成为了团队的核心竞争力。投入可观测性建设短期看是增加了工具链的复杂度但长期看它通过大幅降低故障平均恢复时间MTTR、提升研发排障效率、辅助进行性能优化将运维从被动的“救火队”转变为主动的“系统医生”最终成为保障业务稳定、驱动产品迭代的价值引擎。开始行动吧。从一个核心服务开始接入一个追踪工具将日志、指标、追踪串联起来。当你第一次通过一个TraceID在30秒内复现了一个线上用户投诉的完整请求路径时你就会明白这种掌控感是任何传统监控都无法给予的。