You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Optionally if we want to support the concept of startup/readiness probes we could split this into three routes that return 200 on success and something else for the appropriate scenarios:
/health/startup - 200 as soon as the application is started
/health/ready - 200 as soon the config is loaded
/health/alive - 200 once the exporter is started
I do believe that returning a non-200 reply in case a router is not available is not appropriate.
Currently, the containerized deployment works very easily but the container engine has no knowledge about the health of the instance.
For Docker the following concept applies: https://docs.docker.com/reference/dockerfile/#healthcheck
This can be reused for k8s of course: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
For this simple purpose, I would recommend having a simple
/health
endpoint that returns only 200 if the exporter runs successfully.The text was updated successfully, but these errors were encountered: