- Sitemap
- Related Documents
- Properties
Introduction
This concept gives an overview of IOM server health checks and how they can be used within an HA installation of IOM. The document is mainly addressed to application administration.
Glossary
Wording | Description |
|---|---|
API | Application Programming Interface |
HA | High Availability |
IOM | The abbreviation for Intershop Order Management |
REST | Representational State Transfer |
References
Health Status of Application Servers
An application server is one single application server within a cluster of multiple application servers.
The health status of one application server reflects whether the server is able to adequately fulfill its tasks.
For Intershop Order Management, the status can be requested using the REST API.
The IOM health check is limited to a database connection check.
Application Server Monitoring
The main purpose of health status support is to enable server monitoring applications to manage the application cluster, i. e., not to host unhealthy/broken servers and/or to trigger the repair/restart of unhealthy/broken servers.
Especially in the case of HA health checks are required to always ensure a running application.
Cluster Status
The cluster status endpoint in the REST API is deprecated in IOM 4.6 and should be removed in IOM 4.7.
There is no requirement for a cluster status overview in Kubernetes context.
The cluster status reflects the general health status of each application server of a server cluster. Basically, it can be used to give a quick overview of the healthiness of the server cluster.
The cluster status can be requested using REST API which returns the persisted results from the last health status check of each application server.
REST
The REST response for the application server health status will return a status code that reflects the health status and can be used by the server monitoring application.
Further Information
Deployment
To offer the health check for an IOM application server, the artifact oms.monitoring must be deployed.
Configuration of Checked Services
The following list describes the current checks that are done by a health check.
Check | Description | Required/Configurable |
|---|---|---|
Database | A connection to the database will always be established. | Always performed |
Also, see Guide - Operate Intershop Order Management 3.X or later, see Overview - IOM Setup, for cluster properties.
Triggering Health Checks
Since IOM 4.6, the application server status check is synchronous and not cached anymore. It is triggered by the REST request itself.
Before IOM 4.6, each performed check was cached, and subsequent requests served from that cache as long as the lastCheck time was not older than the value configured with is.oms.healthcheck.cachelivetime.
Health checks were performed by a Java timer and not triggered by the REST requests. The result will be cached for responding to REST calls.
With this improvement, the signification of the property is.oms.healthcheck.cachelivetime has changed and is.oms.healthcheck.recurringtime has been added.
Also, see Guide - Operate Intershop Order Management 3.X or later, see Overview - IOM Setup, for cluster properties.
Expandability
The health check can be extended within HealthServiceBean.java of artifact oms.monitoring by adding a new check.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.