Övervaka och underhålla din Adobe Experience Manager-instans monitoring-and-maintaining-your-aem-instance

När AEM har distribuerats måste du övervaka och underhålla deras åtgärder, prestanda och integritet.

En viktig faktor här är att du måste känna till hur systemet ser ut och fungerar under normala förhållanden för att kunna identifiera potentiella problem. Detta görs bäst genom att man övervakar systemet och samlar in information över tid.

Säkerhetskopior backups

Det är god praxis att säkerhetskopiera

Företaget har förmodligen en säkerhetskopieringsprincip som du följer, ytterligare överväganden om vad och när du ska säkerhetskopiera inkluderar följande:

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

Säkerhetskopiera din programvaruinstallation backing-up-your-software-installation

Efter installationen, eller betydande ändringar i konfigurationen, skapar du en säkerhetskopia av din programvaruinstallation.

För att utföra den här uppgiften, säkerhetskopiera hela lagringsplatsen och sedan:

Säkerhetskopiera din lagringsplats backing-up-your-repository

Avsnittet 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 skapar en "hot"-säkerhetskopiering online finns i Skapa en onlinesäkerhetskopiering.

Rensning av version version-purging

Verktyget Rensa versioner är avsett 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. Verktyget Rensa version är avsett att rensa versioner av en nod eller en hierarki av noder i databasen. Dess primära syfte är att hjälpa dig att minska storleken på ditt arkiv genom att ta bort gamla versioner av dina noder.

Överblick overview

Verktyget Rensa versioner är tillgängligt som en underhållsåtgärd varje vecka. Innan du använder den för första gången måste den läggas till och sedan konfigureras. Därefter kan det köras på begäran eller varje vecka.

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

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

Torr körning - Analyserar konsolen analyzing-the-console

Det klassiska användargränssnittet innehåller ett torrt körningsalternativ från:

Processen visar alla noder som har bearbetats. Under processen kan en nod ha någon av följande statusar:

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 och var du kan hitta den.

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 en fil regelbundet. I AEM roteras en loggfil med namnet error.log 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 loggnivån för FELSÖKNING activating-the-debug-log-level

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

Om du vill aktivera felsökningsloggnivån för en loggare ställer du in egenskapen org.apache.sling.commons.log.level på att felsöka i databasen. På /libs/sling/config/org.apache.sling.commons.log.LogManager om du till exempel vill konfigurera global Apache Sling-loggning.

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å. Gör följande i databasen:

Felix Console innehåller även information om stöd för delningsloggar på ../system/console/slinglog, till exempel https://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 mappen /var/audit hålls granskningsposter enligt resursen. Du kan gå nedåt tills du ser enskilda poster 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 visas på fliken Konfigurationsstatus > fliken 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:

Även här kan du 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 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 om hur du kan hitta och motverka dem.

Prestandaproblem kan bero på olika orsaker som inte har något med din webbplats att göra, 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 verktyg är 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. Därigenom kan värdefulla slutsatser dras.

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 request.log och hålla utkik efter långsamma svarstider. Om du vill analysera ett större request.log rekommenderar Adobe användningen av rlog.jar, vilket gör att du kan sortera och filtrera efter svarstider.

Adobe rekommenderar att du isolerar de "långsamma" sidorna från request.log och sedan justerar dem individuellt för att få bättre prestanda. Inkludera prestandamått per komponent eller använd 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 inom specifika perioder (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. Med hjälp av den här statistiken kan du se 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 har bestämt svarstiden kan du 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

Återigen kan request.log användas för att övervaka samtidighet och systemets reaktion på den.

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 i följande:
<cq-installation-dir>/crx-quickstart/opt/helpers

Ett av dessa verktyg, rlog.jar, kan användas för att snabbt sortera request.log så att begäranden visas med varaktighet, från längsta till kortaste tid.

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 filen request.log som en parameter och visa de tio 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

Sammanfoga de enskilda request.log-filerna om du måste utföra den här åtgärden på ett stort dataexempel.

Apache Bench apache-bench

För att minimera effekten av specialfall (till exempel skräpinsamling) rekommenderar vi att du använder ett verktyg som apachebench (till exempel 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 "https://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 hämtas från en vanlig bärbar dator från MAcBook Pro (mitten av 2010) som har åtkomst till Geometrixx företagssida, vilket ingår i en AEM. Sidan är 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 för samtidig användning -c (antalet flera begäranden som ska utföras 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.log, men med räknare automatiseras 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 rulla längst ned. Kod som följande kan ses:

</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.

Övervaka prestanda med hjälp av (J)VisualVM monitoring-performance-using-j-visualvm

För JDK 6-8 är verktygskommandot visualvm tillgängligt. När du har installerat en JDK kan du göra följande:

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. Samla in dessa mätvärden med jämna mellanrum 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 du en databasfråga. Med CRXDE - Verktyg - Fråga:

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 finns på servern använder du en databasfråga, via CRXDE - Verktyg - Fråga:

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

Använd en databasfråga för att fastställa det totala antalet rollouts sedan installationen. Med CRXDE - Verktyg - Fråga:

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

Om du vill fastställa det totala antalet live-kopior som har gjorts sedan installationen använder du en databasfråga, via CRXDE - Verktyg - Fråga:

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

Använd en databasfråga, via CRXDE - Verktyg - Fråga, om du vill se hur många DAM-resurser du för närvarande har:

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

Så här fastställer du den totala storleken på mappen /var/dam :

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

Om du vill visa antalet mallar som finns på servern använder du en databasfråga, via CRXDE - Verktyg - Fråga:

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

Om du vill se antalet komponenter som finns på servern använder du en databasfråga, via CRXDE - Verktyg - Fråga:

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 avgör du 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 %, se följande:

Slut på minne out-of-memory

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

Om det inte finns tillräckligt med minne i systemet kan det här problemet visas på olika sätt, bland annat prestandaförsämringar och felmeddelanden, bland annat undertexten:

java.lang.OutOfMemoryError

Kontrollera i så fall:

Skiva-I/O disk-i-o

Om det inte finns tillräckligt med diskutrymme på datorn eller om det uppstår problem med hårddisken kan du läsa mer i:

Regelbunden prestandaförsämring regular-performance-degradation

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

JVM-justering jvm-tuning

Java™ Virtual Machine (JVM) har 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 upprätta en metod för att övervaka och utvärdera GC-prestanda. Gör det innan du försöker justera JVM. Den här processen kan omfatta övervakningsfaktorer, inklusive heapstorlek, 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:

Du kan 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 den här processen har på programmets prestanda. Utan den är finjustering bara "slumpmässigt virvlande knoppar".