When hosting Devilry as a service in a container orchestration environment, the service will need to answer health checks quite often. Doing these against the / endpoint will clutter the access logs. A better approach is to have a dedicated endpoint, i.e. /health. This way, the production environment can use a logging.Filter to do disable access logging for /health endpoint so it never enters the logging infrastructure (ELK, etc).
Python packages such as django-health-check and django-heartbeat offers a lot of extra functionality while I believe we only need the bare minimum:
dedicated endpoint
test that database is available
Since this could run a few times per minute per pod the database test should be as simple as possible to keep it fast. If OK, it only needs to return a simple HTTP 200.
When hosting Devilry as a service in a container orchestration environment, the service will need to answer health checks quite often. Doing these against the
/endpoint will clutter the access logs. A better approach is to have a dedicated endpoint, i.e./health. This way, the production environment can use alogging.Filterto do disable access logging for/healthendpoint so it never enters the logging infrastructure (ELK, etc).Python packages such as
django-health-checkanddjango-heartbeatoffers a lot of extra functionality while I believe we only need the bare minimum:Since this could run a few times per minute per pod the database test should be as simple as possible to keep it fast. If OK, it only needs to return a simple HTTP 200.