Painel de operações

Introdução

O Painel de Operações no AEM 6 ajuda os operadores do sistema a monitorar AEM integridade do sistema imediatamente. Ele também fornece informações de diagnóstico geradas automaticamente sobre aspectos relevantes do AEM e permite configurar e executar automação de manutenção independente para reduzir significativamente as operações do projeto e os casos de suporte. O Painel de Operações pode ser estendido com verificações de integridade personalizadas e tarefas de manutenção. Além disso, os dados do Painel de operações podem ser acessados a partir de ferramentas de monitoramento externas via JMX.

O Painel de Operações:

  • É um status de sistema com um clique para ajudar os departamentos de operações a aumentar a eficiência
  • Fornece uma visão geral da integridade do sistema em um único local centralizado
  • Reduz o tempo para localizar, analisar e corrigir problemas
  • Fornece automação de manutenção independente que ajuda a reduzir significativamente os custos das operações do projeto

Ele pode ser acessado indo até Ferramentas - Operações na tela AEM Welcome .

OBSERVAÇÃO

Para poder acessar o Painel de Operações, o usuário conectado deve fazer parte do grupo de usuários "Operadores". Para obter mais informações, consulte a documentação em Administração de usuário, grupo e direito de acesso.

Relatórios de integridade

O sistema de Relatório de Integridade fornece informações sobre a integridade de uma instância de AEM por meio de Sling Health Checks. Isso pode ser feito por meio de solicitações OSGI, JMX, HTTP (via JSON) ou pela interface de toque. Ele oferece medidas e o limite de determinados contadores configuráveis e, em alguns casos, oferecerá informações sobre como resolver o problema.

Ela tem vários recursos, descritos abaixo.

Verificações de integridade

O Relatórios de integridade são um sistema de cartões que indica uma boa ou má saúde em relação a uma determinada área de produtos. Esses cartões são visualizações das Verificações de integridade do Sling, que agregam dados do JMX e de outras fontes e expõem as informações processadas novamente como MBeans. Esses MBeans também podem ser inspecionados no Console da Web JMXnos termos do org.apache.sling.health.check domínio.

A interface dos Relatórios de integridade pode ser acessada por meio do Ferramentas - Operações - Relatórios de integridade na tela de Boas-vindas AEM ou diretamente pelo seguinte URL:

https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html

chlimage_1-116

O sistema de cartões expõe três estados possíveis: OK, AVISO e CRÍTICO. Os estados são resultado de regras e limites, que podem ser configurados ao passar o mouse sobre o cartão e clicar no ícone de engrenagem na barra de ação:

chlimage_1-117

Tipos de Verificação de Integridade

Existem dois tipos de controlos sanitários no AEM 6:

  1. Verificações de integridade individual
  2. Verificações de integridade composta

Um Verificação de integridade individual é uma única verificação de integridade que corresponde a um cartão de status. As Verificações de Integridade Individual podem ser configuradas com regras ou limites e podem fornecer uma ou mais dicas e links para resolver problemas de integridade identificados. Vamos considerar a verificação "Erros de registro" como um exemplo: se houver entradas ERROR nos logs da instância, você as encontrará na página de detalhes da verificação de integridade. Na parte superior da página, você verá um link para o analisador de "Mensagem de log" na seção Ferramentas de diagnóstico, que permitirá que você analise esses erros com mais detalhes e reconfigure os registradores.

A Verificação de integridade composta é uma verificação que agrega informações de várias verificações individuais.

Os controlos sanitários compostos são configurados com o auxílio de filtrar tags. Em essência, todas as verificações únicas que têm a mesma tag de filtro serão agrupadas como uma verificação de integridade composta. Uma Verificação de integridade composta terá um status OK somente se todas as verificações únicas que ela agregar tiverem status OK também.

Como criar verificações de integridade

No Painel de Operações, é possível visualizar o resultado de Verificações de Integridade individuais e compostas.

Criação de uma verificação de integridade individual

A criação de uma Verificação de Integridade individual envolve duas etapas: implementando uma Verificação de Integridade do Sling e adicionando uma entrada para a Verificação de Integridade nos nós de configuração do Dashboard.

  1. Para criar uma Verificação de Integridade do Sling, é necessário criar um componente OSGI implementando a interface do Sling HealthCheck. Você adicionará esse componente dentro de um pacote. As propriedades do componente identificarão totalmente a Verificação de integridade. Quando o componente estiver instalado, um MBean JMX será criado automaticamente para a verificação de integridade. Consulte a Documentação de verificação de integridade do Sling para obter mais informações.

    Exemplo de um componente de Verificação de integridade do Sling, gravado com anotações do componente de serviço OSGI:

    @Component(service = HealthCheck.class,
    property = {
        HealthCheck.NAME + "=Example Check",
        HealthCheck.TAGS + "=example",
        HealthCheck.TAGS + "=test",
        HealthCheck.MBEAN_NAME + "=exampleHealthCheckMBean"
    })
     public class ExampleHealthCheck implements HealthCheck {
        @Override
        public Result execute() {
            // health check code
        }
     }
    
    OBSERVAÇÃO

    O MBEAN_NAME define o nome do mbean que será gerado para esta verificação de integridade.

  2. Depois de criar uma Verificação de integridade, um novo nó de configuração precisa ser criado para torná-lo acessível na interface do Painel de operações. Para esta etapa, é necessário conhecer o nome do Feijão JMX da Verificação de Integridade (o MBEAN_NAME propriedade). Para criar uma configuração para a Verificação de integridade, abra o CRXDE e adicione um novo nó (do tipo nt:unstructured) no seguinte caminho: /apps/settings/granite/operations/hc

    As seguintes propriedades devem ser definidas no novo nó:

    • Nome: sling:resourceType

      • Tipo: String
      • Valor: granite/operations/components/mbean
    • Nome: resource

      • Tipo: String
      • Valor: /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
    OBSERVAÇÃO

    O caminho do recurso acima é criado da seguinte maneira: se o nome do bean da sua verificação de integridade for "teste", adicione "teste" ao final do caminho /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck

    Assim, o caminho final será:

    /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test

    OBSERVAÇÃO

    Certifique-se de que a variável /apps/settings/granite/operations/hc path tem as seguintes propriedades definidas como true:

    sling:configCollectionInherit

    sling:configPropertyInherit

    Isso instruirá o gerenciador de configuração a mesclar as novas configurações com as existentes de /libs.

