Övervaka och underhålla AEM monitoring-and-maintaining-your-aem-instance

När AEM har distribuerats behövs vissa uppgifter för att övervaka och underhålla deras åtgärder, prestanda och integritet.

En nyckelfaktor här är att för att identifiera potentiella problem måste du veta hur dina system ser ut och beter sig under normala förhållanden. Detta görs bäst genom att övervaka systemet och samla in information över en tidsperiod.

Säkerhetskopior backups

Det är god praxis att säkerhetskopiera

Företaget kommer förmodligen att ha en säkerhetskopieringsprincip som du måste följa, ytterligare överväganden om vad som ska säkerhetskopieras och när inkluderar:

Ofta utförs en fullständig säkerhetskopiering med regelbundna intervall (t.ex. dagligen, veckovis eller månadsvis), med inkrementella säkerhetskopieringar mellan (t.ex. varje timme, dag eller vecka).

Säkerhetskopiera programvaruinstallationen backing-up-your-software-installation

När installationen är klar, eller om konfigurationen har ändrats på ett betydande sätt, gör du en säkerhetskopia av programvaruinstallationen.

För att göra detta måste du säkerhetskopiera hela databasen och sedan:

Säkerhetskopiera databasen backing-up-your-repository

The Säkerhetskopiering och återställning i CRX-dokumentationen täcker alla problem som rör säkerhetskopiering av CRX-databasen.

Mer information om hur du gör en "hot"-säkerhetskopiering online finns i Skapa en onlinesäkerhetskopiering.

Rensning av version version-purging

The Rensa versioner är avsett för att rensa versioner av en nod eller en hierarki av noder i din databas. Dess främsta syfte är att hjälpa dig att minska storleken på databasen genom att ta bort tidigare versioner av dina noder.

I det här avsnittet behandlas underhållsåtgärder som rör versionsfunktionen i AEM. The Rensa version är avsett för att rensa versioner av en nod eller en hierarki av noder i din databas. Dess främsta syfte är att hjälpa dig att minska storleken på databasen genom att ta bort tidigare versioner av dina noder.

Översikt overview

The Rensa versioner finns i verktyg konsol under Versionshantering eller direkt på

https://<server>:<port>/etc/versioning/purge.html

Startbana En absolut väg som rensningen måste göras på. Du kan välja Startsökväg genom att klicka på databasträdnavigatören.

Rekursiv När du rensar data kan du välja mellan att utföra åtgärden på en nod eller på en hel hierarki genom att välja Rekursiv. I det sista fallet definierar den angivna sökvägen rotnoden i hierarkin.

Högsta antal versioner att behålla Det högsta antalet versioner som kan behållas för en nod. När de här siffrorna överskrider det här värdet rensas de äldsta versionerna.

Högsta versionsålder Högsta ålder för en nods version. När en versions ålder överskrider det här värdet rensas den.

Torr körning Eftersom borttagning av versioner av ditt innehåll är definierat och inte kan återställas utan att du återställer en säkerhetskopia har verktyget Rensa versioner ett torrt körningsläge som gör att du kan förhandsgranska rensade versioner. Klicka på Torr körning om du vill starta en torr tömningsprocess.

Rensa Starta rensningen av versionerna på noden som definieras av startsökvägen.

Rensa versioner av en webbplats purging-versions-of-a-web-site

Så här rensar du versioner av en webbplats:

Analyserar konsolen analyzing-the-console

The Torr körning och Rensa I visas alla noder som har bearbetats. Under processen kan en nod ha någon av följande status:

Konsolen ger dessutom användbar information om versionerna:

I nästa exempel:

Arbeta med granskningsposter och loggfiler working-with-audit-records-and-log-files

Granskningsposter och loggfiler för Adobe Experience Manager (AEM) finns på olika platser. Här följer en översikt över vad du kan hitta.

Arbeta med loggar working-with-logs

AEM WCM registrerar detaljerade loggar. När du har packat upp och startat Quickstart hittar du loggar in:

Rotation av loggfil log-file-rotation

Rotation av loggfiler avser den process som begränsar filens tillväxt genom att skapa nya filer med jämna mellanrum. I AEM anropas en loggfil error.log roteras en gång om dagen enligt följande regler:

Hitta loggfilerna finding-the-log-files

Olika loggfiler finns på den filserver där du installerade AEM:

Aktivera felsökningsloggnivån activating-the-debug-log-level

Standardloggnivån Konfiguration av Apache Sling-loggning är Information, så felsökningsmeddelanden loggas inte.

Om du vill aktivera felsökningsloggnivån för en loggare anger du egenskapen org.apache.sling.commons.log.level för att felsöka i databasen. På /libs/sling/config/org.apache.sling.commons.log.LogManager för att konfigurera global Apache Sling Logging.

En rad i felsökningsfilen börjar oftast med DEBUG och anger sedan loggnivån, installationsåtgärden och loggmeddelandet. Till exempel:

DEBUG 3 WebApp Panel: WebApp successfully deployed

Loggnivåerna är följande:

Skapa en anpassad loggfil create-a-custom-log-file

I vissa fall kanske du vill skapa en anpassad loggfil med en annan loggnivå. Du kan göra detta i databasen genom att:

Felix Console innehåller även information om stöd för att lagra loggar på ../system/console/slinglog; till exempel http://localhost:4502/system/console/slinglog.

Söka efter granskningsposter finding-the-audit-records

Granskningsregister förs för att visa vem som gjorde vad och när. Olika granskningsposter genereras för både AEM WCM- och OSGi-händelser.

AEM WCM-granskningsposter visas vid sidredigering aem-wcm-audit-records-shown-when-page-authoring

AEM WCM-granskningsposter i databasen aem-wcm-auditing-records-within-the-repository

I /var/audit mapp, granskningsposter sparas enligt resursen. Du kan gå nedåt tills du ser de enskilda posterna och den information de innehåller.

Dessa poster innehåller samma information som den som visas när du redigerar en sida.

OSGi Granskningsposter från webbkonsolen osgi-audit-records-from-the-web-console

OSGi-händelser genererar också granskningsposter som kan ses av Konfigurationsstatus tab -> Loggfiler i AEM webbkonsol:

Övervaka replikeringsagenter monitoring-your-replication-agents

Du kan övervaka dina replikeringsköer för att identifiera när en kö är avstängd eller blockerad - vilket i sin tur kan tyda på ett problem med en publiceringsinstans eller ett externt system:

Så här övervakar du en replikeringsagent:

Du kan också utveckla en lösning för att identifiera alla replikeringsagenter (som finns under /etc/replication/author eller /etc/replication/publish) och sedan kontrollera status för agenten ( enabled, disabled) och den underliggande kön ( active, idle, blocked).

Övervakningsprestanda monitoring-performance

Prestandaoptimering är en interaktiv process som får fokus under utvecklingen. Efter distributionen granskas den vanligtvis efter specifika intervall eller händelser.

Metoder som används för att samla in information för optimering kan också användas för kontinuerlig övervakning.

Nedan visas vanliga prestandaproblem som uppstår, tillsammans med förslag på hur du kan hitta och motverka dem.

Prestandaproblem kan bero på ett antal orsaker som inte har något att göra med webbplatsen, bland annat tillfälliga avbrott i anslutningshastigheten, processorbelastningen och många andra.

Det kan även påverka alla besökare eller bara en del av dem.

All denna information måste hämtas, sorteras och analyseras innan du kan optimera den allmänna prestandan eller lösa specifika problem.

Verktyg för övervakning och analys av prestanda tools-for-monitoring-and-analyzing-performance

Nedan ges en kort översikt över några av de verktyg som är tillgängliga för övervakning och analys av prestanda.

Vissa av dessa kommer att vara beroende av operativsystemet.

Tolka request.log interpreting-the-request-log

Den här filen registrerar grundläggande information om varje begäran som görs till AEM. Denna värdefulla slutsats kan extraheras.

The request.log erbjuder ett inbyggt sätt att se hur lång tid det tar att begära. I utvecklingssyfte är det användbart att tail -f den request.log och hålla utkik efter långsamma svarstider. Analysera en större request.log rekommenderar vi användning av rlog.jar som gör att du kan sortera och filtrera efter svarstider.

Vi rekommenderar att du isolerar de"långsamma" sidorna från request.logoch sedan justera dem individuellt för bättre prestanda. Detta görs vanligtvis genom att prestandamätningar per komponent inkluderas eller genom att ett prestandaprofileringsverktyg som [yourkit](https://www.yourkit.com/).

Övervaka trafik på din webbplats monitoring-traffic-on-your-website

Begärandeloggen registrerar varje begäran som gjorts, tillsammans med svaret:

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

Genom att summera alla GETTER under en viss period (t.ex. under olika 24-timmarsperioder) kan du göra utdrag om den genomsnittliga trafiken på webbplatsen.

Övervaka svarstider med request.log monitoring-response-times-with-the-request-log

En bra utgångspunkt för prestandaanalys är begärandeloggen:

<cq-installation-dir>/crx-quickstart/logs/request.log

Loggen ser ut så här (raderna förkortas för enkelhetens skull):

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Den här loggen har en rad per begäran eller svar:

Med små skript kan du extrahera den information som behövs från loggfilen och sammanställa den statistik som du vill ha. Därifrån ser du vilka sidor eller typer av sidor som är långsamma och om de totala prestandan är tillfredsställande.

Övervaka söksvarstider med request.log monitoring-search-response-times-with-the-request-log

Sökbegäranden registreras också i loggfilen:

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Så som ovan kan du använda skript för att extrahera relevant information och bygga upp statistik.

När du väl har bestämt svarstiden kan du behöva analysera varför begäran tar den tid som behövs och vad som kan göras för att förbättra svaret.

Övervaka antalet samtidiga användare och deras inverkan monitoring-the-number-and-impact-of-concurrent-users

Igen request.log kan användas för att övervaka samtidighet och systemets reaktion på detta.

Testerna måste göras för att avgöra hur många samtidiga användare som systemet kan hantera innan en negativ påverkan ses. Återigen kan du använda skript för att extrahera resultat från loggfilen:

31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Använda rlog.jar för att hitta begäranden med lång varaktighet using-rlog-jar-to-find-requests-with-long-duration-times

AEM innehåller olika hjälpverktyg som finns i:
<cq-installation-dir>/crx-quickstart/opt/helpers

En av dessa, rlog.jar, kan användas för att snabbt sortera request.log så att förfrågningar visas med varaktighet, från längst till kortast.

Följande kommando visar möjliga argument:

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

Du kan till exempel köra den och ange request.log som en parameter och visa de 10 första begäranden som har längst varaktighet:

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

Du kan behöva sammanfoga den enskilda personen request.log filer om du behöver utföra den här åtgärden på ett stort dataprov.

Apache Bench apache-bench

För att minimera specialfall (t.ex. skräpinsamling) rekommenderar vi att du använder ett verktyg som apachebench (se t.ex. ab för ytterligare dokumentation) för att identifiera minnesläckor och selektivt analysera svarstiden.

Apache Bench kan användas på följande sätt:

$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

Siffrorna ovan är tagna från en vanlig bärbar MAcBook Pro-dator (mitten av 2010) med åtkomst till företagssidan för geometrixx, som ingår i en AEM. Sidan är mycket enkel, men inte optimerad för prestanda.

apachebench visar också tiden per begäran som medelvärde för alla samtidiga begäranden, se Time per request: 54.595 [ms] (medelvärde, för alla samtidiga begäranden). Du kan ändra värdet på parametern concurrency -c (antal flera begäranden om att utföra samtidigt) för att se eventuella effekter.

Begäranräknare request-counters

Information om begärandetrafik (antal förfrågningar under en viss tidsperiod) ger dig en indikation på belastningen på din instans. Den här informationen kan extraheras från request.logmen med räknare kan du automatisera datainsamlingen så att du kan se:

Om du vill automatisera informationsinsamlingen kan du även installera ett RequestFilter för att öka antalet räknare vid varje begäran. Flera räknare kan användas för olika tidsperioder.

De insamlade uppgifterna kan användas för att ange

HTML kommentarer html-comments

Vi rekommenderar att alla projekt innehåller html comments för serverprestanda. Många bra exempel finns. Välj en sida, öppna sidkällan för visning och bläddra längst ned. Kod som följande kan visas:

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Övervaka prestanda med JConsole monitoring-performance-using-jconsole

Verktygskommandot jconsole är tillgängligt med JDK.

Övervakningsprestanda med (J)VisualVM monitoring-performance-using-j-visualvm

Sedan JDK 1.6 kommando för verktyget jvisualvm är tillgängligt. När du har installerat JDK 1.6 kan du:

Du kan använda det här verktyget för att generera tråddumpar och minnesdumpar. Den här informationen begärs ofta av den tekniska supportteamet.

Informationsinsamling information-collection

Om du vet så mycket som möjligt om din installation kan det hjälpa dig att spåra vad som kan ha orsakat prestandaförändringar och om dessa ändringar är motiverade. Dessa mätvärden måste samlas in med regelbundna intervall så att du enkelt kan se betydande ändringar.

Följande information kan vara användbar:

Hur många författare arbetar med systemet? how-many-authors-are-working-with-the-system

Använd kommandoraden för att se hur många författare som har använt systemet sedan installationen:

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Så här ser du hur många författare som arbetar ett visst datum:

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Vilket är det genomsnittliga antalet sidaktiveringar per dag? what-is-the-average-number-of-page-activations-per-day

Om du vill se det totala antalet sidaktiveringar sedan serverinstallationen använder en databasfråga, via CRXDE - Tools - Query:

Beräkna sedan medelvärdet genom att beräkna antalet dagar som har gått sedan installationen.

Hur många sidor har du i det här systemet? how-many-pages-do-you-currently-maintain-on-this-system

Om du vill se antalet sidor som för närvarande finns på servern använder du en databasfråga; via CRXDE - Tools - Query:

Om du använder MSM, vilket är det genomsnittliga antalet utrullningar per månad? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

För att fastställa det totala antalet utrullningar sedan installationen använder du en databasfråga. via CRXDE - Tools - Query:

Beräkna medelvärdet genom att beräkna antalet månader som har gått sedan installationen.

Vilket är det genomsnittliga antalet Live-kopior per månad? what-is-the-average-number-of-live-copies-per-month

För att fastställa det totala antalet live-kopior som gjorts sedan installationen använder du en databasfråga. via CRXDE - Tools - Query:

Använd återigen antalet månader som har gått sedan installationen för att beräkna genomsnittet.

Om du använder AEM Assets, hur många mediefiler har du för närvarande i Assets? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Om du vill se hur många DAM-resurser du för närvarande har använder du en databasfråga; via CRXDE - Tools - Query:

Vilken är den genomsnittliga storleken på resurserna? what-is-the-average-size-of-the-assets

Så här avgör du den totala storleken på /var/dam mapp:

Hur många mallar används för närvarande? how-many-templates-are-currently-used

Om du vill se antalet mallar som för närvarande finns på servern använder du en databasfråga. via CRXDE - Tools - Query:

Hur många komponenter används för närvarande? how-many-components-are-currently-used

Om du vill se antalet komponenter som för närvarande finns på servern använder du en databasfråga. via CRXDE - Tools - Query:

Hur många förfrågningar per timme har du på författarsystemet vid maximal tid? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Så här tar du reda på begäranden per timme som du har på författarsystemet vid maximal tid:

Hur många begäranden per timme har du i publiceringssystemet vid maximal tid? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Upprepa proceduren ovan på din publiceringsinstans.

Analyserar specifika scenarier analyzing-specific-scenarios

Här följer en lista med förslag på vad du ska kontrollera om du får vissa prestandaproblem. Listan är tyvärr inte helt heltäckande.

CPU vid 100 % cpu-at

Om datorns CPU hela tiden körs med 100 % kan du se:

Slut på minne out-of-memory

Även om sådana fel bör identifieras under utveckling och testning kan vissa scenarier gå igenom.

Om minnet håller på att ta slut kan du se det på olika sätt, bland annat på prestandaförsämringar och felmeddelanden, inklusive undertexten:

java.lang.OutOfMemoryError

I dessa fall ska du kontrollera:

Skiva-I/O disk-i-o

Om det inte finns tillräckligt med diskutrymme på datorn eller om disktrassel börjar visas följande:

Regelbunden prestandaförsämring regular-performance-degradation

Om du ser att prestanda för instansen försämras efter varje omstart (ibland en vecka eller mer senare) kan du kontrollera följande:

JVM-justering jvm-tuning

Java Virtual Machine (JVM) har kraftigt förbättrats när det gäller justering (särskilt sedan Java 7). Därför är det ofta lämpligt att ange en rimlig fast JVM-storlek och att använda standardvärdena.

Om standardinställningarna inte är lämpliga är det viktigt att fastställa en metod för att övervaka och utvärdera prestandan för global katalog innan du försöker justera den virtuella datorn. Detta kan inbegripa övervakningsfaktorer som stackstorlek, algoritm och andra aspekter.

Några vanliga alternativ är:

Den resulterande loggen kan importeras av en GC-visualiserare som:

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

Eller JConsole:

Detta hjälper dig att se hur mycket minne som används, vilka GC-algoritmer som används, hur lång tid det tar att köra dem och vilken effekt detta har på programmets prestanda. Utan detta är finjustering bara "slumpmässigt virvlande knoppar".