Show Menu
ARGOMENTI×

Best practice per monitorare Adobe Experience Manager Assets l'implementazione

Dal Experience Manager Assets punto di vista, il monitoraggio dovrebbe includere l'osservazione e la segnalazione dei seguenti processi e tecnologie:
  • CPU del sistema
  • Utilizzo della memoria di sistema
  • Tempo di attesa IO e IO del disco di sistema
  • I/O di rete del sistema
  • MBeans JMX per l'utilizzo dell'heap e processi asincroni, ad esempio flussi di lavoro
  • Controlli dello stato della console OSGi
In genere, Experience Manager Assets è possibile monitorare i dati in due modi: dal vivo e dal lungo termine.

Monitoraggio live

È necessario eseguire il monitoraggio live durante la fase di test delle prestazioni del proprio sviluppo o durante situazioni di carico elevato per comprendere le caratteristiche di prestazioni dell'ambiente. In genere, il monitoraggio live dovrebbe essere eseguito utilizzando una suite di strumenti. Di seguito sono riportati alcuni suggerimenti:
  • VM visiva: La VM visiva consente di visualizzare informazioni dettagliate sulla VM Java, incluso l'utilizzo della CPU, l'utilizzo della memoria Java. Inoltre, consente di campionare e valutare il codice in esecuzione su una distribuzione.
  • In alto : Top è un comando Linux che apre un dashboard, che visualizza le statistiche di utilizzo, incluso l'utilizzo di CPU, memoria e IO. Fornisce una panoramica di alto livello di ciò che sta accadendo in un’istanza.
  • Htop : Htop è un visualizzatore di processo interattivo. Offre un utilizzo dettagliato della CPU e della memoria oltre a quanto può fornire Top. Htop può essere installato nella maggior parte dei sistemi Linux utilizzando yum install htop o apt-get install htop .
  • Iotop : Iotop è una dashboard dettagliata per l'utilizzo di I/O su disco. Vengono visualizzate barre e misuratori che rappresentano i processi che utilizzano l'I/O del disco e la quantità utilizzata. Iotop può essere installato sulla maggior parte dei sistemi Linux utilizzando yum install iotop o apt-get install iotop .
  • Iftop : Iftop visualizza informazioni dettagliate sull'utilizzo di Ethernet/rete. Iftop visualizza le statistiche sui canali di comunicazione delle entità che utilizzano Ethernet e la quantità di larghezza di banda utilizzata. Iftop può essere installato nella maggior parte dei sistemi Linux utilizzando yum install iftop o apt-get install iftop .
  • Registratore di volo Java (JFR): Uno strumento commerciale di Oracle che può essere utilizzato liberamente in ambienti non di produzione. Per ulteriori dettagli, vedere Come utilizzare il registratore di volo Java per diagnosticare problemi di runtime CQ.
  • Experience Manager error.log file: È possibile esaminare il Experience Manager error.log file per informazioni dettagliate sugli errori registrati nel sistema. Utilizzate il comando tail -F quickstart/logs/error.log per identificare gli errori da esaminare.
  • Console Flusso di lavoro: Utilizza la console del flusso di lavoro per monitorare i flussi di lavoro che si trovano in ritardo o che restano bloccati.
In genere, questi strumenti vengono utilizzati insieme per ottenere un’idea completa delle prestazioni della Experience Manager distribuzione.
Questi strumenti sono strumenti standard e non sono supportati direttamente da Adobe. Non richiedono licenze aggiuntive.
Figura: Monitoraggio dal vivo con lo strumento Visual VM.

Monitoraggio a lungo termine

Il monitoraggio a lungo termine di un' Experience Manager installazione implica il monitoraggio per un periodo più lungo delle stesse porzioni monitorate dal vivo. Include inoltre la definizione di avvisi specifici per l’ambiente.

Aggregazione dei registri e generazione dei rapporti

Sono disponibili diversi strumenti per aggregare i registri, ad esempio Splunk(TM) e Elastic Search, Logstash e Kabana (ELK). Per valutare i tempi di attività della Experience Manager distribuzione, è importante comprendere gli eventi di registro specifici del sistema e creare avvisi basati su di essi. Una buona conoscenza delle procedure di sviluppo e di gestione consente di comprendere meglio come ottimizzare il processo di aggregazione dei log per generare avvisi critici.

Monitoraggio ambientale

Il monitoraggio ambientale include il monitoraggio dei seguenti elementi:
  • Rete
  • IO disco
  • Memoria
  • Utilizzo CPU
  • JMX MBeans
  • Siti Web esterni
Per monitorare ogni elemento sono necessari strumenti esterni, come NewRelic(TM) e AppDynamics(TM). Utilizzando questi strumenti, puoi definire avvisi specifici per il tuo sistema, ad esempio un elevato utilizzo del sistema, un backup del flusso di lavoro, un errore del controllo dello stato o un accesso non autenticato al tuo sito Web. Adobe non consiglia di utilizzare strumenti particolari su altri. Trovate lo strumento che funziona per voi e sfruttatelo per monitorare gli elementi discussi.