Criando uma Verificação de Integridade Composta

A função de uma verificação de integridade composta é agregar várias verificações de integridade individuais que compartilham um conjunto de recursos comuns. Por exemplo, a Verificação de Integridade Composta de Segurança agrupa todas as verificações de integridade individuais que realizam verificações relacionadas com a segurança. A primeira etapa para criar uma verificação composta é adicionar uma nova configuração OSGI. Para ser exibido no Painel de operações, um novo nó de configuração precisa ser adicionado, da mesma forma que fizemos para uma verificação simples.

  1. Vá para o Web Configuration Manager no console OSGI. Você pode fazer isso acessando https://serveraddress:port/system/console/configMgr

  2. Procure a entrada chamada Verificação de integridade composta do Apache Sling. Depois de encontrá-lo, observe que há duas configurações já disponíveis: um para as verificações do sistema e outro para as verificações de segurança.

  3. Crie uma nova configuração pressionando o botão "+" no lado direito da configuração. Uma nova janela será exibida, conforme mostrado abaixo:

    chlimage_1-23

  4. Crie uma configuração e salve-a. Um Mbean será criado com a nova configuração.

    A finalidade de cada propriedade de configuração é a seguinte:

    • Nome (hc.name): O nome da verificação de integridade composta. Recomenda-se um nome significativo.
    • Tags (hc.tags): As tags para esta Verificação de Integridade. Se esta verificação de integridade composta se destinar a ser parte de outra verificação de integridade composta (como em uma hierarquia de verificações de integridade), adicione as tags às quais esse composto está relacionado.
    • Nome do MBean (hc.mbean.name): O nome do Mbean que será fornecido ao MBean JMX dessa verificação de integridade composta.
    • Tags de filtro (filter.tags): Esta é uma propriedade específica para verificações de integridade compostas. Essas são as tags que o compósito deve agregar. A verificação de integridade composta agregará sob seu grupo todas as verificações de integridade que tenham qualquer tag correspondente a qualquer uma das tags de filtro desse composto. Por exemplo, uma verificação de integridade composta com as tags de filtro teste e check agregará todos os controlos de saúde individuais e compostos que tenham qualquer um dos teste e check tags em sua propriedade de tags ( hc.tags).
    OBSERVAÇÃO

    Um novo Mbean JMX é criado para cada nova configuração da Verificação de integridade composta do Apache Sling.**

  5. Finalmente, a entrada da verificação de integridade composta que acabou de ser criada precisa ser adicionada nos nós de configuração do Painel de Operações . O procedimento para o efeito é o mesmo que os controlos sanitários individuais: um nó do tipo nt:unstructured precisa ser criada em /apps/settings/granite/operations/hc. A propriedade resource do nó será definida pelo valor de hc.average.name na configuração OSGI.

    Se, por exemplo, você criou uma configuração e definiu a variável hc.mbean.name para diskusage, os nós de configuração terão esta aparência:

    • Nome: Composite Health Check

      • Tipo: nt:unstructured

    Com as seguintes propriedades:

    • Nome: sling:resourceType

      • Tipo: String
      • Valor: granite/operations/components/mbean
    • Nome: resource

      • Tipo: String
      • Valor: /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
    OBSERVAÇÃO

    Se você criar verificações de integridade individuais que logicamente pertencem a uma verificação composta que já está presente no Painel por padrão, elas serão automaticamente capturadas e agrupadas na respectiva verificação composta. Por causa disso, não há necessidade de criar um novo nó de configuração para essas verificações.

    Por exemplo, se você criar uma verificação de integridade de segurança individual, tudo o que precisa fazer é atribuir a ela o "segurança" e estiver instalado, ele aparecerá automaticamente na verificação composta de Verificações de Segurança no Painel de Operações.

Verificações de integridade fornecidas com AEM

Nome da verificação de integridade Descrição
Desempenho da consulta

Este exame de saúde foi simplificado no AEM 6.4e agora verifica a função recém-refatorada Oak QueryStats MBean, mais especificamente o SlowQueries atributo. Se as estatísticas contiverem queries lentos, a verificação de integridade retornará um aviso. Caso contrário, retorna o status OK.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=queriesStatus,type=HealthCheck.

Comprimento da fila de observação

A Duração da Fila de Observação é repetida em todos os Ouvintes de Eventos e Observadores de Plano de Fundo, e compara seus queueSize para maxQueueSize e:

  • retorna o status Crítico se a variável queueSize excede o valor maxQueueSize valor (é quando os eventos são soltos)
  • retorna Avisar se a variável queueSize é maior que maxQueueSize * WARN_THRESHOLD (o valor padrão é 0,75)

O comprimento máximo de cada fila provém de configurações separadas (Oak e AEM) e não é configurável a partir dessa verificação de integridade. O MBean para esta verificação de integridade é org.apache.sling.health check:name=ObservationQueueLengthHealthCheck,type=HealthCheck.

Limites de cruzamento da consulta

Limites de passagem de consulta verifica o QueryEngineSettings MBean, mais especificamente o LimitInMemory e LimitReads e retorna o seguinte status:

  • retorna o status Warn se um dos limites for igual ou superior a Integer.MAX_VALUE
  • retorna o status Warn se um dos limites for menor que 10000 (a configuração recomendada do Oak)
  • retorna o status Crítico se a variável QueryEngineSettings ou qualquer um dos limites não pode ser recuperado

O Mbean para este exame de saúde é org.apache.sling.health check:name=queryTraversalLimitsBundle,type=HealthCheck.

Relógios sincronizados

