Esempi di analisi request.log | AEM

Il request.log di Adobe Experience Manager (AEM) è una ricca fonte di informazioni, inclusi i tempi di risposta, che sono fondamentali per l’analisi dei problemi di prestazioni. Questo articolo fornisce diversi esempi per illustrare questo punto.

Descrizione description

Ambiente

Experience Manager 6.5

Problema/Sintomi

Il Adobe Experience Manager (AEM) request.log contiene diverse informazioni utili, ad esempio il tempo di risposta, per l'analisi dei problemi relativi alle prestazioni. Di seguito è riportato un elenco di esempi di analisi che utilizzano comandi Linux (inclusi alcuni comandi esterni come ruby [ 1] e datamash [ 2] ).

Guide all'installazione

[ 1] https://www.ruby-lang.org/en/documentation/installation/

[ 2] https://www.gnu.org/software/datamash/download/

Risoluzione resolution

Sommario

A. Introduzione

B. Passaggi di preparazione

C. Esempi di analisi

G. Conclusione

A. Introduzione

Formato di request.log:

Per impostazione predefinita, AEM 6.5 genera request.log nel seguente formato. A causa di una limitazione del sistema, le righe di comando in questo articolo vengono visualizzate come immagini anziché come testo normale.

Esempio di request.log:

In questo articolo, una riga con "-> " viene definita "record di richiesta". Una riga con "< -" è un record di risposta.

Record richiesta:

Quando una richiesta viene ricevuta dall’AEM, viene registrato un record di richiesta. Contiene la data e l’ora di ricezione, l’ID della richiesta, il metodo di richiesta e l’URL.

Record risposta:

Quando l’AEM risponde a una richiesta, viene registrato un record di risposta. Contiene la data e l’ora della risposta, l’ID della richiesta, il codice di stato, Content-Type e il tempo di risposta (in millisecondi).

Trova il manuale corrispondente su Interpretazione del request.log.

B. Passaggi di preparazione

Passaggio 1. Pulizia dati

Prima di iniziare l'analisi di request.log, è importante standardizzare i record del registro.

Il primo comando sed rimuove uno spazio aggiuntivo nei record di risposta Content-Type, per evitare la separazione errata dei campi con spazi vuoti. Il comando ruby (vedi [ 1] sopra per installare Ruby) converte il formato della data in ISO 8601. Il comando ruby separa anche la data e l'ora con uno spazio vuoto anziché due punti.

Passaggio 2. Ora di riavvio

Il riavvio dell'AEM e l'installazione di un service pack ripristina l'ID richiesta di request.log. I record di richiesta con richiesta ID = 0 indicano che potrebbero essere presenti questi tipi di operazioni.

Nell'esempio precedente, gli ID richiesta sono stati reimpostati su 0 alle ore 13:08:49 e 13:26:13.

Passaggio 3: Numero di accessi all'ora

Contare il numero di accessi all'ora e l'intervallo di tempo di request.log.

Passaggio 4. Elaborazione simultanea massima

Il numero di elaborazioni simultanee consente di indovinare il carico del server dell’AEM.

Per impostazione predefinita, il numero massimo di connessioni simultanee per Jetty in AEM è impostato su 200. Si è verificato un ritardo nel rilascio del socket dopo il completamento della risposta. Quando il numero di elaborazioni simultanee supera circa 170, non può più accettare nuove richieste.

Passaggio 5. Dividi un file di registro

L'ID richiesta di request.log viene reimpostato al riavvio dell'AEM o all'installazione di un Service Pack. A causa di questo comportamento, l'analisi potrebbe non essere corretta quando un request.log contiene tali operazioni. Per eseguire analisi accurate e ridurre le dimensioni del file gestito contemporaneamente, dividere request.log utilizzando i record di richiesta con la richiesta ID = 0.

Passaggio 6. Unisci record di richieste e record di risposta

L’unione dei record di richieste e risposte per ID richiesta semplifica l’individuazione all’avvio dei problemi di prestazioni. Questo file di registro unito verrà utilizzato negli esempi successivi.

L'ultimo comando sed aggiunge una risposta fittizia ai record di richiesta che non hanno un record di risposta corrispondente. Possono essere presenti anche record di risposta senza record di richiesta. Ma sono ignorabili in quanto di solito non sono un problema da indagare.

Il file di registro unito deve essere simile al seguente:

C. Esempi di analisi

Esempio 1. Gli accessi più pesanti

Ordina il file di registro unito in base al tempo di risposta in ordine decrescente, inclusi gli accessi senza risposta.

Esempio 2. Accede alla risposta mancante

Gli accessi estratti non presentano i record di risposta corrispondenti utilizzando il tempo di risposta fittizio.

Se i tempi di ricezione degli accessi senza risposta sono correlati a un aumento del carico del server, questi accessi potrebbero aver provocato problemi di prestazioni.

Esempio 3. Accessi lenti

Estrarre gli accessi che hanno richiesto più di 10 secondi.

Quando il numero di hit è troppo elevato, sostituire [ 0-9] {5} con [ 0-9] {6} nel comando grep per limitare gli accessi che hanno richiesto più di 100 secondi.

Esempio 4. Dati della serie temporale del tempo di risposta

Per creare i grafici, è utile estrarre dai dati solo la marca temporale e il tempo di risposta.

Omettendo gli accessi che hanno risposto immediatamente, i dati diventano più efficienti. Nell'esempio seguente viene estratto l'accesso che ha richiesto più di un secondo.

Esempio 5. Tempo di risposta minimo, medio, mediano, massimo

Nell'esempio precedente viene utilizzato il comando datamash (https://www.gnu.org/software/datamash/) per l'elaborazione statistica. Se il registro contiene accessi senza risposta, il valore fittizio influisce sul risultato.

Esempio 6. Numero di accessi per periodo

Conteggio del numero di accessi per dieci minuti. Il risultato consente di determinare se un traffico elevato ha causato un problema di prestazioni.

Nell'esempio seguente i dati vengono limitati alle sole richieste POST. Un caso d’uso tipico consiste nel determinare se vi è una concentrazione di authoring o replica di contenuti sul livello Publish.

Esempio 7. Numero di stati di risposta per un periodo

Crea una tabella del numero di ciascuno stato di risposta per dieci minuti con il comando datamash.

Esempio 8. URL più frequenti

Stampa i primi tre URL a cui si accedeva più frequentemente in dieci minuti.

Esempio 9. record access.log per un record request.log

Cercare in access.log i record corrispondenti a un determinato ID richiesta.

Se si verificano più accessi contemporaneamente allo stesso URL, il risultato mostra più record access.log per un singolo ID richiesta.

G. Conclusione

Gli esempi contenuti in questo articolo sono utili per analizzare i problemi di prestazioni.

Gli esempi elencati sono stati testati su CentOS 7.5 e Ubuntu 22.04LTS, ma potrebbero non funzionare come previsto a seconda dell’ambiente, ad esempio versioni o varianti diverse dei comandi. Regolarli in base ai comandi installati nell'ambiente.