Apache Sling health checks tools

If we want to use an automated system for live checking and monitoring the current status, performance, and configuration of the AEM application environment, we can opt for OOTB Apache Sling Health Checks Tools.

Below I will explain the basic idea of these tools and demonstrate some simple configuration and customization examples. You will see how UI building is easy and simple to understand.

Problems and goals

Before resolving any AEM application issue, we should check the following points:

  • Required bundles are up and running;
  • Related web services endpoint are available;
  • Required resources and appropriate content structure exist.

All the steps above can be done manually from time to time, but we need to run these validations automatically. This approach will help us monitor the AEM application at a glance.

If we need to build such automation for live checking and monitoring environments, we can use OOTB Apache Sling Health Checks Tools (or HC).

Health Checks at a glance

HC instance is an OSGi service that implements org.apache.sling.hc.api.HealthCheck interface and returns Result according to validate conditions:

public interface HealthCheck {
public Result execute();
}

Result is a simple, immutable class that provides a Status (OK, WARN, CRITICAL, etc.) and one or more log-like messages for additional info.

Note: if you set any Result log message, it will be identified within AEM as WARN. As a result, we should define it as:

new Result(Result.Status.OK, "Some Message")

Health Checks Execution

AEM is a modular system so we have a couple of configuration places for every piece of the system. The HC Executor service is one of these services, which can be configured from “/system/console/configMgr/org.apache.sling.hc.core.impl.executor.HealthCheckExecutorImpl”:

Note: HC Executor executes every HC within the Sling Thread pool, guaranteeing that we have only one running instance at a time.

Custom Health Checks

For individual HC implementation, we should implement interface org.apache.sling.hc.api.HealthCheck first and specify options for service as follows:

@Component(metatype = true)
@Properties({
        @Property(name = HealthCheck.NAME,value = "HCName"),
        @Property(name = HealthCheck.TAGS,value = {"meetup"}),
        @Property(name = HealthCheck.MBEAN_NAME,value = "HCName")
})
@Service(value = {HealthCheck.class})
public class IncorrectLocalhostHC implements HealthCheck {

If HC needs to be executed by the scheduler (once a day, for example), we can specify schedule intervals within properties:

@Property(name = HealthCheck.ASYNC_CRON_EXPRESSION, value = "0 0 12 1/1 * ? *")

The Sling HC core 1.2.6 version will have a new property, “hc.resultCacheTtlInMs”. It overrides the global default TTL as configured in the HC executor for HC responses.

HC can also be configured with annotation @SlingHealthCheck, but it doesn’t work for OOTB in AEM 6.1:

@SlingHealthCheck(
    name="Health Check Name For Felix Console", 
    mbeanName="JMX Name",
    description="Health Check Description",
    tags={"meetup"}
)

These simple steps allow you to implement HC, executed from Felix console over the path “/system/console/healthcheck”:

Health Checks User Interface

If we open Tools -> Operations -> Dashboard -> Console -> Health Reports (or from the path “/libs/granite/operations/content/healthreports.html”), we will see cards with HC.

To add a custom HC as a card on this dashboard, we need to create a node under the path /apps/granite/operations/config/hc with the following properties:

  • resource{String} – /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/[ hc.name ]
  • sling:resourceType{String} – granite/operations/components/mbean

The Operations dashboard also allows merging HC cards into the groups (as it’s already done for “System Checks” and “Security Checks”). All composite HC configurations are stored within org.apache.sling.hc.core.impl.CompositeHealthCheck factory. To add our custom HC here, we should implement a new configuration to this factory from Felix console or from a configuration file. In the case of Felix console, we need to specify “Name” for HC group and “Filter Tags” so all HC with these tags will be available under this HC card composite on the Operations dashboard.

+1 (438) 383-6878
Give Us a Call

Recommended
blog posts

back to all posts

Apache Sling health checks tools

If we want to use an automated system for live checking and monitoring the current status, performance, and configuration of the AEM application environment, we can opt for OOTB Apache Sling Health Checks Tools.

Below I will explain the basic idea of these tools and demonstrate some simple configuration and customization examples. You will see how UI building is easy and simple to understand.

Problems and goals

Before resolving any AEM application issue, we should check the following points:

  • Required bundles are up and running;
  • Related web services endpoint are available;
  • Required resources and appropriate content structure exist.

All the steps above can be done manually from time to time, but we need to run these validations automatically. This approach will help us monitor the AEM application at a glance.

If we need to build such automation for live checking and monitoring environments, we can use OOTB Apache Sling Health Checks Tools (or HC).

Health Checks at a glance

HC instance is an OSGi service that implements org.apache.sling.hc.api.HealthCheck interface and returns Result according to validate conditions:

public interface HealthCheck {
public Result execute();
}

Result is a simple, immutable class that provides a Status (OK, WARN, CRITICAL, etc.) and one or more log-like messages for additional info.

Note: if you set any Result log message, it will be identified within AEM as WARN. As a result, we should define it as:

new Result(Result.Status.OK, "Some Message")

Health Checks Execution

AEM is a modular system so we have a couple of configuration places for every piece of the system. The HC Executor service is one of these services, which can be configured from “/system/console/configMgr/org.apache.sling.hc.core.impl.executor.HealthCheckExecutorImpl”:

Note: HC Executor executes every HC within the Sling Thread pool, guaranteeing that we have only one running instance at a time.

Custom Health Checks

For individual HC implementation, we should implement interface org.apache.sling.hc.api.HealthCheck first and specify options for service as follows:

@Component(metatype = true)
@Properties({
        @Property(name = HealthCheck.NAME,value = "HCName"),
        @Property(name = HealthCheck.TAGS,value = {"meetup"}),
        @Property(name = HealthCheck.MBEAN_NAME,value = "HCName")
})
@Service(value = {HealthCheck.class})
public class IncorrectLocalhostHC implements HealthCheck {

If HC needs to be executed by the scheduler (once a day, for example), we can specify schedule intervals within properties:

@Property(name = HealthCheck.ASYNC_CRON_EXPRESSION, value = "0 0 12 1/1 * ? *")

The Sling HC core 1.2.6 version will have a new property, “hc.resultCacheTtlInMs”. It overrides the global default TTL as configured in the HC executor for HC responses.

HC can also be configured with annotation @SlingHealthCheck, but it doesn’t work for OOTB in AEM 6.1:

@SlingHealthCheck(
    name="Health Check Name For Felix Console", 
    mbeanName="JMX Name",
    description="Health Check Description",
    tags={"meetup"}
)

These simple steps allow you to implement HC, executed from Felix console over the path “/system/console/healthcheck”:

Health Checks User Interface

If we open Tools -> Operations -> Dashboard -> Console -> Health Reports (or from the path “/libs/granite/operations/content/healthreports.html”), we will see cards with HC.

To add a custom HC as a card on this dashboard, we need to create a node under the path /apps/granite/operations/config/hc with the following properties:

  • resource{String} – /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/[ hc.name ]
  • sling:resourceType{String} – granite/operations/components/mbean

The Operations dashboard also allows merging HC cards into the groups (as it’s already done for “System Checks” and “Security Checks”). All composite HC configurations are stored within org.apache.sling.hc.core.impl.CompositeHealthCheck factory. To add our custom HC here, we should implement a new configuration to this factory from Felix console or from a configuration file. In the case of Felix console, we need to specify “Name” for HC group and “Filter Tags” so all HC with these tags will be available under this HC card composite on the Operations dashboard.

Recommended
blog posts

back to all posts