How to watch a specific service

[half-dead]

We want to watch a specific service, and get a notification once there is any change on this service(e.g. a new client that provides this service are up/down, or health check failing), but for anything else, we don't want to know.

I've tried the "/v1/health/service/service1?index=100" endpoint, but this will be triggered to return in so many cases, like call "/v1/agent/service/deregister/node1-service2" on the same node, or even an irrelevant node join this cluster.

But the CLI "consul watch -type service -service service1 handler.sh" works just fine, how do we do the same thing using only HTTP endpoints?

-- update
I found the code for the CLI "consul watch" in watch/plan.go.Run(), and it proves my thought.

But in our use case, the size of consul cluster is over 1K, therefore, the X-Consul-Index will be changing all the time, so compare the results using DeepEqual maybe not an option; and the size of JSON response could be quite large, so it could also cause a network traffic problem, since all the requests are forwarded to consul server nodes. Any suggestions?

[armon]

@half-dead it's effectively a cache invalidation problem. The granularity of our invalidation is too large and is something that must be handled inside the core. You need something like DeepEqual on the client to de duplicate. It's a very difficult problem but one we are working on.

[half-dead]

@armon thanks for answering, will consul support small-granularity invalidation in future version?

[armon]

@half-dead Yep! We've been improving steadily ever since Consul 0.1. It used to be all blocking queries triggered with any write. The contract between Consul and the client is purposely designed so that we can make improvements server side without the client re-writing. The signal just gets less noisy over time.

[half-dead]

@armon Have you ever benchmarked the '/v1/agent/check/pass/xx' endpoint? It seems that it will trigger all server node's disk write, right?

[armon]

@half-dead In the Consul architecture, checks are edge triggered, so we only do RPC traffic from clients to servers if something changes. If a check in in a steady state, then we don't need to update the servers. So typically even with a large volume of checks, there is only a small amount of updates taking place on the servers. For example the '/v1/agent/check/pass/ endpoint is only doing a request to the local agent to prevent the TTL from expiring, so the load on the servers is not affected until the TTL fails.