Eureka Renews threshold & Renews (last min)

Question

I have one Eureka Server A and two client instances of B(Client3) and C(Client4)

I got logs from Eureka Server, which are as follows :

2018-01-25 12:56:27.828  INFO 7145 --- [nio-8765-exec-2] c.n.e.registry.AbstractInstanceRegistry  : Registered instance CLIENT3/client3:bb488bb73fd313321e393915f746bfe5 with status UP (replication=false)
2018-01-25 12:56:28.417  INFO 7145 --- [nio-8765-exec-3] c.n.e.registry.AbstractInstanceRegistry  : Registered instance CLIENT3/client3:bb488bb73fd313321e393915f746bfe5 with status UP (replication=true)
2018-01-25 12:56:33.028  INFO 7145 --- [nio-8765-exec-3] c.n.e.registry.AbstractInstanceRegistry  : Registered instance CLIENT4/client4:9fcbf4ed26162ee12c4c4b85774c39b1 with status UP (replication=false)
2018-01-25 12:56:33.542  INFO 7145 --- [nio-8765-exec-8] c.n.e.registry.AbstractInstanceRegistry  : Registered instance CLIENT4/client4:9fcbf4ed26162ee12c4c4b85774c39b1 with status UP (replication=true)

a) What do they mean? I mean each client appeared twice

b) Renews threshold : 5 , Renews (last min) : 8, why is renew last min is 8 , it should be 4? Since only two client, 2 beats per client per minute

c) When I start 3rd Service D(CLient5), the renew threshold is 6 but not 7, why is that?

d)How does Eureka Peers pass info delta info to each other and when? For Example currently there are two eureka server(peers) and two client(1 instance each). Now when a new client registers, will it send beat to both peers or just one? In one, how does the other peer know?

Skolnik

Answer 1

a) This means that Eureka is replicating heartbeats to itself. This is most probably due to misconfiguration. If you take a look at Eureka's dashboard you probably have your host on the list of unavailable-replicas. To fix this, Eureka instance name needs to be the same as hostname used in defaultZone. So, for your standalone Eureka server the config should look like

eureka:
  client:
    registerWithEureka: false
    fetchRegistry: false
    serviceUrl:
      defaultZone: http://localhost:8080/eureka/
  instance:
    hostname: localhost

It is crucial for eureka.instance.hostname to match with the hostname in eureka.client.serviceUrl.defaultZone. Once you configure this, the unavailable-replicas should disappear.

b) Once you fix a) this problem should be fixed and you should see 4 renewals.

c) Going to quote the explanation here

The math works like this: If there are two clients registered to a Eureka instance, each one sending a heartbeat every 30s, the instance should receive 4 heartbeats in a minute. Spring adds a lower minimum of 1 to that (configurable by eureka.instance.registry.expectedNumberOfRenewsPerMin), so the instance expects to receive 5 heartbeats every minute. This is then multiplied by 0.85 (configurable by eureka.server.renewalPercentThreshold) and rounded to the next integer, which brings us back to 5 again. If anytime there are less than 5 heartbeats received by Eureka in 15min (configurable by eureka.server.renewalThresholdUpdateIntervalMs), it goes into self-preservation mode and stops expiring already registered instances.

So, in your case for two instances: (2 * 2 + 1) * 0.85 = 4.25, rounded to 5. For three instances (2 * 3 + 1) * 0.85 = 5.95 rounded to 6.

d) Eureka clients send heartbeats to only one server instance. That instance pass those heartbeats to the other ones keeping them updated. If you check Eureka server logs, you can find logs like this

InstanceRegistry: renew SERVICEA serverId localhost:serviceA:12345, isReplication {}true

If isReplication is true, this means that the renewal is sent from the peer server node. If it is false, that means the instance itself received a renewal.

Tridentum