Instrumentpanel för åtgärder

Introduktion

På kontrollpanelen för åtgärder i AEM 6 kan systemansvariga övervaka AEM systemhälsan snabbt. Den innehåller även automatiskt genererad diagnos om relevanta aspekter av AEM och gör det möjligt att konfigurera och köra självständig automatisering av underhåll för att avsevärt minska projektdriften och supportärenden. Kontrollpanelen för åtgärder kan utökas med anpassade hälsokontroller och underhållsuppgifter. Data från Operations Dashboard kan dessutom nås från externa övervakningsverktyg via JMX.

Kontrollpanelen för åtgärder:

  • Är en enklicksstatus som hjälper verksamhetstjänsterna att bli effektivare
  • Ger en översikt över systemets hälsa på en central plats
  • Minskar tiden för att hitta, analysera och åtgärda problem
  • Automatisering av underhåll som kan minska projektkostnaderna avsevärt

Den kan nås genom att verktyg - Operationer på AEM välkomstskärm.

OBSERVERA

För att kunna komma åt Operations Dashboard måste den inloggade användaren vara en del av användargruppen Operators. Mer information finns i dokumentationen om Administrering av användare, grupper och åtkomsträttigheter.

Hälsorapporter

I systemet för hälsorapporter finns information om hälsotillståndet i en AEM via Sling Health Checks. Detta kan göras antingen via OSGI, JMX, HTTP-begäranden (via JSON) eller via Touch-gränssnittet. Den erbjuder mått och tröskelvärden för vissa konfigurerbara räknare och ger i vissa fall information om hur problemet kan lösas.

Den har flera funktioner som beskrivs nedan.

Hälsokontroller

The Hälsorapporter är ett kortsystem som anger god eller dålig hälsa med avseende på ett visst produktområde. Dessa kort är visualiseringar av Sling Health Checks, som samlar in data från JMX och andra källor och visar bearbetad information igen som MBeans. Dessa MBeans kan också granskas i JMX-webbkonsol, under org.apache.sling.healthCheck domän.

Du kommer åt gränssnittet Hälsorapporter via verktyg - Operationer - Hälsorapporter på AEM välkomstskärm eller direkt via följande URL:

https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html

chlimage_1-116

Kortsystemet visar tre möjliga lägen: OK, VARNING och KRITISK. Lägen är ett resultat av regler och tröskelvärden, som kan konfigureras genom att du håller muspekaren över kortet och sedan klickar på kugghjulsikonen i åtgärdsfältet:

chlimage_1-117

Typ av hälsokontroll

Det finns två typer av hälsokontroller i AEM 6:

  1. Individuella hälsokontroller
  2. Sammansatta hälsokontroller

An Individuell hälsokontroll är en enda hälsokontroll som motsvarar ett statuskort. Enskilda hälsokontroller kan konfigureras med regler eller tröskelvärden och de kan ge ett eller flera tips och länkar för att lösa identifierade hälsoproblem. Låt oss ta kontrollen "Loggfel" som ett exempel: Om det finns FEL-poster i instansloggarna finns de på informationssidan i hälsokontrollen. Längst upp på sidan finns en länk till "Loggmeddelandeanalyseraren" i avsnittet Diagnosverktyg, där du kan analysera felen mer ingående och konfigurera om loggarna.

A Sammansatt hälsokontroll är en kontroll som sammanställer information från flera enskilda kontroller.

Sammansatta hälsokontroller konfigureras med hjälp av filtertaggar. Alla enskilda kontroller som har samma filtertagg grupperas alltså som en sammansatt hälsokontroll. En sammansatt hälsokontroll har bara OK-status om alla de enskilda kontrollerna också har OK-status.

Så här skapar du hälsokontroller

På kontrollpanelen för åtgärder kan du visualisera resultatet av både individuella och sammansatta hälsokontroller.

Skapa en enskild hälsokontroll

Du skapar en enskild hälsokontroll i två steg: implementera en kontroll av skickningshälsa och lägga till en post för hälsokontrollen på instrumentpanelens konfigurationsnoder.

  1. För att kunna skapa en Sling Health Check måste du skapa en OSGI-komponent som implementerar Sling HealthCheck-gränssnittet. Du lägger till den här komponenten i ett paket. Komponentens egenskaper identifierar hälsokontrollen fullständigt. När komponenten har installerats skapas en JMX MBean automatiskt för hälsokontrollen. Se Dokumentation för hälsokontroll vid segmentering för mer information.

    Exempel på en Sling Health Check-komponent, skriven med OSGI-tjänstkomponentanteckningar:

    @Component(service = HealthCheck.class,
    property = {
        HealthCheck.NAME + "=Example Check",
        HealthCheck.TAGS + "=example",
        HealthCheck.TAGS + "=test",
        HealthCheck.MBEAN_NAME + "=exampleHealthCheckMBean"
    })
     public class ExampleHealthCheck implements HealthCheck {
        @Override
        public Result execute() {
            // health check code
        }
     }
    
    OBSERVERA

    The MBEAN_NAME -egenskapen definierar namnet på den böna som ska genereras för den här hälsokontrollen.

  2. När du har skapat en hälsokontroll måste en ny konfigurationsnod skapas för att den ska bli tillgänglig i gränssnittet för kontrollpanelen för åtgärder. I detta steg är det nödvändigt att känna till JMX-namnet på hälsokontrollen ( MBEAN_NAME egenskap). Om du vill skapa en konfiguration för hälsokontrollen öppnar du CRXDE och lägger till en ny nod (av typen nt:ostrukturerad) under följande sökväg: /apps/settings/granite/operations/hc

    Följande egenskaper ska anges för den nya noden:

    • Namn: sling:resourceType

      • Typ: String
      • Värde: granite/operations/components/mbean
    • Namn: resource

      • Typ: String
      • Värde: /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
    OBSERVERA

    Resurssökvägen ovan skapas enligt följande: Om huvudnamnet för din hälsokontroll är "test" lägger du till "test" i slutet av sökvägen /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck

    Så den sista vägen blir:

    /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test

    OBSERVERA

    Se till att /apps/settings/granite/operations/hc path har följande egenskaper inställda på true:

    sling:configCollectionInherit

    sling:configPropertyInherit

    Detta anger för konfigurationshanteraren att sammanfoga de nya konfigurationerna med de befintliga från /libs.

