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

Feature request - REST API - healtcheck endpoint #15

Open
thim81 opened this issue Jun 13, 2019 · 3 comments
Open

Feature request - REST API - healtcheck endpoint #15

thim81 opened this issue Jun 13, 2019 · 3 comments

Comments

@thim81
Copy link
Contributor

thim81 commented Jun 13, 2019

Hi Reddec,

Another idea, the REST API now exposes per instance the config and status.

/instance/{name}:
    get:
      summary: Get instance config and status

This is very usefull from a management point of view, but it would also be usefull to have a "healthcheck" endpoint that just reports the status of a service and/or an endpoint that reports only the status of all managed services.

These healtcheck endpoints could be added to monitoring tools, that would report a system as down if the healtcheck endpoint would report a certain error code.

Idea:

/healtchecks/:
get:
summary: Get instance health status of all services that should be running

/healtcheck/{name}:
get:
summary: Get instance health status of a service

Response codes:

  • 200: if the service is running or stopped, body: "service xxx is up"
  • 5xx: if the service is not running, while it would be expected to be running, body "service xxx is down"
@thim81
Copy link
Contributor Author

thim81 commented Jun 13, 2019

If I look at the

router.GET("/instance/:name", func(gctx *gin.Context) {
		name := gctx.Param("name")
		for _, sv := range pl.Instances() {
			if sv.Config().Name == name {
				gctx.JSON(http.StatusOK, sv)
				return
			}
		}
		gctx.AbortWithStatus(http.StatusNotFound)
	})

I think I'm able to create a PR for the Healtcheck feature, but I first want to present it to you before giving it a try.

@reddec
Copy link
Owner

reddec commented Jun 13, 2019

Hi Thim!

It looks OK for me. Maybe bit redundant, because basically you can combine endpoints /instance and /supervisors plus some logic. However, I fully agree that for automation purpose existent approach is not a good way.

@thim81
Copy link
Contributor Author

thim81 commented Jun 13, 2019

This endpoint would mostly be used for monitoring purposes and unsecured, so we don't want to expose the full service info.

I'll give it a GO ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants