Eureka心跳健康检查机制和Spring boot admin 节点状态一直为DOWN的排查（忽略某一个节点的健康检查）

https://www.jdon.com/springcloud/eureka-health-monitoring.html

运行阶段执行健康检查的目的是为了从Eureka服务器注册表中识别并删除不可访问的微服务，Eureka 服务器并不是向客户端发送心跳请求，而是反过来，Eureka 客户端将心跳发送到Eureka服务器，让服务器了解其状态。

这些心跳机制就需要在微服务嵌入一个客户端，用来发送心跳，但是客户端本身必须确定其健康状态，而且Eureka服务器必须为客户端公开一些REST操作以让其发布心跳。

Eureka服务器向客户端公开下面资源以让其发送心跳：

PUT /eureka/apps/{app id}/{instance id}?status={status}

{instance id}采用  hostname:app id:port，其中app id代表标识唯一的Eureka客户端实例，Eureka服务器会识别一些状态数值：UP; DOWN; STARTING; OUT_OF_SERVICE; UNKNOWN.

客户端发送心跳时的URL如下：

PUT /eureka/apps/ORDER-SERVICE/localhost:order-service:8886?status=UP

Eureka服务器收到心跳请求后，会续订该实例的租约。如果是第一个心跳，则Eureka服务器以404响应，之后客户端必须首先发送注册请求。

此外， Eureka服务器公开以下操作以允许健康状态的修改和删除：

PUT /eureka/apps/{app id}/{instance id}/status?value={status}

DELETE /eureka/apps/{app id}/{instance id}/status

修改操作（即PUT上面的操作）是用于手动获取健康的实例OUT_OF_SERVICE时操作，或者使用Asgard等管理工具 （暂时禁止某些实例的流量）时操作。

这种修改操作对于“红/黑”部署非常有用，在这种情况下，你可以在一段时间内运行较旧版本的微服务（如果新版本不稳定，则可以轻松回滚到旧版本）。完成新版本的部署并且新版本开始为请求提供服务后，可以让旧版本OUT_OF_SERVICE（但不会让他们停止）暂停提供请求服务。即

PUT /eureka/apps/ORDER-SERVICE/localhost:order-service:8886/statusvalue=OUT_OF_SERVICE

 

上面修改的状态也可以被丢弃，我们可以指示让Eureka服务器开始遵守实例本身发布的状态，如下所示：

DELETE /eureka/apps/ORDER-SERVICE/localhost:order-service:8886/status

当您发现微服务的新版本不稳定并且您希望获得旧版本（即已经被打上OUT_OF_SERVICE标记的版本）以开始提供请求时，上述办法非常有用。

Eureka的健康检查

客户端需要在工程中添加组件依赖:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
    <version>1.5..RELEASE</version>
</dependency>

然后在配置文件里面加上健康状态检查配置:

eureka:
  client:
    healthcheck:
      enabled: true

这时，启动自己的服务，通过http://localhost:port/health访问就可以得到服务的健康状态信息：

{"description":"Composite Discovery Client","status":"UP"}

当这个配置设置为false时，服务将不会把健康状态传递给Eureka，那么Eureka就不会再更新Status信息，但是此时仍能够通过上面的地址获取这个真实的状态信息。

应用状态的取值：UP，DOWN，OUT_OF_SERVICE，UNKNOWN等；只有标记为UP的微服务会被请求；

通过在application.yml中配置eureka.client.healthcheck.enabled = true，应用程序会将自己Spring Boot Actuator的/heath端点的健康状态传播到Eureka Server

这里的/health检查包括下面这些，其中还包括redis、mysql、hystrix等监控的检查：

如健康状况：

• DiskSpaceHealthIndicator
• RefreshScopeHealthIndicator
• HystrixHealthIndicator

它将这些状态会映射到Eureka支持的状态之一，之后被映射后的状态将通过心跳传播到Eureka服务器。

列如一个应用实例在监控检查的时候发现当前的磁盘空间不够用了，就会通过心跳传递给Eureka服务器，这里时候你在Eureka服务器查询到当前应用实例的状态就是down状态

其他应用通过Eureka服务器获得当前应用实例的状态就是down，就无法访问改应用实例，应用实例只有up状态才能访问

Erueka状态变更说明

http://www.seotest.cn/jishu/41663.html

STARTING ： 表示服务正在启动中

DOWN： 表示服务已经宕机，无法继续提供服务

UP ： 服务正常运行

OUT_OF_SERVICE : 不再提供服务，其他的Eureka Client将调用不到该服务，一般有人为的调用接口设置的，如：强制下线。

UNKNOWN： 未知状态

容器启动

在容器刚刚启动，实例化instance信息的时候，默认状态为STARTING

在Eureka Client端，有一个40秒执行一次的定时任务，会定时的去扫描自身的信息，查看自身信息是否发生改变，

