Instrumentpanel för åtgärder operations-dashboard
Introduktion introduction
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.
Hälsorapporter health-reports
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 health-checks
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
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 health-check-types
Det finns två typer av hälsokontroller i AEM 6:
- Individuella hälsokontroller
- 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 how-to-create-health-checks
På kontrollpanelen för åtgärder kan du visualisera resultatet av både individuella och sammansatta hälsokontroller.
Skapa en enskild hälsokontroll creating-an-individual-health-check
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.
-
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:
code language-java @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 } }
note note NOTE The MBEAN_NAME
-egenskapen definierar namnet på den böna som ska genereras för den här hälsokontrollen. -
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
- Typ:
-
Namn:
resource
- Typ:
String
- Värde:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
- Typ:
note note NOTE 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
note note NOTE 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 creating-a-composite-health-check
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.
-
Gå till Web Configuration Manager i OSGI-konsolen. Du kan göra detta genom att gå till
https://serveraddress:port/system/console/configMgr
-
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.
-
Skapa en ny konfiguration genom att trycka på plusknappen (+) till höger om konfigurationen. Ett nytt fönster visas enligt nedan:
-
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
).
note note NOTE En ny JMX Mbean skapas för varje ny konfiguration av den sammansatta hälsokontrollen för Apache Sling.** -
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
- Typ:
Med följande egenskaper:
-
Namn:
sling:resourceType
- Typ:
String
- Värde:
granite/operations/components/mbean
- Typ:
-
Namn:
resource
- Typ:
String
- Värde:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
- Typ:
note note NOTE 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 health-checks-provided-with-aem
Övervakning med Nagios monitoring-with-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.
-
Installera och installera Nagios på övervakningsservern.
-
Installera sedan Nagios Remote Plugin Executor (NRPE).
note note NOTE Mer information om hur du installerar Nagios och NRPE på datorn finns i Nagios-dokumentation. -
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:
- Öppna en webbläsare och peka på Nagios-servern.
- Tryck på Konfigurera på den översta menyn.
- Tryck på Core Config Manager under Avancerad konfiguration.
- Tryck på Värdar länk under Övervakning -avsnitt.
- Lägg till värddefinitionen:
Nedan visas ett exempel på en värdkonfigurationsfil, om du använder Nagios Core:
code language-xml 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 }
-
Installera Nagios och NRPE på AEM.
-
Installera check_http_json plugin-program på båda servrarna.
-
Definiera ett generiskt JSON-kontrollkommando på båda servrarna:
code language-xml 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$' }
-
Lägg till en tjänst för använt minne på AEM:
code language-xml 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> }
-
Kontrollera din Nagios-instrumentpanel för den nya tjänsten:
Diagnosverktyg diagnosis-tools
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
Loggmeddelanden log-messages
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.
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
Begär prestanda request-performance
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:
- Begäranden om åtkomst till resurser under
/content
- Begäranden om åtkomst till resurser under
/etc/design
- 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 query-performance
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 explain-query
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:
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, vilket ger mer information som kan användas för att optimera indexen för programmet eller distributionen.
Indexhanteraren the-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 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 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 fönstret Download Status ZIP . 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.
Ladda ned tråddump download-thread-dump
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 download-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 automated-maintenance-tasks
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:
-
Uppgiften Revision Clean Up finns under Daglig underhållsperiod -menyn.
-
Uppgiften Lucene Binaries Cleanup som finns under Daglig underhållsperiod -menyn.
-
Aktiviteten Workflow purge finns under Underhållsfönster varje vecka -menyn.
-
The Skräpinsamling för datalager uppgift, som finns under Underhållsfönster varje vecka -menyn.
-
The Underhåll av granskningslogg uppgift, som finns under Underhållsfönster varje vecka -menyn.
-
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:
Rensa version revision-clean-up
Mer information om Revision Clean Up for AEM 6.4 finns i se den här dedikerade artikeln.
Lucene Binaries Cleanup 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 data-store-garbage-collection
Mer information om skräpinsamlingen i datalagret finns i den dedikerade dokumentsida.
Rensa arbetsflöde workflow-purge
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:
- Klicka på Underhållsfönster varje vecka sida.
- På följande sida klickar du på Spela upp i Rensa arbetsflöde kort.
Underhåll av granskningslogg audit-log-maintenance
Mer information om underhåll av granskningslogg finns i separat dokumentationssida.
Rensa version version-purge
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:
-
Klicka på Lägg till -knappen.
-
Välj Rensa version i listrutan.
-
Klicka på knappen växlar ikonen på det nya underhållskortet för versionsrensning.
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.
Anpassade underhållsaktiviteter custom-maintenance-tasks
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:
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
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 användargränssnittet för Operations Dashboard och kan läggas till i någon av de tillgängliga underhållsschemana:
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 system-overview
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.
Åtkomst how-to-access
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 system-overview-dashboard-explained
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.