Consul Health Checks and Service Deregistration

1,415 views
Skip to first unread message

Mark Selby

unread,
Nov 16, 2016, 2:33:43 PM11/16/16
to Consul
Below is a contrived example of one of the checks that we run for a service.

As we know when the health check fails we can query this status via the API

Right now we are telling out developers in order to use Consul for services you need to perform two steps
  1. lookup the service via /v1/catalog/service
  2. check its health via /v1/health/service
We use tags pretty heavily so we need to use the /v1/catalog/service API in order to filter by the tag set we need.

What we really want is for services to deregister themselves after a certain number of health checks fail and then re-enable when they come back. We have played with "deregister_critical_service_after": "1m" but that leads to longish de-registration time and no automatic re-registration.

My question is really this. Is the two process the "accepted" practice in terms of connecting to healthy services or is there some other paradigm that can be followed to get the behavior we desire.

Thansk!

{
  "service": {
    "name": "influxdb",
    "tags": ["generic","prod","generic-prod"],
    "address": "10.123.14.131",
    "port": 8086,
    "enableTagOverride": false,
    "checks": [
      {
        "tcp": "localhost:8086",
        "interval": "10s",
        "timeout": "1s",        
      }
    ]
  }
}

JD Harrington

unread,
Nov 16, 2016, 2:59:59 PM11/16/16
to consu...@googlegroups.com
Hi Mark :)

You can query the health endpoint with a “tag” parameter and also a “passing” parameter.


So, you’d probably want to query something like:
/v1/health/service/influxdb?tag=generic-prod&passing

I don’t think, however, that you can currently filter on multiple tags this way, so maybe that’s why it’s necessary for you to use the catalog API.

You could look at prepared queries as an alternative:

Hope that helps!

- JD

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/consul-tool/e9e4986c-ddae-4330-b791-faa90db89be7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

JD Harrington

unread,
Nov 16, 2016, 3:07:52 PM11/16/16
to consu...@googlegroups.com
Also, the /v1/health/service/<service> endpoint returns the tags as well, so you should be able to call it with ?passing and then filter by tag set while saving yourself the call to the Catalog API.

Mark Selby

unread,
Nov 16, 2016, 7:08:07 PM11/16/16
to Consul
Your suggestion will work for me. you can not query by multiple tags in any aspect without prepared queries so this is not a limitation of the health API.

Thanks very much !
To unsubscribe from this group and stop receiving emails from it, send an email to consul-tool...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages