I created Eureka server and client applications in my local development environment.
My client service instances status is not showing properly even though instances are down.
Below image two services are up and running. Actually, those two services are down more than 30 minutes ago. Any idea to show status as down here?
Related
In the basic Setup with Spring Boot-Spring Cloud Components.
Is there any way the Eureka Service can sync the details of available services registered with itself, with a Physical Load Balancer like 'Stingray Traffic Manager'.
This is a question raised in my project, where there is a issue what we are facing, for service unavailable 503 errors or sometimes client-service not able to de-register itself from Eureka.
One cause which was found is something to understand about eureka eviction policy.
Other thing, which I am raising as a question here to know is it possible to sync the availability of registered services with Physical LB like with 'Stingray' tool.
My question might be wrong, but trying to understand the possibilities to improve Eureka Server and Client- Services Register and De-Register issues.
I have a project which contains 6 graphql subgraphs and one gateway (express server) that federates those and connects to those. I have deployed this project on aws, each of those servers represents an ECS task and a load balancer attached to it. All of the graphql servers are up and running, but gateway is failing because of health checks.
I get the logs that server has started, but after that, load balancer performs health checks and the ecs task fails and starts over.
I don't know how to debug this because the health check configurations (path, status etc.) are correct and calling the health check path on local succeeds.
What am I missing and how can I set everything up? Thank you in advance.
Our deployment is currently running on an ECS cluster with multiple Fargate tasks without any problem. The deployment diagram is given
here. There are four different services (only one of them is shown in the diagram) and each service has 2 containers for now.
One of the services, written in Spring Boot framework, includes both REST and WebSocket (without STOMP). When we deploy this service in Elastic Beanstalk as itself only, we can build both REST and WebSocket connections. For example, when we call ws://api_link/other-path-variables, related WebSocket connection is opened successfully. However, when it is deployed on ECS cluster, we can not build a WebSocket connection through API Gateway(REST) shown in the diagram.
Do we have to create a new API Gateway for WebSocket API? If yes, then we are not able to match route keys such $connect with our current WebSocket API. Since, we have only one connection URL, such ws://api_url/task-id, supporting different connection based on task-id. How can we configure it to just open only a connection through api gw?
We also tried the solution here by creating an extra target group but it did not work. We were not able to make a websocket connection through a browser websocket client using the existing API Gateway.
We have a consul cluster of 3 servers and registering agent services on any of them via Rest Api.
In UI, registrations of a server are visible on other servers as well. For e.g. registration on server A is visible on server B's UI (accessible by http://serverb:8500/).
However when hitting server B via Rest Api, it only shows its own registrations and do not show server A registration.
Server are started as
Server A
consul -server -ui bootstrap-expect=1 -node=ServerA -data-dir=D:\data -bind=11.223.15.78 -client=0.0.0.0 -retry-join=11.223.15.79 -retry-join=11.223.15.80
Server B
consul -server -ui bootstrap-expect=1 -node=ServerB -data-dir=D:\data -bind=11.223.15.79 -client=0.0.0.0 -retry-join=11.223.15.78 -retry-join=11.223.15.80
Server C
consul -server -ui bootstrap-expect=1 -node=ServerC -data-dir=D:\data -bind=11.223.15.80 -client=0.0.0.0 -retry-join=11.223.15.78 -retry-join=11.223.15.79
Is this an issue or am I doing something wrong?
The visibility of services will depend on which API endpoint you're using, and where you're registering your services. Consul intends for services to be registered against a Consul client agent which is running on the same host as the deployed service. The services registered with each agent in the data center are aggregated to form the service catalog (https://www.consul.io/docs/architecture/anti-entropy#catalog).
The /catalog/services endpoint returns an aggregated list of services registered with each agent across the data center. The /agent/services endpoint will only return services registered against the specific local agent with which you are communicating.
If you want clients to be able to register services across any server, you'll want to register them using the /catalog/register endpoint. You can optionally use a tool like Consul External Services Monitor to provide health checking for services, independently from the Consul servers. See https://www.hashicorp.com/blog/consul-and-external-services for more information.
If a service has been registered via the agent api only on one consul node of a cluster, you can still query the service by its service name by means of the catalog api from all server nodes:
/v1/catalog/:servicename
See https://www.consul.io/api-docs/catalog#list-nodes-for-service
Note that you need to deregister a service on the same consul node via the agent api where you have registered it via the agent api in the first place. If you just deregister it from the catalog, it will be back after a few minutes (that is at least my experience)
The Consul documentation recommends to use the agent api for registration, so I would still stick to registering via the agent api, although it makes deregistering a bit tricky.
let's take Eureka.
in a normal scenario, A microservice is registered with the Eureka, and we get its information there.
the microservice has multiple backup servers.
the question is, how these servers will be registered in Eureka.
Will all the Backup servers have different IP or same IP!
how the registration for backup servers happen, and how the backup server is chosen.