Health Check Metrics

From idenprotect Knowledge Base
Jump to: navigation, search

Introduction

The idenprotect Core Platform has a Metrics API which runs a series of Health Checks. These health checks are available so you can check in an instant that everything is running and connected as you are expecting. This is especially useful if you are running multiple instances of the server and are managing load balancing decisions with something like GTM (Global Traffic Manager).

The Health Check metrics are accessible in a couple of different ways but both require the idenprotect Core Platform to be installed and running. If the idenprotect Core Platform has not yet been installed, please see Start Here - idenprotect Core Platform


Health Check Metrics

Available Health Checks

The following are the currently available health checks. More health checks may be added later and if they are, this list will be updated.

  • idenprotect - The status and version of the idenprotect Core Platform
  • Authentication Portal - If the idenprotect Core Platform is capable of contacting the idenprotect Authentication Portal and its version
  • User Portal - If the idenprotect Core Platform is capable of contacting the idenprotect User Portal and its version
  • Database - If the idenprotect Core Platform is capable of contacting a database
  • LDAP - If the idenprotect Core Platform is capable of contacting LDAP
  • SMTP - If the idenprotect Core Platform is capable of contacting an SMTP server

Accessing the Health Checks

The Health Check Metrics are accessible in a couple of ways. They are immediately available upon logging into the idenprotect Core Platform admin console in the top-right corner under the heading Server Health. It can also be accessed by making a GET request to the following API (replace pathtohost with the location of your idenprotect Core Platform installation)

https://pathtohost/api/metrics/healthcheck 

Understanding the JSON response

If you are accessing the API directly, as long as the server is running and accessible - you will get a response with an HTTP status code indicating whether the request has succeeded or failed and a response body containing a JSON object in the following format. Note that the following example shows both a passing health check and a failing health check for reference. For the status of the applications, the message will show the application's version number on a successful check.

[
    {
        "active":true,
        "healthCheckName":"Database"
    },
    {
        "active":false,
        "healthCheckName":"LDAP",
        "message":"Ldap service is not connected"
    },
]

If you do not get a response, please ensure the server is running.

If all Health checks have passed, the HTTP response status code will be 200 (OK). If ANY of the checks have failed, the HTTP response status code will be 500 (Internal Server Error)

For more information on the specifics of any failures, you can see the details in the JSON object which contains a list of checks. Each list item can contain the following:-

  • "active" - Boolean value, always present. True for passing a check and false for failing check
  • "healthCheckName" - String, always present. The name of the check being performed. The defaults are Database, LDAP and SMTP.
  • "message" - String, present if the check has failed or if it is providing additional information such as the Version number. This can contain a brief message advising of the problem and a stack trace if unexpected exceptions are thrown.