Esta verificação é relevante apenas para clusters de nodestore de documentos. Ele retorna o seguinte status:

  • retorna o status Warn quando os relógios da instância ficam fora de sincronia e passam por um limite baixo predefinido
  • retorna o status Crítico quando os relógios de instância ficam fora de sincronia e ultrapassam um limite alto predefinido

O Mbean para este exame de saúde é org.apache.sling.health check:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck.

Índices assíncronos

A verificação de Índices Assíncronos:

  • retorna o status Crítico se pelo menos uma faixa de indexação estiver falhando
  • verifica a lastIndexedTime para todas as vias de indexação e:
    • retorna o status Crítico se tiver mais de 2 horas atrás
    • retorna o status Warning se estiver entre 2 horas e 45 minutos atrás
    • retorna o status OK se for inferior a 45 minutos atrás
  • se nenhuma dessas condições for atendida, retornará o status OK

Os limites de status Crítico e Aviso podem ser configurados. O Mbean para este exame de saúde é org.apache.sling.health check:name=asyncIndexHealthCheck,type=HealthCheck.

Observação: Esta verificação de integridade está disponível com o AEM 6.4 e foi transferida para o AEM 6.3.0.1.

Índices Lucene grandes

Essa verificação usa os dados expostos pela variável Lucene Index Statistics MBean para identificar índices e retornos grandes:

  • um status de Aviso se houver um índice com mais de 1 bilhão de documentos
  • um status Crítico se houver um índice com mais de 1,5 bilhão de documentos

Os limites são configuráveis e o MBean para a verificação de integridade é org.apache.sling.health check:name=largeIndexHealthCheck,type=HealthCheck.

Observação: Essa verificação está disponível com o AEM 6.4 e foi transferida para o AEM 6.3.2.0.

Manutenção do sistema

System Maintenance (Manutenção do sistema) é uma verificação composta que retorna o OK se todas as tarefas de manutenção estiverem sendo executadas como configuradas. Lembre-se:

  • cada tarefa de manutenção é acompanhada de um exame de saúde associado
  • se uma tarefa não for adicionada a uma janela de manutenção, sua verificação de integridade retornará Crítico
  • é necessário configurar as tarefas de manutenção Log de auditoria e Expurgação do fluxo de trabalho ou removê-las das janelas de manutenção. Se deixadas não configuradas, essas tarefas falharão na primeira execução tentada, de modo que a verificação de Manutenção do Sistema retornará o status Crítico.
  • Com AEM 6.4, também há uma verificação para o Manutenção de binários Lucene tarefa
  • em AEM 6.2 e inferior, a verificação de manutenção do sistema retorna um status Warning logo após a inicialização, pois as tarefas nunca são executadas. A partir da versão 6.3, eles retornarão OK se a primeira janela de manutenção ainda não tiver sido atingida.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=systemcontrols,type=HealthCheck.

Fila de replicação

Essa verificação repete os agentes de replicação e observa suas filas. Para o item na parte superior da fila, a verificação verifica quantas vezes o agente tentou novamente a replicação. Se o agente tiver tentado novamente a replicação mais do que o valor da numberOfRetriesAllowed , retorna um aviso. O numberOfRetriesAllowed é configurável.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=replicationQueue,type=HealthCheck.

Sling Jobs
O Sling Jobs verifica o número de tarefas enfileiradas no JobManager, o compara ao maxNumQueueJobs limite e:
  • retorna Crítico se for maior que a variável maxNumQueueJobs estão na fila
  • retorna Crítico se houver trabalhos ativos de longa duração com mais de 1 hora
  • retorna Crítico se houver trabalhos em fila e o último horário de trabalho concluído for superior a 1 hora

Somente o parâmetro de número máximo de trabalhos em fila é configurável e tem o valor padrão de 1000.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=slingJobs,type=HealthCheck.

Desempenho da solicitação

Essa verificação analisa o granite.request.metrics.timer Métrica Sling e:

  • retorna Crítico se o valor do percentil 75 estiver acima do limite crítico (o valor padrão é 500 milissegundos)
  • retorna Warn se o valor do percentil 75 estiver acima do limite de aviso (o valor padrão é 200 milissegundos)

O MBean para esta verificação de integridade é org.apache.sling.health check:name=requestsStatus,type=HealthCheck.

Erros de log

Essa verificação retorna o status Warn se houver erros no log.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=logErrorHealthCheck,type=HealthCheck.

Espaço em disco

A verificação do Espaço em Disco verifica o FileStoreStats O MBean recupera o tamanho do armazenamento de nós e a quantidade de espaço em disco utilizável na partição do armazenamento de nós, e:

  • retorna Warn se a proporção de espaço em disco utilizável para o tamanho do repositório for menor que o limite de aviso (o valor padrão é 10)
  • retorna Crítico se a proporção de espaço em disco utilizável para o tamanho do repositório for menor que o limite crítico (o valor padrão é 2)

Ambos os limites são configuráveis. A verificação só funciona em instâncias com uma Loja de segmentos.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=DiskSpaceHealthCheck,type=HealthCheck.

Verificação de integridade do assistente de agendamento

Essa verificação retornará um aviso se a instância tiver trabalhos do Quartz em execução por mais de 60 segundos. O limite de duração aceitável é configurável.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=slingCommonsSchedulerHealthCheck,type=HealthCheck.

Verificações de segurança

A verificação de segurança é um composto que agrega os resultados de várias verificações relacionadas à segurança. Estes controlos de saúde individuais abordam preocupações diferentes da lista de controlo de segurança disponível no Página de documentação da Lista de verificação de segurança. A verificação é útil como um teste de segurança de fumaça quando a instância é iniciada.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=securityCheck,type=HealthCheck

Grupos ativos

Os Pacotes Ativos verificam o estado de todos os pacotes e:

  • retorna o status Warn se qualquer um dos pacotes não estiver ativo ou (iniciando, com ativação lenta)
  • ele ignora o status dos pacotes na lista de ignorados

O parâmetro ignore list pode ser configurado.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=inativeBundles,type=HealthCheck.

Verificação do Cache de Código

