Basic Health Checks¶
WSO2 API-M exposes health check APIs as explained below.
API-M runtime health checks¶
Basic health checks can be performed on an API Manager node by connecting to relevant ports. Listed below are the ports that can be used for health checks in the available API-M profiles.
|API Manager Profile||Ports that can be used for health checks|
|Gateway||9763 (HTTP), 9443 (HTTPS)|
|Traffic Manager||5672 (TCP), 9611 (TCP)|
|Key Manager||9673 (HTTP), 9443 (HTTPS)|
For more information on each profile, see API Manager Profiles.
There can be scenarios where even though the ports are responding, the services are not properly started. It is advisable to use service-level health checks to ensure that the services are started. For example, API Manager by default is shipped with the simple axis2 service named
Version. This service returns the version of the API Manager instance that is running currently.
A sample cURL command and the response from the
Version service are given below.
curl -v http://<HOSTNAME>:<PORT>/services/Version
curl -v http://localhost:9763/services/Version
<ns:getVersionResponse xmlns:ns="http://version.services.core.carbon.wso2.org"><return>WSO2 API Manager-4.0.0</return></ns:getVersionResponse>
When deploying the WSO2 API Manager Gateway, it's a best practice to ensure that all APIs are correctly deployed and ready to accept traffic before directing actual requests to the newly spawned Gateway. It's important to note that merely checking the server status might not be sufficient in this context.
To verify the successful deployment of APIs in the Gateway, we recommend using the Gateway health-check API. This dedicated API allows you to confirm the readiness of all the APIs in the Gateway. If everything is in order and all the APIs are deployed successfully, the health-check API will respond with a status code of 200 OK. This additional step helps guarantee that your API Gateway is fully prepared to handle incoming traffic.
Sample usages of this are shown below
curl -k https://<GATEWAY_HOSTNAME>:<PORT>/api/am/gateway/v2/server-startup-healthcheck
readinessProbe: httpGet: path: /api/am/gateway/v2/server-startup-healthcheck port: 9443 scheme: HTTPS
Micro Integrator health checks¶
WSO2 Micro Integrator provides a dedicated API for checking the health of the server. This can be used by a load balancer prior to routing traffic to a particular server node.
Health Check API¶
The health check API has two behaviors depending on whether the deployment is mutable or immutable. If the deployment is mutable (which is mostly the configuration in centralized deployments), the probe gives a ready status when the server starts successfully. If the deployment is immutable, the probe gives a ready status only if all the CApps are deployed successfully during server startup. If there are faulty CApps, the probe returns the list of faulty CApps.
The health check API serves at:
The health check can be performed over HTTPS APIs by adding the below configurations in the
[readiness_probe] protocols = "http https"
curl GET 'https://localhost:9164/healthz' -k
If you are running the server instance with a different port offset other than the default (which is 10), the heath check API serves at 9191 + offset.
The readiness probe is a vital configuration for deployments in Kubernetes as it governs the routing logic. The requests are not routed to a pod that is not ready.
Add the following configurations to your
deployment.yaml file in order to configure the readiness probe for
the server. Initial delay and the period has to be fine-tuned according to your deployment.
readinessProbe: httpGet: path: /healthz port: 9201 initialDelaySeconds: 3 periodSeconds: 1
The Liveness probe is a primary configuration in Kubernetes since it is used for knowing when to restart a container. For example, if the server stops serving requests on the HTTP port, even though the server is alive, the container needs to be restarted so that the Micro Integrator instances serve the requests flawlessly. The default HTTP socket of WSO2 Micro Integrator can be used to health check for Liveness.
Add the following configurations to your
deployment.yaml file in order to configure the Liveness probe for
the server. Initial delay and the period have to be fine-tuned according to your deployment.
livenessProbe: tcpSocket: port: 8290 initialDelaySeconds: 15 periodSeconds: 5