Il dashboard delle operazioni nel AEM 6 aiuta gli operatori di sistema a monitorare AEM lo stato del sistema a colpo d'occhio. Fornisce inoltre informazioni di diagnosi generate automaticamente sugli aspetti rilevanti della AEM e consente di configurare ed eseguire l'automazione della manutenzione autonoma per ridurre in modo significativo le operazioni di progetto e i casi di supporto. Il dashboard delle operazioni può essere esteso con controlli di integrità personalizzati e attività di manutenzione. Inoltre, i dati del dashboard delle operazioni sono accessibili da strumenti di monitoraggio esterni tramite JMX.
Dashboard delle operazioni:
È possibile accedervi andando su Strumenti - Operazioni dalla schermata di benvenuto AEM.
Per poter accedere al Dashboard delle 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 rapporto sullo stato di salute fornisce informazioni sullo stato di un'istanza AEM tramite Sling Health Checks. Questo può essere fatto tramite OSGI, JMX, richieste HTTP (tramite JSON) o tramite l'interfaccia utente touch. Offre misurazioni e soglia di determinati contatori configurabili e, in alcuni casi, offrirà informazioni su come risolvere il problema.
Presenta diverse funzioni, descritte di seguito.
Le relazioni sulla salute sono un sistema di carte che indicano una buona o cattiva salute per quanto riguarda una specifica area di prodotto. Queste schede sono visualizzazioni degli Sling Health Checks, che aggregano i dati da JMX e altre fonti ed espongono di nuovo le informazioni elaborate come MBeans. Questi MBeans possono anche essere ispezionati nella console web JMX, nel dominio org.apache.sling.health.check .
L'interfaccia dei rapporti sullo stato è accessibile tramite il menu Strumenti - Operazioni - Rapporti sullo stato nella schermata di benvenuto AEM o direttamente tramite il seguente URL:
https://<serveraddress>:port/libs/granite/operations/content/healthreports/healthreportlist.html
Il sistema di carte espone tre possibili stati: OK, WARN 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:
Nella AEM 6 esistono due tipi di controlli sanitari:
Un controllo integrità individuale è un singolo controllo dello stato 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 il controllo "Log Errors" come esempio: se ci sono voci ERROR nei log di istanza, le troverai nella pagina dei dettagli del controllo di integrità. Nella parte superiore della pagina viene visualizzato un collegamento all’analizzatore "Log Message" nella sezione Strumenti di diagnosi, che consente di analizzare questi errori in modo più dettagliato e riconfigurare i logger.
Una Verifica dello stato composito è un controllo che aggrega le informazioni provenienti da diversi controlli individuali.
I controlli di integrità compositi sono configurati con l'ausilio di tag filtro. In sostanza, tutti i controlli singoli con lo stesso tag di filtro verranno raggruppati come un controllo di integrità composito. Un controllo di integrità composito avrà uno stato OK solo se tutti i controlli singoli che aggrega hanno anche lo stato OK.
Nel Dashboard delle operazioni è possibile visualizzare il risultato dei controlli di integrità individuali e compositi.
La creazione di un singolo controllo integrità prevede due passaggi: implementazione di un controllo dello stato di Sling 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 identificano completamente il controllo dello stato. Una volta installato il componente, verrà automaticamente creato un MBean JMX per il controllo dello stato. Per ulteriori informazioni, consulta la Documentazione Sling Health Check .
Esempio di un 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
}
}
La proprietà MBEAN_NAME
definisce il nome del mbean che verrà generato per questo controllo di integrità.
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 JMX Mbean del controllo di integrità (la proprietà MBEAN_NAME
). Per creare una configurazione per il controllo dello stato, apri CRXDE e aggiungi un nuovo 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 di cui sopra viene creato come segue: se il nome del fagiolo del controllo di integrità è "test", aggiungi "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
Assicurati che le seguenti proprietà del percorso /apps/settings/granite/operations/hc
siano impostate su true:
sling:configCollectionInherit
sling:configPropertyInherit
Questo dirà al gestore di configurazione di unire le nuove configurazioni con quelle esistenti da /libs
.
Il ruolo di un controllo dello stato composito consiste nell'aggregare un certo numero di controlli di integrità individuali che condividono un insieme di funzioni comuni. Ad esempio, il Security Composite Health Check raggruppa tutti i singoli controlli di integrità che eseguono verifiche relative alla sicurezza. Il primo passo per creare un controllo composito è quello di 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.
Vai a Web Configuration Manager nella console OSGI. Per farlo, accedi a https://serveraddress:port/system/console/configMgr
Cerca la voce denominata Verifica dello stato composito di Apache Sling. Una volta trovato, noterai che sono già disponibili due configurazioni: uno per i controlli di sistema e un altro per i controlli di sicurezza.
Crea una nuova configurazione premendo il pulsante "+" sul lato destro della configurazione. Viene visualizzata una nuova finestra, come illustrato di seguito:
Crea una configurazione e salvala. Verrà creato un Mbean con la nuova configurazione.
Lo scopo di ciascuna proprietà di configurazione è il seguente:
hc.tags
).Viene creato un nuovo Mbean JMX per ogni nuova configurazione di Apache Sling Composite Health Check.**
Infine, è necessario aggiungere la voce del controllo di integrità composito appena creato nei nodi di configurazione del dashboard delle operazioni. La procedura è la stessa dei controlli sanitari individuali: è necessario creare un nodo di tipo nt:unstructured in /apps/settings/granite/operations/hc
. La proprietà della risorsa del nodo sarà definita dal valore di hc.media.name nella configurazione OSGI.
Se, ad esempio, hai creato una configurazione e impostato il valore hc.mbean.name su diskusage, i nodi di configurazione avranno questo aspetto:
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 crei controlli di integrità individuali che logicamente appartengono a un controllo composito già presente nel dashboard per impostazione predefinita, questi verranno acquisiti automaticamente e raggruppati sotto il rispettivo controllo composito. Per questo motivo, non è necessario creare un nuovo nodo di configurazione per questi controlli.
Ad esempio, se crei un singolo controllo di integrità della sicurezza, tutto ciò che devi fare è assegnargli il tag "security" e viene installato, apparirà automaticamente sotto il controllo composito Controlli di sicurezza nel dashboard delle operazioni.
Nome zHealthcheck | Descrizione |
Prestazioni delle query | Questo controllo dello stato di salute è stato semplificato in AEM 6.4 e ora controlla l'attributo L'MBean per questo controllo di integrità è org.apache.sling.health.check:name=queryStatus,type=HealthCheck. |
Lunghezza coda di osservazione | La lunghezza della coda di osservazione esegue un iterazione su tutti gli ascoltatori di eventi e gli osservatori di background, confronta i loro
La lunghezza massima di ogni coda proviene da configurazioni separate (Oak e AEM) e non è configurabile da questo controllo di integrità. L'MBean per questo controllo di integrità è org.apache.sling.health.check:name=ObservationQueueLengthHealthCheck,type=HealthCheck. |
Limiti di attraversamento per query | I limiti di attraversamento delle query controllano i MBean
Il Mbean per questo controllo di integrità è org.apache.sling.health.check:name=queryTraversalLimitsBundle,type=HealthCheck. |
Orologi sincronizzati | Questo controllo è pertinente solo per i cluster document nodestore. Restituisce il seguente stato:
Il Mbean per questo controllo di integrità è org.apache.sling.health.check:name=slingDiscoveryOakSynchronizedClocks,type=HealthCheck. |
Indici asincroni | Controllo degli indici asincroni:
Le soglie di stato Critico e Avvisa sono configurabili. Il Mbean per questo controllo di integrità è org.apache.sling.health.check:name=asyncIndexHealthCheck,type=HealthCheck. Nota: Questo controllo dello stato di salute è disponibile con AEM 6.4 ed è stato riportato al 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 di salute è org.apache.sling.health.check: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 l'OK se tutte le attività di manutenzione sono in esecuzione come configurato. Tieni presente che:
L'MBean per questo controllo di integrità è org.apache.sling.health.check:name=systemChecks,type=HealthCheck. |
Coda di replica | Questo controllo esegue iterazioni sugli agenti di replica e controlla le loro code. Per l'elemento nella parte superiore della coda, il controllo controlla quante volte l'agente ha effettuato un nuovo tentativo di replica. Se l'agente ha effettuato un nuovo tentativo di replica oltre il valore del parametro L'MBean per questo controllo di integrità è org.apache.sling.health.check:name=replicationQueue,type=HealthCheck. |
Processi Sling |
Sling Jobs controlla il numero di processi in coda nel JobManager, confrontandolo con il
maxNumQueueJobs soglia e:
È configurabile solo il numero massimo di processi in coda e il valore predefinito è 1000. La MBean per questo controllo di integrità è org.apache.sling.health.check:name=slingJobs,type=HealthCheck. |
Prestazioni delle richieste | Questo controllo esamina la
L'MBean per questo controllo di integrità è 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 di integrità è org.apache.sling.health.check:name=logErrorHealthCheck,type=HealthCheck. |
Spazio su disco | Il controllo Spazio su disco esamina la
Entrambe le soglie sono configurabili. Il controllo funziona solo sulle istanze con un archivio segmenti. La MBean per questo controllo di integrità è org.apache.sling.health.check:name=DiskSpaceHealthCheck,type=HealthCheck. |
Verifica stato modulo di pianificazione | Questo controllo restituisce un avviso se l’istanza dispone di processi Quartz in esecuzione per più di 60 secondi. La soglia di durata accettabile è configurabile. La MBean per questo controllo di integrità è org.apache.sling.health.check:name=slingCommonsSchedulerHealthCheck,type=HealthCheck. |
Verifiche di sicurezza | Il controllo di sicurezza è un composito che aggrega i risultati di più controlli relativi alla sicurezza. Questi controlli di integrità individuali risolvono problemi diversi dalla lista di controllo della sicurezza disponibile nella pagina di documentazione Lista di controllo della sicurezza . Il controllo è utile come prova di fumo di sicurezza all'avvio dell'istanza. L'MBean per questo controllo di integrità è org.apache.sling.health.check:name=securityChecks,type=HealthCheck |
Bundle attivi | Bundle attivi controlla lo stato di tutti i bundle e:
Il parametro di elenco di ignoramenti è configurabile. L'MBean per questo controllo di integrità è org.apache.sling.health.check:name=inactiveBundles,type=HealthCheck. |
Controllo della cache del codice | Questo è un controllo dello stato che verifica diverse condizioni JVM che possono attivare un bug CodeCache presente in Java 7:
La soglia L'MBean per questo controllo di integrità è org.apache.sling.health.check:name=codeCacheHealthCheck,type=HealthCheck. |
Errori nel percorso di ricerca delle risorse | Controlla se sono presenti risorse nel percorso
L'MBean per questo controllo di integrità è org.apache.sling.health.check:name=resourceSearchPathErrorHealthCheck,type=HealthCheck. |
Il dashboard di controllo dello stato può integrarsi con Nagios tramite il 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 il plugin remoto Nagios (NRPE).
Per ulteriori informazioni su come installare Nagios e NRPE sul tuo sistema, consulta la Documentazione di Nagios.
Aggiungi una definizione host per il server AEM. Questo può essere fatto tramite l'interfaccia Web Nagios XI, utilizzando Configuration Manager:
Di seguito è riportato un esempio di file di configurazione dell'host, nel caso in cui 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
}
Installa Nagios e NRPE sul server AEM.
Installa 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$'
}
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 il tuo dashboard di Nagios per il servizio appena creato:
Il dashboard dell'operazione fornisce anche l'accesso agli strumenti di diagnosi che possono aiutare a trovare e risolvere le cause principali degli avvisi provenienti dal dashboard di controllo dello stato, nonché fornire informazioni di debug importanti per gli operatori di sistema.
Tra le sue caratteristiche più importanti:
Per accedere alla schermata Strumenti di diagnosi, vai a Strumenti - Operazioni - Diagnosi dalla schermata di benvenuto AEM. Puoi anche accedere direttamente alla schermata accedendo direttamente al seguente URL: https://serveraddress:port/libs/granite/operations/content/diagnosis.html
Per impostazione predefinita, l'interfaccia utente dei messaggi di log visualizza tutti i messaggi ERROR. Se desideri visualizzare più messaggi di log, devi configurare un logger con il livello di log appropriato.
I messaggi di log utilizzano un appender del log in memoria e quindi non sono correlati ai file di log. Un’altra conseguenza è che la modifica dei livelli di registro in questa interfaccia utente non modificherà le informazioni registrate nei file di registro tradizionali. L’aggiunta e la rimozione di logger in questa interfaccia utente influirà solo sul logger di memoria in . Inoltre, si noti che la modifica delle configurazioni del logger si rifletterà nel futuro del logger di memoria - le voci che sono già registrate e non sono più rilevanti non vengono eliminate, ma voci simili non verranno registrate in futuro.
Puoi configurare ciò che viene registrato fornendo configurazioni del logger dal pulsante in alto a sinistra dell’ingranaggio nell’interfaccia utente. Qui puoi aggiungere, rimuovere o aggiornare le configurazioni del logger. Una configurazione del logger è composta da un livello di log (WARN / INFO / DEBUG) e da un nome filtro. Il nome filtro ha il ruolo di filtrare l'origine dei messaggi di log che vengono registrati. In alternativa, se un logger deve acquisire tutti i messaggi di log per il livello specificato, il nome del filtro deve essere "root". L’impostazione del livello di un logger attiverà l’acquisizione di tutti i messaggi con un livello uguale o superiore a quello specificato.
Esempi:
Se prevedi di acquisire tutti i messaggi ERROR, non è necessaria alcuna configurazione. Tutti i messaggi ERROR vengono acquisiti per impostazione predefinita.
Se prevedi di acquisire tutti i messaggi ERROR, WARN e INFO, il nome del logger deve essere impostato su: "root" e il livello di logger a: 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 di logger è: DEBUG (questo acquisirà tutti i messaggi ERROR, WARN, INFO e DEBUG), come mostrato nell'immagine seguente.
Non è possibile impostare un nome di logger per acquisire solo i messaggi ERROR tramite un filtro specificato. Per impostazione predefinita, tutti i messaggi ERROR vengono acquisiti.
L'interfaccia utente dei messaggi di log non riflette l'effettivo registro degli errori. A meno che non si configurino altri tipi di messaggi di log nell'interfaccia utente, verranno visualizzati solo i messaggi ERROR. Per informazioni su come visualizzare messaggi di log specifici, consulta le istruzioni riportate sopra.
Le impostazioni nella pagina di diagnosi non influenzano ciò che viene registrato nei file di log e viceversa. Pertanto, anche se il registro degli errori potrebbe rilevare i messaggi INFO, potrebbero non essere visualizzati nell'interfaccia utente dei messaggi di log. Inoltre, attraverso l'interfaccia utente è possibile catturare i messaggi DEBUG da alcuni pacchetti senza che questo influisca sul registro degli errori. Per ulteriori informazioni su come configurare i file di registro, consulta Logging.
Con AEM 6.4, le attività di manutenzione vengono disconnesse in un formato più ricco di informazioni a livello INFO. Ciò consente una migliore visibilità dello stato delle attività di manutenzione.
Se utilizzi strumenti di terze parti (come Splunk) per monitorare e reagire all’attività di manutenzione, puoi 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 richiesta 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 Configuration Manager.
La pagina Prestazioni query consente di analizzare le query più lente eseguite dal sistema. Queste informazioni sono fornite dall'archivio in un Mbean JMX. In Jackrabbit, il com.adobe.granite.QueryStat
JMX Mbean fornisce queste informazioni, mentre nell'archivio Oak, è offerto da org.apache.jackrabbit.oak.QueryStats.
Viene visualizzata la pagina:
Per qualsiasi query specifica, Oak cerca di trovare il modo migliore per eseguire in base agli indici Oak definiti nell'archivio sotto il nodo oak:index. A seconda della query, Oak può scegliere indici diversi. La comprensione di come Oak sta eseguendo una query è il primo passaggio per ottimizzare la query.
La query di spiegazione è uno strumento che spiega come Oak sta eseguendo una query. È possibile accedervi andando su Strumenti - Operazioni - Diagnosi dalla schermata di benvenuto AEM, quindi facendo clic su Prestazioni query e passando alla scheda Spiega query .
Funzioni
Una volta nell'interfaccia utente di Explain Query, tutto ciò che devi fare per usarla è inserire la query e premere il pulsante Spiega:
La prima voce nella sezione Spiegazione query è la spiegazione effettiva. Nella spiegazione verrà visualizzato il tipo di indice utilizzato per eseguire la query.
La seconda voce è il piano di esecuzione.
Quando si fa clic sulla casella Includi tempo di esecuzione prima di eseguire la query, viene visualizzata anche la quantità di tempo in cui la query è stata eseguita, consentendo 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 su Strumenti - Operazioni - Diagnosi dalla schermata iniziale, quindi fai clic sul pulsante Gestione indici .
È inoltre possibile accedervi direttamente a 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 del filtro nella casella di ricerca nell’angolo in alto a sinistra dello schermo.
Questo attiverà il download di un file ZIP contenente informazioni utili sullo stato e sulla configurazione del sistema. L'archivio contiene configurazioni di istanza, un elenco di bundle, OSGI, metriche Sling e statistiche e questo può portare a un file di grandi dimensioni. È possibile ridurre l’impatto di file di stato di grandi dimensioni utilizzando la finestra Download Status ZIP (Scarica stato). È possibile accedere alla finestra da: AEM > Strumenti > Operazioni > Diagnosi > Scarica ZIP stato.
Da questa finestra è possibile selezionare gli elementi da esportare (file di registro e o immagini 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 ogni thread, ad esempio il suo stato, il classloader e lo stacktrace.
È inoltre possibile scaricare un’istantanea dell’heap, in modo da analizzarla in un secondo momento. Tieni presente che questo attiverà il download di un file di grandi dimensioni, nell’ordine di centinaia di megabyte.
La pagina Attività di manutenzione automatica è un luogo 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 controllo dello stato di salute. Le attività possono anche essere eseguite manualmente dall’interfaccia .
Per passare alla pagina Manutenzione nel Dashboard delle operazioni, è necessario passare 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 dashboard delle operazioni:
L'attività Revision Clean Up si trova nel menu Daily Maintenance Window .
L'attività Pulizia binari Lucene si trova nel menu Finestra di manutenzione giornaliera.
L'attività Pulizia del flusso di lavoro si trova nel menu Finestra di manutenzione settimanale.
L'attività Archivio dati raccolta oggetti inattivi, che si trova nel menu Finestra manutenzione settimanale.
L'attività Manutenzione 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. Le attività configurate per l'esecuzione nella finestra di manutenzione settimanale verranno eseguite tra le 1 e le 2 del mattino del sabato.
È inoltre possibile configurare i tempi premendo l'icona ingranaggio su una delle due schede di manutenzione:
A partire dal AEM 6.1, le finestre di manutenzione esistenti possono essere configurate per l'esecuzione mensile.
Per ulteriori informazioni sull'esecuzione del cleanup delle revisioni per AEM 6.4, consulta questo articolo dedicato.
Utilizzando l'attività Pulizia binari Lucene, è possibile eliminare i binari lucene e ridurre il fabbisogno di dimensioni dell'archivio dati in esecuzione. Questo perché l'abbandono binario di lucene verrà ririchiesto quotidianamente invece della dipendenza precedente da un'esecuzione garbage collection dell'archivio dati riuscita.
Anche se l'attività di manutenzione è stata sviluppata per ridurre i rifiuti di revisione relativi a Lucene, ci sono miglioramenti generali di efficienza quando si esegue l'attività:
Puoi accedere all’attività Pulizia binari Lucene da: AEM > Strumenti > Operazioni > Manutenzione > Finestra Manutenzione giornaliera > Pulizia binari Lucene.
Per informazioni dettagliate sulla raccolta degli oggetti inattivi nell'archivio dati, vedere la pagina dedicata di documentazione.
I flussi di lavoro possono anche essere eliminati dal dashboard di manutenzione. Per eseguire l’attività Elimina flusso di lavoro, è necessario:
Per informazioni più dettagliate sulla manutenzione del flusso di lavoro, consulta questa pagina.
Per la manutenzione del registro di controllo, vedere la pagina della documentazione separata.
È possibile pianificare l'attività di manutenzione Pulizia versione 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à Pulizia versione accedendo a Strumenti > Operazioni > Manutenzione > Finestra manutenzione settimanale e seguendo questi passaggi:
Fai clic sul pulsante Aggiungi .
Scegli Pulizia versione dal menu a discesa.
Per configurare l'attività Pulizia versione, fai clic sull'icona ingranaggi nella scheda di manutenzione Pulizia versione appena creata.
Con AEM 6.4, puoi interrompere l’attività di manutenzione Pulizia versione come segue:
Per interrompere l’attività di manutenzione, sospenderne l’esecuzione senza perdere traccia del processo già in corso.
Per ottimizzare le dimensioni del repository, è necessario eseguire frequentemente l'attività di eliminazione della versione. L'attività deve essere pianificata al di fuori dell'orario di lavoro quando vi è 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 arrestata, deve verificare durante la sua 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 è presente in alcuna finestra di pianificazione attiva, un controllo integrità segnalerà l'errore. Il valore predefinito è false. | vero | Facoltativo |
granite.maintenance.name | Nome univoco dell'attività, utilizzato per fare riferimento all'attività. Questo è di solito un nome semplice. | AttivitàManutenzionePersonale | Obbligatorio |
granite.maintenance.title | Titolo visualizzato per l'attività | Attività di manutenzione speciale | Obbligatorio |
job.topics | Questo è un argomento unico dell'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 di cui sopra, il metodo process()
dell'interfaccia JobConsumer
deve essere implementato aggiungendo il codice da eseguire per l'attività di manutenzione. Il JobExecutionContext
fornito può essere utilizzato per generare informazioni sullo stato, controllare se il processo viene interrotto dall'utente e creare un risultato (riuscito o non riuscito).
Per le situazioni in cui un’attività di manutenzione non deve essere eseguita su tutte le installazioni (ad esempio, eseguita solo sull’istanza di pubblicazione), puoi fare sì che il servizio richieda una configurazione per essere attivo aggiungendo @Component(policy=ConfigurationPolicy.REQUIRE)
. Puoi quindi contrassegnare la configurazione in base alla modalità di esecuzione a seconda dell’archivio. Per ulteriori informazioni, consulta Configurazione di OSGi.
Di seguito è riportato un esempio di un'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-maintenance-ancetask-sample - src/main/java/com/adobe/granite/samples/maintenance/impl/DeleteTempFilesTask.java
Una volta implementato, il servizio verrà esposto all’interfaccia utente del dashboard delle operazioni e può 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.Conditions.runmode deve essere impostata su quel nodo con i valori delle modalità di esecuzione che devono essere attive per questa attività di manutenzione.
Il Dashboard panoramica sistema visualizza una panoramica di alto livello della configurazione, dell'hardware e dello stato dell'istanza AEM. Ciò significa che lo stato di integrità del sistema è trasparente e che tutte le informazioni sono aggregate in un unico dashboard.
Puoi anche guardare questo video per un'introduzione al dashboard Panoramica sistema.
Per accedere al dashboard Panoramica sistema, passa a Strumenti > Operazioni > Panoramica del sistema.
La tabella seguente descrive tutte le informazioni visualizzate nel dashboard Panoramica sistema. Tieni presente che quando non sono presenti informazioni rilevanti da mostrare (ad esempio, il backup non è in corso, non sono presenti controlli di integrità critici) nella rispettiva sezione verrà visualizzato il messaggio "Nessuna voce".
È inoltre possibile scaricare un file JSON
che riepiloga le informazioni del dashboard facendo clic sul pulsante Scarica nell'angolo in alto a destra 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 | Informazioni 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 viene eseguita una query con un limite di 400 millisecondi. A 400 millisecondi viene visualizzato il numero di voci ottenute fino a quel momento. |
Non interpretato:
|
Pagina Errori di flusso di lavoro |
Processi Sling | Conteggi dei processi Sling - numero di processi in uno stato specifico (se presenti):
|
Non interpretato:
|
N/D |
Conteggi nodi stimati | Numero stimato di:
Il numero totale di nodi viene ottenuto da nodeCounterMBean, 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 un thread di indicizzazione o query è presente nel dump di thread. |
N/D | N/D |