Esta é uma Verificação de integridade que verifica várias condições da JVM que podem acionar um bug do CodeCache presente no Java 7:

  • retorna Avisar se a instância estiver sendo executada no Java 7, com a limpeza do Cache de Código ativada
  • retorna Avisar se a instância estiver sendo executada no Java 7 e o tamanho do Cache de Código Reservado for menor que um limite mínimo (o valor padrão é 90 MB)

O minimum.code.cache.size limite é configurável. Para obter mais informações sobre o erro, check esta página.

O MBean para esta verificação de integridade é org.apache.sling.health check:name=codeCacheHealthCheck,type=HealthCheck.

Recurso Buscar erros de caminho

Verifica se há recursos no caminho /apps/foundation/components/primary e:

  • retorna Avisar se houver nós secundários em /apps/foundation/components/primary

O MBean para esta verificação de integridade é org.apache.sling.health check:name=resourceSearchPathErrorHealthCheck,type=HealthCheck.

Configuração da Verificação de Integridade

Por padrão, para uma instância AEM predefinida, as verificações de integridade são executadas a cada 60 segundos.

Você pode configurar o Período com o Configuração do OSGi Configuração da Verificação de Integridade da Consulta (com.adobe.granite.queries.impl.hc.QueryHealthCheckMetrics).

Monitoramento com o Nagios

O Painel de verificação de integridade pode se integrar ao Nagios por meio do Granite JMX Mbeans. O exemplo abaixo ilustra como adicionar uma verificação que mostra a memória usada no servidor que está executando o AEM.

  1. Configure e instale o Nagios no servidor de monitoramento.

  2. Em seguida, instale o NRPE (Executor de Plug-in Remoto do Nagios).

    OBSERVAÇÃO

    Para obter mais informações sobre como instalar Nagios e NRPE em seu sistema, consulte o Documentação do Nagios.

  3. Adicione uma definição de host para o servidor AEM. Isso pode ser feito por meio da Interface Web Nagios XI, usando o Gerenciador de configuração:

    1. Abra um navegador e aponte para o servidor Nagios.
    2. Pressione a tecla Configurar no menu superior.
    3. No painel esquerdo, pressione a tecla Gerenciador de configuração principal under Configuração avançada.
    4. Pressione a tecla Hosts sob o Monitoramento seção.
    5. Adicione a definição de host:

    chlimage_1-118

    Veja abaixo um exemplo de um arquivo de configuração de host, caso você esteja usando o Nagios Core:

    define host {
       address 192.168.0.5
       max_check_attempts 3
       check_period 24x7
       check-command check-host-alive
       contacts admin
       notification_interval 60
       notification_period 24x7
    }
    
  4. Instale o Nagios e o NRPE no servidor AEM.

  5. Instale o check_http_json em ambos os servidores.

  6. Defina um comando genérico de verificação JSON em ambos os servidores:

    define command{
    
        command_name    check_http_json-int
    
        command_line    /usr/lib/nagios/plugins/check_http_json --user "$ARG1$" --pass "$ARG2$" -u 'https://$HOSTNAME$:$ARG3$/$ARG4$' -e '$ARG5$' -w '$ARG6$' -c '$ARG7$'
    
    }
    
  7. Adicione um serviço para memória usada no servidor AEM:

    define service {
    
        use generic-service
    
        host_name my.remote.host
    
        service_description AEM Author Used Memory
    
        check_command  check_http_json-int!<cq-user>!<cq-password>!<cq-port>!system/sling/monitoring/mbeans/java/lang/Memory.infinity.json!{noname}.mbean:attributes.HeapMemoryUsage.mbean:attributes.used.mbean:value!<warn-threshold-in-bytes>!<critical-threshold-in-bytes>
    
        }
    
  8. Verifique o painel Nagios quanto ao serviço recém-criado:

    chlimage_1-119

Ferramentas de diagnóstico

O Painel de Operações também fornece acesso às Ferramentas de Diagnóstico, que podem ajudar a encontrar e solucionar problemas de causas raiz dos avisos provenientes do Painel de Verificação de Integridade, além de fornecer informações importantes de depuração para operadores do sistema.

Entre as suas características mais importantes estão:

  • Um analisador de mensagens de log
  • A capacidade de acessar despejos de heap e thread
  • Analisadores de desempenho de solicitações e consultas

Você pode acessar a tela Ferramentas de diagnóstico acessando Ferramentas - Operações - Diagnóstico na tela AEM Welcome . Você também pode acessar a tela acessando diretamente o seguinte URL: https://serveraddress:port/libs/granite/operations/content/diagnosis.html

chlimage_1-120

Mensagens de registro

Por padrão, a Interface do usuário das mensagens de log exibirá todas as mensagens de ERRO. Se desejar que mais mensagens de log sejam exibidas, será necessário configurar um agente de log com o nível de log apropriado.

As mensagens de log usam um appender no log de memória e, portanto, não estão relacionadas aos arquivos de log. Outra consequência é que alterar os níveis de log nessa interface não alterará as informações que são registradas nos arquivos de log tradicionais. Adicionar e remover loggers nesta interface do usuário afetará somente o logger da memória. Além disso, observe que a alteração das configurações do agente de log será refletida no futuro do agente de log da memória - as entradas que já estão registradas e não são mais relevantes não são excluídas, mas entradas semelhantes não serão registradas no futuro.

Você pode configurar o que é registrado fornecendo configurações de logger do botão de engrenagem superior esquerdo na interface do usuário. Lá, você pode adicionar, remover ou atualizar configurações do agente de log. Uma configuração de logger é composta por um nível de log (AVISO / INFORMAÇÕES / DEBUG) e um nome do filtro. O nome do filtro tem a função de filtrar a fonte das mensagens de log que são registradas. Como alternativa, se um agente de log deve capturar todas as mensagens de log do nível especificado, o nome do filtro deve ser "root". Definir o nível de um agente de log acionará a captura de todas as mensagens com um nível igual ou superior ao especificado.

