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.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
anddjango-heartbeat
offers 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.