#AEM

Narzędzia sprawdzania kondycji Apache Sling

Spis treści

Jeśli chcemy używać zautomatyzowanego systemu do sprawdzania i monitorowania w czasie rzeczywistym aktualnego statusu, wydajności i konfiguracji środowiska aplikacji AEM, możemy wybrać narzędzia OOTB Apache Sling Health Checks.

Poniżej wyjaśnię podstawową ideę tych narzędzi i zademonstruję kilka prostych przykładów konfiguracji i dostosowania. Zobaczysz, jak budowanie interfejsu użytkownika jest łatwe i proste do zrozumienia.

Problemy i cele

Przed rozwiązaniem jakiegokolwiek problemu z aplikacją AEM, powinniśmy sprawdzić następujące punkty:

  • Wymagane pakiety są uruchomione i działają;
  • Powiązane punkty końcowe usług sieciowych są dostępne;
  • Wymagane zasoby i odpowiednia struktura treści istnieją.

Wszystkie powyższe kroki można wykonywać ręcznie od czasu do czasu, ale musimy uruchamiać te walidacje automatycznie. Takie podejście pomoże nam monitorować aplikację AEM na pierwszy rzut oka.

Jeśli potrzebujemy zbudować taką automatyzację do sprawdzania i monitorowania środowisk w czasie rzeczywistym, możemy użyć narzędzi OOTB Apache Sling Health Checks (lub HC).

Health Checks w pigułce

Instancja HC to usługa OSGi, która implementuje org.apache.sling.hc.api.HealthCheck interfejs i zwraca Result zgodnie ze sprawdzanymi warunkami:

public interface HealthCheck {
public Result execute();
}

Result to prosta, niezmienna klasa, która dostarcza Status (OK, WARN, CRITICAL, itd.) oraz jedną lub więcej wiadomości przypominających logi dla dodatkowych informacji.

Uwaga: jeśli ustawisz jakąkolwiek wiadomość logu Result, zostanie ona zidentyfikowana w AEM jako WARN. W rezultacie powinniśmy ją zdefiniować jako:

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

Wykonanie Health Checks

AEM to system modułowy, więc mamy kilka miejsc konfiguracji dla każdego elementu systemu. Usługa HC Executor jest jedną z tych usług, którą można skonfigurować z „/system/console/configMgr/org.apache.sling.hc.core.impl.executor.HealthCheckExecutorImpl”:”

Uwaga: HC Executor wykonuje każdy HC w ramach Sling Thread pool, gwarantując, że mamy tylko jedną uruchomioną instancję naraz.

Niestandardowe Health Checks

Dla indywidualnej implementacji HC, powinniśmy najpierw zaimplementować interfejs org.apache.sling.hc.api.HealthCheck i określić opcje dla usługi w następujący sposób:

@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 {

Jeśli HC ma być wykonywany przez harmonogram (na przykład raz dziennie), możemy określić interwały harmonogramu we właściwościach:

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

Wersja Sling HC core 1.2.6 będzie miała nową właściwość, “hc.resultCacheTtlInMs”. Zastępuje ona globalny domyślny czas życia (TTL) skonfigurowany w wykonawcy HC dla odpowiedzi HC.

HC może być również skonfigurowany za pomocą adnotacji @SlingHealthCheck, ale nie działa dla OOTB w AEM 6.1:

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

Te proste kroki pozwalają na implementację HC, wykonywanego z konsoli Felix pod ścieżką “/system/console/healthcheck”:

Interfejs użytkownika Health Checks

Jeśli otworzymy Tools -> Operations -> Dashboard -> Console -> Health Reports (lub ze ścieżki “/libs/granite/operations/content/healthreports.html”), zobaczymy karty z HC.

Aby dodać niestandardowy HC jako kartę na tym pulpicie nawigacyjnym, musimy utworzyć węzeł pod ścieżką /apps/granite/operations/config/hc z następującymi właściwościami:

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

Pulpit nawigacyjny Operations umożliwia również łączenie kart HC w grupy (jak to już zrobiono dla “System Checks” i “Security Checks”). Wszystkie złożone konfiguracje HC są przechowywane w fabryce org.apache.sling.hc.core.impl.CompositeHealthCheck. Aby dodać tutaj nasz niestandardowy HC, powinniśmy zaimplementować nową konfigurację do tej fabryki z konsoli Felix lub z pliku konfiguracyjnego. W przypadku konsoli Felix musimy określić “Name” dla grupy HC i “Filter Tags”, tak aby wszystkie HC z tymi tagami były dostępne w ramach tego złożonego komponentu karty HC na pulpicie nawigacyjnym Operations.

    Porozmawiajmy o Twoim projekcie!
    / 2
    Wszystkie pola oznaczone gwiazdką są obowiązkowe
    Wszystkie pola oznaczone gwiazdką są obowiązkowe
    All fields marked with an asterisk are required
    All fields marked with an asterisk are required
    Check the box
    Success!
    We will contact you by email