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 att du kan 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 enklickssystemstatus 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.

Hälsorapporter

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

Den har flera funktioner som beskrivs nedan.

Hälsokontroller

The Hälsorapporter är ett kortsystem som indikerar god eller dålig hälsa i 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

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:

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 exempel: om det finns FEL-poster i instansloggarna kan du hitta dem på informationssidan i hälsokontrollen. Längst upp på sidan finns en länk till analysverktyget för loggmeddelanden i avsnittet Diagnosverktyg, där du kan analysera felen mer i detalj 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 statusen OK om alla enskilda kontroller som den sammanställer 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

Att skapa en enskild hälsokontroll består av två steg: implementera en hälsokontroll vid enkel inloggning och lägga till en post för hälsokontrollen på kontrollpanelens konfigurationsnoder.

1. Skapa en OSGI-komponent som implementerar Sling HealthCheck-gränssnittet om du vill skapa en Sling-hälsokontroll. Lägg 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änstkomponentsanteckningar:

   @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 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 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 så här: Om huvudnamnet för hälsokontrollen ä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 banan är följande:

   /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

   Den här processen instruerar 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 flera 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 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 en enkel kontroll.

1. Gå till Web Configuration Manager i OSGI-konsolen. Öppna https://serveraddress:port/system/console/configMgr

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

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

   

4. Skapa en konfiguration och spara den. En böna 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 Mbean som ges till JMX MBean för den här sammansatta hälsokontrollen.
   • Filtertaggar (filter.tags): Egenskapen som är specifik för sammansatta hälsokontroller. Dessa taggar sammanställs av det sammansatta. Den sammansatta hälsokontrollen aggregerar under sin grupp alla hälsokontroller som har en tagg som matchar någon av filtertaggarna i den här sammansatta sammansättningen. En sammansatt hälsokontroll med till exempel filtertaggarna test och check, sammanställer 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 har skapats läggas till i konfigurationsnoderna för kontrollpanelen för åtgärder. Proceduren är densamma som för individuella hälsokontroller: en nod av typen nt:ostrukturerad måste skapas under /apps/settings/granite/operations/hc. Egenskapen resource 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 ser konfigurationsnoderna 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. Därför behöver du inte skapa en konfigurationsnod för dessa kontroller.

   Om du till exempel skapar en enskild säkerhetshälsokontroll tilldelar du den värdet säkerhet-taggen och den är installerad. Den visas automatiskt under den sammansatta kontrollen Säkerhetskontroller på kontrollpanelen för åtgärder.

Hälsokontroller som tillhandahålls med AEM

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. Konfigurera 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. Du kan utföra den här uppgiften med webbgränssnittet Nagios XI genom att använda 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:

   

   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:

   

Diagnosverktyg

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

Bland de viktigaste funktionerna är:

• 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 komma åt skärmen genom att gå direkt till följande URL: https://serveraddress:port/libs/granite/operations/content/diagnosis.html

Loggmeddelanden

Loggmeddelandena Användargränssnittet visar alla FELmeddelanden som standard. Om du vill att fler loggmeddelanden ska visas konfigurerar du 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 minnesloggaren. Dessutom återspeglas ändringen av loggningskonfigurationerna i framtiden för minnesloggaren. Poster som redan är loggade och inte längre är relevanta tas inte bort, men liknande poster loggas inte 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 anger nivån för en logger aktiveras inhämtning 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 är inställd på: FELSÖKNING (gör det fångar alla FEL, VARNING, INFORMATION och FELSÖKNING som visas i bilden nedan.

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 hämtas följande förfrågningar:

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

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

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 på AEM välkomstskärm. Klicka sedan på Frågeprestanda och växla 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 anger du frågan och trycker på Förklara knapp:

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 antalet noder. Rapporten innehåller mer information som kan användas för att optimera index för ditt program eller din distribution.

Index Manager

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

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

Den här åtgärden 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, som 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 dagar med loggar som ingår i hämtningen i förhållande till det aktuella datumet.

Ladda ned tråddump

Den här åtgärden aktiverar nedladdningen av en zip 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 hämta en ögonblicksbild av heapen för att analysera den senare. Den här åtgärden aktiverar hämtning av en stor fil (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 Underhåll på kontrollpanelen för drift går du AEM välkomstskärmen till Verktyg - Drift - Kontrollpanel - Underhåll, 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.

Standardtimingen för det dagliga underhållet är 2:00 till 5:00. De uppgifter som konfigurerats för att köras varje vecka i underhållsfönstret körs mellan 1:00 A.M och 2:00 A.M. på lördagar.

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

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. Lucene's binary churn regenereras dagligen i stället för 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 kan slutföras snabbare.
• Den kan också förbättra den övergripande AEM något.

Du kan komma åt aktiviteten Rensa Lucene-binärfiler från: AEM > Verktyg > Åtgärder > Underhåll > Dagligt underhåll > 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. Så här kör du tömningsaktiviteten för arbetsflöde:

1. Klicka på Underhållsfönster varje vecka sida.
2. Klicka på Spela upp i Rensa arbetsflöde kort.

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. Den här åtgärden 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 Lägg till.

2. Välj Rensa version i listrutan.

   

3. Konfigurera aktiviteten Rensa version genom att klicka på växlar ikonen på det nya underhållskortet Version Renge.

   

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 utan problem.

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ållsåtgärd 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:

Förutom de ovanstående tjänstegenskaperna finns följande process() metod för JobConsumer -gränssnittet måste implementeras genom att lägga till koden som ska köras för underhållsaktiviteten. 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 att en konfiguration är aktiv 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

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:

Den här åtgärden lägger till en motsvarande resurs på /apps/granite/operations/config/intenance/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. Systemets hälsostatus är transparent och all information samlas på en enda kontrollpanel.

Så här får du åtkomst

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

Kontrollpanelen för systemöversikt förklaras

Tabellen nedan beskriver all information som visas i kontrollpanelen för systemöversikt. 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å Ladda ned i kontrollpanelens övre högra hörn. The JSON slutpunkten är /libs/granite/operations/content/systemoverview/export.json och kan användas i en curl för extern övervakning.