Load balancing and health checks

When a Connect2id server is launched it becomes ready to serve requests when the health check endpoint becomes available and returns a 200 HTTP status code.

When setting up a load balancer / reverse proxy make sure you poll this endpoint to determine the operational status of a server. Do not poll the banner page (the root resource) as it will likely be loaded first, before all endpoints.

Calls to the monitoring endpoint (which includes the health check endpoint as sub-resource) require a bearer access token. You can configure up to two separate tokens:

• monitor.apiAccessTokenSHA256
• monitor.secondaryAPIAccessTokenSHA256

The access token can be passed in the Authorization header or in a access_token query parameter, with the latter method guaranteed to be supported by all load balancers.

For example:

http://c2id.com/monitor/v1/healthcheck?access_token=with1lohY8wion9ophair0icaquaXeiy

The health check endpoint will ping the underlying databases. If the cluster is run in replication mode it will also include a check for the “split brain” cluster condition, when communication between nodes has broken down, and there is risk of in-memory data becoming inconsistent.

Example healthy response, SQL backend, stateless cluster mode:

HTTP/1.1 200 Success
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: application/json

{
  "authzStore.accessTokenMap.availability": {
    "healthy": true
  },
  "authzStore.accessTokenMap.sqlStore.pool.ConnectivityCheck": {
    "healthy": true
  },
  "authzStore.codeMap.availability": {
    "healthy": true
  },
  "authzStore.longLivedAuthzMap.availability": {
    "healthy": true
  },
  "authzStore.longLivedAuthzMap.sqlStore.pool.ConnectivityCheck": {
    "healthy": true
  },
  "authzStore.revocationJournalMap.availability": {
    "healthy": true
  },
  "authzStore.revocationJournalMap.sqlStore.pool.ConnectivityCheck": {
    "healthy": true
  },
  "clients.registrationsMap.availability": {
    "healthy": true
  },
  "clients.registrationsMap.sqlStore.pool.ConnectivityCheck": {
    "healthy": true
  },
  "clients.remoteJWKSetCache.availability": {
    "healthy": true
  },
  "clients.remoteRequestJWTClaimsCache.availability": {
    "healthy": true
  },
  "op.authSessionMap.availability": {
    "healthy": true
  },
  "op.clientRegTokenMap.availability": {
    "healthy": true
  },
  "op.consentSessionMap.availability": {
    "healthy": true
  },
  "sessionStore.sessionMap.availability": {
    "healthy": true
  },
  "sessionStore.sessionMap.sqlStore.pool.ConnectivityCheck": {
    "healthy": true
  },
  "sessionStore.subjectMap.availability": {
    "healthy": true
  },
  "sessionStore.subjectMap.sqlStore.pool.ConnectivityCheck": {
    "healthy": true
  },
  "tenantRegistry.tenants.availability": {
    "healthy": true
  },
  "tenantRegistry.tenants.sqlStore.pool.ConnectivityCheck": {
    "healthy": true
  }
}

AWS Elastic Beanstalk

In AWS Elastic Beanstalk use the Application Healthcheck URL environment parameter (e.g. in AWS Cloud Formation) to set the URL for the health check endpoint together with the access token.

Example:

- Namespace: aws:elasticbeanstalk:application
  OptionName: Application Healthcheck URL #Spaces are correct!
  Value: '/monitor/v1/healthcheck?access_token=with1lohY8wion9ophair0icaquaXeiy'