Health checks provide a mechanism for determining the liveness of a given connector. The method used to determine liveness will often vary depending on the exact connector. Health checks are an essential part of using the orchestrator for continuity use cases.
Health Check Algorithms
OIDC-based IDP
When determining the liveness of an OIDC-based IDP, a well-formed request is made to the IDP's auth endpoint. It is expected that a successful response is returned.
SAML-based IDP
When determining the liveness of an SAML-based IDP, a well-formed request is made to the IDP's SSO endpoint. It is expected that a successful response is returned.
LDAP
When determining the liveness of an LDAP server, the Orchestrator will connect to the server and bind with the provided service account credentials. It is expected that a successful response is returned.
Configuration options
Enabled
enabled determines if the health check runs.
Timeout
timeout determines the HTTP client or LDAP client timeout duration. When not defined, a default of 30 seconds will be used.
Interval
interval determines the duration that will elapse before the next health check probe is made. When not defined, an interval of 30 seconds will be used.
Healthy Threshold
healthyThreshold determines the number of consecutive successful health checks necessary to consider the connector healthy. When not defined, a threshold of two (2) successful health checks will be used.
Unhealthy Threshold
unhealthyThreshold determines the number of consecutive failed health checks necessary to consider the connector unhealthy. When not defined, a threshold of two (2) failed health checks will be used.
Simulation
simulation defines the optional properties that determine whether a health check is mocked.
Enabled
enabled determines if the simulation runs.
Start After
startAfter is the duration that must elapse before the simulation starts.
Downtime
downtime is the duration that the IDP will be down.
Custom health check endpoint
customEndpoint defines the optional properties that determine whether a custom health check endpoint should be used.
Type
type determines the type of custom health check to use. Currently, the only available type is http.
Endpoint
endpoint determines the endpoint to use for the custom health check. The value must be a fully qualified URL.
Headers
headers determines the optional headers to include in the custom health check request. The value must be a map of key-value pairs.
Transport Layer Security (TLS)
tls optionally references the name of the TLS config defined in the tls section.
Response matcher
responseMatcher defines the optional properties that determine the expected response from the custom health check.
Expected statusesexpectedStatuses defines the list of expected HTTP status codes that should be returned by the custom health check. The default value is 200.
Body
body defines the optional rule that will be used to match against the response body. This option is useful when a given health check endpoint returns dynamic content in the response body to indicate liveness.
Equalsequals evaluates to true if the response body exactly matches the expected value.
Containscontains evaluates to true if the response body contains the expected value.
Regexregexp evaluates to true if the response body matches the regular expression.
Examples
Basic Health Check
connectors:
- name: azure
type: azure
# ...
healthCheck:
enabled: true
timeout: 5s
interval: 10s
Health Check with Simulation
connectors:
- name: azure
type: azure
# ...
healthCheck:
enabled: true
simulation:
enabled: true
startAfter: 1m
downtime: 1h
Health Check with Custom Endpoint
tls:
healthcheckTLS:
caFile: /etc/maverics/certs/rootCA.pem
connectors:
- name: azure
type: azure
# ...
healthCheck:
enabled: true
customEndpoint:
type: http
tls: healthcheckTLS
endpoint: https://example.com/health
headers:
client_id: example_id
client_secret: <client_secret> # This value will be retrieved from a secret provider.
responseMatcher:
expectedStatuses:
- 200
- 201
body:
contains: '"status": "up"'