Registering external services and checks

[Daniel Kennedy]

I'm wanting to set up external checks for nodes without them having a local agent installed. I've used the catalog/register endpoint to create the node, service and check but how do I set the status of this check? It looks like the only way I can set a TTL for it is to use agent/check/register but that will register it with the local agent.

An outline of the process might help here. I'm wanting for nodes to register, via curl, with my service (and http endpoint running on each of 3 consul cluster servers), which then delegates the calls to consul to register the node, service and check with the catalog. I'd ideally then like to register a check for each of those nodes within that service AND perform the external checking and updating of the check status on their behalf.

Does that make sense? Am I trying to do something that's not supported? Am I using TTL checks in the wrong way?

Any help/guidance much appreciated.

Thanks

[Armon Dadgar]

Hey Daniel.

I think you are doing it correctly. In the Consul model, the health checks are performed at the

edges (agents) not by the central servers. The API’s are used to push state updates to the

servers. 

Because of this, there is no notion of TTLs or scripts etc in the low level catalog API’s,

because those are concepts that only make sense on agents.

It sounds like all of this is part of your architecture anyways. To update the health check,

you just call the register endpoint again with the updated status. The endpoint does an

“upsert” kind of operation, so you just invoke it again. This is what the agents are doing

internally as well.

Best Regards,

Armon Dadgar

--
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.
For more options, visit https://groups.google.com/d/optout.

[Daniel Kennedy]

Armon,

Thanks for your response. I can't believe I overlooked such a simple solution as to run the registration again with the new status/output. I appreciate this is not really how consul intended for checks to be performed so I'm very glad I've managed to find something that works (with your help).

Thanks again. Much appreciated.

Dan

On Thursday, 29 January 2015 18:27:08 UTC, Armon Dadgar wrote:

Hey Daniel.

I think you are doing it correctly. In the Consul model, the health checks are performed at the

edges (agents) not by the central servers. The API’s are used to push state updates to the

servers. 

Because of this, there is no notion of TTLs or scripts etc in the low level catalog API’s,

because those are concepts that only make sense on agents.

It sounds like all of this is part of your architecture anyways. To update the health check,

you just call the register endpoint again with the updated status. The endpoint does an

“upsert” kind of operation, so you just invoke it again. This is what the agents are doing

internally as well.

Best Regards,

Armon Dadgar

[Volker Krebs]

Hello,

this thread helped me a lot understanding external services. Thanks :)

But one point remains open.

Am Donnerstag, 29. Januar 2015 19:27:08 UTC+1 schrieb Armon Dadgar:

Because of this, there is no notion of TTLs or scripts etc in the low level catalog API’s,

because those are concepts that only make sense on agents.

I've made a script that checks the external service and updates the status of it every few seconds.

But if this script fails, the status will not be changed and remains "passing".

So I think a ttl would be nice, so the status can be set to "unkown" if it wasn't refreshed during ttl.

Thanks

Volker

[Armon Dadgar]

Hey Volker,

That is an option that we could definitely support in the future. However our general design

principal is to push as much work and compute to the edges as possible to allow the servers

to scale to huge clusters. Another way to tackle this would be to run those external checks in

multiple places, but using “consul lock” to ensure only one instance is active at a time.

Best Regards,

Armon Dadgar

--
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/f8074dcb-647c-49cb-a765-207d9876b167%40googlegroups.com.