Eureka Server从Camden.R3升级到Flinchley.RC1后健康检查404问题咨询

我之前也踩过Spring Cloud版本升级的坑，针对你从Camden.R3升到Flinchley.RC1遇到的健康检查404，以及想确认客户端是否执行健康检查上下文的问题，给你梳理下具体的解决和验证步骤：

一、先搞定404的核心原因 #

Flinchley对应的是Spring Boot 2.x版本，而Camden用的是1.x，这俩版本里Actuator（健康检查依赖）的默认路径完全不一样：

• 首先确认客户端项目里已经引入了spring-boot-starter-actuator依赖，Flinchley版本不会像Camden那样默认把这个包含在Eureka客户端依赖里，没加的话肯定会404。
• 然后在客户端的配置文件里显式指定健康检查的路径，因为2.x的Actuator默认前缀是/actuator，不是1.x的根路径：

  eureka:
    instance:
      health-check-url-path: /actuator/health
      status-page-url-path: /actuator/info
  

  把这个加上之后，基本就能解决404的问题了。

二、验证客户端是否真的在执行健康检查上下文 #

1. 看客户端日志最直接 #

给客户端开个debug级别的日志，专门盯Eureka相关的包：

logging:
  level:
    com.netflix.discovery: DEBUG
    org.springframework.cloud.netflix.eureka: DEBUG

启动客户端后，去日志里找有没有类似这样的内容：

Sending health check to Eureka server...
Successfully sent health check status: UP

要是能看到这类日志，说明客户端正定时给Eureka Server发健康检查请求，上下文肯定是在正常执行的。

2. 抓包或者直接调接口验证 #

• 先在本地调用客户端的健康检查接口：http://<客户端IP>:<端口>/actuator/health，如果返回200和{"status":"UP"}，说明客户端自身的健康检查接口是好的。
• 然后可以用抓包工具（比如Wireshark）看客户端和Eureka Server之间的请求，有没有定时发送的PUT请求到Eureka Server的/eureka/apps/<你的应用ID>/<实例ID>/status路径——这是Eureka健康检查的默认请求路径，有这个请求就说明客户端在执行健康检查逻辑。

3. 从Eureka Server端确认 #

打开Eureka Server的控制台，找到你的客户端实例，看它的Health Check URL是不是已经变成/actuator/health了，点击这个链接如果能正常返回（不再404），就说明客户端的健康检查上下文已经生效。另外也可以调用Eureka的API：http://<Eureka Server IP>:<端口>/eureka/apps，返回的JSON里找对应实例的healthCheckUrl字段，看路径对不对，还有status是不是UP（如果实例健康的话）。

三、额外提醒 #

• 一定要保证Eureka Server和客户端的Spring Cloud版本匹配，别混用不同系列的依赖，不然容易出各种奇怪的问题。
• 如果你的客户端有自定义的健康检查逻辑（比如自己写了HealthIndicator），要确认这个逻辑没出错，不然健康检查接口可能返回异常状态，影响Eureka的实例状态判断。

内容的提问来源于stack exchange，提问作者Nap