O Painel Operations 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 da AEM e permite configurar e executar automação de manutenção autônoma para reduzir significativamente as operações do projeto e os casos de suporte. O Painel Operações pode ser estendido com verificações de integridade personalizadas e tarefas de manutenção. Além disso, os dados do Operations Painel podem ser acessados a partir de ferramentas de monitoramento externas via JMX.
O Painel de Operações:
Ele pode ser acessado indo para Ferramentas - Operações na tela de boas-vindas AEM.
Para poder acessar o Painel 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 direitos de usuário, grupo e acesso.
O sistema de Relatório de Integridade fornece informações sobre a integridade de uma instância 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 usuário de toque. Ele oferta as medições e o limite de certos contadores configuráveis e, em alguns casos, oferta informações sobre como resolver o problema.
Ele tem vários recursos, descritos abaixo.
Os Relatórios de integridade são um sistema de cartões que indica integridade boa ou ruim em relação a uma área específica do produto. Esses cartões são visualizações das Sling Health Checks, que agregação dados do JMX e de outras fontes e expõe as informações processadas novamente como MBeans. Esses MBeans também podem ser inspecionados no console da Web JMX, sob o domínio org.apache.sling.saudcheck.
A interface de Relatórios de Integridade pode ser acessada por meio do menu 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
O sistema de cartões expõe três estados possíveis: OK, AVISO e CRÍTICO. Os estados resultam de regras e limites, que podem ser configurados passando o mouse sobre o cartão e, em seguida, clicando no ícone de engrenagem na barra de ação:
Existem dois tipos de controlos sanitários no AEM 6:
Uma Verificação de integridade individual é uma verificação de integridade única que corresponde a um cartão de status. As Verificações de integridade individuais podem ser configuradas com regras ou limites e podem fornecer uma ou mais dicas e links para resolver problemas de integridade identificados. Vejamos a verificação "Erros de registro" como um exemplo: se houver entradas ERROR nos registros 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 "Mensagem de registro" na seção Ferramentas de diagnóstico, que permitirá que você analise esses erros com mais detalhes e reconfigure os registradores.
Um Composite Health Check é uma verificação que agregação informações de várias verificações individuais.
As verificações de integridade composta são configuradas com o auxílio de tags de filtro. Essencialmente, 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 agregação tiverem status OK também.
No Painel Operações, você pode visualizar o resultado de verificações de integridade individuais e compostas.
A criação de uma verificação de integridade individual envolve duas etapas: implementar uma Verificação de integridade Sling e adicionar uma entrada para a Verificação de integridade nos nós de configuração do Painel.
Para criar uma Verificação de integridade Sling, é necessário criar um componente OSGI que implemente a interface Sling HealthCheck. Você adicionará esse componente dentro de um pacote. As propriedades do componente identificarão completamente 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 do Sling Health Check para obter mais informações.
Exemplo de um componente Sling Health Check, 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
}
}
A propriedade MBEAN_NAME
define o nome da mbean que será gerada para essa verificação de integridade.
Depois de criar uma Verificação de integridade, é necessário criar um novo nó de configuração para torná-lo acessível na interface do Painel Operações. Para esta etapa, é necessário saber o nome do JMX Mbean da verificação de integridade (a propriedade MBEAN_NAME
). Para criar uma configuração para a Verificação de integridade, abra o CRXDE e adicione um novo nó (do tipo nt:unstructed) no seguinte caminho: /apps/settings/granite/operations/hc
As seguintes propriedades devem ser definidas no novo nó:
Nome: sling:resourceType
String
granite/operations/components/mbean
Nome: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
O caminho do recurso acima é criado da seguinte forma: se o nome do bean da sua Verificação de integridade for "test", adicione "test" 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
Verifique se o caminho /apps/settings/granite/operations/hc
tem as seguintes propriedades definidas como true:
sling:configCollectionInherit
sling:configPropertyInherit
Isso instruirá o gerenciador de configuração a unir as novas configurações às existentes de /libs
.
A função de uma verificação de integridade composta é agregação de várias verificações de integridade individuais que compartilham um conjunto de recursos comuns. Por exemplo, o Security Composite Health Check 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 Operações, é necessário adicionar um novo nó de configuração, da mesma forma que fizemos para uma verificação simples.
Vá para o Web Configuration Manager no Console OSGI. Você pode fazer isso acessando https://serveraddress:port/system/console/configMgr
Procure a entrada chamada Apache Sling Composite Health Check. Depois de encontrá-lo, observe que existem duas configurações disponíveis: um para as verificações do sistema e outro para as verificações de segurança.
Crie uma nova configuração pressionando o botão "+" no lado direito da configuração. Uma nova janela será exibida, como mostrado abaixo:
Crie uma configuração e salve-a. Uma Mbean será criada com a nova configuração.
A finalidade de cada propriedade de configuração é a seguinte:
hc.tags
).Um novo JMX Mbean é criado para cada nova configuração da Verificação de integridade composta do Apache Sling.**
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 Operations. O procedimento para o efeito é o mesmo que para os controlos sanitários individuais: um nó do tipo nt:unstruct precisa ser criado em /apps/settings/granite/operations/hc
. A propriedade resource do nó será definida pelo valor de hc.medium.name na configuração OSGI.
Se, por exemplo, você tiver criado uma configuração e definir o valor hc.mbean.name como diskusage, os nós de configuração terão a seguinte aparência:
Nome: Composite Health Check
nt:unstructured
Com as seguintes propriedades:
Nome: sling:resourceType
String
granite/operations/components/mbean
Nome: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
Se você criar verificações de integridade individuais que pertencem logicamente a uma verificação composta que já está presente no Painel por padrão, elas serão automaticamente capturadas e agrupadas sob a respectiva verificação composta. Por isso, 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 a tag "security" e ela estiver instalada, ela aparecerá automaticamente sob a verificação composta de Verificações de segurança no Painel Operações.
Nome da verificação completa | Descrição |
Desempenho da consulta | Essa verificação de integridade foi simplificada no AEM 6.4 e agora verifica o MBean O MBean para esta verificação de integridade é org.apache.sling.saudcheck:name=queriesStatus,type=HealthCheck. |
Comprimento da fila de observação | A Duração da Fila de Observação repete todos os Ouvintes de Evento e Observadores de Plano de Fundo, compara seus
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.saudcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck. |
Limites de cruzamento da consulta | Os limites de travessia do query verificam
O Mbean para esta verificação de integridade é org.apache.sling.saudcheck:name=queryTraversalLimitsBundle,type=HealthCheck. |
Relógios sincronizados | Essa verificação é relevante apenas para clusters de nó de documento. Ele retorna o seguinte status:
O Mbean para esta verificação de integridade é org.apache.sling.saudcheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck. |
Índices assíncronos | A verificação Índices Assíncronos:
Os limites de status Crítico e Avisar são configuráveis. O Mbean para esta verificação de integridade é org.apache.sling.saudcheck:name=asyncIndexHealthCheck,type=HealthCheck. Observação: Esta verificação de integridade está disponível com o AEM 6.4 e tem suporte para AEM 6.3.0.1. |
Índices Lucene grandes | Essa verificação usa os dados expostos pelo MBean
Os limites são configuráveis e o MBean para a verificação de integridade é org.apache.sling.saudcheck:name=largeIndexHealthCheck,type=HealthCheck. Observação: Esta verificação está disponível com o AEM 6.4 e tem suporte para AEM 6.3.2.0. |
Manutenção do sistema | A Manutenção do sistema é uma verificação composta que retorna o OK se todas as tarefas de manutenção estiverem em execução como configurado. Lembre-se de que:
O MBean para esta verificação de integridade é org.apache.sling.saudcheck:name=systemcheck,type=HealthCheck. |
Fila de replicação | Esta 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 repetiu a replicação. Se o agente tentar novamente a replicação mais do que o valor do parâmetro O MBean para esta verificação de integridade é org.apache.sling.saudcheck:name=ReplicationQueue,type=HealthCheck. |
Tarefas de arremesso |
O Sling Jobs verifica o número de jobs na fila no JobManager, o compara ao
maxNumQueueJobs limite e:
Somente o número máximo de parâmetros 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.saudcheck:name=slingJobs,type=HealthCheck. |
Desempenho da solicitação | Esta verificação analisa a métrica
O MBean para esta verificação de integridade é org.apache.sling.saudcheck:name=RequestsStatus,type=HealthCheck. |
Erros de log | Essa verificação retornará o status Avisar se houver erros no log. O MBean para esta verificação de integridade é org.apache.sling.saudcheck:name=logErrorHealthCheck,type=HealthCheck. |
Espaço em disco | A verificação de Espaço em Disco verifica o MBean
Ambos os limites são configuráveis. A verificação só funciona em instâncias com um Repositório de segmentos. O MBean para esta verificação de integridade é org.apache.sling.saudcheck: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.saudcheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheck. |
Verificações de segurança | A verificação de segurança é um composto que agregação os resultados de várias verificações relacionadas à segurança. Essas verificações de integridade individuais tratam de preocupações diferentes da lista de verificação de segurança disponível na 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.saudcheck:name=securityCheckits,type=HealthCheck |
Grupos ativos | Os Pacotes Ativos verificam o estado de todos os pacotes e:
O parâmetro ignorar lista é configurável. O MBean para esta verificação de integridade é org.apache.sling.saudcheck:name=inativeBundles,type=HealthCheck. |
Verificação de Cache de Código | Esta é uma verificação de integridade que verifica várias condições JVM que podem disparar um erro CodeCache presente no Java 7:
O limite O MBean para esta verificação de integridade é org.apache.sling.saudcheck:name=codeCacheHealthCheck,type=HealthCheck. |
Recurso Buscar erros de caminho | Verifica se há recursos no caminho
O MBean para esta verificação de integridade é org.apache.sling.saudcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck. |
O Painel de verificação de integridade pode se integrar ao Nagios por meio do Granite JMX Mbeans. O exemplo a seguir ilustra como adicionar uma verificação que mostre a memória usada no servidor que está executando o AEM.
Configure e instale Nagios no servidor de monitoramento.
Em seguida, instale o executor de plug-in remoto Nagios (NRPE).
Para obter mais informações sobre como instalar Nagios e NRPE em seu sistema, consulte a Documentação do Nagios.
Adicione uma definição de host para o servidor AEM. Isso pode ser feito por meio da interface da Web Nagios XI, usando o Configuration Manager:
Abaixo está um exemplo de um arquivo de configuração de host, no caso de você estar 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
}
Instale Nagios e NRPE no servidor AEM.
Instale o plug-in check_http_json em ambos os servidores.
Defina um comando de verificação JSON genérico 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$'
}
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>
}
Verifique seu painel Nagios para obter o serviço recém-criado:
O Painel Operation também fornece acesso às Ferramentas de diagnóstico que podem ajudar a encontrar e solucionar problemas das causas raiz dos avisos provenientes do Painel Health Check, além de fornecer informações importantes de depuração para os operadores do sistema.
Entre as suas características mais importantes estão:
Você pode acessar a tela Ferramentas de diagnóstico indo para Ferramentas - Operações - Diagnóstico na tela de boas-vindas do AEM. Você também pode acessar a tela acessando diretamente o seguinte URL: https://serveraddress:port/libs/granite/operations/content/diagnosis.html
Por padrão, as mensagens de log da Interface do usuário exibirão todas as mensagens de ERRO. Se desejar que mais mensagens de log sejam exibidas, é necessário configurar um agente de log com o nível de log apropriado.
As mensagens de registro usam um anexo de registro de memória e, portanto, não estão relacionadas aos arquivos de registro. Outra consequência é que alterar os níveis de log nesta interface não alterará as informações que são registradas nos arquivos de log tradicionais. A adição e remoção de registradores nesta interface afetará apenas o registrador de 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 de memória - as entradas que já estão registradas e não são mais relevantes não serã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 de agente de log. Uma configuração de agente de log é composta por um log level (WARN / INFO / DEBUG) e um nome do filtro. O nome do filtro tem a função de filtrar a origem das mensagens de registro que são registradas. Como alternativa, se um agente de log deve capturar todas as mensagens de log para o 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 mensagens ERROR - nenhuma configuração é necessária. Todas as mensagens de ERRO são capturadas por padrão.
Se você planeja capturar todas as mensagens ERROR, WARN e INFO - o nome do agente de log deve ser definido como: "root" e o nível do agente de log para: INFO.
Se você planeja capturar todas as mensagens provenientes de um determinado pacote (por exemplo, com.adobe.granite) - o nome do agente de log deve ser definido como: "com.adobe.granite" e o nível do agente de log para: DEBUG (isso capturará todas as mensagens ERROR, WARN, INFO e DEBUG), conforme mostrado na imagem abaixo.
Não é possível definir um nome de agente de log para capturar somente mensagens ERROR por meio de um filtro especificado. Por padrão, todas as mensagens de ERRO são capturadas.
A interface do usuário das mensagens de log não reflete o log de erros real. A menos que você 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 registro específicas, consulte as instruções acima.
As configurações na página de diagnóstico não influenciam o que está registrado nos arquivos de log e vice-versa. Assim, embora o registro de erros possa capturar mensagens INFO, talvez você não as veja na interface do usuário das mensagens de registro. Além disso, por meio da interface é 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 registro, consulte Registro.
Com o AEM 6.4, as tarefas de manutenção são desconectadas da caixa em um formato mais rico em 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 Splunk) para monitorar e reagir à atividade da tarefa de manutenção, você pode usar as seguintes declarações de log:
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
A página Desempenho da solicitação permite a análise das solicitações de página mais lentas processadas. Somente as solicitações de conteúdo serão registradas nesta página. Mais especificamente, as seguintes solicitações serão capturadas:
/content
/etc/design
".html"
A página exibe:
Por padrão, as 20 solicitações de página mais lentas são capturadas, mas o limite pode ser modificado no Configuration Manager.
A página Desempenho do Query permite a análise dos query mais lentos executados pelo sistema. Essas informações são fornecidas pelo repositório em um JMX Mbean. Em Jackrabbit, o com.adobe.granite.QueryStat
JMX Mbean fornece essas informações, enquanto no repositório Oak, ele é oferecido por org.apache.jackrabbit.oak.QueryStats.
A página exibe:
Para qualquer query, Oak tenta descobrir a melhor maneira de executar com base nos índices Oak definidos no repositório no nó oak:index. Dependendo do query, diferentes índices podem ser escolhidos por Oak. Entender como o Oak está executando um query é o primeiro passo para otimizar o query.
O Query Explique é uma ferramenta que explica como o Oak está executando um query. Ele pode ser acessado indo até Ferramentas - Operações - Diagnóstico da tela de boas-vindas AEM, clicando em Desempenho do Query e alternando para a guia Explorar Query.
Recursos
Depois que você estiver na interface do usuário do Query Explique, tudo o que precisa fazer para usá-la é digitar o query e pressionar o botão Explicar:
A primeira entrada na seção Explicação do Query é a explicação concreta. A explicação mostrará o tipo de índice usado para executar o query.
A segunda entrada é o plano de execução.
Clicar na caixa Incluir tempo de execução antes de executar o query também mostrará a quantidade de tempo em que o query foi executado, permitindo mais informações que podem ser usadas para otimizar os índices do aplicativo ou da implantação.
A finalidade do Gerenciador de índice é facilitar o gerenciamento de índice, como manter índices, ou exibir 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.
Ele também pode ser acessado diretamente neste URL: https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
A interface do usuário pode ser usada para filtrar índices na tabela digitando os critérios do filtro na caixa de pesquisa no canto superior esquerdo da tela.
Isso acionará o download de um zip que contém 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 Sling, o que pode resultar em um arquivo grande. Você pode reduzir o impacto de arquivos de status grandes usando a janela Baixar ZIP de status. 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.
Isso acionará o download de um zip que contém informações sobre os encadeamentos presentes no sistema. Informações sobre cada thread são fornecidas, como seu status, o carregador de classe e o rastreamento de 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.
A página Tarefas de manutenção automatizada é um local onde você pode visualização 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 a partir da interface.
Para chegar à página Manutenção no Painel Operações, você precisa ir para Ferramentas - Operações - Painel - Manutenção na tela de Boas-vindas AEM ou seguir diretamente este link:
https://serveraddress:port/libs/granite/operations/content/maintenance.html
As seguintes tarefas estão disponíveis no Painel Operações:
O tempo padrão para a janela de manutenção diária é de 2 a 5 da manhã. As tarefas configuradas para execução na janela de manutenção semanal serão executadas entre 1 e 2 AM aos sábados.
Você também pode configurar os horários pressionando o ícone de engrenagem em qualquer uma das duas placas de manutenção:
Desde AEM 6.1, as janelas de manutenção existentes também podem ser configuradas para serem executadas mensalmente.
Para obter mais informações sobre como executar a limpeza de revisão, consulte este artigo dedicado.
Ao usar a tarefa de Limpeza de binários Lucene, você pode expurgar binários lucene e reduzir o requisito de tamanho do armazenamento de dados em execução. Isso ocorre porque a grade binária do lucene será recuperada diariamente em vez da dependência anterior em uma coleta de lixo do armazenamento de dados executada com êxito.
Embora a tarefa de manutenção tenha sido desenvolvida para reduzir o lixo de revisão relacionado a Lucene, há ganhos gerais de eficiência ao executar a tarefa:
Você pode acessar a tarefa de Limpeza de binários de Lucene a partir de: AEM > Ferramentas > Operações > Manutenção > Janela de manutenção diária > Limpeza de binários Lucene.
Para obter detalhes sobre a coleta de lixo do Data Store, consulte a página de documentação dedicada a1/>.
Workflows também podem ser removidos do Painel Maintenance. Para executar a tarefa de Expurgação do Fluxo de Trabalho, é necessário:
Para obter informações mais detalhadas sobre a Manutenção do Fluxo de Trabalho, consulte esta página.
Para a Manutenção do Log de Auditoria, consulte a página de documentação separada.
Você pode agendar a tarefa de manutenção Expurgação da versão para excluir versões antigas automaticamente. Como resultado, isso minimiza a necessidade de usar manualmente as ferramentas de Expurgação da Versão. Você pode agendar e configurar a tarefa de Expurgação da Versão acessando Ferramentas > Operações > Manutenção > Janela de manutenção semanal e seguindo estas etapas:
Clique no botão Adicionar.
Escolha Expurgação da versão no menu suspenso.
Para configurar a tarefa de Expurgação da Versão, clique no ícone engrenagens no cartão de manutenção de Expurgação da Versão recém-criado.
Com o AEM 6.4, você pode parar a tarefa de manutenção da Expurgação da Versão da seguinte maneira:
Parar a tarefa de manutenção significa suspender sua execução sem perder o controle da tarefa já em andamento.
Para otimizar o tamanho do repositório, execute a tarefa de expurgação da 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 podem ser implementadas como serviços OSGi. Como a infraestrutura da tarefa de manutenção se baseia no gerenciamento 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 tarefa de manutenção, conforme listado abaixo:
Nome da propriedade do serviço |
Descrição | Exemplo |
Tipo |
granite.maintenance.isStoppable | Atributo booliano que define se a tarefa pode ser interrompida pelo usuário. Se uma tarefa declarar que é parada, deverá verificar, durante a sua execução, se foi parada e, em seguida, agir em conformidade. O padrão é false. | verdadeiro | Opcional |
granite.maintenance.mandatory | Atributo booliano 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 reportará 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. Este é 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. O manuseio de tarefas do Apache Sling irá start um trabalho com exatamente este tópico para executar a tarefa de manutenção e, conforme a tarefa é registrada para este tópico, ele será executado. O tópico deve ser start com/ adobe/granite/manutenção/job/ |
com/adobe/granite/manutenção/job/MyMaintenanceTask | Obrigatório |
Além das propriedades de serviço acima, o método process()
da interface JobConsumer
precisa ser implementado adicionando o código que deve ser executado para a tarefa de manutenção. O JobExecutionContext
fornecido pode ser usado para gerar informações de status, verificar se o trabalho foi interrompido pelo usuário e criar um resultado (bem-sucedido ou com falha).
Para situações em que uma tarefa de manutenção não deve ser executada em todas as instalações (por exemplo, executada apenas na instância de publicação), você pode fazer com que o serviço exija uma configuração para ficar ativo adicionando @Component(policy=ConfigurationPolicy.REQUIRE)
. 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.
Abaixo está 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
|
experience-emanager-java-manuetask-sample - src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
Depois que o serviço é implantado, 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:
Isso adicionará um recurso correspondente em /apps/granite/operations/config/manutenção/schedule
/taskname
. Se a tarefa for dependente do modo de execução, a propriedade granite.operations.as.runmode precisa ser definida nesse nó com os valores dos modos de execução que precisam estar ativos para essa tarefa de manutenção.
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 AEM. Isso significa que o status de integridade do sistema é transparente e todas as informações são agregadas em um único painel.
Você também pode assistir a este vídeo para obter uma introdução ao Painel Visão geral do sistema.
Para acessar o Painel Visão geral do sistema, navegue até Ferramentas > Operações > Visão geral do sistema.
A tabela abaixo descreve todas as informações exibidas no Painel 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".
Você também pode baixar um arquivo JSON
resumindo as informações do painel clicando no botão Download no canto superior direito do painel. O endpoint JSON
é /libs/granite/operations/content/systemoverview/export.json
e pode ser usado em um script curl
para monitoramento externo.
Seção | Que informações são exibidas | Quando é crítico | Links para |
Verificações de integridade |
|
Indicado visualmente:
|
|
Tarefas de manutenção |
|
Indicado visualmente:
|
|
Sistema |
|
N/A | N/A |
Instância |
|
N/A | N/A |
Repositório |
|
N/A | N/A |
Agentes de distribuição |
|
Indicado visualmente:
|
Página de distribuição |
Agentes de replicação |
|
Indicado visualmente:
|
Página Replicação |
Fluxos de trabalhos |
Para cada um dos status apresentados acima, um query é executado, com um limite de 400 milissegundos. Em 400 milissegundos, o número de entradas obtidas até esse ponto é exibido. |
Não interpretado:
|
Página Falhas de Fluxo de Trabalho |
Tarefas de arremesso | Contagem de trabalhos de sling - número de trabalhos em um determinado status (se houver):
|
Não interpretado:
|
N/A |
Contagens estimadas de nós | Número estimado de:
O número total de nós é obtido a partir de nodeCounterMBean, enquanto o restante das estatísticas é obtido a partir de IndexInfoService. |
N/A | N/A |
Backup | Exibe "Backup on-line em andamento", se esse for o caso. | N/A | N/A |
Indexação | Exibições:
Se uma indexação ou thread de query estiver presente no despejo de thread. |
N/A | N/A |