Skapa en sammansatt hälsokontroll

En sammansatt hälsokontroll har till uppgift att sammanställa ett antal enskilda hälsokontroller som delar en uppsättning gemensamma funktioner. Den sammansatta hälsokontrollen för Säkerhet grupperar till exempel alla enskilda hälsokontroller som utför säkerhetsrelaterade kontroller. Det första steget för att skapa en sammansatt kontroll är att lägga till en ny OSGI-konfiguration. För att den ska kunna visas på kontrollpanelen för åtgärder måste en ny konfigurationsnod läggas till, på samma sätt som vi gjorde för en enkel kontroll.

  1. Gå till Web Configuration Manager i OSGI-konsolen. Du kan göra detta genom att gå till https://serveraddress:port/system/console/configMgr

  2. Sök efter den anropade posten Apache Sling Composite Health Check. Observera att det redan finns två konfigurationer när du har hittat den: en för systemkontrollerna och en annan för säkerhetskontrollerna.

  3. Skapa en ny konfiguration genom att trycka på plusknappen (+) till höger om konfigurationen. Ett nytt fönster visas enligt nedan:

    chlimage_1-23

  4. Skapa en konfiguration och spara den. En böna kommer att skapas med den nya konfigurationen.

    Syftet med varje konfigurationsegenskap är följande:

    • Namn (hc.name): Namnet på den sammansatta hälsokontrollen. Ett beskrivande namn rekommenderas.
    • Taggar (hc.tags): Taggarna för den här hälsokontrollen. Om den här sammansatta hälsokontrollen är avsedd att ingå i en annan sammansatt hälsokontroll (till exempel i en hierarki av hälsokontroller) lägger du till de taggar som den sammansatta kontrollen är relaterad till.
    • MBean-namn (hc.mbean.name): Namnet på den böna som ska ges till JMX MBean för den här sammansatta hälsokontrollen.
    • Filtertaggar (filter.tags): Detta är en egenskap som är specifik för sammansatta hälsokontroller. Det här är de taggar som det sammansatta objektet ska aggregera. Den sammansatta hälsokontrollen sammanfogas under sin grupp med alla hälsokontroller som har en tagg som matchar någon av filtertaggarna i den sammansatta samlingen. En sammansatt hälsokontroll med till exempel filtertaggarna test och check kommer att samla alla individuella och sammansatta hälsokontroller som har någon av test och check taggar i deras taggegenskap ( hc.tags).
    OBSERVERA

    En ny JMX Mbean skapas för varje ny konfiguration av den sammansatta hälsokontrollen för Apache Sling.**

  5. Slutligen måste posten för den sammansatta hälsokontrollen som precis har skapats läggas till i konfigurationsnoderna för kontrollpanelen för åtgärder. Förfarandet för detta är detsamma som för individuella hälsokontroller: en nod av typen nt:ostrukturerad måste skapas under /apps/settings/granite/operations/hc. Resursegenskapen för noden definieras av värdet för hc.ean.name i OSGI-konfigurationen.

    Om du till exempel har skapat en konfiguration och ställt in hc.mbean.name värde till diskus kommer konfigurationsnoderna att se ut så här:

    • Namn: Composite Health Check

      • Typ: nt:unstructured

    Med följande egenskaper:

    • Namn: sling:resourceType

      • Typ: String
      • Värde: granite/operations/components/mbean
    • Namn: resource

      • Typ: String
      • Värde: /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
    OBSERVERA

    Om du skapar enskilda hälsokontroller som logiskt sett hör till en sammansatt kontroll som redan finns på kontrollpanelen som standard, hämtas de automatiskt och grupperas under respektive sammansatta kontroll. På grund av detta behöver du inte skapa en ny konfigurationsnod för dessa kontroller.

    Om du till exempel skapar en enskild säkerhetshälsokontroll behöver du bara tilldela den till säkerhet-taggen, och den är installerad, visas automatiskt under den sammansatta kontrollen Säkerhetskontroller på kontrollpanelen för åtgärder.

Hälsokontroller som tillhandahålls med AEM

zHealthcheck-namn Beskrivning
Frågeprestanda

Den här hälsokontrollen har förenklats i AEM 6.4och nu kontrollerar den nyligen omarbetade Oak QueryStats MBean, mer specifikt SlowQueries -attribut. Om statistiken innehåller långsamma frågor returnerar hälsokontrollen en varning. Annars returneras OK-statusen.

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=queriesStatus,type=HealthCheck.

Längd på observationskö

Längden på observationskön itererar över alla händelseavlyssnare och bakgrundsobservrar och jämför deras queueSize till maxQueueSize och:

  • returnerar Kritisk status om queueSize värdet överskrider maxQueueSize värde (d.v.s. när händelser tas bort)
  • returnerar Varna om queueSize värdet är över maxQueueSize * WARN_THRESHOLD (standardvärdet är 0,75)

Den maximala längden för varje kö kommer från olika konfigurationer (Oak och AEM) och kan inte konfigureras från den här hälsokontrollen. MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck.

Gränser för genomgång av frågor

Gränser för frågesport kontrollerar QueryEngineSettings MBean, mer specifikt LimitInMemory och LimitReads och returnerar följande status:

  • returnerar varningsstatus om en av gränserna är lika med eller högre än Integer.MAX_VALUE
  • returnerar Warn-status om en av gränserna är lägre än 10000 (den rekommenderade inställningen från Oak)
  • returnerar statusen Kritisk om QueryEngineSettings eller någon av gränserna inte kan hämtas

The Mbean for this health check is org.apache.sling.healthCheck:name=queryTraversalLimitsBundle,type=HealthCheck.

