Health Check Probes
Health check probes determines when to start the container and ready for service or live to serve traffic. Temenos microservices support the health check probes for better stability and availability of the Kubernetes (K8) platform. To improve the availability of microservices on the K8 platform, you need to implement a set of probes in microservices to monitor the application’s health.
When the pods fail to operate, the health check probes act on the pods and display the reason for the failure. Thus, the health check probes is an important feature in microservices to monitor and act on the state of pods (containers) and to ensure only healthy pods serve the traffic. With the help of the probes, we can control when a pod should be started, ready for service, or live to serve traffic.
The following are different types of health check probes implemented in the related pods.
- Liveness Probe - Indicates whether the container is operating actively. If yes, this probe allows it to run for some more and check again. Else, the kubelet kills and restarts the container.
- Readiness Probe - Indicates whether the application running in the container is ready to accept the customer’s requests. If yes, services matching the pod are allowed to send traffic to it. Else, the endpoints controller removes the pod from all matching Kubernetes Services.
- Startup Probe - Indicates whether the application running in the container is started. If yes, the other probes start functioning. Else, the kubelet kills and restarts the container.
Solution Approach
The following are the three services to which you can add the health check probes.
- API Service - Serves the functional purpose of the microservice through REST API. This service mandatorily depends on a database (SQL/NoSQL), and optionally depends on Kafka, and other Temenos microservices.
- Ingester service - Serves the background processing of Kafka events. This service mandatorily depends on Kafka.
- Scheduler service - Runs the scheduler jobs or tasks of the 'API service'. The jobs are picked from a database. This service mandatorily depends on the database and Kafka.
Each of the above services has different prerequisites while starting the service and serving the requests. In the case of Ingester and Scheduler containers, these prerequisites are common across all the microservices, such as GenConfig, VirtualTable, and so on, and change as per the API service container.
As a solution approach, the probes are implemented as Rest APIs for these containers.
Sample Configuration for API Service in YAML file
In Helm-postgreSql or Helm-Mongo pack, add the configuration for probe in the <infraMS_name>-api.yaml file that is available in the helm-chart\svc\templates\svc directory as given in the screenshot below.
Sample Configuration for Ingester Service in YAML file
In Helm-postgreSql or Helm-Mongo pack, add the configuration for probe in the <infraMS_name>-ingester.yaml file that is available in the helm-chart\svc\templates\svc directory as given in the screenshot below.
Sample Configuration for Scheduler ervice in YAML file
In Helm-postgreSql or Helm-Mongo pack, add the configuration for probe in the <infraMS_name>-scheduler.yaml file that is available in the helm-chart\svc\templates\svc directory as given in the screenshot below.
Sample API for API Health Check
API container has a pre-built health check API which would fetch the health status of the API service.
GETV1.0.0/health/api/
http://localhost:7014/ms-adapterservice-api/api/v1.0.0/health/api/{
"status": "SUCCESS",
"details": {
"hostName": "adapterms-api-5758459bbb-wxspl",
"database": [
{
"checkName": "DATABASE",
"name": "adapterservicedb",
"status": "SUCCESS"
}
]
}
}
Sample API for Ingester Health Check
Ingester container has a pre-built health check API which would fetch the health status of the Ingester service.
GET/{ingester}/v1.0.0/health
http://localhost:7011/ms-adapterms-command-ingester/v1.0.0/health{
"status": "SUCCESS",
"components": {
"ingester": {
"status": "SUCCESS",
"details": {
"hostName": "adapterms-command-ingester-5f74d9bf8b-82s9w",
"database": [
{
"checkName": "DATABASE",
"name": "adapterservicedb",
"status": "SUCCESS"
}
],
"streamTopic": {
"status": "SUCCESS",
"sourceStream": "ms-adapterservice-event-topic,ms-adapterservice-second-event-topic"
}
}
},
"jms": {
"status": "UP",
"details": {
"provider": "ActiveMQ"
}
},
"livenessState": {
"status": "UP"
},
"readinessState": {
"status": "UP"
}
},
"groups": [
"liveness",
"readiness"
]
}
In this topic