HealthCheck

Service Owners can define healthcheck for their Services, which can be triggered by both the Service Owners and Consumers for their specific Service Items. When a healthcheck is triggered from NetOrca, a POST HTTP request is sent to the predefined target url. It is up to the receiving system, i.e. the Service Owners, how they decide a Service Item is healthy or not. However, NetOrca expects an HTTP response to that request with a specific structure. In the next section, the structure of the response is explained. Additionally, scheduled triggers are supported.

Create a HealthCheck

To create a healthcheck, the Service Owner must

HTTP requestPython SDKGUI

POST /v1/external/serviceowner/healthchecks/ HTTP/1.1
Content-Type: application/json
Authorization: Token <YOUR_TOKEN>
{
  "service": <service_id defined in NetOrca>,
  "target_url": "<target_url>",
  "authorization": "<auth header, e.g. 'Bearer AwesomeKey'",
  "schedule_enabled": true,
  "schedule_crontab": "* * * * *"
}

Trigger a HealthCheck

Both Service Owner and Consumer can trigger a healthcheck for a specific Service Item using

HTTP requestPython SDKGUI

GET /v1/external/<pov:"serviceowner"/"consumer">/healthchecks/trigger/service_item/<service_item_id>/ HTTP/1.1
Content-Type: application/json
Authorization: Token <YOUR_TOKEN>

Service Owners can also trigger healthcheck for all the Service's Service Items at once:

HTTP requestPython SDKGUI

GET /v1/external/<pov:"serviceowner"/"consumer">/healthchecks/trigger/service/<service_id>/ HTTP/1.1
Content-Type: application/json
Authorization: Token <YOUR_TOKEN>

When a healthcheck is triggered, a POST HTTP request is sent to the target url. Here, is the detail of the HTTP request:

For Service Item trigger:

POST <healthcheck.target_url> HTTP/1.1
Content-Type: application/json
Authorization: <healthcheck.authorization>
{
    "service": "<service name>",
    "service_item": "<service_item name>",
    "application": "service_item's application name",
    "consumer": "service_item's application's owner name"
}

And, for Service trigger:

POST <healthcheck.target_url> HTTP/1.1
Content-Type: application/json
Authorization: <healthcheck.authorization>
{
    "service": "<service name>", 
    "service_items" : [
        {
            "id": "<service item x id>", 
            "name": "<service item x name>", 
            "application": "<service item x 's application name>", 
            "consumer": "<service item x 's application's consumer name>"
        }
    ]
}

HealthCheck Response

NetOrca determines if the Service Item is healthy by the status code of the healthcheck HTTP response. If the status is 200, it means the Service Item is healthy. Otherwise, it is unhealthy.

In the case of trigger for Service, NetOrca determines it from the body of the response, not the status code. The HTTP response to the healthcheck for Service must contain a JSON dictionary in its body. An example of the JSON body is as follows:

{
    <service_item_id_1>: {
        "status_code": 200, // means healthy
        "body": {}
    },
    <service_item_id_2>: {
        "status_code": 400,  // means unhealthy
        "body": {}
    }
}

When a healthcheck is triggered, a healthcheck response object is created in NetOrca's database. This object includes the status code and the response body from the executed healthcheck's request. In the case of trigger for a Service, a healthcheck response object is generated for each Service Item.

The healthcheck task operates asynchronously. The response object might not immediately contain the final result. Therefore, each healthcheck response object includes a state to track the current status of the healthcheck request.

Here are the possible states for a healthCheck response:

• OK: The HealthCheck HTTP request is sent and responded successfully
• FAILED: The HealthCheck HTTP request is sent but the response was corrupted or timed out
• WAITING_FOR_RESPONSE: The HealthCheck HTTP request is sent and waiting for its response
• SCHEDULED: The HealthCheck HTTP request is waiting to be sent

HTTP requests limits

• NetOrca admin can limit the number of triggers for each healthcheck per minute
• They also can limit the number responses saved in NetOrca. For example, if they limit it to 10, only the 10 recent responses are available in NetOrca, the older responses will be deleted