Il pannello operativo dell’AEM 6 aiuta gli operatori di sistema a monitorare immediatamente lo stato del sistema dell’AEM. Fornisce inoltre informazioni di diagnosi generate automaticamente su aspetti rilevanti dell’AEM e consente di configurare ed eseguire automazione della manutenzione autonoma per ridurre in modo significativo le operazioni del progetto e i casi di supporto. Il dashboard operazioni può essere esteso con controlli di integrità personalizzati e attività di manutenzione. Inoltre, i dati della dashboard operazioni sono accessibili da strumenti di monitoraggio esterni tramite JMX.
Dashboard operazioni:
È accessibile da Strumenti - Operazioni dalla schermata iniziale dell’AEM.
Per poter accedere al dashboard operazioni, l’utente connesso deve far parte del gruppo di utenti "Operatori". Per ulteriori informazioni, consulta la documentazione su Amministrazione di utenti, gruppi e diritti di accesso.
Il sistema di rapporti sullo stato fornisce informazioni sullo stato di un’istanza AEM tramite Sling Health Checks. Puoi eseguire questa operazione tramite OSGI, JMX, richieste HTTP (tramite JSON) o tramite l’interfaccia utente touch. Offre misurazioni e soglie di alcuni contatori configurabili e, a volte, offre informazioni su come risolvere il problema.
Dispone di diverse funzioni, descritte di seguito.
Il Rapporti stato sono un sistema di schede che indicano una buona o cattiva salute in una specifica area di prodotto. Queste schede sono visualizzazioni dei controlli di integrità Sling, che aggregano i dati da JMX e altre origini ed espongono nuovamente le informazioni elaborate come MBean. Questi MBean possono essere esaminati anche nel Console web JMX, sotto il org.apache.sling.healthcheck dominio.
È possibile accedere all'interfaccia dei rapporti di stato tramite Strumenti - Operazioni - Rapporti stato nella schermata iniziale dell’AEM o direttamente tramite il seguente URL:
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
Il sistema di carte di pagamento espone tre possibili stati: OK, AVVERTI e CRITICO. Gli stati sono il risultato di regole e soglie, che possono essere configurate passando il mouse sulla scheda e facendo clic sull'icona a forma di ingranaggio nella barra delle azioni:
Esistono due tipi di controlli sanitari nell'AEM 6:
Un Verifica stato individuale è un singolo controllo di integrità che corrisponde a una scheda di stato. I singoli controlli di integrità possono essere configurati con regole o soglie e possono fornire uno o più suggerimenti e collegamenti per risolvere i problemi di integrità identificati. Prendiamo il controllo "Errori di registro" come esempio: se ci sono voci ERROR nei registri delle istanze, trovale nella pagina dei dettagli del controllo di integrità. Nella parte superiore della pagina, è possibile visualizzare un collegamento all'analizzatore "Log Message" (Messaggi di registro) nella sezione Strumenti di diagnostica, che consente di analizzare questi errori più dettagliatamente e riconfigurare i logger.
A Verifica stato composito è un controllo che aggrega le informazioni provenienti da diversi singoli controlli.
I controlli di integrità compositi sono configurati con l’aiuto di filtrare i tag. In sostanza, tutti i singoli controlli che hanno lo stesso tag filtro sono raggruppati come un controllo di integrità composito. Un controllo di integrità composito ha lo stato OK solo se anche tutti i singoli controlli che aggrega hanno lo stato OK.
Nel dashboard operazioni puoi visualizzare il risultato dei controlli di integrità sia singoli che compositi.
La creazione di un singolo controllo di integrità prevede due passaggi: l’implementazione di un controllo di integrità Sling e l’aggiunta di una voce per il controllo di integrità nei nodi di configurazione del dashboard.
Per creare una verifica stato Sling, crea un componente OSGI che implementa l’interfaccia Sling HealthCheck. Aggiungi questo componente all’interno di un bundle. Le proprietà del componente identificano completamente il controllo di integrità. Una volta installato il componente, viene automaticamente creato un MBean JMX per il controllo dello stato. Consulta la Documentazione di Sling Health Check per ulteriori informazioni.
Esempio di componente Sling Health Check, scritto con annotazioni del componente del servizio 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
}
}
Il MBEAN_NAME
definisce il nome del mbean generato per questa verifica stato.
Dopo aver creato una verifica stato, è necessario creare un nuovo nodo di configurazione per renderlo accessibile nell’interfaccia del dashboard operazioni. Per questo passaggio, è necessario conoscere il nome Mbean JMX del controllo di integrità (il MBEAN_NAME
proprietà ). Per creare una configurazione per il controllo dello stato, apri CRXDE e aggiungi un nodo (di tipo nt:unstructured) nel seguente percorso: /apps/settings/granite/operations/hc
Le seguenti proprietà devono essere impostate sul nuovo nodo:
Nome: sling:resourceType
String
granite/operations/components/mbean
Nome: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/exampleHealthCheck
Il percorso della risorsa precedente viene creato come segue: se il nome mbean di Verifica stato è "test", aggiungi "test" alla fine del percorso /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
Quindi il percorso finale è il seguente:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
Assicurati che il /apps/settings/granite/operations/hc
il percorso ha le seguenti proprietà impostate su true:
sling:configCollectionInherit
sling:configPropertyInherit
Questo processo comunica al gestore della configurazione di unire le nuove configurazioni con quelle esistenti da /libs
.
Il ruolo di una Verifica stato composita è quello di aggregare più verifiche di integrità individuali condividendo una serie di caratteristiche comuni. Ad esempio, il controllo di integrità del composto di sicurezza raggruppa tutti i singoli controlli di integrità che eseguono le verifiche relative alla sicurezza. Il primo passaggio per creare un controllo composito consiste nell’aggiungere una configurazione OSGI. Per visualizzarlo nel dashboard operazioni, è necessario aggiungere un nuovo nodo di configurazione nello stesso modo di un semplice controllo.
Passa a Gestione configurazione Web nella console OSGI. Accesso https://serveraddress:port/system/console/configMgr
Cerca la voce denominata Verifica stato composito Apache Sling. Dopo averlo trovato, noterai che sono già disponibili due configurazioni: una per i controlli di sistema e un’altra per i controlli di sicurezza.
Per creare una configurazione, premi il pulsante "+" a destra. Viene visualizzata una nuova finestra, come illustrato di seguito:
Crea una configurazione e salvala. Viene creato un Mbean con la nuova configurazione.
Lo scopo di ciascuna proprietà di configurazione è il seguente:
hc.tags
).Per ogni nuova configurazione di Apache Sling Composite Health Check viene creato un nuovo JMX Mbean.**
Infine, la voce del controllo di integrità composito creato deve essere aggiunta nei nodi di configurazione del dashboard operazioni. La procedura è la stessa dei singoli controlli di integrità: un nodo di tipo nt:unstructured deve essere creato in /apps/settings/granite/operations/hc
. La proprietà di risorsa del nodo è definita dal valore di hc.media.name nella configurazione OSGI.
Ad esempio, se hai creato una configurazione e hai impostato hc.mbean.name valore per diskusage, i nodi di configurazione si presentano come segue:
Nome: Composite Health Check
nt:unstructured
Con le seguenti proprietà:
Nome: sling:resourceType
String
granite/operations/components/mbean
Nome: resource
String
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/diskusage
Se si creano singoli controlli di integrità che appartengono logicamente a un controllo composito già presente nel dashboard per impostazione predefinita, questi vengono acquisiti e raggruppati automaticamente nel rispettivo controllo composito. Di conseguenza, non è necessario creare un nodo di configurazione per questi controlli.
Ad esempio, se crei un singolo controllo di integrità della sicurezza, assegnalo al "protezione" ed è installato. Viene visualizzato automaticamente sotto il controllo composito dei controlli di sicurezza nel dashboard operazioni.
Nome controllo di integrità | Descrizione |
Prestazioni delle query | Questo controllo di integrità è stato semplificato AEM 6.4, e ora controlla il refactoring di recente MBean per questa verifica stato è org.apache.sling.healthCheck:name=queriesStatus,type=HealthCheck. |
Lunghezza coda di osservazione | La lunghezza della coda di osservazione viene iterata su tutti i listener di eventi e gli osservatori in background e ne confronta le
La lunghezza massima di ciascuna coda proviene da configurazioni separate (Oak e AEM) e non è configurabile da questa verifica di integrità. MBean per questa verifica stato è org.apache.sling.healthCheck:name=OsservazioneCodaLunghezzaVerificaStato,type=VerificaStato. |
Limiti di attraversamento per query | Query Traversal Limits controlla i
Il Mbean per questo controllo stato è org.apache.sling.healthCheck:name=queryTraversalLimitsBundle,type=HealthCheck. |
Orologi sincronizzati | Questo controllo è pertinente solo per cluster di tipo nodo documento. Restituisce il seguente stato:
Il Mbean per questo controllo stato è org.apache.sling.healthcheck:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck. |
Indici asincroni | La verifica degli indici asincroni:
È possibile configurare sia le soglie di stato Critico che quelle di Avviso. Il Mbean per questo controllo stato è org.apache.sling.healthCheck:name=asyncIndexHealthCheck,type=HealthCheck. Nota: Questa valutazione dello stato di salute è disponibile con AEM 6.4 ed è stata supportata come AEM 6.3.0.1. |
Indici Lucene di grandi dimensioni | Questo controllo utilizza i dati esposti da
Le soglie sono configurabili e la voce MBean per il controllo dello stato è org.apache.sling.healthCheck:name=largeIndexHealthCheck,type=HealthCheck. Nota: Questo controllo è disponibile con AEM 6.4 ed è stato eseguito il backport a AEM 6.3.2.0. |
Manutenzione sistema | Manutenzione sistema è un controllo composito che restituisce l'OK se tutte le attività di manutenzione sono in esecuzione come configurato. Tieni presente che:
MBean per questa verifica stato è org.apache.sling.healthCheck:name=systemchecs,type=HealthCheck. |
Coda di replica | Questo controllo scorre gli agenti di replica e ne esamina le code. Per l'elemento nella parte superiore della coda, il controllo verifica il numero di tentativi di replica eseguiti dall'agente. Se l'agente ha ritentato la replica di un valore superiore a quello del MBean per questa verifica stato è org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck. |
Processi Sling |
Sling Jobs controlla il numero di job in coda in JobManager, confrontandolo con
maxNumQueueJobs soglia e:
È possibile configurare solo il parametro relativo al numero massimo di processi in coda e il valore predefinito è 1000. MBean per questa verifica stato è org.apache.sling.healthCheck:name=slingJobs,type=HealthCheck. |
Prestazioni delle richieste | Questo controllo esamina
MBean per questa verifica stato è org.apache.sling.healthCheck:name=requestsStatus,type=HealthCheck. |
Errori registro | Questo controllo restituisce lo stato Warn in caso di errori nel registro. MBean per questa verifica stato è org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck. |
Spazio su disco | Il controllo dello spazio su disco esamina
Entrambe le soglie sono configurabili. Il controllo funziona solo sulle istanze con un archivio segmenti. MBean per questa verifica stato è org.apache.sling.healthCheck:name=DiskSpaceHealthCheck,type=HealthCheck. |
Verifica stato modulo di pianificazione | Questo controllo restituisce un avviso se l’istanza ha processi Quartz in esecuzione per più di 60 secondi. È possibile configurare la soglia di durata accettabile. MBean per questa verifica stato è org.apache.sling.healthCheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheck. |
Verifiche di sicurezza | Il controllo di sicurezza è un elemento composito che aggrega i risultati di più controlli relativi alla sicurezza. Questi singoli controlli di integrità rispondono a diversi problemi segnalati nell'elenco di controllo della sicurezza disponibile all'indirizzo Pagina della documentazione dell’elenco di controllo della sicurezza. Il controllo è utile come test del fumo di sicurezza all'avvio dell'istanza. MBean per questa verifica stato è org.apache.sling.healthCheck:name=controlli di sicurezza,type=HealthCheck |
Bundle attivi | Bundle attivi controlla lo stato di tutti i bundle e:
Il parametro dell’elenco da ignorare è configurabile. MBean per questa verifica stato è org.apache.sling.healthCheck:name=inactiveBundles,type=HealthCheck. |
Controllo cache codice | Verifica stato che verifichi diverse condizioni JVM che possono attivare un bug CodeCache presente in Java™ 7:
Il MBean per questa verifica stato è org.apache.sling.healthCheck:name=codeCacheHealthCheck,type=HealthCheck. |
Errori nel percorso di ricerca delle risorse | Controlla se nel percorso sono presenti risorse
MBean per questa verifica stato è org.apache.sling.healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck. |
Per impostazione predefinita, per un’istanza AEM preconfigurata, i controlli di integrità vengono eseguiti ogni 60 secondi.
È possibile configurare Periodo con Configurazione OSGi Configurazione verifica stato query (com.adobe.granite.queries.impl.hc.QueryHealthCheckMetrics).
La dashboard di controllo dello stato può integrarsi con Nagios tramite Granite JMX Mbeans. L'esempio seguente illustra come aggiungere un controllo che mostra la memoria utilizzata sul server che esegue AEM.
Configurare e installare Nagios sul server di monitoraggio.
Quindi, installare Nagios Remote Plugin Executor (NRPE).
Per ulteriori informazioni su come installare Nagios e NRPE sul sistema, consultare Documentazione di Nagios.
Aggiungere una definizione host per il server AEM. È possibile eseguire questa operazione tramite l'interfaccia Web Nagios XI, utilizzando Configuration Manager:
Di seguito è riportato un esempio di file di configurazione host, nel caso in cui si utilizzi 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
}
Installare Nagios e NRPE sul server AEM.
Installare check_http_json plug-in su entrambi i server.
Definisci un comando di controllo JSON generico su entrambi i server:
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$'
}
Aggiungi un servizio per la memoria utilizzata sul server 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>
}
Controlla la dashboard di Nagios per verificare se il servizio è stato appena creato:
Il dashboard delle operazioni consente inoltre di accedere agli strumenti di diagnostica che consentono di individuare e risolvere le cause principali degli avvisi provenienti dal dashboard di verifica stato e di fornire importanti informazioni di debug per gli operatori di sistema.
Tra le sue caratteristiche più importanti vi sono:
Per accedere alla schermata Strumenti di diagnostica, vai a Strumenti - Operazioni - Diagnosi dalla schermata iniziale dell’AEM. Puoi anche accedere alla schermata accedendo direttamente al seguente URL: https://serveraddress:port/libs/granite/operations/content/diagnosis.html
Per impostazione predefinita, nell'interfaccia utente dei messaggi di registro vengono visualizzati tutti i messaggi di ERRORE. Per visualizzare più messaggi di registro, configura un logger con il livello di registro appropriato.
I messaggi di log utilizzano un appender di log in memoria e pertanto non sono correlati ai file di log. Un’altra conseguenza è che la modifica dei livelli di registro in questa interfaccia utente non modifica le informazioni che vengono registrate nei file di registro tradizionali. L’aggiunta e la rimozione dei logger in questa interfaccia utente influisce solo sul logger di memoria. Inoltre, la modifica delle configurazioni del logger si riflette nel futuro del logger in memoria. Le voci già registrate e non più rilevanti non vengono eliminate, ma voci simili non verranno registrate in futuro.
Puoi configurare gli elementi registrati fornendo le configurazioni del logger dal pulsante in alto a sinistra nell’interfaccia utente. È possibile aggiungere, rimuovere o aggiornare le configurazioni del logger. Una configurazione logger è composta da un livello di registro (WARN / INFO / DEBUG) e un nome filtro. Il nome filtro ha il ruolo di filtrare l’origine dei messaggi di registro che vengono registrati. In alternativa, se un logger deve acquisire tutti i messaggi di registro per il livello specificato, il nome del filtro deve essere "radice". L’impostazione del livello di un logger attiva l’acquisizione di tutti i messaggi con un livello uguale o superiore a quello specificato.
Esempi:
Se prevedi di acquisire tutti i ERRORE messaggi: non è richiesta alcuna configurazione. Tutti i messaggi ERROR vengono acquisiti per impostazione predefinita.
Se prevedi di acquisire tutti i ERRORE, AVVERTI e INFO messages - il nome del logger deve essere impostato su: "radice", e il livello logger per: INFO.
Se prevedi di acquisire tutti i messaggi provenienti da un determinato pacchetto (ad esempio com.adobe.granite), il nome del logger deve essere impostato su: "com.adobe.granite". E, il livello logger è impostato su: DEBUG (in questo modo acquisisce tutte le ERRORE, AVVERTI, INFO, e DEBUG ), come illustrato nell'immagine seguente.
Non è possibile impostare un nome di logger per acquisire solo i messaggi di ERRORE tramite un filtro specificato. Per impostazione predefinita, vengono acquisiti tutti i messaggi ERROR.
L’interfaccia utente dei messaggi di registro non riflette il registro degli errori effettivo. A meno che non si configurino altri tipi di messaggi di registro nell'interfaccia utente, vengono visualizzati solo i messaggi di ERRORE. Per informazioni su come visualizzare messaggi di registro specifici, consulta le istruzioni precedenti.
Le impostazioni nella pagina di diagnostica non influenzano ciò che viene registrato nei file di registro e viceversa. Pertanto, anche se il registro degli errori può rilevare i messaggi INFO, è possibile che tali messaggi non vengano visualizzati nell’interfaccia utente dei messaggi di registro. Inoltre, tramite l’interfaccia utente di è possibile rilevare i messaggi DEBUG da alcuni pacchetti senza che questo influisca sul registro degli errori. Per ulteriori informazioni su come configurare i file di registro, vedere Registrazione.
Con AEM 6.4, le attività di manutenzione vengono disconnesse in un formato più ricco di informazioni a livello INFO. Questo flusso di lavoro offre una migliore visibilità dello stato delle attività di manutenzione.
Se si utilizzano strumenti di terze parti, ad esempio Splunk, per monitorare e reagire all'attività di manutenzione, è possibile utilizzare le istruzioni di registro seguenti:
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
La pagina Prestazioni delle richieste consente di analizzare le richieste di pagina più lente elaborate. In questa pagina vengono registrate solo le richieste di contenuto. In particolare, vengono acquisite le seguenti richieste:
/content
/etc/design
".html"
estensioneLa pagina mostra:
Per impostazione predefinita, vengono acquisite le 20 richieste più lente, ma il limite può essere modificato in Configuration Manager.
La pagina Prestazioni query consente di analizzare le query più lente eseguite dal sistema. Queste informazioni vengono fornite dall’archivio in un JMX Mbean. In Jackrabbit, il com.adobe.granite.QueryStat
JMX Mbean fornisce queste informazioni, mentre nell’archivio Oak queste sono offerte da org.apache.jackrabbit.oak.QueryStats.
La pagina mostra:
Per una determinata query, Oak tenta di capire il modo migliore per eseguire in base agli indici Oak definiti nell’archivio in oak:index nodo. A seconda della query, Oak può scegliere indici diversi. Il primo passaggio per ottimizzare la query consiste nel comprendere in che modo Oak esegue una query.
Explain Query è uno strumento che spiega come Oak sta eseguendo una query. È accessibile da Strumenti - Operazioni - Diagnosi dalla schermata di benvenuto dell’AEM. Quindi, fai clic su Prestazioni query e passa al Spiega query scheda.
Funzioni
Nell’interfaccia utente Spiega query, inserisci la query e premi Spiega pulsante:
La prima voce nella sezione Spiegazione query è la spiegazione effettiva. La spiegazione mostra il tipo di indice utilizzato per eseguire la query.
La seconda voce è il piano di esecuzione.
Come selezionare Includi tempo di esecuzione prima di eseguire la query mostra anche la quantità di tempo di esecuzione della query. Il Includi conteggio nodi riporta il conteggio dei nodi. Il rapporto consente di ottenere ulteriori informazioni che possono essere utilizzate per ottimizzare gli indici per l’applicazione o la distribuzione.
Lo scopo di Gestione indici è quello di facilitare la gestione degli indici, ad esempio la manutenzione degli indici o la visualizzazione del loro stato.
Per accedervi, vai a Strumenti - Operazioni - Diagnosi dalla schermata di benvenuto, quindi fai clic su Gestore indice pulsante.
È inoltre possibile accedervi direttamente da questo URL: https://serveraddress:port/libs/granite/operations/content/diagnosistools/indexManager.html
L’interfaccia utente può essere utilizzata per filtrare gli indici nella tabella digitando i criteri di filtro nella casella di ricerca nell’angolo in alto a sinistra dello schermo.
Questa azione attiva il download di un file ZIP contenente informazioni utili sullo stato e sulla configurazione del sistema. L’archivio contiene configurazioni di istanze, un elenco di bundle, OSGI, metriche e statistiche Sling, che possono causare un file di grandi dimensioni. È possibile ridurre l’impatto dei file di stato di grandi dimensioni utilizzando Scarica ZIP stato finestra. La finestra è accessibile da:AEM > Strumenti > Operazioni > Diagnosi > Scarica ZIP stato.
Da questa finestra puoi selezionare gli elementi da esportare (file di registro e/o immagini thread) e il numero di giorni di registri inclusi nel download rispetto alla data corrente.
Questa azione attiva il download di un file ZIP contenente informazioni sui thread presenti nel sistema. Vengono fornite informazioni su ciascun thread, ad esempio il relativo stato, il caricatore di classi e la traccia dello stack.
Puoi scaricare un’istantanea dell’heap per analizzarla in un secondo momento. Questa azione attiva il download di un file di grandi dimensioni (centinaia di MB).
La pagina Attività di manutenzione automatizzata è un'area in cui è possibile visualizzare e tenere traccia delle attività di manutenzione consigliate pianificate per l'esecuzione periodica. Le attività sono integrate con il sistema di Verifica stato. Le attività possono anche essere eseguite manualmente dall’interfaccia.
Per accedere alla pagina Manutenzione nel dashboard operazioni, dalla schermata di benvenuto AEM, vai a Strumenti - Operazioni - Dashboard - Manutenzione, oppure segui direttamente questo collegamento:
https://serveraddress:port/libs/granite/operations/content/maintenance.html
Nel dashboard operazioni sono disponibili le seguenti attività:
L'orario predefinito per la finestra di manutenzione giornaliera è dalle 2.00 alle 5.00. Le attività configurate per l’esecuzione nella finestra di manutenzione settimanale vengono eseguite tra le ore 1:00 e le ore 2:00 del sabato.
Puoi anche configurare gli intervalli premendo l’icona ingranaggio su una qualsiasi delle due schede di manutenzione:
A partire da AEM 6.1, è possibile configurare le finestre di manutenzione esistenti in modo che vengano eseguite mensilmente.
Per ulteriori informazioni sull'esecuzione di Pulizia revisioni, consulta questo articolo dedicato.
Utilizzando l'attività Pulizia dati binari di Lucene, è possibile eliminare i dati binari di Lucene e ridurre i requisiti relativi alle dimensioni dell'archivio dati in esecuzione. L'abbandono binario di Lucene viene recuperato quotidianamente invece della precedente dipendenza da un raccolta di oggetti inattivi dell’archivio dati esegui.
Anche se l’attività di manutenzione è stata sviluppata per ridurre i rifiuti di revisione correlati a Lucene, vi sono miglioramenti generali di efficienza durante l’esecuzione dell’attività:
Puoi accedere all’attività Pulizia binary di Lucene da: AEM > Strumenti > Operazioni > Manutenzione > Finestra Manutenzione giornaliera > Pulizia dati binari Lucene.
Per informazioni dettagliate sulla raccolta di oggetti inattivi dell’archivio dati, consulta la sezione dedicata pagina della documentazione.
I flussi di lavoro possono essere eliminati anche dal dashboard di manutenzione. Per eseguire l'attività Rimozione flusso di lavoro, eseguire le operazioni seguenti:
Per informazioni più dettagliate sulla manutenzione dei flussi di lavoro, consulta questa pagina.
Per la manutenzione del registro di controllo, vedere pagina separata della documentazione.
È possibile pianificare l'attività di manutenzione Pulizia delle versioni per eliminare automaticamente le versioni precedenti. Questa azione riduce al minimo la necessità di utilizzare manualmente Strumenti di Pulizia delle versioni. È possibile pianificare e configurare l'attività Pulizia delle versioni accedendo a Strumenti > Operazioni > Manutenzione > Finestra Manutenzione settimanale e seguendo questi passaggi:
Clic Aggiungi.
Scegli Pulizia versione dal menu a discesa.
Per configurare l'attività Pulizia delle versioni, fare clic sul pulsante ingranaggi sulla scheda di manutenzione Pulizia delle versioni appena creata.
Con AEM 6.4, è possibile interrompere l'attività di manutenzione Pulizia delle versioni come indicato di seguito:
Interrompere l'attività di manutenzione significa sospenderne l'esecuzione senza perdere la traccia del processo già in corso.
Per ottimizzare le dimensioni dell'archivio, è consigliabile eseguire frequentemente l'operazione di rimozione della versione. L’attività deve essere pianificata al di fuori dell’orario di lavoro in presenza di una quantità limitata di traffico.
Le attività di manutenzione personalizzate possono essere implementate come servizi OSGi. Poiché l’infrastruttura delle attività di manutenzione si basa sulla gestione dei processi di Apache Sling, un’attività di manutenzione deve implementare l’interfaccia Java™ [org.apache.sling.event.jobs.consumer.JobExecutor](https://sling.apache.org/apidocs/sling7/org/apache/sling/event/jobs/consumer/JobExecutor.html)
. Inoltre, deve dichiarare diverse proprietà di registrazione del servizio da rilevare come attività di manutenzione, come indicato di seguito:
Nome proprietà servizio |
Descrizione | Esempio |
Tipo |
granite.maintenance.isStoppable | Attributo booleano che definisce se l’attività può essere interrotta dall’utente. Se un'attività dichiara di essere arrestabile, durante l'esecuzione deve verificare se è stata arrestata e quindi agire di conseguenza. Il valore predefinito è false. | vero | Facoltativo |
granite.maintenance.mandatory | Attributo booleano che definisce se un’attività è obbligatoria e deve essere eseguita periodicamente. Se un'attività è obbligatoria ma al momento non è presente in alcuna finestra di programmazione attiva, un controllo di integrità segnala questo errore. Il valore predefinito è false. | vero | Facoltativo |
granite.maintenance.name | Nome univoco per l'attività: il nome viene utilizzato per fare riferimento all'attività ed è solo un nome semplice. | MyMaintenanceTask | Obbligatorio |
granite.maintenance.title | Titolo visualizzato per l'attività | La mia attività di manutenzione speciale | Obbligatorio |
job.topics | Argomento univoco dell’attività di manutenzione. La gestione del processo Apache Sling avvia un processo esattamente con questo argomento per eseguire l’attività di manutenzione e quando l’attività viene registrata per questo argomento viene eseguita. L’argomento deve iniziare con com/adobe/granite/maintenance/job/ |
com/adobe/granite/maintenance/job/MyMaintenanceTask | Obbligatorio |
Oltre alle proprietà del servizio di cui sopra, il process()
metodo del JobConsumer
L’interfaccia deve essere implementata aggiungendo il codice da eseguire per l’attività di manutenzione. Il fornito JobExecutionContext
può essere utilizzato per generare informazioni sullo stato, verificare se il processo viene interrotto dall’utente e creare un risultato (positivo o negativo).
Per le situazioni in cui un'attività di manutenzione non deve essere eseguita su tutte le installazioni (ad esempio, eseguire solo sull'istanza Publish), è possibile rendere il servizio necessario per attivare una configurazione aggiungendo @Component(policy=ConfigurationPolicy.REQUIRE)
. Puoi quindi contrassegnare la configurazione corrispondente come dipendente dalla modalità di esecuzione nell’archivio. Per ulteriori informazioni, consulta Configurazione di OSGi.
Di seguito è riportato un esempio di attività di manutenzione personalizzata che elimina i file da una directory temporanea configurabile che sono stati modificati nelle ultime 24 ore:
src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
|
experiencemanager-java-maintenancetask-sample- src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
Dopo che il servizio è stato distribuito, viene esposto all’interfaccia utente del dashboard operazioni. Puoi aggiungerlo a una delle pianificazioni di manutenzione disponibili:
Questa azione aggiunge una risorsa corrispondente in /apps/granite/operations/config/maintenance/schedule
/taskname
. Se l'attività dipende dalla modalità di esecuzione, la proprietà granite.operations.conditions.runmode deve essere impostata su tale nodo con i valori delle modalità di esecuzione che devono essere attive per l'attività di manutenzione.
Il Dashboard panoramica sistema visualizza una panoramica di alto livello della configurazione, dell’hardware e dello stato dell’istanza AEM. Lo stato di integrità del sistema è trasparente e tutte le informazioni sono aggregate in un unico dashboard.
È inoltre possibile guarda questo video per un'introduzione al dashboard Panoramica sistema.
Per accedere al dashboard Panoramica sistema, passare a Strumenti > Operazioni > Panoramica sistema.
La tabella seguente descrive tutte le informazioni visualizzate nel dashboard Panoramica sistema. Se non sono presenti informazioni rilevanti da mostrare (ad esempio, se il backup non è in corso o non sono presenti controlli di integrità critici), nella rispettiva sezione viene visualizzato il messaggio "Nessuna voce".
È inoltre possibile scaricare un JSON
file che riepiloga le informazioni del dashboard facendo clic sul pulsante Scarica nell'angolo superiore destro del dashboard. Il JSON
l'endpoint è /libs/granite/operations/content/systemoverview/export.json
e può essere utilizzato in un curl
script per il monitoraggio esterno.
Sezione | Informazioni visualizzate | Quando è fondamentale | Collegamenti a |
Verifiche stato |
|
A vista:
|
|
Attività di manutenzione |
|
A vista:
|
|
Sistema |
|
N/D | N/D |
Istanza |
|
N/D | N/D |
Archivio |
|
N/D | N/D |
Agenti di distribuzione |
|
A vista:
|
Pagina Distribuzione |
Agenti di replica |
|
A vista:
|
Pagina di replica |
Flussi di lavoro |
Per ciascuno degli stati presentati sopra viene eseguita una query, con un limite di 400 millisecondi. A 400 millisecondi, viene visualizzato il numero di voci ottenute fino a quel punto. |
Non interpretato:
|
Pagina Errori di flusso di lavoro |
Processi Sling | Conteggi processi Sling - numero di processi in un determinato stato (se presenti):
|
Non interpretato:
|
N/D |
Conteggi nodi stimati | Numero stimato di:
Il numero totale di nodi viene ottenuto da nodeCounterMBean, mentre le altre statistiche vengono ottenute da IndexInfoService. |
N/D | N/D |
Backup | In tal caso, viene visualizzato "Backup online in corso". | N/D | N/D |
Indicizzazione | Display:
Se nel dump del thread è presente un thread di indicizzazione o di query. |
N/D | N/D |