Monitoramento e manutenção da instância do Adobe Experience Manager monitoring-and-maintaining-your-aem-instance

Depois que as instâncias do AEM forem implantadas, você deverá monitorar e manter a operação, o desempenho e a integridade.

Um fator chave é que, para reconhecer possíveis problemas, você precisa saber como o seu sistema se parece e se comporta sob condições normais. Essa capacidade é melhor realizada monitorando o sistema e coletando informações ao longo do tempo.

Backups backups

É uma boa prática fazer backups de:

Sua empresa provavelmente tem uma política de backup que você segue, considerações adicionais sobre o que e quando fazer backup incluem o seguinte:

Geralmente, um backup completo é feito em intervalos regulares (por exemplo, diariamente, semanalmente ou mensalmente), com backups incrementais entre eles (por exemplo, a cada hora, diariamente ou semanalmente).

Fazendo backup da instalação do software backing-up-your-software-installation

Após a instalação ou alterações significativas na configuração, crie uma backup da instalação do software.

Para fazer isso tarefa, faça backup de toda a sua repositório e, em seguida:

Fazendo backup do repositório backing-up-your-repository

A seção Backup e restauração da documentação do CRX abrange todos os problemas relacionados a backups do repositório do CRX.

Para obter detalhes completos sobre como fazer um backup online dinâmico, consulte Criando um Backup Online.

Limpeza de versão version-purging

A ferramenta Versões de Limpeza serve para limpar as versões de um nó ou de uma hierarquia de nós no seu repositório. Seu principal objetivo é ajudá-lo a reduzir o tamanho do repositório removendo versões antigas dos nós.

Esta seção trata das operações de manutenção relacionadas ao recurso de controle de versão do AEM. A ferramenta Limpar Versão destina-se a limpar as versões de um nó ou uma hierarquia de nós no seu repositório. Seu principal objetivo é ajudá-lo a reduzir o tamanho do repositório removendo versões antigas dos nós.

Visão geral overview

A ferramenta Versões de Limpeza está disponível como uma tarefa de manutenção semanal. Antes de usar o pela primeira vez, ele deve ser adicionado e configurado. Depois disso, ele poderá ser executado mediante solicitação ou semanalmente.

Expurgando Versões de um Site purging-versions-of-a-web-site

Para expurgar versões de um site, proceda da seguinte forma:

Dry Run - Análise do console analyzing-the-console

A interface clássica fornece uma opção de Execução Seca de:

O processo lista todos os nós que foram processados. Durante o processo, um nó pode ter um dos seguintes status:

Além disso, o console fornece informações úteis sobre as versões:

No exemplo a seguir:

Trabalhar com registros de auditoria e arquivos de log working-with-audit-records-and-log-files

Registros de auditoria e arquivos de log relacionados ao Adobe Experience Manager (AEM) podem ser encontrados em vários locais. O seguinte é fornecido para lhe dar uma visão geral do que você pode encontrar e onde pode encontrá-lo.

Trabalhar com logs working-with-logs

O WCM do AEM registra logs detalhados. Depois de descompactar e iniciar o Quickstart, você pode encontrar logs em:

Rotação de arquivo de log log-file-rotation

Rotação de arquivos de registro refere-se ao processo que limita o crescimento do arquivo criando um arquivo periodicamente. No AEM, um arquivo de log chamado error.log é girado uma vez por dia de acordo com as regras fornecidas:

Localizando os arquivos de registro finding-the-log-files

Vários arquivos de registro são mantidos no servidor de arquivos em que o AEM foi instalado:

Ativando o Nível de Log DEBUG activating-the-debug-log-level

O nível de log padrão (Configuração de Log do Apache Sling) é Informação, portanto, as mensagens de depuração não são registradas.

Para ativar o nível de log de depuração de um Agente de Log, defina a propriedade org.apache.sling.commons.log.level como debug no repositório. Por exemplo, em /libs/sling/config/org.apache.sling.commons.log.LogManager para configurar o Log global do Apache Sling.

Uma linha no arquivo de depuração geralmente começa com DEBUG, em seguida, fornece o nível de log, a ação do instalador e a mensagem de log. Por exemplo:

DEBUG 3 WebApp Panel: WebApp successfully deployed

