Spring Boot Actuator 有什么作用？生产环境如何安全使用？

简化版

Actuator 为应用提供健康、指标、日志级别、线程、配置等运维端点，并通过 Micrometer 对接监控系统。生产环境不能直接暴露全部端点，应区分“端点是否启用”和“是否通过 Web/JMX 暴露”，只开放必要端点并配置认证授权、网络隔离和敏感信息保护。

详细版

引入 spring-boot-starter-actuator 后，可使用 /actuator/health、/actuator/metrics 等端点；默认 Web 暴露范围较保守，新增端点通常需要通过 management.endpoints.web.exposure.include 显式开放。Prometheus 抓取还需要相应 Micrometer registry 并暴露 prometheus 端点。

Health 适合表达依赖可用性，Metrics 适合观察随时间变化的数值。Kubernetes 场景应区分 liveness 和 readiness：存活失败意味着进程需要重启，就绪失败意味着暂时停止接收流量，不能把短暂数据库故障随意判为进程死亡。

完整版教学

一、端点提供哪些信息

常见端点包括：

• health：应用及各 HealthIndicator 的健康状态；
• metrics：Micrometer 指标名称与样本查询；
• prometheus：Prometheus 文本格式抓取端点，需要对应 registry；
• loggers：查看或调整日志级别；
• threaddump、heapdump：线程和堆诊断；
• env、configprops、beans、mappings：运行时配置和容器信息。

不同端点的存在、默认启用状态和访问控制会随 Boot 版本及应用类型变化，实际应查看当前版本端点发现页和配置元数据。

二、启用、暴露与访问控制是三件事

一个端点先要在应用中启用，随后才可能通过 HTTP 或 JMX 技术暴露，暴露后还需要安全规则决定谁能访问。只配置 Spring Security 并不能让一个未暴露端点出现，暴露端点也不代表已经安全。

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus

不要在生产环境使用 include: "*" 后再寄希望于路径不公开。heapdump、env、configprops 等端点可能包含大量内部结构或敏感线索。

三、健康检查与探针语义

HealthIndicator 返回 UP、DOWN、OUT_OF_SERVICE 等状态，并可组成健康组。readiness 应回答“现在是否可以接收新流量”，liveness 应回答“进程是否已陷入无法自行恢复的状态”。

如果把数据库短暂不可用加入 liveness，编排平台可能不断重启所有实例，反而放大故障。数据库不可用通常更适合影响 readiness 或业务降级，具体仍要根据服务是否能在无数据库时恢复判断。

四、Metrics 与 Micrometer

Actuator 使用 Micrometer 提供统一指标门面，JVM、HTTP、连接池等自动配置会注册 Meter。接入 Prometheus 等后端时，应用暴露或推送的是带标签的时间序列。

自定义指标应控制标签基数。把 userId、订单号或完整 URL 作为 tag 会产生海量时间序列，导致内存与监控存储成本失控。计数、耗时分布和当前值应分别使用适合的 Counter、Timer、Gauge 等类型。

五、安全配置边界

类路径存在 Spring Security 且应用没有自定义 SecurityFilterChain 时，Boot 会提供一定的 Actuator 安全自动配置；一旦应用定义自己的 SecurityFilterChain，通常就由应用负责完整访问规则。不能只因“引了 Security”就认定所有管理端点安全。

生产中常把管理端口或地址与业务流量分离，再通过防火墙、网关、mTLS 或认证授权限制访问。健康端点也应控制 details 的显示范围，避免把数据库地址、异常栈和配置值返回给匿名用户。

六、自定义端点还是普通 Controller

需要同时通过不同管理技术暴露、并融入 Actuator 发现和访问模型的运维能力，可使用 @Endpoint 及读写操作注解。面向普通业务用户的 API 仍应写 Controller，不要把 Actuator 当通用 REST 框架。

自定义健康检查要设置合理超时并避免昂贵调用。探针本身若每秒执行复杂查询，也会成为新的故障源。

七、用一次生产暴露方案算清风险

假设一个服务有 14 个可用端点，却只需要负载均衡探活、Prometheus 抓取和版本信息，那么 Web 暴露集合应收敛到 health,prometheus,info 这 3 个，而不是为了省配置开放全部 14 个。若 Prometheus 每 15 秒抓取一次，一天会请求 86400 / 15 = 5760 次；自定义 HealthIndicator 若每次执行 2 秒全表查询，就会把探针本身变成持续负载，因此健康检查必须轻量、超时可控。

端点类别	示例	匿名暴露建议	主要风险
基础探活	health 的有限信息	可按网络边界开放	详情泄露依赖地址
指标采集	prometheus	仅监控网络或认证后开放	业务标签、容量信息泄露
运行期诊断	threaddump、heapdump	不对公网开放	内存数据、线程与代码结构泄露
配置观察	env、configprops	严格限制	配置值与内部拓扑泄露
运行期修改	loggers 等写操作	强认证、审计	被滥用后影响稳定性

Internet
   ×  不直接访问管理端点
   │
business gateway ──> application port
monitoring network ──mTLS/RBAC──> management port ──> selected endpoints

管理端口分离只能建立网络边界，不能替代应用层授权；反过来，只有认证而没有网络隔离，也会扩大暴力尝试和信息探测面。敏感值脱敏、最小暴露、只读优先、访问审计应一起落地。

安全记忆钩子：先问端点“是否启用”，再问“通过什么技术暴露”，最后问“谁被授权访问”；三关少一关都不能称为安全。

八、常见误区与追问

• 误区：引入 Actuator 后所有端点都会通过 HTTP 自动开放。 端点存在、端点启用和 Web/JMX 暴露是不同层次，默认 Web 暴露通常很克制。
• 误区：有 Spring Security 依赖就无需再写管理端点规则。 应用一旦提供自己的 SecurityFilterChain，通常需要自行承担完整授权配置，不能依赖模糊的默认行为。
• 误区：数据库不可用就应让 liveness 失败。 可自行恢复的外部依赖故障通常更适合影响 readiness，错误重启会放大级联故障。
• 追问：health 和 metrics 的区别是什么？ health 给出当前能否服务的状态判断，metrics 是可随时间聚合的数值序列，二者用途和消费方式不同。
• 追问：为什么不能把 userId 作为 Micrometer 标签？ 高基数值会为每个用户生成新时间序列，迅速消耗应用内存和监控后端存储。
• 追问：Prometheus 端点为什么访问不到？ 除 Actuator 外还需对应 registry 依赖，并且 prometheus 端点必须被启用且加入 Web 暴露集合。

九、加强记忆

Actuator 是运维观察入口：Health 看可用性，Metrics 经 Micrometer 看趋势，诊断端点看现场。安全上按“启用 → 暴露 → 授权”三层检查，只开放必要端点，并把 liveness、readiness 和敏感详情的语义配置正确。