Synkroniserade klockor

Den här kontrollen gäller endast för dokumentnodestore-kluster. Den returnerar följande status:

  • returnerar Warn-status när instansklockorna inte är synkroniserade och går över ett fördefinierat lågt tröskelvärde
  • returnerar statusen Kritisk när instansklockorna inte är synkroniserade och går över ett fördefinierat högt tröskelvärde

The Mbean for this health check is org.apache.sling.healthCheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck.

Asynkrona index

Kontrollen Asynkrona index:

  • returnerar Kritisk status om minst ett indexeringsfält misslyckas
  • kontrollerar lastIndexedTime för alla indexeringsbanor och
    • returnerar Kritisk status om det är mer än 2 timmar sedan
    • returnerar varningsstatus om det är mellan 2 timmar och 45 minuter sedan
    • returnerar OK-status om det är mindre än 45 minuter sedan
  • om inget av dessa villkor uppfylls returneras OK-statusen

Både statuströskelvärdena Kritisk och Varna är konfigurerbara. The Mbean for this health check is org.apache.sling.healthCheck:name=asyncIndexHealthCheck,type=HealthCheck.

Obs! Den här hälsokontrollen är tillgänglig i AEM 6.4 och har flyttats tillbaka till AEM 6.3.0.1.

Stora Lucene-index

Den här kontrollen använder data som exponeras av Lucene Index Statistics MBean för att identifiera stora index och returnera:

  • en varningsstatus om det finns ett index med mer än 1 miljard dokument
  • en kritisk status om det finns ett index med mer än 1,5 miljarder dokument

Tröskelvärdena kan konfigureras och MBean för hälsokontrollen är org.apache.sling.healthCheck:name=largeIndexHealthCheck,type=HealthCheck.

Obs! Den här kontrollen är tillgänglig i AEM 6.4 och har flyttats tillbaka till AEM 6.3.2.0.

Systemunderhåll

Systemunderhåll är en sammansatt kontroll som returnerar OK om alla underhållsåtgärder körs som de är konfigurerade. Kom ihåg att:

  • varje underhållsåtgärd åtföljs av en tillhörande hälsokontroll
  • Om en uppgift inte läggs till i ett underhållsfönster returneras den kritiska hälsokontrollen
  • du måste konfigurera underhållsaktiviteterna Granskningslogg och Arbetsflödestömning eller på annat sätt ta bort dem från underhållsfönstren. Om de inte konfigureras kommer dessa uppgifter att misslyckas vid den första körningen, så systemunderhållskontrollen returnerar statusen Kritisk.
  • Med AEM 6.4, finns det också en kontroll för Lucene Binaries-underhåll uppgift
  • på AEM 6.2 och lägre returnerar systemunderhållskontrollen en varningsstatus direkt efter start eftersom aktiviteterna aldrig körs. Från och med 6.3 returneras OK om det första underhållet inte har nåtts än.

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=systemchecks,type=HealthCheck.

Replikeringskö

Den här kontrollen itererar över replikeringsagenter och tittar på deras köer. För objektet högst upp i kön kontrolleras hur många gånger agenten försökte replikera på nytt. Om agenten gjorde ett nytt försök att replikera mer än värdet för numberOfRetriesAllowed returnerar den en varning. The numberOfRetriesAllowed parametern kan konfigureras.

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=replicationQueue,type=HealthCheck.

Försäljningsjobb
Sling Jobs kontrollerar antalet jobb som köas i JobManager, jämför det med maxNumQueueJobs och
  • returnerar Critical om mer än maxNumQueueJobs finns i kön
  • returnerar Kritisk om det finns aktiva jobb som körs länge och är äldre än 1 timme
  • returnerar Kritisk om det finns jobb i kö och den senaste slutförda jobbtiden är äldre än 1 timme

Endast parametern för maximalt antal jobb i kö kan konfigureras och har standardvärdet 1 000.

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=slingJobs,type=HealthCheck.

Begär prestanda

Den här kontrollen tittar på granite.request.metrics.timer Sling-mått och:

  • returnerar Kritisk om det 75:e percentilvärdet överstiger det kritiska tröskelvärdet (standardvärdet är 500 millisekunder)
  • returnerar Varna om det 75:e percentilvärdet överstiger varningströskeln (standardvärdet är 200 millisekunder)

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=requestsStatus,type=HealthCheck.

Loggfel

Den här kontrollen returnerar varningsstatus om loggen innehåller fel.

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=logErrorHealthCheck,type=HealthCheck.

Diskutrymme

Kontrollen av diskutrymme finns på FileStoreStats MBean, hämtar storleken på nodarkivet och hur mycket diskutrymme som kan användas på partitionen Node Store, och:

  • returnerar Varna om det tillgängliga diskutrymmet till databasstorleken är mindre än varningströskeln (standardvärdet är 10)
  • returnerar Kritisk om det användbara diskutrymmet till databasstorleken är mindre än det kritiska tröskelvärdet (standardvärdet är 2)

Båda tröskelvärdena kan konfigureras. Kontrollen fungerar bara på instanser med ett segmentlager.

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=DiskSpaceHealthCheck,type=HealthCheck.

Hälsokontroll för schemaläggare

Den här kontrollen returnerar en varning om instansen har Quartz-jobb som körs i mer än 60 sekunder. Tröskelvärdet för acceptabel varaktighet kan konfigureras.

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheck.

Säkerhetskontroller

Säkerhetskontrollen är en sammansatt kontroll som sammanställer resultaten av flera säkerhetsrelaterade kontroller. Dessa individuella hälsokontroller tar upp andra problem än checklistan för säkerhet som finns på Dokumentationssida för checklista för säkerhet. Kontrollen är användbar som säkerhetsröktest när instansen startas.

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=securityCheck,type=HealthCheck

Aktiva paket

Active Bundles kontrollerar statusen för alla paket och:

  • returnerar Warn-status om något av paketen inte är aktivt eller (med start, med lat aktivering)
  • ignorerar paketens status i ignoreringslistan

