Exemplos de análise request.log | AEM

O request.log do Adobe Experience Manager (AEM) é uma fonte rica de informações, incluindo tempos de resposta, que é crucial para analisar problemas de desempenho. Este artigo fornece vários exemplos para ilustrar esse ponto.

Descrição description

Ambiente

Experience Manager 6.5

Problema/Sintomas

O Adobe Experience Manager (AEM) request.log contém várias informações úteis, como tempo de resposta, para analisar os problemas de desempenho. Esta é uma lista de exemplos de análise usando comandos do Linux (incluindo alguns comandos externos, como ruby [ 1] e datamash [ 2] ).

Guias de instalação

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

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

Resolução resolution

Sumário

A Introdução

B Etapas de preparação

C Exemplos de análise

D Conclusão

A Introdução

O formato do request.log:

Por padrão, o AEM 6.5 gera request.log no seguinte formato. Devido a uma limitação do sistema, as linhas de comando neste artigo são mostradas como imagens em vez de texto sem formatação.

Exemplo de request.log:

Neste artigo, uma linha com "-> " é chamada de "registro de solicitação". Uma linha com "< -" é um "registro de resposta".

Solicitar registro:

Quando uma solicitação é recebida pelo AEM, um registro de solicitação é registrado. Ela contém a data e a hora do recebimento, o ID da solicitação, o método de solicitação e o URL.

Registro de Resposta:

Quando o AEM responde a uma solicitação, um registro de resposta é registrado. Ele contém a data e a hora da resposta, a ID da solicitação, o código do status, o Content-Type e o tempo de resposta (em milissegundos).

Localize o manual correspondente em Interpretando request.log.

B Etapas de preparação

Etapa 1. Limpeza de dados

Antes de mergulhar na análise de request.log, é importante padronizar os registros de log.

O primeiro comando sed remove um espaço extra no tipo de conteúdo dos registros de resposta, para evitar a separação incorreta de campos com espaços em branco. O comando ruby (consulte [ 1] acima para instalar o Ruby) converte o formato de data para ISO 8601. O comando ruby também separa data e hora com espaço em branco em vez de dois-pontos.

Etapa 2. Tempo reiniciado

Reiniciar o AEM e uma instalação de service pack redefine a ID de solicitação de request.log. Os registros de solicitação com a solicitação ID = 0 indicam que pode haver esses tipos de operação.

No exemplo acima, as IDs de solicitação foram redefinidas para 0 em 13:08:49 e 13:26:13.

Etapa 3. Número de acessos por hora

Conte o número de acessos por hora e o intervalo de tempo de request.log.

Etapa 4. Máximo de processamento simultâneo

O número de processamento simultâneo ajuda a adivinhar a carga do servidor de AEM.

Por padrão, o número máximo de conexões simultâneas para o Jetty no AEM é definido como 200. Há um atraso na liberação do soquete após concluir a resposta. Quando o número de processamentos simultâneos exceder aproximadamente 170, ele não poderá mais aceitar novas solicitações.

Etapa 5. Dividir um arquivo de log

A ID de solicitação de request.log é redefinida quando o AEM é reiniciado ou um Service Pack é instalado. Devido a este comportamento, a análise pode estar incorreta quando um request.log contém tais operações. Para executar uma análise precisa e reduzir o tamanho do arquivo que está sendo manipulado de uma só vez, divida o request.log usando registros de solicitação com a solicitação ID = 0.

Etapa 6. Registros de solicitação de mesclagem e registros de resposta

A mesclagem de registros de solicitação e resposta pela ID de solicitação facilita a identificação do início dos problemas de desempenho. Esse arquivo de log mesclado será usado nos exemplos posteriores.

O último comando sed adiciona uma resposta fictícia para solicitar registros que não têm um registro de resposta correspondente. Também pode haver registros de resposta sem registros de solicitação. Mas eles são ignoráveis, pois normalmente não são um assunto para investigação.

O arquivo de log mesclado deve ter esta aparência:

C Exemplos de análise

Exemplo 1. Os acessos mais pesados

Classifique o arquivo de log mesclado por tempo de resposta em ordem decrescente, incluindo acessos sem resposta.

Exemplo 2. Acessos sem resposta

Acessos de extração não têm os registros de resposta correspondentes usando o tempo de resposta de teste.

Se o tempo de recebimento de acessos sem resposta estiver correlacionado com um aumento na carga do servidor, esses acessos podem ter causado problemas de desempenho.

Exemplo 3. Acessos lentos

Extrair acessos que levaram mais de 10 segundos.

Quando o número de ocorrências for muito alto, substitua [ 0-9] {5} por [ 0-9] {6} no comando grep para restringir a acessos que levaram mais de 100 segundos.

Exemplo 4. Dados de série temporal do tempo de resposta

Extrair apenas o carimbo de data e hora e o tempo de resposta dos dados é útil para criar gráficos.

Omitir os acessos que responderam imediatamente torna os dados mais eficientes. O exemplo a seguir extrai um acesso que levou mais de um segundo.

Exemplo 5. Tempo de resposta mínimo, médio, mediano e máximo

O exemplo acima usa o comando datamash (https://www.gnu.org/software/datamash/) para processamento estatístico. Se o log contiver acessos sem resposta, o valor fictício influenciará o resultado.

Exemplo 6. Número de acessos por período

Conte o número de acessos por dez minutos. O resultado ajuda a determinar se um tráfego grande causou um problema de desempenho.

O exemplo a seguir restringe os dados somente a solicitações POST. Um caso de uso típico é determinar se há uma concentração de criação ou replicação de conteúdo no nível do Publish.

Exemplo 7. Número de status de resposta por período

Crie uma tabela do número de cada status de resposta por dez minutos com o comando datamash.

Exemplo 8. URLs mais frequentes

Imprima os três principais URLs que foram acessados com mais frequência a cada dez minutos.

Exemplo 9. registros access.log para um registro request.log

Pesquise access.log por registros que correspondam a uma ID de solicitação específica.

Se houver vários acessos ao mesmo URL ao mesmo tempo, o resultado mostrará vários registros access.log para uma única ID de solicitação.

D Conclusão

Os exemplos neste artigo devem ajudar você a analisar seus problemas de desempenho.

Os exemplos listados foram testados no CentOS 7.5 e no Ubuntu 22.04LTS, mas podem não funcionar conforme esperado dependendo do seu ambiente, como versões diferentes ou variações dos comandos. Ajuste-os de acordo com os comandos instalados em seu ambiente.