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 analizzare i problemi di prestazioni. Di seguito è riportato un elenco di esempi di analisi con 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. Fasi di preparazione

C. Esempi di analisi

D. Conclusione

A. Introduzione

Formato di request.log:

L’AEM 6.5 genera request.log nel seguente formato per impostazione predefinita. 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 "-> " è definito "record di richiesta". Una riga con "< -" è un record di risposta.

Richiedi record:

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 di 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).

Trovare il manuale corrispondente su Interpretazione di request.log.

B. Fasi di preparazione

Passaggio 1: Pulizia dati

Prima di immergerti nell'analisi di request.log, è importante standardizzare i record di registro.

Il primo sed Questo comando rimuove uno spazio aggiuntivo nei record di risposta Content-Type, per evitare la separazione errata dei campi con spazi vuoti. Il comando ruby (vedere [ 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. Record della richiesta con richiesta ID = 0 indica che potrebbero esserci questi tipi di operazioni.

Nell’esempio precedente, gli ID richiesta sono stati reimpostati su 0 a 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 del request.log.

Passaggio 4: Massima elaborazione simultanea

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: Dividere un file di registro

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 request.log contiene tali operazioni. Per eseguire un'analisi accurata e ridurre le dimensioni del file gestito contemporaneamente, suddividere request.log utilizzo dei 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 sed Il comando aggiunge una risposta fittizia ai record di richiesta che non dispongono di 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, sostituisci [ 0-9] {5} con [ 0-9] {6} nel grep per limitare l’accesso a 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 (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 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

Ricerca access.log per i record che corrispondono a un determinato ID richiesta.

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

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