Parametern för ignoreringslistan kan konfigureras.

MBean för den här hälsokontrollen är org.apache.sling.hälsokontroll:name=inactiveBundles,type=HealthCheck.

Kontroll av kodcache

Det här är en hälsokontroll som verifierar flera JVM-villkor som kan utlösa ett CodeCache-fel i Java 7:

  • returnerar Varna om instansen körs på Java 7, med tömning av kodcache aktiverat
  • returnerar Varna om instansen körs på Java 7 och storleken på den reserverade kodcachen är mindre än ett minimitröskelvärde (standardvärdet är 90 MB)

The minimum.code.cache.size Tröskelvärdet kan konfigureras. Mer information om felet finns i check den här sidan.

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=codeCacheHealthCheck,type=HealthCheck.

Sökvägsfel för resurssökning

Kontrollerar om det finns några resurser i sökvägen /apps/foundation/components/primary och:

  • returnerar Varna om det finns underordnade noder under /apps/foundation/components/primary

MBean för den här hälsokontrollen är org.apache.sling.healthCheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck.

Konfiguration av hälsokontroll

Som standard körs hälsokontrollerna var 60:e sekund för en AEM.

Du kan konfigurera Period med OSGi-konfiguration Konfiguration av hälsokontroll av fråga (com.adobe.granite.queries.impl.hc.QueryHealthCheckMetrics).

Övervakning med Nagios

Kontrollpanelen för hälsokontroll kan integreras med Nagios via Granite JMX Mbeans. I följande exempel visas hur du lägger till en kontroll som visar hur mycket minne som används på AEM.

  1. Installera och installera Nagios på övervakningsservern.

  2. Installera sedan Nagios Remote Plugin Executor (NRPE).

    OBSERVERA

    Mer information om hur du installerar Nagios och NRPE på datorn finns i Nagios-dokumentation.

  3. Lägg till en värddefinition för AEM. Detta kan göras via webbgränssnittet för Nagios XI med hjälp av Configuration Manager:

    1. Öppna en webbläsare och peka på Nagios-servern.
    2. Tryck på Konfigurera på den översta menyn.
    3. Tryck på Core Config Manager under Avancerad konfiguration.
    4. Tryck på Värdar länk under Övervakning -avsnitt.
    5. Lägg till värddefinitionen:

    chlimage_1-118

    Nedan visas ett exempel på en värdkonfigurationsfil, om du använder Nagios Core:

    define host {
       address 192.168.0.5
       max_check_attempts 3
       check_period 24x7
       check-command check-host-alive
       contacts admin
       notification_interval 60
       notification_period 24x7
    }
    
  4. Installera Nagios och NRPE på AEM.

  5. Installera check_http_json plugin-program på båda servrarna.

  6. Definiera ett generiskt JSON-kontrollkommando på båda servrarna:

    define command{
    
        command_name    check_http_json-int
    
        command_line    /usr/lib/nagios/plugins/check_http_json --user "$ARG1$" --pass "$ARG2$" -u 'https://$HOSTNAME$:$ARG3$/$ARG4$' -e '$ARG5$' -w '$ARG6$' -c '$ARG7$'
    
    }
    
  7. Lägg till en tjänst för använt minne på AEM:

    define service {
    
        use generic-service
    
        host_name my.remote.host
    
        service_description AEM Author Used Memory
    
        check_command  check_http_json-int!<cq-user>!<cq-password>!<cq-port>!system/sling/monitoring/mbeans/java/lang/Memory.infinity.json!{noname}.mbean:attributes.HeapMemoryUsage.mbean:attributes.used.mbean:value!<warn-threshold-in-bytes>!<critical-threshold-in-bytes>
    
        }
    
  8. Kontrollera din Nagios-instrumentpanel för den nya tjänsten:

    chlimage_1-119

Diagnosverktyg

Kontrollpanelen för åtgärder ger även tillgång till diagnosverktyg som kan hjälpa dig att hitta och felsöka grundorsaker till varningarna från kontrollpanelen för hälsokontroll samt tillhandahålla viktig felsökningsinformation för systemoperatorer.

Bland de viktigaste funktionerna finns:

  • En loggmeddelandeanalyserare
  • Möjlighet att komma åt stackar och tråddumpar
  • Begäranden och frågeprestandaanalyser

Du kan nå skärmen Diagnosverktyg genom att gå till Verktyg - Åtgärder - diagnostik på AEM välkomstskärm. Du kan även få åtkomst till skärmen via följande URL: https://serveraddress:port/libs/granite/operations/content/diagnosis.html

chlimage_1-120

Loggmeddelanden

Loggmeddelandena Användargränssnittet visar som standard alla FELmeddelanden. Om du vill att fler loggmeddelanden ska visas måste du konfigurera en loggare med rätt loggnivå.

Loggmeddelandena använder ett tillägg i minnesloggen och är därför inte relaterade till loggfilerna. En annan konsekvens är att om du ändrar loggnivåerna i det här användargränssnittet ändras inte den information som loggas i de traditionella loggfilerna. Om du lägger till och tar bort loggare i det här användargränssnittet påverkas bara loggen i minnet. Observera också att ändringar av loggningskonfigurationerna kommer att återspeglas i framtiden för minnesloggen. De poster som redan är loggade och inte längre är relevanta tas inte bort, men liknande poster kommer inte att loggas i framtiden.

Du kan konfigurera vad som loggas genom att tillhandahålla loggkonfigurationer från den övre vänstra kugghjulsknappen i användargränssnittet. Där kan du lägga till, ta bort eller uppdatera loggkonfigurationer. En loggningskonfiguration består av en loggnivå (VARNA / INFO / DEBUG) och filternamn. The filternamn har rollen som att filtrera källan för loggmeddelanden som loggas. Om en loggare däremot ska samla in alla loggmeddelanden för den angivna nivån ska filternamnet vara "root". Om du ställer in en loggningsnivå aktiveras fångandet av alla meddelanden med en nivå som är lika med eller högre än den angivna.