Os níveis de log são os seguintes:

Criar um arquivo de log personalizado create-a-custom-log-file

Em determinadas circunstâncias, talvez você queira criar um arquivo de log personalizado com um nível de log diferente. No repositório, faça o seguinte:

O Felix Console também fornece informações sobre o Suporte ao Log do Sling em ../system/console/slinglog; por exemplo, https://localhost:4502/system/console/slinglog.

Localizando os Registros de Auditoria finding-the-audit-records

Os registros de auditoria são mantidos para fornecer um registro de quem fez o que e quando. Registros de auditoria diferentes são gerados para eventos AEM WCM e OSGi.

Registros de auditoria WCM do AEM exibidos ao criar páginas aem-wcm-audit-records-shown-when-page-authoring

Registros de auditoria AEM WCM no repositório aem-wcm-auditing-records-within-the-repository

Na pasta /var/audit, os registros de auditoria são mantidos de acordo com o recurso. Você pode fazer drill-down até ver registros individuais e as informações que eles contêm.

Essas entradas contêm as mesmas informações que são exibidas ao editar uma página.

Registros de auditoria OSGi no console da Web osgi-audit-records-from-the-web-console

Os eventos OSGi também geram registros de auditoria que podem ser vistos na guia Status da configuração > Arquivos de log no Console da Web do AEM:

Monitorar os agentes de replicação monitoring-your-replication-agents

Você pode monitorar as filas de replicação para detectar quando uma fila está inativa ou bloqueada, o que, por sua vez, pode indicar um problema com uma instância de publicação ou sistema externo:

Para monitorar um agente de replicação:

Novamente, você pode desenvolver uma solução para detectar todos os agentes de replicação (localizados em /etc/replication/author ou /etc/replication/publish) e, em seguida, verificar o status do agente ( enabled, disabled) e da fila subjacente ( active, idle, blocked).

Monitorando o desempenho monitoring-performance

Otimização de Desempenho é um processo interativo que recebe foco durante o desenvolvimento. Após a implantação, ela é revisada após intervalos ou eventos específicos.

Métodos usados ao coletar informações para otimização também podem ser usados para monitoramento contínuo.

A seguir, uma lista de problemas comuns de desempenho que ocorrem, juntamente com propostas sobre como detectá-los e neutralizá-los.

Os problemas de desempenho podem resultar de várias causas que não têm nada a ver com o seu site, incluindo lentidão temporária na velocidade da conexão, carga da CPU e muito mais.

Também pode afetar todos os visitantes ou somente um subconjunto deles.

Todas essas informações devem ser obtidas, classificadas e analisadas antes que você possa otimizar o desempenho geral ou resolver problemas específicos.

Ferramentas para Monitorar e Analisar Desempenho tools-for-monitoring-and-analyzing-performance

A seguir há uma breve visão geral de algumas das ferramentas disponíveis para monitorar e analisar o desempenho.

Algumas dessas ferramentas dependem do sistema operacional.

Interpretando o request.log interpreting-the-request-log

Esse arquivo registra informações básicas sobre cada solicitação feita ao AEM. Daí podem ser extraídas conclusões valiosas.

O request.log oferece uma maneira integrada de verificar quanto tempo as solicitações levam. Para fins de desenvolvimento, é útil tail -f o request.log e observar tempos de resposta lentos. Para analisar um request.log maior, a Adobe recomenda o uso de rlog.jar, que permite classificar e filtrar os tempos de resposta.

