Il Pannello operazioni nel AEM 6 aiuta gli operatori di sistema a monitorare AEM stato del sistema. Fornisce inoltre informazioni diagnostiche generate automaticamente su aspetti rilevanti della AEM e consente di configurare ed eseguire l'automazione di manutenzione indipendente per ridurre notevolmente le operazioni di progetto e i casi di supporto. Il Pannello operazioni può essere esteso con controlli dello stato e attività di manutenzione personalizzati. Inoltre, è possibile accedere ai dati del dashboard operativo da strumenti di monitoraggio esterni tramite JMX.
Pannello delle operazioni:
È possibile accedervi scegliendo Strumenti - Operazioni dalla schermata di benvenuto AEM.
Per poter accedere al Pannello operazioni, l'utente connesso deve far parte del gruppo di utenti "Operatori". Per ulteriori informazioni, consulta la documentazione su Amministrazione utente, gruppo e diritti di accesso.
Il sistema Health Report fornisce informazioni sullo stato di un'istanza AEM tramite Sling Health Checks. Questa operazione può essere eseguita tramite OSGI, JMX, richieste HTTP (tramite JSON) o tramite l'interfaccia utente touch. Offre misurazioni e soglie di alcuni contatori configurabili e, in alcuni casi, fornirà informazioni su come risolvere il problema.
Presenta diverse funzioni, descritte di seguito.
Le Health Reports sono un sistema di schede che indicano una buona o cattiva salute per una specifica area di prodotto. Queste schede sono visualizzazioni dei Sling Health Checks, che aggregano i dati da JMX e da altre fonti ed espongono di nuovo le informazioni elaborate come MBeans. Questi MBeans possono essere ispezionati anche nella console Web JMX, nel dominio org.apache.sling.santhcheck.
È possibile accedere all'interfaccia Rapporti integrità tramite il menu Strumenti - Operazioni - Rapporto stato nella schermata di benvenuto AEM oppure direttamente tramite il seguente URL:
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
Il sistema di schede espone tre possibili stati: OK, WARN e CRITICAL. Gli stati sono il risultato di regole e soglie, che possono essere configurate posizionando il mouse sulla scheda e facendo clic sull'icona a forma di ingranaggio nella barra delle azioni:
Esistono due tipi di controlli sanitari nella AEM 6:
Un controllo integrità individuale è un controllo dello stato singolo che corrisponde a una scheda di stato. I controlli di integrità individuali possono essere configurati con regole o soglie e possono fornire uno o più suggerimenti e collegamenti per risolvere problemi di salute identificati. Prendiamo ad esempio il controllo "Log Errors": se nei registri delle istanze sono presenti voci di ERRORE, queste verranno trovate nella pagina dei dettagli della verifica dello stato. Nella parte superiore della pagina viene visualizzato un collegamento all’analizzatore "Messaggio registro" nella sezione Strumenti di diagnostica, che consente di analizzare questi errori in modo più dettagliato e riconfigurare i logger.
Un controllo dello stato composito è un controllo che raccoglie informazioni da diversi controlli individuali.
I controlli dello stato composito sono configurati con l'ausilio di tag filtro. In sostanza, tutti i controlli singoli con lo stesso tag del filtro verranno raggruppati come un controllo dello stato composito. Un controllo dello stato composito avrà uno stato OK solo se tutti i controlli singoli che aggrega hanno anche stati OK.
Nel Pannello operazioni è possibile visualizzare il risultato dei controlli di integrità individuali e compositi.
La creazione di un singolo controllo dello stato comporta due passaggi: implementazione di un Sling Health Check e aggiunta di una voce per il controllo dello stato nei nodi di configurazione del dashboard.
Per creare un Sling Health Check, è necessario creare un componente OSGI che implementa l’interfaccia Sling HealthCheck. Questo componente verrà aggiunto all’interno di un bundle. Le proprietà del componente identificheranno completamente il controllo dello stato. Una volta installato il componente, viene automaticamente creato un MBean JMX per il controllo dello stato. Per ulteriori informazioni, vedere la Documentazione Sling Health Check.
Esempio di un componente Sling Health Check, scritto con le annotazioni dei componenti 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
}
}
La proprietà MBEAN_NAME
definisce il nome del fagiolo che verrà generato per il controllo dello stato.
Dopo aver creato un controllo dello stato, è necessario creare un nuovo nodo di configurazione, per renderlo accessibile nell'interfaccia del dashboard delle operazioni. Per questo passaggio, è necessario conoscere il nome del file MFave JMX del controllo dello stato (la proprietà MBEAN_NAME
). Per creare una configurazione per il controllo dello stato, aprite CRXDE e aggiungete un nuovo nodo (di tipo nt:unstructure) nel percorso seguente: /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 del fagiolo del controllo dello stato è "test", aggiungere "test" alla fine del percorso /system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck
Quindi il percorso finale sarà:
/system/sling/monitoring/mbeans/org/apache/sling/healthcheck/HealthCheck/test
Verificate che il percorso /apps/settings/granite/operations/hc
abbia le seguenti proprietà impostate su true:
sling:configCollectionInherit
sling:configPropertyInherit
Questo indicherà al gestore di configurazione di unire le nuove configurazioni con quelle esistenti da /libs
.
Il ruolo di Composite Health Check consiste nell'aggregare una serie di controlli di integrità individuali che condividono una serie di funzioni comuni. Ad esempio, il Security Composite Health Check raggruppa tutti i singoli controlli dello stato di salute che eseguono verifiche relative alla sicurezza. Il primo passo per creare un controllo composito è aggiungere una nuova configurazione OSGI. Affinché possa essere visualizzato nel dashboard delle operazioni, è necessario aggiungere un nuovo nodo di configurazione, come abbiamo fatto per un semplice controllo.
Andate a Web Configuration Manager nella console OSGI. A tal fine, è possibile accedere a https://serveraddress:port/system/console/configMgr
Cercare la voce denominata Apache Sling Composite Health Check. Dopo averlo trovato, potete notare che sono già disponibili due configurazioni: uno per i controlli di sistema e uno per i controlli di sicurezza.
Per creare una nuova configurazione, premere il pulsante "+" a destra della configurazione. Verrà visualizzata una nuova finestra, come illustrato di seguito:
Create una configurazione e salvatela. Con la nuova configurazione verrà creato un file Mava.
Lo scopo di ciascuna proprietà di configurazione è il seguente:
hc.tags
).Per ogni nuova configurazione del controllo dello stato composito Apache Sling viene creata una nuova Mava JMX.**
Infine, la voce del controllo dello stato composito appena creato deve essere aggiunta nei nodi di configurazione del dashboard operativo. La procedura è la stessa dei singoli controlli sanitari: è necessario creare un nodo di tipo nt:unstructure in /apps/settings/granite/operations/hc
. La proprietà resource del nodo sarà definita dal valore di hc.medium.name nella configurazione OSGI.
Se, ad esempio, avete creato una configurazione e impostato il valore hc.mava.name su diskusage, i nodi di configurazione saranno simili a quelli seguenti:
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 create dei singoli controlli di integrità che logicamente appartengono a un controllo composito già presente nel dashboard per impostazione predefinita, questi verranno catturati automaticamente e raggruppati sotto il rispettivo controllo composito. Di conseguenza, non è necessario creare un nuovo nodo di configurazione per questi controlli.
Ad esempio, se create un singolo controllo dello stato di sicurezza, tutto ciò che dovete fare è assegnargli il tag "security", e viene installato, verrà visualizzato automaticamente sotto il controllo composito Controlli di sicurezza nel Pannello operazioni.
zHealthcheck Name | Descrizione |
Prestazioni delle query | Questo controllo dello stato è stato semplificato in AEM 6.4 e ora controlla l'attributo L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=queryStatus,type=HealthCheck. |
Lunghezza coda di osservazione | La lunghezza della coda di osservazione viene ripetuta su tutti i listener di eventi e gli osservatori in background, confronta i relativi
La lunghezza massima di ogni coda proviene da configurazioni separate (Oak e AEM) e non è configurabile da questo controllo di stato. L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=ObservationQueueLengthHealthCheck,type=HealthCheck. |
Limiti di attraversamento per query | Limiti di attraversamento query controlla gli attributi
Il campo di notifica per questo controllo dello stato è org.apache.sling.Healthcheck:name=queryTraversalLimitsBundle,type=HealthCheck. |
Orologi sincronizzati | Questo controllo è pertinente solo per i cluster document nodestore. Restituisce il seguente stato:
Il fagiolo per questa verifica dello stato è org.apache.sling.Healthcheck:name=slingDiscoveryOakSynchronizedClock,type=HealthCheck. |
Indici asincroni | Controllo Indici asincroni:
Sono configurabili sia le soglie di stato Critico che Avvisi. Il campo di notifica per questo controllo dello stato è org.apache.sling.Healthcheck:name=asinccIndexHealthCheck,type=HealthCheck. Nota: Questo controllo dello stato di salute è disponibile con AEM 6.4 ed è stato riportato a AEM 6.3.0.1. |
Indici Lucene di grandi dimensioni | Questo controllo utilizza i dati esposti da
Le soglie sono configurabili e l'MBean per il controllo dello stato è org.apache.sling.Healthcheck:name=largeIndexHealthCheck,type=HealthCheck. Nota: Questo controllo è disponibile con AEM 6.4 ed è stato riportato a AEM 6.3.2.0. |
Manutenzione sistema | La manutenzione del sistema è un controllo composito che restituisce il OK se tutte le attività di manutenzione sono in esecuzione come configurate. Tenere presente che:
L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=systemcheque,type=HealthCheck. |
Coda di replica | Questo controllo esegue un'iterazione sugli agenti di replica e controlla le rispettive code. Per l'elemento nella parte superiore della coda, il controllo verifica il numero di tentativi di replica ripetuti dall'agente. Se l'agente ha ripetuto la replica oltre il valore del parametro L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=replicaQueue,type=HealthCheck. |
Processi Sling |
Processi Sling verifica il numero di processi in coda in JobManager e li confronta con il
maxNumQueueJobs , e:
È possibile configurare solo il numero massimo di processi in coda e il valore predefinito è 1000. L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=slingJobs,type=HealthCheck. |
Prestazioni delle richieste | Questo controllo esamina la
L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=requestsStatus,type=HealthCheck. |
Errori registro | Questo controllo restituisce lo stato Avvisa in caso di errori nel registro. L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=logErrorHealthCheck,type=HealthCheck. |
Spazio su disco | Il controllo Spazio su disco controlla la
Entrambe le soglie sono configurabili. Il controllo funziona solo sulle istanze con un Segment Store. L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=DiskSpaceHealthCheck,type=HealthCheck. |
Verifica stato modulo di pianificazione | Questo controllo restituisce un avviso se nell’istanza sono in esecuzione processi Quartz per più di 60 secondi. La soglia di durata accettabile è configurabile. L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=slingCommonsSchedulerHealthCheck,type=HealthCheck. |
Verifiche di sicurezza | Il controllo di sicurezza è un insieme composto che aggrega i risultati di più controlli di sicurezza. Questi controlli di integrità individuali risolvono problemi diversi dall'elenco di controllo di sicurezza disponibile nella pagina di documentazione della lista di controllo di sicurezza. Il controllo è utile come test di fumo di sicurezza all'avvio dell'istanza. L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=securityChecks,type=HealthCheck |
Bundle attivi | Bundle attivi controlla lo stato di tutti i bundle e:
Il parametro ignore list è configurabile. L'MBean per questo controllo dello stato è org.apache.sling.Healthcheck:name=inactiveBundles,type=HealthCheck. |
Controllo cache codice | Si tratta di un controllo dello stato che verifica diverse condizioni JVM che possono attivare un bug CodeCache presente in Java 7:
La soglia L'MBean per questa verifica dello stato è org.apache.sling.Healthcheck:name=codeCacheHealthCheck,type=HealthCheck. |
Errori nel percorso di ricerca delle risorse | Controlla se sono presenti risorse nel percorso
L'MBean per questa verifica dello stato è org.apache.sling.Healthcheck:name=resourceSearchPathErrorHealthCheck,type=HealthCheck. |
Il Pannello di controllo dello stato può integrarsi con Nagios tramite i fagioli JMX Granite. L'esempio seguente illustra come aggiungere un controllo che mostra la memoria utilizzata sul server in cui è in esecuzione AEM.
Installazione e installazione di Nagios sul server di monitoraggio.
Quindi, installare il plugin remoto Nagios (NRPE).
Per ulteriori informazioni su come installare Nagios e NRPE sul sistema, consultare la Documentazione Nagios.
Aggiungete una definizione host per il server AEM. Questo può essere fatto tramite l'interfaccia Web di Nagios XI, utilizzando Configuration Manager:
Di seguito è riportato un esempio di un file di configurazione dell'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
}
Installate Nagios e NRPE sul server AEM.
Installate il plug-in check_http_json su entrambi i server.
Definire 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$'
}
Aggiungete 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 il dashboard di Nagios per il servizio appena creato:
Il Pannello di controllo dell'operazione fornisce inoltre l'accesso a Strumenti di diagnostica che possono aiutare a trovare e risolvere le cause principali degli avvisi provenienti dal Pannello di controllo dello stato, nonché fornire importanti informazioni di debug per gli operatori di sistema.
Tra le sue caratteristiche più importanti:
È possibile accedere alla schermata Strumenti di diagnostica scegliendo Strumenti - Operazioni - Diagnosi dalla schermata di benvenuto AEM. Potete inoltre accedere alla schermata accedendo direttamente al seguente URL: https://serveraddress:port/libs/granite/operations/content/diagnosis.html
I messaggi di registro Interfaccia utente visualizzeranno tutti i messaggi di errore per impostazione predefinita. Se desiderate visualizzare più messaggi di registro, dovete configurare un logger con il livello di registro appropriato.
I messaggi di registro utilizzano un appender del registro di memoria e pertanto non sono correlati ai file di registro. 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 di logger in questa interfaccia utente influirà solo sul logger di memoria. Inoltre, si noti che la modifica delle configurazioni del logger si rifletterà nel futuro del in Memory logger - le voci già registrate e non rilevanti non sono più cancellate, ma voci simili non saranno registrate in futuro.
Potete configurare gli elementi registrati fornendo configurazioni del logger dal pulsante in alto a sinistra dell’ingranaggio nell’interfaccia utente. Qui potete aggiungere, rimuovere o aggiornare le configurazioni del logger. Una configurazione logger è composta da un livello di registro (WARN / INFO / DEBUG) e da un nome di filtro. Il nome del 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 "root". Impostando il livello di un logger si attiva l’acquisizione di tutti i messaggi con un livello pari o superiore a quello specificato.
Esempi:
Se si prevede di acquisire tutti i messaggi ERROR, non è necessaria alcuna configurazione. Tutti i messaggi di errore vengono acquisiti per impostazione predefinita.
Se intendete acquisire tutti i messaggi ERROR, WARN e INFO, il nome del logger deve essere impostato su: "root" e il livello di registrazione su: INFO.
Se intendete 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 di registrazione è: DEBUG (in questo modo verranno acquisiti tutti i messaggi ERROR, WARN, INFO e DEBUG), come illustrato nell'immagine seguente.
Non potete impostare un nome di logger per acquisire solo i messaggi di errore tramite un filtro specificato. Per impostazione predefinita, tutti i messaggi di errore vengono acquisiti.
L'interfaccia utente dei messaggi di registro non riflette il registro errori effettivo. A meno che non si configurino altri tipi di messaggi di registro nell'interfaccia utente, verranno visualizzati solo messaggi di errore. Per informazioni sulla visualizzazione di messaggi di registro specifici, vedere le istruzioni riportate sopra.
Le impostazioni nella pagina di diagnosi non influiscono sui contenuti registrati nei file di registro e viceversa. Pertanto, anche se il registro errori potrebbe intercettare i messaggi INFO, potrebbe non essere visualizzato nell'interfaccia utente dei messaggi di registro. Inoltre, tramite l'interfaccia utente è possibile intercettare i messaggi DEBUG da alcuni pacchetti senza che questo influisca sul registro degli errori. Per ulteriori informazioni sulla configurazione dei file di registro, vedere Registrazione.
Con AEM 6.4, le attività di manutenzione vengono disconnesse in un formato più ricco di informazioni a livello di INFO. Ciò consente una migliore visibilità dello stato delle attività di manutenzione.
Se si utilizzano strumenti di terze parti (come Splunk) per monitorare e reagire alle attività di manutenzione, è possibile utilizzare le seguenti istruzioni di registro:
Log level: INFO
DATE+TIME [MaintanceLogger] Name=<MT_NAME>, Status=<MT_STATUS>, Time=<MT_TIME>, Error=<MT_ERROR>, Details=<MT_DETAILS>
La pagina Prestazioni richieste consente di analizzare le richieste di pagina più lente elaborate. Solo le richieste di contenuto verranno registrate in questa pagina. In particolare, verranno acquisite le seguenti richieste:
/content
/etc/design
".html"
Viene visualizzata la pagina:
Per impostazione predefinita, vengono acquisite le 20 richieste di pagina più lente, ma il limite può essere modificato in Gestione configurazione.
La pagina Prestazioni query consente di analizzare le query più lente eseguite dal sistema. Queste informazioni vengono fornite dall'archivio in un Mfavo JMX. In Jackrabbit, il com.adobe.granite.QueryStat
JMX Mava fornisce queste informazioni, mentre nel repository di Oak, è offerto da org.apache.jackrabbit.oak.QueryStats.
Viene visualizzata la pagina:
Per ogni query, Oak tenta di individuare il modo migliore per eseguire in base agli indici Oak definiti nel repository sotto il nodo oak:index. A seconda della query, i diversi indici possono essere scelti da Oak. La comprensione dell’esecuzione di una query da parte di Oak è il primo passo per ottimizzare la query.
La query di spiegazione è uno strumento che spiega in che modo Oak sta eseguendo una query. È possibile accedervi scegliendo Strumenti - Operazioni - Diagnosi dalla schermata di benvenuto AEM, quindi facendo clic su Prestazioni query e passando alla scheda Spiega query.
Funzioni
Una volta che vi trovate nell'interfaccia utente Spiega query, tutto ciò che dovete fare per utilizzarla è immettere la query e premere il pulsante Spiega:
La prima voce nella sezione Spiegazione query rappresenta la spiegazione effettiva. Nella spiegazione verrà visualizzato il tipo di indice utilizzato per eseguire la query.
La seconda voce è il piano di esecuzione.
Se si fa clic sulla casella Includi tempo di esecuzione prima di eseguire la query, viene visualizzato anche il tempo di esecuzione della query, consentendo di visualizzare ulteriori informazioni che possono essere utilizzate per ottimizzare gli indici per l'applicazione o la distribuzione.
Lo scopo di Gestione indici è facilitare la gestione degli indici, ad esempio la manutenzione degli indici o la visualizzazione del relativo stato.
È possibile accedervi andando a Strumenti - Operazioni - Diagnosi dalla schermata introduttiva, quindi facendo clic sul pulsante Index Manager.
È inoltre possibile accedervi direttamente al seguente 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 superiore sinistro dello schermo.
Questo attiverà il download di un file ZIP contenente informazioni utili sullo stato e la configurazione del sistema. L'archivio contiene configurazioni di istanza, un elenco di bundle, OSGI, metriche Sling e statistiche e questo può causare un file di grandi dimensioni. È possibile ridurre l'impatto di file di stato di grandi dimensioni utilizzando la finestra Download Status ZIP. È possibile accedere alla finestra da: AEM > Strumenti > Operazioni > Diagnosi > Download ZIP dello stato.
Da questa finestra è possibile selezionare gli elementi da esportare (file di registro e file di thread) e il numero di giorni di log inclusi nel download rispetto alla data corrente.
Questo attiverà il download di un file ZIP contenente informazioni sui thread presenti nel sistema. Vengono fornite informazioni su ciascun thread, ad esempio lo stato, il caricatore e la traccia di stack.
È inoltre possibile scaricare un’istantanea dell’heap per analizzarla in un secondo momento. Tenete presente che questo attiverà il download di un file di grandi dimensioni, nell'ordine di centinaia di megabyte.
La pagina Attività di manutenzione automatizzata è un luogo in cui è possibile visualizzare e tenere traccia delle attività di manutenzione consigliate pianificate per l'esecuzione periodica. I compiti sono integrati con il sistema di controllo dello stato. Le attività possono essere eseguite manualmente dall'interfaccia.
Per accedere alla pagina Manutenzione del Pannello operazioni, è necessario andare a Strumenti - Operazioni - Dashboard - Manutenzione dalla schermata di benvenuto AEM oppure seguire direttamente questo collegamento:
https://serveraddress:port/libs/granite/operations/content/maintenance.html
Le seguenti attività sono disponibili nel Pannello operazioni:
L'attività Revision Clean Up si trova nel menu Daily Maintenance Window.
L'attività Pulizia binarie Lucene è disponibile nel menu Finestra di manutenzione giornaliera.
L'attività Pulizia flusso di lavoro si trova nel menu Finestra manutenzione settimanale.
L'attività Data Store Garbage Collection, che si trova nel menu Finestra di manutenzione settimanale.
L'attività Gestione log di controllo, situata nel menu Finestra manutenzione settimanale.
L'attività Manutenzione eliminazione versione, che si trova nel menu Finestra manutenzione settimanale.
Il tempo predefinito per la finestra di manutenzione giornaliera è compreso tra 2 e 5 AM. Le attività configurate per l'esecuzione nella finestra di manutenzione settimanale verranno eseguite tra 1 e 2 di sabato.
È inoltre possibile configurare le sincronizzazioni premendo l'icona a forma di ingranaggio su una delle due schede di manutenzione:
A partire dal AEM 6.1, le finestre di manutenzione esistenti possono essere configurate per essere eseguite mensilmente.
Per ulteriori informazioni sull'esecuzione di Revision Clean Up per AEM 6.4, consultare questo articolo dedicato.
Utilizzando l'attività Pulizia binarie Lucene è possibile eliminare i file binari di lucene e ridurre il requisito di dimensioni dell'archivio dati in esecuzione. Questo perché il churn binario di lucene verrà recuperato ogni giorno invece della dipendenza precedente su un'esecuzione garbage collection dell'archivio dati riuscita.
Sebbene l'attività di manutenzione sia stata sviluppata per ridurre i rifiuti di revisione relativi a Lucene, durante l'esecuzione dell'attività si ottengono miglioramenti generali in termini di efficienza:
È possibile accedere all'attività Pulizia binarie Lucene da: AEM > Strumenti > Operazioni > Manutenzione > Finestra di manutenzione giornaliera > Pulizia binarie Lucene.
Per informazioni dettagliate sulla raccolta dei rifiuti nell'archivio dati, vedere la pagina dedicata della documentazione.
I flussi di lavoro possono essere eliminati anche dal dashboard di manutenzione. Per eseguire l'attività Rimozione flusso di lavoro, è necessario:
Per ulteriori informazioni sulla manutenzione dei flussi di lavoro, vedere questa pagina.
Per la manutenzione del registro di controllo, vedere la pagina della documentazione separata.
È possibile pianificare l'attività di manutenzione di Rimozione versioni per eliminare automaticamente le versioni precedenti. Di conseguenza, questo riduce al minimo la necessità di utilizzare manualmente gli strumenti di eliminazione delle versioni. È possibile pianificare e configurare l'attività Rimozione versioni accedendo a Strumenti > Operazioni > Manutenzione > Finestra manutenzione settimanale e seguendo la procedura seguente:
Fare clic sul pulsante Aggiungi.
Scegliete Version Purge dal menu a discesa.
Per configurare l'attività Rimozione versione, fare clic sull'icona ingranaggi nella scheda di manutenzione della rimozione versione appena creata.
Con AEM 6.4, potete interrompere l'attività di manutenzione di Version Purge come segue:
Per interrompere l’attività di manutenzione si intende sospendere l’esecuzione senza perdere traccia del processo già in corso.
Per ottimizzare le dimensioni del repository è necessario eseguire frequentemente l'attività di eliminazione delle versioni. L'attività deve essere programmata al di fuori degli orari di lavoro quando il traffico è limitato.
Le attività di manutenzione personalizzate possono essere implementate come servizi OSGi. Poiché l'infrastruttura delle attività di manutenzione è basata sulla gestione dei lavori 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 arrestata, deve verificare durante l'esecuzione se è stata arrestata e 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 è in alcuna finestra di pianificazione attiva, un controllo dello stato segnalerà questo errore. Il valore predefinito è false. | vero | Facoltativo |
granite.maintenance.name | Un nome univoco per l'attività, utilizzato per fare riferimento all'attività. Di solito si tratta di un nome semplice. | MyMaintenanceTask | Obbligatorio |
granite.maintenance.title | Titolo visualizzato per l'attività | Attività di manutenzione speciale | Obbligatorio |
job.topics | Si tratta di un argomento unico nell’attività di manutenzione. La gestione dei processi Apache Sling avvierà un processo con esattamente 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 sopra riportate, il metodo process()
dell'interfaccia JobConsumer
deve essere implementato aggiungendo il codice da eseguire per l'attività di manutenzione. È possibile utilizzare la JobExecutionContext
fornita per inviare informazioni sullo stato, verificare se il processo viene interrotto dall'utente e creare un risultato (con esito positivo o negativo).
Per le situazioni in cui un'attività di manutenzione non deve essere eseguita su tutte le installazioni (ad esempio, eseguita solo sull'istanza pubblica), potete fare in modo che il servizio richieda una configurazione per essere attivo aggiungendo @Component(policy=ConfigurationPolicy.REQUIRE)
. È quindi possibile contrassegnare la configurazione in base alla modalità di esecuzione a seconda della directory archivio. Per ulteriori informazioni, vedere Configurazione di OSGi.
Di seguito è riportato un esempio di un'attività di manutenzione personalizzata che elimina i file da una directory temporanea configurabile modificata nelle ultime 24 ore:
src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
|
experienceemanager-java-Maintenance-ancetask-sample- src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
Una volta distribuito, il servizio verrà esposto all’interfaccia utente del dashboard operativo e potrà essere aggiunto a una delle pianificazioni di manutenzione disponibili:
Verrà aggiunta una risorsa corrispondente in /apps/granite/operations/config/Maintenance/schedule
/taskname
. Se l'attività dipende dalla modalità di esecuzione, la proprietà granite.operations.condition.runmode deve essere impostata su tale nodo con i valori dei runmode che devono essere attivi per questa attività di manutenzione.
Il Pannello Panoramica sistema visualizza una panoramica di alto livello della configurazione, dell'hardware e dello stato dell'istanza AEM. Questo significa che lo stato di integrità del sistema è trasparente e che tutte le informazioni sono aggregate in un'unica dashboard.
Potete anche guardare questo video per un'introduzione al Pannello Panoramica del sistema.
Per accedere al Pannello Panoramica del sistema, passare a Strumenti > Operazioni > Panoramica del sistema.
La tabella seguente descrive tutte le informazioni visualizzate nel Pannello Panoramica del sistema. Tenere presente che quando non sono disponibili informazioni rilevanti da visualizzare (ad esempio, il backup non è in corso, non sono presenti controlli di integrità critici) nella rispettiva sezione viene visualizzato il messaggio "Nessuna voce".
È inoltre possibile scaricare un file JSON
che riepiloga le informazioni del dashboard facendo clic sul pulsante Scarica nell'angolo superiore destro del dashboard.L'endpoint JSON
è /libs/granite/operations/content/systemoverview/export.json
e può essere utilizzato in uno script curl
per il monitoraggio esterno.
Sezione | Quali informazioni vengono visualizzate | Quando è critico | Collegamenti a |
Verifiche stato |
|
Indicato visivamente:
|
|
Attività di manutenzione |
|
Indicato visivamente:
|
|
Sistema |
|
N/D | N/D |
Istanza |
|
N/D | N/D |
Archivio |
|
N/D | N/D |
Agenti di distribuzione |
|
Indicato visivamente:
|
Pagina di distribuzione |
Agenti di replica |
|
Indicato visivamente:
|
Pagina di replica |
Flussi di lavoro |
Per ciascuno degli stati presentati sopra una query viene eseguito un limite di 400 millisecondi. A 400 millisecondi, viene visualizzato il numero di voci ottenute fino a quel momento. |
Non interpretato:
|
Pagina Errori del flusso di lavoro |
Processi Sling | Conteggio processi Sling - numero di processi in uno stato specificato (se presente):
|
Non interpretato:
|
N/D |
Conteggi nodi stimati | Numero stimato di:
Il numero totale di nodi viene ottenuto dal nodoCounterMBean, mentre il resto delle statistiche viene ottenuto da IndexInfoService. |
N/D | N/D |
Backup | Visualizza "Backup online in corso", se questo è il caso. | N/D | N/D |
Indicizzazione | Display:
Se è presente un thread di indicizzazione o query nel dump del thread. |
N/D | N/D |