Infrastructure/operations
Monitoring
Ontoserver supports the Docker Healthcheck model. This checks the health of any resource to determine whether that resource is operating normally.
Ontoserver further supports detailed health check information via the /healthcheck.sh script which can be run on the container with several options:
| -h | Display this usage message |
| -v | Output details of healthcheck |
| -p | Pedantic mode – exit with non-zero status if any indexes are unhealthy |
| -l | Check preload – exit with non-zero status if preload is running |
| -s | Check startup preload success – exit with non-zero status if startup preload is not successful |
| -f | Check startup preload has failed or is running but will fail – exit with non-zero status if startup preload will or has failed |
Additionally, running docker inspect on an Ontoserver container will reveal healthcheck.sh details via the Health Log.
Logging
Ontoserver produces log messages that can be used to monitor the usage of the server’s APIs.
For the FHIR API, Ontoserver will produce both “provider” and HTTP “response” log messages. The latter correspond to each REST call, while the former correspond to the logical FHIR operations. Both these log message types are formatted as JSON objects to facilitate parsing and analysis.
In most cases there is one provider message per response message, but for batch requests there will be one provider message per batch entry, but only a single response message. For example, a GET-style $expand request will generate one log message of each type. By contrast, a batch request containing two $lookup requests will generate three provider logs (one for the batch and two for the $lookup requests), and one HTTP response log (for the batch response). Request ids are included in the log messages so that provider logs can be linked with their corresponding request log.
Details on this structured logging can be found in Ontoserver’s online documentation: Log Format
TLS offload and caching
TLS offload
Ontoserver can operate over plain HTTP or HTTPS by configuration – i.e. TLS can be terminated by the application.
There are configuration settings for each application to provide certificates to use for TLS. However, it is often more convenient to terminate TLS in front of the applications using a reverse proxy (e.g. Kubernetes ingress controller or AWS ELB/ALB) which can be also used for other purposes (routing, security, caching, etc). This enables certificate renewal to be integrated with automated sources such as Let’s Encrypt or platform services in cloud providers, eliminating the need to regularly update the certificates configured into the applications.
To offload TLS to a reverse proxy simply run Ontoserver without TLS and configure the reverse proxy to perform TLS termination.
Caching
Ontoserver can benefit to some degree from web caching, which can speed up response times.
Ontoserver is built to support standard HTTP caching using ETags and Last-Modified headers, meaning standard front-side caches such as Apache, NGINX, Varnish, Squid, etc. can be used.
Effective caching in front of Ontoserver can provide a very significant performance benefit for common requests, and computationally difficult requests, particularly in a read-only Ontoserver endpoint context, where caching can be set up to be particularly aggressive.
However authorisation can reduce the effectiveness of the cache, where a cache can only choose to not cache responses for authorised requests, or include the authorisation in the cache key limiting hits to the same user session. Therefore, caching is much more effective on content without authorisation.