Exemplos:

  • Se você planeja capturar todas as ERRO messages - nenhuma configuração é necessária. Todas as mensagens de ERRO são capturadas por padrão.

  • Se você planeja capturar todas as ERRO, AVISO e INFO messages - o nome do logger deve ser definido como: "root" e o nível do logger para: INFO.

  • Se você planeja capturar todas as mensagens provenientes de um determinado pacote (por exemplo, com.adobe.granite), o nome do logger deve ser definido como: "com.adobe.granite" e o nível do agente de log para: DEPURAR (isso capturará todas as ERRO, AVISO, INFO e DEPURAR mensagens), conforme mostrado na imagem abaixo.

chlimage_1-121

OBSERVAÇÃO

Não é possível definir um nome de agente de log para capturar apenas mensagens ERROR por meio de um filtro especificado. Por padrão, todas as mensagens de ERRO são capturadas.

OBSERVAÇÃO

A interface do usuário das mensagens de log não reflete o log de erros real. A menos que esteja configurando outros tipos de mensagens de log na interface do usuário, você verá apenas mensagens de ERRO. Para saber como exibir mensagens de log específicas, consulte as instruções acima.

OBSERVAÇÃO

As configurações na página de diagnóstico não influenciam o que está registrado nos arquivos de log e vice-versa. Portanto, embora o log de erros possa capturar mensagens INFO, talvez você não as veja na interface do usuário de mensagens de log. Além disso, por meio da interface do usuário, é possível capturar mensagens DEBUG de determinados pacotes sem afetar o log de erros. Para obter mais informações sobre como configurar os arquivos de log, consulte Registro.

OBSERVAÇÃO

Com AEM 6.4, as tarefas de manutenção são desconectadas da caixa em um formato mais avançado de informações no nível INFO. Isso permite uma melhor visibilidade do estado das tarefas de manutenção.

Caso esteja usando ferramentas de terceiros (como o Splunk) para monitorar e reagir à atividade de tarefa de manutenção, você pode usar as seguintes instruções de log:

Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>

Solicitar desempenho

A página Desempenho da solicitação permite a análise das solicitações de página mais lentas processadas. Somente solicitações de conteúdo serão registradas nesta página. Mais especificamente, as seguintes solicitações serão capturadas:

  1. Solicitações de acesso a recursos em /content
  2. Solicitações de acesso a recursos em /etc/design
  3. Pedidos com ".html" extensão

chlimage_1-122

A página é exibida:

  • A hora em que a solicitação foi feita
  • O URL e o método de solicitação
  • A duração em milissegundos

Por padrão, as 20 solicitações de página mais lentas são capturadas, mas o limite pode ser modificado no Configuration Manager.

Desempenho da consulta

A página Desempenho da Consulta permite a análise das consultas mais lentas realizadas pelo sistema. Essas informações são fornecidas pelo repositório em um Mbean JMX. Em Jackrabbit, a com.adobe.granite.QueryStat O JMX Mbean fornece essas informações, enquanto no repositório Oak, ele é oferecido por org.apache.jackrabbit.oak.QueryStats.

A página é exibida:

  • A hora em que o query foi feito
  • O idioma do query
  • O número de vezes que o query foi emitido
  • A instrução do query
  • A duração em milissegundos

chlimage_1-123

Explicar consulta

Para qualquer query, o Oak tenta descobrir a melhor maneira de executar com base nos índices do Oak definidos no repositório no oak:index nó . Dependendo da query, índices diferentes podem ser escolhidos pelo Oak. Entender como o Oak está executando um query é a primeira etapa para otimizar o query.

O Explain Query é uma ferramenta que explica como o Oak está executando um query. Ele pode ser acessado indo até Ferramentas - Operações - Diagnóstico na tela de boas-vindas AEM, em seguida, clicando em Desempenho da consulta e alternando para o Explicar Consulta guia .

Recursos

  • Suporta os idiomas de consulta Xpath, JCR-SQL e JCR-SQL2
  • Relata o tempo de execução real da consulta fornecida
  • Detecta consultas lentas e avisa sobre consultas que podem ser potencialmente lentas
  • Relata o índice Oak usado para executar a consulta
  • Exibe a explicação real do mecanismo Oak Query
  • Fornece uma lista click-to-load de consultas lentas e populares

Quando estiver na interface do usuário do Explain Query, tudo o que você precisa fazer para usá-la é inserir o query e pressionar o Explicar botão:

chlimage_1-124

A primeira entrada na seção Explicação da Consulta é a explicação real. A explicação mostrará o tipo de índice usado para executar a query.

A segunda entrada é o plano de execução.

Marcar o Incluir tempo de execução antes de executar o query, também mostrará a quantidade de tempo em que o query foi executado. O Incluir contagem de nós reportará a contagem de nós. Isso permite obter mais informações, que podem ser usadas para otimizar os índices para seu aplicativo ou implantação.

chlimage_1-125

O Gerenciador de Índice

A finalidade do Gerenciador de índice é facilitar o gerenciamento do índice, como manter índices ou visualizar seu status.

Ele pode ser acessado indo até Ferramentas - Operações - Diagnóstico ​ na tela de boas-vindas e clicando no botão Gerenciador de índice botão.

Ele também pode ser acessado diretamente neste URL: https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html

index_manager

A interface do usuário pode ser usada para filtrar índices na tabela, digitando os critérios de filtro na caixa de pesquisa no canto superior esquerdo da tela.

Baixar o ZIP de status

Isso acionará o download de um zip contendo informações úteis sobre o status e a configuração do sistema. O arquivo contém configurações de instância, uma lista de pacotes, OSGI, métricas e estatísticas de Sling e isso pode resultar em um arquivo grande. Você pode reduzir o impacto de arquivos de status grandes usando o ZIP de status de download janela. A janela pode ser acessada de:AEM > Ferramentas > Operações > Diagnóstico > Baixar ZIP de status.

Nessa janela, você pode selecionar o que exportar (arquivos de log e/ou despejos de thread) e o número de dias de logs incluídos no download em relação à data atual.

download_status_zip

