search

hashicorp / consul

Consul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.
https://www.consul.io
Other
28.39k stars 4.43k forks source link

Add service status change time field #461

Open mfischer-zd opened 10 years ago

mfischer-zd commented 10 years ago

It would be nice to know when the last state transition for a service occurred by querying the check API, for example:

{
    "service:mysrv": {
        "Node": "srv1",
        "CheckID": "service:mysrv",
        "Name": "Service 'mysrv' check",
        "Status": "passing",
        "LastChangeTime": 123456789,
        "Notes": "",
        "Output": "",
        "ServiceID": "mysrv",
        "ServiceName": "mysrv"
    }
}

UTC ISO8601 timestamp is slightly more readable, but a UNIX timestamp would be fine as well.

mfischer-zd commented 10 years ago

Even better would be a history (maybe the last 10 or so) in an array so we could detect and issue flap alerts.

armon commented 10 years ago

Interesting, we definitely could add this. Time is always a major issue in a distributed system, so the clock would probably track the current leader (caveat emptor), with usual disclaimers about drift blah blah

mfischer-zd commented 10 years ago

The clock of the node on which the service check is run should be definitive, no?

armon commented 10 years ago

That works too, but then it's hard to compare the times to each other, since then you have N different clock values.

mfischer-zd commented 10 years ago

I think it's pretty well understood these days that NTP synchronization is a requirement.

armon commented 10 years ago

I guess is there any reason not to rely on the servers? If NTP is being used, then the times should be sync'd anyways. Doing it server side would allow it to be done in a backwards compatible way (otherwise the client needs to annotate the time, and older clients obviously can't do that).

mfischer-zd commented 10 years ago

It's a good excuse to get people to update their clients :)

pfischermx commented 10 years ago

This would be really nice to have. More than happy to test it out!

sbward commented 9 years ago

+1 to adding full change history to keys/values. Having the ability to "undo" accidental config breakage would be extremely valuable (even if I have to view the history and revert by changing it again instead of a real "undo").

patelpayal commented 9 years ago

what is the timeline for this? This is something useful for our use case and we're looking forward to this...

pfischermx commented 9 years ago

ping. Any idea when this could be added?

armon commented 9 years ago

It's not on our immediate roadmap, so unlikely to make it into 0.6. Most likely, many of these API changing fields will come with the v2 API

slackpad commented 7 years ago

This is still not on our roadmap so closing this for now.

simonvanderveldt commented 7 years ago

@slackpad why close the issue then? Keep it open until it can/will be added to the roadmap or until someone creates a PR

slackpad commented 7 years ago

@simonvanderveldt suppose that since this is additive this may be fairly small to add (even PR-friendly) so I'll open it back up. This could also be part of #2890.

r3lik commented 5 years ago

+1 for this. Would be great to have this.

ShimmerGlass commented 5 years ago

for ref: https://github.com/hashicorp/consul/pull/4744

rtudo commented 5 years ago

+1 to have this. A Log(may be in db) will be a great thing for consul agent health check(same way icinga/nagios does it). It could easily extended to build a good monitoring system. And with the help of handlers, we are anyways having the alerting scope as well. History of state changes of services is really good thing to have.

rusia-rak commented 5 years ago

to have history for service state changes will be a killer feature to have.