Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return uptime or something similar for /health endpoint #1450

Closed
benraskin92 opened this issue Apr 2, 2019 · 3 comments · Fixed by #1465 or code98/jaeger#1
Closed

Return uptime or something similar for /health endpoint #1450

benraskin92 opened this issue Apr 2, 2019 · 3 comments · Fixed by #1465 or code98/jaeger#1
Labels
good first issue Good for beginners help wanted Features that maintainers are willing to accept but do not have cycles to implement

Comments

@benraskin92
Copy link

Currently, the /health endpoint returns a 204 when it becomes Ready, which isn't a great indicator of whether the service is healthy or not.

// New creates a HealthCheck with the specified initial state.
func New() *HealthCheck {
	hc := &HealthCheck{
		state: int32(Unavailable),
		mapping: map[Status]int{
			Unavailable: http.StatusServiceUnavailable,
			Ready:       http.StatusNoContent,
		},
		logger: zap.NewNop(),
	}
	return hc
}

However, it would be nice to return a 200 and something like:
{"ok":true,"status":"up"} or even {"uptime":1h20m}, etc.

@yurishkuro yurishkuro added good first issue Good for beginners help wanted Features that maintainers are willing to accept but do not have cycles to implement labels Apr 2, 2019
@benraskin92
Copy link
Author

I can probably tackle this when I get some time.

@yurishkuro
Copy link
Member

We indicate the status via HTTP status code, but I don't mind returning it in JSON as well. And I like the idea of uptime, so:

{
    "status": "unavailable"
}
{
    "status": "up",
    "uptime": "1h20m"
}

@jpkrohling
Copy link
Contributor

The initial idea was to indeed return some content, like the status of the connection to the backing storage, but we never ended up doing that.

Uptime is indeed something we can return right now. Perhaps another field indicating when it has started could also be helpful? Parsing 2019-04-03T09:31:07+02:00 is usually easier (and more accurate) than the uptime.

stefanvassilev added a commit to stefanvassilev/jaeger that referenced this issue Apr 8, 2019
Return 200 OK for status `ready` and `upTimeStats`

Resolves jaegertracing#1450
stefanvassilev added a commit to stefanvassilev/jaeger that referenced this issue Apr 8, 2019
Return 200 OK for status `ready` and `upTimeStats`

Resolves jaegertracing#1450
stefanvassilev added a commit to stefanvassilev/jaeger that referenced this issue Apr 8, 2019
Return 200 OK for status `ready` and `upTimeStats`

Resolves jaegertracing#1450

Signed-off-by: stefan vassilev <stefanvassilev1@gmail.com>
stefanvassilev added a commit to stefanvassilev/jaeger that referenced this issue Apr 10, 2019
Return 200 OK for status `ready` and `upTimeStats`

Resolves jaegertracing#1450

Signed-off-by: stefan vassilev <stefanvassilev1@gmail.com>
yurishkuro pushed a commit that referenced this issue Apr 13, 2019
* Return info msg for `/health` endpoint

Return 200 OK for status `ready` and `upTimeStats`

Resolves #1450

Signed-off-by: stefan vassilev <stefanvassilev1@gmail.com>

* Address PR comments

Signed-off-by: stefan vassilev <stefanvassilev1@gmail.com>

* Fix failing test

Signed-off-by: stefan vassilev <stefanvassilev1@gmail.com>

* Address PR comments

Signed-off-by: stefan vassilev <stefanvassilev1@gmail.com>

* Retrigger tests

Signed-off-by: stefan vassilev <stefanvassilev1@gmail.com>

* Retrigger tests

Signed-off-by: stefan vassilev <stefanvassilev1@gmail.com>

* Make thread-safe

Signed-off-by: Yuri Shkuro <ys@uber.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for beginners help wanted Features that maintainers are willing to accept but do not have cycles to implement
Projects
None yet
3 participants