Health endpoints#
A load balancer, an orchestrator or a monitoring system asks each Querona node two questions: is it alive, and does it accept clients. Querona answers both over HTTP without a login, and gives administrators the state of the node in more detail.
Endpoint |
Access |
Answer |
|---|---|---|
|
Anonymous |
|
|
Anonymous |
|
|
A login that holds |
The health details of the node, described below. |
The endpoints are served on the port of the Administrative Portal.
Load balancers#
Point the health probe of a load balancer at /health/ready on the port of the Administrative Portal, and treat
200 as healthy. A node that is starting answers 503, and a node that is stopping refuses the connection, so the
load balancer stops sending it new connections in both cases. The answer carries no role and no version.
Liveness probes#
/health/live checks nothing beyond the web server itself. A problem outside the process, such as an unreachable
metabase, therefore never makes an orchestrator restart Querona.
Health details#
A login that holds the VIEW SERVER STATE permission reads the details of the node with
GET /api/1.0/health:
the readiness status, as
/health/readyreports it;the id and name of the instance;
the TDS port and whether the TDS listener accepts connections;
the web port and whether it serves HTTPS;
whether the metabase answered a test query within five seconds, how long it took and, when it did not answer, why;
when the Querona process started, in UTC;
the build version.
A login without the permission gets the answer VIEW SERVER STATE permission was denied on object ‘server’, database ‘master’.
For example, in PowerShell:
Invoke-WebRequest -Uri https://querona.example.com/health/ready -UseBasicParsing |
Select-Object StatusCode, Content