Health Monitoring Usage

Determine Web Service Health

The health monitoring endpoints can be used to determine if an Elastic Path Commerce service is healthy and/or ready to accept traffic. There are separate endpoints for determining liveness vs readiness:

• The liveness endpoint should be checked regularly by the deployment environment. If this returns a non 2XX response, the service should be restarted.
• The readiness endpoint should be checked by the deployment environment during service startup. The service should not be considered ready to accept traffic until this returns a 2XX response.

Endpoints

All of the paths listed below are accessible on the standard Tomcat port 8080. However if your Tomcat configuration supports a second connection pool, we recommend using port 8081 to check liveness to ensure that if the available Tomcat connections are exhausted the liveness checks will not fail.

Cortex

• /healthcheck/liveness - Liveness validation.
  • Checks that the application is able to respond to requests (ApplicationStatusTargetImpl).
• /healthcheck/readiness - Readiness validation.
  • Checks that all OSGi services are started (OSGIBundleStatusTargetImpl).
  • Checks that the database connection pool has available connections (DBConnectionPoolStatusTargetImpl).
• /status - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.
• /status/lb - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.

Integration Server

• /healthcheck/liveness - Liveness validation.
  • Checks that the application is able to respond to requests (ApplicationStatusTargetImpl).
• /healthcheck/readiness - Readiness validation.
  • Checks that the database connection pool has available connections (DBConnectionPoolStatusTargetImpl).
• /status - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.
• /status/lb - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.

Batch Server

• /healthcheck/liveness - Liveness validation.
  • Checks that the application is able to respond to requests (ApplicationStatusTargetImpl).
• /healthcheck/readiness - Readiness validation.
  • Checks that the database connection pool has available connections (DBConnectionPoolStatusTargetImpl).
• /status - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.
• /status/lb - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.

Search Server

• /healthcheck/liveness - Liveness validation.
  • Checks that the application is able to respond to requests (ApplicationStatusTargetImpl).
• /healthcheck/readiness - Readiness validation.
  • Checks that the database connection pool has available connections (DBConnectionPoolStatusTargetImpl).
• /status - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.
• /status/lb - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.

Data Sync Server

• /healthcheck/liveness - Liveness validation.
  • Checks that the application is able to respond to requests (ApplicationStatusTargetImpl).
• /healthcheck/readiness - Readiness validation.
  • Checks that the database connection pool has available connections (DBConnectionPoolStatusTargetImpl).
• /status - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.
• /status/lb - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.

Commerce Manager

• /healthcheck/liveness - Liveness validation.
  • Checks that the application is able to respond to requests (ApplicationStatusTargetImpl).
• /healthcheck/readiness - Readiness validation.
  • Checks that the database connection pool has available connections (DBConnectionPoolStatusTargetImpl).
• /?servicehandler=status - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.
• /status - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.
• /status/lb - Readiness validation (deprecated). This is an alias that resolves to the same behaviour as the /healthcheck/readiness path.

Responses

If the healthcheck validations pass, the endpoint will return a 200 HTTP status code. If one or more healthcheck validations pass, the endpoint will return a non-200 HTTP status code.

Additionally, the body of the response will contain a JSON object with details, such as the following:

[
  {
    "summary": "Application is up",
    "timeTakenMillis": 0,
    "details": "Application name = Cortex",
    "checkName": "ApplicationStatusTargetImpl",
    "status": "OK"
  }
]

[
  {
    "summary": "All required OSGI bundles are loaded and active.",
    "timeTakenMillis": 27,
    "details": "URL = http://localhost:9080/cortex/healthcheck",
    "checkName": "OSGIBundleStatusTargetImpl",
    "status": "OK"
  },
  {
    "summary": "Database connection pool is healthy.",
    "timeTakenMillis": 19,
    "details": "Currently 0 connections are active, 10 connections are idle and 0 connections are waiting for datasource \"jdbc/epjndi\".",
    "checkName": "DBConnectionPoolStatusTargetImpl",
    "status": "OK"
  }
]

Polling Frequency

The values below are our recommended starting point for a typical deployment. Project teams may need to tune the values to adapt to customizations or unique business needs. The values should be validated through testing.

We recommend the following probe settings for liveness checks:

• How long to wait before making the first check (Kubernetes initial_delay_seconds): 300 seconds
• How often to check (Kubernetes period_seconds): 10 seconds
• How long to wait for a response before calling it a failure (Kubernetes timeout_seconds): 2 seconds
• How many times to check before giving up and killing the container (Kubernetes failure_threshold): 3

We recommend the following probe settings for readiness checks:

• How long to wait before making the first check (Kubernetes initial_delay_seconds): 1 second
• How often to check (Kubernetes period_seconds): 10 seconds
• How long to wait for a response before calling it a failure (Kubernetes timeout_seconds): 2 seconds
• How many times to check before considering the container unavailable (Kubernetes failure_threshold): 3