Monitoraggio delle applicazioni interne

Il monitoraggio interno delle applicazioni include il monitoraggio dei componenti dell'applicazione che costituiscono lo Experience Manager stack, tra cui JVM, l'archivio dei contenuti e il monitoraggio attraverso il codice dell'applicazione personalizzato integrato nella piattaforma. In generale, viene eseguito tramite MBeg JMX che può essere monitorato direttamente da molte soluzioni di monitoraggio popolari, come SolarWinds (TM), HP OpenView(TM), Hyperic(TM), Zabbix(TM) e altri. Per i sistemi che non supportano una connessione diretta a JMX, è possibile scrivere script shell per estrarre i dati JMX ed esporli a tali sistemi in un formato che essi conoscono nativamente.
Per impostazione predefinita, l'accesso remoto ai fagioli JMX non è attivato. Per ulteriori informazioni sul monitoraggio tramite JMX, consulta Monitoring and Management Using JMX Technology .
In molti casi, è necessaria una linea di base per monitorare efficacemente una statistica. Per creare una linea di base, osservare il sistema in condizioni di lavoro normali per un periodo predeterminato e quindi identificare la metrica normale.
Monitoraggio JVM
Come per qualsiasi stack di applicazioni basato su Java, Experience Manager dipende dalle risorse che gli vengono fornite tramite la macchina virtuale Java sottostante. È possibile monitorare lo stato di molte di queste risorse attraverso i meccanismi MXB della piattaforma esposti da JVM. Per ulteriori informazioni sui file MXBeans, vedere Utilizzo dei server MBean e MXBeans della piattaforma.
Di seguito sono riportati alcuni parametri di base che è possibile monitorare per JVM:
Memoria
  • MBean: lava.lang:type=Memory
  • URL: /system/console/jmx/java.lang:type=Memory
  • Istanze: Tutti i server
  • Soglia allarme: Quando l'utilizzo della memoria heap o non heap supera il 75% della memoria massima corrispondente.
  • Definizione allarme: La memoria del sistema è insufficiente o si verifica una perdita di memoria nel codice. Analizzare un dump di thread per arrivare a una definizione.
Thread
  • MBean: java.lang:type=Threading
  • URL: /system/console/jmx/java.lang:type=Threading
  • Istanze: Tutti i server
  • Soglia allarme: Quando il numero di thread è maggiore del 150% della linea di base.
  • Definizione allarme: È presente un processo di runtime attivo o un'operazione inefficiente che consuma una grande quantità di risorse. Analizzare un dump di thread per arrivare a una definizione.
MonitorExperience Manager
Experience Manager espone inoltre una serie di statistiche e operazioni tramite JMX. Questi possono aiutare a valutare lo stato di salute del sistema e a identificare potenziali problemi prima che abbiano un impatto sugli utenti. Per ulteriori informazioni, consulta la documentazione sugli MBeans Experience Manager JMX.
Di seguito sono riportati alcuni parametri di base che è possibile monitorare per Experience Manager:
Agenti di replica
  • MBean: com.adobe.granite.replication:type=agent,id=”<AGENT_NAME>”
  • URL: /system/console/jmx/com.adobe.granite.replication:type=agent,id=”<AGENT_NAME>"
  • Istanze: Un autore e tutte le istanze pubblicate (per gli agenti di scaricamento)
  • Soglia allarme: Quando il valore di QueueBlocked è true o il valore di QueueNumEntries è maggiore del 150% della linea di base.
  • Definizione allarme: Presenza di una coda bloccata nel sistema per indicare che la destinazione di replica è inattiva o non raggiungibile. Spesso, problemi di rete o di infrastruttura causano la messa in coda di voci eccessive, che possono avere un impatto negativo sulle prestazioni del sistema.
Contatore di sessione
  • MBean: org.apache.jackrabbit.oak:id=7,name="OakRepository Statistics",type="RepositoryStats"
  • URL: /system/console/jmx/org.apache.jackrabbit.oak:id=7,name="Statistiche OakRepository",type ="RepositoryStats"
  • Istanze: Tutti i server
  • Soglia allarme: Quando le sessioni aperte superano la linea di base di oltre il 50%.
  • Definizione allarme: Le sessioni possono essere aperte tramite un frammento di codice e non chiudersi mai. Questo può accadere lentamente nel tempo e alla fine causare perdite di memoria nel sistema. Il numero di sessioni dovrebbe variare su un sistema, ma non dovrebbe aumentare continuamente.
