/tags/actuator/ Recent content in actuator on Hugo -- gohugo.io en Sat, 07 Nov 2026 10:54:00 +0800 /posts/spring-boot-actuator-management-port/ Sat, 07 Nov 2026 10:54:00 +0800 /posts/spring-boot-actuator-management-port/ 背景 在 Kubernetes 环境中部署 Spring Boot 应用时，actuator 端点是跟着业务走同一个端口，还是通过 management.server.port 单独开一个管理端口，是微服务基础配置里经常被讨论的问题。 很多团队在推进容器化和可观测基线时，往往会经历两种方案并存的混乱期： 一部分服务单独开了管理端口，但部署清单或 Helm chart 里的 ServiceMonitor 仍然去抓业务端口，导致 Prometheus 出现大量 TargetDown 告警； 开了管理端口的服务把 liveness 和 readiness 探针直接指向管理端口，业务工作线程耗尽后探针却依然正常返回； 部分应用配置了 server.servlet.context-path，如果共用业务端口，端点前缀会跟着变动，导致监控抓取路径难以统一维护。 单独开端口不仅仅是修改一行配置，它背后涉及 Spring Boot 的双容器运行时模型、Kubernetes 探针有效性，以及集群内部网络的边界管理。 本篇的配置项与行为按 Spring Boot 4.1 参考文档核对，与 3.4、3.5 版本的机制保持一致。 运行时机制：双 WebServer 与子上下文 在 Spring Boot 中，一旦为 management.server.port 指定了与 server.port 不同的端口，框架底层的初始化逻辑就会发生分流。 此时 Spring Boot 不只是简单地增加了一个端口监听，而是通过 ManagementContextAutoConfiguration 创建了一个独立的子应用上下文（child ApplicationContext），并在其中启动了第二个独立的内嵌 Web 服务实例（如 Tomcat、Jetty 或 Undertow）。 flowchart TB subgraph K8S["Kubernetes 节点与控制面"] Ingress["Ingress / 网关"