Watch all service changes within a given agent?

453 views
Skip to first unread message

Chris Berry

unread,
Jan 7, 2016, 5:17:58 PM1/7/16
to Consul

Hi,


I am wondering if I’m just missing something, because I feel like this should be possible without polling.

I need a “watch" for all "service changes" within a given consul Agent (service create, delete, etc.) 

But it does not look like this is currently possible??


What I don’t want is 

1] for this to have to talk back to the mother ship every time —  since I’m already on the same Node as the Agent, this should stay "on box" (this DOES look possible with /v1/agent/services ??)

2] to have to poll for this information. I.e. I really want a watch. (which rules out /v1/event/list I think)


All I want to know is if anything has changed, so that I can react to it, and can reload some config in some other daemons on the Node. 

I really don’t even need the overhead of consul-template. 


What am I missing?

Thanks,

— Chris 


James Phillips

unread,
Jan 8, 2016, 7:12:32 PM1/8/16
to consu...@googlegroups.com
Hi Chris,

Unfortunately, I don't think there's anything currently that will meet all your requirements. The agent endpoints don't support blocking queries and if do a blocking query against the catalog API that's going to have to go back to the mother ship. Polling the /v1/agent/services API is super cheap since it doesn't hit the servers and just dumps the local state, so I wouldn't worry about the performance impact of that, though I do understand it's not ideal to have to implement polling logic.

Right now if you did a blocking query against the catalog API it would wake up for any change in the catalog, not just for your node. We hope to make that more fine-grained in the next major release of Consul, so that would make that strategy a lot better and less noisy.

-- James

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/consul/issues
IRC: #consul on Freenode
---
You received this message because you are subscribed to the Google Groups "Consul" group.
To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/053bef59-5e7b-4aa7-8d06-780df52f6a7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Chris Berry

unread,
Jan 9, 2016, 10:26:33 AM1/9/16
to consu...@googlegroups.com
James,
Thanks much for responding!
I do think this would be an excellent addition to Consul.

What I would really love to see is a way to actually query the local consul-agent for information on the “local service registry” and any events it sees — over HTTP (localhost). But I know that is asking for a lot, and I’ll take what I can get… :~). 

I think for many use cases this will make the use of “local consul-templates" considerably more performant.

Let me explain my use case, to maybe put some icing on this…. We run dd_agent on every host. This is a "metrics collector" that then forwards the metrics off to DataDog and soon, for us, onto Kafka . It needs to be aware of all the services on the host, when they come and go, and what sort of apps they are (think “app family”; elasicsearch, cassandra, codahale java, …). This allows it to config itself with all the appropriate “checks” against the appropriate services. I just need a “local service registry” file that lists out all the _current_ services info for that node, that I can watch on the file system and react to. 

If I was to do this with consul-template, it would result in a huge load against the remote consul service. All of which is quite silly, since all that information came out of the local consul-agent in the first place. So I’d be asking the remote consul to tell me everything about myself, when I was the one who told it in the first place, and when really I should just be self-aware.

We have some other similar use cases WRT log forwarders, etc.

In the end, the Docker event stream is the actual source of truth, and the closer we sit to that, the better.
In the interim we plan to add another Backend to Registrator that does this for us.

Thanks again,
— Chris 


You received this message because you are subscribed to a topic in the Google Groups "Consul" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/consul-tool/HwlfpVw52_I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to consul-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/CAGoWc06hZSS9m4Ln_O01zFs8fQX0%3Den9JmQqansNvOT94KxWHg%40mail.gmail.com.

James Phillips

unread,
Jan 11, 2016, 3:23:07 PM1/11/16
to consu...@googlegroups.com
Hi Chris,

That makes sense - I opened an issue so we can take a deeper look - https://github.com/hashicorp/consul/issues/1586.

-- James

Reply all
Reply to author
Forward
0 new messages