Baixar o despejo de encadeamento

Isso acionará o download de um zip contendo informações sobre os threads presentes no sistema. Informações sobre cada thread são fornecidas, como seu status, o carregador de classe e o rastreamento de pilha.

Baixar o despejo da pilha

Você também pode baixar um instantâneo do heap para analisá-lo posteriormente. Observe que isso acionará o download de um arquivo grande, da ordem de centenas de megabytes.

Tarefas de manutenção automatizada

A página Tarefas de manutenção automatizada é um local onde você pode visualizar e rastrear tarefas de manutenção recomendadas programadas para execução periódica. As tarefas são integradas ao sistema de verificação de integridade. As tarefas também podem ser executadas manualmente na interface.

Para acessar a página Manutenção no Painel de Operações, você precisa acessar Ferramentas - Operações - Painel - Manutenção na tela AEM Welcome ou siga diretamente este link:

https://serveraddress:port/libs/granite/operations/content/maintenance.html

As seguintes tarefas estão disponíveis no Painel de Operações:

  1. O Revisão de limpeza tarefa, localizada na Janela de manutenção diária menu.
  2. O Limpeza de binários Lucene tarefa, localizada na Janela de manutenção diária menu.
  3. O Limpeza de fluxo de trabalho tarefa, localizada na Janela de manutenção semanal menu.
  4. O Coleta de lixo do armazenamento de dados tarefa, localizada na Janela de manutenção semanal menu.
  5. O Manutenção do log de auditoria tarefa, localizada na Janela de manutenção semanal menu.
  6. O Manutenção da limpeza de versão tarefa, localizada na Janela de manutenção semanal menu.

O tempo padrão para a janela de manutenção diária é de 2 a 5 horas. As tarefas configuradas para serem executadas na janela de manutenção semanal serão executadas entre 1 e 2 AM aos sábados.

Você também pode configurar os tempos pressionando o ícone de engrenagem em qualquer uma das duas placas de manutenção:

chlimage_1-126

OBSERVAÇÃO

Desde o AEM 6.1, as janelas de manutenção existentes também podem ser configuradas para serem executadas mensalmente.

Limpeza da revisão

Para obter mais informações sobre como executar a Revisão de limpeza, consulte este artigo dedicado.

Limpeza de binários do Lucene

Ao usar a tarefa Limpeza de binários do Lucene, é possível limpar binários do lucene e reduzir o requisito de tamanho do armazenamento de dados em execução. Isso ocorre porque o churn binário do lucene será reivindicado diariamente em vez da dependência anterior em um coleta de lixo do armazenamento de dados executar.

Embora a tarefa de manutenção tenha sido desenvolvida para reduzir o lixo de revisão relacionado ao Lucene, há ganhos gerais de eficiência ao executar a tarefa:

  • A execução semanal da tarefa de coleta de lixo do armazenamento de dados será concluída mais rapidamente
  • Também pode melhorar ligeiramente o desempenho geral do AEM

Você pode acessar a tarefa Limpeza de binários Lucene a partir de: AEM > Ferramentas > Operações > Manutenção > Janela de manutenção diária > Limpeza de binários do Lucene.

Coleta de lixo do armazenamento de dados

Para obter detalhes sobre a Coleta de lixo do Data Store, consulte o página de documentação.

Limpeza de fluxo de trabalho

Os fluxos de trabalho também podem ser removidos do Painel de manutenção. Para executar a tarefa Expurgação de Fluxo de Trabalho, é necessário:

  1. Clique no botão Janela de manutenção semanal página.
  2. Na página a seguir, clique no link Reproduzir no botão Limpeza de fluxo de trabalho cartão.
OBSERVAÇÃO

Para obter informações mais detalhadas sobre a Manutenção do Fluxo de Trabalho, consulte esta página.

Manutenção do log de auditoria

Para a Manutenção do Log de Auditoria, consulte o página de documentação separada.

Remoção da versão

Você pode agendar a tarefa de manutenção da limpeza de versão para excluir automaticamente as versões antigas. Como resultado, isso minimiza a necessidade de usar manualmente a variável Ferramentas de limpeza de versão. Você pode agendar e configurar a tarefa de limpeza de versão acessando Ferramentas > Operações > Manutenção > Janela de manutenção semanal e seguindo estas etapas:

  1. Clique no botão Adicionar botão.

  2. Choose Limpeza de versão no menu suspenso.

    version_purge_maintenanceask

  3. Para configurar a tarefa de limpeza de versão, clique no botão engrenagens no cartão de manutenção Version Purge recém-criado.

    version_purge_taskconfiguration

Com AEM 6.4, você pode interromper a tarefa de manutenção da limpeza de versão da seguinte maneira:

  • Automaticamente - Se a janela de manutenção agendada for fechada antes que a tarefa possa ser concluída, a tarefa será interrompida automaticamente. Ele será retomado quando a próxima janela de manutenção for aberta.
  • Manualmente - Para interromper manualmente a tarefa, no cartão de manutenção Expurgação de Versão, clique no botão Stop ícone . Na próxima execução, a tarefa será retomada com segurança.
OBSERVAÇÃO

Parar a tarefa de manutenção significa suspender sua execução sem perder o controle da tarefa já em andamento.

ATENÇÃO

Para otimizar o tamanho do repositório, você deve executar a tarefa de limpeza de versão com frequência. A tarefa deve ser agendada fora do horário comercial, quando houver uma quantidade limitada de tráfego.

Tarefas de manutenção personalizadas

As tarefas de manutenção personalizadas podem ser implementadas como serviços OSGi. Como a infraestrutura da tarefa de manutenção se baseia no manuseio de tarefas do Apache Sling, uma tarefa de manutenção deve implementar a interface java [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html). Além disso, deve declarar várias propriedades de registro de serviço a serem detectadas como uma tarefa de manutenção, conforme listado abaixo:

