-
Include only those checks which you think, if fails, will get cured with a pod restart
-
Health-check endpoints are called frequently and within fixed intervals, therefore your latencies should ideally be small. Enforce an overall upper bound for your health-check response and make sure to cancel any pending checks to the downstream dependencies in case of timeout.
-
If you are performing multiple dependency checks over the network, try to process them concurrently, if possible, to reduce the overall response time.
-
Checks that would prevent faulty app from deployment e.g. wrong URL’s for depdenencies
-
Readiness probes should include the viability of connections to downstream services in their result when there isn’t an acceptable fallback if the downstream service is unavailable. This does not mean calling the health check provided by the downstream service directly, as infrastructure will be checking that for you. Instead, consider verifying the health of the existing references your application has to downstream services: this might be a JMS connection to WebSphere MQ, or an initialized Kafka consumer or producer. If you do check the viability of internal references to downstream services, cache the result to minimize the impact health checking has on your application.
-
Highly Available Microservices with Health Checks and Circuit Breakers - https://konghq.com/blog/microservices-high-availability/
-
Designing a health-check API – ETHER Labs – https://medium.com/ether-labs/designing-a-health-check-api-a98784eb6a07
-
Kubernetes best practices: Setting up health checks with readiness and liveness probes | Google Cloud Blog https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes
-
https://stackoverflow.com/questions/46014206/kubernetes-liveness-and-readiness-probe-implementation
-
https://console.bluemix.net/docs/java-spring/healthcheck.html#healthcheck