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

basic health endpoint #295

Closed
wants to merge 1 commit into from
Closed

Conversation

ktzsolt
Copy link

@ktzsolt ktzsolt commented Nov 22, 2023

Created a /health endpoint so this can be used in k8s with http readiness/liveness probes.
In router.go I added:

	// /health endpoint
	if reqURI == "/health" {
		c.SendString("UP!")
		c.SendStatus(http.StatusOK)
		return nil
	}

I never used go before, but the docker image based on the Dockerfile is built and the webp server is running as it should be, /health url returns "UP!" with HTTP 200.

@n0vad3v
Copy link
Member

n0vad3v commented Nov 22, 2023

Thanks for contributing, currently you can just rely on Pod status to determine whether WebP Server Go is running in healthy state.

May we know a little bit more on your use case on this?

@ktzsolt
Copy link
Author

ktzsolt commented Nov 22, 2023

I am using this pattern: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

A common pattern for liveness probes is to use the same low-cost HTTP endpoint as for readiness probes, but with a higher failureThreshold. This ensures that the pod is observed as not-ready for some period of time before it is hard killed.

I run the webp as a sidecar container in the pod so when webp would be overwhelmed with requests and can't serve requests or not fast enough, I just want the pod to go into "not ready" state and let the new requests served by other pod replicas until it is able to server requests again.

Also the go webp server process (/usr/bin/webp-server) might be up and running so the container is up and running but the server process might not serve request at all due to some unknown error or bug in go itself, any 3rd party package used in the code or in the code itself. Even in the containers OS packages can be bugs.

I always use readiness, liveness and startup probes and when I have to fall back to exec probe (write file into container, and check if it exists, or use bash script to check if some file has something in it) I think it is "code smell". I would have also done exec probe or TCP probe here too, but I just thought why not check out the code and try to write a basic /health HTTP endpoint myself.

I guess these scenarios will never happen to me, but "anything that can go wrong will go wrong".

@n0vad3v n0vad3v mentioned this pull request Nov 23, 2023
@n0vad3v
Copy link
Member

n0vad3v commented Nov 23, 2023

I got you, will add this feature.

There is a better way to add this endpoint, at router, I've done a PR on #296

@ktzsolt
Copy link
Author

ktzsolt commented Nov 23, 2023

Excellent, thanks!

@ktzsolt ktzsolt closed this Nov 23, 2023
@n0vad3v
Copy link
Member

n0vad3v commented Nov 23, 2023

We've released https://github.com/webp-sh/webp_server_go/releases/tag/0.10.2 that includes /healthz endpoint.

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

Successfully merging this pull request may close these issues.

None yet

2 participants