Monitoraggio e manutenzione dell’istanza di Adobe Experience Manager monitoring-and-maintaining-your-aem-instance

Dopo aver implementato le istanze AEM, è necessario monitorarne e mantenerne il funzionamento, le prestazioni e l'integrità.

Un fattore chiave in questo caso è che per riconoscere potenziali problemi è necessario conoscere l'aspetto e il funzionamento del sistema in condizioni normali. Questa capacità è resa possibile al meglio monitorando il sistema e raccogliendo informazioni nel tempo.

Backup backups

È buona prassi eseguire il backup di:

È probabile che l'azienda disponga di una politica di backup da seguire. Considerazioni aggiuntive su cosa e quando eseguire il backup sono le seguenti:

Spesso viene eseguito un backup completo a intervalli regolari (ad esempio, giornaliero, settimanale o mensile), con backup incrementali compresi tra (ad esempio, ogni ora, ogni giorno o ogni settimana).

Backup dell'installazione del software backing-up-your-software-installation

Dopo l'installazione o modifiche significative nella configurazione, creare un backup dell'installazione del software.

Per eseguire questa operazione, eseguire il backup dell'intero archivio e quindi:

Backup dell’archivio backing-up-your-repository

Il Backup e ripristino nella documentazione di CRX sono descritti tutti i problemi relativi ai backup dell’archivio CRX.

Per informazioni dettagliate sulla creazione di un backup "a caldo" online, vedere Creazione di un backup online.

Rimozione versione version-purging

Il Rimuovi versioni Questo strumento serve per eliminare le versioni di un nodo o di una gerarchia di nodi nell’archivio. Il suo scopo principale è quello di aiutare a ridurre le dimensioni dell’archivio rimuovendo le versioni precedenti dei nodi.

Questa sezione tratta le operazioni di manutenzione relative alla funzione di controllo delle versioni dell’AEM. Il Rimuovi versione Questo strumento serve per eliminare le versioni di un nodo o di una gerarchia di nodi nell’archivio. Il suo scopo principale è quello di aiutarti a ridurre le dimensioni del tuo archivio rimuovendo le vecchie versioni dei tuoi nodi.

Panoramica overview

Il Rimuovi versioni è disponibile come attività di manutenzione settimanale. Prima di utilizzare per la prima volta, è necessario aggiungerlo e configurarlo. Successivamente può essere eseguito su richiesta o settimanalmente.

Rimozione delle versioni di un sito Web purging-versions-of-a-web-site

Per eliminare le versioni di un sito Web, procedere come segue:

Dry Run: analisi della console analyzing-the-console

L’interfaccia classica offre Dry Run opzione da:

Il processo elenca tutti i nodi che sono stati elaborati. Durante il processo, un nodo può avere uno dei seguenti stati:

Inoltre, la console fornisce informazioni utili sulle versioni:

Nel prossimo esempio:

Utilizzo dei record di controllo e dei file di registro working-with-audit-records-and-log-files

I record di controllo e i file di registro relativi a Adobe Experience Manager (AEM) sono disponibili in varie posizioni. Di seguito viene fornita una panoramica di ciò che è possibile trovare e dove è possibile trovarlo.

Utilizzo dei registri working-with-logs

WCM AEM registra registri dettagliati. Dopo aver decompresso e avviato Quickstart, puoi trovare i registri in:

Rotazione del file di registro log-file-rotation

La rotazione del file di registro si riferisce al processo che limita la crescita del file creando periodicamente un file. In AEM, un file di registro denominato error.log viene ruotato una volta al giorno in base alle regole specificate:

Ricerca dei file di registro finding-the-log-files

Nel file server in cui è stato installato AEM sono presenti diversi file di registro:

Attivazione del livello di registro DEBUG activating-the-debug-log-level

Livello di registro predefinito (Configurazione registrazione Apache Sling) è Information, pertanto i messaggi di debug non vengono registrati.

Per attivare il livello di registro di debug per un logger, imposta la proprietà org.apache.sling.commons.log.level per eseguire il debug nel repository. Ad esempio, il /libs/sling/config/org.apache.sling.commons.log.LogManager per configurare registrazione globale di Apache Sling.

Una riga nel file di debug in genere inizia con DEBUG, quindi fornisce il livello del registro, l'azione del programma di installazione e il messaggio del registro. Ad esempio:

DEBUG 3 WebApp Panel: WebApp successfully deployed

I livelli del registro sono i seguenti:

Creare un file di registro personalizzato create-a-custom-log-file

