When I run Eureka on port 8761, everything works great. The config server can register to Eureka without problem. When I change eureka port to 7001, however, things stop working and I can't seem to figure out how to fix them.
The issue seems to revolve around Eureka not being able to find a peer node running at: http://localhost:8761/eureka. The exception is:
2015-07-05 08:00:47.301 ERROR 4140 --- [egister-process]
c.netflix.eureka.cluster.PeerEurekaNode : PeerEurekaNode:
http://localhost:8761/eureka/apps/: CONFIGSERVER/localhost:Register
Indeed when Eureka starts, it says: Adding replica node: http://localhost:8761/eureka/. It seems thus that somewhere the a replica node is assumed to be running at 8761.
Is there a way to disable Eureka looking for replica nodes? Or how do I control if and when and where replica should happen? I looked at the EurekaServerConfig class (http://netflix.github.io/eureka/javadoc/eureka-core/index.html) but I could not find anything that goes in this direction.
This is with Spring Cloud 1.0.2.RELEASE.
You have to configure eureka.client.serviceUrl.defaultZone property in application.yml file.
Related
There are two microservices (microservice-A & microservice-B), written in Spring boot, are talking to each other through the Feign Client and the services are registered in K8S Native service registry
Whenever a fresh deployment of a microservice-A is happening, the microservice-B that is already running in kubertnetes fails to make HTTP call to the freshly deployed service-A and below is the exception
feign.RetryableException: No route to host (Host unreachable) executing GET http://microserice-a/api/v1/myresources
This issue is getting resolved immediately after restarting the microservice-B.
When we googled for solutions, we got to see this link https://github.com/spring-cloud/spring-cloud-netflix/issues/769 and an user had given the below comment there
I suspect the root cause is that FeignClient keeps an old list of service providers and the Ribbon cannot move correctly to the next node if one node has been destroyed
Not sure if that is correct root cause. Please comment If anyone has faced similar issue and solved it?
(It is basically two Eureka server and three Eureka client microservices)
I want to remove the following message:
EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY'RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
error image
Eureka Server1:
spring.application.name=ms-service-discovery-1
server.port=8761
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false
eureka.server.enableSelfPreservation= true
eureka.instance.leaseRenewalIntervalInSeconds=1
eviction-interval-timer-in-ms: 1000
eureka.server.wait-time-in-ms-when-sync-empty: 1000
eureka.server.responseCacheUpdateIntervalMs: 1000
Eureka Server2:
spring.application.name=ms-service-discovery-2
server.port=8761
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false
eureka.server.enableSelfPreservation= true
eureka.instance.leaseRenewalIntervalInSeconds=1
eviction-interval-timer-in-ms: 1000
eureka.server.wait-time-in-ms-when-sync-empty: 1000
It's due to Eureka's self-preservation mode. Eureka servers will stop the eviction of all instances if the number of heartbeats renewals is below the expected threshold. The warning in your Eureka servers shows this situation happened.
Please try to adjust the below property. 85% is the default value. First, just try to lower the below property like 0.50
eureka.renewalPercentThreshold=0.85
Alternatively, you can disable self-preservation mode with the below property.
eureka.enableSelfPreservation=false
Note
Basically, all Eureka client unregister itself when it shuts down. If it unregisters itself successfully, the above problem will not happen.
Unfortunately, sometimes the Spring Cloud based Eureka client doesn't unregister itself when it shuts down and the symptom is different based on the Spring Cloud version. Dalston and Edgware release unregister itself well in most cases. But Finchley releases seem not to unregister itself now.
Also, you start to run MANY instances in your Eureka environment, the above message will disappear because just one or two instances shutdown will not reach the threshold.
You can find more information about self-preservation mode here
I have a development environment in windows where I can access the spring build in both IP Address and Hostname(PC-Name) for my Eureka Config Server / Client. When I move it to the RedHat environment it does not recognize the URL if it is a hostname.
My main goal is to change the eureka client status page to point to the hysterix monitor for the eureka client's hysterix stream. The value of ${spring.cloud.client.hostname} resolves to the hostname. I was wondering what is the way to make it the current IP of the eureka client?
To be exact here is an example of what I want am trying to do.
eureka:
instance:
preferIPAddress: true
statusPageUrlPath: http://${spring.cloud.client.hostname}:${eureka.cloud.config.port}/hystrix/monitor?stream=http%3A%2F%2F${spring.cloud.client.hostname}%3A${server.port}%2Factuator%2Fhystrix.stream
It just so happen that the client and the server are both in the same machine so I am contented in using the client hostname for both the Eureka Config Server path and the Eureka Client hystrix stream.
Note that I already set the preferIPAddress to true but the generated hostname is still the value of "/etc/hostname". I saw some solution that explicitly specifies the IP Address in the Eureka Client Instance. But I prefer to make it dynamic so that the same code can run smoothly on either Development and Deploy environment.
What can I do so that the hostname can also be recognized the same as the ip address?
The answer has dawn upon me just now. I just changed the following to this.
${spring.cloud.client.hostname}
↓↓↓↓↓↓↓↓↓↓↓↓
${spring.cloud.client.ip-address}
I was thrown to a wrong conclusion because other sites would tell me to use this configuration ${spring.cloud.client.ipAddress} which does not work.
Probably there was a change in Finchley / Spring boot 2.0 version. If anyone can give me a link to a documentation or discussion describing the configuration change, it would be helpful.
I've encountered an issue with #RefreshScope and it's behaviour. Two main queries:
When the refresh endpoint is invoked, the service effectively restarts and unregisters, then re-registers with Eureka. I thought refreshing the scope would in the main be non-service affecting?
My service starts on a random port, i.e. I've set server.port to be 0 in my properties. The restart mentioned above changes initial value assigned to the server port, and changes it to be 0 for the purpose of registering with Eureka. This means the service is effectively uncontactable to any Ribbon/eureka aware load balancer.
See my sample project here:
https://github.com/KramKroc/refreshscope
Thanks to #DaveSyer I was able to get to the bottom of this issue. In my bootstrap.yml in sample-service (see https://github.com/KramKroc/refreshscope) I had the following line:
eureka:
instance:
nonSecurePort: ${server.port:8082}
This was incorrect as it caused the service to re-register with eureka on the server.port (which was set to zero) or 8082 if not defined. Removing the nonSecurePort entry allowed the service to be refreshed and still be registered with the correct (random) port in Eureka.
I’m having a bit of trouble getting Turbine to work in Spring Cloud. In a nutshell, I can’t determine how to configure it to aggregate circuits from more than one application at a time.
I have 6 separate services, a eureka server, and a turbine server running in standalone mode. I can see from my Eureka server that all of the services are registered, including turbine. My turbine server is up and running, and I can see its /hystrix page without issue. But when I try to use it to examine turbine.stream, I only see the FIRST server that is listed in turbine.appConfig, the rest are ignored.
This is my Turbine server’s application.yml, or at least the relevant parts:
---
eureka:
client:
serviceUrl:
defaultZone: http://localhost:8010/eureka/
server:
port: 8030
info:
component: Turbine
turbine:
clusterNameExpression: new String(“default”)
appConfig: sentence,subject,verb,article,adjective,noun
management:
port: 8990
When I run this and access the hystrix dashboard on my turbine instance, asking for the turbine.stream, the ONLY circuit breakers listed in the output are for the first service listed in appConfig, the “sentence” service in this case. Curiously, if I re-arrange the order of these services and put another one first (like “noun”), I see only the circuits for THAT service. Only the first service in the list is displayed.
I’ll admit to being a little confused on some of the terminology, like streams, clusters, etc., so I could be missing some basic concept here, but my understanding is that Turbine could digest streams from more than one service and aggregate them in a single display. Suggestions would be appreciated.
I don't have enough reputation to comment, so I have to write this in an answer :)
I had the exactly same problem:
There are two services "test-service" and "other-service", each with it's own working hystrix-stream
and there is one Turbine-Application, which is configured like this:
turbine:
clusterNameExpression: new String("default")
appConfig: test-service,other-service
All of my services are running on my local machine.
Result is: My Hystrix-Dashboard just shows the metrics from "test-service".
Reason:
It seems to be, that a Turbine-Client which is configured the described way doesn't handle multiple services when they are running at the same host.
This is explained here:
https://github.com/Netflix/Hystrix/issues/117#issuecomment-14262713
Turbine maintains state of all these instances in order to maintain persistent connections to them and it does rely on the "hostname" and if the host name is the same then it won't instantiate a new connection to that same server (on a different port).
So the main point is, that all of your services must be registered with different hostnames. How you could do this on your local machine is described below.
UPDATE 2015-06-12/2016-01-23: Workaround for local testing
Change your hostfile:
# ...
127.0.0.1 localhost
127.0.0.1 localdomain1
127.0.0.1 localdomain2
# ...
127.0.0.1 localdomainx
And then set the hostname for your clients each to a different domain-entry like this:
application.yml:
eureka:
instance:
hostname: localdomainx