用 SkyWalking 排除健康检查和静态资源前，我先替你把账算清楚了

先说个真实场景。Spring Boot 微服务接入 SkyWalking 之后，第一天打开 Trace 查询页面，屏幕前坐着的我整个人是蒙的：满屏的 GET:/actuator/health、GET:/actuator/health/liveness，夹杂着 /static/js/app-xxxx.js、/webjars/bootstrap.js 这类请求，真正要找的下单链路、支付回调，被淹没在几十页数据后面。这不是我一个人的问题，团队里另一个后端搭的网关用 Kong 3.4 做上游健康检查，每 10 秒对每个上游实例探测一次，20 个实例，一天下来健康检查的链路数量比真实业务请求还多。

这篇文章就是来解决这个问题的：怎么让 SkyWalking 忽略特定接口，重点排除健康检查和静态资源这两类“高噪声、低价值”的请求，保持追踪数据的干净，同时不损失对真实链路的可观测性。适合已经在用 SkyWalking、或者正准备规划探针接入的 Java 后端、SRE、平台工程同学。

1. 大量无意义链路从哪来：健康检查与静态资源对追踪数据的污染

1.1 健康检查不是“偶尔一次”，而是“持续高频”

很多人对健康检查有个错觉：觉得它不过是个 /health 接口，一天也就访问几次。实际放到生产环境里，健康检查的访问频率远超你的想象。

以我们线上一个 20 实例的服务为例，健康检查的来源至少有四个：

• Kubernetes 的 readinessProbe 和 livenessProbe，默认每 10 秒探测一次，20 个实例意味着每秒约 4 次请求。
• Kong 3.4 网关的上游健康检查，如果配置了 active check，每隔几秒就会对每个 upstream target 发起一次 HTTP 探测。
• Spring Boot Actuator 自带的 /actuator/health，很多内部监控平台会定时轮询。
• 运维脚本、负载均衡器的 HTTP 监测，同样会频繁调用。

这些链路本身响应快、逻辑简单，但它们有一个共同点：会完整走完请求进入、Servlet 处理、组件调用采集、Segment 上报这一整套流程。SkyWalking 的 Java Agent 并不会因为请求简单就跳过埋点，每一条健康检查都会被包装成一个 TraceSegment，传到 OAP 后落库。

带来的后果是两方面的。第一，存储浪费。一条健康检查链路即便只有 3-5 个 Span，每天积累下来也是千万级别，磁盘和索引开销都不小。第二，数据失真。你打开拓扑图，会看到服务之间有一条很粗的调用线，点进去发现全是从健康检查发起的 FeignClient 调用，真实业务调用反而被掩盖。链路分析、慢请求排行这类功能，也会被这些“永远成功、永远很快”的假数据带偏。

仔细观察你会发现，这类噪声请求有一个共同特点：它们不是用户发起的业务操作，而是系统自我保护机制产生的。对可观测性系统来说，它们是被动记录的数据，业务价值几乎为零。

1.2 静态资源请求：把端点列表变成“文件列表”

静态资源又是另一类情况。只要你的服务里有 Web 页面，不管是用 Spring Boot 直接托管静态资源，还是前后端分离后由 Nginx 反代到后端，都存在大量 CSS、JavaScript、图片、字体请求。

一个典型的订单管理后台页面，一次整页刷新可能带出 20 到 50 个静态资源请求。前端框架打包后的 JS 文件还会带上 hash，比如 app.e4f8a2b3.js，每次发版文件名都变。在 SkyWalking 的端点列表里，它们会生成大量新的 endpoint，导致 endpoint 基数蹭蹭往上涨。

我看过一个比较极端的上线案例：某服务接入 SkyWalking 后跑了一周，单日 Segment 总量里 65% 来自静态资源。诊断的时候翻 Trace，前端页面的各种 js、css、图片请求把真正报错的接口全顶到后面去了，定位一个 500 错误反而要多翻好多页。

这两种请求不处理，SkyWalking 用起来会非常“脏”。下面这部分我们就来说清楚，排除它们有哪些手段，各自的边界在哪里。

2. 排除机制梳理：探针端配置、采样降噪与后端端点过滤的取舍

排查问题之前，得先搞清楚手上有什么工具。SkyWalking 从探针采集到后端展示，每一层都有干预手段，但效果和代价完全不同。

2.1 探针端的 ignore_path：从源头掐断

agent.trace.ignore_path 是 Java Agent 提供的一个配置项，作用是在探针端直接跳过对指定路径的追踪。路径命中后，这个请求不会生成 TraceSegment，也不会上报到 OAP，是整个链路里最彻底的排除方式。

它的好处是显而易见的：

• 节省探针到 OAP 的网络开销。
• 减少 OAP 的存储和索引压力。
• 让端点和拓扑数据从源头变得干净。

代价也很明确：配置是进程级的，修改后需要重启应用才能生效（后面我会专门展开验证部分）。另外，它只对进入