Monitoring

The application provides a health endpoint which you can utilize to check the health of the service. Located at /api/health, it returns information about the current product and its version.

In turn this endpoint is used to implement a Docker HEALTHCHECK which will periodically check the container status.

For examples on how-to integrate this with existing tools, see:

Additionally you can use your own custom monitoring software to check the health endpoint.

Example response: /api/health (200 OK)
{
  "application": {
    "company": "Fonto",
    "product": "Content Quality",
    "version": "7.12.0"
  }
}

This endpoint is used to define a Docker HEALTHCHECK instruction when running the application backend in a Docker container.

Health-checks and ASPNETCORE_URLS

Note that when you overwrite the ASPNETCORE_URLS environment variable of the Docker container to define a custom port, the Docker health-check will fail as it will be looking for http://localhost/api/health by default to check the application status. You will have to overwrite the health-check prior to starting the application by either defining a custom health-check for the container in the docker run command or the docker-compose file for the application.

For example:

docker run --env ASPNETCORE_URLS=http://::8080 --health-cmd "wget --quiet --spider --tries=1 --timeout=20 http://localhost:8080/api/health || exit 1" my-image:latest

Or, when using docker-compose:

...
	healthcheck:
		test: wget --quiet --spider --tries=1 http://localhost:8080/api/health || exit 1
...

In addition, there is currently a known problem regarding the Docker health-check when you configure it to checks a HTTPS URL. Make sure that the health-check runs on the HTTP protocol instead of the HTTPS protocol. This is to prevent the health-check from creating zombie ssl_client (defunct) processes that will eventually kill the container.

Was this page helpful?