Nome da Propriedade do Serviço
Descrição Exemplo
Tipo
granite.maintenance.isStoppable Atributo booleano que define se a tarefa pode ser interrompida pelo usuário. Se uma tarefa declarar que é parável, ela deverá verificar, durante sua execução, se foi interrompida e agir de acordo. O padrão é false. verdadeiro Opcional
granite.maintenance.mandatory Atributo booleano que define se uma tarefa é obrigatória e deve ser executada periodicamente. Se uma tarefa for obrigatória, mas não estiver em nenhuma janela de programação ativa, uma Verificação de integridade relatará isso como um erro. O padrão é false. verdadeiro Opcional
granite.maintenance.name Um nome exclusivo para a tarefa - é usado para fazer referência à tarefa. Esse geralmente é um nome simples. MyMaintenanceTask Obrigatório
granite.maintenance.title Um título exibido para esta tarefa Minha Tarefa de Manutenção Especial Obrigatório
job.topics Este é um tópico exclusivo da tarefa de manutenção.
A manipulação do trabalho do Apache Sling iniciará um trabalho com exatamente este tópico para executar a tarefa de manutenção e, à medida que a tarefa for registrada para este tópico, ele será executado.
O tópico deve começar com com/adobe/granite/maintenance/job/
com/adobe/granite/maintenance/job/MyMaintenanceTask Obrigatório

Além das propriedades de serviço acima, a função process() do método JobConsumer A interface precisa ser implementada adicionando o código que deve ser executado para a tarefa de manutenção. O JobExecutionContext pode ser usado para gerar informações de status, verificar se o trabalho foi interrompido pelo usuário e criar um resultado (sucesso ou falha).

Para situações em que uma tarefa de manutenção não deve ser executada em todas as instalações (por exemplo, executar somente na instância de publicação), é possível fazer com que o serviço exija uma configuração para estar ativo, adicionando @Component(policy=ConfigurationPolicy.REQUIRE). Em seguida, você pode marcar a configuração de acordo como sendo o modo de execução dependente no repositório. Para obter mais informações, consulte Configuração do OSGi.

Veja abaixo um exemplo de uma tarefa de manutenção personalizada que exclui arquivos de um diretório temporário configurável que foi modificado nas últimas 24 horas:

src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java

/*

* #%L

* sample-maintenance-task

* %%

* Copyright (C) 2014 Adobe

* %%

* Licensed under the Apache License, Version 2.0 (the "License");

* you may not use this file except in compliance with the License.

* You may obtain a copy of the License at

*

* https://www.apache.org/licenses/LICENSE-2.0

*

* Unless required by applicable law or agreed to in writing, software

* distributed under the License is distributed on an "AS IS" BASIS,

* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

* See the License for the specific language governing permissions and

* limitations under the License.

* #L%

*/

package com.adobe.granite.samples.maintenance.impl;

import java.io.File;

import java.util.Calendar;

import java.util.Collection;

import java.util.Map;

import org.apache.commons.io.FileUtils;

import org.apache.commons.io.filefilter.IOFileFilter;

import org.apache.commons.io.filefilter.TrueFileFilter;

import org.apache.felix.scr.annotations.Activate;

import org.apache.felix.scr.annotations.Component;

import org.apache.felix.scr.annotations.Properties;

import org.apache.felix.scr.annotations.Property;

import org.apache.felix.scr.annotations.Service;

import org.apache.sling.commons.osgi.PropertiesUtil;

import org.apache.sling.event.jobs.Job;

import org.apache.sling.event.jobs.consumer.JobConsumer;

import org.apache.sling.event.jobs.consumer.JobExecutionContext;

import org.apache.sling.event.jobs.consumer.JobExecutionResult;

import org.apache.sling.event.jobs.consumer.JobExecutor;

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

import com.adobe.granite.maintenance.MaintenanceConstants;

@Component(metatype = true,

label = "Delete Temp Files Maintenance Task",

description = "Maintatence Task which deletes files from a configurable temporary directory which have been modified in the last 24 hours.")

@Service

@Properties({

@Property(name = MaintenanceConstants.PROPERTY_TASK_NAME, value = "DeleteTempFilesTask", propertyPrivate = true),

@Property(name = MaintenanceConstants.PROPERTY_TASK_TITLE, value = "Delete Temp Files", propertyPrivate = true),

@Property(name = JobConsumer.PROPERTY_TOPICS, value = MaintenanceConstants.TASK_TOPIC_PREFIX

+ "DeleteTempFilesTask", propertyPrivate = true) })

public class DeleteTempFilesTask implements JobExecutor {

private static final Logger log = LoggerFactory.getLogger(DeleteTempFilesTask.class);

@Property(label = "Temporary Directory", description="Temporary Directory. Defaults to the java.io.tmpdir system property.")

private static final String PROP_TEMP_DIR = "temp.dir";

private File tempDir;

@Activate

private void activate(Map<string, object=""> properties) {

this.tempDir = new File(PropertiesUtil.toString(properties.get(PROP_TEMP_DIR),

System.getProperty("java.io.tmpdir")));

}

@Override

public JobExecutionResult process(Job job, JobExecutionContext context) {

log.info("Deleting old temp files from {}.", tempDir.getAbsolutePath());

Collection<file> files = FileUtils.listFiles(tempDir, new LastModifiedBeforeYesterdayFilter(),

TrueFileFilter.INSTANCE);

int counter = 0;

for (File file : files) {

log.debug("Deleting file {}.", file.getAbsolutePath());

counter++;

file.delete();

// TODO - capture the output of delete() and do something useful with it

}

return context.result().message(String.format("Deleted %s files.", counter)).succeeded();

}

/**

* IOFileFilter which filters out files which have been modified in the last 24 hours.

*

*/

private static class LastModifiedBeforeYesterdayFilter implements IOFileFilter {

private final long minTime;

private LastModifiedBeforeYesterdayFilter() {

Calendar cal = Calendar.getInstance();

cal.add(Calendar.DATE, -1);

this.minTime = cal.getTimeInMillis();

}

@Override

public boolean accept(File dir, String name) {

// this method is never actually called.

return false;

}

@Override

public boolean accept(File file) {

return file.lastModified() <= this.minTime;

}

}

}