In determinate circostanze, può essere opportuno creare un file di registro personalizzato con un livello di registro diverso. Nell’archivio, effettua le seguenti operazioni:

La console Felix fornisce anche informazioni sul supporto del registro Sling all’indirizzo ../system/console/slinglogad esempio, https://localhost:4502/system/console/slinglog.

Ricerca dei record di audit finding-the-audit-records

I registri di audit sono tenuti per fornire una registrazione di chi ha fatto cosa e quando. Vengono generati record di audit diversi per entrambi gli eventi AEM WCM e OSGi.

Record di audit WCM AEM visualizzati durante l’authoring delle pagine aem-wcm-audit-records-shown-when-page-authoring

Record di controllo WCM AEM nell’archivio aem-wcm-auditing-records-within-the-repository

All'interno del /var/audit cartella, i record di audit vengono conservati in base alla risorsa. È possibile espandere la visualizzazione fino a visualizzare i singoli record e le informazioni in essi contenute.

Queste voci contengono le stesse informazioni visualizzate durante la modifica di una pagina.

Record di controllo OSGi dalla console Web osgi-audit-records-from-the-web-console

Gli eventi OSGi generano anche record di audit che possono essere visualizzati dalla sezione Stato configurazione scheda > File di registro nella console Web AEM:

Monitoraggio degli agenti di replica monitoring-your-replication-agents

È possibile monitorare code di replica per rilevare quando una coda è inattiva o bloccata, il che potrebbe a sua volta indicare un problema con un’istanza di pubblicazione o un sistema esterno:

Per monitorare un agente di replica:

Anche in questo caso è possibile sviluppare una soluzione per rilevare tutti gli agenti di replica (che si trovano sotto /etc/replication/author o /etc/replication/publish), quindi controlla lo stato dell’agente ( enabled, disabled) e la coda sottostante ( active, idle, blocked).

Monitoraggio delle prestazioni monitoring-performance

Ottimizzazione delle prestazioni è un processo interattivo che viene messo a fuoco durante lo sviluppo. Dopo la distribuzione, viene rivisto dopo intervalli o eventi specifici.

I metodi utilizzati durante la raccolta delle informazioni per l’ottimizzazione possono essere utilizzati anche per il monitoraggio continuo.

Di seguito sono elencati i problemi di prestazioni comuni che si verificano, insieme a proposte su come individuarli e contrastarli.

I problemi di prestazioni possono derivare da varie cause che non hanno nulla a che fare con il sito web, tra cui rallentamenti temporanei della velocità di connessione, del carico della CPU e molto altro.

Inoltre, può influire su tutti i visitatori o solo su un sottoinsieme di essi.

Tutte queste informazioni devono essere ottenute, ordinate e analizzate prima di poter ottimizzare le prestazioni generali o risolvere problemi specifici.

Strumenti per il monitoraggio e l'analisi delle prestazioni tools-for-monitoring-and-analyzing-performance

Di seguito viene fornita una breve panoramica di alcuni degli strumenti disponibili per il monitoraggio e l'analisi delle prestazioni.

Alcuni di questi strumenti dipendono dal sistema operativo.

Interpretazione di request.log interpreting-the-request-log

In questo file vengono registrate le informazioni di base relative a ogni richiesta inviata all'AEM. Da ciò si possono trarre conclusioni preziose.

Il request.log offre una modalità integrata per dare un’occhiata alla durata delle richieste. Ai fini dello sviluppo, è utile tail -f il request.log e osserva i tempi di risposta lenti. Per analizzare una dimensione maggiore request.log, l'Adobe consiglia utilizzo di rlog.jar che consente di ordinare e filtrare i tempi di risposta.

