CAS, being a Spring-Boot application at heart, includes a number of endpoints to help you monitor and manage the server when it’s pushed to production. You can choose to manage and monitor the deployment using HTTP endpoints, referred to as actuators. This tutorial provides a basic overview of the health
and status
endpoints provided by both Spring Boot and CAS and also provides instructions on how such endpoints can be secured for access and win.
Our starting position is based on the following:
6.1.x
11
jq
CAS has traditionally presented a status
endpoint, now at /actuator/status
, which provides the user with basic server information and reports from all Monitor
components; those that reported back on memory usage, connection information, etc. Having switched to Spring Boot, such components are transformed to use the native Spring Boot API known as HealthIndicator
s and the status
endpoint is mostly kept for legacy reasons and backward compatibility. The status
endpoint now simply acts as a proxy by invoking the health
endpoint internally to obtain and present data. If the health
endpoint is turned off, you would only receive basic and very modest health data from status
itself.
More information about the health endpoint may be found here, and high-level notes discussing the monitoring capabilities of the Apereo CAS server can be found here.
Let’s try to enable both status
and health
first. The following settings should come in handy:
management.endpoints.web.exposure.include=status,health
management.endpoint.status.enabled=true
management.endpoint.health.enabled=true
cas.monitor.endpoints.endpoint.defaults.access[0]=IP_ADDRESS
cas.monitor.endpoints.endpoint.defaults.requiredIpAddresses[0]=127\\.0\\.0\\.1
management.endpoint.health.show-details=always
The above collection of settings instruct CAS to:
status
and health
over the web as HTTP endpoints.health
endpoint can always produce details from internal monitors and health indicators.If you invoke the status
endpoint using curl https://sso.example.org/cas/actuator/status | jq
:
{
"status": 200,
"description": "OK",
"health": "UP",
"host": "misaghmoayyed",
"server": "https://sso.example.org",
"version": "6.1.0-RC2-SNAPSHOT - ..."
}
Simple stuff. Let’s invoke health
with curl https://sso.example.org/cas/actuator/health | jq
:
{
"status": "UP",
"details": {
"memory": {
"status": "UP",
"details": {
"freeMemory": 4066209416,
"totalMemory": 4294967296
}
}
}
}
Notice how details
are always returned back in the response where we are getting data from one health indicator, reporting on memory usage and statistics.
The health
endpoint provided by Spring Boot is set to check the status of your running CAS server. It is often used by monitoring software to alert someone when a production system goes down. Health information is collected from the content of a registry that has collected, at runtime, reports from HealthIndicator
components and monitors.
Spring Boot includes a number of auto-configured HealthIndicator
s and CAS presents a few of its own. The final system state is derived by an aggregator which sorts the statuses from each HealthIndicator
based on an ordered list of statuses. The first status in the sorted list is used as the overall health status.
/login
endpoint, stop doing that. You should be using status
or health
instead.
Note that all health indicators (except the memoryHealthIndicator
) are turned off by default whose capability can be individually controlled. For instance, we could turn off the memory monitor via:
management.health.memoryHealthIndicator.enabled=false
With the above setting, if you try to invoke the health
endpoint again you may see:
{
"status": "UP",
"details": {
"application": {
"status": "UP"
}
}
}
…where details on memory usage are now removed, given the monitor underneath is disabled.
More information on CAS health indicators and monitors can be found here. If you’d like to learn more details about this topic, see the Spring Boot documentation.
I hope this review was of some help to you and I am sure that both this post as well as the functionality it attempts to explain can be improved in any number of ways. Please feel free to engage and contribute as best as you can.
Monday-Friday
9am-6pm, Central European Time
7am-1pm, U.S. Eastern Time
Monday-Friday
9am-6pm, Central European Time