其中就有一个对状态的检测，这个时候，如果设置了健康检查器，那么会以健康检查的结果为准，判断当前实例的

状态，然后会通过心跳实例的最新状态重新注册到Eureka上面去。

Eureka客户端健康端点

Eureka客户端在向服务器注册时会在其POST的内容中加入healthCheckUrl ，这个healthCheckUrl的值是由以下实例属性计算得出：
eureka.instance.health-check-url
eureka.instance.health-check-url-path

.health-check-url-path的默认值是 /health，这是Springboot默认专门用于检查健康的actuator端点，除非.heath-check-url被专门配置了。

如果实现自定义健康状况端点或更改默认健康检查路径，则应配置这些属性：

endpoints.health.path=/new-heath
# either relative path
eureka.instance.health-check-url-path=${endpoints.health.path}
# or absolute path
eureka.instance.health-check-url=http://${eureka.hostname}:${server.port}/${endpoints.health.path}

如果你引入一个 management.context-path  

management.context-path=/admin
# either relative path
eureka.instance.health-check-url-path=${management.context-path}/health
# or absolute path
eureka.instance.health-check-url=http://${eureka.hostname}:${server.port}/${management.context-path}/health

健康状况的试验

Eureka服务器并不关心客户端的状态 - 它只记录客户端状态，当有人查询其注册表时，它也会发布客户的健康状况。即

GET /eureka/apps/ORDER-SERVICE

<application>
   <name>DISCOVERY-EUREKA-CLIENT</name>
   <instance>
      <instanceId>localhost:discovery-eureka-client:</instanceId
      <ipAddr>192.168.1.6</ipAddr>
      <port></port>
      <status>UP</status>
      <overriddenstatus>UP</overriddenstatus>
      <healthCheckUrl>http://localhost:8886/health</healthCheckUrl>
      ...
      ...
   </instance>
</application>

这个响应有三个与健康有关的重要信息： status 、overridenstatus和healthCheckUrl

• status 是Eureka实例本身发布的健康状况。
• overriddenstatus 是手动或通过工具强制执行的健康状态。比如PUT /eureka/apps/{app id}/instance id}/status?value={status}操作用于修改发布的状态，那么status和overriddenstatus都将变更为新的状态。
• healthCheckUrl 是客户端公开GET其健康状态的端点。

其他工具则可以利用这些健康信息：

• 客户端负载平衡器（如Ribbon）可以做出负载平衡决策 : Ribbon 读取  status  属性并仅使用具有UP  负载平衡状态的实例  。但是，Ribbon不会调用  healthCheckUrl， 而是依赖于注册表中可用的、已发布实例状态。如一个应用实例在Eureka在服务器上面的状态是down，Ribbon从Eureka服务器上面读取实例的状态是down，那么Ribbon就不会调用down状态的应用实例，但是你直接通过postman请求改应用实例是可以的，但是通过Ribbon是无法远程访问改应用实例的

健康状况的准确性

由于下面列出的原因，Eureka服务器注册表健康状况的并不总是准确的。

• CAP中的AP  - 由于Eureka在CAP定理方面定位于高度可用的系统，因此在网络分区期间，集群Eureka服务器之间的信息可能不一致。
• 服务器响应缓存  - Eureka服务器维护一个响应缓存，默认情况下每30秒更新一次。因此，实际上在  GET /eureka/apps/{app id}/ 响应中出现 UP 的实例可能已经DOWN 了 。
• 定期调度心跳  - 由于客户端默认情况下每30秒发送一次心跳，因此服务器注册表中实例的运行状况可能不准确。
• 自我保护 - 当Eureka服务器没有收到超过某个阈值的心跳时，它会停止失效注册表中的客户端，从而会使注册表不准确。

因此，客户端应遵循适当的故障转移机制来补充这种不准确性。

Spring boot admin 节点状态一直为DOWN的排查（忽略某一个节点的健康检查）

某个应用实例运行成功后服务节点一直显示为DOWN，访问 http://127.0.0.1:8081/actuator/health健康检查端点返回值如下

可以看出redis 宕机了，但其实我项目本身没有使用redis。，我们可以在应该实例的健康检查中忽略redis的检查，这里在eureka服务器上面改应用实例的状态就不是down状态了。

在显示DOWN的客户端添加如下配置（忽略redis的健康检查）：

spring:
  profiles:
    active: dev
management:
  health:
    redis:
      enabled: false
  endpoint:
    health:
      show-details: always
  endpoints:
    web:
      exposure:
        include: "*"
server:
  port: 

在spring boot admin监控中，一个应用下面存在3个应用实例，只要其中的一个应用实例的状态为down，那么该应用的状态就是down只要其中一个监控内容为DOWN,则该节点的总体状态就为DOWN