1. 从一次线上告警说起为什么我们需要 Actuator去年冬天的一个凌晨我被一条告警短信吵醒——某核心接口的 P99 响应时间突然从 80ms 飙到了 2.3s。爬起来连上服务器第一反应是看日志但日志里只有零星的业务报错根本看不出系统整体状态。CPU 多少内存有没有泄漏数据库连接池是不是被打满了线程池队列积压了多少这些信息一个都拿不到。最后折腾了快一个小时才发现是某个定时任务触发了全表扫描把数据库连接池占满了。那次事故之后我做的第一件事就是给所有 Spring Boot 服务加上 Actuator。很多人对 Actuator 的印象还停留在加个依赖就能看 /health 和 /info但实际上它是 Spring Boot 生态里最被低估的一个模块。它能做的事情远超大多数人的想象运行时查看所有 Bean 的依赖关系、动态调整日志级别、导出线程栈和堆转储、监控 HTTP 请求的调用链路、甚至直接查看数据库连接池的实时状态。这篇文章是服务端性能监控最佳实践系列的第二篇专门聊 Spring Boot Actuator。我会从它到底解决了什么问题讲起然后逐个拆解那些真正在生产环境中有用的端点再讲怎么把它和 Prometheus、Grafana 串起来形成完整的监控闭环。如果你正在维护 Spring Boot 服务或者正在搭建监控体系这篇内容应该能帮你少走不少弯路。2. Actuator 到底解决了什么问题从盲人摸象到全景透视2.1 没有 Actuator 的时候我们是怎么排查问题的在 Actuator 出现之前排查线上问题基本靠三板斧看日志、登服务器敲命令、翻代码猜逻辑。这套方法不是不能用但效率极低而且严重依赖个人经验。举个例子你想知道当前应用的线程池状态。没有 Actuator 的话你得先jstack导出线程栈然后在几千行输出里搜索线程池相关的线程名再手动统计活跃线程数、队列长度。整个过程至少五分钟而且每次都要重复。再比如你想临时把某个包的日志级别从 INFO 调到 DEBUG传统做法是改配置文件、重新打包、重新部署——等部署完问题现场早就没了。更麻烦的是这些操作在生产环境往往受限。很多公司不给开发人员服务器登录权限只能通过跳板机或者运维代劳。一来一回故障恢复时间被拉得很长。2.2 Actuator 的核心价值把运行时状态变成可编程的接口Actuator 的本质是把应用运行时的各种内部状态暴露成 HTTP 接口或 JMX MBean。这意味着你可以用任何能发 HTTP 请求的工具去获取这些信息——浏览器、curl、Postman、监控系统甚至是另一个程序。这个设计带来的最大好处是自动化。以前需要人工登录服务器敲命令才能拿到的数据现在监控系统可以定时抓取、自动告警。以前需要重启才能生效的配置变更现在一个 POST 请求就能搞定。我整理了一个对比表能直观看出有和没有 Actuator 的差别排查场景传统方式使用 Actuator查看健康状态手动检查各依赖组件/actuator/health一键获取调整日志级别改配置重启应用POST 请求动态修改立即生效查看线程栈登录服务器执行 jstack/actuator/threaddump直接返回 JSON查看 Bean 依赖翻代码或启动时看日志/actuator/beans完整依赖图获取堆转储jmap 命令导出文件再下载/actuator/heapdump直接下载查看 HTTP 调用统计自己埋点或看访问日志/actuator/metrics/http.server.requests2.3 一个容易被忽略的定位Actuator 是监控体系的数据源很多人把 Actuator 当成一个调试工具只在开发阶段用用。这个定位其实窄了。在生产环境中Actuator 更重要的角色是监控数据的生产者。Prometheus 通过定时抓取/actuator/prometheus端点获取指标Grafana 再把 Prometheus 的数据可视化。整个链路里Actuator 负责把应用内部状态翻译成标准格式的指标这是监控体系的地基。没有这个地基上层做得再漂亮也是空中楼阁。注意Actuator 默认只暴露/health和/info两个端点。生产环境需要显式配置暴露哪些端点但绝对不能无脑全部暴露后面会详细讲安全配置。3. 端点分类详解哪些能直接用哪些要小心Actuator 的端点按用途可以分成几大类。我不会把官方文档里的端点列表照搬一遍而是挑那些在实际工作中真正用得上的说清楚它们各自解决什么问题、怎么用、有什么坑。3.1 健康检查类/health 不只是返回一个 UP/health是最常用的端点但很多人只看到它返回{status:UP}就以为完事了。实际上它的信息量可以很大。默认情况下Spring Boot 会根据 classpath 中存在的组件自动配置健康指示器HealthIndicator。比如引入了 DataSource就会有db指示器引入了 Redis就会有redis指示器。但默认这些详细信息是不展示的只返回一个总体的 UP 或 DOWN。要看到每个组件的详细状态需要配置management: endpoint: health: show-details: always配置之后/actuator/health会返回类似这样的结构{ status: UP, components: { db: { status: UP, details: { database: MySQL, validationQuery: isValid() } }, redis: { status: UP, details: { version: 6.2.6 } }, diskSpace: { status: UP, details: { total: 107374182400, free: 53687091200, threshold: 10485760 } } } }这里有个实战经验show-details: always在开发环境很方便但生产环境可能泄露内部信息比如数据库版本、磁盘路径。更稳妥的做法是用show-details: when-authorized配合 Spring Security 做权限控制只有认证通过的请求才能看到详情。另外健康检查的粒度也值得考虑。默认的健康检查是全有或全无——任何一个组件 DOWN整体就是 DOWN。但有时候某个非核心组件挂了不应该影响整个服务的健康状态。这时候可以实现自定义的HealthIndicator或者用HealthContributor做分组。3.2 指标类/metrics 里藏着应用的体检报告/actuator/metrics是 Actuator 最有价值的端点之一。它基于 Micrometer 库自动收集了大量 JVM 和应用级别的指标。访问/actuator/metrics会返回所有可用指标的名称列表比如jvm.memory.usedJVM 各内存区域的使用量jvm.gc.pauseGC 暂停时间统计jvm.threads.live活跃线程数http.server.requestsHTTP 请求的响应时间分布system.cpu.usage系统 CPU 使用率process.uptime应用运行时长要看某个指标的具体数值访问/actuator/metrics/{metricName}。比如/actuator/metrics/jvm.memory.used会返回{ name: jvm.memory.used, measurements: [ { statistic: VALUE, value: 268435456 } ], availableTags: [ { tag: area, values: [heap, nonheap] }, { tag: id, values: [G1 Eden Space, G1 Old Gen, Metaspace] } ] }这里的关键是availableTags。你可以用它做更细粒度的查询比如只看堆内存/actuator/metrics/jvm.memory.used?tagarea:heap。我在实际使用中总结了几条经验第一http.server.requests这个指标默认只记录总体统计但你可以通过配置让它按 URI、方法、状态码分组。配置方式是在application.yml中设置management: metrics: web: server: request: autotime: enabled: true percentiles-histogram: http.server.requests: true第二默认的指标保留策略可能不够用。Micrometer 支持配置指标的过期时间、直方图桶等参数。对于 P99 这种分位数指标建议开启percentiles-histogram这样 Prometheus 才能正确计算分位数。第三不要忽视jvm.gc.pause指标。很多性能问题表面上是接口慢根因其实是 GC 频繁。这个指标能帮你快速判断是不是 GC 的锅。3.3 运行时诊断类threaddump、heapdump 和 loggers这一类端点在排查具体问题时特别有用但因为涉及敏感信息生产环境需要谨慎暴露。/actuator/threaddump返回当前所有线程的堆栈信息格式是 JSON。相比jstack命令它的优势是可以通过 HTTP 远程获取不需要登录服务器。返回的 JSON 里包含线程名、线程状态、锁信息、堆栈轨迹用程序解析起来很方便。我遇到过一个典型场景某接口偶尔超时但日志里没有任何异常。通过/actuator/threaddump抓了几次线程栈发现有一个线程长时间处于WAITING状态卡在一个外部 HTTP 调用上。顺着堆栈找到代码位置发现是没设置超时时间。这个问题如果靠看日志可能永远找不到。/actuator/heapdump会触发一次堆转储并直接返回.hprof文件。这个操作比较重会暂停应用取决于 JVM 参数所以绝对不能在高峰期随便调用。一般只在怀疑内存泄漏时使用拿到文件后用 MAT 或 VisualVM 分析。/actuator/loggers是我用得最多的端点。它支持 GET 和 POST 两种方法GET/actuator/loggers返回所有 logger 的配置GET/actuator/loggers/com.example返回指定 logger 的配置POST/actuator/loggers/com.example动态修改日志级别动态修改日志级别的请求体是{ configuredLevel: DEBUG }这个功能在排查线上问题时简直是救命稻草。你可以在不重启应用的情况下把某个包的日志级别调到 DEBUG复现问题后再调回来。我一般会把这个端点保留在生产环境但加上权限控制。3.4 配置与依赖类beans、configprops 和 env/actuator/beans返回应用上下文中所有 Bean 的完整依赖关系。这个端点在排查为什么这个 Bean 没注入或者循环依赖问题时特别有用。返回的 JSON 结构是树形的能清楚看到每个 Bean 的类型、作用域、依赖的 Bean 列表。/actuator/configprops返回所有ConfigurationProperties的配置值。注意它默认会对敏感字段做脱敏处理比如密码显示为******但还是要小心因为有些敏感信息可能没有被正确识别。/actuator/env返回所有环境变量和配置属性的来源。这个端点在排查配置为什么没生效时很有用——它能告诉你某个属性最终是从哪个配置源加载的是 application.yml、环境变量还是命令行参数。注意/actuator/env和/actuator/configprops在生产环境属于高风险端点因为它们可能泄露数据库密码、API 密钥等敏感信息。如果确实需要暴露务必配合 Spring Security 做严格的权限控制并且确认脱敏配置覆盖了所有敏感字段。4. 从零搭建Actuator 的引入、配置与安全加固4.1 依赖引入与基础配置在 Spring Boot 项目中引入 Actuator 非常简单加一个 starter 依赖就行dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency加完之后启动应用默认就能访问/actuator/health和/actuator/info。但这两个端点远远不够我们需要显式配置暴露哪些端点。在application.yml中management: endpoints: web: exposure: include: health,info,metrics,loggers,threaddump,beans,configprops,env,prometheus base-path: /actuator endpoint: health: show-details: when-authorized metrics: enabled: true这里有几个关键决策点需要解释为什么用include而不是exclude因为白名单比黑名单安全。如果哪天 Spring Boot 升级引入了新的端点用exclude的话新端点会自动暴露而用include则不会。安全策略上默认拒绝永远比默认允许更稳妥。base-path要不要改默认是/actuator改成别的路径能起到一点隐藏作用但这不是真正的安全措施。真正的安全要靠认证和授权。show-details设成什么开发环境用always方便调试生产环境用when-authorized配合权限控制。如果服务在内网且没有敏感信息always也可以接受但要评估风险。4.2 安全加固别让 Actuator 成为攻击入口Actuator 端点暴露的信息非常敏感如果不做安全控制相当于把应用的内脏摊开给所有人看。我见过最离谱的情况是某公司的/actuator/env直接暴露在公网数据库密码明文可见。安全加固的核心思路是认证 授权 网络隔离。第一层是网络隔离。Actuator 的管理端口最好和业务端口分开只在内网或管理网段可访问。Spring Boot 支持配置独立的管理端口management: server: port: 8081 address: 127.0.0.1这样 Actuator 只在本地监听外部无法直接访问。如果监控系统需要远程抓取可以通过反向代理或者只监听内网 IP。第二层是认证。如果项目已经引入了 Spring SecurityActuator 端点会自动受到保护。可以针对 Actuator 路径配置独立的认证规则Configuration public class ActuatorSecurityConfig { Bean public SecurityFilterChain actuatorFilterChain(HttpSecurity http) throws Exception { http.securityMatcher(EndpointRequest.toAnyEndpoint()) .authorizeHttpRequests(auth - auth .requestMatchers(EndpointRequest.to(health, info)).permitAll() .anyRequest().hasRole(ACTUATOR_ADMIN) ) .httpBasic(Customizer.withDefaults()); return http.build(); } }这段配置的逻辑是/health和/info允许匿名访问方便负载均衡器做健康检查其他端点需要ACTUATOR_ADMIN角色。第三层是敏感信息脱敏。对于/env和/configprops这类端点Spring Boot 默认会脱敏包含password、secret、key、token等关键词的属性。但这个默认规则不一定覆盖所有情况可以通过自定义SanitizingFunction来扩展Bean public SanitizingFunction customSanitizingFunction() { return data - { String key data.getKey(); if (key.contains(credential) || key.contains(private)) { return data.withValue(******); } return data; }; }4.3 自定义端点暴露业务特有的监控指标Spring Boot 内置的端点覆盖了通用的运行时信息但业务特有的指标需要自己实现。比如你想监控订单队列的积压情况、缓存命中率、某个业务开关的状态都可以通过自定义端点暴露。自定义端点的实现方式是使用Endpoint注解Component Endpoint(id orderQueue) public class OrderQueueEndpoint { private final OrderQueueService orderQueueService; public OrderQueueEndpoint(OrderQueueService orderQueueService) { this.orderQueueService orderQueueService; } ReadOperation public MapString, Object getQueueStatus() { MapString, Object status new HashMap(); status.put(pendingCount, orderQueueService.getPendingCount()); status.put(processingCount, orderQueueService.getProcessingCount()); status.put(failedCount, orderQueueService.getFailedCount()); status.put(oldestPendingAgeSeconds, orderQueueService.getOldestPendingAge()); return status; } WriteOperation public void clearFailedOrders() { orderQueueService.clearFailed(); } }ReadOperation对应 GET 请求WriteOperation对应 POST 请求。访问/actuator/orderQueue就能拿到队列状态。这里有个经验自定义端点的 ID 命名建议用驼峰式Actuator 会自动转换成短横线格式。比如orderQueue对应的访问路径是/actuator/order-queue。4.4 与 Prometheus 集成让指标真正流动起来Actuator 的/metrics端点返回的是 JSON 格式适合人工查看但不适合监控系统抓取。Prometheus 需要的是它自己的文本格式。所以需要引入 Micrometer 的 Prometheus 注册表dependency groupIdio.micrometer/groupId artifactIdmicrometer-registry-prometheus/artifactId /dependency加完依赖后/actuator/prometheus端点会自动可用。Prometheus 的抓取配置大概是这样的scrape_configs: - job_name: spring-boot-app metrics_path: /actuator/prometheus scrape_interval: 15s static_configs: - targets: [localhost:8081]这里有几个配置细节值得注意抓取间隔设多少15 秒是 Prometheus 的默认值对大多数应用够用。如果业务对实时性要求高可以调到 5 秒但会增加应用和 Prometheus 的负担。指标基数问题。Prometheus 对指标基数cardinality很敏感。如果http.server.requests按 URI 分组而 URI 里包含用户 ID 这种高基数标签会导致指标爆炸。解决办法是在配置中限制标签的取值或者用 URI 模板代替实际 URI。JVM 指标的采集。Micrometer 会自动采集 JVM 指标但有些指标需要额外配置。比如 GC 暂停时间的直方图需要在配置中开启management: metrics: distribution: percentiles-histogram: jvm.gc.pause: true slo: jvm.gc.pause: 10ms, 50ms, 100ms, 500ms5. 生产环境踩过的坑那些文档里不会写的事5.1 健康检查导致的级联故障这是一个真实踩过的坑。某次大促前我们把服务的健康检查接入了负载均衡器。配置是/actuator/health返回非 200 就把节点摘掉。结果大促开始后数据库连接池因为流量激增被打满db健康指示器返回 DOWN负载均衡器把所有节点都摘了整个服务不可用。但实际上应用本身还能处理部分请求只是数据库暂时压力大。这个坑的本质是健康检查的粒度和负载均衡的策略不匹配。健康检查是全有或全无但实际服务的降级能力是分级的。解决方案有两个一是自定义健康检查逻辑把非核心依赖的健康状态排除在总体状态之外二是负载均衡器不要只依赖健康检查结合其他指标如响应时间、错误率做综合判断。5.2 指标采集带来的性能开销Actuator 的指标采集不是没有成本的。特别是开启percentiles-histogram之后每个请求都要记录直方图数据对高 QPS 服务来说这部分开销不可忽视。我做过一个简单的压测对比在 QPS 5000 的场景下关闭 Actuator 指标采集时 P99 是 45ms开启后变成 52ms增加了大约 15%。这个开销在大多数场景下可以接受但如果你的服务对延迟极其敏感就需要权衡。优化的思路是只采集真正需要的指标关闭不必要的指标。比如jvm.memory.used这种指标采集成本很低但http.server.requests的直方图采集成本较高。可以通过配置只对特定 URI 开启直方图。5.3 日志级别动态调整的后遗症/actuator/loggers动态调整日志级别很方便但有一个容易被忽略的问题调整后的级别不会持久化。应用重启后日志级别会恢复成配置文件里的值。这在排查问题时是好事不会永久改变配置但在某些场景下会带来麻烦。比如你临时把某个包的级别调到 DEBUG 来排查问题排查完忘了调回来结果日志文件疯狂增长磁盘被写满。我的做法是动态调整日志级别时一定记录一条操作日志并且设置一个提醒确保问题解决后及时恢复。有些团队会写一个定时任务每天检查是否有 logger 的级别和配置文件不一致如果有就告警。5.4 端点暴露顺序与路径冲突Spring Boot 的 Actuator 端点默认注册在/actuator路径下。如果你的应用本身有一个 Controller 映射到了/actuator开头的路径就会冲突。更隐蔽的问题是如果应用配置了server.servlet.context-pathActuator 的路径也会受到影响。比如 context-path 是/api那 Actuator 的实际路径就变成了/api/actuator/health。这一点在配置负载均衡器和监控系统时容易搞错。解决办法是显式配置management.endpoints.web.base-path把它设成一个不会冲突的路径比如/manage。6. 从 Actuator 到完整监控闭环还差哪几步6.1 告警规则的设计别让告警变成狼来了有了 Prometheus 和 Grafana 之后下一步是配置告警。但告警规则的设计是一门学问配得不好会导致告警疲劳——每天几百条告警最后没人看。我的经验是遵循几个原则告警要分级。P0 告警电话短信只留给真正影响用户的问题比如核心接口错误率超过 5%、服务完全不可用。P1 告警企业微信/钉钉用于需要关注但不紧急的问题比如磁盘使用率超过 80%。P2 告警邮件用于趋势性指标比如内存使用率持续上升。告警要有明确的处理动作。每条告警都应该能回答收到这条告警后我该做什么。如果一条告警的处理方式是看看再说那它就不应该存在。避免单点指标告警。不要只根据一个指标就告警要结合多个指标做综合判断。比如CPU 使用率超过 90%单独看可能只是正常波动但如果同时接口 P99 超过 1s且错误率上升那就是真问题了。6.2 监控大盘的设计让问题一眼可见Grafana 大盘的设计直接影响排查效率。我见过很多大盘堆了几十个图表但真正出问题时根本不知道看哪个。一个好的大盘应该遵循金字塔原则最上面是核心业务指标请求量、错误率、响应时间中间是应用指标JVM、线程池、连接池最下面是基础设施指标CPU、内存、磁盘、网络。排查问题时从上往下看逐层定位。对于 Spring Boot 应用我通常会配置这几个核心图表HTTP 请求概览QPS、P50/P95/P99 响应时间、错误率JVM 内存堆内存使用量、GC 次数和暂停时间线程池活跃线程数、队列长度、拒绝次数数据库连接池活跃连接数、空闲连接数、等待时间系统资源CPU、内存、磁盘 I/O6.3 日志与指标的联动从看到异常到定位根因指标能告诉你出问题了但通常不能告诉你为什么出问题。这时候需要日志来补充。理想的情况是指标告警触发后能一键跳转到对应时间段的日志查询。这需要在日志中记录 traceId并且指标和日志使用相同的时间轴。Spring Boot 3.x 集成了 Micrometer Tracing可以自动在日志中注入 traceId 和 spanId。配置方式management: tracing: sampling: probability: 1.0这样每条日志都会带上 traceId在 Grafana 中可以通过 traceId 关联到具体的请求链路。7. 一些零散但实用的经验关于 Actuator 的配置还有几个零散的点值得单独拎出来说。关于/info端点。默认它返回空对象但可以通过配置填充有用信息比如应用版本、构建时间、Git 提交号。这些信息在排查当前运行的是哪个版本时很有用。配置方式management: info: git: mode: full build: enabled: true关于端点的缓存。Actuator 的某些端点如/metrics返回的数据量大频繁访问会有性能开销。可以通过配置缓存时间来减少重复计算management: endpoint: metrics: cache: time-to-live: 10s关于自定义健康检查的超时。如果健康检查依赖外部服务一定要设置超时时间。否则外部服务卡住时健康检查也会卡住导致负载均衡器误判。可以通过配置management: health: defaults: enabled: false db: enabled: true然后实现自定义的HealthIndicator在里面控制超时。关于 Actuator 和 Spring Cloud 的配合。如果项目用了 Spring CloudActuator 的/health端点会被服务注册中心用来做健康检查。这时候要特别注意健康检查的粒度避免因为某个非核心依赖不可用导致服务被摘除。关于版本兼容性。Spring Boot 2.x 和 3.x 在 Actuator 的配置上有一些差异。比如 2.x 中management.endpoints.web.exposure.include的默认值是health,info3.x 也是但 3.x 对某些端点的默认行为做了调整。升级时要注意查看迁移指南。关于端点的访问日志。Actuator 端点的访问默认不会记录在业务访问日志中这给审计带来了困难。如果需要对 Actuator 的访问做审计可以通过配置management.endpoints.web.exposure.include配合自定义的 Filter 来实现。关于内存指标的单位。Actuator 返回的内存指标单位是字节但 Grafana 展示时通常需要转换成 MB 或 GB。在 Grafana 的查询语句中可以用/ 1024 / 1024做转换或者用 Grafana 的单位配置自动转换。关于 GC 指标的解读。jvm.gc.pause指标记录的是 GC 暂停的累计时间和次数。看这个指标时不要只看绝对值要看趋势。如果暂停时间突然增加或者 GC 频率明显上升通常意味着内存压力增大。关于线程池监控。Spring Boot 默认不暴露线程池指标需要手动注册。如果用的是ThreadPoolTaskExecutor可以通过ExecutorServiceMetrics来注册Bean public ExecutorServiceMetrics threadPoolMetrics(ThreadPoolTaskExecutor executor) { return new ExecutorServiceMetrics( executor.getThreadPoolExecutor(), business-thread-pool, Collections.emptyList() ); }注册之后/actuator/metrics/executor.active、/actuator/metrics/executor.queued等指标就可以用了。关于数据库连接池监控。如果用的是 HikariCPActuator 会自动暴露连接池指标包括活跃连接数、空闲连接数、等待线程数等。这些指标在排查数据库相关问题时非常有用。可以通过/actuator/metrics/hikaricp.connections.active查看。关于 Actuator 的测试。在写集成测试时可以用AutoConfigureMockMvc配合MockMvc来测试 Actuator 端点。但要注意测试环境和生产环境的端点暴露配置可能不同测试时要确保配置一致。关于端点的国际化。Actuator 端点的返回信息默认是英文的目前没有官方的国际化支持。如果确实需要中文只能自己实现自定义端点。关于 Actuator 和 API 网关的配合。如果应用前面有 API 网关要注意网关是否放行了 Actuator 的路径。有些网关默认只放行/api/**Actuator 的/actuator/**会被拦截。这时候需要在网关配置中单独放行或者把 Actuator 的管理端口和业务端口分开。关于端点的性能影响。/actuator/beans和/actuator/env这两个端点在数据量大时返回会很慢因为它们需要遍历整个应用上下文。在生产环境要谨慎调用最好加上缓存或者限制访问频率。关于 Actuator 的扩展点。除了自定义端点Actuator 还提供了EndpointFilter和AdditionalHealthEndpointPathsWebMvcEndpointHandlerMapping等扩展点可以实现更复杂的定制逻辑。比如给所有端点加上统一的响应头或者根据请求来源返回不同的健康检查结果。关于监控数据的保留策略。Prometheus 默认保留 15 天的数据对于长期趋势分析可能不够。可以通过配置storage.tsdb.retention.time来延长保留时间但要注意磁盘空间。另一个方案是使用远程存储把数据写到对象存储或时序数据库中。关于告警的静默和抑制。在计划内维护时需要提前静默告警避免误报。Prometheus 的 Alertmanager 支持静默规则可以按时间窗口、标签等条件静默告警。这个功能在大促、发布等场景下特别有用。关于 Actuator 在容器环境中的使用。在 Kubernetes 环境中Actuator 的/health端点通常被用作 liveness 和 readiness 探针。这时候要区分 liveness 和 readiness 的语义liveness 探针失败会重启容器readiness 探针失败只会把容器从 Service 的 Endpoints 中移除。对于 liveness 探针健康检查应该只关注应用本身是否存活不要依赖外部服务对于 readiness 探针可以包含外部依赖的检查。关于 Actuator 和配置中心的配合。如果项目用了配置中心如 Nacos、ApolloActuator 的/env端点会显示配置中心的属性源。但要注意配置中心的属性可能是加密的/env端点默认不会解密显示的是密文。如果需要查看解密后的值需要自定义SanitizingFunction或者使用配置中心提供的查看工具。关于 Actuator 的版本升级。从 Spring Boot 2.x 升级到 3.x 时Actuator 有一些破坏性变更。比如management.endpoints.web.exposure.include的默认值变了某些端点的路径变了/actuator/health的响应结构也有调整。升级前一定要仔细阅读迁移指南并且在测试环境充分验证。关于 Actuator 的日志。Actuator 本身的日志默认是 INFO 级别如果遇到端点不工作的问题可以把org.springframework.boot.actuate包的日志级别调到 DEBUG能看到端点注册和请求处理的详细过程。关于端点的自定义路径。除了全局的base-path每个端点还可以单独配置路径management: endpoints: web: path-mapping: health: healthcheck metrics: stats这样/actuator/health就变成了/actuator/healthcheck。这个功能在需要兼容旧系统或者隐藏端点时有用。关于 Actuator 的 CORS 配置。如果前端需要直接访问 Actuator 端点比如做一个简单的监控页面需要配置 CORSmanagement: endpoints: web: cors: allowed-origins: https://monitor.example.com allowed-methods: GET但生产环境不建议直接让前端访问 Actuator最好通过后端代理。关于 Actuator 的响应压缩。/actuator/metrics和/actuator/beans的响应可能很大开启 GZIP 压缩能显著减少传输时间server: compression: enabled: true mime-types: application/json关于 Actuator 和分布式追踪的配合。如果项目用了 Sleuth 或 Micrometer TracingActuator 的/actuator/metrics中会包含追踪相关的指标。这些指标可以帮助分析调用链路的性能瓶颈。关于 Actuator 的限流。如果 Actuator 端点暴露在公网不推荐一定要做限流防止被恶意刷。可以通过 Spring Cloud Gateway 或者 Nginx 做限流也可以在应用层用 Bucket4j 等库实现。关于 Actuator 的审计。Spring Boot 提供了AuditEventRepository可以记录敏感操作如动态修改日志级别。默认实现是InMemoryAuditEventRepository生产环境建议换成持久化实现。关于 Actuator 的测试覆盖率。自定义端点和健康检查逻辑应该写单元测试。Spring Boot 提供了EndpointWebMvcTest和HealthEndpointTest等测试注解可以方便地测试 Actuator 相关代码。关于 Actuator 的文档。自定义端点和健康检查应该写文档说明端点的用途、返回结构、访问权限。这些文档可以和 API 文档一起维护方便团队成员查阅。关于 Actuator 的监控告警联动。最后一点也是最重要的一点监控的最终目的是发现问题并解决问题。Actuator 提供了数据Prometheus 提供了存储和查询Grafana 提供了可视化Alertmanager 提供了告警。但真正解决问题还是要靠人。所以监控体系的设计要围绕如何让值班人员快速定位和解决问题来展开而不是堆砌技术栈。我在实际使用 Actuator 的这几年里最大的体会是它不是一个配好就不用管的组件而是需要根据业务特点持续调整的。哪些端点该暴露、健康检查的粒度怎么定、指标采集的开销如何平衡这些问题没有标准答案只能在实践中不断摸索。但只要你开始用起来并且把它接入监控体系你会发现排查问题的效率会有质的提升。