L’Adobe consiglia di isolare le pagine "lente" dal request.log, quindi regolarle singolarmente per ottenere prestazioni migliori. Includi metriche delle prestazioni per componente o utilizzando uno strumento di analisi delle prestazioni come [yourkit](https://www.yourkit.com/).

Monitoraggio del traffico sul sito web monitoring-traffic-on-your-website

Il registro delle richieste registra ogni richiesta effettuata, insieme alla risposta fornita:

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

Calcolando il totale di tutte le voci di GET in periodi specifici (ad esempio, in vari periodi di 24 ore), puoi fare dichiarazioni sul traffico medio sul tuo sito web.

Monitoraggio dei tempi di risposta con request.log monitoring-response-times-with-the-request-log

Un buon punto di partenza per l’analisi delle prestazioni è il registro delle richieste:

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

Il registro si presenta come segue (le righe sono abbreviate per semplicità):

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

Questo registro contiene una riga per richiesta o risposta:

Utilizzando piccoli script, è possibile estrarre le informazioni richieste dal file di log e assemblare le statistiche desiderate. Da queste statistiche, puoi vedere quali pagine o tipi di pagine sono lenti e se le prestazioni complessive sono soddisfacenti.

Monitoraggio dei tempi di risposta delle ricerche con request.log monitoring-search-response-times-with-the-request-log

Le richieste di ricerca vengono registrate anche nel file di registro:

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

Quindi, come sopra, puoi utilizzare gli script per estrarre le informazioni rilevanti e creare statistiche.

Tuttavia, dopo aver determinato il tempo di risposta, analizza il motivo per cui la richiesta sta impiegando il tempo richiesto e cosa si può fare per migliorare la risposta.

Monitoraggio del numero e dell'impatto di utenti simultanei monitoring-the-number-and-impact-of-concurrent-users

Di nuovo il request.log può essere utilizzato per monitorare la concorrenza e la reazione del sistema ad essa.

È necessario eseguire dei test per determinare quanti utenti simultanei il sistema è in grado di gestire prima che si verifichi un impatto negativo. Di nuovo, gli script possono essere utilizzati per estrarre i risultati dal file di registro:

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

Utilizzo di rlog.jar per trovare richieste con tempi di durata prolungata using-rlog-jar-to-find-requests-with-long-duration-times

L’AEM include vari strumenti di assistenza nei seguenti casi:
<cq-installation-dir>/crx-quickstart/opt/helpers

Uno di questi strumenti, rlog.jar, può essere utilizzato per ordinare rapidamente request.log in modo che le richieste vengano visualizzate in base alla durata, dal tempo più lungo a quello più breve.

Il comando seguente mostra i possibili argomenti:

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

Ad esempio, puoi eseguirlo specificando request.log file come parametro e mostra le prime dieci richieste con durata maggiore:

$ 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

Concatenare l’individuo request.log file se è necessario eseguire questa operazione su un campione di dati di grandi dimensioni.

Apache Bench apache-bench

Per ridurre al minimo l’impatto di casi speciali (come la raccolta di rifiuti), si consiglia di utilizzare uno strumento come apachebench (ad esempio, ab per ulteriore documentazione) per identificare eventuali perdite di memoria e analizzare in modo selettivo i tempi di risposta.

Apache Bench può essere utilizzato nel modo seguente:

$ 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)

I numeri riportati sopra sono ricavati da un notebook standard MAcBook Pro (metà 2010) che accede alla pagina della società del Geometrixx, come incluso in un'installazione AEM predefinita. La pagina è semplice, ma non ottimizzata per le prestazioni.

Il apachebench mostra anche il tempo per richiesta come media, in tutte le richieste simultanee; vedi Time per request: 54.595 [ms] (media, su tutte le richieste simultanee). È possibile modificare il valore del parametro di concorrenza -c (numero di richieste multiple da eseguire alla volta) per visualizzare eventuali effetti.

Contatori richieste request-counters

Le informazioni sul traffico delle richieste (numero di richieste durante un periodo di tempo specifico) forniscono un’indicazione del carico sull’istanza. Queste informazioni possono essere estratte da request.log, anche se l’utilizzo dei contatori automatizza la raccolta dei dati per consentirti di visualizzare:

Per automatizzare la raccolta delle informazioni, è inoltre possibile installare RequestFilter per incrementare un contatore a ogni richiesta. È possibile utilizzare più contatori per diversi periodi di tempo.

Le informazioni raccolte possono essere utilizzate per indicare:

Commenti HTML html-comments

Si consiglia che ogni progetto includa html comments per le prestazioni del server. Si possono trovare molti buoni esempi pubblici. Seleziona una pagina, apri l’origine della pagina da visualizzare e scorri verso il basso. È possibile visualizzare un codice come il seguente:

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

Monitoraggio delle prestazioni tramite JConsole monitoring-performance-using-jconsole

Comando dello strumento jconsole è disponibile con JDK.

Monitoraggio delle prestazioni con (J)VisualVM monitoring-performance-using-j-visualvm

Per JDK 6-8, il comando tool visualvm è disponibile. Dopo aver installato un JDK, puoi effettuare le seguenti operazioni:

Puoi utilizzare questo strumento per generare immagini thread e immagini head della memoria. Queste informazioni vengono spesso richieste dal team di supporto tecnico.

Raccolta di informazioni information-collection