A Adobe recomenda isolar as páginas "lentas" do request.log e ajustá-las individualmente para obter um melhor desempenho. Inclua métricas de desempenho por componente ou use uma ferramenta de criação de perfil de desempenho como o [yourkit](https://www.yourkit.com/).

Monitoramento de tráfego em seu site monitoring-traffic-on-your-website

O log de solicitação registra cada solicitação feita, juntamente com a resposta feita:

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

Ao totalizar todas as entradas de GET em períodos específicos (por exemplo, em vários períodos de 24 horas), você pode fazer declarações sobre o tráfego médio no seu site.

Monitoramento dos tempos de resposta com o request.log monitoring-response-times-with-the-request-log

Um bom ponto de partida para a análise de desempenho é o registro de solicitações:

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

O registro tem a seguinte aparência (as linhas são encurtadas para simplificar):

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

Este log tem uma linha por solicitação ou resposta:

Usando scripts pequenos, você pode extrair as informações necessárias do arquivo de log e montar as estatísticas desejadas. Nessas estatísticas, é possível ver quais páginas ou tipos de páginas estão lentas e se o desempenho geral é satisfatório.

Monitoramento dos tempos de resposta de pesquisa com o request.log monitoring-search-response-times-with-the-request-log

As solicitações de pesquisa também são registradas no arquivo de log:

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

Assim, como acima, você pode usar scripts para extrair as informações relevantes e criar estatísticas.

No entanto, após determinar o tempo de resposta, analise por que a solicitação está demorando e o que pode ser feito para melhorar a resposta.

Monitoramento do número e do impacto de usuários simultâneos monitoring-the-number-and-impact-of-concurrent-users

Novamente, o request.log pode ser usado para monitorar a simultaneidade e a reação do sistema a ele.

Testes devem ser feitos para determinar quantos usuários simultâneos o sistema pode manipular antes que um impacto negativo seja visto. Novamente, os scripts podem ser usados para extrair resultados do arquivo de log:

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

Usar rlog.jar para encontrar solicitações com tempos de longa duração using-rlog-jar-to-find-requests-with-long-duration-times

O AEM inclui várias ferramentas auxiliares no seguinte:
<cq-installation-dir>/crx-quickstart/opt/helpers

Uma dessas ferramentas, rlog.jar, pode ser usada para classificar rapidamente request.log de modo que as solicitações sejam exibidas por duração, do mais longo ao menor tempo.

O comando a seguir mostra os argumentos possíveis:

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

Por exemplo, você pode executá-lo especificando o arquivo request.log como parâmetro e mostrar as dez primeiras solicitações que têm a duração mais longa:

$ 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

Concatene os arquivos request.log individuais se precisar fazer essa operação em uma amostra de dados grande.

Apache Bench apache-bench

Para minimizar o impacto de casos especiais (como coleta de lixo), é recomendável usar uma ferramenta como o apachebench (por exemplo, ab para documentação adicional) para ajudar a identificar vazamentos de memória e analisar seletivamente o tempo de resposta.

O Apache Bench pode ser usado da seguinte maneira:

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

Os números acima são retirados de um notebook MAcBook Pro padrão (meados de 2010) que acessa a página da empresa Geometrixx, conforme incluído em uma instalação padrão do AEM. A página é simples, mas não otimizada para desempenho.

O apachebench também exibe o tempo por solicitação como a média em todas as solicitações simultâneas; consulte Time per request: 54.595 [ms] (média em todas as solicitações simultâneas). Você pode alterar o valor do parâmetro de simultaneidade -c (número de várias solicitações a serem executadas de cada vez) para ver os efeitos.

Contadores de solicitações request-counters

Informações sobre o tráfego de solicitações (número de solicitações durante um período específico) fornecem uma indicação da carga na instância. Estas informações podem ser extraídas de request.log, embora o uso de contadores automatize a coleta de dados para permitir que você veja:

Para automatizar a coleta de informações, você também pode instalar um RequestFilter para incrementar um contador em cada solicitação. Vários contadores podem ser usados para diferentes períodos.

As informações recolhidas podem ser utilizadas para indicar:

Comentários HTML html-comments

É recomendável que todos os projetos incluam html comments para desempenho de servidor. Muitos bons exemplos públicos podem ser encontrados. Selecione uma página, abra a origem da página para exibição e role até a parte inferior. Códigos como os seguintes podem ser vistos:

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

Monitorando o desempenho usando o JConsole monitoring-performance-using-jconsole

O comando de ferramenta jconsole está disponível com o JDK.

Monitoramento do desempenho usando (J)VisualVM monitoring-performance-using-j-visualvm

Para o JDK 6-8, o comando de ferramenta visualvm está disponível. Depois de instalar um JDK, você pode fazer o seguinte:

Você pode usar esta ferramenta para gerar despejos de thread e despejos de cabeçote de memória. Essas informações são solicitadas com frequência pela equipe de suporte técnico.

Coleta de informações information-collection

Saber o máximo possível sobre a instalação do pode ajudar a identificar o que pode ter causado uma alteração no desempenho e se essas alterações são justificadas. Colete essas métricas em intervalos regulares para que você possa ver facilmente alterações significativas.

As seguintes informações podem ser úteis:

Quantos autores estão trabalhando com o sistema? how-many-authors-are-working-with-the-system

Para ver o número de autores que usaram o sistema desde a instalação, use a linha de comando:

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

Para ver o número de autores trabalhando em uma determinada data:

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

Qual é o número médio de ativações de página por dia? what-is-the-average-number-of-page-activations-per-day

Para ver o número total de ativações de página desde a instalação do servidor, use uma consulta do repositório; por meio do CRXDE - Ferramentas - Consulta:

Em seguida, calcule o número de dias decorridos desde a instalação para calcular a média.

Quantas páginas você mantém atualmente neste sistema? how-many-pages-do-you-currently-maintain-on-this-system

Para ver o número de páginas atualmente no servidor, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

Se você usa o MSM, qual é o número médio de implantações por mês? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Para determinar o número total de implantações desde a instalação, use uma consulta de repositório; por meio do CRXDE - Ferramentas - Consulta:

Calcule o número de meses decorridos desde a instalação para calcular a média.

Qual é o número médio de Live Copies por mês? what-is-the-average-number-of-live-copies-per-month

Para determinar o número total de Live Copies feitas desde a instalação, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

Use novamente o número de meses decorridos desde a instalação para calcular a média.

Se você usa o AEM Assets, quantos ativos você mantém atualmente no Assets? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Para ver quantos ativos DAM você mantém atualmente, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

Qual é o tamanho médio dos ativos? what-is-the-average-size-of-the-assets

Para determinar o tamanho total da /var/dam pasta:

Quantos modelos são usados atualmente? how-many-templates-are-currently-used

Para ver o número de modelos atualmente no servidor, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

Quantos componentes são usados atualmente? how-many-components-are-currently-used

Para ver o número de componentes atualmente no servidor, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

Quantas solicitações por hora você tem no sistema do autor no horário de pico? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Para determinar as solicitações por hora que você tem no sistema do autor no horário de pico:

Quantas solicitações por hora você tem no sistema de publicação no horário de pico? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Repita o procedimento acima na instância de publicação.

Análise de cenários específicos analyzing-specific-scenarios

Veja a seguir uma lista de sugestões sobre o que verificar se você começa a enfrentar determinados problemas de desempenho. A lista não é (infelizmente) totalmente abrangente.

CPU em 100% cpu-at

Se a CPU do seu sistema estiver em execução constantemente a 100%, consulte o seguinte:

Memória insuficiente out-of-memory

Embora esses erros devam ser detectados durante o desenvolvimento e o teste, alguns cenários podem ser ignorados.

Se o sistema estiver ficando sem memória, esse problema poderá ser observado de várias maneiras, incluindo degradação de desempenho e mensagens de erro, incluindo o subtexto:

java.lang.OutOfMemoryError

Nesses casos, verifique:

E/S de disco disk-i-o

Se o sistema estiver ficando sem espaço em disco ou se você notar hash no disco, consulte:

Degradação regular do desempenho regular-performance-degradation

Se você observar o desempenho da sua instância se deteriorando após cada reinicialização (às vezes, uma semana ou mais tarde), o seguinte pode ser verificado:

Ajuste de JVM jvm-tuning

A Java™ Virtual Machine (JVM) melhorou em relação ao ajuste (especialmente desde o Java™ 7). Dessa forma, geralmente é adequado especificar um tamanho de JVM fixo e razoável e usar os padrões.

Se as configurações padrão não forem adequadas, é importante estabelecer um método para monitorar e avaliar o desempenho de GC. Faça isso antes de tentar ajustar a JVM. Esse processo pode envolver fatores de monitoramento, incluindo tamanho do heap, algoritmo e outros aspectos.

Algumas opções comuns são:

O log resultante pode ser assimilado por um visualizador de GC, como:

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

Ou JConsole:

Você pode ver quanta memória está sendo usada, quais algoritmos de GC estão sendo usados, quanto tempo eles levam para serem executados e qual efeito esse processo tem no desempenho do aplicativo. Sem ele, o ajuste é apenas "aleatoriamente girando botões".