<file></string,>

experiencemanager-java-maintenance-ask-sample- src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java

Após a implantação do serviço, ele é exposto à interface do usuário do Painel de Operações. Você pode adicioná-lo a uma das programações de manutenção disponíveis:

chlimage_1-127

Isso adicionará um recurso correspondente em /apps/granite/operations/config/maintenance/schedule/taskname. Se a tarefa for dependente do modo de execução, a propriedade granite.operations.conditions.runmode precisará ser definida nesse nó com os valores dos runmodes que precisam estar ativos para esta tarefa de manutenção.

Visão geral do sistema

O Painel Visão geral do sistema exibe uma visão geral de alto nível da configuração, hardware e integridade da instância do AEM. Isso significa que o status de integridade do sistema é transparente e todas as informações são agregadas em um único painel.

OBSERVAÇÃO

Você também pode assistir a este vídeo para obter uma introdução ao Painel de visão geral do sistema.

Como acessar

Para acessar o Painel Visão geral do sistema, navegue até Ferramentas > Operações > Visão geral do sistema.

system_overview_dashboard

Explicação do painel Visão geral do sistema

A tabela abaixo descreve todas as informações exibidas no Painel de visão geral do sistema. Lembre-se de que quando não houver informações relevantes para mostrar (por exemplo, o backup não está em andamento, não há verificações de integridade críticas) a respectiva seção exibirá a mensagem "Nenhuma entrada".

Também é possível baixar uma JSON arquivo que resume as informações do painel clicando no Baixar no canto superior direito do painel. JSON endpoint é /libs/granite/operations/content/systemoverview/export.json e pode ser usado em um curl script para monitoramento externo.

Seção Quais informações são exibidas Quando é crítico Links para
Verificações de integridade
  • uma lista de verificações que estão em estado Crítico
  • uma lista de verificações que estão no status Warn
Indicado visualmente:
  • uma marca vermelha para verificações Críticas
  • uma tag laranja para as verificações de Aviso
  • Página Relatórios de integridade
Tarefas de manutenção
  • uma lista de tarefas que falharam
  • uma lista de tarefas que estão em execução no momento
  • uma lista de tarefas que tiveram êxito na última execução
  • uma lista de tarefas que nunca foram executadas
  • uma lista de tarefas que não estão agendadas

Indicado visualmente:

  • uma tag vermelha para tarefas com falha
  • uma tag laranja para executar tarefas (pois elas podem afetar o desempenho)
  • tags cinza para todos os outros status
  • Página Tarefas de manutenção
Sistema
  • sistema operacional e versão do sistema operacional (por exemplo, Mac OS X)
  • média de carga do sistema, conforme recuperado de OperatingSystemMXBeable
  • espaço em disco (na partição onde o diretório inicial está localizado)
  • heap máximo, como retornado por MemoryMXBean
N/A N/D
Instância
  • a versão AEM
  • lista de modos de execução
  • a data em que a instância foi iniciada
N/D N/D
Repositório
  • a versão Oak
  • tipo de armazenamento de nó (Segment Tar ou Document)
    • se o tipo for documento, o tipo de armazenamento de documento será exibido (RDB ou Mongo)
  • se houver um armazenamento de dados personalizado:
    • para um Armazenamento de dados de arquivo, o caminho é exibido
    • para um armazenamento de dados S3, o nome do bucket S3 é exibido
    • para um armazenamento de dados S3 compartilhado, o nome do bucket S3 é exibido
    • para um Data Store do Azure, o contêiner é exibido
  • se não houver um armazenamento de dados externo personalizado, uma mensagem indicando esse fato será exibida
N/D N/D
Agentes de distribuição
  • uma lista de agentes com filas bloqueadas
  • uma lista de agentes mal configurados ("Erro de configuração")
  • uma lista de agentes com processamento de fila pausado
  • uma lista de agentes ociosos
  • uma lista de agentes em execução (que estão processando entradas no momento)

Indicado visualmente:

  • uma tag vermelha para agentes bloqueados ou erros de configuração
  • uma tag laranja para agentes pausados
  • uma tag cinza para agentes pausados, ociosos ou em execução
Página Distribuição
Agentes de replicação
  • uma lista de agentes com filas bloqueadas
  • uma lista de agentes ociosos
  • uma lista de agentes em execução (que estão processando entradas no momento)

Indicado visualmente:

  • uma marca vermelha para agentes bloqueados
  • uma tag cinza para agentes pausados
Página Replicação
Fluxos de trabalhos
  • Trabalhos do fluxo de trabalho:
    • número de tarefas de fluxo de trabalho com falha (se houver)
    • número de trabalhos de fluxo de trabalho cancelados (se houver)
  • Contagens de workflow - número de workflows em um determinado status (se houver):
    • em execução
    • Falha
    • suspenso
    • abortado

Para cada um dos status apresentados acima, é realizada uma query com um limite de 400 milissegundos. Em 400 milissegundos, o número de entradas obtidas até esse ponto é exibido.

Não interpretado:

  • o usuário deve investigar quando há workflows e trabalhos em status inesperados.
Página Falhas do fluxo de trabalho
Trabalhos Sling

Contagens de tarefas Sling - número de tarefas em um determinado status (se houver):

  • Falha
  • em fila
  • cancelado
  • ativo

Não interpretado:

  • o usuário deve investigar quando houver trabalhos em status inesperado ou com contagens altas.
N/D
Contagens estimadas de nós

Número estimado de:

  • páginas
  • ativos
  • tags
  • autorizáveis
  • número total de nós

O número total de nós é obtido a partir do nodeCounterMBean, enquanto o resto das estatísticas são obtidas a partir de IndexInfoService.

N/D N/D
Backup Exibe "Backup online em andamento", se for o caso. N/D N/D
Indexação

Exibições:

  • "Indexação em andamento"
  • "Consulta em andamento"

Se um encadeamento de indexação ou consulta estiver presente no despejo de encadeamento.

N/D N/D

Nesta página