1. 为什么监控面板上全是健康检查的接口先说个我实际遇到的场景。某个服务接入 SkyWalking 之后链路追踪页面打开一看排在前面的接口根本不是业务接口而是/health、/actuator/health、/favicon.ico这类请求。更夸张的是一个 Spring Boot 服务接入 Kubernetes 后livenessProbe 和 readinessProbe 默认每隔几秒就打一次健康检查一天下来能产生几十万条 trace 数据而真正需要关注的订单接口、支付回调反而被淹没在数据海里。这个问题的本质在于APM 系统是无差别采集的它不管你请求的是POST /api/order/create还是GET /health只要进了应用就会被记录、被采样、被统计。健康检查和静态资源这类请求有两个共同特点一是频率高二是跟业务没有直接关系。频率高意味着会占据大量的存储和计算资源跟业务无关意味着它们会让接口响应时间、错误率、吞吐量这些核心指标出现失真。举个例子一个接口的平均响应时间本来应该是 200ms但如果同时统计了静态资源请求而静态资源走的是本地缓存平均只要 5ms那整体平均响应时间会被拉低到看起来不真实的地步。如果反过来某些健康检查因为依赖了数据库或 Redis 而出现超时它又会让你以为业务接口在报错误报警就这么产生了。所以接入 SkyWalking 之后第一件要做的优化不是调整 JVM 参数也不是改造业务代码而是先把那些不该出现在监控里的请求排除掉。这篇文章就用实际案例来讲清楚 SkyWalking 忽略特定接口的完整方案包括健康检查、静态资源、大文件上传这类高噪音接口的排除方法以及我在线上环境踩过的坑。2. 到底有哪些接口值得被排除在动手配置之前先梳理一下哪些接口最应该进入忽略名单。这不是一个固定的清单不同业务形态差异很大但有几类接口几乎适用于所有场景。2.1 健康检查类接口健康检查类接口是最典型的高噪音来源。Spring Boot Actuator 暴露的/actuator/health、Kubernetes 的 liveness 和 readiness 探针、Nginx 后面挂的/nginx-health、注册中心的心跳检测以及各种自定义的ping接口都是高频低价值的调用。这类接口的调用频率通常非常高。Kubernetes 默认探针间隔是 10 秒一次如果一个 Pod 部署了 3 个副本每分钟就有 18 次健康检查。如果服务有 20 个每分钟就是 360 次一小时就是 21600 次。这些数据全部进 SkyWalking一天的存储量会非常可观。这里要提醒一点不要把健康检查全部一刀切忽略掉。有些团队的监控体系依赖 SkyWalking 来做健康检查告警如果把健康检查全部过滤了告警通道就废了。我见过一个团队这样做之后服务挂了半小时才发现问题就是因为过于依赖 APM 的告警。更合理的做法是如果健康检查已经由 Kubernetes 或者独立的监控系统负责那 APM 层面的健康检查数据可以直接忽略如果没有独立的健康检查监控那至少要保留一个核心健康检查接口的追踪。2.2 静态资源类接口静态资源请求是第二种噪音源。Spring Boot 应用如果开启了静态资源映射/static/**、/public/**、/resources/**下的 CSS、JS、图片都会被记录。如果应用还接了文件上传下载功能比如/file/download那大文件的传输链路也会全部进入监控。静态资源的典型特征是单次耗时短、调用量大、对业务判断没有参考价值。特别是图片类资源用户每次刷新页面可能触发几十个请求如果这些全部进入 SkyWalking一天的数据量会非常吓人。2.3 文件上传下载类接口还有一种容易被忽略的接口是文件上传下载。这类接口的耗时通常很长而且波动极大。一个 500MB 文件的上传可能耗时 30 秒而一个 1KB 文件只需要 50ms。如果把这两种请求放在同一个接口的统计数据里平均响应时间会变得毫无参考价值。之前有个电商项目就是这个情况用户的实名认证需要上传身份证照片照片通常是 2MB8MB上传接口的响应时间从 500ms 到 20 秒都有。监控面板上这个接口的响应时间曲线几乎是一条波浪线根本无法判断是业务变慢还是网络波动。后来我们把大于 10MB 的上传请求从统计中剔除曲线才真正反映了服务本身的性能。2.4 内部调试与预发布接口最后一类是在非生产环境或调试阶段产生的接口调用比如/debug/**、Swagger 的/v2/api-docs、/swagger-ui.html。这些接口在测试环境频率不高但如果团队习惯在预发布环境做压测和联调这些请求也会进入生产环境的 SkyWalking。3. SkyWalking 忽略接口的机制与配置入口清楚了哪些接口需要排除接下来要理解 SkyWalking 是基于什么机制来实现忽略的。只有搞清楚了底层逻辑遇到配置不生效的问题时才能快速定位。3.1 trace.ignore_path 是唯一入口SkyWalking 官方提供的忽略接口配置项叫trace.ignore_path配置在 agent 端的agent.config文件中。它的作用是让 agent 在采集阶段就直接丢弃匹配的请求不生成 trace不进入后续的分析流程。这个参数的核心逻辑是在 HTTP 请求进入应用时agent 会先检查请求路径是否匹配 ignore_path 的规则如果匹配就直接跳过追踪逻辑不创建 trace segment。这意味着被忽略的接口不会出现在链路追踪列表里也不会被统计到服务拓扑和响应时间指标中。打开 SkyWalking agent 的配置文件一般在agent/config/agent.config或agent/config/agent.ymal不同版本位置可能不同你会找到这样一行# The path will be ignored. Support Ant path pattern. Default is blank. trace.ignore_path${SW_IGNORE_PATH:}默认值是空的也就是默认不忽略任何接口。配置的格式是 Ant Path 模式多个路径用逗号分隔。3.2 Agent 端配置与服务端处理的关系这里有一个容易混淆的点SkyWalking 的 ignore_path 是在 agent 端生效的不是在 OAP Server 端。也就是说配置了 ignore_path 之后被忽略的请求根本不会上报到 OAP Server。这和另一种常见的处理方式——在 OAP Server 上做数据过滤——有本质区别。Agent 端忽略是彻底不采集服务端过滤是采集了再丢弃。前者节省了 agent 到 OAP 的网络传输和 OAP 的处理资源后者只是节省了存储和展示的成本。所以如果你想让忽略效果最大化优先在 agent 端配置 ignore_path。如果你的 agent 版本太老不支持 ignore_path或者在采集端做统一管理更方便那可以在 OAP Server 上通过配置过滤器来处理但这不是这篇文章的重点而且它消耗的资源更多。3.3 修改配置后必须重启进程这是一个非常关键的操作要点trace.ignore_path 是在 agent 启动时加载的不支持热更新。修改了 agent.config 之后必须重启应用进程才能生效。如果你用的是 Spring Boot 内置 Tomcat那就是要重启整个 Spring Boot 进程。如果你用的是外置 Tomcat那就要重启 Tomcat。很多人在配置完之后发现没生效第一反应是检查配置格式其实最常见的原因就是忘了重启进程。3.4 Java Agent 路径匹配规则Agent 端的路径匹配遵循 Ant Path 匹配规则常见的通配符有以下几种通配符含义示例?匹配任意单个字符/health?匹配/health和/healths*匹配零个或多个字符不跨目录层级/health/*匹配/health/a不匹配/health/a/b**匹配零个或多个目录层级/health/**匹配/health/a和/health/a/b/c在配置的时候要特别注意*和**的区别。很多人会把/static/*当成匹配所有静态资源结果发现/static/js/app.js匹配上了但/static/js/vendor/lib.js没匹配上就是因为*不跨层级。如果你希望忽略某个目录下的所有内容用**会更稳妥。4. 健康检查、静态资源、大文件上传三类接口的排除实战接下来进入实际操作阶段。我会按照最常见的三类接口逐一演示配置方案并附上线上环境的验证效果。4.1 健康检查接口的排除方案首先是健康检查接口。假设你的服务有以下健康检查路径/actuator/healthSpring Boot Actuator 的健康检查端点/actuator/info服务信息端点/health自定义的探活接口/ping某些网关或负载均衡器的心跳检查那么trace.ignore_path可以这样配置trace.ignore_path${SW_IGNORE_PATH:/actuator/health,/actuator/info,/health,/ping}如果你希望匹配所有以/actuator开头的端点包括/actuator/metrics、/actuator/env等可以用**通配符trace.ignore_path${SW_IGNORE_PATH:/actuator/**,/health,/ping}这里要说明一点/actuator/**会把所有 actuator 相关的端点都忽略掉包括/actuator/prometheus如果有暴露 Prometheus 指标的话。在 SkyWalking 的监控中这些指标采集请求同样属于高频低价值请求忽略掉没有问题。如果你使用环境变量来配置在docker-compose.yml或 Kubernetes 的 environment 中这样写- name: SW_IGNORE_PATH value: /actuator/**,/health,/ping验证方式重启服务后调用一次健康检查接口然后到 SkyWalking 的追踪列表里搜索这个路径应该没有任何 trace 记录。如果还能看到说明配置没生效检查进程是否真的重启了。4.2 静态资源请求的排除方案静态资源的处理稍微复杂一点因为不同的 Web 框架的静态资源路径格式并不统一。对于 Spring Boot 应用默认的静态资源路径是classpath:/static/classpath:/public/classpath:/resources/classpath:/META-INF/resources/这些路径可以通过spring.mvc.static-path-pattern来修改默认是/**。如果没改过默认配置那么访问http://localhost:8080/js/app.js实际上对应的是classpath:/static/js/app.js。对应的 ignore 配置如下trace.ignore_path${SW_IGNORE_PATH:/actuator/**,/health,/ping,/static/**,/public/**,/resources/**,/favicon.ico}这里把/favicon.ico单独列出来了因为浏览器每次打开页面都会自动请求这个文件虽然请求量不大但它在追踪列表里非常碍眼。如果你用的是 Nginx 对外提供静态资源而不经过应用层那 application 层其实只处理动态请求这种情况就不需要配置静态资源忽略规则。但如果你把前端构建的 dist 目录放进了 Spring Boot 应用里比如打成 jar 包一起部署那/static/**的忽略规则就非常必要了。4.3 文件上传下载等长耗时接口的处理文件上传下载接口的忽略方式比较特殊不是无脑忽略而是要看情况。如果你的业务需要监控文件传输的成功率和耗时趋势那就不应该完全忽略。但如果你只是希望业务接口的平均响应时间更真实可以考虑将大文件接口从统计中排除。假设上传接口是/api/file/upload下载接口是/api/file/download配置如下trace.ignore_path${SW_IGNORE_PATH:/actuator/**,/health,/ping,/static/**,/public/**,/resources/**,/favicon.ico,/api/file/upload,/api/file/download}如果你只想忽略大于某个阈值的请求那在 SkyWalking agent 层做不到。agent 端是对路径做匹配无法判断请求体大小。这种情况有另一种思路在业务代码里对于大文件请求直接不写入 SkyWalking 的上下文。比如在拦截器里判断 Content-Length 大于 10MB 的话把当前请求的 traceId 设为空SkyWalking agent 就不会上报。这个方案需要自己写代码不是纯配置能实现的这里不做展开。我的实际经验是文件上传下载接口在排除名单里要单独建一个分组来评估而不是直接混在一起全部忽略。如果业务对文件传输质量比较敏感建议保留监控同时单独看这个接口的耗时分布观察 P95 和 P99 的变化趋势。如果只是普通业务文件如用户头像、附件等那直接忽略掉就行。5. 常见问题与排查技巧实录这部分是我在实际支持和运维过程中最常遇到的问题整理。每一个都踩过写出来帮大家少走弯路。5.1 配置了 ignore_path 但完全不生效现象agent.config里已经配置了trace.ignore_path重启服务后健康检查接口仍然出现在追踪列表里。排查顺序先检查 agent 是否真的加载了新配置。用jinfo -flag查看 JVM 参数或者在应用启动日志中搜索agent.config的加载路径。SkyWalking agent 在启动时会打印配置文件的绝对路径例如INFO SkyWalkingAgent:102 - Config file path: /opt/skywalking-agent/config/agent.config确认这个路径是不是你修改的那个文件。我在排查时发现很多情况下是因为同时存在多个 agent 目录改了一个加载的是另一个。检查配置格式。trace.ignore_path的值不能有空格除非路径本身需要多个路径用英文逗号分隔不能使用全角逗号不能有多余的缩进。看起来是小问题实际出现的概率非常高。确认重启的是不是带 SkyWalking agent 的进程。如果你是在 IDEA 里直接重启了应用但启动参数中的-javaagent指向的是另一个目录的 agent那自然是不会加载新配置的。确认匹配路径的格式。你可以先用最简单的方式测试比如配置/health而不是/health/**或者带上下文路径的格式。如果/health能忽略而/health/**不能那多数是路径匹配的问题。我遇到的一个真实案例有个同事配置了/actuator/health但通配符写成了/actuator/*然后来问为什么不生效。原因就是/actuator/*匹配的是/actuator/xxx这样的二级路径而/actuator/health是直接匹配Ant 通配符中*不包含斜杠所以这种配置只对少一层级的路径有效。正确的写法是/actuator/**或者直接把/actuator/health写全。5.2 路径匹配不准确的坑现象想忽略/static/js/app.js配置了/static/**结果发现/static/img/logo.png也被忽略了。这个其实是正常的。/static/**匹配static目录下的所有子路径包括所有层级。如果你只想匹配static/js下的内容应该配置/static/js/**。反过来也有坑想匹配/static/*.js以为*能匹配文件名但*不跨层级只能匹配/static/app.js这样的直接文件/static/js/app.js是匹配不到的。建议在配置之前先画清楚路径结构避免凭感觉写通配符。5.3 忽略了健康检查会影响告警和拓扑现象配置了忽略健康检查接口过了一段时间发现服务拓扑图里两个服务之间的连线消失了或者某个依赖组件的健康状态无法查看。原因健康检查接口被忽略后相应的链路追踪数据不会上报服务拓扑中的节点关系是基于调用关系建立的。如果服务 A 调用服务 B 的唯一路径是健康检查接口而这条链路被忽略了A 和 B 之间的拓扑关系自然就消失了。解决方案如果你的服务之间完全依赖健康检查接口来维持拓扑关系建议保留一条健康检查链路不忽略或者为健康检查单独设置一个采样率让少量数据进入系统以维持拓扑图的完整性。SkyWalking 的采样配置是agent.sample_n_per_3_secs${SW_AGENT_SAMPLE_N_PER_3_SECS:1}这个参数的意思是每 3 秒采集多少条追踪。如果设为 1那么在 3 秒窗口内只上报 1 条链路数据剩下的全部丢弃。这种方案可以大幅减少健康检查接口的数据量同时保留拓扑关系。对于高频健康检查场景这个方案比全部忽略更合理。5.4 ignore_path 不改也能生效的场景现象同事说我没有改 ignore_path但接口不再上报了。排查发现应用的访问路径变了。原来健康检查是/health后来改成了/healthz流量不再经过/healthSkyWalking 自然就没有这个路径的数据了。这个场景看起来好笑实际很常见。当负载均衡层、网关层做路径重写后应用层收到的路径和你在 SkyWalking 里看到的路径可能不一致。比如 Nginx 把外部/ping转发为内部的/health你在 SkyWalking 里应该配置的是内部路径/health而不是外部的/ping。这里的关键是理解 SkyWalking agent 记录的是应用实际收到的 requestURI不是外部访问的 URL。5.5 不同语言的 Agent 配置差异现象Java 的 agent.config 里配置了 ignore_path但 Node.js 项目也用了 SkyWalking agent想配同样的效果却找不到配置项。原因不同语言的 agent 配置项名称和作用范围不完全一样。Java agent 对应的是trace.ignore_pathNode.js agent 对应的是ignore参数Python agent 需要在插件配置中处理。如果你用的是非 Java 服务建议先去查看对应语言的 agent 文档不要在 Java 的配置方法上死磕。6. 还可以这样优化Agent 全局限流和其他优化手段ignore_path 只是起点真正让 SkyWalking 监控数据保持干净清爽还有几个非常实用的优化手段。6.1 采样率调优对于非核心服务或者调用量特别大的服务可以调低采样率不必把每个请求都记录下来。agent.sample_n_per_3_secs${SW_AGENT_SAMPLE_N_PER_3_SECS:1}这个参数的含义是每 3 秒采样 N 条追踪。默认值是1如果设置为-1表示全部采样。对于健康检查特别频繁的服务我通常建议设置一个较小的值比如每 3 秒 1 条这样既能保留部分链路用于排查问题又不会撑爆存储。需要注意的是采样率降低后服务拓扑图中看到的调用次数会按采样比例放大但不一定完全准确。对于精细化性能分析尤其是需要看 P99 延迟的时候建议对核心链路保持全量采样只有噪音接口才用 ignore_path 或单独采样。6.2 链路数据的过期清理如果你发现即使忽略了很多接口ES 中的 trace 数据量仍然增长很快那问题可能出在 OAP Server 的索引策略上。SkyWalking 默认的 trace 数据保留时间是 3 天core/topN/report-period和storage/elasticsearch中的 TTL 配置。如果业务需要更长的链路追踪留存时间可以在application.yml中调整storage: elasticsearch: namespace: ${SW_NAMESPACE:} # 索引分片数和副本数根据数据量调整 indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:2} indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:0} # 数据保留天数 recordDataTTL: ${SW_RECORD_DATA_TTL:3} otherDataTTL: ${SW_OTHER_DATA_TTL:36}这里recordDataTTL是明细数据的保留时间默认 3 天otherDataTTL是聚合数据的保留时间默认 36 小时。如果存储告紧优先调低recordDataTTL聚合数据保留时间长一点不影响整体分析。6.3 按服务粒度定义不同的忽略规则如果微服务架构中有多个服务不同服务的健康检查路径可能完全不同。比如服务 A 的探活路径是/actuator/health服务 B 的探活路径是/internal/health服务 C 用的是 gRPC 健康检查不走 HTTP 路径。一个通用方案是在每个服务的 agent.config 里分别配置自己的 ignore_path但这样做运维成本比较高。我采用的方案是在服务的部署编排层统一注入环境变量例如 Kubernetes 中通过 ConfigMap 管理每个服务的 SW_IGNORE_PATH 配置更新只需要修改 ConfigMap 后滚动重启 Pod。这里有一个小技巧可以在环境变量中把通配路径统一写成一个基础列表然后追加各服务的特殊路径。例如apiVersion: v1 kind: ConfigMap metadata: name: skywalking-agent-config data: default-ignore-path: /actuator/**,/health,/ping,/static/**,/public/**,/resources/**,/favicon.ico然后在 Deployment 中引用这个 ConfigMap 并追加自定义路径env: - name: SW_IGNORE_PATH value: /actuator/**,/health,/ping,/static/**,/public/**,/resources/**,/favicon.ico,/custom/health这种做法的好处是各服务共用一套基础配置又保留了按服务定制的空间管理起来非常清晰。6.4 与 Prometheus 监控的边界划分最后聊聊一个经常让人困惑的问题有了 Prometheus Grafana还需要在 SkyWalking 中处理健康检查吗我的看法是两者定位不同不能互相替代。Prometheus 擅长采集指标和告警但它不太适合做跨服务的链路追踪排查。SkyWalking 的优势在于端到端调用链分析比如一个请求先从网关到订单服务再到支付服务最后到消息队列整个调用过程在 SkyWalking 里可以直观地看到。健康检查接口的这种调用链路通常很短对排障几乎没有价值所以无论 Prometheus 是否存在我都建议在 SkyWalking 中把高频无用的健康检查排除掉。这样可以保证链路追踪页面里展示的都是真正有分析价值的调用链。6.5 线上配置后的效果验证配置完成后如何判断效果我一般会看三个维度的数据。第一个是 SkyWalking 的追踪列表确认被忽略的接口不再出现。第二个是 ES 索引的数据增长率如果配置正确数据增长速度会明显下降。第三个是服务拓扑图和响应时间统计健康检查接口消失后业务接口的统计数据会变得更加平滑、真实。有一次帮一个电商团队配置完成后对比了一周的数据ES 中 trace 索引的大小下降了约 60%OAP Server 的 CPU 使用率下降了约 30%监控面板上的接口列表从几百个减少到几十个查找具体业务接口变得非常容易。这个效果超出了预期也让团队真正感受到了忽略规则的价值。7. 总结配置模板可直接抄作业为了让这篇文章可以直接落地我整理了一个通用配置模板。根据你的实际环境微调即可。7.1 Spring Boot Actuator 场景trace.ignore_path${SW_IGNORE_PATH:/actuator/**,/health,/ping,/static/**,/public/**,/resources/**,/favicon.ico}这个配置适用于大多数 Spring Boot 项目健康检查走 Actuator同时部署了前端静态资源的场景。7.2 纯 API 服务无静态资源trace.ignore_path${SW_IGNORE_PATH:/actuator/**,/health,/ping}如果服务完全不提供静态资源不用配置静态资源的忽略规则少写一点就少一点匹配开销。7.3 包含文件上传下载的场景trace.ignore_path${SW_IGNORE_PATH:/actuator/**,/health,/ping,/static/**,/public/**,/resources/**,/favicon.ico,/api/file/upload,/api/file/download}如果文件接口对业务很重要建议保留监控只忽略非核心的那部分。7.4 多环境差异化配置在 Kubernetes 中通过环境变量覆盖默认配置env: - name: SW_IGNORE_PATH value: /actuator/**,/health,/ping,/static/**,/public/**,/resources/**,/favicon.ico在这种方式下如果某个环境需要保留健康检查监控只需修改这个环境的环境变量值不用改动 agent.config 文件运维起来非常方便。我在实际使用中发现最稳妥的做法是先把匹配规则简化到最小集合逐个验证生效之后再逐步扩充。一次配置太多路径如果某些没生效很难判断是路径写错了还是配置根本没加载。这个技巧帮我避免了很多无效排查。