Search health check

The search health check API is used to regularly check the status of Commerce containers to
make sure they are in a healthy state.

The search health check is a REST call with the following endpoint with the required
parameter type and an optional parameter mode:
/search/admin/resources/health/status?type=type&mode=modetype
where type is either environment or container,. Container allows an additional
parameter, mode=modetype where modetype is either startup (the default) or liveness. The
default value for mode is startup, which is the current behaviour.

The health check call will return 200 if successful, and 500 if unsuccessful.

type=environment
A health check is composed to test whether multiple parties can communicate with each
other. The result differs slightly depending on which kind of node is pinged:

 On master servers, the Authoring database and Authoring transaction server are
both checked.
 On the repeater, the process looks for a live database and cores in all
subordinates.
 In subordinates, it looks for a live database, live transaction server and cores in
all subordinates.

type=container
The check is micro-service tests run at a set interval to ensure that each container stays
healthy. When called on the master or repeater, it verifies that all local cores accept
search queries and are responsive. If run on the repeater it will perform the same check,
plus if the mode is set to startup it will verify that replication is working with subordinates.
mode=startup
DEFAULT option if mode parameter is not set. When the mode parameter is not invoked
or has the value of startup, if the search repeater is brought down (or is temporarily
unavailable), then all its subordinate search servers are also brought down.

 Check that we can send a request to each of our search cores (based on search
cores defined in SRCHCONF/SRCHCONFEXT table).
 If Step 1 is successful, then check results of index replication.
 Return a successful health check if no checks failed, otherwise return a failed
health check.

mode=liveness
If the mode parameter has the value of liveness, the health check will return OK if Solr
subordinate servers are live even if the search repeater is unavailable.

1. Check that it can send a request to each of its search cores (based on search
cores defined in SRCHCONF/SRCHCONFEXT table).
2. Return successful health check if no checks failed, otherwise return a failed
health check.

Both of the following calls will return with a status of 500.

search/admin/resources/health/status?type=container
 search/admin/resources/health/status?type=container&
mode=startup

This call will return a status of 200 if the repeater is down but
subordinate servers are up.

search/admin/resources/health/status?type=container&
mode=liveness