Conoscere il più possibile le informazioni sull'installazione può essere utile per tenere traccia di ciò che potrebbe aver causato un cambiamento nelle prestazioni e per verificare se tali modifiche sono giustificate. Raccogli queste metriche a intervalli regolari in modo da poter vedere facilmente cambiamenti significativi.

Le seguenti informazioni possono essere utili:

Quanti autori lavorano con il sistema? how-many-authors-are-working-with-the-system

Per visualizzare il numero di autori che hanno utilizzato il sistema dall'installazione, utilizzare la riga di comando:

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

Per visualizzare il numero di autori che lavorano in una data specifica:

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

Qual è il numero medio di attivazioni di pagina al giorno? what-is-the-average-number-of-page-activations-per-day

Per visualizzare il numero totale di attivazioni di pagina dall’installazione del server, utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

Quindi calcola il numero di giorni trascorsi dall’installazione per calcolare la media.

Quante pagine sono attualmente gestite in questo sistema? how-many-pages-do-you-currently-maintain-on-this-system

Per visualizzare il numero di pagine attualmente sul server utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

Se utilizzi MSM, qual è la media del numero di rollout al mese? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Per determinare il numero totale di rollout dall’installazione, utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

Calcolare il numero di mesi trascorsi dall'installazione per calcolare la media.

Qual è il numero medio di Live Copy al mese? what-is-the-average-number-of-live-copies-per-month

Per determinare il numero totale di Live Copy effettuate dall’installazione, utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

Utilizzare nuovamente il numero di mesi trascorsi dall'installazione per calcolare la media.

Se utilizzi AEM Assets, quante risorse gestisci attualmente in Assets? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Per visualizzare quante risorse DAM sono attualmente gestite, utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

Qual è la dimensione media delle risorse? what-is-the-average-size-of-the-assets

Per determinare la dimensione totale della /var/dam cartella:

Quanti modelli vengono attualmente utilizzati? how-many-templates-are-currently-used

Per visualizzare il numero di modelli attualmente sul server utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

Quanti componenti sono attualmente utilizzati? how-many-components-are-currently-used

Per visualizzare il numero di componenti attualmente sul server utilizza una query dell’archivio; tramite CRXDE - Strumenti - Query:

Quante richieste all’ora hai nel sistema di authoring al momento di picco? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Per determinare le richieste all’ora disponibili nel sistema di authoring al momento di picco:

Quante richieste all’ora hai sul sistema di pubblicazione al momento di picco? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Ripeti la procedura precedente sull’istanza di pubblicazione.

Analisi di scenari specifici analyzing-specific-scenarios

Di seguito è riportato un elenco di suggerimenti su cosa controllare se si verificano alcuni problemi di prestazioni. L'elenco non è (purtroppo) completo.

CPU al 100% cpu-at

Se la CPU del sistema è costantemente in esecuzione al 100%, vedi quanto segue:

Memoria insufficiente out-of-memory

Anche se tali errori devono essere rilevati durante lo sviluppo e il test, alcuni scenari possono slittare.

Se la memoria del sistema è quasi esaurita, il problema può essere rilevato in vari modi, tra cui il deterioramento delle prestazioni e messaggi di errore, incluso il testo secondario:

java.lang.OutOfMemoryError

In questi casi verificare:

I/O disco disk-i-o

Se il sistema sta esaurendo lo spazio su disco o si notano problemi di accesso al disco, vedere:

Degradazione delle prestazioni regolare regular-performance-degradation

Se le prestazioni dell’istanza si deteriorano dopo ogni riavvio (a volte una settimana o più tardi), è possibile controllare quanto segue:

Ottimizzazione JVM jvm-tuning

La Java™ Virtual Machine (JVM) è migliorata per quanto riguarda la messa a punto (soprattutto da Java™ 7). Di conseguenza, spesso è opportuno specificare una dimensione JVM fissa ragionevole e utilizzare le impostazioni predefinite.

Se le impostazioni predefinite non sono adatte, è importante stabilire un metodo per monitorare e valutare le prestazioni di GC. Farlo prima di provare a regolare la JVM. Questo processo può includere fattori di monitoraggio, tra cui la dimensione dell’heap, l’algoritmo e altri aspetti.

Alcune scelte comuni sono:

Il registro risultante può essere acquisito da un visualizzatore GC come:

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

Oppure JConsole:

È possibile vedere la quantità di memoria utilizzata, gli algoritmi GC utilizzati, il tempo necessario per l'esecuzione e l'effetto di questo processo sulle prestazioni dell'applicazione. Senza di esso, la messa a punto è solo "manopole che girano casualmente".