Exemplos de análise de request.log | AEP

Descrição

Ambiente
Experience Manager 6.5

Problema/Sintomas
A 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 Linux (incluindo alguns comandos externos).

Resolução

Índice:
Introdução O formato do request.log

Etapas de preparação

  1. Limpeza de dados
  2. Hora reiniciada
  3. Número de acessos por hora
  4. Processamento simultâneo máximo
  5. Dividir um arquivo de log
  6. Mesclar registros de solicitação e registros de resposta

Exemplos de análise

  1. Os acessos mais pesados
  2. Acessa a resposta ausente
  3. Acessos lentos
  4. Dados da série cronológica do tempo de resposta
  5. Mínimo, média (média), mediana, tempo máximo de resposta
  6. Número de acessos por período
  7. Número de status de resposta por período
  8. URLs mais frequentes
  9. registros access.log para um registro request.log

Conclusão

Introdução

O formato de request.log

AEM 6.5 gera request.log no seguinte formato por padrão. 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, refiro-me a uma linha com "-" como um "registro de solicitação". Uma linha com "-" é um "registro de resposta".

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

Registro de resposta Quando 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 Tipo de conteúdo e o tempo de resposta (em milissegundos).

Consulte também o manual correspondente: https://experienceleague.adobe.com/docs/experience-manager-65/deploying/configuring/monitoring-and-maintaining.html?lang=pt-BR#interpreting-the-request-log

Etapas de preparação:

Etapa 1. Limpeza de dados

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

O primeiro comando sed remove um espaço extra nos registros de resposta Content-Type, para evitar a separação incorreta de campos com espaço em branco. O comando ruby converte o formato de data em ISO 8601. O comando ruby também separa data e hora com espaço em branco em vez de dois pontos.

Etapa 2. Hora reiniciada

Reiniciar AEM e uma instalação de service pack redefine a ID de solicitação do request.log. Os registros de solicitação com ID de solicitação = 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 do request.log.

Etapa 4. Processamento simultâneo máximo

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 Jetty no AEM é definido como 200. Há um atraso na liberação do soquete após concluir a resposta. Quando o número de processamento simultâneo excede aproximadamente 170, ele se torna incapaz de aceitar novas solicitações.

Etapa 5. Dividir um arquivo de log

A ID de solicitação de request.log é redefinida quando AEM é reiniciado ou um Service Pack é instalado. Devido a esse comportamento, a análise pode estar incorreta quando um request.log contém essas operações. Para executar análises precisas 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 ID de solicitação = 0.

Etapa 6. Mesclar registros de solicitação e registros de resposta

Mesclar registros de solicitação e resposta por ID de solicitação facilita a identificação de problemas de desempenho iniciados. Usarei esse arquivo de log mesclado nos exemplos mais recentes.

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

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

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. Acessa a resposta ausente

Extrair acessos sem os registros de resposta correspondentes usando o tempo de resposta fictício.

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

Exemplo 3. Acessos lentos

Extraia acessos que demoraram 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 demoraram mais de 100 segundos.

Exemplo 4. Dados da série cronológica do tempo de resposta

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

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

Exemplo 5. Mínimo, média (média), mediana, tempo máximo de resposta

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 às solicitações de 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 de Publicação.

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 por dez minutos.

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

Procure registros que correspondam a uma ID de solicitação específica.

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

Conclusão

Espero que os exemplos deste artigo o ajudem 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 ou variações diferentes dos comandos. Ajuste-os de acordo com os comandos instalados em seu ambiente.

Nesta página