Exempel:

  • Om du planerar att hämta alla FEL meddelanden - ingen konfiguration krävs. Alla FELmeddelanden hämtas som standard.

  • Om du planerar att hämta alla FEL, VARNING och INFORMATION meddelanden - loggningsnamnet ska anges till: "root" och loggningsnivån till: INFORMATION.

  • Om du planerar att hämta alla meddelanden som kommer från ett visst paket (till exempel com.adobe.granite) ska loggningsnamnet anges till: "com.adobe.granite" och loggningsnivån till: FELSÖKNING (detta fångar alla FEL, VARNING, INFORMATION och FELSÖKNING som visas i bilden nedan.

chlimage_1-121

OBSERVERA

Du kan inte ställa in ett loggningsnamn så att endast FELMEDDELANDEN hämtas via ett angivet filter. Som standard hämtas alla FELMEDDELANDEN.

OBSERVERA

Användargränssnittet för loggmeddelanden återspeglar inte den faktiska felloggen. Såvida du inte konfigurerar andra typer av loggmeddelanden i användargränssnittet visas endast FELmeddelanden. Mer information om hur du visar specifika loggmeddelanden finns i instruktionerna ovan.

OBSERVERA

Inställningarna på diagnossidan påverkar inte loggfilerna och vice versa. Så även om felloggen kan fånga upp INFO-meddelanden kanske du inte ser dem i användargränssnittet för loggmeddelanden. Via gränssnittet går det också att fånga upp DEBUG-meddelanden från vissa paket utan att det påverkar felloggen. Mer information om hur du konfigurerar loggfilerna finns i Loggning.

OBSERVERA

Med AEM 6.4, loggas underhållsaktiviteter ut ur kartongen i ett mer informationsformat på INFO-nivå. Det gör att underhållsaktiviteternas status blir mer synlig.

Om du använder verktyg från tredje part (till exempel Splunk) för att övervaka och reagera på underhållsaktiviteter kan du använda följande loggsatser:

Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>

Begär prestanda

På sidan Prestandabegäran kan du analysera de långsammaste sidbegäranden som behandlas. Endast innehållsbegäranden registreras på den här sidan. Mer specifikt kommer följande förfrågningar att hämtas:

  1. Begäranden om åtkomst till resurser under /content
  2. Begäranden om åtkomst till resurser under /etc/design
  3. Begäranden med ".html" extension

chlimage_1-122

Sidan visar:

  • Tiden då begäran gjordes
  • URL:en och förfrågningsmetoden
  • Längden i millisekunder

Som standard hämtas de långsammaste 20 sidbegäranden, men gränsen kan ändras i Configuration Manager.

Frågeprestanda

På sidan Frågeprestanda kan du analysera de långsammaste frågorna som har utförts av systemet. Denna information tillhandahålls av databasen i en JMX Mbean. I Jackrabbit com.adobe.granite.QueryStat JMX Mbean lämnar denna information, medan den i Oak-databasen erbjuds av org.apache.jackrabbit.oak.QueryStats.

Sidan visar:

  • Tidpunkten då frågan gjordes
  • Frågans språk
  • Antal gånger frågan utfärdades
  • Frågeinstruktionen
  • Längden i millisekunder

chlimage_1-123

Förklara fråga

För varje given fråga försöker Oak hitta det bästa sättet att köra baserat på de Oak-index som definieras i databasen under oak:index nod. Oak kan välja olika index beroende på frågan. Att förstå hur Oak kör en fråga är det första steget till att optimera frågan.

Förklara frågan är ett verktyg som förklarar hur Oak kör en fråga. Den kan nås genom att Verktyg - Åtgärder - diagnostik från AEM välkomstskärm och sedan klicka på Frågeprestanda och gå över till Förklara fråga -fliken.

Funktioner

  • Stöder frågespråken Xpath, JCR-SQL och JCR-SQL2
  • Rapporterar den faktiska körningstiden för den angivna frågan
  • Identifierar långsamma frågor och varningar om frågor som kan vara långsamma
  • Rapporterar Oak-indexet som används för att köra frågan
  • Visar den faktiska förklaringen till Oak Query-motorn
  • Innehåller klickbar-för-inläsningslista med långsamma och populära frågor

När du är i användargränssnittet för enkla frågor behöver du bara skriva in frågan och trycka på Förklara knapp:

chlimage_1-124

Den första posten i avsnittet Frågeförklaring är den faktiska förklaringen. Förklaringen visar vilken typ av index som användes för att köra frågan.

Den andra posten är körningsplanen.

Kickar Inkludera körningstid innan frågan körs visas även hur lång tid frågan kördes i. The Inkludera nodantal Alternativet rapporterar nodantalet. På så sätt kan du få mer information som kan användas för att optimera indexen för ditt program eller din distribution.

chlimage_1-125

Indexhanteraren

Syftet med indexhanteraren är att underlätta indexhantering, t.ex. att underhålla index eller visa deras status.

Du kommer åt den genom att gå till Verktyg - Åtgärder - Diagnos ​ från välkomstskärmen och sedan klicka på Indexhanteraren -knappen.

Den kan också nås direkt på den här URL:en: https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html

index_manager

Gränssnittet kan användas för att filtrera index i tabellen genom att skriva in filtervillkoren i sökrutan i skärmens övre vänstra hörn.

Download Status ZIP

Detta aktiverar nedladdningen av en zip som innehåller användbar information om systemstatus och konfiguration. Arkivet innehåller instanskonfigurationer, en lista över paket, OSGI, Sling-statistik och statistik. Detta kan resultera i en stor fil. Du kan minska effekten av stora statusfiler genom att använda Download Status ZIP-fönstret. Du kommer åt fönstret från:AEM > Verktyg > Åtgärder > Diagnostik > Download Status ZIP.

I det här fönstret kan du välja vad som ska exporteras (loggfiler och/eller tråddumpar) och antalet loggdagar som ska inkluderas i hämtningen i förhållande till det aktuella datumet.

download_status_zip

Ladda ned tråddump

Då laddas en zip-fil ned som innehåller information om trådarna i systemet. Information om varje tråd anges, t.ex. dess status, klassinläsaren och stackspårningen.

Ladda ned Heap Dump

Du kan också hämta en ögonblicksbild av heap för att kunna analysera den vid ett senare tillfälle. Observera att detta kommer att starta nedladdningen av en stor fil, i storleksordningen hundratals megabyte.

Automatiserade underhållsuppgifter

Sidan Automatiserade underhållsaktiviteter är en plats där du kan visa och spåra rekommenderade underhållsaktiviteter som schemalagts för periodisk körning. Uppgifterna integreras med systemet för hälsokontroll. Uppgifterna kan också utföras manuellt från gränssnittet.

Om du vill gå till sidan för underhåll på kontrollpanelen för drift måste du gå till Verktyg - Drift - Kontrollpanel - Underhåll från AEM välkomstskärm, eller följ den här länken direkt:

https://serveraddress:port/libs/granite/operations/content/maintenance.html

Följande åtgärder är tillgängliga på kontrollpanelen för åtgärder:

  1. The Rensa version uppgift, som finns under Daglig underhållsperiod -menyn.
  2. The Lucene Binaries Cleanup uppgift, som finns under Daglig underhållsperiod -menyn.
  3. The Rensa arbetsflöde uppgift, som finns under Underhållsfönster varje vecka -menyn.
  4. The Skräpinsamling för datalager uppgift, som finns under Underhållsfönster varje vecka -menyn.
  5. The Underhåll av granskningslogg uppgift, som finns under Underhållsfönster varje vecka -menyn.
  6. The Underhåll av versionsrensning uppgift, som finns under Underhållsfönster varje vecka -menyn.

Standardtiden för det dagliga underhållet är 2 till 5 AM. De uppgifter som konfigurerats för att köras varje vecka i underhållsperioden körs mellan 1 och 2.00 på lördagar.

Du kan också konfigurera timinginställningarna genom att trycka på kugghjulsikonen på något av de två underhållskorten:

chlimage_1-126

OBSERVERA

Sedan AEM 6.1 kan de befintliga underhållsfönstren även konfigureras att köras månadsvis.

Rensa version

Mer information om Revision Clean Up finns här: se den här dedikerade artikeln.

Lucene Binaries Cleanup

Genom att använda rensningsaktiviteten för Lucene-binärfiler kan du rensa bort lucene-binärfiler och minska storlekskraven för det datalager som körs. Detta beror på att lucens binära urn återanvänds dagligen i stället för att det tidigare beroendet av en lyckad skräpinsamling för datalager kör.

Även om underhållsarbetet utvecklades för att minska Lucene-relaterat revisionsskräp, finns det allmänna effektivitetsvinster när uppgiften körs:

  • Den veckovisa körningen av skräpinsamlingen för datalagret slutförs snabbare
  • Den kan också förbättra AEM prestanda något

Du kommer åt aktiviteten Rensa Lucene-binärfiler från: AEM > Tools > Operations > Maintenance > Daily Maintenance Window > Lucene Binaries Cleanup.

Skräpinsamling för datalager

Mer information om skräpinsamlingen i datalagret finns i den dedikerade dokumentsida.

Rensa arbetsflöde

Arbetsflöden kan också rensas från kontrollpanelen för underhåll. För att kunna köra aktiviteten Rensa arbetsflöde måste du:

  1. Klicka på Underhållsfönster varje vecka sida.
  2. På följande sida klickar du på Spela upp i Rensa arbetsflöde kort.
OBSERVERA

Mer information om underhåll av arbetsflöden finns i den här sidan.

Underhåll av granskningslogg

Mer information om underhåll av granskningslogg finns i separat dokumentationssida.

Rensa version

Du kan schemalägga underhållsaktiviteten Rensa version så att tidigare versioner tas bort automatiskt. Detta minimerar behovet av att manuellt använda Verktyg för versionsrensning. Du kan schemalägga och konfigurera aktiviteten Rensa version genom att gå till Verktyg > Åtgärder > Underhåll > Fönster för veckounderhåll och följande steg:

  1. Klicka på Lägg till -knappen.

  2. Välj Rensa version i listrutan.

    version_purge_MaintenanceMetask

  3. Klicka på knappen växlar ikonen på det nya underhållskortet för versionsrensning.

    version_purge_taskconfiguration

Med AEM 6.4 kan du stoppa underhållsaktiviteten Rensa version enligt följande:

  • Automatiskt - Om det schemalagda underhållsfönstret stängs innan aktiviteten kan slutföras stoppas aktiviteten automatiskt. Den återupptas när nästa underhållsfönster öppnas.
  • Manuellt - Om du vill stoppa aktiviteten manuellt går du till underhållskortet för versionsrensning och klickar på Stoppa ikon. Nästa körning innebär att uppgiften återupptas.
OBSERVERA

Att stoppa underhållsaktiviteten innebär att avbryta körningen utan att förlora spårning av det pågående jobbet.

FÖRSIKTIGHET

För att optimera databasstorleken bör du köra versionsrensningen ofta. Uppgiften bör schemaläggas utanför kontorstid när trafiken är begränsad.

Anpassade underhållsaktiviteter

Anpassade underhållsåtgärder kan implementeras som OSGi-tjänster. Eftersom infrastrukturen för underhållsaktiviteter baseras på Apache Slings jobbhantering måste en underhållsaktivitet implementera java-gränssnittet [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html). Dessutom måste den deklarera flera egenskaper för serviceregistrering som ska identifieras som en underhållsuppgift enligt nedan:

Tjänstegenskapsnamn
Beskrivning Exempel
Typ
granite.maintenance.isStoppable Booleskt attribut som definierar om aktiviteten kan stoppas av användaren. Om en uppgift deklarerar att den kan avbrytas måste den under körningen kontrollera om den har stoppats och sedan vidta åtgärder i enlighet med detta. Standardvärdet är false. true Valfritt
granite.maintenance.mandatory Booleskt attribut som definierar om en uppgift är obligatorisk och måste köras regelbundet. Om en uppgift är obligatorisk men inte finns i något aktivt schemafönster visas en hälsokontroll som ett fel. Standardvärdet är false. true Valfritt
granite.maintenance.name Ett unikt namn för aktiviteten - det används för att referera till uppgiften. Det här är vanligtvis ett enkelt namn. MyMaintenanceTask Krävs
granite.maintenance.title En titel som visas för den här uppgiften Min speciella underhållsuppgift Krävs
job.topics Detta är ett unikt ämne i underhållsaktiviteten.
Jobbhanteringen i Apache Sling startar ett jobb med exakt det här avsnittet för att utföra underhållsaktiviteten. När aktiviteten registreras för det här avsnittet körs den.
Ämnet måste börja med com/adobe/granite/Maintenance/job/
com/adobe/granite/Maintenance/job/MyMaintenanceTask Krävs

Förutom de ovanstående tjänstegenskaperna finns följande process() metoden JobConsumer -gränssnittet måste implementeras genom att lägga till koden som ska köras för underhållsuppgiften. Angiven JobExecutionContext kan användas för att visa statusinformation, kontrollera om jobbet har stoppats av användaren och skapa ett resultat (om det lyckades eller misslyckades).

I situationer där en underhållsuppgift inte ska köras på alla installationer (till exempel bara på publiceringsinstansen) kan du få tjänsten att kräva en konfiguration för att kunna aktiveras genom att lägga till @Component(policy=ConfigurationPolicy.REQUIRE). Du kan sedan markera konfigurationen som körningsläge beroende i databasen. Mer information finns i Konfigurerar OSGi.

Nedan visas ett exempel på en anpassad underhållsåtgärd som tar bort filer från en konfigurerbar tillfällig katalog som har ändrats under de senaste 24 timmarna:

src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java

/*

* #%L

* sample-maintenance-task

* %%

* Copyright (C) 2014 Adobe

* %%

* Licensed under the Apache License, Version 2.0 (the "License");

* you may not use this file except in compliance with the License.

* You may obtain a copy of the License at

*

* https://www.apache.org/licenses/LICENSE-2.0

*

* Unless required by applicable law or agreed to in writing, software

* distributed under the License is distributed on an "AS IS" BASIS,

* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

* See the License for the specific language governing permissions and

* limitations under the License.

* #L%

*/

package com.adobe.granite.samples.maintenance.impl;

import java.io.File;

import java.util.Calendar;

import java.util.Collection;

import java.util.Map;

import org.apache.commons.io.FileUtils;

import org.apache.commons.io.filefilter.IOFileFilter;

import org.apache.commons.io.filefilter.TrueFileFilter;

import org.apache.felix.scr.annotations.Activate;

import org.apache.felix.scr.annotations.Component;

import org.apache.felix.scr.annotations.Properties;

import org.apache.felix.scr.annotations.Property;

import org.apache.felix.scr.annotations.Service;

import org.apache.sling.commons.osgi.PropertiesUtil;

import org.apache.sling.event.jobs.Job;

import org.apache.sling.event.jobs.consumer.JobConsumer;

import org.apache.sling.event.jobs.consumer.JobExecutionContext;

import org.apache.sling.event.jobs.consumer.JobExecutionResult;

import org.apache.sling.event.jobs.consumer.JobExecutor;

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

import com.adobe.granite.maintenance.MaintenanceConstants;

@Component(metatype = true,

label = "Delete Temp Files Maintenance Task",

description = "Maintatence Task which deletes files from a configurable temporary directory which have been modified in the last 24 hours.")

@Service

@Properties({

@Property(name = MaintenanceConstants.PROPERTY_TASK_NAME, value = "DeleteTempFilesTask", propertyPrivate = true),

@Property(name = MaintenanceConstants.PROPERTY_TASK_TITLE, value = "Delete Temp Files", propertyPrivate = true),

@Property(name = JobConsumer.PROPERTY_TOPICS, value = MaintenanceConstants.TASK_TOPIC_PREFIX

+ "DeleteTempFilesTask", propertyPrivate = true) })

public class DeleteTempFilesTask implements JobExecutor {

private static final Logger log = LoggerFactory.getLogger(DeleteTempFilesTask.class);

@Property(label = "Temporary Directory", description="Temporary Directory. Defaults to the java.io.tmpdir system property.")

private static final String PROP_TEMP_DIR = "temp.dir";

private File tempDir;

@Activate

private void activate(Map<string, object=""> properties) {

this.tempDir = new File(PropertiesUtil.toString(properties.get(PROP_TEMP_DIR),

System.getProperty("java.io.tmpdir")));

}

@Override

public JobExecutionResult process(Job job, JobExecutionContext context) {

log.info("Deleting old temp files from {}.", tempDir.getAbsolutePath());

Collection<file> files = FileUtils.listFiles(tempDir, new LastModifiedBeforeYesterdayFilter(),

TrueFileFilter.INSTANCE);

int counter = 0;

for (File file : files) {

log.debug("Deleting file {}.", file.getAbsolutePath());

counter++;

file.delete();

// TODO - capture the output of delete() and do something useful with it

}

return context.result().message(String.format("Deleted %s files.", counter)).succeeded();

}

/**

* IOFileFilter which filters out files which have been modified in the last 24 hours.

*

*/

private static class LastModifiedBeforeYesterdayFilter implements IOFileFilter {

private final long minTime;

private LastModifiedBeforeYesterdayFilter() {

Calendar cal = Calendar.getInstance();

cal.add(Calendar.DATE, -1);

this.minTime = cal.getTimeInMillis();

}

@Override

public boolean accept(File dir, String name) {

// this method is never actually called.

return false;

}

@Override

public boolean accept(File file) {

return file.lastModified() <= this.minTime;

}

}

}

<file></string,>

experience-anager-java-MaintenanceMetask-sample- src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java

När tjänsten har distribuerats visas den i gränssnittet för kontrollpanelen för åtgärder. Du kan lägga till den i något av de tillgängliga underhållsschemana:

chlimage_1-127

Detta lägger till en motsvarande resurs på /apps/granite/operations/config/Maintenance/schedule/taskname. Om aktiviteten är beroende av körningsläge måste egenskapen granite.operations.conditions.runmode anges på den noden med värdena för de körningslägen som måste vara aktiva för den här underhållsaktiviteten.

Systemöversikt

The Kontrollpanel för systemöversikt visar en översikt på hög nivå över konfiguration, maskinvara och hälsa för AEM. Detta innebär att systemets hälsostatus är transparent och att all information samlas på en enda kontrollpanel.

OBSERVERA

Du kan också se den här videon om du vill få en introduktion till kontrollpanelen för systemöversikt.

Åtkomst

Om du vill komma åt kontrollpanelen för systemöversikt går du till Verktyg > Åtgärder > Systemöversikt.

system_overview_dashboard

Kontrollpanelen för systemöversikt förklaras

I tabellen nedan beskrivs all information som visas på kontrollpanelen för systemöversikt. Tänk på att om det inte finns någon relevant information att visa (t.ex. om säkerhetskopiering inte pågår, finns det inga hälsokontroller som är kritiska) visas meddelandet"Inga poster" i respektive avsnitt.

Du kan även hämta en JSON fil som sammanfattar instrumentpanelsinformationen genom att klicka på Hämta i det övre högra hörnet av instrumentpanelen.The JSON slutpunkten är /libs/granite/operations/content/systemoverview/export.json och kan användas i en curl skript för extern övervakning.

Avsnitt Vilken information som visas När är det viktigt? Länkar till
Hälsokontroller
  • en lista över kontroller som har statusen Kritisk
  • en lista över kontroller som har statusen Varna
Visuellt:
  • en röd tagg för kritiska kontroller
  • en orange tagg för Warn-kontroller
  • Sidan Hälsorapporter
Underhållsåtgärder
  • en lista över misslyckade uppgifter
  • en lista över aktiviteter som körs
  • en lista över åtgärder som har slutförts i den senaste körningen
  • en lista över uppgifter som aldrig har körts
  • en lista över aktiviteter som inte är schemalagda

Visuellt:

  • en röd tagg för misslyckade uppgifter
  • en orange tagg för att köra uppgifter (eftersom de kan påverka prestandan)
  • grå taggar för varannan status
  • Underhållsaktiviteter
System
  • operativsystem och OS-version (till exempel Mac OS X)
  • systemets genomsnittliga belastning, som hämtats från OperatingSystemMXBeusable
  • diskutrymme (på partitionen där arbetskatalogen finns)
  • maximal heap, som returneras av MemoryMXBean
Ej tillämpligt Ej tillämpligt
Instans
  • AEM
  • lista över körningslägen
  • det datum då instansen startades
Ej tillämpligt Ej tillämpligt
Databas
  • Oak-versionen
  • typ av nodarkiv (Segmentmål eller dokument)
    • om typen är dokument, visas typen av dokumentarkiv (RDB eller Mongo)
  • om det finns ett anpassat datalager:
    • för ett fildatalager visas sökvägen
    • för ett S3-datalager visas namnet på S3-bucket
    • för ett delat S3-datalager visas namnet på S3-bucket
    • för ett Azure Data Store visas behållaren
  • om det inte finns något anpassat externt datalager visas ett meddelande som anger detta
Ej tillämpligt Ej tillämpligt
Distributionsagenter
  • en lista över agenter med blockerade köer
  • en lista över felkonfigurerade agenter ("Konfigurationsfel")
  • en lista över agenter med köbearbetning pausad
  • en lista över inaktiva agenter
  • en lista över agenter som körs (som för närvarande bearbetar poster)

Visuellt:

  • en röd tagg för blockerade agenter eller konfigurationsfel
  • en orange tagg för pausade agenter
  • en grå tagg för pausade, inaktiva eller aktiva agenter
Distributionssida
Replikeringsagenter
  • en lista över agenter med blockerade köer
  • en lista över inaktiva agenter
  • en lista över agenter som körs (som för närvarande bearbetar poster)

Visuellt:

  • en röd tagg för blockerade agenter
  • en grå tagg för pausade agenter
Replikeringssida
Arbetsflöden
  • Arbetsflödesjobb:
    • antal misslyckade arbetsflödesjobb (om sådana finns)
    • antal avbrutna arbetsflödesjobb (om sådana finns)
  • Antal arbetsflöden - antal arbetsflöden i en viss status (om sådana finns):
    • körs
    • misslyckades
    • pausad
    • avbruten

För vart och ett av de statusvärden som anges ovan utförs en fråga, med en gräns på 400 millisekunder. Vid 400 millisekunder visas antalet poster fram till den punkten.

Ej tolkad:

  • användaren bör undersöka när det finns arbetsflöden och jobb i oväntade statusvärden.
Sidan med arbetsflödesfel
Försäljningsjobb

Antal jobb vid körning - antal jobb med en given status (om sådana finns):

  • misslyckades
  • köad
  • avbruten
  • aktiv

Ej tolkad:

  • användaren bör undersöka när det finns jobb i oväntade statusvärden eller med höga räkningar.
Ej tillämpligt
Beräknat nodantal

Uppskattat antal:

  • sidor
  • resurser
  • taggar
  • auktoriszables
  • totalt antal noder

Det totala antalet noder hämtas från nodeCounterMBean, medan resten av statistiken hämtas från IndexInfoService.

Ej tillämpligt Ej tillämpligt
Säkerhetskopiering Visar "Onlinesäkerhetskopiering pågår" om så är fallet. Ej tillämpligt Ej tillämpligt
Indexering

Skärmar:

  • "Indexering pågår"
  • "Fråga pågår"

Om det finns en indexerings- eller frågetråd i tråddumpen.

Ej tillämpligt Ej tillämpligt

På denna sida