allow specifying check id for service

[blalor]

I'd like to be able to specify the id for a check associated with a service. The notes field is useful for human-readable text about the check, but it would be useful to have a more structured id to use for alerting. For example, I have two checks for mysql: one for aliveness and another for replication on slaves. The generated id for the replication check is service:mysql:2 but I'd like to have service:mysql:replication.

Check IDs for a service are of the form service:<service_id>[:<index>] and the id property is ignored when reading the service definition from a file. By specifying the check id it would be possible to have service:<service_id>:<check_id>, with a fallback to the other format.

[blalor]

It looks like this can be accomplished by providing the checks separately, giving them their own id, and providing service_id.

[pepov]

👍 for supporting the id field in service check configs

[armon]

@blalor So I am a bit confused, I think this is already possible right?

[blalor]

It's possible when defining a standalone check. It is not possible to define the check id for a check embedded in a service definition.

[armon]

Ohh I see. Okay, tagging as enhancement.

[pepov]

Id and name to be precise. Mrantime a pointer to this in the documentation would be great.

[cruatta]

👍 This would be incredibly useful.

[cruatta]

I was looking into this and the issue is the way ServiceDefinition is defined.

type ServiceDefinition struct {
    ID      string
    Name    string
    Tags    []string
    Address string
    Port    int
    Check   CheckType
    Checks  CheckTypes
}

type CheckType struct {
    Script   string
    HTTP     string
    Interval time.Duration

    Timeout time.Duration
    TTL     time.Duration

    Notes string
}

ServiceDefinition takes a slice of CheckTypes rather than full blown HealthDefinitions so you don't get fields like ID and Name. You could add ID and/or Name to CheckType and I think that would solve this but then you might as well just have a slice of HealthDefinitions inside of ServiceDefinition. The way I am currently avoiding this problem is just defining a Service in one file and then in a separate file defining a list of checks that are all associated with that one service which makes config management easy. It's not as elegant as what @blalor suggested but it works.

[aconrad]

Same here, I have two health checks for a given service, but one of the Consul API consumers is only interested in one of the two, and there is not easy way to know which is which -- currently it's trying to parse the output of the first, and if parsing fails, it tries the output of the other one.

It would be nice to have something more structured that would be exposed via the API (for instance /v1/health/checks/<service>).

[ryanuber]

@aconrad the endpoint /v1/health/checks/<service> does currently exist. Does it not function how you would expect?

I looked at this a while back and found exactly the same as @cruatta did - the changes actually go pretty deep to support passing in the CheckID, which is unfortunate. I would probably just use a file with separate definitions like some have hinted at above, all in a single file for each service, like this:

{
    "service": {
        "name": "myservice"
    },
    "checks": [
        {
            "id": "check1",
            "service_id": "myservice",
            "ttl": "30s"
        },
        {
            "id": "check2",
            "service_id": "myservice",
            "ttl": "30s"
        }
    ]
}

This is going to be a somewhat low-priority enhancement since we have a reasonable work-around, but we definitely want to get it fixed for the embedded definitions.

[aconrad]

@ryanuber the endpoint works (and I'm using it) but I have no way to know which check item in the list of checks is the one I care about since I can't identify them by name -- so as I explained, I try to detect the check I care about by parsing its output.

[ryanuber]

@aconrad using a configuration like the sample above, you should be able to pass in the check ID to your liking. Then you can refer to the health check much more easily from your own app my just checking the ID field in responses. Does that make sense, or am I missing something?

[aconrad]

@ryanuber ah got it. The person that manages our cluster applied the work-around, works great. Thanks!

[n2taylor]

Encountering this issue as well, and the workaround doesn't work for me. No matter how I structure the config file, I always get the generated service name and id when I access health check status via v1/agent/checks or the v1/health/checks endpoints

[ryanuber]

@n2taylor can you paste your service + check config? This should work perfectly with the example config above. You can verify by saving the example config as config.json and running:

$ consul agent -dev -config=config.json
$ curl localhost:8500/v1/health/checks/myservice?pretty

[n2taylor]

Never mind, I figured it out... I was missing the service_id attribute on the check itself. Thanks!

[slackpad]

This was fixed in #3051 while closing out #3047.