Verifiche stato
I controlli di integrità disponibili nel dashboard Rapporti stato delle operazioni presentano MBeans JMX corrispondenti per il monitoraggio. Tuttavia, potete scrivere controlli di integrità personalizzati per esporre ulteriori statistiche di sistema.
Di seguito sono riportati alcuni controlli di stato out-of-the-box utili per monitorare:
  • Verifiche di sistema
    • MBean: org.apache.sling.healthcheck:name=systemchecks,type=HealthCheck
    • URL: /system/console/jmx/org.apache.sling.healthcheck:name=systemchecks,type=HealthCheck
    • Istanze: Un autore, tutti i server di pubblicazione
    • Soglia allarme: Quando lo stato non è OK
    • Definizione allarme: Lo stato di una delle metriche è WARN o CRITICAL. Per ulteriori informazioni sulla causa del problema, consultate l’attributo di registro.
  • Coda di replica
    • MBean: org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck
    • URL: /system/console/jmx/org.apache.sling.healthcheck:name=replicationQueue,type=HealthCheck
    • Istanze: Un autore, tutti i server di pubblicazione
    • Soglia allarme: Quando lo stato non è OK
    • Definizione allarme: Lo stato di una delle metriche è WARN o CRITICAL. Per ulteriori informazioni sulla coda che ha causato il problema, controllate l’attributo di registro.
  • Prestazioni delle risposte
    • MBean: org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck
    • URL: /system/console/jmx/org.apache.sling.healthcheck:name=requestsStatus,type=HealthCheck
    • Istanze: Tutti i server
    • Durata allarme: Quando lo stato non è OK
    • Definizione allarme: Lo stato di una delle metriche è WARN o CRITICAL. Per ulteriori informazioni sulla coda che ha causato il problema, controllate l’attributo di registro.
  • Prestazioni delle query
    • MBean: org.apache.sling.healthcheck:name=queriesStatus,type=HealthCheck
    • URL: /system/console/jmx/org.apache.sling.healthcheck:name= queriesStatus,type=HealthCheck
    • Istanze: Un autore, tutti i server di pubblicazione
    • Soglia allarme: Quando lo stato non è OK
    • Definizione allarme: Una o più query con esecuzione lenta nel sistema. Per ulteriori informazioni sulle query che hanno causato il problema, consultate l'attributo di registro.
  • Bundle attivi
    • MBean: org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck
    • URL: /system/console/jmx/org.apache.sling.healthcheck:name=inactiveBundles,type=HealthCheck
    • Istanze: Tutti i server
    • Soglia allarme: Quando lo stato non è OK
    • Definizione allarme: Presenza nel sistema di bundle OSGi inattivi o non risolti. Per ulteriori informazioni sui bundle che hanno causato il problema, consultate l'attributo di registro.
  • Errori registro
    • MBean: org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck
    • URL: /system/console/jmx/org.apache.sling.healthcheck:name=logErrorHealthCheck,type=HealthCheck
    • Istanze: Tutti i server
    • Soglia allarme: Quando lo stato non è OK
    • Definizione allarme: I file di registro presentano degli errori. Per ulteriori informazioni sulla causa del problema, consultate l’attributo di registro.

Problemi comuni e risoluzioni

Nel processo di monitoraggio, in caso di problemi, sono disponibili alcune attività di risoluzione dei problemi che è possibile eseguire per risolvere i problemi più comuni relativi Experience Manager alle distribuzioni:
  • Se si utilizza TarMK, eseguire spesso la compattazione Tar. Per ulteriori dettagli, vedere Gestione della directory archivio .
  • Controllare OutOfMemoryError i registri. Per ulteriori informazioni, consultate Analizzare i problemi di memoria.
  • Controllate i file di registro per eventuali riferimenti a query non indicizzate, traversate ad albero o traverse di indice. Ciò indica query non indicizzate o query indicizzate in modo inadeguato. Per le best practice sull'ottimizzazione delle prestazioni di query e indicizzazione, vedere Best practice per query e indicizzazione .
  • Utilizzate la console del flusso di lavoro per verificare che i flussi di lavoro funzionino come previsto. Se possibile, condensa più flussi di lavoro in un unico flusso di lavoro.
  • Rivedere il monitoraggio live e cercare ulteriori strozzature o elevati consumatori di risorse specifiche.
  • Esaminare i punti di uscita dalla rete client e i punti di ingresso alla rete di Experience Manager distribuzione, incluso il dispatcher. Spesso si tratta di aree con collo di bottiglia. Per ulteriori informazioni, consulta Considerazioni sulla rete delle risorse .
  • Ridimensionare il Experience Manager server. È possibile che la Experience Manager distribuzione non sia sufficientemente dimensionata. L'Assistenza clienti Adobe può aiutarti a identificare se il server è di dimensioni ridotte.
  • Esaminare i access.log file e error.log le voci relative al momento in cui qualcosa è andato storto. Cercare pattern che possono indicare anomalie di codice potenzialmente personalizzate. Aggiungeteli all’elenco degli eventi monitorati.